Вчера я прочувствовал всецело "кость в горле".

Подавился костью рыбы. Так было больно, одновременно досадно саднило. И вдохновило.

Сел - пишу статью дальше.
Так живешь, строишь планы, прыгаешь в горах как козел по камням на байке, а отъезжаешь в миг от безобидной оливки или предательской кости рыбы в горле.

Курица кажется безопаснее.
Она не пытается меня убить из тарелки.
С другой стороны: мою собаку убивает сильная аллергия на курицу.
Мы окружены, Гарри.

Ты давился костью рыбы? На сколько она была большая?
Я в этот раз задумался и пропустил большую.
Ты так не делай. Будь в моменте))

#codemonsterslog

Я помню, когда я прочитал доклад несколько лет назад про ROP и программирование на типах в пустой колодец. Инженеры просто молчали. А ведь это крайне полезные подходы.

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

ROP (Railway-oriented Programming) и программирование на типах действительно очень полезные подходы, особенно для создания надежного кода.

из серии: воспоминания деда

#codemonsterslog

День прокрутил на хорошей скорости

С пленки вайб идёт по проводам
Продолжаю писать

Ты стримовый или аналоговый звук слушаешь?

#codemonsterslog #vibe@codemonsterslogs

Вирт:

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

Дорабатываю фрагмент статьи, нашел прекрасную цитату.

Всем хорошего дня.

#codemonsterslog

🚀 Со-творчество с машиной: как я создал валидатор контрактов без единой строки кода

Представьте: инженер надевает "костюм супергероя" в 5 утра, садится за Claude терминал и за 10 часов создает production-ready инструмент на Go с 300+ тестами, НЕ НАПИСАВ НИ ОДНОЙ СТРОКИ КОДА вручную.
Научная фантастика? Нет, реальность 2025 года.

🎯 Суть эксперимента:
Вместо Pact создал с машиной валидатор контрактов между микросервисами по AsyncAPI 3.0 спецификациям.

Идея простая: зачем писать дополнительные pact тесты в BDD-стиле, если спецификации уже содержат всю информацию о контрактах?

💡 Ключевые открытия:

TDD + ИИ = магия
- Маленькие итерации от тестов к коду
- Машина обнаружила 2 критических бага в процессе
- Ноль переписываний благодаря четкому проектированию модулей и структур сообщений для модулей

Проектирование решает всё
- Схемы иерархии модулей на бумаге
- Псевдокод основной функции
- Railway-oriented Programming для обработки ошибок, для упрощения потока программы
- "Один модуль — одна функция"

Роль инженера меняется кардинально
Из кодировщика в архитектора: формулируешь техзадание, рисуешь схемы, валидируешь результат. Машина делает всю рутину.

🔥 Результат:
Полнофункциональный валидатор контрактов с модульной архитектурой, исчерпывающим тестированием и стандартизированной обработкой ошибок. Готов к production.

💭 Главный инсайт:
Принципы структурного программирования 70-х + современные ИИ-ассистенты = мощнейшая комбинация.
Качественное проектирование становится единственным критическим навыком.

Читать статью

Мы живем в уникальном срезе реальности, где сбываются мечты программистов о "средствах автоматизации кодирования" из 1973 года.

Читать код валидатора контрактов

#codemonsterslog

Spec-driven development: программируем через спецификацию

Сначала была лаконичная спецификация. Потом был код на Go.
Без some-driven development сейчас ты не девелопер.

Наткнулся на статью, которая отлично дополняет мой эксперимент по кодированию с ИИ. Я тоже описывал задачу в README машине — и это работает.

Написать лаконичную спецификацию перед тем, как начнёшь кодить — правильный цикл разработки.
Причём сейчас, в эпоху ИИ-ассистентов, это не просто best practice, а рабочий инструмент.

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

Потом можно провести встречу без повестки, доски, стикеров, без протокола, просто походить и почесать языком часов 8 — и ты уже герой, получаешь 💰. Но результата ноль.

Цикл разработки прост:

1. Отредактируй спецификацию в main.md или README.md
2. Попроси ИИ-агента скомпилировать её в код Go
3. Запусти и протестируй приложение
4. Если что-то работает не так — обнови спецификацию

Повторяй, пока не получишь нужный результат.

Подробнее: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-using-markdown-as-a-programming-language-when-building-with-ai/

#codemonsterslog #dev2dev

https://youtu.be/mfv0V1SxbNA?si=-1iRVOo0xTJYLob1

Linus собирает Linus-у комп и обсуждает много тем
#vibe

В конце года в 4-м квартале мы запустили Бэкенд Академию для аналитиков и тестировщиков, чтобы переквалифицировать сотрудников в бэкенд инженеров и дать возможность развиваться по бэкенд треку.
Для меня это стало настоящей отдушиной в конце необычного и классного года.
Я люблю инженеров и видеть рост компетенций у ребят - это большая радость.
Меня это сильно заряжает и мотивирует.

Я собрал команду единомышленников, мы провели первичный отбор из 67-ти инженеров отобрали 26.
Выстроили и постоянно улучшаем процессы, например процесс поэтапной аттестации, чтобы отслеживать насколько качественно усваивается материал и выполняются домашки.
Наша цель на выходе получить настоящих инженеров.
Программу построили от теории к практике, так как я убежден, что универсальные теории студенты смогут применять в карьере вне зависимости от стека.
Обучение построено по стандарту, который мы разрабатываем в параллель с инженерами.
От API First, Doc as Cod, до компонентных тестов и качественного проектирования софта до установки в кубер и сопровождения.
Про тестирования мы отдельно даем теорию и практику, чтобы инженер понимал, что от количества тестов качество софта не зависит. Что писать код программы и код тестов нужно меньше - так как это работа, которая стоит денег, а мы строим эффективное производство при котором меньше пишем, больше катим и меньше ошибаемся, а если ошибаемся и роняем, быстро поднимаем.

Про мифы тестирования и введение в структурное программирование собрал материал из классических трудов отцов основателей, просто понятно раскрыта суть вопроса без лишних модных терминов.
https://codemonsters.team/blog/2025/12/12/structured-programming-essential/

Дай пять.🙌

#codemonsterslog

Модульность программы: как писать код, который не превратится в хаос

  Модуль — это последовательность логически связанных фрагментов кода, оформленных как отдельная подпрограмма (функция, класс, сервис).

  Ключевой принцип: один модуль — одна функция.

  5 главных правил модульного кода:

  1. Один вход, один выход — модуль должен возвращать управление тому, кто его вызвал
  2. Небольшой размер — обычно 20-200 строк. Если больше — разделяй
  3. Единственная ответственность — функция модуля должна выражаться одной фразой: "Валидировать email", "Создать карточку клиента", "Вычислить возраст"
  4. Вертикальное управление — модуль может вызывать только подчиненные модули уровнем ниже. Главные решения принимает головной модуль
  5. Черный ящик — вызывающий модуль не должен знать о внутреннем устройстве вызываемого

  Почему это важно:
  - Проще тестировать
  - Легче вносить изменения
  - Меньше багов
  - Код можно переиспользовать

  На практике: начинай с нисходящего проектирования (top-down).
Сначала определи общую функцию программы, затем разбей на подфункции, потом детализируй каждую.

  Головной модуль — это краткий конспект всей программы.

 Читать полностью: ссылка на статью

https://codemonsters.team/blog/2025/12/15/program-modules/

#codemonsterslog

Математическое доказательство корректности программ

Собрал очень ценную статью про математическое доказательство правильности программы и формальное доказательство, которое мы используем при кодировании. https://codemonsters.team/blog/2025/12/30/program-correctness/

Для меня это особенно важная работа.

Показывает, как от математики мы переходим к инкапсуляции в ООП и типизации (формальному доказательству)

Правильная архитектура даёт нам 100% покрытие бизнес-логики юнит-тестами. Управляемое тестирование, а не тестирование ради процентного покрытия.

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


Формируется мощный фрейм для программирования на русском языке с AI-ассистентами.
От классических основ к современному синтезу работы человека с машиной.

Бежим дальше.

#codemonsterslog

Увлекательная статья

https://cursor.com/blog/self-driving-codebases

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

Увлекательный отрывок словно из соцреализма

Когда мы требовали 100% корректности перед каждым коммитом, это приводило к серьёзным проблемам с сериализацией и замедлению эффективной пропускной способности. Даже одна небольшая ошибка, например, изменение API или опечатка, могла привести к полной остановке всей системы. Рабочие выходили за рамки своих полномочий и начинали исправлять несущественные вещи. Множество агентов набрасывались друг на друга, пытаясь исправить одну и ту же проблему.

#vibe

Привет.
Две книги, на которые не жалко ни одной из четырёх тысяч недель.

Первая — «Четыре тысячи недель на всё». Оливер Беркман объясняет, почему попытки всё успеть — ловушка. И предлагает смотреть на время иначе.
Не как ресурс, который надо оптимизировать, а как ограничение, с которым стоит подружиться.
В сущности, я и есть время. Несмотря на то, что я старался держать мысли о конечности жизни в оперативке(вспоминал Хагакурэ), последние два года изрядно выбили из меня всю дурь.
Я иначе смотрю на своего пса, которому 9 лет — и времени вместе осталось не так много.
Я вернулся к вопросу: а чего хочу действительно я? Что мне дорого?

Обожаю мысленный эксперимент: как бы я провёл последний день на этой прекрасной планете?

Пошёл на Физикл 3.0, добавил больше прогулок, активности, силовых. Хочу выстроить для себя в систему адекватный ЗОЖ.
Недель у меня не так много. Хочу прожить и качественно. Энергии прибавилось, настроение улучшилось.

Вторая — «Как устроен мир на самом деле». Вацлав Смил настойчиво снимает розовые очки и показывает, на чём мир реально держится. Сталь, бетон, аммиак, энергия.
Без этого ни электромобили, ни ИИ — ничего нам не скажут.

После прочтения берегу две эти книги.

Если читал — поделись в комментах: чем тебя зацепила книга? Что изменил в своей жизни?

#codemonsterslog