Всем привет! Эта статья — продолжение материала про универсальный прототип бэкенд-приложений. В ней я поделюсь практическим опытом написания тестов и покажу, как выбранная архитектура упрощает этот процесс.
Привет, Хабр!
«Давайте все будем на ассемблере писать. Зачем мы пользуемся фреймворками?» — эта фраза из недавней дискуссии о low-code платформах прозвучала как манифест. И она заставила задуматься: где граница между разумным использованием абстракций и откровенным vendor lock-in?
Коллеги устроили жёсткий разбор low-code платформ — без маркетингового глянца и дипломатии. Спойлер: никакой «серебряной пули» мы не нашли. Зато выяснилось, что low-code платформы прошлого и нового поколения — это принципиально разные вещи. И что конфликт между разработчиками и визуальным программированием — это на самом деле спор о том, как писать код в 2025 году, когда есть и мощные LLM, и микросервисная архитектура из сотен сервисов.
Почему REST API не всегда подходит для общения микросервисов?
Разбираем на примере интернет-магазина, как Kafka решает проблемы синхронной коммуникации, масштабирования и отказоустойчивости.
Простыми словами о топиках, партициях, consumer groups — для начинающих разработчиков.
Представьте: вы скачали готовый образ с Docker Hub, запустили контейнер, и вдруг ваш сервер становится частью ботнета. Как этого избежать?
Рассказываем 3 простых способа сканирования образов
Trivy — сканер для ленивых (но эффективный)
Привет Хабр!
С развитием нейросетей стала заметна тенденция замены ручного труда человеков на автоматизированную работу ИИ. От программистов, ускоряющих рутинные задачи, до маркетологов, создающих креативный контент — ИИ уверенно встраивается в рабочие процессы. В наше время почти все клики и нажатия на клавиши за тебя может сделать какая-нибудь умная модель, надо просто знать какая.
Я собрал подборку ИИ-сервисов и моделей для решения широкого пула задач. В сегодняшнем выпуске нейросети по направлениям: Код, Презентации, Копирайтинг, Рекламные модели, Созвоны, Видео, Картинки, Автоматизация процессов, Аудио, Дизайн, Соцесети, ИИ детекторы, WEB 3, Блог и пара нейронок для исследовательского интереса.
Uptrace v2.0 использует новый JSON-тип ClickHouse для хранения observability-данных. Результат: запросы по трейсам ускорились в 10 раз.
Делюсь практическим опытом внедрения: установка за 5 минут через Docker, настройка data transformations для обработки данных на лету, гибкие retention policies для экономии на хранении.
В статье:
Пошаговая инструкция от установки до production
Примеры кода на Node.js с OpenTelemetry
Кейсы настройки: снижение cardinality URL, парсинг данных, удаление PII
Чеклист для продакшена
Подходит для микросервисных архитектур на 5+ сервисов, где нужна скорость поиска по атрибутам трейсов.
Я создал этот инструмент, потому что устал от одних и тех же скучных кликов каждую неделю. Мне нужен был инструмент, который: отслеживает папку, извлекает данные из PDF, обогащает их, отправляет отчеты и, в идеале, позволяет выставлять кому-то счет за сэкономленное время. Два выходных, несколько библиотек и пачка кофе – и у меня был продукт, за который люди действительно платили.
Ниже я покажу точный технологический стек, архитектуру, методы монетизации и паттерны кода, которые я использовал. Вас ждет практический код, ООП-структура и один небольшой трюк с C++, когда чистого Python уже не хватало.
1. Выбирайте маленькую, но болезненную задачу
Большинство проектов по автоматизации умирают, потому что пытаются решить слишком много. Вместо этого выберите одну повторяющуюся «боль» с измеримым ROI. Моя проблема была такой:
В этом посте я расскажу, почему для доставки push-уведомлений в клиентское приложение была выбрана технология Server-Sent Events, и главное, как реализовать масштабируемый SSE сервис на Java + Spring Boot + Webflux, который подойдет для использования не только в небольших проектах, но и в крупных организациях с большим количеством пользователей. Естественно, без подготовки дополнительной инфраструктуры не обойдется.
Теория — это прекрасно, но мое "расследование" не могло закончиться на простом понимании проблемы, ведь конечная цель любого инженера — построить работающую и надежную систему. К счастью, проверенные решения существуют.
Эти решения можно разделить на две большие группы: реактивные и превентивные.
Про выделение микросервисов из монолита рассказывали много, но у каждого свой путь – в статье расскажем про наш.
От простейшего выделения сервиса в модуль в начале до решения проблем разрыва транзакций, SQL Join-запросов, задержек асинхронного API и непосредственно выделения нового сервиса. Использование event-driven архитектуры, редизайна модели данных и интеграционного слоя как основных подходов в процессе выделения.
Предыдущая статья: Часть 3: А при чём здесь The Thundering Herd Problem?
Thundering Herd — это о бесполезной трате CPU на пробуждение “лишних” процессов, которые не смогут выполнить работу.
Dogpile Effect — это о бесполезной нагрузке на внешний ресурс (например, БД) из-за многократного выполнения одной и той же работы.
Часть 3: А при чём здесь Thundering Herd?
В конце второй части я оставил вас с интригой: почему мой AI-ассистент решил поправить лектора и предложил термин Thundering Herd (несущееся стадо бизонов)?
Часть 2: В поисках классических проявлений Dogpile Effect.
Мое "расследование" началось с самого очевидного — поиска информации по термину Dogpile Effect. Хотелось найти каноническое определение термина Dogpile Effect.
Этим постом хочу открыть серию постов по материалам курса Архитектор ПО.
Управление репликами - как избежать проблемы Dogpile при горизонтальном масштабировании и что вообще такое Dogpile.
Предупреждение: не сомневаюсь, что наверняка кто-то, прочитав данную статью, возжелает закидать меня тапками, но это его право, я не претендую на истину.
Я начал писать эту статью около двух месяцев назад. Писал по мере возможности и уже почти закончил, как буквально на днях было обсуждение именно этой темы с коллегами. По результатам услышанных там вопросов я добавил еще пару абзацев, чтобы постараться ответить на данные вопросы в комплексе. Эта статья лежала в черновиках с декабря 2021г, я совсем про нее забыл.
В наше время каждый слышал про Web-API и у многих это ассоциируется с REST. Однако этот многострадальный REST всегда какой-то не такой, с ним все время что-то не так.
Разработчики часто спорят и упрекают друг друга, что твой REST недостаточно REST-овый. Это стало чем-то вроде культа или даже религии. Я не планирую рассказывать о том, как правильно готовить REST, но весь материал именно вокруг этого многострадального RESTа.
Один сервер — это точка отказа. Рано или поздно он не выдержит. Как только появляется второй, третий, десятый сервер, возникает вопрос: кто будет раздавать им работу? Эту роль и берет на себя балансировщик нагрузки.
Но это не тупая раздача запросов по очереди. Хороший балансировщик — это мозг. Он должен чувствовать пульс системы: какой сервер отвечает быстро, а какой начал "тормозить". Он должен понимать, что запросы одного пользователя лучше отправлять в одно и то же место. Ошибка в этой логике — и вся система превращается в хаос из ошибок и потерянных сессий.
Я PHP-разработчик с восьмилетним коммерческим опытом. Долгое время я не видел смысла в микросервисах — пока не перешёл на Python и не столкнулся с его архитектурными особенностями.
Привет! Меня зовут Денис, я руковожу группой R&D в Naumen Service Management Platform. В этой статье — разбор виртуальных потоков (VT) в Java: почему исторически обычные потоки упирались в I/O, как и зачем появились виртуальные потоки, что пошло не так в Java 21, что исправили в JDK 24–25, а также когда виртуальные потоки необходимы, а когда — лучше от них отказаться.
Всем привет. Это моя первая статья на Habr. Хочу поделиться с вами своей историей, через что я прошел, чтобы устроиться на свою первую официальную работу программиста на популярном и любимом всеми языке Python. В статье будет приведена вся статистика: названия компаний, предложенные мне зарплаты, количество откликов, количество скринингов, технических собеседований, суммарно потраченное время и, конечно, результаты проделанных трудов. Возможно, вы обнаружите много воды, но по другому статья не будет полноценной.
По тексту есть достаточно много полезных лайфхаков, которые помогли мне на этом пути. Надеюсь, вы подчерпнете что нибудь для себя.
Микросервисная архитектура при построении приложений в последние годы пользуется большой популярностью среди разработчиков. Всевозможные веб-приложения активно используют данную архитектуру. Но почему бы не попробовать использовать эту архитектуру при работе с 1С?
В этой статье мы поговорим о преимуществах и недостатках каждой из архитектур и о том, как можно использовать микросервисы при работе с конфигурациями 1С.
