Разработка большой фичи с нуля часто начинается обманчиво легко. Заказчик объяснил идею, команда обсудила экраны, разработчики примерно представляют архитектуру. Можно приступать. Но стоит перейти от общего замысла к конкретному поведению, как появляются вопросы, на которые у каждого участника свой ответ.
Рубрика «backend»
Большая фича без бесконечных переделок: Spec driven development с AI, UML, C4 и OpenAPI
2026-10-29 в 11:11, admin, рубрики: AI, backend, C4, develop, llm, system design, UMLSenior Java — это кто? Почему одинаковый title ещё не означает одинаковую работу
2026-10-05 в 6:45, admin, рубрики: backend, it-рекрутмент, java, Java Developer, Senior Java, seniority, вакансии, найм в IT, техническое лидерствоФраза нам нужен Senior Java для меня вообще не бриф — это только начало разговора.
Потому что один нанимающий менеджер дальше расскажет про Spring, Kafka, PostgreSQL и обычный продуктовый backend. Другой про highload, JVM и производительность. Третий вроде тоже ищет Senior, но через пять минут выясняется, что человек должен принимать архитектурные решения, менторить команду и местами уже выполнять функции техлида.
Мне стало интересно — это моя профессиональная деформация после лет в IT‑рекрутменте или под одним Senior Java рынок действительно прячет довольно разную работу?
Зачем я добавил Go-сервис туда, где его не просили
2026-09-30 в 13:59, admin, рубрики: 1С, api, backend, Go, yandex 360, архитектура, базы данных, интеграция, микросервисы, очередиНедавно мне дали тестовое задание на проектирование интеграции между 1С и Yandex 360. На первый взгляд задача выглядела достаточно прямолинейно: 1С формирует письмо, дальше его нужно передать в почтовую систему, отправить и получить информацию о результате. Но в исходном ТЗ не было отдельного сервиса на Go. Я добавил его сам. И в этой статье хочу разобрать не столько само тестовое задание, сколько процесс принятия архитектурного решения: зачем вообще добавлять ещё один компонент и в какой момент он действительно оправданЧитать полностью »
Агент пишет быстрее, команда релизит медленнее: 30 дней с coding agent на реальном проекте
2026-09-22 в 6:38, admin, рубрики: backend, coding agents, python, автоматизация разработки, ии-агенты, разработка по, технический долгПервые несколько дней с AI агентом легко создают ощущение, что разработку наконец‑то «сломали». Даёшь задачу, через несколько минут получаешь diff на несколько файлов, тесты и уверенный отчёт о том, что всё готово. Если мерить производительность от момента, когда ты сформулировал prompt, до появления кода, результат действительно впечатляет.
Примерно через неделю я заметил другую вещь: код стал появляться заметно быстрее, а задачи не начали с той же скоростью попадать в production.
Как AI‑ассистент вырос в production‑систему: путь от NLU к оркестрации и надёжной обработке сообщений
2026-09-15 в 11:45, admin, рубрики: backend, fastapi, llm, nlu, python, system design, архитектура по, оркестрацияВ 2025 году Volga AI Assistant начинался как отдельный Telegram‑бот. Пользователь отправлял сообщение, NLU определял намерение, после чего бот возвращал подготовленный ответ.
Архитектура первой версии почти полностью повторяла этот сценарий:
Я думал, что 16 воркеров ускорят обработку задач в 16 раз. Но что‑то пошло не так
2026-08-13 в 14:29, admin, рубрики: backend, celery, docker, optimisation, python, worker, асинхронность, многопоточность, распределенные системы, тестированиеНедавно я написал свою систему распределённой обработки задач. Сначала это был учебный проект. Мне хотелось лучше разобраться в очередях задач, координации воркеров, блокировках строк в PostgreSQL, retry‑механизмах и планировании фоновых задач. Когда основная функциональность была готова, я понял, что не знаю, как система ведёт себя под нагрузкой.
Поэтому вместо того, чтобы добавлять очередную фичу, я решил провести простой эксперимент. Взять одинаковый набор задач и постепенно увеличивать количество воркеров. Первые результаты выглядели именно так, как я ожидал, а потом масштабирование внезапно остановилось.Читать полностью »
Я написал мессенджер в одиночку. Поможете устроить ему краш‑тест?
2026-08-04 в 16:06, admin, рубрики: backend, mvp, mysql, php, polling, архитектура, веб-чат, краш-тест, мессенджер, хабраэффектДисклеймер: Это статья-проверка на прочность. Проект работает на PHP + MySQL + Polling каждые 3 секунды. Если вы кликнули по ссылке, а сервер отдаёт 502 или упорно молчит — значит, поллинг взял своё под нагрузкой Хабра, а я прямо сейчас судорожно оптимизирую запросы и чиню базу!
Привет.
Мониторинг, который не переживёт собственного падения
2026-08-03 в 16:18, admin, рубрики: backend, deploy, devops, monitoringВсем привет! Хотел бы поговорить о мониторинге наших web, да и не только web, приложений, в первую очередь, о проблемах, с которыми мы сталкиваемся. В этой статье я буду использовать язык python и популярные сервисы, чтобы содержимое было максимально понятно большинству.
К примеру, мы написали простой проект, ставить Prometheus с Grafana ради одной машины скорее избыточно, поэтому мы используем что‑то типо этого:
curl -sf https://example.com/ >/dev/null ||
curl -s "https://api.telegram.org/bot$TOKEN/sendMessage"
-d chat_id=$CHAT_ID -d text="Сайт лежит"Как поднять userver без Docker на Ubuntu
2026-07-28 в 14:06, admin, рубрики: backend, c++, cmake, native, ninja, open source, Ubuntu, userver, без DockerDocker для userver удобен, но не обязателен. Ниже — рабочий путь: системные пакеты + CMake/Ninja + сборка сервиса из официального шаблона нативно.
Статья по мотивам реального подъёма сервиса на Ubuntu (без make docker-*).
Зачем без Docker
-
быстрее итерации по коду (нет обёртки контейнера);
-
проще отладка в IDE / sanitizers;
-
понятнее, какие библиотеки реально нужны.
Минус: первая сборка долгая — CMake тянет userver через CPM и компилирует сотни файлов.
Что понадобится
-
Ubuntu (проверялось на свежих релизах; список пакетов близок к Читать полностью »
Биддер «одной цифрой» для Wildberries на Rust: контроллер с мёртвой зоной, лимиты API и выживание под 429
2026-07-27 в 10:12, admin, рубрики: api маркетплейсов, backend, http 429, rate limiting, Rust, token bucket, автоматизация, контроллерПродавцы на маркетплейсах управляют рекламой руками: утром посмотрел ставки, днём подкрутил, вечером обнаружил, что бюджет слит. При этом сама цель продавца формулируется одной цифрой: «хочу, чтобы реклама съедала не больше 12% выручки» (ДРР — доля рекламных расходов) или «каждый рубль рекламы должен приносить три» (ROMI). Кабинет же оперирует только ставками за тысячу показов.