Представьте: вы — инженер-программист из 60-х. Ваш код — это дикие прерии, где goto прыгает через функции как ковбой через барную стойку, а память — ваше личное ранчо. Вас внезапно переносят в 2023 год. Вас окружают фразы вроде «SOLID», «иммутабельность», «реактивные потоки». Вы пытаетесь написать пару строк на Python, но слышите: «Стоп. Мутировать переменные? В 2023-то? Это же грех!».

Что случилось с нашей свободой?

За последние 70 лет программирование из искусства постепенно превращалось в ремесло со своими жёсткими требованиями и правилами. Мы больше не взламываем реальность — мы строим мосты по ГОСТу.

Вы уже встречались с этими "веселыми" историями, когда разработчик заканчивает работу над задачей, она проходит тестирование, отправляется в прод, а там встречается неожиданным отказом какого-нибудь мелкого метода api и укладывает всё приложение так, что пользователи наблюдают только белый экран?

Я в своё время познакомился с ними чересчур близко... И, честно сказать, потоки RxJs прекрасные учителя - тебе не захочется снова повторять их уроки. Чему же они нас учат? В первую очередь тому, что не стоит доверять внешним источникам; вы не контролируете ни соединение с сервером, ни api-сервис, а значит не имеете никаких оснований слепо доверять им и ожидать безотказной работы.

Введение: Архитектурное дежавю

Вы когда-нибудь замечали, как цифровой мир движется по спирали? В 2018 году я, размахивая Dockerfile и Helm-чартами, внедрял микросервисы на C# с RabbitMQ — всё ради священной цели «низкой связанности». А через три года, переключившись на Angular, с ужасом осознал: фронтенд-компоненты общались через цепочки Input/Output, словно это 2005-й, а мы пишем WinForms.

Это как собрать космический корабль, но управлять им через телеграф. На бэкенде мы гордо декларируем event-driven architecture, а на фронтенде компоненты перешёптываются через пропсы, будто подростки на школьной дискотеке. Ирония? Чем сложнее становились наши системы, тем больше они напоминали те самые монолиты, от которых мы бежали в мире backend.

На протяжении первой, второй и третьей статей мы прошли вместе довольно увлекательный путь: от первого знакомства с Observables, где разобрались с основами реактивного подхода, через освоение операторов, которые позволили нам эффективно преобразовывать и фильтровать данные, до комбинирования потоков, открывшего возможности для синхронизации данных из нескольких источников. Мы постепенно превращали RxJS из интересного инструмента для экспериментов в мощный инструмент для реальных задач.

Теперь, сделав три уверенных шага, пришло время взглянуть на тёмную сторону реактивного программирования. Как и у любой технологии, у RxJS есть свои подводные камни. Один из самых коварных — это незакрытые подписки, которые могут привести к серьёзным проблемам, таким как утечки памяти, деградация производительности и даже краши приложения. Реальная мощь инструментов RxJS требует от разработчиков не только технических знаний, но и настоящего профессионального мастерства, чтобы создавать надёжные и быстрые приложения.

Если первые три шага были о создании и трансформации потоков, то четвёртый шаг — это о том, как брать ответственность за созданное. Это шаг к зрелости в работе с RxJS — понимание того, почему управление подписками важно и как оно влияет на качество ваших приложений.

Присоединяйтесь, чтобы шагнуть дальше в мир RxJS, избежать распространённых ошибок и стать разработчиком, который не только умеет создавать интересный код, но и делает его надёжным, оптимизированным и удобным для любых условий эксплуатации.

Dependency Injection (или DI) — концепция, которая настолько естественно вплелась в повседневную практику программирования, что, кажется, её игнорирование можно смело записать в список смертных грехов наравне с отсутствием контроля версии. Но почему же DI стал столь важным?

DI — это один из ключевых принципов, позволяющих создавать гибкие и сопровождаемые приложения. Философия подхода заключается в том, чтобы избавить код от ненужных деталей, которые связывают логические компоненты приложения слишком плотно. Компоненты перестают быть зависимыми от конкретных реализаций других частей системы — они лишь говорят, что им требуется, а DI предоставляет необходимые зависимости.

Теперь о цели: DI — это вовсе не про навык освоения модной технологии, а про универсальный архитектурный инструмент, понятие которого пересекается в совершенно разных экосистемах. Изучение DI в нескольких языках и средах помогает не просто улучшить понимание самой концепции, но и значительно расширяет взгляд на проектирование систем, приходит понимание, что, несмотря на разницу в синтаксисе, фундаментальные идеи стремятся к одним и тем же архитектурным целям.

Кому будет полезна эта статья? Если вы давно уже подружились с .NET с его IServiceCollection, но всегда хотели разобраться, что из себя представляют Angular Injectors, — добро пожаловать. И наоборот, если вы пишете код в TypeScript, но слово "Transient" у вас вызывает только вопросы, — прошу к прочтению. Мы разберемся, как похожие концепции адаптируются в двух разных мирах и почему их изучение в обеих экосистемах позволит вам лучше проектировать свои приложения.

Когда вы в последний раз чувствовали себя настоящим экспертом в разработке? Лично я — где-то в тот момент, когда впервые написал программу, которая завершилась без ошибок. Программирование — это как бесконечный ремонт дома, в котором ты уже живёшь. Ещё вчера тебе казалось, что новая крыша будет решением всех проблем. А сегодня оказалось, что появились окна с автоподогревом, и без них дом вообще не дом. И, конечно, все соседи уже поставили такие.

RxJS — штука мощная, но одновременно и коварная. Многие новички, освоив такие базовые операторы, как map, filter и, возможно, даже take, начинают чувствовать себя уверенно. Но в какой-то момент они сталкиваются с задачами, где нужно сочетать несколько потоков одновременно… и всё! Паника. Что выбирать: combineLatest, forkJoin, merge, zip? А что делать, если данные приходят с разной скоростью? Этот материал для тех, кто запутался на этом этапе. Давайте попробуем спокойно и пошагово разобраться.

Приветствую,
сегодня я решил поговорить о том, как автоматическая генерация моделей и сервисов на фронтенде может упростить процесс разработки.

Проблема взаимодействия между фронтом и бэкендом — одна из самых больших головных болей разработчиков. Разрыв в форматах данных, устаревшая документация и ошибки на этапе интеграции неизбежно замедляют процесс разработки. Однако современные подходы позволяют минимизировать эти сложности.

Одной из технологий, которая хорошо зарекомендовала себя для таких задач, является автоматическая генерация кода из OpenAPI-спецификаций.

Любой программист, вне зависимости от уровня, когда‑то сталкивался с этим. Ты садишься за проект, полный планов и идей, предвкушаешь, как создашь нечто совершенное, но... проходит час, второй, а на экране только десяток папок, пара заглушек и файл README.md. И вот уже начинаешь возвращаться к документации в поисках «правильной» структуры проекта или подсматриваешь, как сделали другие.

Примерно то же самое происходит, когда ты работаешь в команде: собрания перетекают в бесконечное обсуждение архитектуры, абстракций и фреймворков. Идеи летят кометами, все соглашаются, что «всё должно быть как надо», но реальная работа — застопорилась. Потому что команда вместе с тобой подсознательно ждет чего‑то: идеального старта.

Синдром идеального старта — не просто миф, а настоящая преграда для продуктивной разработки. В этой статье мы поговорим о том, почему ждать «идеальности» — значит тормозить, как такой подход мешает развитию, и что с этим можно сделать.

Зачем мы ждём идеального старта?

Давайте начистоту. Инженерный подход прививает большинству программистов стремление к «чистоте» и «вечному». Важно, чтобы проект был построен на устойчивом фундаменте, который можно будет развивать много лет. Но эта стремительность к «безупречности» часто оборачивается довольно токсичной привычкой откладывать реальные действия, пока не будет найдено «идеальное решение».

Проблема в том, что идеальное, как правило, недостижимо. Вот почему:

Добро пожаловать во вторую статью на тему RxJS! Если вы прочли первую часть, то, скорее всего, уже экспериментировали с from(), interval() и знакомились с элементарными операциями — фильтрацией и преобразованием данных. На этом фундаменте мы будем строить знакомство с более хитрыми инструментами, чтобы из просто «интересных экспериментов» RxJS превратился в реальный мощный инструмент для ваших проектов.

Обращаю Ваше внимание на то, что данный опус, как и прочие в этом цикле рассчитаны исключительно на новичков, никаких открытий, прорывов и "умных" мыслей для преисполнившихся здесь не предполагается. Все повествование строится на моём понимании того, как лучше построить процесс изучения обозначенной темы.

Каждый Angular-разработчик хотя бы раз задумывался: "Почему я пишу так много однотипного кода?". Инъекция зависимостей, повторяющиеся методы логирования, одинаковая обработка событий — всё это напоминает вечную гонку с шаблонным кодом (boilerplate). Однако в арсенале Angular есть мощное средство для упрощения задач и автоматизации повторяющихся действий — TypeScript-декораторы. Декораторы — это быстрый способ добавить унифицированную функциональность к кодовой базе, сделав её чище, понятнее и поддерживаемой. В этой статье мы разберём, как с помощью декораторов избавляться от однообразных повторов, одновременно привнося гибкость и снижение количества ошибок.

Приветствую! Продолжаем разбирать возможности @artstesh/postboy и обсуждать, как сделать ваше приложение проще, а код элегантнее. Сегодня поговорим о том, что такое асинхронные команды и запросы, почему этот механизм так удобен, и как использовать его в реальных приложениях. Как всегда, всё покажу на живых примерах, чтобы можно было сразу применить на практике.

Проблема многих новичков, впервые сталкивающихся с темой подписок, заключается в обилии тем и нюансов, связанных с этим направлением. Тонны статей, дискуссий, документаций на темы, аля «RxJS mergeMap vs switchMap vs concatMap vs exhaustMap» могут вызвать головную боль уже в первые пятнадцать минут. Потому первый мой совет: ограничьте список тем и осваиваемых инструментов до самого минимума, декомпозиция важна везде и всегда — слона надо есть по частям. Так начинающий учиться шахматам сначала разбирает каждую фигуру в отдельности, запоминает возможности и нюансы, постепенно переходя к глобальной стратегии игры. Поэтому давайте смахнем все фигуры с доски и оставим там только пешку.

Тестирование — неотъемлемая часть разработки, особенно если речь идёт о сложных приложениях. Оно позволяет нам быть уверенными в качестве кода и предотвращать неожиданные ошибки. Но важный вопрос, который рано или поздно возникает у каждого разработчика: как балансировать между качественным покрытием тестами и затратами на их написание? И, что ещё более важно, как справляться с рутиной при этом?

Работа с тестовыми данными — проблема, способная выжать все силы у даже самых терпеливых разработчиков. Простые тесты с примитивными параметрами пишутся быстро и легко. Но когда ваш метод оперирует сложными объектами с вложенными структурами, ситуация усложняется многократно. С каждым новым тестом всё больше времени уходит на составление данных, разрушая читаемость и увеличивая объём работы.

Эта история — не про рекламу библиотек или продвижение инструментов. Это мой личный опыт борьбы с типовыми проблемами генерации данных в тестах TypeScript. Я решил поделиться тем, с какими сложностями я столкнулся, как привычные подходы из других языков не сработали и к каким решениям в итоге удалось прийти и, возможно, найти новый взгляд на проблему от сообщества.

RxJS — один из самых мощных инструментов в экосистеме Angular, который позволяет работать с асинхронными потоками данных с элегантностью и гибкостью. Однако за этой мощью скрывается коварная проблема: при неправильном управлении потоками ваши приложения смогут утонуть в утечках памяти. Это — потенциально незаметный убийца производительности. В этой статье я, постараюсь поделиться практиками управления потоками RxJS и посоветую, как избежать утечек памяти.

Всем нам, разработчикам, приходится сталкиваться с задачей создания тестовых данных. Это могут быть как простые объекты (например, пользователь с именем, email и ролями), так и сложные вложенные структуры: API-ответы, модели базы данных и так далее. Это особенно актуально при написании unit-тестов, когда нам нужны разнообразные данные для проверки разных сценариев.

И вот тут становится понятно, сколько времени мы тратим на эту рутину. Либо вручную создаем объекты, либо используем более простые инструменты, которые не всегда подходят для сложных проектов. Так появился инструмент — библиотека @artstesh/forger, созданная специально для таких задач, чтобы в разы сократить наше время и упростить процесс разработки. Давайте разберем, как она работает и почему это будет полезно.

Angular предоставляет мощный механизм Dependency Injection (DI), который делает приложения модульными и тестируемыми. В этой статье мы рассмотрим базовые механизмы работы DI-контейнера Angular, разберем иерархию инжекторов, ключевые роли @Injectable и @Optional, а также рассмотрим создание кастомных провайдеров и их применение в сложных проектах.

Асинхронное управление событиями в Angular-приложениях — одна из основных задач при разработке, особенно если приложение активно взаимодействует с динамическими данными или имеет сложную архитектуру. Зачастую для решения этой задачи разработчики используют подписки и/или промежуточные сервисы. Несмотря на популярность этих подходов, они могут приводить к избыточным зависимостям, высокому уровню связности и сложному коду.

Библиотека @artstesh/postboy предоставляет альтернативный взгляд на эту проблему: она позволяет избавиться промежуточных сервисов и использовать асинхронные события простым и лаконичным способом.

RxJS (Reactive Extensions for JavaScript) — мощный инструмент для работы с асинхронными потоками данных, который используется во многих современных веб-приложениях. Хотя RxJS предоставляет богатую коллекцию операторов, иногда для решения специфических задач бывает необходимо писать свои собственные. Это позволяет избежать дублирования кода и повысить читаемость программы.

Создание своих операторов RxJS может показаться сложным, особенно для тех, кто только начал использовать библиотеку. Однако, фундаментальные принципы их разработки понятны, если погрузиться в механику работы RxJS. В этой статье мы углубимся в то, как создавать собственные pipeable и creation operators, а также рассмотрим практические примеры их применения.

Если вы разрабатывали приложения на Angular, то наверняка сталкивались с ситуацией, когда множество компонентов требуют тесного взаимодействия друг с другом. Количество @Input, @Output, Services и Subjects растет с каждым коммитом и требует все больших усилий для сохранения качества кода...