Всем привет! Я Лина, инженер по обеспечению качества в Команде Контента и Трафика в Банки.ру.
Я хочу рассказать, как мы работали над обновлением сложного сервиса – Народными рейтингами. В этой статье представлен каждый шаг от макетов до пострелизного теста: со своими заметками, выводами и, конечно, примерами конкретных багов, которые попадались во время работы над новыми Народными рейтингами и редизайном НРСК.
В Enterprise-сегменте (ритейл, финтех, промышленность) часто возникает типичная задача: есть тяжелое, неповоротливое ядро (SAP, Oracle, IBM Tririga или монолитная 1С) и есть необходимость дать доступ к части его данных внешним контрагентам.
Бизнес просит: «Давайте сделаем легкий B2B-портал для подрядчиков, чтобы они сами обновляли свои лимиты/квоты/статусы».
На первый взгляд задача кажется тривиальной: подняли Frontend на React/Vue, сделали пару REST API эндпоинтов и пишем напрямую в базу ядра. Но именно здесь начинаются архитектурные катастрофы, которые стоят корпорациям миллионы рублей из-за потерянных данных и логических конфликтов.
В этой статье я разберу паттерн отказоустойчивой двусторонней интеграции через шину данных (ESB) и покажу, как мы стандартизируем описание таких узлов с помощью протокола АОК (Архитектурно-Ориентированное Знание).
Добрый день, дорогие читатели!
Поделюсь с вами опытом составления артефакта, который объединяет уровни абстракции проектируемого решения в одном месте: развертка вариантов использования по статусной модели с маппингом на API.
Привет, Хабр! На связи Алексей Боровиков, архитектор Astra Cloud.
Когда меня спрашивают, чем мы занимаемся, я часто слышу в ответ: «Понятно, облако делаете». Потом, разговор имеет два сценария развития. Либо в сторону «А что такое облако?», либо — «А, еще одно облако». Как понимаете, дискуссия не из легких. Но в любой ситуации все сводится к тому, что облако облаку рознь. Потому что за последние несколько лет я наблюдал, как этим словом называют все, что угодно.
В нашем случае за этим термином стоит конкретная инженерная философия, которая ломает привычные сценарии «сначала сделаем для себя, а потом как-нибудь упакуем в коробку». Именно так рождались все крупные провайдеры, и именно так рождалась куча проблем, с которыми мы теперь разбираемся.
Привет, Хабр! Меня зовут Роман, я программист в команде «Гравитон» и моя задача в компании — разработка API/CLI интерфейсов и приложений на языке Python.
Цель данной статьи в том, чтобы показать как через внедрение «типовых подходов» и вспомогательных библиотек/утилит очень сильно упрощается поддержка проекта в настоящем (при передаче другому человеку или разработке в команде) и в будущем (возобновили проект спустя время).
Первое, что нужно сказать — проект на Python это не только сам Python, но и множество технологий используемых вместе (Git, Docker, и т.д.). В этой статье мы сконцентрируемся на самом проекте, а именно с чего начать, что прикрутить, что учитывать при разработке.
40 000+ записей без пагинации, 200 OK вместо 400 Bad Request, SQL-запросы в ответах клиенту. Собрал 10 ошибок API из реальных проектов: монолитов, микросервисов, стартапах и энтерпрайза.
Предыдущие две статьи сформулировали гипотезу: распределённое сообщество IT-специалистов может координироваться без иерархии, зарплат и венчурного капитала — если протокол взаимодействия спроектирован правильно. Гипотеза красивая. Но красота — не аргумент. Нужна верификация. Здесь — первая попытка её провести: агентная симуляция на 500 независимых прогонов, математические метрики и один неудобный результат, который требует решения.
Большинство знают базу: создал схему компоновки, написал запрос, перетащил поля в настройки — получил отчёт. Но СКД умеет гораздо больше! И многие задачи, которые решают кодом в модуле отчёта, на самом деле решаются средствами самой компоновки — проще, надёжнее и с бонусом в виде пользовательской настройки.
Разберём механизм и приёмы, которые экономят время и код.
Видеонаблюдение умеет быть очень вежливым. Сначала оно тихо просит подключить еще пару камер. Потом добавить удаленный доступ. Потом аналитику. Потом второе рабочее место. Потом архив подольше. Потом мобильный просмотр. Потом облачное дублирование. А потом внезапно выясняется, что система, которую считали как “небольшую на 15 камер”, ведет себя как полноценная инфраструктура с десятками параллельных видеопотоков, конкуренцией за сеть, сервер, хранилище и внимание администратора.
Язык проектировался простым, лёгким в освоении, готовым для написания сервисов с первого дня. Он мог бы таким и остаться, если бы не одна проблема. Проблема отбора.
Инженеры Google понимали, что без подводных камней, необходимости знать детали реализации языка и неконсистентного синтаксиса не о чем будет спрашивать на собеседовании.
Явно ставилась задача — сделать язык достаточно простым, но не настолько, чтобы собеседование мог пройти любой новичок.
Что сработало хорошо
MQTT — надёжный и простой протокол для умного дома
Плагин-архитектура — легко добавлять новые устройства
Обработка ошибок — система устойчива к сбоям
Очередь команд — предотвращает конфликты
Что можно улучшить
Поддержка больше протоколов — Zigbee, Z-Wave, Matter
Голосовая обратная связь — подтверждение команд голосом
Сценарии — поддержка сложных сценариев (макросов)
Машинное обучение — адаптация под привычки пользователя
Советы для разработчиков
Начинайте с простого — начните с одного устройства, затем масштабируйте
Тестируйте надёжность — тестируйте в реальных условиях
Обрабатывайте ошибки — устройства могут быть недоступны
Документируйте API — облегчает добавление новых устройств
Индустрия генеративного искусственного интеллекта больна. Симптомы этой болезни видны невооруженным глазом: шесть пальцев на руках, нарушенная геометрия объектов в движении и рассинхрон звука с артикуляцией (AV-desync). Но вместо того, чтобы лечить причину математикой, техногиганты пытаются заглушить боль грубой силой, заливая проблему деньгами и сжигая мегаватты энергии на кластерах Nvidia H100.
Сегодня мы наблюдаем классическую архитектурную ошибку: попытку решить фундаментальный математический изъян экстенсивным наращиванием "железа". И эта гонка приведет к неизбежному краху текущей бизнес-модели монополистов.
За свой многолетний опыт я не встречал основательного подхода к логам приложений.
Часто я слышал фразы: "что нужны логи", "логи плохие" и т.д.
Но они слишком общие и могут означать все и ничего одновременно.
Предлагаю детально разобраться, как именно можно писать логи в этой статье.
Простой вопрос, который разделяет инженеров и «операторов фреймворков»
Дисклеймер для опытных: если вы знаете ответ – внутри реальный кейс, как этот баг сломал мой паспорт в проде, и история с собеседования, от которой хочется плакать.
В этой статье мы рассмотрим, как при помощи искусственного интеллекта отрефакторить множественные файлы на Java. Действуем по такому сценарию:
Есть компания, которая при работе с микросервисами на Java использует собственную библиотеку, управляющую флагами для переключения фич. Теперь решено мигрировать на Unleash, где работа с флагами переключения фич организована удобнее, а также предусмотрено поэтапное включение фич.
Рассказ технолога о том, как делают сложные платы и почему там все не как в двухслойках.
Мы уже много говорили про проектирование отверстий, про разницу между высокоскоростными и высокочастотными платами. Но сегодня заберемся в самую глубину — буквально. Поговорим о многослойных печатных платах.
Однослойные и двухслойные платы — это классика, с нее все начинали. Но когда устройство становится сложным, миниатюрным и быстрым, без многослойки не обойтись. Четыре, шесть, восемь и больше слоев — это уже не просто «еще одна плата», это совсем другой уровень проектирования и производства.
Почему многослойка — это отдельный мир?
Внешне четырехслойная плата может выглядеть как двухслойная — ну подумаешь, толщина чуть больше, а иногда такая же. Но внутри это пирог, в котором каждый слой живет своей жизнью:
Я перепробовал несколько способов вести документацию по базе данных — и у каждого были свои проблемы: информации недостаточно, сложно поддерживать, непонятна команде. Хуже всего, что плохая документация по БД тянет за собой проблемы с требованиями к данным — а это не только таблицы, но и миграции, и данные в коде. В какой-то момент я понял, что пытался решить одним документом три разные задачи.
Рефакторинг — это не уборка, это хирургия на живом коде. Большинство провалов здесь не технические: смешали рефакторинг с улучшениями, сделали один огромный коммит, затянули релиз — и три недели работы ушли в мусор. Собрал 10 ошибок из реальных проектов: с примерами кода, разбором механики и способами не наступить на те же грабли.
Приветствуем, Хабр.
Сегодня мы хотим напомнить вам об одной важной книге, которую в очередной раз допечатали в январе текущего года: «Создание событийно‑управляемых микросервисов». Мы пытаемся развить эту тему в разрезе «для начинающих архитекторов», рады были бы пообщаться с потенциальным автором, который также разделяет наш интерес. Чтобы был более понятен интересующий нас уровень сложности и круг тем, предлагаем ознакомиться с переводным обзором этой темы; статья сентябрьская, найдена в блоге «The Scalable Thread».
Всем привет! Меня зовут Саша. Я тимлид команды разработки личного кабинета пользователя в Банки.ру.
В какой-то момент я понял, что мы тратим слишком много времени на однотипные изменения в коде: обновления зависимостей, правки после breaking changes, синхронизация между проектами. Всё это делается через поиск, регулярки и ручное редактирование и быстро начинает масштабироваться в боль.
В статье разобрал, как можно подойти к этому иначе: использовать codemod и jscodeshift, чтобы автоматизировать такие изменения и применять их сразу ко всей кодовой базе. Как это работает через AST, и посмотрим на примере, как писать свои трансформации.
