Привет! Это снова я, Паша Лукьянов. Я по-прежнему deputy CTO в AGIMA и по-прежнему рассказываю о принципах работы архкомитета у нас в компании. В первой части статьи я объяснил, из каких критериев состоят наши Definition of Ready (DoR) и Definition of Done (DoD), а также что представляет собой наша статусная модель. А теперь поговорим об этапах проработки архитектурных документов. Если вы внедряете архитектурный комитет в своей компании и прописываете процессы — вам сюда.
Привет! Меня зовут Павел Лукьянов, я deputy CTO в AGIMA. Каждую пятницу с 3 до 4 пополудни я занят. Не звоните мне и не ищите меня. В это время у нас еженедельная встреча архитектурного комитета, где я и другие умные люди обсуждаем важные вопросы. Как правило, в центре внимания новые проекты или капитальные перемены на старых. Меняется стек? Это к нам. Обновляем архитектуру? Окей, давайте подумаем. Запускаем проект с нуля? Подберем оптимальные решения.
Все важнейшие технические вопросы у нас проходят через такой вот консилиум архитекторов и руководителей департаментов. Поэтому мы можем гарантировать и самим себе, и заказчику, что техническая часть проекта точно будет на высоте. Но архитектурный комитет, как и любая другая структура, живет по своим правилам и законам. Что это за правила и законы, я расскажу в этой статье. Если вам предстоит настраивать работу архкомитета в вашей компании — велком.
Это первая статья специалиста по архитектуре ИТ-систем и трансформации ИТ-ландшафта Дениса Прилепского из серии «Строим корпоративную GenAI-платформу: от концепции до ROI». В этой части он объясняет, зачем вообще нужен архитектурный подход при внедрении GenAI-решений и как грамотная архитектура помогает пройти путь от идеи до реальной бизнес-ценности.
Мне тут попалась идеальная статья про DI в который нашелся очень интересный пример для разбора. Есть фундаментальные основы, которые почему то никто не хочет сформулировать, а начинающим разработчикам, которые впервые сталкиваются с концепцией DI, в первую очередь надо бы рассказать эти фундаментальные основы, но почему то нет желающих это сделать и у меня даже есть предположения, почему это не получается, я попробую их как-то выразить в том числе.
Я знаю что искать ошибки в статьях начинающих на Хабре это плохой тон, и я вряд ли выйду в плюс с такой статьей, но как говорится: Платон мне друг, но истина дороже.
В предыдущей статье мы выяснили как создать два класса (Хост и Енкодер, класс А и класс В) один из которых (А) не может работать без использования функций другого класса (В, а может, и без данных из этого класса В не может работать), но при этом совершенно не зависит от этого класса В! То есть класс А может запросто работать с любым другим классом (C, D, … ) вместо класса В, при некотором условии изложенном в предыдущей статье. По моему, та статья может быть хорошей разминкой для понимания концепции Внедрения Зависимостей. И, определенно, эта статья может считаться продолжением темы практической архитектуры ПО.
Привет, Хабр! На связи Сергей Гайдамаков. Продолжаем обсуждать и тестировать набор реплик MongoDB.
В предыдущей статье мы рассмотрели структуру отдельного узла MongoDB, разобрали свойства параметров writeConcern и readConcern для работы с набором реплик MongoDB.
В этой статье я покажу результаты тестов при аварийных ситуациях, которые могут происходить в распределенной системе. Сделаем выводы о свойствах набора реплик с точки зрения CAP- и PACELC-теорем для распределенных систем и посмотрим параметры управления CAP-свойствами неоднородных распределенных систем.
Реализация системы с микросервисной архитектурой редко обходится без классического разруливающего REST-гейтвея. Но когда ваша система растёт годами, а в гейтвее плодятся сотни ручек с просачивающейся бизнес-логикой, можно внезапно обнаружить, что ваш REST-гейтвей стал монолитом со всеми вытекающими последствиями.
Мы в Авто.ру шли к этому состоянию гейтвея довольно долго. История его началась в 2015 году: десятки разработчиков, сотни ручек, почти 300 000 строк кода — и релизы, которые можно катить неделю. Чтобы спасти наш стремительно деградирующий time-to-market и вернуть разработке гибкость, мы решили попробовать GraphQL-федерацию. Спойлер: кажется, получилось.
Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру, и в этой статье я расскажу, как мы перешли от REST к федерации GraphQL: зачем нам это понадобилось, с какими подводными камнями мы столкнулись, как выглядели первые миграции трафика, к чему всё это привело на данный момент в цифрах и инфраструктуре.
Привет! Распознаванием речи (ASR) уже никого не удивишь, но качественное распознавание на разговорном русском языке, а особенно в телефонии — очень сложная штука: люди редко говорят как профессиональные дикторы, часто бывает плохое качество звука с постоянными шумами на фоне и в целом есть миллиарды прочих нюансов. Наша компания занимается голосом больше 8 лет, есть собственные классные модели синтеза, распознавания и продукты на их основе, поэтому экспериментов мы проводим очень много и за появлением новых голосовых моделей следим очень внимательно.
В свободном доступе уже есть самый узнаваемый Whisper, есть интересные модели GigaAM от Сбера, не так давно Т-Банк выложил в открытый доступ свою модель T-One — давайте заглянем под капот нашего внутреннего бенчмарка и посмотрим насколько кто хорош.
Поехали!
Это третья статья из цикла «Проектирование GraphQL API».
В предыдущих статьях мы рассмотрели основы GraphQL и принципы проектирования схемы. Теперь перейдем к архитектуре — фундаменту, определяющему, как GraphQL API будет работать в реальных условиях.
В отличие от классического подхода, где BI-система жестко фиксирует связи, мы реализовали модель, которая сама определяет, какие таблицы и связи нужны под конкретный дэшлет, и формирует оптимальный запрос «на лету». Это наша новая Адаптивная модель данных Luxms BI.
Я, Николай Павлов, инженер по обработке данных, и в статье мы разберём, как на практике построить такую модель на примере небольшого проекта: поднимем ClickHouse в Docker, создадим схему «снежинка» с тестовыми данными, соберём адаптивную модель и построим дэшборд с экономическими метриками интернет-магазина.
В этой статье расскажем про новую адаптивную модель данных в Luxms BI. Мы реализовали подход, при котором модель сама понимает, какие таблицы и связи нужны под конкретный дэшборд, и строит оптимальный SQL-запрос. Это делает аналитику быстрее, а работу с данными — действительно self-service.
Расскажем как это работает, чем отличается от старого подхода и какие преимущества дает аналитикам и бизнесу.
Что такое системный дизайн? На мой взгляд, если дизайн программного обеспечения — это про то, как собирать строки кода, то системный дизайн — это про то, как собирать сервисы. Базовые строительные блоки софта — переменные, функции, классы и так далее. Базовые строительные блоки системного дизайна — это серверы приложений, базы данных, кэши, очереди, шины событий, прокси и прочее.
Этот текст — моя попытка в общих чертах изложить всё, что я знаю о хорошем системном дизайне. Многие конкретные решения приходят только с опытом, и этим опытом я не могу поделиться напрямую. Но я хочу зафиксировать хотя бы то, что можно сформулировать словами.
В этой статье я покажу, как провожу UX-аудит: от первого контакта с клиентом до выдачи финальных рекомендаций. Поделюсь своим процессом, инструментами, примерами документов и рефлексией о том, что на самом деле важно в UX-работе.
Как это обычно происходит? Покажу на примере последнего запроса. Пишет мне потенциальный клиент в Телеграм:
— Добрый день, Егор! Подскажите, пожалуйста, ориентировочную стоимость проектирования и аудита интерфейса. Уже есть готовый проект, думаем о редизайне.
На этом этапе моя цель — понять суть задачи и смогу ли я помочь. Дело в том, что разные люди по-разному представляют себе, что такое проектирование и аудит и в результате разговора может выясниться, что они имели в виду что-то, чем я не занимаюсь.
Объясняю в переписке, что всё очень индивидуально и предлагаю время созвона. Моя задача — организовать часовой разговор, во время которого я познакомлюсь с человеком и проектом, а также успею провести экспресс-аудит. Это бесплатно и всегда интересно.
Агенты — одна из горячих тем этого лета: интерес к ним существенно вырос, как и потребность в инструментах, упрощающих разработку таких систем. И мы в Beeline Cloud собрали несколько open source-проектов по теме под лицензией Apache 2.0.
Есть один чудесный советский фильм — «Приключения Электроника». В нём злой персонаж с криком «Где же у него кнопка?!» ищет у мальчика-робота скрытый рычаг, который заставит робота вести себя так, как нужно злодею. Многие руководители и тим лиды, напоминают мне этого персонажа, считая, что человек устроен просто - у него есть "волшебный пендель" или "волшебная кнопка", нажав на которую можно сделать так, чтобы он (сотрудник) наконец начал поступать правильно. И я, грешен, тоже искал эти «кнопки». Но моя практика упрямо показывает: у людей нет таких кнопок.
Зато есть паттерны — устойчивые способы реагировать на неоднозначные и неопределенные ситуации. Их я обнаружил эмпирически на своей управленческой практие. К моему великому удивлению, они напомнили мне принципы ведущих религий и мировых этических учений.
Скажу сразу — это не теория и не наука. Я не ставил экспериментов в лаборатории. Это обобщение моей практики руководства людьми. Когда в команде или коллективе появляется нечто непонятное, неоднозначное, конфликтное, когда возникает напряжение, когда нужно «что‑то с этим делать» — люди начинают вести себя по‑разному. И при этом их реакции, казалось бы, случайные, конфликтные, эмоциональные — повторяют одни и те же паттерны. Я выделил пять таких паттернов. Это мой опыт, мои обобщения, сделанные в реальных коллективах. Некоторые сочтут это упрощением, фантазией, «философствованием». Возможно, так оно и есть.
Но если вы когда-либо задавались вопросом: «Почему этот человек снова и снова поступает именно так, как поступает?» — возможно, эти паттерны помогут вам увидеть то, что скрыто за словами.
Переход на микросервисы — это не просто тренд. Для многих компаний это стало необходимостью. Монолитные приложения, которые когда-то служили верой и правдой, начинают трещать по швам под нагрузкой. Они медленно собираются. Их сложно обновлять. Малейшая ошибка в одном модуле может обрушить всю систему.
Микросервисы обещают решение. Гибкость. Масштабируемость. Независимые команды. Быстрые релизы. Звучит идеально. Но дорога к этой цели усеяна ловушками. Я видел проекты, которые провалились, потратив миллионы. Они просто поменяли один большой клубок проблем на десятки маленьких.
Почему технический прогресс превращается в системный коллапс?
Всё дело в парадоксе Джевонса — эффекте, при котором повышение эффективности не ведёт к экономии, а запускает цепную реакцию роста.
И в эффекте Черномырдина — когда «лучше» на бумаге становится «как всегда» в реальности. Это не философия. Это — диагноз.
Узнайте, как эти феномены работают в ИТ-проектах, почему «оптимизация» часто бьёт по людям, и как построить систему, которая не разрушает то, что должна улучшать.
Чек-лист для аудита проекта внутри.
Практическое руководство по работе со сложными клиентами — с примерами из нефтегаза, госсектора, бизнеса и стартапов.
Эта статья — концентрированный опыт нашей команды аналитиков из компании Rubius, накопленный за годы работы в заказной разработке. Здесь нет теории из учебников — только проверенные на практике методы общения с «Генералами», «Истериками», «Цезарями» и другими сложными типами заказчиков.
Ястолкнулся с такой проблемой: логика между доменами сложнее самих доменов
Если строить систему по DDD: домены, агрегаты, use cases, события - всё красиво.
Потом пришёл сценарий: «Отменить заказ»
Я думал: `Order::cancel()`, вызову `inventory.release()`, `pricing.refund()`, и готово». Но...
• Если доставка уже в пути - нужно создать возвратную накладную
• Если платёж падал дважды - отменить всё, а при первой попытке только заморозить баллы
• Если товара нет - перенести резерв на другой склад, пересчитать доставку, спросить клиента, если дороже
• Если клиент повторил платёж - восстановить резерв и доставку
И я решил:
Самая сложная логика тут не в доменах, а между ними.
А в книжках по DDD, Clean Architecture, Hexagonal об этом не пишут.
Это напомнило проблему в ООП, когда каждый объект отвечает только за свою корректность (инвариант), а логическую зависимость при взаимодействии должен обеспечить ещё один класс "чистая выдумка". Также, у ФП есть более простые и явные способы.
Я напишу на Rust, потому что этот язык удобнее управляет бизнес правилами.
Всем привет! Меня зовут Дима Лунин, я автор курса по экспериментам в Академии Аналитиков Авито. В текущей статье я хочу "обкатать" материал, который мы рассказываем на курсе экспериментов, а также поделиться экспертизой по АБ-тестированию с ребятами, которые только начинают свой путь в аналитике, но уже имеют базовые знания в статистике и в проверке стат. гипотез.
История ИТ представляет собой череду волн автоматизации, каждая из которых радикально меняла требования рынка и подходы к разработке. Эти волны не просто внедряли новые технологии, они трансформировали бизнес-модели, создавали новые профессии и переопределяли ценность специалистов. Предлагаю ретроспективно взглянуть на сферу ИТ и пофантазировать, что нас ждёт.
