✨Запустили промо — вырос GMV. Совпадение или всё-таки эффект?

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

👉 Подробности и разбор — читайте на Хабре!

🌍 «Где-то на вики было про это» или используем антидот в виде сниппетов

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

Дмитрий Рагулин, DevOps-инженер платформы (PaaS), делится практическим подходом, как вытаскивать такие фрагменты на поверхность и держать их под рукой без переписывания документации и новых инструментов.

Если у вас тоже есть «команда, которая точно где-то была», то переходите по ссылке и читайте советы!🏃

Как LLM чувствуют себя в поиске?

👉 Кажется, что поиск — это «нашёл → показал → купили».
Но если бы всё было так просто, у нас не было бы этого поста.

Предлагаем пройти небольшой квиз и попробовать угадать, какие особенности есть у поиска в Купер.тех на самом деле:

🟢Где LLM проще всего принимать решение?

- Исправление опечаток
- Проверка синонимов
- Разметка релевантности
- Комплементарные товары
(Подсказка: не всё, что кажется простым человеку, так же просто для модели)

Ответ: Валидация исправлений опечаток — лучший и самый стабильный кейс

🟢А где, наоборот, больше всего «серых зон» и субъективности?

- Оценка «почти подходит» vs «подходит»
- Различие похожих товаров
- Понимание пользовательского намерения
- Все варианты сразу

Ответ: Оценка «почти подходит» vs «подходит» (промежуточные классы)

🟢Как думаете, что сильнее всего повлияло на качество LLM-разметки?

- Качество промпта
- Формат данных
- Несколько моделей вместо одной
- Выбор схемы классов
- «Модель просто стала умнее»

Разобраться, что действительно сыграло ключевую роль, можно в новой статье Александра Баранова, аналитика данных в команде поиска Купера, где он подробно рассказывает, как LLM-разметка прошла путь от эксперимента до инструмента в проде.

Здравствуй, разработчик!

Запомни одну важную истину — код можно переписать, а архитектурные решения живут долго и ломаются без предупреждения.

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

🔮 Базовые заклинания

Роберт Мартин — «Чистая архитектура»
Чтобы понять, что архитектура это не про фреймворки, а про границы, ответственность и направление зависимостей. Даёт язык для обсуждения архитектуры в команде.

Саймон Браун — «Software Architecture for Developers»
Коротко и по делу: как думать об архитектуре, не утонув в схемах.

Сэм Ньюман — «Building Microservices»
Хорошая вводная в распределённые системы: что в них реально усложняется и почему микросервисы — это выбор, а не апгрейд.

Дейв Фарли — «Современная программная инженерия. ПО в эпоху аджайла и непрерывного развёртывания»
Основная идея книги в том, что программирование — это не магия, а инженерная дисциплина, основанная на научном методе. Понятия «хорошей» архитектуры и качества Дейв сводит к двум базовым вещам: управлению сложностью и поддержанию скорости изменений.
🎬Кстати, у Дейва есть отличный канал на Ютубе.

🪄Сложные чары

Сюй Алекс — «System Design. Подготовка к сложному интервью»
Эта книга не только про интервью. Она учит структурировать рассуждения, задавать правильные вопросы и объяснять решения так, чтобы вас понимали.

Крис Ричардсон — «Микросервисы»
Про реальную стоимость микросервисов, компромиссы и сложности, о которых обычно забывают на старте.

Нил Форд, Марк Ричардс, Прамод Садаладж и Жамак Дехгани — «Software Architecture: The Hard Parts»
Про самые неудобные вопросы архитектуры: где провести границы, когда разделять систему и какие компромиссы действительно важны.

🧙‍♂️ Высшее искусство

Мартин Фаулер — «Patterns of Enterprise Application Architecture»
Многие паттерны из книги вы уже встречали в проде, просто не знали, как они называются. Помогает систематизировать опыт и лучше понимать чужие решения.

Нил Форд, Ребекка Парсонс, Патрик Куа, Прамод Садаладж — «Эволюционная архитектура»
От ребят из Thoughtworks. Главная идея: архитектура должна жить и дышать, а ключ к этому fitness functions, которые автоматически проверяют, не ушли ли вы в отрыв от заданных характеристик системы. По сути, авторы предлагают заменить скучные code review и архитектурные комитеты железобетонной автоматизацией. Местами книга напоминает экскурсию по инженерной кухне Thoughtworks с разбором реальных кейсов, что реально полезно.

Ли Атчисон — «Architecting for Scale»
Про мышление архитектора: как думать о росте, изменениях и последствиях решений ещё до того, как появляются проблемы.

☠️ Запретный том

Лен Басс, Пол Клементс, Рик Казман — «Software Architecture in Practice»
Сложная, плотная, не развлекательная, но именно она чаще всего оказывается ответом на вопрос «а почему мы вообще так сделали?».

А какие книги или материалы помогли вам больше всего? Делитесь своими рекомендациями в комментариях!

🌍 Kafka и искусство отпускать прошлое

Мы часто рассчитываем, что Kafka «как-нибудь сама разберётся» с хранением данных, а потом внезапно обнаруживаем, что она разобралась, но не совсем так, как мы планировали.

В этом лонгриде Павел Иванов, администратор баз данных, разбирает, как Kafka на самом деле решает, что хранить, что сжимать, а что удалять, и почему политики очистки часто ведут себя не так, как мы ожидаем, когда просто ставим retention и идём дальше писать код.

🏃 Зачем это нужно?
Без понимания очистки люди начинают: хранить лишнее в базе, угрожать жизни брокеров или делать сложную логику на стороне consumer.

🏃 Читайте и наводите порядок в своих данных

👉 Разделяй и властвуй. Но аккуратно

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

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

🏃 Часть 2 — уже на Хабре.