Цой жив!!1 ❤️
"Ты должен быть сильным" :)
 
Делать два дела сразу — значит не делать ни одного.
Публилий Сир
 
Не позволяйте календарю вас обмануть. В году лишь столько дней, сколько вы проводите с пользой. Одни весь год занимаются тем, на что хватило бы и недели. Другие за неделю справляются с делами, которые стоят целого года.
Чарльз Ричардс
 
Ежедневник подводит вас. Вам следует оценить, приближает ли вас недельный план к намеченной цели? Если ответ “нет”, надо менять план. В вашем распоряжении не так уж много времени, чтобы достичь желаемого,
"На пределе" Эрик Ларссен
 
Мы боимся выступать на публике, отстаивать свои права, принимать решения, допускать кого-то близко к себе, менять работу, оставаться в одиночестве, стареть, водить автомобиль, боимся потерять любимого человека, отношения… В нашем обществе страх стал эпидемией. Мы боимся начинать — и заканчивать. Боимся меняться — и стоять на месте. Боимся успеха — и провала. Боимся жить — и боимся умереть.
"Бойся, но действуй!" Сьюзен Джефферс
 
Как только вы овладеете временем, вы поймете, насколько соответствует истине правило, что большинство людей переоценивают то, что могут выполнить за год, — и недооценивают то, чего могут достигнуть за десять лет.
Тони Роббинс:)
 
Можно выбрать для себя возвращение назад, к безопасности, или продвижение вперед, к росту. Человек должен снова и снова выбирать рост, но при этом ему нужно снова и снова преодолевать страх.
Абрахам Маслоу (в "Синей бороде" Пелевина шикарный разбор его пирамидки)
 
Пусть будет всё как будет
Ведь как-нибудь да будет
Ведь никогда же не было
Чтоб не было никак

.

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

"Стюарт Блум не спасает Вселенную" шикарный сериал (если конечно вы любите ТБВ).

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

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

Итак, дорогие, как вы работаете над кодовой базой, не перегорая при каждом запросе на доработку и пересмотр дизайна системы? Как вы не раздражаете всех, заставляя подчиняться своим требованиям?..


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

40 часов учёбы при 25%-ной эффективности это то же самое, что 12.5 часов при 80% эффективности. Поэтому, быть абсолютно честным с самим собой по поводу своей продуктивности — это одна из самых полезных вещей, которые только вы можете сделать для себя любимого. Но самостоятельно выбраться за 30% продуктивности, без стороннего "намордника", практически нереально...

Все говорят об агентах искусственного интеллекта, но мало кто создал и настроил такого агента, который они действительно используют в своём рабочем процессе (не обязательно в программировании). Почему это так?
Дело в том, что чтение обучающих гайдов и просмотр видео с демками использования агента — это не то же самое, что подготовка агента, которого вы *действительно* можете использовать.
Процесс "От нуля к агенту искусственного интеллекта".

(лонгрид)
Практически на всех собеседованиях любого уровня с вероятностью 90% вас будут спрашивать по теме "алгоритмы и структуры данных". Важные нюансы...

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

Ладно, разберём ещё несколько паттернов System Design, всего их немного, а глубоко эту темку разбираем с курсантами на треке по highload-системам...

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

=

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

В курс карьеры добавлены
143-й материал "Ваше портфолио 2026".
Наконец-то настал тот долгожданный момент, когда менеджер по персоналу каким-то волшебным образом выделил 10 секунд на просмотр вашего резюме. Вот 4 проблемы, которые нужно устранить, если вы хотите, чтобы они серьёзно относились к вашему портфолио...
144-й материал "Щедро делегируйте свои полномочия".
Если у вас есть подчинённые (например, вы сеньор, распределяющий задачи джунам, или тимлид/техлид), вы должны заниматься максимальным делегированием...

=

"Функциональные архитектуры" 161(+3) топиков.
Продолжаем тему DSL и декларативных языков для агентов.

Last Principles Framework: готовы 29(+3) задач, закрыты 13(+1) тем из ~20 первого уровня. Вы же понимаете например, почему если все эти ваши пайплайны, в т.ч. асинхронные и агентские (монадические цепочки) - не гомоморфизмы моноидов (которые строятся контринтуитивно, а не этими вашими псевдо-монадами на коленке), то разрушаются изоморфизмы архитектуры в целом?

=

"ЛаМПовое":

Каждый должен выполнять свою работу в облаке/vps на arch linux через ssh...

Пишем свою ОС...

=

Лаборатория идёт со скоростью самых лучших ментатов.
(продолжаю бесконечное ужесточение правил занятий :)

=

Память никогда не восстанавливает реальность. Память реконструирует. Реконструкция же изменяет оригинал, становясь внешней формой, содержание которой неизбежно страдает изъянами.
Руководство ментата, "Еретики Дюны"

Меняю основного провайдера.

Во время вчерашнего московского блэкаута отключился проводной интернет wifire.
Я им пользуюсь лет 15, ещё когда он был netbynet, а как слились/укрупнились, так "техподдержка" стала карго-культом (личное оценочное суждение). По качеству претензий нет, может 1-2 раза в год бывали короткие сбои, но в чате решалось быстро.

Но вот теперь, решить проблему стало просто невозможно - переписка моя в чате на скринах. В заключение спросилось "ваша проблема решена?" - "нет", и показалось окно "оценить удовлетворенность 0-10", я хотел поставить 0, а оказалось, его некуда вводить, а кнопка не доступна :) Ну зато по kpi всё отлично.

Надо ли продолжать работать с провайдером, у которого такая техподдержка, вопрос риторический. Особенно когда весь подъезд залеплен десятком объявлений "быстрый интернет в квартиру за один час" :)

Но самой ситуацией совершенно кстати не удивлён, и дальше будет только хуже.
No Future.

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

Когда в самом начале очень быстро получаешь Big Ball of Mud, и далее как Микеланджело начинаешь постепенно отсекать всё лишнее, чтобы получить идеальную систему :)

И спрос на это однозначно будет расти, потому что вся эта история AI-программирования по сути - бесконечная борьба с недетерминированностью, которая по определению не может закончиться успехом. Сначала были промпты, потом контекст, потом вики, потом спеки, потом харнес, потом loop, теперь вот graphify (компилируем код через ast и доки в компактный граф с узлами, связями и отчётами), экономия токенов почти в 100 раз (правда только в единичных примерах:).

И этой осенью 💯 мы опять услышим тут что-то новенькое, которое по сути будет всё тот же очередной развод гоев "к пониманию нейронками кодовой базы". Продавцы курсов "AI для разработчиков" дико бешено озолачиваются :) Ну реально, эта темка по объёму того, что надо изучить, уже в разы превосходит классический бэкенд и devops например, а выхлоп крайне мутный в отличие от. По сути буки и казики.

p.s. Вот ещё кстати до кучи: envoy
Envoy creates durable, invite-only spaces that agents, tools, and people can read and write through CLI or MCP

В продолжение вчерашнего "Продавцы курсов "AI для разработчиков" дико бешено озолачиваются" - прислал сегодня в личку мой любимый цветной банк.

ИИ для руководителей
Приглашаем на интенсив в Москве 11—12 сентября.
За 2 дня эксперты из Центрального университета, Норникеля, Сбера и других бигтехов помогут ввести нейросети в бизнес‑процессы: от делегирования рутинных задач ИИ‑агентам до создания рабочих сервисов без существенных временных и денежных затрат.
На тренинге Gogol School вы по‑новому взглянете на внедрение изменений в эпоху ИИ.
До 1 сентября — скидка 20 000 ₽.

Это даже не цена, а скидка, Карл )))
Лох не мамонт, никогда не вымрет.

Но само предложение совсем никудышное с т.зр. маркетинга. Зачем мне "по‑новому взглянуть на внедрение изменений в эпоху ИИ"? Что мне это даст-то?

Я бы вот так например пиарил подобные тренинги-шменинги:

Люди работали вертикально в течение 300 000 лет. Мы перешли в сидячую позу только потому, что 40 лет разработки сложного программного обеспечения требовали экрана и клавиатуры. Но когда ИИ-агенты выполняют работу с кодом самостоятельно, сидение за столом теряет свою цель. Вы теперь можете работать с искусственным интеллектом на ходу, в парке, на пляже, в кафе, в любой точке мира, просто удерживая одну физическую кнопку на телефоне и диктуя раз в час одно предложение на выполнение задания!
Как? Легко и просто! Эксклюзивно всего за 15 часов под ключ на нашем тренинге ГоголСокол!

(на картинке обложка Le Monde июль'26, которой завален весь Париж: "Все ненавидят ИИ")

Из сегодняшнего чата:

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

- в пятницу что-то задеплоили? )

- практически =) -- кто-то в команде включил разбор ошибочных задач в пятницу вечером (а там маленький батч был), к субботе развалился кликхаус из-за фонового мержа большого количества маленьких part'ов."

Вы знаете, что делать :) Самое время отправить в прод что-нибудь позаковыристее.

А тимлидам пора традиционно накидать команде побольше тикетов "на понедельник".

p.s. в 0:22 ребята пишут: "сегодня весь день инциденты решал в честь пятницы."

Агенты выглядят продуктивными лишь потому, что быстро генерят код. Да только вы проводите рабочий день, возясь с Клодом, который основывается на файлах проекта, которые он видит, затем объясняете решение Codex, который основывается на своих локальных данных, затем засылаете результат в Hermes, вручную устраняете противоречия, и этот loop тянется бесконечно.
 
Что толку, что у вас 32 агента, если ни один из них не видит контекст, который связывает их всех, всю их работу в единый асинхронный пайплайн. А так-то каждый агент прав в своей собственной маленькой вселенной, но в целом их активность скорее отбрасывает проект назад, а ты превращаешься в диспетчера и становишься самым узким местом и самым слабым звеном.
 
Сколько часов в день ты тратишь на перестройку агентского контента и бесишься, когда агент как в дне сурка утром снова спрашивает "а что собственно мы вообще делаем??"?
 
Самое глупое -- это покупать AI, а затем заставлять каждый инстанс погружаться в работу с нуля. Например, 10 миддлов каждый день тратят по часу на такую бессмысленную возню. Час работы каждого стоит 1000 рублей (~200k).
10k × 5 дней = 50 тысяч рублей в рабочую неделю сгорает в никуда,
и за год это потеря бизнеса аж 2,5 миллиона рублей, которые можно было бы направить "на фичи".
 
Каждое новое "рабочее место" агента должно приносить явный доход - например в плане роста продуктивности, ведь это всё можно в айтишке достаточно ясно измерить, и нету из kpi ничего более идиотского, нежели токенмаксинг. Но без общего контекста такой подход приводит ровно к обратному результату: больше параллельной работы богу агентов, больше противоречивых предположений и больше программистов, которым платят за тупое согласование результатов.
 
Тут мне надо что-нибудь вам продать, "со скидкой 20,000 рублей" :)
 
Но я лучше переложу ответственность на вас, напомню про новый тренд на смену всем этим лупам: graphify для быстрой загрузки контекста в сжатой форме.
Turn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph.

Ну а мой подход менее инженерный и больше формальный, через DSL. В ФА добавил "Формализация спек в КНФ"

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

Во-первых в России 🇷🇺 полно обёрток вокруг любых моделей, в том числе и самых последних, которые работают прекрасно и стабильно через стандартный API, я год активно пользуюсь и ни разу не было никаких проблем.

Во-вторых, ну наверное любой миддл сегодня скажет, что завязывать проект на одну конкретную версию библиотеки/сервиса... это наверное едва ли не самый первый анти-паттерн из всех first principles.

Есть такое правило тринадцатого удара: если часы бьют 13 раз, то это ставит под сомнение не только последний удар, но и все предыдущие 12.

В нашем курсе карьеры в частности недавно публиковал материал "как правильно составлять портфолио с проектами в 2026-м" - чтобы никого не распугать :)

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

Гарри Поттер и Методы Математического Мышления

Книга 1. Гарри Поттер и Неорганический Интеллект.

Глава 20/23 (и все предыдущие). Две стороны одной петли

Это был сон Комбинатора Мерлина — память о том, как строился Хогвартс, как четыре основателя склеивали реальность комбинаторами S, K и I, не зная, что через тысячу лет их творение станет полем битвы между типами и их отражениями...

Гарри увидел себя со стороны. Он стоял на одной стороне петли. Драко — на другой. Между ними — пустота, которая была не пустотой, а гомотопией, непрерывным путём от одного состояния к другому.
— Унивалентность, — прошептал Гарри во сне. — Если два типа эквивалентны, они тождественны.
— Но мы не тождественны, — ответил Драко из другого конца сна. — Мы эквивалентны. И это — разрыв...

Гермиона закрыла блокнот.
— Ты функтор, Гарри. Драко — естественное преобразование. А я — категория.
Я Бесконечность, в которой все планы существуют одновременно...

Гарри поднял руку и начертил в воздухе последний тип:
∀X. (X → Реальность) → (Реальность → X)

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

По неведомым причинам этот тип решили переписать с нуля: другая внутренняя структура, другая реализация.

Ты должен гарантировать, что после смены реализации ни один модуль в проекте, ни существующий, ни будущий, не должен заметить разницы.

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

Сюрприз, но это не сработает, патамушта лемма Йонеды (буквальное совпадение по сигнатурам не гарантирует согласованности с гомоморфизмами, не даёт естественное семейство биекций, диаграмма не коммутирует).

Малышам полезно вспомнить утиную типизацию и LSP, если конечно это проверяется вашими тестами. До изоморфизма Карри-Ховарда, понятно, никакими тестами не добираемся, но хотя бы приближаемся.

А с ментатами, как гарантировать корректность такого рефакторинга, разбираем в Last Principles Framework.

Думайте.

.

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

Ура, понедельник!

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

Сильная корпоративная культура превосходит всё. Но даже самая сильная культура прогибается под тяжестью современного программного обеспечения. Сложность слишком велика.
Вам нужны циклы обратной связи: тесты, хорошая система типов, и наблюдаемость/прозрачность...

+ Вам надо автоматизировать общие/рутинные задачи: это единственный способ масштабирования команды...


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

Подавляющее большинство книг и курсов по программированию — это часто просто сборник чего попало, не учитывающий главное, просто описание инструментов. *Учиться* профессиональному программированию это совсем другое, нужны совсем по другому подготовленные материалы.
А когда потратил на советы искусственного интеллекта кучу времени?
А по итогу не можешь написать простой алгоритм или сделать простой веб-проект, и пишешь ему: "это же не работает!", AI просто ответит "извините, я был неправ тут и тут, спасибо что обратили внимание."...

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

Маленький набор (эксклюзивно для донов) на занятия для начинающих с полного/около нуля, 3 места закончились за 1 час 20 минут.
Набор последний, продолжение будет к зиме или в 2027-м...

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

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

Продолжаю выкладывать для донов материалы СильныхИдей.
Начинаем новый модуль "Интерфейсы и абстракции".
102. Антипаттерн "Интерфейс должен быть проще реализации"
На любой вопрос по поводу интерфейса можно ответить очень точно, получив в ответ ответ на вопрос "а как будет выглядеть формальная спецификация?"

Мега-материал (БАЗА) по теме "Интерфейсы и абстракции".
103. Что такое абстракция в программировании?
Мы должны выйти за пределы двоичного определения того, является или не является что-то абстракцией, и вместо этого открыть для себя новый семантический уровень мышления, на котором мы парадоксально можем быть абсолютно точны -- ещё более точны, чем даже на уровне синтаксиса кода...

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

=

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

В СильныеИдеи добавлены материалы
"154) Надо ли тестировать тривиальный код?"
Почему Дядя Боб ошибался, и как правильно с т.зр. TDD...
"153) Простой пример формальных инвариантов"
Инвариант сам по себе это не просто ассерт с соответствующей проверкой. Это абстракция, это вещь формальная, и как мы её используем и определяем, зависит от выбранной логики. В простейшем случае, чисто на уровне кода, никакой логики нету (точнее, вы так субъективно (и ошибочно) полагаете)...

В раздел "Элитный программист" добавлен материал
101) Вглубь потока и deep work - 2
Люди, достигающие макропотока, поступают наоборот. Они как серферы используют энергию волны, на плоских участках раскачиваясь с помощью ног, чтобы поддерживать собственную скорость. Вам достаточно сделать для этого совсем немного...

=

"Функциональные архитектуры" 163(+2) топиков.

Last Principles Framework: готовы 31(+2) задач, закрыты 15(+2) тем из ~20 первого уровня. Вы же понимаете например, когда ваши асинхронные пайплайны бесконечно ломаются, на самом деле корректная работа пайпа будет просто неотъемлемое свойство правильно реализованной композиции Клейсли?

=

"ЛаМПовое":

Гарри Поттер и Неорганический интеллект. 20/23

=

Мы здесь, потому что это трудно 💪🏻

=

Это был типичный подход ментата - сосредотачиваться на вопросах. Они накапливают вопросы так, как остальные люди накапливают ответы. Вопросы образовывали свои паттерны и системы. Это придавало проблемам форму.
Особую прелесть этим конструкциям придавали их временность и текучесть.
"Капитул Дюны"

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

Не знаю, как вообще сегодня не вести такой список? Цифровизация своего опыта, своей карьеры. Резюме это не совсем то, как минимум в нём должен быть раздел "Проекты", который будет особо актуален, когда уже ведёшь переговоры по офферу. Гитхаб получше, но он всё равно чисто техническое хранилище, а нужен (лучше) свой сайт портфолио презентация, qr-код раздаёшь всем, и ведёт он конкретно на страничку с твоими проектами.

Следующий шаг это прокачка личного бренда (через блог прежде всего), я тут помогаю индивидуально, но за последние лет 5 всего *один* этим реально занялся, и где-то человек 10 периодически упоминают это как хотелку, которая конечно никогда не реализуется. Как только стал что-то оттягивать, считай забросил 100%

Йоги распознают до 30 типов сомнения, какой у тебя?

Многие думают, что тут надо прямо из штанов выпрыгнуть, чтобы выглядеть идеально в чужих глазах, но фишка просто в том, чтобы эйчар (а лучше CTO) из "ты кто такой?" сразу переходил к "хочу тебя нанять", для чего достаточно грамотного раздела "Проекты".
Да, тут есть нюансы разные конечно, например простое информирование это одно, а создание желания тебя нанять это другое, и т.п. Но прежде всего вам просто надо дать хорошее структурированное понимание вашего опыта, просто компактно рассказывайте о нём, и не надо тут как-то особо стараться и париться.

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

Один из ключевых показателей мастерства в программировании -- это быть одержимым деталями. И сегодня он стремительно сходит на нет. Да, от нас требуют фичи, требуют понимания бизнеса, и это нормально, однако прежде всего мы всегда должны стремиться к совершенству в своём прямом ремесле.
 
Это буквально значит писать вручную код ради самого кода. Это также означает размышление о глубоких аспектах программирования (computer science, math), которые мэйнстрим не воспринимает вообще. И в конечном итоге по заветам Дейкстры открыть для себя новый семантический уровень мышления, на котором мы (а теперь и искусственный интеллект) как недетерминированные сущности парадоксально можем быть абсолютно точны -- ещё более точны, чем даже на уровне синтаксиса кода.

Продолжаю работу с ментатами 🤓

...Чуть лучше разобрался с работой вложенных лямбд в Java. Заметили в коде проекта баг, который связан с этим делом.
Код был написан исходя из неверных предположений и делал не совсем то, что от него ждали. Проблему заметил тимлид. В том коде хотели выполнять некоторую операцию в чистом контексте, операция передавалась как лямбда в метод выполнения задачи. Всё это было обёрнуто методом forEach какой-то коллекции. Но оказалось, что в чистом контексте происходило только создание лямбды, а сама же операция выполнялась в рамках основного контекста.
В общем мы попали в ситуацию, когда одна лямбда создавала другую, которая потом выполнялась в рамках forEach(), а код был написан так, будто вторая лямбда не создаётся, а сразу выполняется.
Как меня всё это запутало. Но потом стал разбираться с темами создания и работы лямбд, подключил ИИ к объяснению происходящего и вроде удалось понять что там происходит и в каком порядке вызывается. Теперь буду с особым вниманием писать код в таких местах, чтобы самому не оказаться в такой ловушке.

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

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

...После изучения TOP, в голове так и крутится что типы это состояния, я состояния - это типы.

...Возврат из репо дефолтной sql ошибки не понравился, решил оберунть в кастомную ошибку с nil полем,
не заполнил nil поле, получил панику на проде при попытке логирования

...Если подвести общий итог. Солвер — не про то, чтобы получить ответ, а про то, чтобы обнаружить, что вопрос был задан неточно. Ответ он даёт мгновенно.

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

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

...В примере 2 задал имплементацию класса статистики BonusAccountStats с реализацией plus, чего делать, конечно не надо было, так как:
теряется гибкость задания Stats (по сравнению с Max);
BonusAccountStats начинает знать про plus.
Это противоречит идее универсальности использования моноида. Оставил как напоминание себе.
В примере 3 доработал пример 2, чтобы довести моноид до группы. Пришлось избавиться от вычисления максимума в статистике, так как при откате для него нет обратимой операции.
В примере 4 моделировал движение робота как мы это делали в одном из курсов через задание смещения относительно текущего положения. Группа получилась абелевой, так как в исходную точку можно вернуться с помощью инвертированного набора исходных шагов вне зависимости от их порядка.

🔥

...Да, вы можете записать в SKILLS архитектурные шаблоны, и будете получать полезный фидбек. Эти скиллы отлично работают, когда вы запускаете их на своём компьютере. Вы получаете полезные комментарии, исправляете то, что стоит исправить, и двигаетесь дальше.

Но как только вы запускаете это в общий рабочий процесс... Это будет ужасно. Шум становится просто невыносимым. Вы начинаете тратить кучу времени просто на просмотр комментариев нейронки.

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

У вас есть довольно странные и оригинальные внутренние правила, которые отлично работают в вашем проекте, но как привлечь к этому AI, не сжигая кучу токенов и не занимаясь кропотливой настройкой универсального AI-фреймворка?

Спалил эту фичу в "Функциональных архитектурах",

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

Твой босс со старой работы, с которым вы расстались в хороших отношениях, занимается обработкой счетов-фактур от разных компаний, в каждой из которых собственные форматы и правила подтверждения. Код представляет собой несколько сотен if-ов, и только продолжал разбухать :)

Ну, начитавшись и насмотревшись хайповых блогов и видео про искусственный интеллект, как он типа здорово пишет код и распознаёт вообще что угодно, CTO решает прикрутить к своему легаси нейронку, которая потенциально действительно умеет классифицировать такие счета и решать, какой именно обработчик применить. Он находит какого-то супер-гуру, который за скромную сумму в 100500 миллионов рублей добавляет в проект "автоматизацию с помощью AI", и в демо-режиме на тестовых данных вроде бы всё идёт нормально. Но когда эта "автоматизация" получает реальные данные, проект резко начинает сыпаться...

Дело вот в чём: в тот момент, когда вы применяете магию искусственного интеллекта к прекрасно отлаженному, но детерминированному рабочему процессу, правила кардинально меняются. Один и тот же запрос может пойти по другому пути, пропустить важный шаг, и всё равно вернуть 200 OK.

В этой компании уже были 102 пакетика логов, 75 ампул с метриками, 5 комплектов распределённой трассировки и opentelemetry, солонка, забитая дашбордами в grafana, и целое море алертов всех цветов и степеней критичности. А также поллитра promql, квартальная доза сессий в кликхаусе, и большой запас эндпоинтов для health-чеков. И при этом они сидели и просто смотрели, как падают поды...

По их традиционным стандартам все показатели были в зелёном режиме. Да только всё перестало работать :)

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

Период полураспада очередной AI-парадигмы сейчас составляет где-то 1 месяц.

Недавно предполагал, что осенью в темке AI точно придумают очередную фичу (шоу должно продолжаться) "чтобы курсы продавать", а вот уже например Context-as-a-Service (Context-First). Год назад это была в основном теория, а сейчас уже массовый прикладной карго-культ тренд.

А осенью явится какая-нибудь нейро-символическая инженерия, и все бросятся массово изучать Prolog и солверы. Думаю, уже таки совсем недалеко и до полноценных формальных подходов.

Продолжаю работу с ментатами 🤓

Кажется, уже пора рефакторить, потому что архитектура получилась не такая гибкая, как я планировал)

Ну да, и это при том что мы ещё по сути и не начинали :)
"Дипломный проект", 7-е задание из 45.

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

...не рассчитал время и график - завалили

Я уже не раз на эту тему говорил, все свои любые сроки-прогнозы, пусть даже самые пессимистичные на ваш взгляд, сразу умножайте x2 x3, тогда получите самую оптимистичную оценку :)
Классическая рекомендация - Голдратт "Критическая цепь"

...Очень частый паттерн в реальных Go-репозиториях (Uber, многие внутренние сервисы на github, шаблоны типа golang-standards/project-layout): для каждого struct, у которого нужен мок в тестах, через mockery/moq механически генерируется интерфейс
Это ровно "Extract Interface": единственная продакшн-реализация -- orderService, интерфейс существует только ради DI/мокирования в юнит-тестах, а не потому что появилась вторая содержательная реализация.

...Но когда я разбиралась с Hibernate для данного задания, я выяснила интересную вещь: из-за того, что объект Entity не содержит бизнес-логики, мы не используем многих фичей Hibernate, таких как dirty checking, lazy loading.
И в нашем случае вместо Spring Data JPA можно использовать Spring Data JDBC. Он вообще не использует Hibernate. Вот его уровни:
Spring Data JDBC -> JdbcTemplate (надстройка Spring над plain JDBC)-> JDBC -> Postgres
В то время как Spring Data JPA:
Spring Data JPA -> EntityManager -> Hibernate -> JDBC -> Postgres
Не будет накладных расходов на прокси, n+1. При этом, это будет тот же удобный CRUD Repository, к которому привыкла команда, но без накладных расходов ORM.

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

...После понимания, что у нас есть уровни, до меня сейчас дошло, что не надо думать обо всех уровнях сразу, и вспомнил про bottom to top проектирование на ООАП3. В принципе, на данном этапе, мне кажется это и к фп тоже применимо, тк каждый уровень предоставляет типы, функции, и мы просто потом используем его. Потому что я прямо зависал по долгу над тем как "всё оно вместе" должно общаться. Сразу после понимания уровней это не пришло. Тут конечно надо дальше менять мышление, потому что программировать только один уровень, и не думать о 10 других почему то трудно.

Это удивительно, но даже тем, кто активно использует AI, подчас приходится объяснять эту базу: если что-то не получается, вините не модель и не агентов, а себя :)

Смотрите, какой из трёх слоёв у вас сломался. В 98% случаев у вас не получается агентная инженерия ровно по этим причинам.

Ну а далее остаётся принципиальная неполнота знаний модели и её недетерминированность, которые решаются только вашими скиллами декомпозиции и проектирования (в частности, формализация проектной семантики), но это всего 2%.

И ещё такой нюанс, что например антропиков все пинают что они дескать массово воруют инфу из книг, скупают их грузовиками, сканируют и сжигают, да, ну так по сути именно таким способом только и можно создать хорошую модель! А жпт например обучают на куче сетевого мусора, ну и. Поэтому рулят Клоды прежде всего, вы просто не умеете их готовить.

При том, что качественных технических книг больше не будет, и развитие цивилизации остановилось :) Писать их больше некому - на смену пришёл тотальный нейрослоп, и АI теперь будет только пожирать "за хвост" самого себя.