Павлин Шарит

Как связаны мониторинг и репликация postgres Можно связать по-разному, но в данном случае это последние ролики на бусти, которые вы могли пропустить glances собирает все ключевые метрики в одно окно - cpu, ram, диски, сеть и docker-контейнеры с их потреблением Написан на python, а вы уже знаете, что я люблю утилиты, у которых могу легко прочитать исходный код Из коробки web-режим и экспорт в prometheus/influxdb, так что из дев-утилиты при желании вырастает полноценный мониторинг Вторая тема куда глубже - это цикл роликов про репликацию postgres, тему, которую долго просили на ютубе, а я всё откладывал В первой части зашёл с фундамента - разобрал WAL (write-ahead log), механизм, который гарантирует, что запись в БД не потеряется Прогнал бенчмарк - сколько вывозит одна урезанная postgres в докере (1/2 CPU + 256 mb RAM). Это точка отсчёта, чтобы дальше смотреть, как меняется картина с репликами Прошёлся по типам репликации - физическая против логической, синхронная против асинхронной, кто что гарантирует и чем за это платит Так что прошу к просмотру на бусти: Убийца htop - glances Первая часть про репликацию

На реддите ожидают новую подписку в клоде

Прошел школу CTO от Стратоплана - мысли по итогам Полгода обучения в школе CTO от Стратоплана пролетели незаметно - время подвести итоги С точки зрения контента курс сделал главное - помог систематизировать то, что раньше делал интуитивно Управление ожиданиями, метрики, делегирование, оптимизация процессов - все эти темы я так или иначе встречал в работе, но курс дал общий каркас, в который они теперь укладываются Структурно курс состоит из трех частей. Еженедельные трехчасовые занятия по специализации - именно про работу CTO. Двухдневки - интенсивы по пять часов два дня подряд по конкретным базовым навыкам руководителя (постановка задач, делегирование, найм, метрики). И вебинары - дополнительные встречи с приглашенными спикерами на смежные темы. В сумме получается насыщенно, но не перегружено - примерно один-два вечера в неделю Но самым ценным оказался даже не контент. Каждое занятие включало разбор кейса в якорной команде - группе людей, с которой проходишь весь курс с января по май. Состав получился сильным - все из разных индустрий, размеры команд от 15 до 150+ человек, и одну и ту же проблему каждый разбирает через призму своего опыта. Часто именно в этих обсуждениях рождались инсайты, которые в самих лекциях звучали абстрактно. И отдельный бонус - после курса остается нетворк из людей, с которыми уже проработал десятки кейсов и понимаешь, к кому за чем можно прийти Отдельно отмечу организацию - можно назвать эталонной для образовательного продукта. После каждого занятия собирается обратная связь, и видно, что программа на нее реагирует. Например, первая половина обучения шла в классическом формате теория-практика. К середине курса формат переключили на цикл Колба - сначала ныряем в кейс без теории, потом разбираем в группе что и почему делали, и только потом тренер дает теоретическую рамку. Когда теория ложится на уже прожитый опыт, она усваивается совсем иначе В сухом остатке - очень рекомендую курс тем, кто уже работает на позиции технического руководителя и чувствует, что многое делает интуитивно. Курс не научит управлять с нуля, но если есть опыт и нужно навести порядок в голове, разложить все по полкам и получить недостающие куски паззла - это именно то место

Адаптация телеграмма под ИИ-тренды Прошел уже месяц с крупного обновления телеграмма для поддержки ИИ прямо в мессенджере, и разработчики ботов получили сразу несколько нативных штук, которые раньше приходилось городить руками Из ключевого: - Guest Bots - бота можно вызвать по @username в любом чате, не добавляя его в участники. Один инстанс отвечает хоть в миллионе чатов, при этом видит только те сообщения, где его упомянули, и ответы на них - sendMessageDraft - нативный стриминг ответа, бот публикует черновик и докидывает в него токены по мере генерации - Bot-to-Bot - боты теперь отвечают не только людям, но и друг другу Настал момент, когда боты видят сообщения друг друга, хотя раньше это казалось табу, так как могло зациклить их Теперь можно собирать автономных агентов, которые дергают друг друга как сервисы и автоматизируют процессы И отдельно радует sendMessageDraft - раньше эффект печатающегося текста собирали через edit_message_text. Отправляешь сообщение, а потом на каждый токен правишь его же: msg = await message.answer("…") buffer = "" async for token in stream: buffer += token await msg.edit_text(buffer) await asyncio.sleep(1) # троттлим, иначе rate limit Но надо было учитывать лимиты телеграмм и редачить не чаще раза в секунду Теперь под это есть родной метод. Черновик живет как превью, ты докидываешь в него токены по одному draft_id, а в конце один раз отправляешь финальное сообщение, чтобы оно осталось в чате: buffer = "" async for token in stream: buffer += token await bot.send_message_draft( chat_id=message.chat.id, draft_id=message.message_id, text=buffer, ) await message.answer(buffer) # финал, чтобы остался в чате Так что теперь не будет подергиваний при ответе Приятно видеть, как телеграмм из мессенджера превращается в площадку, где боты (или моднее - агенты) становятся все большей частью экосистемы

LLM gateway Поймал себя на том, что в третьем по счету проекте копирую один и тот же кусок прокси для OpenAI - и понял, что пора это выносить Сейчас сложно найти продукт, в котором нет хотя бы одного обращения к LLM (или БЯМ - большая языковая модель, как же мне нравится эта аббревитура), и вместе с этим остро встает вопрос работы с ключами Понятно, что секреты мы держим в переменных среды или в централизованном хранилище, но когда проектов становится много, этого уже мало - нет единого подсчета токенов, нет централизованного управления, и в каждом сервисе болтается свой кусок логики для общения с провайдером Решается это через AI gateway - по сути как nginx, только стоит не перед бекендом, а перед LLM-провайдером и проксирует все запросы через себя Litellm - open source решение, которое умеет говорить со 100+ провайдерами (OpenAI, Anthropic, Gemini, Bedrock и тд) в едином OpenAI-формате, так что менять провайдера можно прямо в конфиге, не переписывая интеграцию в коде Через конфиги настраиваешь, какие есть провайдеры и их fallback-и на случай, если какой-то ляжет, а заодно получаешь: - retry с настраиваемым числом попыток - load balancing между несколькими ключами или деплойментами одной модели - virtual keys - выдаешь команде или проекту отдельный ключ, не светя реальные ключи провайдеров - лимиты по бюджету и токенам в разрезе проекта или пользователя - кеширование ответов и rate limiting - callbacks для логирования и observability - Langfuse, MLflow и прочие Но что зашло больше всего - можно настроить пред и постобработку запроса, то есть написать кастомные middleware сразу на все запросы - например, вырезать персональные данные перед отправкой в модель и это заработает для всех сервисов разом, а не копипастой в каждом

Мониторинг всех ИИ-лимитов Наткнулся на CodexBar - утилита для macOS, которая собирает лимиты всех провайдеров прямо в menu bar. Узнал про нее, когда увидел, что ей пользуется создатель openclaw, позволяет не прыгать в веб-морду для просмотра или спамить /usage Что умеет: - 40+ провайдеров - claude, codex, cursor, copilot, gemini, openrouter, deepseek, warp и далее по списку - Окна сброса сессий, недельные и месячные лимиты с таймером обратного отсчета - не надо гадать, успеешь ли стартануть длинную задачу до сброса - Балансы кредитов и месячные расходы там, где провайдер их отдает - Локальное сканирование стоимости для codex и claude - Бесплатно и open source Приятный момент по приватности - утилита переиспользует существующие сессии провайдеров: oauth, device flow, api-ключи, cookies, локальные файлы. Никакие пароли нигде не хранятся Ставится одной командой через homebrew: brew install --cask steipete/tap/codexbar По статистике я в клоде сейчас трачу токенов на 1500$ в месяц, а у вас сколько получается?

60% времени задачи - это ожидание, а не работа Финальный блок школы CTO от Стратоплана - шесть занятий про операционный менеджмент: оргструктуры, построение и оптимизация бизнес-процессов, метрики, инфраструктура и закупки. Этот блок не столько про новые концепции, сколько про то, как собрать уже знакомые вещи в систему более высокого уровня Оргструктуры Нет одной правильной оргструктуры на всю компанию. Каждый вид решает свою задачу: функциональная дает специализацию и качество экспертизы, проектная фокусирует команду на delivery, матричная балансирует первое и второе, дивизионная позволяет масштабироваться и автономно развивать отдельные продукты. Внутри одной компании разные подразделения могут жить в разных структурах. И отдельно важно отделять роль от сотрудника - роль это набор функций, а закрывать ее может один человек, несколько или целая команда Построение процессов Базовая модель "Цель-Ограничение-Зависимость" - для любого процесса задаем три вопроса: зачем он существует, что нельзя нарушать и от чего он зависит. Отдельно стоит запомнить разницу process-first и work-first подходов. Первый - сначала проектируем, потом запускаем, долго и контролируемо. Второй - сначала работаем, потом фиксируем, быстро и гибко, но есть риск зафиксировать и неудобства Оптимизация процессов Структура времени выполнения задачи - рабочее время 10-20%, ожидание 60-70%, принятие решений 20%. Когда хотят ускорить delivery, инстинктивно лезут в рабочее время, хотя весь резерв в ожиданиях. И ожидание это не простой человека, а ожидание других - код-ревью, согласования архитектуры, прохождение тестирования, ответа от заказчика Из этой же темы три понятия из Lean, которые дают язык для разговора о потерях: - Mura (неравномерность) - когда одна задача делается 3 дня, а похожая 15. Замеряется отношением p90 к медиане времени выполнения, если больше трех - поток рваный - Muri (перегруз) - когда люди работают на пределе. Замеряется количеством задач в работе на человека и тем, как давно они висят без движения - Muda (потери) - все, что съедает ресурсы без создания ценности: переделки, лишние согласования, ожидания на стыках Метрики и KPI Пирамида из четырех уровней - сотрудники, процессы, продукт, финансы. Каждый нижний уровень это прогноз верхнего. Текущее состояние проектов прогнозирует удовлетворенность клиентов, а удовлетворенность прогнозирует финансы Важно, чтобы метрики уравновешивали друг друга, если ставим метрику на количество, обязательно нужна балансирующая метрика на качество. Иначе получаем разработчиков, которые закрывают много задач, но половина возвращается с багами. Velocity идет в паре с индексом качества, звонки менеджера - с конверсией, скорость найма - с прохождением испытательного срока Инфраструктура и софт Разбирали интеграционный сценарий - когда нужно встроить что-то новое в существующий ландшафт после поглощения или миграции. Понравилось правило "Ядро vs Контекст" - конкурентное преимущество разрабатываем сами, вспомогательное берем у подрядчиков. И матрица решений по legacy-сервисам по осям бизнес-ценность и техническое состояние - что-то отключаем, что-то оптимизируем, что-то переписываем, во что-то инвестируем Закупки Главный тезис - правильный контракт это 80% качественной закупки. Три типа под разные ситуации: fixed price для тендеров и фиксированного скоупа, cost plus fee для сторонних сервисов и инфраструктуры, time and materials для agile и плавающего скоупа. И сильная мысль про контроль подрядчиков - роадмапы и ганты не работают, работает фактура: метрики, демо и доска или код. Все остальное это интерпретация подрядчика Книги, которые попали в обойму на прочитать после этого блока: - Э. Голдратт "Цель" - Дж. Лайкер "Дао Toyota" - У. Эдвардс Деминг "Выход из кризиса"

Skills vs Commands vs Sub-agents - что выбрать В Claude Code есть три способа упаковать переиспользуемый воркфлоу, и они начинают конкурировать друг с другом, как только проект вырастает за пределы пары файлов. Разбираем чем они реально отличаются и когда что брать Skills (.claude/skills/SKILL.md) Метаинформация загружается в контекст при старте сессии (см. прошлый пост про контекст) Тело SKILL.md грузится только когда Claude решит, что скилл релевантен задаче Может тащить с собой связанные файлы - доку, шаблоны, примеры Один и тот же скилл работает в Claude.ai, Claude Code и Claude Desktop Подходит для правил, которые должны всплывать сами в нужный момент - типа «когда пишешь миграцию - используй apps.get_model и не импортируй текущую модель» Commands (.claude/commands/*.md) Запускаются явно через /command - это команда от пользователя, не от агента Детерминированный сценарий, ты сам решаешь когда дернуть Обычно один файл без бандла Подходит для воркфлоу по запросу - /review, /seo, /pr-check Sub-agents (.claude/agents/*.md) Работают в отдельном окне контекста, в основное возвращается только сжатый результат работы Со своим набором инструментов, моделью, системным промптом Запускаются основным агентом, когда тот решит делегировать Подходит для тяжелых задач, которые засирают контекст - security review модуля, ресерч по большому документу, рефакторинг между фреймворками Матрица выбора получается простая: Кто инициирует - юзер или агент? Юзер - command. Агент сам решит - skill или subagent Важно сохранить основной контекст чистым? Да - subagent. Нет - skill Нужна вспомогательная дока, шаблоны, примеры? Да - skill. Нет - command Ошибка - все пихать в скиллы. У них есть бюджет (5k токенов на одно тело скилла и 25k всего на сессию после /compact), и метаинфа всех скиллов сидит в контексте всегда. Если что-то требуется раз в месяц при конкретном действии - это команда, а не скилл Самое мощное сочетание - команда/скилл, которая внутри вызывает сабагента. /security-review запускает изолированного агента, тот читает 20 файлов, выдает отчет на 200 строк, в основной контекст возвращается только summary. И контекст экономишь, и копнуть глубоко можешь Поддержать на Boosty Посмотреть на Youtube

Кеширование на уровне Django ORM - где оно стреляет в ногу У каждого QuerySet есть встроенный кеш результатов - _result_cache. QuerySet ленивый - в БД не идет, пока его не начнут вызывать. При первой полной итерации запрос выполняется, результат складывается в кеш инстанса. Вторая итерация того же инстанса - уже из памяти Один и тот же запрос дважды это два разных QuerySet # два запроса в БД print([e.headline for e in Entry.objects.all()]) print([e.pub_date for e in Entry.objects.all()]) # один запрос entries = Entry.objects.all() print([e.headline for e in entries]) print([e.pub_date for e in entries]) Кеш живет на инстансе QuerySet, не на запросе. Каждый вызов .all() создает новый инстанс с пустым кешем - даже если SQL идентичный Не все обращения заполняют кеш qs = Entry.objects.all() print(qs) # __repr__ - НЕ кеширует print(qs[5]) # SELECT с LIMIT/OFFSET - запрос print(qs[5]) # еще один запрос Заполняют кеш: [entry for entry in qs] # полная итерация list(qs) # материализация bool(qs) # if qs: entry in qs # проверка вхождения print(qs) дергает repr, который берет первые 20 + 1 элемент (REPR_OUTPUT_SIZE + 1, в SQL это LIMIT 21) и не считает это полной оценкой. Кеш пустой С индексацией - пока QuerySet не выполнен, qs[5] идет в БД с LIMIT/OFFSET. После list() - из кеша Связанные объекты в кеш не попадают сами entries = Entry.objects.all() for e in entries: print(e.blog.name) # +1 запрос на каждую запись, N+1 entries = Entry.objects.select_related('blog') for entry in entries: print(entry.blog.name) # из join Базовый кеш тянет только поля самой модели. FK кешируется на инстансе после первого обращения - e.blog второй раз для того же entry уже из памяти. Для другого entry - снова запрос. Решается select_related для FK/OneToOne и prefetch_related для M2M и обратных связей cached_property + QuerySet работает не как ожидаешь class User(models.Model): @cached_property def followers(self): return User.objects.filter(followed_by=self) cached_property запоминает то, что вернула функция - один и тот же инстанс QuerySet на все обращения. Полная итерация - заполнит кеш QuerySet, второй проход уже из памяти. Это работает Ломается на чейнинге и индексации: user.followers[0] # запрос user.followers[0] # еще запрос user.followers.filter(active=True) # новый QuerySet Любая .filter(), .order_by() создает новый QuerySet с пустым кешем. Хочешь кешировать именно данные - оборачивай в list() @cached_property def followers(self): return list(User.objects.filter(followed_by=self)) iterator() кеш отключает совсем qs.iterator(chunk_size=2000) - стрим без кеша. Повторная итерация = повторный запрос. By design, но забыть легко Что вынести - Сохрани QuerySet в переменную если используешь больше одного раза - На связанные объекты - select_related/prefetch_related - В cached_property оборачивай в list() если хочешь данные, а не запрос - Перед оптимизацией смотри реальные SQL - django-debug-toolbar и connection.queries полезнее интуиции Это встроенный кеш на уровне инстанса - живет в рамках одного запроса. Шарить между запросами и процессами - это уже Redis и совершенно другая история Поддержать на Boosty Посмотреть на Youtube

Как Claude Code собирает контекст и где это лежит Когда стартует сессия, в окно контекста уезжает заметно больше, чем кажется на первый взгляд. Полезно понимать, что туда попадает и из каких источников До того как ты вообще что-то напишешь, в контекст уже загружено: - Системный промпт и описания системных тулз Claude Code - Содержимое CLAUDE.md - из домашки (~/.claude/CLAUDE.md), из корня проекта (./CLAUDE.md) и из подпапок если они там есть. Все три уровня собираются в одну иерархию - Auto-memory - то, что Claude Code сам сохранил о проекте между сессиями - Имена и описания MCP-инструментов от подключенных серверов - Метаинформация скиллов. Сами тела SKILL.md не грузятся пока ты скилл не вызовешь, НО метаинфа с описанием каждого скилла загружается сразу, чтобы знать, что их можно вызвать. Если у тебя 30 скиллов, а используешь за сессию ты один - 30 описаний все равно сидят в контексте Дальше по ходу работы в окно доезжают чтения файлов, ответы Claude и path-scoped правила, которые подгружаются автоматически при чтении соответствующих файлов. Сабагенты при этом работают в отдельном окне контекста - в основное возвращается только сжатый результат их работы Чтобы посмотреть, что реально лежит в контексте прямо сейчас - команда /context, она показывает разбивку по категориям с процентами, см. скрин в шапке поста А что AGENTS.md? Распространенное заблуждение - что Claude Code читает AGENTS.md как fallback. Пока не читает. AGENTS.md это открытый стандарт от OpenAI, его поддерживают Codex, Cursor, Amp, Gemini CLI, но Claude Code автоматически его не подхватит Issue висит открытой на github с августа 2025и собрала тысячи апвоутов Если хочется единый источник правды для всех инструментов можно обыграть следующим образом: - В CLAUDE.md написать одну строку @AGENTS.md - Claude Code умеет импорты и подтянет содержимое - Сделать симлинк CLAUDE.md → AGENTS.md - Повесить SessionStart-хук, который пробежится по всем AGENTS.md в репе и закинет их в контекст На бусти готовили claude code под питоновские проекты - можно брать за основу И раз уж речь зашла про экономию контекста - апну пост про rtk, который сжимает вывод команд еще до того как он попадет в окно

Делегирование - это про свободу, а не про избавление от задач В Стратоплане есть формат "двухдневок" - два дня по 5 часов, одна из них была посвящена Regular Operations, а именно постановке задач, контролю и делегированию. Формат плотный - теория, индивидуальный кейс, обсуждение в группе, разбор. И так три раза за день Первый день разбирали постановку и контроль задач. Казалось бы, базовая тема - SMART, OKR, виды контроля. Но дьявол в деталях. Есть четыре причины, почему человек не делает задачу - не понял, не умеет, не может, не хочет. И для каждой причины нужен свой подход. Звучит очевидно, но на практике большинство руководителей по умолчанию выбирают "не хочет" и начинают давить, хотя человек просто не понял Отдельно разбирали выбор контроля через модель DISC. Красные - не дослушивают задачу и могут сделать не то, им нужен периодический контроль. Желтые - фантазеры, придумают решение, но не реализуют, тут нужен поэтапный контроль. Зеленые - экологисты, могут скорректировать решение ради сохранения комфорта команды. Синие - перфекционисты, будут бесконечно совершенствовать. И для каждого типа - свой подход к контролю Второй день был целиком про делегирование, и вот тут случился главный инсайт. Оказывается, при делегировании иногда стоит специально не давать детальное описание задачи - чтобы человек мог проявить себя и найти собственное решение. Раньше не рассматривал это под таким углом, всегда казалось что чем детальнее - тем лучше. Но делегирование это не просто передача задачи, это передача свободы выбора и полномочий Еще сильная концепция - разница между контролем и контроллингом. Контроль - это про конкретные задачи. Контроллинг - это процесс постоянного фокуса внимания через метрики, дашборды и синхронизации. По сути, ты выстраиваешь систему, которая дает прозрачность без необходимости лично проверять каждую задачу И золотое правило, которое стоит запомнить - больше делегирования означает меньше контроля, а не больше. Когда доверие растет, контроль снижается, делегирование увеличивается, у руководителя появляется больше времени. И это время должно уходить не на еще больший контроль, а на стратегические задачи По классике - чтобы вы могли углубиться в тему, несколько книг из рекомендованных на курсе: - Т. Демарко, Т. Листер "Человеческий фактор: успешные проекты и команды" - И. Адизес "Развитие лидеров. Как понять свой стиль управления и эффективно общаться с носителями иных стилей" - К. Прайор "Не рычите на собаку! Книга о дрессировке людей, животных и самого себя"

Как отмечали в комментариях выше - opus 4.7 действительно может блокировать чаты, столкнулся лично

Поднять продуктивность!

Warp не перестает удивлять Ребята, которые начинали как просто красивый терминал, сделали пивот в сторону AI-агентов, а теперь пошли еще дальше - стали оберткой над другими агентами. И сделали это красиво Теперь Warp из коробки поддерживает Claude Code, Codex, OpenCode, Gemini CLI и вообще любой агентский CLI. То есть весь тулинг, который они построили для своего агента - код-ревью, нотификации, удобный ввод - теперь работает и с вашим любимым агентом Что добавили: - Вертикальные табы - все агентские сессии в одном месте со статусом, веткой git и директорией. Запустил пять сессий Claude Code на рефакторинг - видишь состояние каждой и переключаешься в один клик - Нотификации - запустил агента, переключился на другую задачу, и Warp дергает тебя в момент, когда агенту нужно твое внимание. Это прям приятная вещь для тех, кто гоняет несколько агентов параллельно - Код-ревью прямо на выходе агента - оставляешь инлайн-комментарии на дифф, агент их обрабатывает. По сути PR-ревью, не выходя из терминала - Rich input - можно прикрепить картинку, использовать голосовой ввод, открыть файловый менеджер, писать многострочные промпты через Ctrl-G Вообще интересно наблюдать за эволюцией Warp. Терминал -> свой агент -> платформа для любых агентов. Каждый шаг выглядит логичным, но мало кто мог предсказать такую трансформацию из обычного терминала. SuperSet и аналогам стоит присмотреться - конкуренция за место "главного окна разработчика" становится все жестче Напомню, что он еще и на windows появился Скачать Warp

Устали сливать токены в AI-ассистентах на мусор? Когда работаешь с Claude Code или Codex, большАя часть контекста - это шум: портянки вывода тестов, многоэтажные ls, простыни docker logs. Модель это всё читает и тратит токены, которые вы оплатили RTK (Rust Token Killer) - CLI-прокси, который фильтрует и сжимает вывод команд до того, как он попадает в контекст модели. Написан на Rust, добавляет меньше 10ms оверхеда Один пример - pytest без и с RTK: # Обычный pytest (~2000 токенов) collected 47 items test_api.py::test_create_user PASSED test_api.py::test_get_user PASSED test_api.py::test_update_user PASSED ... ещё 40 строк зелёных тестов ... test_api.py::test_delete_user FAILED # rtk pytest (~200 токенов) FAILED: 1/47 tests test_delete_user: AssertionError at test_api.py:84 Модели не нужны 46 PASSED - ей нужно знать только что сломалось и где. По их замерам экономия на тестах достигает 90% Устанавливается в одну команду: brew install rtk Для Claude Code настраивается так: rtk init -g После этого хук автоматически перехватывает bash-команды и переписывает их в rtk-эквиваленты - вы ничего не меняете в своём флоу, просто начинаете тратить меньше Поддерживает Claude Code, Cursor, Copilot, Gemini CLI Поддержать на Boosty Посмотреть на Youtube

CTO, который не говорит на языке денег - просто исполнитель Продолжаю делиться впечатлениями от школы CTO от Стратоплана. Этот блок оказался более прикладным, чем первый. Четыре основных направления - информационная безопасность, финансы, управление продуктами и найм Про ИБ. Я далек от этой темы, но занятие зацепило не техническими деталями, а подходом к мышлению. Главный инсайт - не нужно пытаться защитить все. Нужно определить то, без чего бизнес перестанет существовать, и сфокусироваться на этом. Есть даже термин для этого - Digital Crown Jewels, "цифровые алмазы короны". Определил их - дальше строишь защиту вокруг приоритетов, а не пытаешься закрыть все 1000 уязвимостей разом. Сам фреймворк мышления - "не все, а главное" - работает далеко за пределами безопасности Финансовый блок занял три занятия - от базовых отчетов до построения финансовых моделей и инвестиционного анализа. Так как я учился на прикладной информатике в экономике, то точки безубыточности, маржинальности и дисконтированные сроки окупаемости напомнили университетские пары. Но одно дело считать это в вакууме на экзамене, и совсем другое - понимать, зачем это нужно тебе как техническому руководителю. Когда умеешь обосновать решение не только техдолгом, но и конкретными цифрами возврата инвестиций - разговор с бизнесом строится иначе Управление продуктами - занятие, которое хорошо расставило акценты. Ключевое разграничение - Product Manager отвечает за то, что именно делает команда и принимает решения, а Project Manager - за координацию и отслеживание планов, то есть за то, как делать. И важная мысль - не везде нужно продуктовое управление с HADI-циклами и проверкой гипотез. Иногда задача понятна, требования зафиксированы, и лучшее что можно сделать - вернуться к классическому проектному подходу по PMBOK Найм и развитие - пожалуй, самое практичное занятие из блока. Три вещи, которые забрал себе: когда стоит растить людей внутри, а когда нанимать извне, как выстраивать систему развития сотрудников, чтобы она работала без ручного управления, и что удержание ключевых людей - это не про деньги, а про понимание их мотивации и точек роста Главный вывод после этого блока - CTO, который не умеет переводить технические решения в язык бизнеса, остается техническим исполнителем. Ты либо приходишь с аргументами на языке денег и рисков, либо тебе спускают решения сверху

Наконец-то LLM добрались и до ТГ

django-modern-rest@0.1.0 – первый публичный релиз! Исходники: https://github.com/wemake-services/django-modern-rest Подробнейшая документация: https://django-modern-rest.readthedocs.io Пример настоящего приложения: https://github.com/wemake-services/wemake-django-template Первый анонс был уже какое-то время назад. Так что давайте повторять, что у нас тут происходит. Во-первых, у нас рекорд: еще нет ни одного релиза, а уже 560+ ⭐ на Гитхабе (сходите поставьте, кто еще не). Вижу, что люди ждут, вижу интерес. Спасибо! import uuid import msgspec from dmr import Body, Controller from dmr.plugins.msgspec import MsgspecSerializer class UserCreateModel(msgspec.Struct): email: str class UserModel(UserCreateModel): uid: uuid.UUID class UserController( Controller[MsgspecSerializer], Body[UserCreateModel], ): def post(self) -> UserModel: return UserModel(uid=uuid.uuid4(), email=self.parsed_body.email) Фичи – Главная фича, которая вообще подтолкнула меня к такому проекту: инфраструктура Джанги. Тут есть буквально все пакеты на все случаи жизни. Но не было нормального REST фреймворка. В комментах я регулярно наблюдал, как люди ненавидят Джангу, но почти всегда говорят про DRF. Да, он был ужасен – то теперь он на свалке истории! – Все существующие плагины к родной Джанге должны работать – Официальная поддержка Джанго в одном файле, да, Джанга может быть настолько простой – Работаем с любыми моделями: pydantic, msgspec, TypedDict, dataclass, тд. Сериализация и валидация не прибиты гвоздями. А значит можно выбирать сериализатор под контроллер. Где-то msgspec + TypedDict для скорости. Где-то pydantic для более широких возможностей валидации. Можно писать свои – Скорость. Мы довольно быстрые. Самый быстрый Python фреймворк для REST в Django. По скорости можно сравнивать с FastAPI, мы всего лишь на 30% медленнее. Но у нас и Джанга вообще-то. Скорость будет улучшаться, есть разные интересные идеи – Типизация: типизировано всё! Но самое важное, типизацию не пихают вам в лицо. Нет огромных и сложных типов. Все просто, надежно и удобно. Поддерживаем mypy, pyright, pyrefly в самых строгих вариантах – Поддержка async везде. От вьюх и моделей до SSE. Никаких sync_to_async внутри – SSE! Без дополнительных костылей: просто работает (с валидацией сообщений и возможностью строить бизнесовые ADT поверх типов сообщений и крутейшей схемой) – Семантика. Одна из ключевых фичей: мы очень сильно упоролись по генерации схемы. Добавил auth= в контроллер? В списке ответов появился 401 статус код автоматически. Возвращаешь ответ, заголовок, куку, которой нет в спеке? Во время дебага – случится ошибка валидации. На проде валидацию нужно отключать для скорости. Так мы гарантируем точность ответов и схемы. Не нравится схема? Все легко переопределить или вообще отключить – Swagger, Scalar, Redoc из коробки, легко настраивать – Работаем не только с json, поддерживаем content negotiation, можно писать свои парсеры и рендереры – JWT и DjangoSessionAuth из коробки, есть возможность отзыва токенов и сессий – Возможность писать заготовки контроллеров и полностью переиспользовать код. Писать плагины под dmr будет просто и удобно – Загрузка и отдача файлов (но на питоне такое очень осторожно надо делать, лучше на Rust) – Нет привязки к логике или DI (берите любой, например dishka). Мы просто парсим данные и возвращаем их. То есть: код не превратится в кашу из логики и фреймворка уже через 10 бизнес фичей – Удобная обработка ошибок на многих уровнях – Полная возможность для кастомизации. Можно даже поменять формат внутренних ошибок в рамках контроллера – Удобные тесты: polyfactory, pytest, schemathesis (проходим все правила из коробки) – Скилы для LLM для написания кода по OpenAPI спеке, llms-full.txt, Context7 для контекста – Но никакого нейрослопа внутри!

Если новый мак от 600$ не интересен, то зацените хотя бы их hero-секцию на обновленном сайте

Опасность использования loaddata в миграциях Есть одна команда в Django, которая работает идеально - ровно до того момента, пока ты не попробуешь накатить миграции с нуля Речь о call_command("loaddata", ...) внутри миграции Выглядит невинно: добавляешь начальные данные в базу прямо при создании схемы - удобно, лаконично. Но потом ты добавляешь новое поле в модель, и при прогоне миграций с нуля всё ломается Почему? Когда ты пишешь RunPython и вызываешь apps.get_model() - ты получаешь историческую модель. Это не та модель, что у тебя сейчас в models.py, а её слепок на момент конкретной миграции. Django специально реконструирует её из цепочки миграций, чтобы INSERT и UPDATE содержали только те колонки, которые реально существуют в базе прямо сейчас - в процессе накатки А вот loaddata на эту логику плевать хотел - он всегда импортирует модель напрямую из приложения, то есть берёт текущее состояние models.py со всеми полями, которые ты добавил позже. В итоге команда пытается сделать INSERT с колонкой, которой в базе ещё нет Решение - отказаться от loaddata в пользу RunPython Читаем JSON сами, создаём объекты через историческую модель из apps.get_model(). Тогда Django собирает INSERT только по полям, которые реально существуют на момент этой миграции - и никакие будущие изменения схемы её не сломают def load_fixture(apps, schema_editor): MyModel = apps.get_model("myapp", "MyModel") MyModel.objects.all().delete() fixture_path = ( Path(__file__).resolve().parent.parent / "fixtures" / "my_fixture.json" ) with fixture_path.open("r", encoding="utf-8") as f: data = json.load(f) objs = [ MyModel(**item["fields"], pk=item.get("pk")) for item in data if item.get("model") == "myapp.mymodel" ] MyModel.objects.bulk_create(objs) Простое правило - миграции должны быть детерминированными и самодостаточными, без привязки к текущему состоянию моделей Поддержать на Boosty Посмотреть на Youtube