Бэкенд

Привет, это снова Егор Гаврилов. Сегодня я расскажу, что было сделано за последний месяц в рамках очередного своего пет-проекта - StingrayTV Alice.

Предыдущая статья была вынесена в черновики мной, однако если вкратце, StingrayTV Alice - это попытка интегрировать ресиверы Триколора на базе платформы StingrayTV с сервисом "Дом с Алисой". Это позволяет управлять ресивером через Алису, и интегрировать его в общий умный дом. Проект пережил несколько доработок, и сейчас там используется Keycloak, Spring Boot 4, и другие самые современные технологии. Также было сделано множество улучшений кодовой базы, что позволило избавиться от лишнего кода, и улучшить стабильность и производительность данного гейтвея.

Keycloak: теперь нормальная аутентификация - это реальность

Изначально планировалась аутентификация по физическому присутствию пользователя за консолью сервера. Однако реализовать это достаточно было нетривиально, и поэтому принято решение использовать уже готовый сервер аутентификации - а именно Keycloak. Оно даёт более гибкий контроль за процессом аутентификации, а также является проверенным и готовым решением для реализации OAuth2.

Куча рефакторинга

Проект подвергся обширному рефакторингу - как те, которые я сделал на всех своих пет-проектах (в частности, перевод проектов на Spring Boot 4, а также улучшения по части CI/CD в проектах - теперь там реализован полноценный пайплайн, который обеспечивает высокий уровень консистентности всего цикла), так и постепенная работа над чисткой кода (при помощи самых разных линтинг-инструментов - начиная от встроенных инструментов OpenIDE, и заканчивая SonarQube for IDE и Explyt Spring). Это позволило обеспечить гораздо большую чистоту и сопровождаемость кода.

В частности:

1. Избавились от кривого механизма аутентификации - теперь там самый что ни на есть цивильный Keycloak.

2. Убрали использование Preferences API для хранения нужных ключей для старого механизма аутентификации - Keycloak куда лучше во всём.

3. Мелкие улучшения в кодовой базе - меньше ужаса и треша, больше чистого кода.

Итоги

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

Мой сайт-резюме
Мой GitHub

Привет, Хабр! Тем, кому регулярно приходится заглядывать в etcd — будь то QA, поддержка или разработчики — хорошо знакома ситуация, когда нужно разобраться с неожиданным состоянием сервиса, проверить конфиги или найти застрявший лок. И каждый раз всё сводится к одному: копировать ключ, запускать etcdctl get, читать многострочный JSON в терминале, ошибаться в пути… и в какой-то момент понимаешь, что это однообразие выматывает больше, чем сама проблема.

Поэтому наш коллега из Хайстекс сделал небольшой TUI-инструмент, который заметно упрощает работу с etcd и делает её куда дружелюбнее для тех, кто каждый день копается в окружениях. Он снимает рутину etcdctl, даёт привычную “каталожную” навигацию, подсвечивает скрытые _-ключи, позволяет комфортно открывать большие конфиги и помогает разбираться с локами, которые любят появляться в самых неожиданных местах.

Если вы в QA, поддержке или просто часто работаете с etcd, этот инструмент легко сэкономит вам время и нервы.

Статью можно прочитать здесь.

📊 Multi‑LLM Orchestrator v0.6.0: метрики провайдеров и умный роутинг

На этой неделе на Хабре вышла статья про Multi-LLM Orchestrator — библиотеку для работы с российскими LLM через единый интерфейс. Сегодня релиз v0.6.0 добавляет метрики провайдеров и стратегию роутинга на основе health status.

Автоматический сбор метрик

Роутер отслеживает каждый запрос и собирает статистику по провайдерам. Latency, success rate, количество ошибок — всё фиксируется без дополнительной настройки.

from orchestrator import Router
from orchestrator.providers import GigaChatProvider, ProviderConfig

router = Router(strategy="best-available")
router.add_provider(GigaChatProvider(
    ProviderConfig(name="gigachat", api_key="...", model="GigaChat")
))

# После нескольких запросов
metrics = router.get_metrics()
print(f"{metrics['gigachat'].avg_latency_ms:.0f}ms")
print(f"Health: {metrics['gigachat'].health_status}")

Система отслеживает среднюю задержку и rolling average по последним 100 запросам. Если провайдер начинает деградировать, это видно сразу.

Health status провайдеров

Роутер классифицирует каждого провайдера автоматически:

• healthy — error rate меньше 30%, стабильная latency

• degraded — error rate 30-60% или задержки растут

• unhealthy — error rate выше 60%

Классификация происходит на лету, без пороговых значений в конфигах.

Стратегия best-available

Новая стратегия роутинга выбирает провайдера на основе метрик. Приоритет отдаётся healthy-провайдерам, среди них — с минимальной задержкой.

router = Router(strategy="best-available")
router.add_provider(gigachat_provider)
router.add_provider(yandexgpt_provider)

# Роутер выбирает самого здорового и быстрого
response = await router.route("Вопрос")

Если GigaChat деградирует до 3 секунд, а YandexGPT стабильно отвечает за 500ms — роутер переключится на YandexGPT.

Тестирование на боевых API

Запущена серия тестов с реальными запросами к GigaChat и YandexGPT. Результаты подтверждают стабильность системы метрик.

YandexGPT показал стабильные 500-700ms на серии из шести запросов. GigaChat медленнее (~1.7s), но это ожидаемо для более тяжёлой модели. Success rate обоих провайдеров — 100%.

Structured logging

Каждый запрос логируется в структурированном формате с полями provider, model, latency_ms, streaming, success. Интеграция с Prometheus или Grafana требует только парсинг JSON

# При успехе
logger.info("llm_request_completed", extra={
    "provider": "gigachat",
    "latency_ms": 1723
})

# При ошибке
logger.warning("llm_request_failed", extra={
    "provider": "yandexgpt",
    "error_type": "RateLimitError"
})

Ссылки

• GitHub: MikhailMalorod/Multi-LLM-Orchestrator

• PyPI: multi-llm-orchestrator

• Статья про v0.5.0: Укрощаем зоопарк API российских LLM

• Release Notes: v0.6.0 на GitHub

Следующий релиз (v0.7.0) добавит token-aware метрики: подсчёт токенов, расчёт tokens/s, cost estimation и экспорт в Prometheus.

Если используете российские LLM в production — буду рад обратной связи в комментариях.

Запуски 2025: программирование

В 2025 году мы запустили 25+ курсов и тарифов для ИТ-специалистов. В этой подборке собрали новые программы по разработке и архитектуре.

«Rust для действующих разработчиков» — 4 месяца
После курса сможете использовать Rust как основной стек и создавать отказоустойчивые системы с высоким уровнем безопасности.

«SRE — обеспечение надёжности систем» — 4 месяца
Освоите практики и подходы SRE, наладите мониторинг инфраструктуры и приложений, чтобы повышать стабильность и улучшать бизнес-процессы.

«DevSecOps: безопасная разработка и эксплуатация» — 3 месяца
Разберём, как выявлять и устранять уязвимости на ранних этапах и снижать риски на всём жизненном цикле приложения — от планирования до эксплуатации.

«MLOps для разработки и мониторинга» — 5 месяцев
Освоите принципы MLOps, чтобы ускорять и безопасно выводить ML-модели в продакшн, настраивать стабильную инфраструктуру и улучшать взаимодействие команд.

«Микросервисная архитектура» — 3 месяца
Научитесь проектировать и реализовывать масштабируемые и отказоустойчивые микросервисные системы. Разберёте паттерны SAGA и Transactional Outbox, подход DDD и другие инструменты.

«Мидл разработчик C++» — 4,5 месяца
Прокачаете владение современным C++: лучшие практики и идиомы языка, работа с диапазонами, библиотечными возможностями, асинхронностью и многопоточностью.

«Продвинутая разработка на C# и .NET» — 5 месяцев
Научитесь писать безопасный высокопроизводительный код, разбирать сложные продакшн-задачи, внедрять observability (логи, метрики, трейсы) и использовать современные возможности .NET.

Проверяем osu! и рассказываем про фишки статических анализаторов

Про существование инструментов статического анализа известно многим, но почему их часто используют и в чём конкретно заключается практическая польза? В этот раз мы предлагаем рассмотреть несколько основных особенностей этого инструмента на примере анализа исходного кода игры osu!

Первая особенность: экономит время

Одной из особенностей статических анализаторов является возможность сэкономить время на код-ревью за счёт схожего подхода (просмотра исходников), только за вас всё делает инструмент :)

Предлагаю начать с небольшой разминки: сможете ли вы самостоятельно найти ошибку?

public partial class TopScoreStatisticsSection
  : CompositeDrawable
{ 
  public ScoreInfo Score
  {
    ....

    if (score == null && value == null) 
      return;

    if (score?.Equals(value) == true)
      return;

    score = value;

    accuracyColumn.Text = value.DisplayAccuracy;

    maxComboColumn.Text = value.MaxCombo
                               .ToLocalisableString(@"0\x");

    ppColumn.Alpha = value.BeatmapInfo!
                          .Status
                          .GrantsPerformancePoints() ? 1 : 0;

   
  }
}

Если нужна подсказка или хотите убедиться в своём варианте, можно посмотреть на предупреждение PVS-Studio:

V3125 [SEC-NULL] The 'value' object was used after it was verified against null. Check lines: 128, 120. TopScoreStatisticsSection.cs 128

Нашли? Ну я в вас и не сомневался :)

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

В начале есть две проверки.

Первая проверка:

if (score == null && value == null)
  return;

Вторая проверка:

if (score?.Equals(value) == true)
  return;

Скорее всего, они предназначались для обработки двух переменных по разным сценариям (если score = null, если value = null, если они равны и т. д.). Но вот если комбинация будет score = "NotNull" и value = null, то первая и вторая проверки отработают без выхода из метода, и мы пойдём дальше по коду, где непременно наткнёмся на разыменовывание свежеполученного null

accuracyColumn.Text = value.DisplayAccuracy;
maxComboColumn.Text = value.MaxCombo.ToLocalisableString(@"0\x");

А это, в свою очередь, может привести к исключению NullReferenceException.

Хотите узнать еще?
Если вас заинтересовало какие еще есть особенности статических анализаторов и что еще мы смогли найти в osu! То предлагаю прочитать полную версию статьи.

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

1. Давать осмысленные имена сразу же

Хорошие названия переменных, функций и классов экономят время всей команде: код проще читать, легче понимать и поддерживать. А еще чем меньше вопросов «что делает эта функция?» или «что содержит переменная?», тем лучше.

2. Декомпозировать код и избегать вложенности

if внутри if или for внутри for путают: каждое разветвление создает еще одну ветку, которую приходится держать в голове. Лучше разбить логику на небольшие части — код становится прозрачнее и надежнее.

как не надо:

функция заказать_пиццу(адрес):
  если адрес_валиден(адрес):
    если у_ресторана_ингредиенты():
      если клиент_может_платить():
        печать "Пицца заказана!"
      иначе:
        печать "Недостаточно денег"
    иначе:
      печать "Нет ингредиентов"
  иначе:
    печать "Адрес некорректный"

как надо:

функция заказать_пиццу(адрес):
  если не адрес_валиден(адрес):
    печать "Адрес некорректный"
    вернуть
  
  если не у_ресторана_ингредиенты():
    печать "Нет ингредиентов"
    вернуть
  
  если не клиент_может_платить():
    печать "Недостаточно денег"
    вернуть
  
  печать "Пицца заказана!"

3. Регулярно делать рефакторинг

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

4. Настроить линтер и форматер

Линтер — статический анализатор кода, который следит за определенным стилем написания кода. Так как у каждого из нас свой подход, нам нужен «инструмент-судья», который беспристрастно оценит оформление кода. Форматер помогает автоматически исправить код и привести его к единому виду. 

5. Комментировать только неочевидную бизнес-логику

Комментарии полезны, если они объясняют то, что нельзя понять из кода. Например, когда понимаем, что участок кода содержит особенность бизнес-логики, которая еще не ясна новому сотруднику. Но важно помнить, что избыток пояснений превращает понятный код в мешанину из кода и комментариев. Принцип простой: объясняем редкие, действительно сложные места и не трогаем остальное.

5 Ошибок Рефакторинга

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

2. Делать один огромный коммит
   Делайте много коммитов, каждый на свой шаг рефакторинга. Рефакторинг это как ходьба по заминированному лабиринту, нужно обязательно записывать все ходы и иногда отступать на шаг или N шагов назад и искать другой путь.

3. Рефакторить без промежуточных проверок
   Когда вдохновение несет и хочется "прибраться" и тут и там и везде и некогда останавливаться можно "пролететь поворот" и даже не один. Лучше всего делить рефакторинг на логические этапы. "Дешевые" по времени и ресурсу проверки можно и нужно запускать как можно чаще: компиляция, тесты, запуск приложение локально. Между крупными этапами желательно проводить регрессионное тестирование. И самое отличное поэтапный релиз рефакторинга, чтобы провести не только синтетические проверки, но самую важную "проверку продакшеном"

4. Затягивать и долго не релизить рефакторинг
   Топ выбрасываний рефакторинга на моей практике происходило из за желания довести его до окончательного окончания, всё всё исправить, привести в идеальную симметрию и тд и тп. Чем дольше человек очищает код, пока параллельно идут продуктовые спринты, тем больше он несет накладных расходов(мержить то надо) и тем больше падает вероятность успешной интеграции ветки рефакторинга с основной и его успешного релиза.

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

   В своем канале о разработке в стартапах делюсь опытом и рассказываю еще больше удачных примеров и факапов. Буду рад видеть каждого! Заходите!
   
   Всем удачного рефакторинга!
   
   

[ВИДЕО] AmoCRM + Joomla: быстрая настройка интеграции. Библиотека WT AmoCRM.

- Как быстро настроить интеграцию AmoCRM и сайта на Joomla?

- использовать PHP библиотеку WT AmoCRM для Joomla, которая предполагает использование её разработчиками. А разработчики могут написать любое количество плагинов и решений по интеграции и автоматизации AmoCRM и Joomla.

Смотреть видео на:

• Youtube

• Rutube

• VK Видео

Содержание:

• 00:15 - что такое эта библиотека и как она работает? Тех.ликбез.

• 03:00 - установка с сайта или с GitHub

• 04:00 - собственно установка и настройка интеграции.

• 05:10 - создание внешней интеграции в интерфейсе AmoCRM

• 08:05 - что-то пошло не так... Почему и как исправить (случай с пересозданием интеграции)

• 08:48 - успешное подключение к AmoCRM

• 11:11 - как понять что всё работает?

• 11:50 - демонстрация работы: отправка заказа из компонента интернет-магазина RadicalMart в AmoCRM

• 14:20 - потенциальные возможности по автоматизации бизнес-процессов в связке Joomla с AmoCRM

Страница расширения

Скачать с GitHub

Есть ряд готовых решений для интеграции:

• JoomShopping - Joomla компонент интернет-магазина

• RadicalMart - Joomla компонент интернет-магазина

• RadicalForm - Joomla плагин формы обратной связи

📈 MariaDB 11.8, векторные БД и курс на миграцию с Oracle: Итоги MariaDB Meetup в Тель-Авиве

Вчера мне посчастливилось побывать на MariaDB Meetup с участием самого Майкла «Монти» Видениуса в Тель-Авиве. Это событие стало не только ценной возможностью услышать о стратегических и технических планах развития MariaDB, но и позволило укрепить партнерские связи между проектом и нашей образовательной платформой.

Делюсь ключевыми тезисами и анонсами с митапа, которые будут интересны всем, кто работает с базами данных и Open Source.

1. Стратегический вектор: Open Source и миграция с Oracle

Майкл Видениус в своем докладе однозначно обозначил стратегию MariaDB: курс на безоговорочную победу открытого кода над проприетарными гигантами. Основной акцент был сделан на преимуществах миграции с Oracle на MariaDB.

Преимущества и миграция:

• Экономическая эффективность: Монти открыто говорил о несопоставимой стоимости использования и владения MariaDB по сравнению с Oracle, что является критическим фактором для многих корпоративных пользователей.

• Совместимость синтаксиса: MariaDB активно развивает режим совместимости с Oracle (Oracle Compatibility Mode), который значительно упрощает процесс перехода, позволяя использовать привычный синтаксис SQL. Это резко снижает затраты времени и ресурсов на переписывание существующего кода.

• Производительность MariaDB 11.8: Были продемонстрированы тесты, подтверждающие рост производительности более чем в 2,5 раза по сравнению с предыдущими версиями за счет архитектурных улучшений.

2. MariaDB, AI и Векторные базы данных

Сергей Голубчик представил глубокий технический обзор поддержки векторного типа данных в последних версиях MariaDB. Это важнейший шаг, который ставит MariaDB в один ряд с современными решениями, адаптированными для задач искусственного интеллекта.

• Векторный тип данных (Векторная БД): Встроенная поддержка векторов позволяет использовать MariaDB как полноценную векторную базу данных, что критически важно для работы с embeddings, семантическим поиском и RAG-системами (Retrieval-Augmented Generation).

• Производительность и точность (Tradeoff): Сергей Голубчик подробно остановился на ключевом вопросе производительности векторных операций и компромиссе между скоростью поиска и точностью (performance vs. precision of search). Он продемонстрировал, как тонкая настройка конфигурации и индексов (например, использование HNSW-индексов) позволяет добиться наилучшего баланса, обеспечивая высокую скорость без существенной потери точности результатов.

3. Видение будущего и сотрудничество

Анна Видениус (CEO MariaDB Foundation) представила стратегический обзор развития проекта, подчеркнув фокус на стабильности, высокой производительности и укреплении позиции MariaDB в корпоративном сегменте.

🤝 Новые горизонты: Планы сотрудничества с sqlize.online

Самой продуктивной частью митапа стало личное общение с Майклом и Анной Видениус, которое вылилось в конкретные договоренности:

1. Расширение поддержки версий: Платформа sqlize.online расширит поддержку MariaDB до трех актуальных версий, включая последнюю — MariaDB 11.8 — с акцентом на тестирование ее векторных возможностей.

2. Новый учебный контент: На sqltest.online будет запущен новый набор практических заданий, разработанных совместно с командой MariaDB, для глубокого освоения последних функций и особенностей этой СУБД.

Это сотрудничество поможет ускорить процесс обучения и внедрения инноваций MariaDB среди разработчиков и аналитиков.

❓ Дискуссия: Готовы ли вы использовать векторы в MariaDB?

MariaDB смело интегрирует технологии будущего, делая ставку на миграцию и ИИ.

Уважаемые читатели Хабра, вопрос к вам:

Как вы относитесь к появлению нативной поддержки векторного типа данных в MariaDB? Готовы ли вы использовать эту функцию в своих новых проектах и рассматривать MariaDB как альтернативу специализированным векторным базам данных?

Делитесь мнениями в комментариях!

Где освоить прикладные программы?

Привет! На Хабр Карьере мы собираем для вас сотни классных онлайн-курсов, которые помогают быстро и качественно прокачать профессиональные навыки.

Мы часто делимся подборками по специальностям, а в этот раз решили действовать прицельно — собрали подборку курсов по конкретным прикладным программам.

— PowerPoint. Презентации, слайды, визуалы, анимации, диаграммы.

— Word. Тексты, документы, форматирование, таблицы, списки, колонтитулы, подготовка к печати.

— Excel. Таблицы, формулы, фильтры, диаграммы, автоматизация.

— Photoshop. Изображения, ретушь, вырезание объектов, фон, баннеры, графика.

— Illustrator. Векторная графика, логотипы, иконки, иллюстрации, фирменный стиль, макеты.

— SQL. Базы данных, запросы, сортировка, фильтрация, анализ информации.

— 1C. Учёт, автоматизация процессов, финансы, склад, продажи, документы, отчётность.

А если программы вы уже освоили, то загляните на нашу витрину с курсами по специализациям — эти навыки наверняка пригодятся в освоении новой профессии

PostgreSQL на 4 ТБ, Patroni на две столицы и 16 000 фур в реалтайме: как мы «перевозили» CARGO.RUN

Привет, Хабр! Представьте ситуацию: один логист управляет 80 машинами одновременно. Маршруты, топливо, простои — все в реальном времени. Остановись сервер — бизнес сразу теряет деньги, а на перевозчиков сваливается хаос.

Именно таков мир, в котором работает команда CARGO.RUN — SaaS-платформа, которая автоматизирует грузоперевозки для топ-игроков рынка. Мы подготовили кейс о том, как помогли CARGO.RUN мигрировать к нам в Selectel. Внутри — настоящий технический детектив и архитектурный дзен.

• Базы данных — почему для PostgreSQL с расширениями PostGIS и Timescale (а это 4 ТБ «горячих» данных!) выбрали именно выделенные серверы, а не облако.

• Отказоустойчивость — как развернули кластер Patroni, физически разнесенный между дата-центрами в Москве и Санкт-Петербурге, чтобы пережить падение целого региона.

• Оркестрация — переход от Docker Swarm к Managed Kubernetes для микросервисов, когда в штате всего три DevOps-инженера.

• IaC — как Terraform и GitOps помогли навести порядок и сделать инфраструктуру прозрачной.

Результат миграции — рост производительности логистов в 2,5 раза и сокращение порожнего пробега фур на 53%.

Читайте полную историю переезда, а также оставляйте заявку на бесплатную миграцию➡️

Лекции с нашего второго митапа питонистов в Новосибирске!

Трансфункции и суперфункции (Евгений Блинов)

ИИ ревьювер твоего кода (Максим Исаев)

Ускорение кода через C расширения в python (Алексеев Бронислав)

Наш чат - https://t.me/python_in_nsk

Получите максимум от объектного хранилища данных

Через 25 минут на вебинаре «Внутри S3». Мы создаем масштабируемые, отказоустойчивые и быстрые S3-хранилища: ледяные, холодные, горячие и стандартные. Познакомим вас с устройством сервиса под капотом и разберем, как используют S3 компании из разных сфер. Присоединяйтесь!

Смотреть →

Что обсудим:

👉 как устроено S3 в Selectel на всех уровнях; 

👉 для чего нужны разные типы хранения данных и как с ними работать; 

👉 как использовать частные инсталляции S3; 

👉 как построить собственную дата-платформу с помощью хранилища Selectel.

Подключайтесь к трансляции:

📼 YouTube
📼 VK

⚡️ITFB Group запускает KODA — платформу для объективной оценки эффективности разработки

Мы представили KODA — собственную платформу, которая показывает, как на самом деле работает команда разработки. Не по ощущениям и не по субъективным отчётам, а на основе данных из всех инструментов инженеров: репозиториев, таск-трекеров, CI/CD, баз знаний и систем тестирования.

🔥 За первые 3 квартала внутреннего использования мы увеличили производительность команд на 30%, сократили количество переделок на 35% и ускорили code review на 40%.

💻 KODA объединяет инженерные метрики, ИИ-модули и аналитику, чтобы дать руководителям полную картину разработки — прозрачную, измеримую и безопасную. Все данные остаются внутри компании.

Наталья Романова, директор по развитию ITFB Group:
«Мы создавали KODA как инженеры для инженеров. Но в итоге получили инструмент, который одинаково важен и для бизнеса: он переводит работу разработки в язык цифр, прозрачности и управляемости».

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

Подробнее о KODA — на сайте ITFB Group.

Приглашаем на бесплатный вебинар «Микросервисы: 5 главных ошибок и как их избежать с самого начала». Обсудим, какие ошибки возникают при переходе на MSA: от не тех границ сервисов до хаоса и технического долга. Вы узнаете, как с самого начала проектировать архитектуру правильно и получите чек-лист «10 признаков здоровой микросервисной системы» чтобы не создать «распределенный монолит».

‼️ Обратите внимание, что чек-лист будет выдан только участникам эфира.

🕓 Когда: 25 ноября, 16:00–17:00 (Мск)

👨‍🎓 Спикер: Бурцев Николай — cпециалист по архитектуре ПО, проектированию MSA, .NET-разработке.

Разберём:

1️⃣ Неправильное выделение границ микросервисов: бизнес-декомпозиция против технической.

2️⃣ REST-зависимость: когда API превращается в паутину.

3️⃣ «Всё через брокер»: когда Kafka и RabbitMQ создают больше проблем, чем решают.

4️⃣ Архитектура без инфраструктуры: CI/CD, наблюдаемость, DevOps-влияние.

5️⃣ Архитектура без коммуникации: стандарты, код-ревью, управление качеством.

👉 Записаться

👉 Вот и осень пролетела — а у нас еще есть незакрытые вакансии 💻

Приглашаем опытных специалистов присоединиться к команде SSP SOFT 🌐

✨ У нас в SSP SOFT не бывает рутинных задач — только проекты, которые сначала удивляют своей сложностью, а затем становятся точками роста.
✨ С первого дня вы не одни: за вами закрепляется наставник, который помогает входить в работу спокойно и без лишнего напряжения.
✨ Карьерный скачок здесь реален: наш Проектный офис — это не просто управление, а среда, которая ускоряет профессиональное развитие.
✨ Вы сами выбираете формат: работайте удаленно, приходите в офис в Москве (ЦАО) или в Томске — или комбинируйте, как удобно.
✨ Мы не пропагандируем культ переработок — рабочие процессы гибкие, а личное время и забота о здоровье уважаются.

А еще у нас:
🎁 ДМС (включая стоматологию) для штатных сотрудников
🎁 обучение за счет компании
🎁 бонусы
🎁 общие ивенты — от онлайн-квизов до выездных сборов

📢 Прямо сейчас мы ищем (Подробности о вакансиях читай на ХХ.ру):

• Разработчик Directum

• Системный аналитик

• 1С Разработчик (1С: ЗУП)

• 1С Консультант (ЗУП КОРП)

• С# Разработчик

• Senior Java-разработчик

👉 Чувствуешь, что это про тебя? Тогда не теряй время — присылай резюме напрямую в ЛС нашему HR Lead Алине. Не забудь добавить сопроводительное письмо с ключевой фразой «Нашел(ла) вас на Хабре».

Спасибо за интерес к нашим вакансиям и желаем успеха на собесе )

Актуализировали версии языков в Apps ⌨️

Чтобы вы запускали приложения на более современных версиях, в которых появились новые функции и улучшение производительности.

Добавили версии:

➖ Python: 3.14, 3.13
➖ PHP: 8.4
➖ Node.js: v24
➖ Go: 1.25, 1.24, 1.23
➖ .NET: 9.0
➖ Elixir: 1.19, 1.18, 1.17, 1.16
➖ Java: 25, 21

➡️ Обновить окружения в Apps →

И вам наш продакт-менеджер, Артем Гринберг просил передать:

🤓 А еще готовим статью и вебинар о том, как мы переписали Apps и что именно в них изменилось. Скоро расскажем подробности.

Почему нужно использовать DTO

Data Transfer Object, термин, который для разработчиков на статических языках является чем-то самим разумеющимся, но вот остальные его могут не знать (даже если пользуются). Хотя в эпоху интеграций, фронтенд-бекенд, сервис-сервис, очереди, это крайне важная конструкция.

DTO это очень промежуточный объект между моделью в вашем коде и данными, которые вы отдаете наружу или принимаете от внешней системы.

• Модель => DTO => json/protobuf/sql...

• json/protobuf/sql... => DTO => Модель

Нафига? Почему не сразу преобразовывать из, допустим, json в нашу модель или наоборот? Тем более во всех экосистемах есть механизмы, которые позволяют упаковывать любые объекты, задавая правила преобразования через метаданные, аннотации или еще как-то. Пример из Java:

@Entity
public class User {
    @Id
    private Long id;
    @JsonIgnore              // приходится скрывать
    private String passwordHash;
    @JsonProperty("created_at")
    private LocalDateTime createdAt;

    // getters/setters ...
}

var json = new ObjectMapper().writeValueAsString(dto);

Существует масса причин, почему это плохая идея. Для начала, это банальное нарушение MVC архитектуры. Модель начинает знать как о представлении, о том какие поля надо выдавать наружу, какие нет, как их переименовывать и так далее. Если это кажется натянутым, то вот вам реальные последствия.

Одна и та же сущность для внешнего мира редко представляется одним способом. В зависимости от задачи, это может быть один набор полей или другой. Как это разрулить? Дальше, здесь плохо контролируется процесс, легко может быть такое, что новое поле автоматически попало наружу, хотя вы этого не планировали, но забыли его исключить. А если нужны вычисляемые поля или другое представление (всегда в датах)? В такой ситуации модель будет наполняться доп свойствами и методами, которые готовят доп данные для преобразования, что ведет к сильному загрязнению кода. Что из этого относится к бизнес-части, а что к представлению? Проблема.

DTO позволяют отделить представление от модели в коде, создавая по сути промежуточный слой. Имея его, вы можете независимо развивать свою модель и API для взаимодействия с ним. И да, это один из аспектов MVC, конкретно Model-View.

Готовые DTO гораздо легче чем модели конвертировать в типы на TS если у вас есть такая потребность. Например мы наши DTO (используем Alba), превращаем в типы TS с помощью готового инструмента (Typelizer). С моделями так легко не получится.

За это конечно придется заплатить. В проекте появится папка, с большим количеством файлов. Но это с лихвой компенсирует все описанные выше проблемы. DTO очень простые и для их создания далеко не всегда надо с нуля писать классы. В той же java они генерируются с помощью mapstruct, в других языках свои механизмы.

Но это только базовая история. Если мы еще подключаем инструменты генерации из sql (как в go) или openapi как везде, то те самые DTO создаются вообще автоматически на основе описаний.

INSERT INTO links (original_url, short_name)
VALUES (sqlc.arg(original_url), sqlc.arg(short_name))
RETURNING *;

DTO:

type CreateLinkParams struct {
	OriginalUrl string `json:"original_url"`
	ShortName   string `json:"short_name"`
}

Причем для update будет создана своя структура:

type UpdateLinkParams struct {
	OriginalUrl string `json:"original_url"`
	ShortName   string `json:"short_name"`
	ID          int64  `json:"id"`
}

Здесь отличается только id, но в реальных кейсах, отличий в создании или обновлении одной сущности обычно значительно больше, поэтому количество DTO тут становится еще больше.

DTO, кстати, должны быть имутабельны, иначе туда потечет логика

Больше про разработку в моем телеграм-канале Организованное программирование

В маркетплейсе VK Cloud появилось сразу несколько новых решений, поэтому мы хотим, чтобы вы узнали, как с ними работать из первых рук во время вебинаров. Оба решения появятся в маркетплейсе накануне трансляций.

📌 26 ноября в 11:00 будем говорить о том, какие преимущества открывает РЕД База Данных. Почему это надежно, и как работает совместная поддержка в рамках SLA. Эфир проведет технологический евангелист VK Cloud Станислав Погоржельский и Алексей Бехтин, аналитик отдела разработки СУБД, РЕД Софт.

Что еще обсудим

🔷 Интеграция с прикладными системами. Как легко и быстро подключить РЕД Базу Данных к вашим приложениям, работающим в VK Cloud.

🔷 Кейсы и выгоды. Примеры из практики, демонстрирующие повышение производительности и снижение TCO (совокупной стоимости владения).

🔷 Разработка с помощью ИИ. Генерация приложения маркетплейса на Go с использованием СУБД РЕД База Данных.

Зарегистрироваться

📌 27 ноября в 11:00 начнем разговор про обеспечение безопасности данных в облаке с помощью Next Generation Firewall. Межсетевой экран позволяет контролировать трафик между ВМ, настраивать правила и вести мониторинг real-time. 

Владислав Закрятин, инженер по предпродажной подготовке из Ideco, покажет в прямом эфире, как развернуть решение за 15 минут.

Кому точно стоит посетить вебинар

🔷 DevOps и SRE-инженерам.

🔷 Руководителям ИТ-направлений.

🔷 Всем, кто использует или планирует использовать облачную инфраструктуру.

Зарегистрироваться

Каждый год в начале декабря мы с друзьями ходим мы с коллегами проводим бесплатную конференцию для IT-специалистов. Мы в ЮMoney верим, что сила — в людях, которые делятся знаниями. Поэтому не только создаём финтех-продукты, но и развиваем комьюнити талантливых специалистов.

Нам всегда есть, что рассказать и чем поделиться — как тут, на Хабре, так и в живом общении. В течение года мы проводим разные митапы: о Java, бэкенде, DevOps, тестировании. И уже много лет завершаем год большой конференцией, где захватываем разные направления финтеха: от архитектуры и аналитики до разработки процессов и управления проектами.

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

Некоторые из докладов мы адаптировали для Хабра. Так, например, появилась статья Дениса о том, как в процессинге проводили импортозамещение железа. Поскольку статья вышла спустя год после выступления, а за это время, как водится, произошли изменения, мы дополнили текст новыми вводными. Еще из примеров прошлогодних докладов, которые перекочевали на Хабр: статья менеджера проектов Ксюши о том, как её команда пережила конфликтную стадию, и статья «8 друзей Белбина» от бизнес-тренера Ани — интересно посмотреть на команду разработки через призму ролевой модели.

Этот год не исключение. 5 и 6 декабря ждём всех на тёплый офлайн- и онлайн-приём. Поговорим о трендах финтеха, внутренних системах, разработке и, конечно, об AI-технологиях. Чуть позже расскажем о программе подробнее. Подписывайтесь на канал ЮMoney Tech, чтобы не пропустить событие.