2135
Канал от Python-разработчиков: — востребованные инструменты — system design — softskills — лучшие практики разработки — подготовка к собеседованиям Увеличим твою ценность на рынке IT Для связи @sa_bul
Насколько 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
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
Как метрики помогут улучшить доставку фич?
Ребята из Точки поделились интересным кейсом из своей практики.
Команда чувствовала, что в процессе доставки фич что-то идёт не так, но на ощупь определить узкие места не удавалось. Тогда тимлид начал внедрять метрики — и это показало всем объективную картину происходящего.
В статье автор описывает, какие именно метрики Точка стала отслеживать и что удалось благодаря этому выявить:
🔹 Cycle time
Показал, что задачи надолго зависают на этапе ревью. Проблема оказалась не в самом ревью, а в его ожидании. Решили делать ревью до дейли. Это резко ускорило прохождение задач по пайплайну.
🔹 Time to market
Подсветил разрыв между идеей и релизом. Стало видно, как задачи тормозятся ещё до разработки — из-за блокеров и неготовых требований.
🔹 Процент возвратов с тестирования
Вскрыл высокий уровень багбэков. Причина — потеря контекста и отсутствие автотестов. После внедрения автотестов возвратов стало меньше, и задачи стали доходить до продакшена с первого раза.
🔹 Распределение времени по типам задач
Дало понимание, как балансируется работа между багами, фичами и техдолгом. Например, если количество багов растёт, а времени на них почти нет — это сигнал, что воронка вот-вот начнёт захлёбываться.
Метрики не спасут, если процессы разваливаются, но без них ты просто не узнаешь, где именно всё ломается. Ребята из Точки не только поняли это, но и показали на реальных цифрах. Очень годный кейс — стоит почитать.
Реклама «АО Точка», tochka.com, 18+
Оперативный постмит
Качественная встреча всегда завершается постмитом. Я обычно тезисно фиксирую ключевые моменты в своих заметках по ходу обсуждения. В конце озвучиваю их вслух для подтверждения, затем немного шлифую текст и отправляю участникам в мессенджер.
Недавно подсмотрел, как мой коллега во время встречи сразу шарит экран и на ходу фиксирует постмит: решения, экшн-поинты, ответственных, сроки.
Это оказалось супер удобно:
– Сразу видно, что записывается, а участники могут поправить, уточнить, добавить
– Все сразу понимают, кто на ком стоял, кто за что отвечает
– Не нужно тратить время после встречи и что-то дооформлять
– Шаблон постмита позволяет ускорить процесс ещё больше
#devfm
fd – удобная альтернатива find
Если используете на практике find, то посмотрите на fd.
Работает быстрее, флаги более лаконичные и поведение по умолчанию разумнее. Вот пару примеров:
🔹 fd сам ищет файлы в текущем каталоге (не нужно писать .) и не требует флага -name
fd txt # Найдет все файлы с "txt" в названии
find . -name "*.txt"
-not -path ‘*/path/*’
Как я провожу синки с тимлидами
Недавно с коллегами заходил разговор за формат синков с тимлидами. Расскажу, как я провожу подобные встречи.
Формат
Обычно, такие встречи проходят раз в неделю. Цель – синхронизация по текущим задачам, проблемам и приоритетам.
Каждый синк – отдельная повторяющаяся приватная таска в таск трекере (как я веду задачи писал тут), либо приватная страничка в вики (в нашем случае конфлюенсе), где фиксируется повестка. Важно, что повестку наполняют оба: руководитель и подчиненный.
Структура
Повестка состоит из трёх частей:
1️⃣ Обязательная часть
Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется.
Как правило это:
– Посмотреть action points с предыдущего синка
– Общий статус по задачам в работе
Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы.
2️⃣ Опциональная часть
Эта такой живой раздел. Сюда каждый из участников записывает темы/вопросы, накапливающиеся в течение недели. Темы могут быть самыми разными: какой формат перфоманс ревью в этом полугодии, обсудить новую идею по изменению шаблонного сервиса, внедрение новых метрик и т.д.
3️⃣ Action points
Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных.
Соответственно, такой скелет повестки с пояснениями по каждому разделу создается для каждой встречи и наполняется в течение недели.
Почему именно так?
Кому-то может показаться, что такой формат слишком бюрократичен. И в целом, когда у тебя пара подчиненных, действительно можно держать многое в голове, но когда их становится больше, то подобный формат мне дает:
✅ прозрачное отслеживание всех вопросов и договоренностей
✅ возможность накидывать темы заранее, не теряя их
✅ отсутствие стихийных созвонов, когда появляется какой-то вопрос. Всегда есть понятное место, куда его можно припарковать
✅ наличие повестки заранее, что позволяет лучше подготовиться к встрече
✅ лучше работает на асинхронное взаимодействие – если какая-то тема потеряла актуальность за неделю, можно просто её удалить, не тратя время на обсуждение
О применении ТГ для асинхронной работы была отдельная статья.
#teamwork #devfm
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
Получил рассылку от Postgres с интересным докладом: Механизмы секционирования больших таблиц, который будет проводиться 25 марта, то есть завтра. Записался, надеюсь, что это не маркетинговый доклад, а то среди тем заявлен pgpro_autopart, а это уже часть Postgres Pro. Посмотрим, что расскажут.
Читать полностью…
Postgres — как делать не надо
В вики Postgres есть отличный гайд с десятками полезных советов о том, как не стоит делать — и, самое главное, объяснениями, почему так делать плохо и как делать правильно.
Вот несколько интересных моментов:
— Не используйте char(n) — у нас был отдельный пост о разнице между char, varchar и text.
— Не используйте serial
— Не используйте NOT IN
— Не используйте timestamp без timezone
#database
Value Stream Mapping
В рамках анализа затыков в процессе поставки релизов наткнулся на статью, рассказывающую о Value Stream Mapping (VSM).
Value Stream Mapping — метод визуализации процесса работы. Он помогает увидеть весь процесс от начала написания кода до деплоя в прод, выявить узкие места и наметить улучшения.
Но, прежде чем строить карту потока, важно понять, зачем мы это делаем. Здесь помогает Outcome Mapping:
1. Собираем ключевых участников.
2. Формулируем, какую стратегическую задачу мы хотим решить.
3. Записываем проблемы, вопросы, идеи.
4. Группируем их, выбираем главную область для улучшения.
5. Формулируем конкретный и измеримый результат.
В статье ещё приводится несколько конкретных примеров Outcome mapping.
Теперь можно перейти к построению VSM.
Что нужно отразить на карте:
— Ключевые шаги — от написания кода до деплоя, тут важно выбрать для себя достаточный уровень детализации процесса, но это можно сделать только эмпирическим путем.
— Задержки — проанализировать и отразить места, где работа простаивает.
— Хенд-оффы — уделить особое внимание на передачу задачи между командами, например, между анализом и разработкой.
— Время ожидания — время, когда кто-то на каком-то этапе кого-то ждет
В целом и раньше подобное делали, но не использовали какую-то конкретную практику. Теперь попробуем применить. Расскажите, применяете ли вы что-то подобное на практике? Как ищете узкие места?
На тему ускорения процесса доставки у нас был пост, где мы анализировали источники багов.
А сократить путь бага нам помогает табличка с зонами ответственности.
#systemdesign
В продолжение поста про правила коммуникации от 37signals
Пример из практики.
На одном из проектов, где была сильная и слаженная команда, произошел сбой. Разработчик работал по системным требованиям, но в какой-то момент что-то стало непонятно. Он написал системному аналитику в личке, они быстро обсудили вопрос, договорились и разработчик продолжил работу.
И это катастрофа. По факту — частная договоренность, которую никто больше не видел, без фиксации в соответствующих артефактах.
Но это сейчас я рассказываю так всё коротенько. Когда через некоторое время словили проблему, команде пришлось разбираться, кто на ком стоял. В итоге вывели два простых правила:
— Никаких обсуждений в личке. Все вопросы в рабочем мессенджере, в тредах. Там можно публично обсудить проблему, привлечь других участников команды для принятия решения.
— Не начинаем работу без фиксации. Решения должны быть отражены в системных требованиях. Эти артефакты — основа, которую используют все: разработчики, тестировщики и аналитики.
Но самое интересное в другом. Эти правила уже были в команде, но инцидент показал, что они плохо зафиксированы или донесены до новых сотрудников.
Главный урок тут такой: нужно регулярно проверять принятые практики и процессы. Убеждаться, что они работают как надо, и команда о них знает.
#devfm #teamwork
The 37signals Guide to Internal Communication
Мы уже писали про замечательную книгу Getting Real от ребят из 37signals.
Давно хотел написать про ещё один классный гайдлайн от ребят — The 37signals Guide to Internal Communication.
Мы внедряем различные практики разработки — как пишем код, какие линтеры используем, как проводим ревью и т.д. А вот как правильно коммуницировать, чтобы были единые, всем понятные правила? На моей практике с этим аспектом не всё так гладко.
В гайде вас ждёт набор очень ёмко сформулированных правил коммуникации. Приведу без перевода особенно откликнувшиеся мне:
— Real-time sometimes, asynchronous most of the time.
— Meetings are the last resort, not the first option.
— Speaking only helps who’s in the room, writing helps everyone.
— If your words can be perceived in different ways, they’ll be understood in the way which does the most harm.
— Never expect or require someone to get back to you immediately unless it’s a true emergency. The expectation of immediate response is toxic.
— Five people in a room for an hour isn’t a one hour meeting, it’s a five hour meeting. Be mindful of the tradeoffs.
— “Now” is often the wrong time to say what just popped into your head. It’s better to let it filter it through the sieve of time. What’s left is the part worth saying.
— Urgency is overrated, ASAP is poison.
— Ask if things are clear. Ask what you left out. Ask if there was anything someone was expecting that you didn’t cover. Address the gaps before they widen with time.
#teamwork #edu
Таки посмотрите на uv
Мы уже писали о быстром пакетном менеджере для Python — uv. Кто-то уже успел его пощупать? Я затащил его в несколько своих проектов — полёт нормальный. В продакшн хотели затащить, но так и не нашли весомых причин.
На днях вышла статья — A year of uv: pros, cons, and should you migrate. Автор в восторге от uv, и когда постарался упомянуть минусы, то даже от них скорее в восторге. В итоге текст — отличный вариант вдохновиться на использование этого инструмента. А если хотите узнать про подводные камни — залетайте в комменты, там автору уже насували.
#tools #python
Пятничное развлекательное
No Vehicles in the Park — необычная инди-игра, которая на самом деле не про транспорт, а про контент-модерацию.
Как установить простые правила для сложных явлений? Где границы допустимого? И можно ли вообще создать систему, которая не сломается об исключения и контекст?
Разработчик вдохновился гипотетическим кейсом "No vehicles in the park" (H.L.A. Hart, 1958) и решил показать, что контент-модерация — это не просто вопрос скорости обработки жалоб, а фундаментальная проблема неопределённости.
В итоге получился интерактивный эксперимент: какие "транспортные средства" вы запретите в парке? Где проходит грань между велосипедом и инвалидной коляской, игрушечной машинкой и электросамокатом?
Стоит ли пытаться вписать хаос в жёсткие правила или проще отказаться от модерирования совсем?
#fun #edu
Годные авторские каналы
Сегодня хочу поделиться с вами каналами, которые сам читаю с завидной регулярностью, чтобы быть в курсе происходящего вокруг.
– Сиолошная: отсюда узнаю подробности о событиях в мире ml
– Системный сдвиг: тема системного анализа и любого другого анализа близка к разработке, и здесь черпаю информацию о происходящем в мире анализа
– Инжиниринг Данных: тут все просто, автор рассказывает за инжиниринг данных
– addmeto: узнаю о действительно значимых и интересных событиях в мире технологий
– Книжный куб: интересные разборы книг и white papers, беру на заметку, что стоит прочитать
– Чем докажешь и Кнопочка: в области ui/ux существует много интересных исследований, а ещё иногда нужно поставить на место самоуверенного дизайнера
И совсем немного около развлекательного:
– Эргономика жилья: я достаточно сильно заморачиваюсь по комфорту и удобству быта, а этот канал как раз посвящен эргономике вокруг нас
– Ряды Фурье: ребята простым языком раскрывают сложные научные и технологические темы. Позабавила их реклама на Таймс-сквер в Нью-Йорке
– Игорь Кузнецов о темных паттернах: отсюда узнаю, какие дикости творят продакты в своих продуктах, дабы добиться желаемого результата и подкрутить нужные продуктовые метрики
Ну, а как организовать этот бесконечный поток информации в телеграме у нас был отдельный пост.
Если ведёте классный авторский канал – делитесь в комментах.
Пятничное развлекательное
Недавно вышла забавная заметка. Ребята из Soundslice делают онлайн-сканер нот: загружаешь снимок партитуры, система распознаёт ноты и тут же проигрывает музыку.
В какой-то момент они обратили внимание на ошибки в логах. Вместо обычных снимков нот туда заливали ASCII-табулатуру из ChatGPT. После небольшого расследования выяснилось, что модель советовала пользователям загружать табы в Soundslice для воспроизведения. А самое забавное – то, что такой функции у ребят никогда не было: ChatGPT её просто выдумал.
Команда встала перед дилеммой: разрабатывать ли эту фичу или просто оповещать пользователей о том, что такая функция не поддерживается. В итоге фичу реализовали.
Получилась забавная и немного странная история: фича родилась не из потребностей пользователей, а из-за галлюцинации ChatGPT.
#ai
Советы, как сделать полезный дашборд
На практике часто видел, что в команде есть какие-то дашборды, но кто ими пользуется, что на них можно увидеть – непонятно.
В статье автор делится советами, как превратить набор красивых графиков в полноценный рабочий инструмент команды.
Дашборд должен отвечать на вопросы
Представьте, что человек открывает дашборд, чтобы получить конкретный ответ: Насколько выросло CPU-потребление у сервиса X? Сколько заявок мы обрабатываем за сутки? Какая температура в серверной прямо сейчас? Если панель не помогает ответить – что-то не так.
Относитесь к дашборду, как к продукту
– ЦА. Дежурный SRE, разработчик, топ-менеджер?
– CJM. Куда пользователь пойдёт после просмотра? Лог, alert, соседний дашборд?
– Условия использования. Инцидент на ноутбуке, большой монитор в опен-спейсе, недельный отчёт?
– Что улучшилось после изменений. Например, добавил спарклайн -> дежурный быстрее ловит аномалию
Проверяйте на целевой аудитории
Задайте дежурному реальный вопрос («Почему вырос latency?»). Посмотрите, как он ищет ответ. Соберите обратную связь, доработайте.
Показывать дашборд случайным коллегам бесполезно – у них другие задачи.
Правила восприятия
– Читаем сверху вниз, слева направо – важное размещайте в левом верхнем углу.
– Большая панель = важная метрика. Мелкие блоки – второстепенное.
– Цвет привлекает внимание: используйте принцип светофора (красный – критично, желтый – предупреждение, зелёный – норма, синий – справочная инфа, серый – неактивно / неизвестно)
Не перегружайте
– Панель должна умещаться на экране без прокрутки
– Не больше 30 линий на графике. В остальных случаях – top-10 и детальный дашборд по клику
– Не больше 3 типа визуализации на странице – иначе когнитивная нагрузка растёт
– Толщина линий ≥ 2 px – их будет видно даже на созвоне
– Null-значения не соединяйте – разрывы важны для диагностики
– Стекирование используйте аккуратно и делать максимально непрозрачную заливку
Документируйте панели
– Заполняйте Description (поддерживает Markdown)
– Выводите в названии переменные Grafana – сразу видно контекст
– Добавляйте ссылки в настройки панели на инструкции и релевантные дашборды
– Добавляйте легенду и следите за ее читабельностью
Оптимизируйте данные
Старайтесь отфильтровать максимальное количество данных на стороне источника, чтобы не перегружать клиент
Осторожно с готовыми дашбордами из интернета
Красиво – не значит полезно. Пройдитесь по каждой панели, поймите логику, только потом ставьте в свой контур. Ошибка всплывет в самый неудобный момент – во время аварии.
Как проводить встречи эффективно
Существуют общепринятые практики организации встреч, но в больших командах даже очевидные правила теряются. Один из лидов недавно задокументировал процесс в виде чеклиста. Этот чеклист выравнивает подходы всей команды и повышает эффективность встреч. Публикую сокращенную версию.
Подготовка
– Избегай звонков без необходимости – большинство вопросов решаются в чате
– Не дергай “на минутку” – если прод не упал, значит не срочно
– Анонсируй: кто, когда, зачем. Иногда достаточно треда в чате
– Проверяй доступность участников через календарь
– Ограничивай время – 30 минут обычно хватает, 1 час — максимум
– Готовь повестку заранее: тема, пункты обсуждения, цель встречи, уважай чужое время
– Рассылай материалы и документы до встречи
– Предупреждай об отмене или задержке как можно раньше
– Опаздываешь? Не опаздывай 🙂
Старт встречи
– Начинай вовремя – без «ждём ещё кого-то»
– Проверь комнату ожидания и список участников
– Напомни повестку – это фокусирует команду
Фасилитация
– Держись повестки и возвращай к цели встречи
– Дай слово молчунам, притормози болтунов.
– Подводи итоги каждые 10–15 минут: «Итак, договорились, что…»
– Следи за чатом и поднятыми руками
– Делись экраном, глаза – тоже канал восприятия
– Включай камеру по возможности
– Не перебивай – сначала дослушай, потом задавай вопросы.
– Паркуй спорные темы после трёх заходов
– Уважай выделенный слот – если нужно больше времени, спроси
– Веди пост-мит в реальном времени
После встречи
– Напиши постмит, опубликуй до конца дня, тегнув участников
#devfm
Про шардирование Postgres и иллюзию ACID
Известно, что шардирование PostgreSQL – задача не из простых. Ребята из YDB в своей статье подсветили один важный нюанс.
Пока вы работаете с одним шардом – всё как в обычном Postgres. Но как только транзакция затрагивает больше одного шарда – вы рискуете столкнуться с неожиданностями. Например, можно получить ситуацию, когда данные на одном шарде уже обновились, а на другом – ещё нет. И тогда тот, кто читает эти данные, может увидеть нечто странное. Как в примере из статьи: Вася проверяет семейный счёт и видит, что на нём 150 рублей, хотя на самом деле должно быть 200. Просто один из шардов уже принял изменения, а второй ещё не успел.
Это происходит потому что двухфазный коммит даёт только атомарность, а не изоляцию. Распределённый снепшот тут не делается, и гарантии ACID превращаются в AC_D.
В общем, если планируете делать широкие транзакции не забывайте об этом факте.
#database
Пятничное развлекательное
Уходящей эпохе Stackoverflow посвящается.
#fun
Пятничное развлекательное
Давным давно у нас был пятничный пост об идеальном языке программирования 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.
Diagrams
Нравится мне python, а если с его помощью ещё и архитектурные диаграммы рисовать — вообще красота. Поэтому принес ещё один инструмент, позволяющий кодом на питоне создавать архитектурные схемы. В примерах можно посмотреть как это выглядит: тут и тут.
Затащить в полноценное использование командами такой инструмент у меня, конечно, не получится (да и смысла большого нет), но развернуть локально и потыкать интересно. На практике мы используем Structurizer. А ранее у нас был пост, зачем мы документируем архитектуру.
#tools
Markwhen — для построения роадмапов
Обычно построением роадмапов занимаются руководители проектов, но иногда это нужно и тимлидам или другим техническим руководителям.
Хочу поделиться гиковским опенсорсным инструментом — Markwhen.
Markwhen позволяет строить роадмапы с использованием синтаксиса Markdown и хранить их в git. Из минусов обнаружил невозможность выставлять зависимости между колбасками.
Вот тут можно потыкать инструмент, посмотреть на его возможности, синтаксис и способы визуализации. А тут документация.
Также у ребят есть всевозможные расширения в том числе для Obsidian и VSCode.
#tools
Backup: архитектура систем
Про system design часто пишут в контексте подготовки к собеседованиям. Мы же в первую очередь пишем про практический аспект — зачем архитектура вообще, как её описывать, какими инструментами мы пользуемся, как вообще процесс можно организовать.
— Для чего нужны архитектурные схемы
— Как документировать архитектуру
— Google design docs
— C4 model для документирования архитектуры
— Анализ источника багов как начало улучшения процессов работы в команде
— Фиксируем зоны ответственности проекта
— визуализируем работу с помощью Value Stream Mapping
Это продолжение цикла тематических подборок. Предыдущая подборка материалов по базам данных.
#backup #systemdesign
"All you need is Postgres" – наверняка слышали этот боевой клич
Недавно наткнулся на целый репозиторий, где собрали кучу интересных задач и способов их решения прямо в Postgres.
Репозиторий оказалася очень залипательным, можно походить по ссылочкам, узнать какие штуки бывают. Так, например, узнал про PGlite — Postgres in WASM. Просто берёшь и запускаешь базу прямо в браузере. Без всяких линуксовых виртуальных машин. Ну очень интересно!
Конечно, не стоит пытаться решать все проблемы с помощью Postgres, но ситуации бывают разные и знать о таких штуках может быть полезно.
#database
Осенью я посещал конференцию ArchDays и уже делился впечатлениями — восторга она у меня не вызвала. Однако было два доклада, которые мне понравились. Организаторы выложили записи в открытый доступ, и я с удовольствием делюсь этими докладами — они точно заслуживают внимания.
▫️Замечательный своей концептуальностью доклад Александра Поломодова “Архитектура в Т-Банке: вчера, сегодня, завтра”
▫️И очень практический доклад Виталия Минко “Архитектурные практики на практике”
#youtube
Пятничное развлекательное
Ребята из Ряды Фурье рассказали о супер интересных исследованиях: оказывается, можно "напихать" трезвому здоровому человеку новые воспоминания!
А ещё у них был пост о том, что человеческая память — это нечто вроде write-only: записать можно, но вот прочитать — только с искажениями и перезаписью.
#fun
Как проводить skip level 1-1
Любопытная статья, посвящённая проведению 1-1 встреч с коллегами на два и более уровня ниже вас. Такие встречи называются один-на-один, или one-to-one, сокращённо 121.
Я не знаю термина, обозначающего такие встречи на русском языке, но в английском есть емкое название skip level 1-1.
С моей точки зрения, начало статьи достаточно банальное, но в разделе с советами автор даёт несколько действительно полезных рекомендаций.
По части организации таких встреч:
— Встречи должны быть прозрачными. Важно заранее обозначить для собеседника формат встречи, её цели, подготовить примерный набор вопросов и ожиданий от встречи.
— Желательно, чтобы такие встречи проводились регулярно. Это позволит избежать нежданчиков и стресса для коллег.
— Руководители людей, с кем вы проводите встречи, также должны быть в курсе таких встреч и их целей.
По части проведения встреч:
— Добавьте в общение какой-то персонализации, заранее узнайте что-то о человеке и его достижениях, это позволит установить более тёплые и честные взаимоотношения.
— Вопросы должны быть конкретными. Если задавать абстрактные вопросы, то ответы, скорее всего, будут размытыми, вроде "да, в целом, всё нормально".
— На таких встречах можно получить фидбек из первых уст по внедрённым недавно изменениям или новым практикам. Также может оказаться, что какие-то инициативы были внедрены, но сотрудники либо понимают их по-разному, либо вообще не в курсе. В итоге получается такой отличный heartbeat.
— На таких встречах можно получить фидбек об их руководителе (вашем подчинённом), чтобы посмотреть на работу вашего непосредственного подчинённого под другим углом.
— Фиксируйте повторяющиеся темы и паттерны. Если одна и та же проблема всплывает у разных людей, это важный сигнал.
Статья не затрагивает тему, что делать с полученной информацией, но это, пожалуй, выходит за рамки заявленной темы.
#teamwork #edu
Обзор способов защиты контейнеров Docker
Докеры мы любим, а думать о безопасности докеров — не всегда.
Неплохая обзорная статья о том, что вы можете сделать для повышения безопасности, чтобы не попасть впросак :)
Автор начинает с актуальности в виде известных инцидентов за 2024 год и, в целом, видов угроз для контейнеров.
Итак, переходим к делу:
🔹 Ограничивайте привилегии контейнеров — по умолчанию они могут запускаться с избыточными правами, что создает новые вектора для атак. Отключайте ненужные привилегии.
🔹 Запускайте rootless-контейнеры — пусть они работают от имени обычного пользователя, а не от root'а.
🔹 Настраивайте сетевую изоляцию — не давайте контейнерам бесконтрольно общаться друг с другом и с внешним миром. Чётко определяйте, кто с кем может взаимодействовать.
🔹 Используйте специальные инструменты — AppArmor, Seccomp и SELinux, они помогут ограничивать системные вызовы и предотвращать несанкционированный доступ к критическим ресурсам.
🔹 Сканируйте образы на уязвимости — Trivy, Docker Scout и аналогичные инструменты помогут обнаружить проблемные зависимости ещё на этапе сборки. Встраивайте эти инструменты в свой CI/CD.
🔹 И, самое базовое, что может делать каждый разработчик — минимизируйте образы, убирайте лишние зависимости, не тяните за собой ненужные файлы, следите за обновлениями базовых образов, запускайте контейнеры от не привилегированных пользователей.
#tools #docker
Простой приём: Как ускорить принятие решений в команде
Если вы руководите людьми, то наверняка сталкивались с ситуацией, когда два специалиста застревают в споре. У каждого есть свои правильные аргументы, но к какому-то окончательному решению прийти не могут.
В этом случае может помочь простой приём — попробуйте предложить радикальное, обоим сторонам неудобное решение.
Приведу пример:
Мы недавно стартовали проект. В качестве базы использовали Postgres. Но так получилось, что новые требования не укладывались в текущую модель данных, обсуждали трейдофы, на которые нужно идти. Время поджимало, обсуждение затянулось на час. Конечно, если обсуждение длится час — его пора заканчивать.
И в один момент я абсолютно серьёзно предложил использовать нереляционную базу. Также серьёзно обосновал своё предложение, почему это может быть хорошим вариантом. И тут случилось чудо – уже через минуту инженеры дружно доказывали мне, что это плохая идея, а заодно быстро пришли к устраивающему всех решению.
В итоге решение найдено, хотя в глазах ребят я предлагаю очень странные идеи.
#teamwork #devfm