"All you need is Postgres" – наверняка слышали этот боевой клич

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

Репозиторий оказалася очень залипательным, можно походить по ссылочкам, узнать какие штуки бывают. Так, например, узнал про PGlite — Postgres in WASM. Просто берёшь и запускаешь базу прямо в браузере. Без всяких линуксовых виртуальных машин. Ну очень интересно!

Конечно, не стоит пытаться решать все проблемы с помощью Postgres, но ситуации бывают разные и знать о таких штуках может быть полезно.

#database

Value Stream Mapping

В рамках анализа затыков в процессе поставки релизов наткнулся на статью, рассказывающую о Value Stream Mapping (VSM).

Value Stream Mapping — метод визуализации процесса работы. Он помогает увидеть весь процесс от начала написания кода до деплоя в прод, выявить узкие места и наметить улучшения.

Но, прежде чем строить карту потока, важно понять, зачем мы это делаем. Здесь помогает Outcome Mapping:
1. Собираем ключевых участников.
2. Формулируем, какую стратегическую задачу мы хотим решить.
3. Записываем проблемы, вопросы, идеи.
4. Группируем их, выбираем главную область для улучшения.
5. Формулируем конкретный и измеримый результат.

В статье ещё приводится несколько конкретных примеров Outcome mapping.

Теперь можно перейти к построению VSM.
Что нужно отразить на карте:
— Ключевые шаги — от написания кода до деплоя, тут важно выбрать для себя достаточный уровень детализации процесса, но это можно сделать только эмпирическим путем.
— Задержки — проанализировать и отразить места, где работа простаивает.
— Хенд-оффы — уделить особое внимание на передачу задачи между командами, например, между анализом и разработкой.
— Время ожидания — время, когда кто-то на каком-то этапе кого-то ждет

В целом и раньше подобное делали, но не использовали какую-то конкретную практику. Теперь попробуем применить. Расскажите, применяете ли вы что-то подобное на практике? Как ищете узкие места?

На тему ускорения процесса доставки у нас был пост, где мы анализировали источники багов.
А сократить путь бага нам помогает табличка с зонами ответственности.

#systemdesign

Backup: архитектура систем

Про system design часто пишут в контексте подготовки к собеседованиям. Мы же в первую очередь пишем про практический аспект — зачем архитектура вообще, как её описывать, какими инструментами мы пользуемся, как вообще процесс можно организовать.

— Для чего нужны архитектурные схемы
— Как документировать архитектуру
— Google design docs
— C4 model для документирования архитектуры
— Анализ источника багов как начало улучшения процессов работы в команде
— Фиксируем зоны ответственности проекта
— визуализируем работу с помощью Value Stream Mapping

Это продолжение цикла тематических подборок. Предыдущая подборка материалов по базам данных.

#backup #systemdesign

Postgres — как делать не надо

В вики Postgres есть отличный гайд с десятками полезных советов о том, как не стоит делать — и, самое главное, объяснениями, почему так делать плохо и как делать правильно.

Вот несколько интересных моментов:
— Не используйте char(n) — у нас был отдельный пост о разнице между char, varchar и text.
— Не используйте serial
— Не используйте NOT IN
— Не используйте timestamp без timezone

#database

Markwhen — для построения роадмапов

Обычно построением роадмапов занимаются руководители проектов, но иногда это нужно и тимлидам или другим техническим руководителям.

Хочу поделиться гиковским опенсорсным инструментом — Markwhen.

Markwhen позволяет строить роадмапы с использованием синтаксиса Markdown и хранить их в git. Из минусов обнаружил невозможность выставлять зависимости между колбасками.
Вот тут можно потыкать инструмент, посмотреть на его возможности, синтаксис и способы визуализации. А тут документация.

Также у ребят есть всевозможные расширения в том числе для Obsidian и VSCode.

#tools

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

Diagrams

Нравится мне python, а если с его помощью ещё и архитектурные диаграммы рисовать — вообще красота. Поэтому принес ещё один инструмент, позволяющий кодом на питоне создавать архитектурные схемы. В примерах можно посмотреть как это выглядит: тут и тут.

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

#tools

Life Altering Postgresql Patterns

Постгрю я, конечно, люблю не так сильно, как питон, но всё равно периодически посматриваю на хорошие практики.

В статье автор дает несколько полезных советов при работе с постгрей. За некоторым исключением, во многом с ним согласен.

🔹 UUID вместо автоинкремента — если работаешь с распределёнными системами или API, лучше сразу использовать uuid DEFAULT gen_random_uuid(). Избавит от проблем с конфликтами ID

🔹 created_at / updated_at — каскадное удаление может привести к неожиданным потерям данных. Лучше контролировать процесс вручную

🔹ON DELETE RESTRICT вместо CASCADE — защищает от случайного удаления связанных данных. Лучше удалять вручную при необходимости

🔹Используйте схемы — не нужно всё пихать в public, схемы помогают логически разделить данные

🔹Таблицы вместо ENUM — если нужно хранить фиксированный набор значений, лучше делать это в отдельной таблице. Всегда так делал, а ещё удивляюсь, что иногда енамки хранятся на уровне кода

🔹Таблицы в единственном числе — user вместо users. Логичнее: одна строка = один объект. Хотя наверняка найдутся сторонники другого подхода

🔹Soft delete вместо удаления — автор убеждён, что хранение дешевле, чем восстановление данных, и почти всегда рекомендует soft delete (deleted_at TIMESTAMP NULL)

🔹 JSONB вместо сложных JOIN'ов — удобно для метаданных и настроек, если структура может меняться. Но я бы тут осторожно подходил к такому решению. Например, что будет со старыми данными, если формат json поменяется? А не будет ли проблем с TOAST? На эти темы у нас были отдельные посты: раз, два

🔹Понятные имена join-таблиц — просто объединяйте имена связываемых таблиц и не городите чего-то этакое

#database

Пятничное развлекательное

Давным давно у нас был пятничный пост об идеальном языке программирования DreamBerd.

Прогресс не стоит на месте, один из наших подписчиков поделился ссылкой на интерпретатор для DreamBerd.

Особенно мне понравилась выдержка из документации:

It's worth noting that Github Copilot doesn't understand DreamBerd, which means that Microsoft won't be able to steal your code.
This is great for when you want to keep your open-sourced project closed-source.

#fun

Как я провожу синки с тимлидами

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

Формат
Обычно, такие встречи проходят раз в неделю. Цель – синхронизация по текущим задачам, проблемам и приоритетам.
Каждый синк – отдельная повторяющаяся приватная таска в таск трекере (как я веду задачи писал тут), либо приватная страничка в вики (в нашем случае конфлюенсе), где фиксируется повестка. Важно, что повестку наполняют оба: руководитель и подчиненный.

Структура
Повестка состоит из трёх частей:
1️⃣ Обязательная часть
Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется.
Как правило это:
– Посмотреть action points с предыдущего синка
– Общий статус по задачам в работе
Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы.

2️⃣ Опциональная часть
Эта такой живой раздел. Сюда каждый из участников записывает темы/вопросы, накапливающиеся в течение недели. Темы могут быть самыми разными: какой формат перфоманс ревью в этом полугодии, обсудить новую идею по изменению шаблонного сервиса, внедрение новых метрик и т.д.

3️⃣ Action points
Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных.

Соответственно, такой скелет повестки с пояснениями по каждому разделу создается для каждой встречи и наполняется в течение недели.

Почему именно так?
Кому-то может показаться, что такой формат слишком бюрократичен. И в целом, когда у тебя пара подчиненных, действительно можно держать многое в голове, но когда их становится больше, то подобный формат мне дает:
✅ прозрачное отслеживание всех вопросов и договоренностей
✅ возможность накидывать темы заранее, не теряя их
✅ отсутствие стихийных созвонов, когда появляется какой-то вопрос. Всегда есть понятное место, куда его можно припарковать
✅ наличие повестки заранее, что позволяет лучше подготовиться к встрече
✅ лучше работает на асинхронное взаимодействие – если какая-то тема потеряла актуальность за неделю, можно просто её удалить, не тратя время на обсуждение

О применении ТГ для асинхронной работы была отдельная статья.

#teamwork #devfm

Пятничное развлекательное

Уходящей эпохе Stackoverflow посвящается.

#fun

fd – удобная альтернатива find

Если используете на практике find, то посмотрите на fd.

Работает быстрее, флаги более лаконичные и поведение по умолчанию разумнее. Вот пару примеров:
🔹 fd сам ищет файлы в текущем каталоге (не нужно писать .) и не требует флага -name

fd txt # Найдет все файлы с "txt" в названии

В find пришлось бы писать:

find . -name "*.txt"

🔹по умолчанию игнорирует скрытые файлы. А еще игнорирует то, что у вас лежит в .gitignore. Очень удобно, избавляет от кучи лишних совпадений. В find же нужно указывать

-not -path ‘*/path/*’

🔹можно делать цветной, более наглядный вывод

🔹написан на Rust, ну, сами понимаете – всё работает быстро-быстро 🙂

В ридми у ребят ещё много примеров.

#tools

Про шардирование Postgres и иллюзию ACID

Известно, что шардирование PostgreSQL – задача не из простых. Ребята из YDB в своей статье подсветили один важный нюанс.

Пока вы работаете с одним шардом – всё как в обычном Postgres. Но как только транзакция затрагивает больше одного шарда – вы рискуете столкнуться с неожиданностями. Например, можно получить ситуацию, когда данные на одном шарде уже обновились, а на другом – ещё нет. И тогда тот, кто читает эти данные, может увидеть нечто странное. Как в примере из статьи: Вася проверяет семейный счёт и видит, что на нём 150 рублей, хотя на самом деле должно быть 200. Просто один из шардов уже принял изменения, а второй ещё не успел.

Это происходит потому что двухфазный коммит даёт только атомарность, а не изоляцию. Распределённый снепшот тут не делается, и гарантии ACID превращаются в AC_D.

В общем, если планируете делать широкие транзакции не забывайте об этом факте.

#database

Оперативный постмит

Качественная встреча всегда завершается постмитом. Я обычно тезисно фиксирую ключевые моменты в своих заметках по ходу обсуждения. В конце озвучиваю их вслух для подтверждения, затем немного шлифую текст и отправляю участникам в мессенджер.

Недавно подсмотрел, как мой коллега во время встречи сразу шарит экран и на ходу фиксирует постмит: решения, экшн-поинты, ответственных, сроки.

Это оказалось супер удобно:
– Сразу видно, что записывается, а участники могут поправить, уточнить, добавить
– Все сразу понимают, кто на ком стоял, кто за что отвечает
– Не нужно тратить время после встречи и что-то дооформлять
– Шаблон постмита позволяет ускорить процесс ещё больше

#devfm

Как проводить встречи эффективно

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

Подготовка
– Избегай звонков без необходимости – большинство вопросов решаются в чате
– Не дергай “на минутку” – если прод не упал, значит не срочно
– Анонсируй: кто, когда, зачем. Иногда достаточно треда в чате
– Проверяй доступность участников через календарь
– Ограничивай время – 30 минут обычно хватает, 1 час — максимум
– Готовь повестку заранее: тема, пункты обсуждения, цель встречи, уважай чужое время
– Рассылай материалы и документы до встречи
– Предупреждай об отмене или задержке как можно раньше
– Опаздываешь? Не опаздывай 🙂

Старт встречи
– Начинай вовремя – без «ждём ещё кого-то»
– Проверь комнату ожидания и список участников
– Напомни повестку – это фокусирует команду

Фасилитация
– Держись повестки и возвращай к цели встречи
– Дай слово молчунам, притормози болтунов.
– Подводи итоги каждые 10–15 минут: «Итак, договорились, что…»
– Следи за чатом и поднятыми руками
– Делись экраном, глаза – тоже канал восприятия
– Включай камеру по возможности
– Не перебивай – сначала дослушай, потом задавай вопросы.
– Паркуй спорные темы после трёх заходов
– Уважай выделенный слот – если нужно больше времени, спроси
– Веди пост-мит в реальном времени

После встречи
– Напиши постмит, опубликуй до конца дня, тегнув участников

#devfm

Как метрики помогут улучшить доставку фич?

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


В статье автор описывает, какие именно метрики Точка стала отслеживать и что удалось благодаря этому выявить:

🔹 Cycle time
Показал, что задачи надолго зависают на этапе ревью. Проблема оказалась не в самом ревью, а в его ожидании. Решили делать ревью до дейли. Это резко ускорило прохождение задач по пайплайну.

🔹 Time to market
Подсветил разрыв между идеей и релизом. Стало видно, как задачи тормозятся ещё до разработки — из-за блокеров и неготовых требований.

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

🔹 Распределение времени по типам задач
Дало понимание, как балансируется работа между багами, фичами и техдолгом. Например, если количество багов растёт, а времени на них почти нет — это сигнал, что воронка вот-вот начнёт захлёбываться.

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

Реклама «АО Точка», tochka.com, 18+

Советы, как сделать полезный дашборд

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

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

Дашборд должен отвечать на вопросы
Представьте, что человек открывает дашборд, чтобы получить конкретный ответ: Насколько выросло CPU-потребление у сервиса X? Сколько заявок мы обрабатываем за сутки? Какая температура в серверной прямо сейчас? Если панель не помогает ответить – что-то не так.

Относитесь к дашборду, как к продукту
– ЦА. Дежурный SRE, разработчик, топ-менеджер?
– CJM. Куда пользователь пойдёт после просмотра? Лог, alert, соседний дашборд?
– Условия использования. Инцидент на ноутбуке, большой монитор в опен-спейсе, недельный отчёт?
– Что улучшилось после изменений. Например, добавил спарклайн -> дежурный быстрее ловит аномалию

Проверяйте на целевой аудитории
Задайте дежурному реальный вопрос («Почему вырос latency?»). Посмотрите, как он ищет ответ. Соберите обратную связь, доработайте.
Показывать дашборд случайным коллегам бесполезно – у них другие задачи.

Правила восприятия
– Читаем сверху вниз, слева направо – важное размещайте в левом верхнем углу.
– Большая панель = важная метрика. Мелкие блоки – второстепенное.
– Цвет привлекает внимание: используйте принцип светофора (красный – критично, желтый – предупреждение, зелёный – норма, синий – справочная инфа, серый – неактивно / неизвестно)

Не перегружайте
– Панель должна умещаться на экране без прокрутки
– Не больше 30 линий на графике. В остальных случаях – top-10 и детальный дашборд по клику
– Не больше 3 типа визуализации на странице – иначе когнитивная нагрузка растёт
– Толщина линий ≥ 2 px – их будет видно даже на созвоне
– Null-значения не соединяйте – разрывы важны для диагностики
– Стекирование используйте аккуратно и делать максимально непрозрачную заливку

Документируйте панели
– Заполняйте Description (поддерживает Markdown)
– Выводите в названии переменные Grafana – сразу видно контекст
– Добавляйте ссылки в настройки панели на инструкции и релевантные дашборды
– Добавляйте легенду и следите за ее читабельностью

Оптимизируйте данные
Старайтесь отфильтровать максимальное количество данных на стороне источника, чтобы не перегружать клиент

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

Cursor изнутри
Недавно вышла немного рекламная, но легкая и интересная статья от The Pragmatic Engineer о том, как устроен Cursor узнутри.

В начале статьи просто любопытные цифры о Cursor. Дальше автор рассказывает нам о технологическом стеке. Из интересного:
- TypeScript – бизнес-логика, критические штуки на Rust
- Turbopuffer – основное KV-хранилище, держит зашифрованные файлы + Merkle-деревья для синка
- Pinecone – векторная БД для семантического поиска по коду
- Datadog, PagerDuty, Sentry, Amplitude для обзервабилити
- Linear – для таск трекинга (рекомендую попробовать для тех, кто не пробовал, интересное решение)

Cursor не хранит наш код на своих серверах. Когда вы отправляете запрос в Chat, происходит следующее:
1. Запрос уходит на сервер
2. Сервер решает, что это – вопрос о коде, и запускает векторный поиск по embedding'ам, которые заранее были созданы на сервере во время “индексации” проекта
3. По результатам векторного поиска сервер понимает, какие файлы могут быть релевантны и запрашивает эти конкретные файлы обратно у клиента
4. Клиент шлёт нужные части кода (зашифрованно) – только те, что реально понадобились
5. Сервер “собирает” полный контекст и запускает inference для ответа
6. Ответ возвращается в чат

Отдельно стоит рассказать, как Cursor узнаёт, какие файлы изменились, и переиндексирует только их. Для используются Merkle-деревья:
1. каждый файл разбивается на чанки, каждый чанк хешируется
2. хеши объединяются попарно и формируют узлы следующего уровня
3. в результате строится дерево, корневой хеш которого отражает состояние всего проекта – аналогичное дерево строится и на клиенте, и на сервере

Каждые ~3 минуты клиент сравнивает свой корневой хеш с серверным:
– если хеши совпадают – индекс остаётся прежним
– если отличаются – обход дерева точно выявляет изменённые чанки, и переиндексирует только их

#ai

Пятничное развлекательное

Недавно вышла забавная заметка. Ребята из Soundslice делают онлайн-сканер нот: загружаешь снимок партитуры, система распознаёт ноты и тут же проигрывает музыку.

В какой-то момент они обратили внимание на ошибки в логах. Вместо обычных снимков нот туда заливали ASCII-табулатуру из ChatGPT. После небольшого расследования выяснилось, что модель советовала пользователям загружать табы в Soundslice для воспроизведения. А самое забавное – то, что такой функции у ребят никогда не было: ChatGPT её просто выдумал.

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

Получилась забавная и немного странная история: фича родилась не из потребностей пользователей, а из-за галлюцинации ChatGPT.

#ai

Насколько AI увеличивает продуктивность программистов

Недавно METR опубликовали исследование с интригующими выводами: авторы задаются вопросом, насколько AI‑асисты действительно ускоряют или замедляют работу опытных разработчиков.

Почему привычные метрики не годятся
– Большинство бенчмарков фокусируется на узко поставленных задачах с автоматической проверкой результатов, не требующих контекста больших кодовых баз
– Они не учитывают время на настройку подсказок, исправление неточностей и интеграцию AI‑сгенерированного кода в проект
– В них отсутствует фактор человеческой правки: в реальности мы тратим дополнительное время на доводку и ревью предложений ИИ

Как проходил эксперимент
16 опытных разработчиков из крупных open‑source‑репозиториев (более 22 000 звёзд и 1 млн строк кода) выбрали по 15–20 реальных задач — фиксы багов, новые фичи и рефакторинг. Всего получилось 246 заданий. Каждую задачу случайным образом разрешали выполнять либо с любыми AI‑инструментами, либо без них. Разработчики фиксировали время выполнения каждой задачи.

Ключевой вывод
И вот барабанная дробь: использование AI‑асистов замедляет разработчика на 19%. При этом участники до эксперимента прогнозировали ускорение на 24%, а после всё ещё считали, что AI их реально ускорили.

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

– Ограниченный объём сэмплирования: в бенчмарках модели могут генерировать тысячи вариантов, здесь — лишь несколько
– Крутая кривая обучения: эффект от AI‑инструментов может проявляться после сотен часов практики, а в эксперименте у большинства участников было лишь несколько десятков часов опыта
– Высокие стандарты качества: Open‑source репозитории часто имеют строгие требования к тестам, документации и стилю, что требует дополнительной правки AI‑кода

От себя хочу добавить: AI – не золотая пуля, а набор специализированных инструментов: какие-то классы задач они выполняет хорошо, какие-то хуже. Чтобы получить реальную выгоду, нужно понимать особенность применения этих инструментов. Именно этот момент, на мой взгляд, упущен в исследовании.
Такую же картину я наблюдаю в реальной жизни: некоторые разработчики столкнувшись с тем, что AI не решил задачу под ключ, сразу отказываются от него.

#ai