Выпадающий список — это ui-компонент, без которого редко обходится сайт. В этой статье я расскажу про то, как принял решение отказаться от enum для рендеринга выпадающих списков и перешел к конфигу-константе, и почему результат мне понравился.
⚡ Архитектура монорепозитория для параллельного исполнения торговых стратегий
Статья описывает архитектуру эмулятора биржи. Эмулятор ускоряет время в 6300x раз и запускает такую же торговую стратегию как в prod без изменений. В статье описаны практики структурирования кодовой базы для командной работы
B-Tree O(log n) , memcache lookupO(1), монорепозиторий, SRP, линейное расширение кодовой базы при модернизации
Привет, Хабр! Меня зовут Кирилл, я партнер брендингового агентства «Бунов+Устинов». Пока индустрия спорит, заменит ли ИИ кожаных мешков, мы с архитектором проекта Сергеем Либединским решили проверить это на самой «душной», долгой и дорогой части нейминга - юридическом скрининге товарных знаков.
Это история о том, как превратить галлюцинирующую LLM в строгий экспертный инструмент, пережить «догфудинг» собственной нейронкой и получить награду «ОСНОВА-2026» за автоматизацию процессов в брендинге.
Устройства дополненной реальности — это устройства, которые обеспечивают интерактивное взаимодействие с реальным миром, интегрируя цифровой визуальный контент и аудио в окружающую среду. К устройствам дополненной реальности относятся проекционные дисплеи, голографические дисплеи, смарт-очки и другие.
Основными типами устройств дополненной реальности являются дисплеи, надеваемые на голову (head-mounted display, HMD), и проекционные дисплеи (head-up display, HUD). Устройства дополненной реальности используются в самых разных отраслях, в том числе в потребительской, коммерческой, корпоративной, здравоохранении, аэрокосмической и оборонной промышленности, энергетике и автомобилестроении. Популярные англоязычные аббревиатуры (VR, AR, MR) — это соответственно виртуальная, дополненная, смешанная реальность.
Посмотрим, что происходит в этой сфере в России и мире с точки зрения патентов.
На текущем месте работы я иногда вижу запросы на систему распределения затрат по определенным правилам, которые должны гибко изменяться без необходимости пересборки всего приложения.
Исходя из текстов запросов, создается впечатление, что многие считают эту задачу сложной и требующей создания специфических, заточенных именно под данную задачу решений.
Однако, исходя из того, что я знаю про Apache Spark, с его помощью и используя расширение по работе с графами, это не выглядит сложной задачей.
Я решил это проверить.
В данной статье будет описана задача и выбранные технологии.
Во второй части будет описана база данных для хранения правил и результатов.
В третьей части будет создано решение на базе Apache Spark и его функций по работе с графами.
Бонусом получится сравнить скорость выборки результирующих данных из Postgres с помощью рекурсивных запросов и запросов к Apache Spark с помощью GraphFrame.
Рано или поздно сложную систему приходится объяснять человеку со стороны: новому разработчику, техлиду, архитектору или ревьюеру. И тут часто начинается боль: репозитории уже показали, основные сущности вроде бы объяснили, но всё ещё непонятно, как данные проходят через систему.
В этой части цикла я показываю, как выбрать один главный поток, проследить конкретную сущность от source до consumer и заранее привязать дебаг к слоям данных.
Внутри 4 практичных артефакта: чек-лист выбора flow, карточка сущности, таблица изменения формы данных и чек-лист точек поломки. А чтобы схема осталась в памяти надолго, я обернула её в кальмара с полипом на лице.
Привет! Я Иван Воробьев, системный аналитик Далее. Часто нам приходится работать со сложными системами не только с нуля, но и на саппорте. И для аналитика это кардинально разные контексты, риски и косты ошибок.
На поддержке каждый error стоит сильно дороже, а допустить его в разы проще. В этой статье расскажу, что точно повредит ваш прод при доработках и как этого избежать.
Когда локальный стейт в React-модуле начинает расти - разработчик инстинктивно тянется к useReducer+Context. Это работает, пока не перестаёт: ререндеры везде, провайдеры в елочку, логика размазана. В статье разбираю как этот путь выглядит в реальном продакшне на примере редактора субтитров, и почему паттерн Scoped Store на базе Context+Zustand+useRef решает эту проблему чище и проще.
У вас небольшой релиз. Вы меняете пару строк кода, выкатываете обновление - и через несколько минут сервис начинает отдавать странные ошибки. Баги появляются в местах, которые вы вообще не трогали.
Знакомо?
Обычно проблема не в конкретном изменении, а в архитектурной связанности системы: инфраструктурные детали начинают протекать в бизнес-логику, и зависимости между компонентами становятся слишком плотными.
Разберём это на примерах. Примеры будут псевдореальные, иначе статья быстро превратится в книгу.
Посмотрите на функцию загрузки инвойса:
Семь месяцев назад я опубликовал на Хабре статью про ментальные ограничения в управлении продуктом. Перечитал ее, остался недоволен. Слишком плоско. Слишком абстрактно. Главного я тогда не сформулировал.
Меня зовут Александр Козуб и я уже двадцать лет в финтехе, последние несколько из них в качестве CPO. Специализируюсь на ситуациях, когда очевидные рычаги роста уже не работают, и нужны системные решения, а не новые фичи. В симптомах вижу систему, об этом и пишу
Эта статья представляет вторую попытку, и в ней я попробую разложить то, чего в первой не было: механизм. То, как именно добросовестная продуктовая работа методично сужает рамку возможного у тех, кто ее делает.
Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает.
Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров. Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами.
Фича для эксперимента была такой: если выбранный фрилансер отказался от оффера, платформа должна автоматически найти следующего подходящего кандидата, отправить ему новый оффер и уведомить заказчика о переназначении.
Claude написал спеку, реализацию и юнит-тесты, но полный сценарий отказа и переназначения не сошёлся. Два независимых ревью нашли одну и ту же группу ошибок: по отдельности сервисы выглядели нормально, а вместе работали не так, как нужно.
На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается.
Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними.
В итоге спека получается подробной, но неполной: в ней есть локальные изменения по сервисам, зато нет системных инвариантов, которые живут между сервисами. Реализация может быть нормально разложена по слоям, тесты отдельных компонентов проходят, а ошибка обнаруживается уже на уровне сценария или ревью.
Navisworks хорошо находит BIM‑коллизии, а Revit — инструмент для исправления. Но между ними часто остаётся хаос: XML и HTML‑отчёты, Excel, переписки, ручной поиск ID и вопросы руководителей в стиле «ну как там с коллизиями?».
Я расскажу, как из этой боли вырос внутренний web‑сервис Clash Analytics: импорт XML‑отчётов Navisworks, аналитика по проектам, история коллизий, статусы, комментарии, назначение отделам и локальный Revit Bridge, который открывает проблемное место в модели за один клик.
У нас было 2 телефонии от разных вендоров, одна речевая аналитика и 300 тысяч звонков в месяц. И задача: сделать сквозную аналитику по звонкам сотрудников.
Привет! Я Никита, инженер системного проектирования в компании Передовые Платежные Решения. Расскажу, как мы использовали единый идентификатор через службу каталогов Active Directory (AD), и стали точно определять, кому из сотрудников принадлежит звонок. Независимо от того, из какой телефонии он исходит.
Наш опыт может быть полезен архитекторам, инженерам и техническим лидерам команд, которым предстоит интеграция разнородных систем телефонии.
Дебаты, касающиеся программирования с применением агентов, в основном касаются подбора инструментария: какую IDE, какую модель, какой CLI использовать и т.д. Гораздо меньше внимания уделяется более интересному вопросу: а сохраняет ли в таких условиях актуальность сам подход к структурированию кода, которому нас учили, если у той штуки, которая теперь пишет код, ограничена долговременная память, а также ограничено контекстное окно? Более того, агент зачастую должен добиваться прогресса по задаче, не имея «перед глазами» всей системы.
Ниже проанализированы различные архитектуры кода: TDD (разработка через тестирование), OOP (объектно-ориентированное программирование, ООП), FP (функциональное программирование, ФП), MVC (модель-представление-контроллер), MVVM (модель-представление-модель представления), микросервисы, событийно-ориентированная архитектура, CQRS (раздельная обработка команд и запросов), гексагональная архитектура, разработка через поведение (BDD), предметно-ориентированное проектирование (DDD). Они отсортированы по показателю прикладной полезности в условиях, когда программирует не человек, а агент.
История о том, как боль с потерянными компонентами и слетевшими токенами в Figma превратилась в собственный плагин для аудита дизайн-системы.
Как только AI‑агенты начинают участвовать в разработке, быстро выясняется неприятная вещь: проблема не в генерации кода, а в управлении смыслом изменений.
В статье рассказываю, как я перестроил процесс проектирования фич через связку:
— чата с агентом бизнес‑аналитиком;
— графовой модели изменений;
— MCP‑доступа к модели;
— агентского бутстрапа;
— формализованного техпроцесса.
На примере разработки агентской памяти показываю, как User Story превращается в граф ролей, целей, мотивов, API и зависимостей, а агент перестаёт быть «чатиком сбоку» и становится участником инженерного процесса.
Это не история про «ИИ пишет код».
Это история про то, как инженерное знание начинает работать как код.
Привет всем, на связи снова Дарья Борисова, системный аналитик из ПСБ. Продолжаю развеивать мифы о REST API. Если вы пропустили первую и вторую часть, то советую заглянуть туда: ведь мы уже разобрали некоторые заблуждения о природе REST. Сегодня мы разберем нюансы транспортных и бизнес-ошибок, погрузимся в кеширование и узнаем, действительно ли REST должен быть прокси для базы данных.
Переходите под кат, начинаем!
Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья — продолжение предыдущей: Мой справочник по Feature-Sliced Design. На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD — архитектурной методологии для проектирования фронтенд-приложений.
В конце статьи есть ссылки на другие подходы к организации файловой структуры фронтенд-приложений.
Air Canada проиграла суд за слова чат-бота. Дилер Chevrolet «продал» Tahoe за доллар. Корень один: LLM одновременно решает что сказать и как. Под давлением точность проигрывает беглости. Разбор паттерна, который это чинит.
Современная разработка программного обеспечения по‑прежнему сталкивается с устойчивым разрывом между тем, как человек описывает намерение системы, и тем, как это намерение затем становится машинно‑исполняемой логикой. Требования, проектные решения, ограничения, бизнес‑правила и примеры ожидаемого поведения чаще всего существуют отдельно от исходного кода. Даже при достаточно дисциплинированном процессе разработки документация со временем может терять связь с реализацией, тогда как код остаётся исполняемым, но не всегда выражает предметный смысл системы в явном и проверяемом виде.
Классическим ответом на эту проблему стали формальные методы и формальные языки спецификаций. Они позволяют описывать систему строго, проверяемо и пригодно для анализа. Однако такая строгость требует от разработчика специальной подготовки и готовности работать в заранее заданной формальной системе. В повседневной инженерной практике значительная часть знания о системе сначала фиксируется не в коде, а в текстовых требованиях, заметках, таблицах, примерах, обсуждениях и проектных пояснениях. Перевод этого материала в формальный язык требует отдельного усилия и потому далеко не всегда становится частью реального рабочего процесса.
Другой ответ связан с развитием больших языковых моделей. Они сделали практически значимым сценарий, при котором код может быть получен непосредственно из естественно‑языкового описания. Такой подход полезен как средство поддержки разработчика, ускорения прототипирования и получения черновых реализаций. Однако в роли компилятора он остаётся проблемным. Вероятностная модель может дать работоспособный фрагмент кода, но такой результат трудно рассматривать как воспроизводимый, проверяемый и объяснимый переход от спецификации к реализации.
