.

Облако драгоценностей за неделю.

Приватный клуб.

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

Для донов-начинающих:

(лонгрид)
Сейчас многие используют искусственный интеллект для генерации кода, а главное, что этот "скилл" стал обязательным в резюме, так что нравится вам это или нет, но вы больше не можете это игнорировать.
AI может помочь вам двигаться быстрее, и вы, наверное, уже знаете -- но это всё в теории. Генерировать код не то же самое, что понимать его. Это вообще совершенно другой навык...

Если я заставлю себя сделать хоть что-нибудь, даже сущую мелочь, более сложные задачи покажутся намного более лёгкими. Пишите код!

Для донов-неначинающих:

98. Интеграционные тесты: скам или польза?
Google и Twitter вообще давно заявляли, что "интеграционный тест - это бесполезный термин". Возможно, проблема в том, что под интеграционными тестами понимаются сильно разные вещи...

...Если вы, едва услышав "система перегружена", сразу же думаете "добавим ещё серверов", значит эта заметка для вас. Иногда это срабатывает, но в большинстве случаев - нет. Вы просто бездумно двигаете нагрузку, выдавая это за прогресс, и надеетесь, что угадаете...

Продолжаю набор на занятия для неначинающих (миддлы сеньоры), эксклюзивно для донов, 2 места закончились за 4 минуты.

(все старые материалы для донов быстро сгорают)

=

Новые материалы для ментатов Лаборатории.

В СильныеИдеи добавлен материал "150) 8 способов снизить трение в проекте".
Внешний API работает не совсем так, как вы думали, или он работал так, а потом его изменили. Ошибки. Предупреждения системы безопасности. При обновлении зависимостей что-то нарушается. Кто-то заболевает. Кто-то уходит из компании. Требования неясны, или заказчик меняет свои хотелки в процессе разработки. Компьютер сломался. Твоя IDE после обновления перестала загружать проект. Статистика против нас...

В раздел "Элитный программист" добавлен материал
99) Нетворк и эхо-камеры в 2026-м
Частая ошибка не знакомиться с разработчиками в вашем стеке просто ради знакомств на перспективу. Люди ошибочно считают, что такие контакты приведут скорее к токсичным разборкам, останутся поверхностными и будут пустой тратой энергии. Но это совершенно неверно...

В курс карьеры добавлен 141-й материал "Как учиться в эпоху искусственного интеллекта?". Три правила использования AI для ускорения обучения, а не для передачи своего мышления на аутсорсинг...

=

"Функциональные архитектуры" 147(+2) топиков
Добавил несколько материалов по архитектурам и ООП (эту тему вместе с ФП тоже продолжаю развивать).
После 150 материалов цена гайда (для новых) вырастет.

Last Principles Framework: готовы 19(+4) задач, закрыты 10(+3) тем из ~20 первого уровня. Вы же понимаете например, почему паттерн Фабрика - конструктивный отстой в сравнении с декларативным ко-произведением типов и глобальным морфизмом?
Откуда мы автоматически попадаем в Функциональные архитектуры ↑ :) только прихватив более сильные абстракции.

=

"ЛаМПовое":

На неделе выйдет седьмой гайд "Programming in Large"

=

it's a privilege to do things that are hard. 💪🏻

=

И вот наконец после долгого пути мы пришли к его началу.
Древняя ментатская головоломка
"Охотники Дюны"

Как формально классифицировать разработчиков (мэйнстрима) через n-гомотопии.

Джун: 0-путь (объекты) и 1-путь (морфизмы).
Пишет функции.

Мидл: 2-путь (комбинирование функций, эквивалентности):
контракты/ограничения/абстракции/паттерны.

Сеньор: 3-путь (комбинирование паттернов, факторизация через ко-предел как клей, верификация): может доказать, что совместная работа новых частей не сгенерирует противоречий в 2-путях (например что сочетание шардирования и кэширования не приводит к скрытым проблемам).
(Формальная) верификация на уровне типов. Оркестраторы.

Архитект: 4-путь (мета-уровень).
Ум как порождающая парадигма: создание оригинального архитектурного стиля под всю систему. Придумывает DSL (хотя бы на уровне спек, как - изучайте ФА) и новые правила композиции (фактически, создание модели высшего порядка). Видит, какие 2-пути и 3-пути надо делать простыми, а какие сложные и как их упростить. Понимает, как их композиции повлияют на долгосрочное развитие системы.
Метрикой связности тут и становятся формальные гомотопии. Например если слишком много высших путей (запутанных зависимостей), значит придуманная конструкция хрупковата.

5-путь -- это чистая теория (зависимых) типов, HoTT как язык программирования и т.д. Засада в том, что реальный код полон побочных эффектов и багов, а требования постоянно меняются, и тем самым стирается когерентность выше 4-пути.

...И здесь мэйнстрим упирается в тупик. Мы же в (Meta) Principles Framework пойдём куда дальше: топологическим сдвигом изменим размерность самой задачи. Сеньор строит лабиринт из паттернов; мы будем строить карту, на которой лабиринт превращается в прямую линию.

Каждый не-технический человек, которого я знаю, что-то создаёт в своей теме с помощью AI. Каково ваше оправдание?

Если нейронки уже отлично пишут код и здорово разбираются в архитектурах, алгоритмах и математике на уровне золотых медалистов, почему продолжают активно разрабатываться и выпускаться всё новые и новые и всё более и более дорогие модели?

opencode - лучший опенсорсный AI-агент для кодинга
opencode - продукт с 7,5 миллионами пользователей в месяц
opencode - репа на гитхабе со 188 000 звёздами
opencode - компания с одним лысым инди-хакером

p.s. а я ведь говорил месяц назад: пилите ai-джуниора (и пофиг, что получится карго-культ :), всё остальное вторично.

Умение создавать программные сервисы, и умение создавать человечный контент в блогах (прежде всего текстовый), станут наиболее прибыльными навыками следующего десятилетия (да уже и текущего).

И именно программные сервисы, а не программные продукты - API-as-a-Service, и желательно не в json, а в более структурированном и при этом более компактном формате, например toon.

Почему? Потому что к 2030-му 98% пользователей софта будут AI-агенты, а нафиг им нужен твой UI? Им подавай Network APIs.

Сегодня каждый должен делать свою работу только на vps с arch linux.
Никто больше не должен писать код локально, это просто глупо.

Мой 7-й гайд "Programming in Large" (по материалам СильныхИдей для ментатов), основной акцент на избавлении от зависимости от зависимостей.

Силлабус:

Избавляемся от зависимости от зависимостей
Сколько раз вы пытались удалить некоторую зависимость из проекта, но не были уверены, что сделали это успешно? Чтобы ваша кодовая база не зависела от чего-то конкретного? Или чтобы она "зависела от интерфейсов, а не от реализации"? Или старались следовать SOLID по инверсии зависимостей?

Избавляемся от зависимости от зависимостей - 2
Ключевой вопрос любой зависимости независимо от её типа, очевидно, такой: "Зависит ли А от B?".

Избавляемся от зависимости от зависимостей - 3
В первом материале по этой теме мы разобрали 9 видов зависимостей, а во втором материале изучили три характеристики любой зависимости, и как правильно о них думать. Теперь вернёмся к исходным 9 видам, и рассмотрим, как с ними разбираться. Но предварительно дадим точное и практическое определение зависимости.

Избавляемся от зависимости от зависимостей - 4
Итак, у нас есть универсальное определение зависимости. Рассмотрим теперь в его свете 9 типов зависимостей, причём в некоторых случаях мы получим ответ вида "это не зависимость, но часть зависимости".

Как извлечь пользу из сторонних зависимостей
Скорее всего, в вашем проекте имеется не одна зависимость от сторонних библиотек, на которые достаточно серьёзно опирается ваше приложение, но вы либо боитесь, либо по каким-то другим причинам не хотите (нету времени...) заглянуть под капот и изучить её исходный код.

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

Что такое баг?
Через некоторое время обнаруживается, что разработчики совершенно неправильно поняли интерфейс API...

Пишем безошибочный код с помощью Typestate-Oriented Programming
ООП позволяет достаточно хорошо моделировать мир, но основополагающим для качественного моделирования становится состояние объекта, которое, с другой стороны, частая причина ошибок и запутывания кода.

Логика бьёт порядок
Сценарии (прежде всего use cases и user stories) сегодня тотально доминируют в технических заданиях. Они опасны тем, что обманчиво хорошо смотрятся с точки зрения здравого смысла, однако не могут претендовать на универсальность прежде всего потому, что им не хватает абстракции, даже если мы предварительно тщательно формируем "проектную онтологию предметной области"...

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

44 правильных вопроса при разбирательстве с легаси-системой
Само по себе изучение кода проекта "в вакууме" довольно абстрактно и бессмысленно. Вместе с кодом у вас должна быть работающая система, сформированная из этого кода, с которой вы взаимодействуете через UI.

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

=

12 материалов,
130 кб чистого текста,
цена до завтрашнего дня 1900 рублей,
купить на бусти

+ этот 7-й гайд добавлен в бандл (кто уже покупал бандл, просто скачайте и этот гайд себе бесплатно, и так и дальше будет с новыми - доплачивать не надо),
цена бандла пока старая 14999 рублей, завтра соответственно вырастет.

=

Предыдущие материалы (в бандле все эти материалы с большой суммарной скидкой + новый данный):
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-26
4. Вайб-проектирование
5. Software Design с акцентом на Programming in Large
6. Programming in Large: продолжение
7. this :)

Вы помните, когда вам в последний раз приходилось писать код?
Вы помните, когда вам в последний раз приходилось читать код?
Вы помните, когда вам в последний раз приходилось отлаживать код?
Вы помните, когда вам в последний раз приходилось делать code review?
Вы помните, когда вам в последний раз приходилось узнавать что-то новое в программировании?
Вы помните, когда вам в последний раз приходилось использовать свою память?
Вы помните, когда вам в последний раз приходилось использовать свой ум?

99,999999999999% программных систем чрезвычайно просты и не требуют новых и сложных решений.

Лишь небольшая часть компаний имеет дело с
-миллиардами пользователей
-безумным количеством запросов в секунду
-невероятными крайними случаями.

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

Выцепил сегодня у Кента Бека классную фишку: когда делаешь code review или pr-обзор, не тыкай прямо в ошибку, если такая есть. Подскажи, какой тут тест пропущен. Кодер не должен тупо фиксить тикеты, он должен думать прежде всего, быть хотя бы немножечко в контексте проекта.

Я так-то уже лет пять на моих курсах по АСД интуитивно ровно так и делаю: если человек не проходит своим решением тесты на учебном сервере и не понимает где у него ошибка, я даю тест какой надо сделать на его ошибку ("красный"). При этом "просто спросить" не разрешается, сперва в любом случае надо сделать тесты на свой вроде бы работающий код (условный "зёлёный"), так как хотя тесты и требуются, но их
особо никто не пишет (правда, в этом году я и наличие тестов теперь проверяю обязательно). И даже когда пишешь свой "зелёный", в 90% проблема обнаруживается "сама собой" :)

Но, да, здесь существует контринтуитивный разрыв между абсолютной стратегически пользой TDD, и непониманием этой пользы в повседневной практике. Например, мало того что вы автоматически получаете регрессионные тесты, вы также получаете минимум двух клиентов для вашего API (подумайте, почему), а между 1 и 2 пропасть огромная (ну, то у вас система работала на одном сервере, а то на двух - 23 - 256 - уже особо без разницы), и т.д.

Десятки других фишек от кента разберём с ментатами в СИ.

Дёшево писать код == дорого сопровождать и развивать код.

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

Внесение изменений в такой код обходится недёшево ровно потому, что сам код был прост в создании. Он будет дёшев только в том случае, если человек полноценно эээ овладеет этим кодом :)

Таким образом, разделительная линия -- это не "может ли агент это написать ". Это "можете ли вы в этом разобраться, и одобрить". Соответствует ли это вашим ожиданиям. Можно ли это протестировать. Хотите ли вы в будущем это развивать.

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

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

В рамках работы над Last Principles Framework познакомился с "-оидизацией": это когда мы допускаем существование некоторой фиговины  во множественном числе как сущности первого класса. Например у тебя есть моноид (монада - это моноид...), и таким превращением его (как целостной структуры) в моноидоид получаем моноидальную категорию (hom-множество само категория, а нафига это понимать программисту, разбираем на примерах в LPF: это каррирование в частности). Собственно, это ФП и есть: множество типов как объекты и функции как стрелки.
 
Далее, продолжая оидизацию, имеем моноидальный моноидоидоид :)

Ну, это всё  естественные преобразования теорката как функциональные паттерны:
трансформеры монад, линзы, оптики, разбираем их на первом курсе ФП (хотя в этом на самом деле от силы 2% функциональщиков/хаскелистов разбираются: они ещё более ленивые, чем мэйнстримщики:). Зато в работе с искусственным идиотом это всё дает мощные прорывы при составлении формальных спецификаций.
 
Но мы конечно пойдём дальше :)
 
Надеюсь вы заметили что на самом деле любую операцию можно обобщить: сначала на множество типов, потом на стрелки между стрелками, и таким образом мы можем проектировать бесконечно композируемые мета-абстракции.
 
Так, следующим шагом становится моноидальный моноидальный (не тафтология; подумайте, почему) моноидоидоидоид :)
 
Получаем преобразования между естественными преобразованиями (в продвинутых библиотеках эффектов, для формальной верификации...), но на самом деле мне это всё очень нравится прежде всего в том плане, что супер прокачивает "мышление (мета-)спецификациями" прежде всего.
 
Фишка же в том, что мета-паттерн
"когда у тебя есть тип данных, всегда можно сделать его параметрическим (обобщив до полиморфного типа или до тайпкласса например), надстроив новый уровень стрелок"
можно применять на всех уровнях!
 
А ФП - это всего лишь про обобщение максимум до 3-категории: через функторы монады естественные преобразования трансформеры оптики...