Представьте мир, где каждый персонаж живёт своей жизнью: принимает решения, взаимодействует с окружающей средой и даже эволюционирует. Где почва, растения и ресурсы подчиняются сложным алгоритмам, а нейронные сети управляют поведением тысяч существ. Это не сценарий для нового блокбастера — это проект, над которым я работаю.
В этой статье я расскажу, как с помощью NestJS, TypeORM и Tensorflow.js создаю виртуальную вселенную, которая “дышит” и развивается. Мы разберём:
Всем привет, с вами Максим Иванов, и сегодня мы поговорим о некоторых улучшениях, которые появились в последней версии Angular 19, вышедшей в ноябре 2024. Публикация довольно запоздалая с этой точки зрения, но мы сегодня постараемся рассмотреть некоторые нововведения более детально. Как и всегда ребята из Google дарят нам что-то новое, что сделает наши приложения еще более быстрыми и эффективными. И в этом нам помогут модерновые реактивные примитивы, инкрементальная гидратация и многое другое.
В этой статье я рассказываю об эффектах. Несмотря на то, что эффект – понятие столь же простое, как обычная функция, для меня оказалось не так просто найти подходящее объяснение, но, я его нашел.
Вы узнаете, в чем заключается идея использования эффектов и чем они отличаются от классических функций. Я делюсь своим опытом разработчика и показываю примеры кода с использованием эффектов. Вероятно вы найдете для себя что-то интересное.
Если вы никогда не слышали об эффектах или термине "побочный эффект", рекомендую ознакомиться с этой темой для повышения вашего профессионального уровня и технического кругозора!
Всем нам, разработчикам, приходится сталкиваться с задачей создания тестовых данных. Это могут быть как простые объекты (например, пользователь с именем, email и ролями), так и сложные вложенные структуры: API-ответы, модели базы данных и так далее. Это особенно актуально при написании unit-тестов, когда нам нужны разнообразные данные для проверки разных сценариев.
И вот тут становится понятно, сколько времени мы тратим на эту рутину. Либо вручную создаем объекты, либо используем более простые инструменты, которые не всегда подходят для сложных проектов. Так появился инструмент — библиотека @artstesh/forger, созданная специально для таких задач, чтобы в разы сократить наше время и упростить процесс разработки. Давайте разберем, как она работает и почему это будет полезно.
Привет, Хабр! Меня зовут Алёна, я senior фронтенд-разработчик отдела разработки ПО для розничного бизнеса в Райффайзенбанке. Недавно передо мной встала задача улучшения пользовательского опыта обработки ошибок запросов к бэкенду. Я решила комплексно исследовать эту тему на примере HTTP-клиента Axios.
Если при отправке запросов с помощью Axios возникает ошибка — клиентское приложение получает аргумент, который может быть экземпляром объекта, производного от системного класса Error, или любым типом. Он может содержать много информации и не всегда понятно, что самое важное для определения типа исключения и способа обработки. Поэтому я выделала 4 категории ошибок запросов, сделанных при помощи Axios, которые нужно по-разному интерпретировать.
Написать эту статью меня побудил один забавный случай. Он хорошо демонстрирует, что не стоит слепо доверять одному источнику, каким бы авторитетным он ни был. Впрочем, обо всём по порядку.
Когда только начинаешь карьеру разработчика, часто гложет сомнение: верно ли я выбрал язык программирования? Может, он уже устарел, или наоборот — слишком новый и не факт, что перспективный? Легко ли будет найти по нему актуальные книги и уроки? Много ли таких неофитов будет вместе со мной обивать пороги ИТ-компаний через год-два?
Опытным разработчикам тоже порой не хватает знания единственного языка программирования. В какой-то момент появляются специфические заказы и интересные вакансии, где крайне желательно владеть вторым (а то и третьим) языком.
Помочь с выбором языка программирования призваны рейтинги их популярности. Однако тут легко обмануться. Каждый рейтинг составляется по своей методике и даёт разные результаты (порой — весьма неожиданные). В этой статье я постарался сделать более взвешенную оценку популярности языков программирования (далее — ЯП) по нескольким источникам. Подробнее о них и почему это важно — рассказываю ниже.
Индексы популярности
Всё началось с того, что мне попался на глаза свежий рейтинг актуальности ЯП, где в TOP 10 внезапно ворвался Delphi. Пытаясь разобраться в причинах его внезапной популярности в 2025 году, я стал искать методики составления таких списков и нашёл много любопытного. Как обычно, дьявол кроется в деталях.
Индекс TIOBE — известный инструмент мониторинга, показывающий динамику интереса к разным ЯП. Он учитывает частоту поисковых запросов, связанных с ЯП. Для этого каждый месяц в Google, Bing, Yahoo! и Baidu отправляются запросы по определённому шаблону, чтобы отсеивать из выдачи мусор и корректно сравнивать статистические данные. Дополнительно в рейтинге учитывается число образовательных материалов о ЯП: количество видеоуроков на YouTube, книг на Amazon и упоминаний на Wikipedia.
Современные web-фреймворки для реализации управления состоянием используют библиотеки, такие, например, как Redux для React или Pinia для Vue. У традиционной реализации управления состоянием есть недостатки. Store в таком варианте является частью скрипта страницы, и его данные при её перезагрузке теряются. Кроме того, если нам в приложении нужно организовать управление отображением контента в нескольких окнах браузера, оказывается, что традиционный Store не может этого обеспечить.
Бизнес Dodo Brands — глобальный. У нас уже более 1200 точек в 24 странах мира, и эти числа постоянно растут. А значит каждое наше приложение нужно постоянно адаптировать под новые реалии — обновлять вёрстку, добавлять переводы и изображения.
Однако мы работаем не только с софтом, но и с железом — своим и сторонним. Своё адаптируем по тому же принципу, что и приложения, а стороннее — с помощью плагинной системы, которую можно отдать аутсорс-командам. Но что если вашему железу — киоскам самообслуживания — нужна интеграция со сторонним железом — POS-терминалами?
На первый взгляд, ничего сложного. Мы снова пишем плагиннную систему и снова отдаём работу с ней на аутсорс. Но на деле всё куда сложнее и интереснее. Привет! Меня зовут Никита Васильков. В этой статье я расскажу вам, как подружить фронтенд приложения с POS-терминалами.
Асинхронное управление событиями в Angular-приложениях — одна из основных задач при разработке, особенно если приложение активно взаимодействует с динамическими данными или имеет сложную архитектуру. Зачастую для решения этой задачи разработчики используют подписки и/или промежуточные сервисы. Несмотря на популярность этих подходов, они могут приводить к избыточным зависимостям, высокому уровню связности и сложному коду.
Библиотека @artstesh/postboy предоставляет альтернативный взгляд на эту проблему: она позволяет избавиться промежуточных сервисов и использовать асинхронные события простым и лаконичным способом.
RxJS (Reactive Extensions for JavaScript) — мощный инструмент для работы с асинхронными потоками данных, который используется во многих современных веб-приложениях. Хотя RxJS предоставляет богатую коллекцию операторов, иногда для решения специфических задач бывает необходимо писать свои собственные. Это позволяет избежать дублирования кода и повысить читаемость программы.
Создание своих операторов RxJS может показаться сложным, особенно для тех, кто только начал использовать библиотеку. Однако, фундаментальные принципы их разработки понятны, если погрузиться в механику работы RxJS. В этой статье мы углубимся в то, как создавать собственные pipeable и creation operators, а также рассмотрим практические примеры их применения.
В этой статье я расскажу о настройках TypeScript, определяемых в файле tsconfig.json, которых я использую в своих проектах.
В этой статье описывается в основном настройка проектов, в которых все локальные модули являются ESM. Мы почти не будем говорить об импорте CommonJS.
Также мы не будем говорить о следующем:
composite и др. См.:
Я и сам до конца не знаю, является ли заголовок статьи кликбейтом или нет. Разберёмся в комментариях. Только давайте по-честному! Согласен с тезисами — напиши, что статья огонь, поставь лайк и всё такое. Не согласен — аргументируй, а не просто: «бред»! Есть что добавить (идеи, фишечки) — добро пожаловать в комментарии.
Привет, меня зовут Андрей Шпилевский, и в этой статье я расскажу, почему я делаю тестовое лучше большинства, а также дам советы, как проходить этот этап быстро и максимально эффективно. Тема достаточно большая, поэтому будет разбита на 3 части. Это первая и начну ее я, пожалуй, не с советов: ‘Делай так, спина болеть не будет’, а с лирического вступления, которое, на самом деле, важнее, чем какие-либо пункты.
Если вы разрабатывали приложения на Angular, то наверняка сталкивались с ситуацией, когда множество компонентов требуют тесного взаимодействия друг с другом. Количество @Input, @Output, Services и Subjects растет с каждым коммитом и требует все больших усилий для сохранения качества кода...
В первой части мы познакомились с базовыми понятиями фикстур в Playwright. Мы узнали, что такое фикстуры, для чего они нужны, какие бывают и как создавать собственные. Рассмотрели примеры и сценарии использования фикстур, которые способны упростить процесс тестирования и сделать тесты более чистыми и поддерживаемыми.
Но как быть, когда проект растет и количество фикстур увеличивается? Как эффективно организовать фикстуры в большом проекте? Как управлять дополнительными опциями фикстур и как они влияют на параллельное выполнение тестов? В этой части глубже погрузимся в тему фикстур и рассмотрим все эти вопросы.
Эта статья станет интересной не только специалистам по TypeScript, но и всем разработчикам, ищущим лучшие практики работы с ошибками в современном программировании.
Вы узнаете, почему традиционный подход к работе с ошибками может тормозить разработку и как правильное разделение ожидаемых ошибок и критических дефектов значительно упрощает жизнь.
Я подробно описываю, как моя реализация решает сложности AWS SDK и делает его использование более надежным.
Буду рад узнать ваш подход к работе с ошибками, пишите в комментарии. Спасибо!
Недавно давно я смотрел ничем не примечательный техническое интервью и услышал фразу от интервьюируемого: «Ну можно написать свой useReducer или useState». Мне врезалась эта фраза в голову, ибо я никогда в серьез не задумывался как они работают под капотом и в исходниках особо не копался, максимум в типах. Поэтому я решил их воссоздать с минимальным количеством зависимостей и попытался интегрировать в реакт.
Современный React все больше соответствует идеалам функционального программирования.
Ежедневно мы пользуемся подходами из мира ФП, зачастую даже не подозревая об этом.
Эти паттерны плотно укоренились в сознании фронтенд-разработчиков, делая наш код значительно чище, читаемее и предсказуемее.
В этой статье мы применим один из функциональных паттернов в React приложении и посмотрим что из этого выйдет.
С ростом приложения и увеличением количества зависимостей, мы осознали необходимость в централизованном управлении зависимостями, выходящем за рамки React и MobX. Существующие IoC-контейнеры показались избыточными и тяжеловесными. Поэтому было создано собственное решение. В статье вы узнаете, как мы решили уравнение :-)
Удивился, что про столь популярный продукт не было статьи на Хабре, срочно это исправляю. Drizzle ORM — это #2 самая желаемая ORM по опросам, и она даже вошла в top 50 JavaScript Rising Stars 2024, заняв 27 место.