Агенты для программирования на базе ИИ — это не мимолётный тренд, а развивающаяся часть современного процесса разработки. Разработчикам становится всё важнее уметь эффективно использовать такие инструменты, чтобы повышать продуктивность и качество своей работы.
Большие языковые модели (LLM) не стоит воспринимать как взаимозаменяемые. Выбор модели существенно влияет на качество работы, которую выполняет агент.
Привет! Хочу с тобой поделиться своим опытом. Долгое время я считал, что нужно стать экспертом, прежде чем начинать кого‑то учить. Типа, сначала освой технологию на 150%, потом уже открывай рот. Классическое мышление перфекциониста, не правда ли?
Пару лет назад ко мне в команду пришёл джун. Классический случай — куча вопросов и Angular знает примерно на уровне «я умею делать кнопочки». В это время подъезжает очередной проект «надо было вчера» на SSR.
Недавно работал над хобби-проектом, который описал в другой своей статьеЧитать полностью »
Речь пойдет конечно же о списках с виртуализацией.
В классическом исполнении, списки включают в себя все элементы из коллекции. Другими словами, те элементы, которые не видны пользователю (находятся за пределами вьюпорта) все равно присутствуют в DOM дереве. А теперь представим, если список состоит допустим из 1 000 000 элементов, как это повлияет на производительность и ресурсоемкось? Ответ очевиден, пропорционально объёму коллекции будет расти ресурсопотребление и снижаться общая производительность.
Всем привет! Сегодня хочу разобрать кейс, с которым сталкивается почти каждый Angular-разработчик на существующем проекте.
Часто в компонентах можно встретить такой код:
public user: User | null = null;
public posts: Post[] | null = null;
public stats: Stats | null = null;
constructor(private readonly apiService: ApiService) {}
public ngOnInit(): void {
this.apiService.getUser().subscribe((user) => this.user = user);
this.apiService.getPosts().subscribe((posts) => this.posts = posts);
this.apiService.getStats().subscribe((stats) => this.stats = stats);
}Все загрузки данных у нас происходят в ngOnInitЧитать полностью »
Всем привет! 👋 Меня зовут Мансур, я фронтенд-разработчик в payme — в одном из крупнейших финтех-сервисов в Узбекистане, через который ежедневно проходят миллионы транзакций. Помимо основной функции, мы активно развиваем дополнительное направление Lifestyle-сервисов внутри мобильного приложения. В этом посте хочу поделиться практическим опытом внедрения WebView: расскажу, как мы используем его в продуктах payme avia и payme tickets, почему выбрали именно такой подход, какие преимущества он даёт, и с какими ограничениями приходится мириться на практике.
Во фронтенд-разработке довольно быстро возникает вопрос: как всё оформить удобно, красиво и единообразно? Сначала всё кажется очевидным – документация показывает, как создать базовый building block, компонент, а дальше чередуй ими и жонглируй, как душе угодно. Более того, можно сильно сэкономить время, используя готовые UI-библиотеки, в которые уже вложены десятки человеко-часов. Но, по мере поступления всё новых задач, порой встают вопросы, которые в какой-то момент побуждают к написанию своего собственного UI Kit.
Всем доброго времени суток! Меня зовут Сергей, мне 18 лет, я Angular разработчик. Это моя первая статья на Хабр, строго не судите, интересно мнение со стороны.
Мой реальный опыт в Angular — почти 11 месяцев, а в общем во фронтенде около 2.5 лет. До этого я работал на React.
Теперь к сути статьи, недавно я решил пооткликаться на вакансии junior и middle Angular разработчиков, везде в сопроводительных письмах указывая, что у меня опыта 10 месяцев, но зато он настоящий а не накрученный.
Если вы разрабатывали приложения на Angular, то наверняка сталкивались с ситуацией, когда множество компонентов требуют тесного взаимодействия друг с другом. Например:
Один компонент должен отправлять события другому компоненту (или нескольким), что часто приводит к написанию громоздкого и запутанного кода.
Использование Input/Output связей может подходить для простых случаев, но становится затруднительным в масштабируемых приложениях.
Проблемы с утечками при работе с RxJS Subjects или Event EmittersЧитать полностью »
Пару лет назад для .NET в Linux не было не то чтобы production-ready фреймворков для создания native desktop приложений, но и экспериментальных. На тот момент существовали Uno Platform и Avalonia (тогда еще бета). Они запускались, работали, но написать реальное и относительно сложное приложение было практически нереально. Сегодня ситуация значительно лучше. Avalonia уже вполне production-ready продукт и является, на мой взгляд, лидером среди desktop фреймворков на .NET для Linux.
В этой статье я расскажу об экспериментальной связке технологий, которую я раньше не встречал нигде и основным мотиватором была проверка жизнеспособности этой идеи.