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

Решать выше перечисленные проблемы можно разными способами. В своей работе в компании Greensight в качестве senior backend developer при разработке заказных проектов на базе Open Source платформы Ensi, я с коллегами перепробовал множество решений.

Данная статья описывает практическое использование Kafka в микросервисных приложениях для решения этих проблем.

Представьте, что вы разработали программное обеспечение. Все идеально: код отточен, тесты пройдены, система готова к работе. Но тут встает вопрос: как отправить документацию заказчику?

Всем привет! Меня зовут Катя, я развиваю Gramax, open source-платформу для управления технической документацией. В этой статье хочу поделиться впечатлением от стандартных способов передачи документации на заказную разработку. А также рассказать о том, как этот процесс можно автоматизировать с помощью Gramax.

Привет! Меня зовут Влад и занимаюсь Python backend-разработкой. Довольно долго я работал над большим продуктом, который объединял несколько команд разработки. В нем было много микросервисов, базовые фичи кочевали из одного в другой, и часто разработчики делали одни и те же инфраструктурные компоненты по-разному. А когда переходили с одного микросервиса на другой, им приходилось долго осмыслять кодовую базу нового решения.

Код полнился ошибками, а разработчики тратили время на их отладку и исправление. Так мы вживую воплотили печальную статистику: разработчики ПО в среднем тратят на написание кода лишь [52 минуты в день](https://www.software.com/reports/code-time-report), остальное — исправление ошибок и другие сопутствующие задачи.

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

Привет, Хабр! Меня зовут Александр Белышев. Хочу поделиться своим недавним опытом работы над RAG‑сервисом и думаю, что эта тема может быть интересна другим коллегам.

У меня на работе возникла задача по реализации RAG (Retrieval‑Augmented Generation) сервиса. Хотя без моего участия эту задачу успешно решили на Python, изучая их код я задумался: а как можно сделать что‑то подобное на Go?
Результатом этого исследования и моей работы стало следующее решение...

Обычно для создания Телеграм-бота нужно знать какой-нибудь язык программирования и арендовать виртуальный веб-сервер. Теперь api2app позволяет создавать в графическом режиме не только веб-приложения, мини-приложения для ВК, но и чат-ботов для Телеграм. Если у вас есть готовое API, то для создания бота Вы можете обойтись без программирования, а бекенд-программисты могут сэкономить время.

В этом уроке расскажу как быстро создать простого Телеграм-бота.

В мире разработки программного обеспечения постоянно появляются новые подходы к построению систем. Event-Driven архитектура выступает одним из наиболее перспективных решений для создания гибких и масштабируемых приложений.

В данной статье мы расскажем о реализации Event-Driven архитектуры (EDA) с использованием FastAPI и паттерна Publish/Subscribe. Рассмотрим основные концепции, компоненты и практические примеры кода для создания масштабируемой системы обмена сообщениями.

Golang — приключение не на 20 минут, а игра вдолгую. Подтвердили это, собрав в офисе Lamoda спикеров Lamoda Tech, а также 2ГИС и МТС. Помимо новых докладов, разблокировали экспериментальный формат факап-разгонов, где наши друзья из ВИ.Tech, Orion soft и Cloud.ru вместе со зрителями делились историями провалов. Публикуем материалы с этой встречи.

К старту курса по разработке на С++ рассказываем, как самостоятельно собрать IP-камеру с обнаружением движения. За подробностями приглашаем под кат, где вы найдёте много фотографий и видео на Youtube-канале автора, за которым наблюдают более 30 000 человек.

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

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

Я решил, что хватит терпеть это, и вдохновился простотой стандартного пакета flag, где каждая опция — это буквально одна строка кода. Представьте: больше никакой беготни по структурам и файлам! В zerocfg вы объявляете опцию, дефолтное значение и документацию в одной строке — лаконично, понятно, надёжно.

Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.

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

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

Меня зовут Маша. Да, как‑то даже во взрослом возрасте все меня так называют. Работаю в IT или около IT сфере еще со студенческих времен. Чего только не насмотрелась… но сегодня не об этом. Сейчас занимаю должность системного аналитика в Ростелеком Информационные Технологии.

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

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

Серия интервью «Open source в России» продолжается уже более года. Мне удалось пообщаться с представителями крупнейших компаний-разработчиков программного обеспечения и лидерами open source-сообществ ведущих университетов.

Пришло время поговорить об открытой разработке с командами стартапов. Спикер сегодняшнего материала — Евгений Перов, директор по продукту в корпоративном мессенджере Compass. Обсуждаем open source-эксперименты компании, а также монетизацию сервисов с открытым кодом и перспективы open source в России.

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

API Mesh упрощает управление API в распределенных системах, предоставляя унифицированный слой для оркестрации, безопасности и "наблюдаемости" (observability). В этой статье мы рассмотрим особенности API Mesh, его уникальные возможности и как он может изменить способы управления API для бизнеса.

Привет, Хабр! Я Антон Ерёмин, ведущий инженер дирекции инфраструктурных проектов Positive Technologies. Сегодня на примере харденинга реальных сервисов продолжаем рассказывать о нашей методологии ХардкорИТ — подходе к определению времени атаки и вероятных маршрутов хакеров.

В прошлый раз мы проводили харденинг инфраструктуры Microsoft Exchange, затрудняя возможность ее атаки, разбирались в тонкостях защиты zVirt. Теперь настало время рассказать про харденинг GitLab.

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

Не так давно команда ОК столкнулась с подобной дилеммой: исторически для отображения страниц мы использовали server-side рендеринг на базе GWT (Google Web Toolkit) и RDK (наша внутренняя разработка), так как разработка первой версии ОК началась более 20 лет назад. Такой набор технологий «под капотом» был оптимален в те времена, но сейчас он, мягко говоря, не самый желательный. Поэтому нам было важно перейти на более распространенную библиотеку, а точнее — на React. Это мы и начали делать итеративно, шаг за шагом для каждого раздела сайта.

Меня зовут Александр Косницкий, я разработчик в компании ОК. В этой статье я расскажу, как мы переводили на React раздел «Обсуждения»: с чего начинали, с чем сталкивались и как в результате смогли получить то, что поможет не только нам, но и остальным командам с переводом на новую библиотеку их собственных разделов.

Привет! Меня зовут Олег Иванов, я руководитель мобильной разработки в Московском кредитном банке. Сегодня поговорим о Server Driven UI вот по такому плану:

• что это вообще за технология

• из чего она состоит

• рассмотрим наши подходы к ее реализации

Начнем с терминологии:

SDUI (Server Driven UI) — это пользовательский интерфейс, управляемый сервером.

Что такое пользовательский интерфейс? Среда, с помощью которой пользователь взаимодействует с программным обеспечением через приложения. Обычно он состоит из множества экранных форм, которые и ведут пользователя по флоу до какого-то определенного результата.

Привет, Хабр! В этой статье поговорим о способах насыщения бэклога продукта, оптимальным способом приоритизации основанном на специфике и стадии продукта. Это короткое, но полноценное руководство для продуктовой команды необходимое для того, чтобы не превратить бэклог в свалку задач, понять как к нему подступиться и держать в нем все самое необходимое.

Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.

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

В сфере строительного проектирования все больше места занимают технологии информационного моделирования (ТИМ). главным форматом обмена данных в ТИМ является формат IFC. Модели в этом формате требуют как коммерческие заказчики, так и государственная экспертиза.

Работа с собственными форматами программных решений для информационного моделирования (такими как RVT) обычно не вызывает затруднений благодаря широкому функционалу, предоставляемому разработчиками программного обеспечения. Однако формат IFC часто вызывает вопросы из-за нехватки специализированных инструментов и знаний.

Одним из таких вопросов является создание чётко сформулированных требований к моделям IFC и последующая их проверка на соответствие этим требованиям.

В этой статье будет подробно рассмотрен данный вопрос. В качестве инструментов будут использованы формат IDS и библиотека ifcopenshell а также предложено готовое решения для валидации моделей IFC на основе этих инструментов.

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