Лаборатория Математики и Программирования Сергея Бобровского

🔥 ТЫ ПИШЕШЬ КОД, НО МИР РУШИТСЯ? 🔥 Знакомо? заказчик приносит «требования», которые на поверку — фантастический роман с элементами бреда. Ты делаешь «как просили», а в проде — кот летит на скорости 200 км/ч, инварианты горят, а космические лучи добивают последние биты. 💀 ДРУЗЬЯ, ХВАТИТ ВЫЖИВАТЬ В ХАОСЕ. Я собрал всё, что реально работает, когда программа весит не 100 строк, а 100500. Никакой магии. Только то, что отделяет сеньора-огрызка от инженера, который спит спокойно. 🟢 Почему тесты — это ложь и самообман, если не понимать одной простой вещи про непрозрачность. TDD не спасёт, если алгоритм внутри — чёрный ящик. Но я расскажу, как сделать его прозрачным. 🟢 Функциональная архитектура — не про «всё immutable». А про то, как сделать побочные эффекты ручными и управляемыми. Да-да, ФП не запрещает side effects, он их приручает. Наконец-то. 🟢 Инварианты — это не страшное слово из матана. Это «кот не едет быстрее 100 км/ч». Если нарушился — значит, у тебя баг. И точка. Я покажу, как ловить такие нарушения на Берегу. 🟢 Рефакторинг по-взрослому: новая версия функции не имеет права ломать старый интерфейс. Звучит банально? А теперь добавь сюда время, состояние и абстракции — и получишь настоящий ад. Или дзен. Смотри внутрь. 🟢 ООП как способ повторного использования? Мечта, которая превратилась в кошмар. Мы не просто не решили проблему — мы ещё сильнее запутались. А DI и ADT путают все подряд. Я распутаю. 🟢 Visitor — мощный, но опасный. У него есть тёмная сторона. Я её покажу. И да, анти-Visitor существует. 🟢 Глобальные ошибки эмерджентности — это когда каждая деталь работает идеально, а вместе — полный разнос. Интеграционные тесты дорогие, юнит-тесты бесполезны. Как выжить? Есть способ. 🟢 Исключения: «просто не вызывайте функцию с пустой коллекцией» — это ответ джуниора. А что делать, когда таких вызовов тысячи? Ответ внутри. 🟢 И главное: как думать о соотношении абстракции и реализации, где грань между генерацией кода через LLM (спойлер: нельзя, но есть нюанс) и ручным контролем. ЭТО НЕ ТЕОРЕТИЧЕСКИЙ ТРЁП. Это хардкорная польза без воды. Ты перестанешь гадать «а правильно ли я строю архитектуру?» и начнёшь просто брать и делать. С инвариантами, явным временем, управляемыми эффектами и без страха перед эмерджентностью. 💰 Цена — как чашка кофе (с пироженкой). Польза — экономия нервов, дедлайнов и карьеры. (силлабус гайда) Ставь 🔥 если тоже ловил кота на скорости 200 км/ч. И переходи по ссылке — там твой новый уровень работы с большим кодом. 🚀 Жми сюда: Programming in Large: продолжение После 11:59 по Гринвичу я закрываю доступ к гайду по текущей цене 2,500 рублей, и через минуту верну его обратно за 999 999 999 долларов. Шучу, не так уж и много. Но, вероятно, примерно вдвое больше.

Программисты общаются в слаке и жире, и затем программируют в своей ide. Где-то между этими двумя вещами контекст перестаёт корректно существовать. При каждой такой полуформальной передаче информации происходит утечка, и каждая такая утечка обходится дорого. Это стабильно растущий налог на хрупкий контекст, и ваша команда платит его каждый день. Собственно, с чего ещё лет 30 назад начинал любой уважающий себя "консультант по оптимизации бизнес-процессов"? Прежде всего выстраивал в организации жёсткий документооборот с прописыванием ролей. Была такая "Золушка" НТЦ ИРМ (и сейчас кстати работает, смотрю), отчёты шли на стол Лужкову, три цвета выделялись выводы, и те подразделения, кто выделялся красным, ужасно паниковали, реально ) Я откуда знаю? Писал про них статьи в 90-е, а местным пацанам немного помогал в освоении IBM Lotus Notes -- реально платформа была топчик 🔥 но потом говномикрософт 💩своим мега-баблом тотально продвинул в Россию свои "решения", как хорошо, что его больше нету, хоть бы никогда и не было больше. ...А сегодняшние тимлиды CTO CEO такие "что это?? нафиг нам не надо, инфоцыганство" 🙈 Ну ок)

5-й сериал Programming in Large: продолжение (на основе СильныхИдей для ментатов) Предыдущие сериалы: 1. БАЗА программной инженерии 2. Software Design с акцентом на Programming in Small 3. SOLID-26 4. Software Design с акцентом на Programming in Large Кто хочет взять все пять, подождите, сделаю бандл со скидкой. 17 материалов, 79 файлов, 170 тыс. знаков чистого текста. Цена 2,500 рублей (завтра повысится) => Проектные требования или проектная онтология? Прежде всего, всегда исходите из того, что "требования заказчика" всегда надо воспринимать как "фантастические представления заказчика о требованиях" :) О пользе формальных спецификаций Когда здесь остановиться? Как вообще правильно думать о соотношении абстрактной спецификации Abstract с нашей реализацией Impl? Можно ли генерировать код из спецификаций? Особенно с учётом последних достижений LLM? Нет, вы не можете это делать... Но есть и хорошие новости. И снова про тесты и TDD Какой бы алгоритм ни был скрыт внутри функции Foo, он полностью непрозрачен со стороны, поэтому тест не справляется со своей базовой ролью спецификации и документации... Функциональная архитектура - что это? Максимально простое определение функционального программирования, из которого естественно вытекает и понятие функционального проектирования... Наилучший способ разрабатывать большие программы Задача ФП -- не устранять "побочные" эффекты, а наоборот, делать их явными и полностью управляемыми... Инварианты и качественный код Понятие инварианта (некоего логического утверждения, истинного всегда в процессе работы программы, например, "скорость объекта Кот не может превышать 100 км/ч") неотделимо от качественного кода. Идея в том, что инвариант может быть нарушен только в том случае, если в вашей программе есть ошибка. Формальный подход к рефакторингу Подсказка: новая версия Foo должна быть инвариантна старой по своему интерфейсу... ООП как средство повторного использования кода Мечта многих поколений программистов -- создание реально многократно используемого кода. Однако можно однозначно сказать, что мы не то что до сих пор не разобрались с этим, а только ещё больше запутались. Состояние -- это время Абстракции -- это (почти) всегда про (виртуальное) время! А мы его эксплицитно учитываем крайне редко. Не путаем DI и ADT В любом случае всегда надо стремиться снижать coupling, а с DI получается, что вроде как зависимости явно описываются и внедряются в классы. Но так как с помощью DI мы можем легко заменять реализации зависимостей, получается, что внедрение зависимостей через интерфейсы способствует инкапсуляции, поскольку делается акцент на использовании интерфейсов вместо конкретных реализаций... Анти-Visitor В предыдущих выпусках мы разбирали, насколько хорош паттерн Visitor ("Всё, что вы знаете об ООП, неверно", "Ключевой паттерн Visitor в ООП и ФП"), но и у него конечно имеется своя тёмная сторона, о которой необходимо знать... Глобальные ошибки эмерджентности Интеграционные и сквозные тесты дорогие и медленные, и "покрыть" ими обычно удаётся лишь малую часть пространства состояний программы. Но глобальная корректность вообще никак не следует из локальной корректности... Три типа программных ошибок Любая система может сломаться: пользователь введёт неверные сведения, данные в базе окажутся некорректными, откажет сеть или интернет, проявятся обычные баги, в параллельных процессах возникнет клинч или гонка, космические лучи инвертируют бит, и т.д. Как правильно работать с исключениями Поспрашивайте знакомых программистов, и большинство пожмёт плечами и скажет: просто не вызывайте функцию с пустой коллекцией. Кто-то более продвинутый уточнит, что для этой конкретной функции надо задать соответствующее предусловие (например, в виде комментария). То есть ответственность перекладывается на вызывающего эту функцию... Как и зачем разграничивать рабочие процессы Agile называет это гибкостью, однако в реальной работе спринты не особо помогают избавиться от бардака... Техническая вишенка в заключение :) Микросервисы должны умереть => Programming in Large: продолжение <=

Аналитики Rankfender изучили кодовые базы 100 стартапов, которые сталкивались с проблемой масштабируемости. Схема ухода в даун в 85% были почти одинаковой :) Месяцы 1-6: Всё работает. Быстрые релизы. Довольные клиенты. Нет времени на архитектуру. Месяцы 7-12: Прогресс замедлился. Появились странные ошибки. Девизом стало "Исправим это позже". Месяцы 13-18: Каждая новая фича нарушала работу трех других существующих. Деплой стал крайне тяжёлым процессом. Месяцы 19-24: Наняли больше программистов :) Чтобы они хотя бы просто поддерживали проэкт в текущем состоянии. Про новые фичи пришлось забыть. 24 месяца: В реальности осталось только два варианта: переписать систему с нуля, или наблюдать, как она медленно умирает ))) = Однако, попробуй-ка объяснить это своему CTO :) Ответом будет глупенькое "тыжпрограммист" "тыжпрофессионал".

На днях говорил что "Никто не знает, как IT будет выглядеть через 2-3 года, но я почти уверен, что роль человека точно перестанет сводиться к координатору работы множества агентов через md-файлики. Скорее ситуация будет ровно обратная: сами агенты тоже уйдут под капот, и мы вернёмся к простому чату." и вот на эту тему уже мем появился :) Забудьте всю эту чушь про AI, все эти agents md и skills md, и оркестровку, и планирование, и всё такое прочее. Это не имеет никакого значения, это фактически та же возня с настройкой IDE и шорткатами vim. Да, приятно что-то настраивать, и это может даже немного помочь. Но нейронки становятся все лучше, включая в себя многие агентские паттерны. Сегодняшние "хитрости" лишь отвлекают ваше внимание от грозно надвигающегося завтрашнего дня. Сосредоточьтесь на том, что *не* меняется: - формулируйте для нейронок всё что можно, максимально чётко; - хорошо знайте и понимаете сами, что вы хотите; - будьте всегда ближе к делу; - предоставьте весь необходимый контекст; - напишите хороший промпт; - повторяйте. Ментатам я этот процесс усиливаю через формализацию, но в целом и эта схема будет давать результат в обычном чате с AI куда лучше, нежели самый продвинутый агентский фреймворк, которому по вы сути предлагаете самостоятельная додумываться до сотен нюансов, которые вы и сами не можете сформулировать даже в своей голове, не говоря уж о тексте в физическом мире :)

. Облако драгоценностей за неделю. Приватный клуб. Любимая темка: монолиты против микросервисов :) В 100500-й раз про это. Времена, когда микросервисы были ответом на все вопросы, закончились года три назад, хотя эффект от ошибочных архитектурных решений ощущается подчас только сейчас. Для донов-начинающих: 9 самых больших ошибок, которые совершают 98% начинающих на собеседованиях по программированию... Чему, куда и как учиться и развиваться начинающим в ИТ в 2026-м? Разбор сегодняшней ситуации по профессиям + подборка старых разборов (устарели немного лишь в технических деталях) Я заметил такую закономерность, что чем больше человек сам планирует *заранее* свою схему обучения программированию, тем сильнее бывает его итоговое разочарование. Люди больше времени тратят на обучение кодированию, чем обучению как пользоваться собственными мозгами... Продолжаю набор на занятия для начинающих с полного/около нуля, 6 мест закончились за 23 минуты. (я хотел только 2 человека взять, но вк затупил, не присылает оповещения; заглядываю в чат, а там... :) Для донов-неначинающих: 85. Избавляемся от зависимости от зависимостей-5 Скорее всего, в вашем проекте имеется не одна зависимость от сторонних библиотек, на которые достаточно серьёзно опирается ваше приложение, но вы либо боитесь, либо по каким-то другим причинам не хотите (нету времени...) заглянуть под капот и изучить её исходный код... (все старые материалы для донов быстро сгорают) = Новые материалы для ментатов Лаборатории. В СильныеИдеи добавлен материал "141) 5 законов DI". Разберём один из стратегических постов по использованию DI для классов со множеством зависимостей от гуру .NET development and architecture... В курс карьеры добавлен 134-й материал "Чему учиться в 2026-м?" Для начинающих. = "ЛаМПовое": Сериал "Дзен и искусство ухода за Arch Linux". 1. Storage Stack (уровень хранения данных) "Гарри Поттер и Методы Математического Мышления". Глава 4. Договор с реальностью. Мы здесь, потому что это трудно. 💪🏻 = Вырвите свои вопросы из породившей их почвы, и вы увидите клубок спутанных корней. Вопросов стало куда больше! ментат-дзенсуффист "Дюна" p.s. весна заблокирована до установки всеми Макса (Макс, иди нахуй)

Если бы я из 80-х попал в сегодня и увидел продуктовый магазин, упал бы в обморок, не поверив своим глазам. Я бы ни за что не поверил, что самая сложная задача при покупке продуктов -- решить, какую из 19 марок йогурта выбрать, или что в январе в Москве можно купить папайю. Когда я в 90-м приехал на работу в Париж, первые дни был в шоке от местного заштатного магазина уровня Магнита. В те годы я с трудом купил программируемый калькулятор на 70 где-то команд, который стоил по сегодняшним ценам 100,000 рублей, это была мечта. А игрушку "волк ловит яйца" - по цене 25,000 рублей, расхватывали в единичных московских магазинах электроники за один час. Но самым шокирующим стала скромная аптека на заднем дворе, которую я посчитал бы буквально волшебной. В 19-м веке выживал 1 ребёнок из 10. Из 18 детей английской королевы Анны ни один из которых не дожил до 18 лет. Американский президент Джеймс Гарфилд умер из-за того, что лучшие врачи не верили в существование микробов. Давление Рузвельта перед смертью составляло 260/150, но тогда не существовало элементарных лекарств от артериального давления. Я-80 с изумлением наблюдал бы, как вы расстраиваетесь из-за необходимости стоять в очереди из трёх человек в аптеке и неблагодарны за волшебные таблетки по бросовой цене. Я бы не смог понять, почему вы жалуетесь на цены на продукты питания, а не приходите в восторг от одной только возможности подобного изобилия. Это я к тому, что смысл жизни по большому счёту -- трудиться и внедрять инновации, чтобы создать более процветающий мир для своих наследников. Чтобы лучше жили не мы (мы уже живём сильно лучше!), а наши дети, но для этого нужна определенная жертвенность, самопожертвование во имя высоких и светлых идеалов будущего (что так ужасно не любят либералы). И, да, конечно, наши дети не будут страдать так, как страдали мы от проблем нашего времени, и они даже не оценят этого -- а мы, их родители, будем считать их ленивыми бездельниками. Всё это известно столетиями ("Отцы и дети" Тургенева). Но разве мои родители не делали то же самое для меня? Им приходилось беспокоиться о полиомиелите, скарлатине и множестве других страшных вещей, которые никогда не приходили мне в голову. Транспорт моей бабушки в молодости был ограничен лошадьми, а плохой урожай мог означать смерть кого–то из детей - жизнь, совершенно немыслимая всего через одно-два поколения. Поэтому моя цель как родители и ментора -- работать так усердно и так самопожертвенно, чтобы мои дети, внуки и ментаты могли жить жизнью, которая кажется испорченной по меркам моего поколения. Я надеюсь, что многим из вас уже не придётся беспокоиться например о раке так, как нам. Я надеюсь, что у вас буду невероятные технологии, которые облегчат вашу работу в отличие от нашей. Я надеюсь, что те проблемы, с которыми мы сталкиваемся сегодня, завтра полностью исчезнут. Следующее поколение будет испорченным? Возможно, более подходящим будет слово "удачливые" или "везучие". Или, возможно, они просто извлекут выгоду из тяжёлого накопленного труда тех, кто был до них, таким образом, чтобы они проводили свои дни, решая качественно новые проблемы. Именно для этого я и работаю, дорогие.

А вы что, сейчас реально не работаете (на себя)?? 40-часовая рабочая неделя -- это просто твоя социально приемлемая форма прокрастинации и нежелания брать ответственность за свою карьеру, свою жизнь, свою семью. Твои родители могут получать качественную платную медицинскую помощь? Твои дети могут круглый год кушать свежие фрукты и овощи? Мы в горящем доме, который AI сжигает всё стремительнее, и помощи ждать нам не от кого. Поэтому важно признать, что на нашу жизнь влияет множество сложных и неизмеримых факторов. Мы никогда не можем быть полностью уверены, что наши решения, сколь бы взвешенными они ни были, приведут к хорошему результату. Но мы можем немного повысить его вероятность, старательно и ответственно воспринимая посылаемые нам возможности. Мои тексты -- большая редкость :) нельзя откладывать практику. Потому что сейчас происходит абсолютный перелом -- технологическая сингулярность, и больше таких возможностей, как сейчас, больше у нас никогда в истории человечества не будет. Wirklich, ich lebe in finsteren Zeiten! -- Bertolt Brecht

А вы что, сейчас реально не работаете?? Вот вам "секретная" стратегия вхождения в инди-хакерство с нуля. Это очень простое решение, и оно действительно работает. Очень простое. 1. Выберите сложную проблему, которая стоит перед вами сегодня, и с большой вероятностью повторяется у других. 2. Создайте продукт: инструмент (оболочку AI), который решит эту проблему. Не оставайтесь в режиме разработки дольше, скажем, недели. 3. Запускайте продукт быстро, неидеально, и тратьте каждый день 1 час на то, чтобы улучшать его. 4. Создавайте продукт открыто, пишите в блоге, и используйте отзывы реальных пользователей для его развития. Нет лучшего ощущения, чем видеть, как пользователи (целых семь человек) работают с твоим продуктом! Вы не умеете программировать? Нет проблем, используйте искусственный интеллект. У вас нет денег? Не тратьте их. У вас нет времени? Сократите вдвое свои ежедневные 2 часа и 42 минуты использования социальных сетей. Вы уже счастливы и полны деньгами и энергией? Смело игнорируйте этот текст и продолжайте расслабляться!

Самая большая архитектурная ложь заключается в том, что работающая инфраструктура якобы означает работающую систему в целом. Это не так. Брокер работает исправно. Все сервисы подключены к интернету. Поступает множество сообщений. Информационные панели зелёненькие. И все же, каким-то образом, на выходе по-прежнему получается неправильный результат. С клиента берётся двойная плата. Возврат средств происходит до реальной оплаты. Заказ записан в базу данных, но ни одна из связанных с ней служб об этом не знает. Безобидное на вид изменение конфигурации прерывает работу, не вызывая видимых сбоев. Это и есть настоящая трудность в highload-системах (прежде всего, управляемых событиями). Они редко выходят из строя из-за масштабных инцидентов с инфраструктурной доступностью. Они выходят из строя из-за незначительных ошибок, которые проявляются в повторных запросах сервисов, неверного упорядочивания по времени, дублирующих записей и нарушения консистентности. 1. Поднимите эффекты на уровень типов (например, Async в F#). Любое изменение конфигурации, чтение БД, вызов внешней службы или запрос текущего времени, должны быть явно "заданы" подходящими типами в сигнатурах функций. Тогда даже "безобидное изменение конфигурации" не сможет прервать работу незаметно: оно станет частью цепочки эффектов, которую придётся обработать или задокументировать, иначе компилятор выдаст ошибку. Остальные рекомендации будут ментатам в Функциональных архитектурах и на консультациях.

А вы что, сейчас реально не работаете?? Идёте по улицам любого города Кремниевой долины, и вам с каждой рекламы лезет в лоб темка какого-нибудь AI-стартапа. Это не я, это инвесторы YC сегодня рассказывают. Пока вы расслабляетесь, ваши гораздо более умные собратья вовсю пилят "свой SaaS", понимая, что классическая работа программиста по найму исчезнет на 90% уже в этом десятилетии. Cейчас же уикенд! самое время клепать очередной MVP. Утром тренировка на часик, но не изматывающая. Затем заказываете себе вкусняшек - и фигачите допоздна как слепые кроты. Фоном включаете эмбиент или спокойное техно, ничего будораживающего. Я ставлю таже шум дождя, прибой etc. Можно добавлять лёгкий СДВГ в течение дня: суммарно на часик кусочки кино/сериалов/футбол/ютуб небольшими порциями, но очень умеренно. Дело не в том, что у вас нет времени, а в том, что вы впустую тратите то время, которое у вас есть. Мы живём в такое время, когда у нас есть инструменты, позволяющие быть продуктивными более чем в десятки раз, чем когда-либо, и всё же большинство людей тратят большую часть своего времени впустую. Но у окон возможностей есть неприятная особенность — они закрываются в один миг и без всплывающих уведомлений. И ты внезапно обнаруживаешь себя в безнадёжно отставших, и даже в курьеры тебя не возьмут. Моим ментатам по инди-хакерству помогаю индивидуально (бесплатно пока), ну и тут пишу для всех об этом, куда и как, и буду регулярно продолжать. (пророческая карикатура из советского Крокодила 1982 г. даже зарплаты совпадают!)

Гарри Поттер и Методы Математического Мышления Книга 1. Гарри Поттер и Неорганический Интеллект. Глава 4. Договор с реальностью. Невилл развернул мантию. На ладони лежал небольшой медальон из тусклого серебра. Никаких рун. Никаких камней. Только странный узор, похожий на две пересекающиеся петли. — Амулет Годрика Гриффиндора, — прошептала Гермиона. — Я думала, это легенда. — Нет, — Гарри протянул руку, но не коснулся. — Это — хранитель гомотопического уровня. Он не хранит заклинания. Он хранит чувство, что два заклинания одинаковы.

Продолжаю работу с курсантами 🤓 Курс "Ясные архитектуры" понравился, хотя постоянно приходилось заставлять себя подняться с уровня "перекладывания JSONов" выше и тогда идеи, заложенные в архитектурах получали свою актуальность! Вынес главную мысль, что код надо стараться писать а) иммутабельным б) инкапсулированным в) простым для понимания и модификации. И что работает это как с кругами Эйлера в известном меме (быстро-качественно-дешево) - все сразу невозможно и нужно постоянно искать правильный компромисс для своего проекта. В целом, кажется (кажется!), что если сейчас мне придется писать приложение нового для меня типа, то я сначала буду долго думать на какую архитектуру лучше переложить домен. И это круто, потому что ранее для незнакомого типа приложений я бы побежал в классический ООП(ну точнее этакая смесь "школьный стиль"/ООП/чистые функции, кого я обманываю?). Это при том, что данный курс ещё даже не с трека ФП, тут я просто привожу для первоначального знакомства несколько функциональных архитектурных паттернов. Фишка в том, что если например в ООП (где нету вообще никакой глубины по определению, да и никакого смысла особо) твой проект начинает экспоненциально запутываться с 50-100-200 классов/таблиц, и надо держать в голове кучу паттернов, чтобы это всё хотя бы не сильно запутывалось, то в ФП, по мере погружения в теорию типов (я уж молчу про теоркат) ты наоборот получаешь экспоненциально растущую продуктивность. Это очень крутой курс ("Функциональное проектирование"), который показывает, как можно заставить работать нейронку на максимум построив правильный промт изначально. И она тебе будет задавать нормальные вопросы и ничего лишнего. Кстати я сейчас пишу для Функциональных архитектур методику по "Математике DDD" (bounded context — это не просто архитектурный паттерн, это атомарная единица работы с нейронкой; формализую эту темку), в апреле будет готова. И всё больше и больше склоняюсь к тому, что инженерия агентов -- это сильно ограниченное. Никто не знает, как IT будет выглядеть через 2-3 года, но я почти уверен, что роль человека точно перестанет сводиться к координатору работы множества агентов через md-файлики. Скорее ситуация будет ровно обратная: сами агенты тоже уйдут под капот, и мы вернёмся к простому чату. Вот только искусство задавать соответствующие промпты будет подразумевать написание научной статьи на уровне PhD. А я этот подход предлагаю фактически уже прямо сейчас :) ИИ-нейтив фаундер строит компанию, которая работает со скоростью света (благодаря агентам), но сам он думает со скорость монаха (с глубоким фокусом и присутствием) пруф Точно так! на треке "Элитный программист" продолжаю сейчас цикл статей по супер-продуктивности (там же, напомню, есть и подборка по теме Monk Mode), только дополню мудреца: "...сам он думает со скорость монаха (с глубоким фокусом и присутствием) глубокими математическими концепциями".

Пред- и пост-условия, которые приходится явно прописывать в объектно-императивной реализации -- это фича, естественно присущая функциональному программированию по определению. Когда вы пишете чистый функциональный код, инвариантность в нём присутствует "автоматически". Так зачем вообще утруждать себя написанием "надёжного" императивного кода? Приличный компилятор незаметно для вас оптимизирует функциональщину в логически безупречную императивщину. Design by Contract мёртв (да он никогда и не был жив): его изобрели просто как супер-лайт-версию ФП для гоев, которая хорошо продаётся.

Массачусетский технологический институт опубликовал MathNet - открытую базу из 30 тысяч математических задач топ-олимпиадного уровня, аналогов нету. Только вот из России она никогда больше не будет доступна...

Вся моя работа теперь заключается в том, чтобы понять, как никогда не возвращаться к наёмной работе. Каждый день я просыпаюсь и думаю про себя: "Что мне нужно сделать сегодня, чтобы никогда не возвращаться к работе на дядю с 9 до 18?". Самое лучшее в отсутствии работы -- это больше не участвовать в созвонах. А то ты такой подключаешься к зуму вовремя, а там никого нет. Ты призрак или все остальные? ...Однако самозанятость погубила меня: если мне приходится отвечать на один-единственный звонок, весь мой день испорчен. Теперь, когда я много лет безработный, каждый божий день для меня одинаков: -ученики -код -прогулка -поплакать (попробую выйти на улицу и поплакать одновременно, чтобы сэкономить время) Если вы не придумаете, как зарабатывать во сне, вы всегда будете обменивать своё время на деньги.

Ну, с великим праздником: сегодня День Старого Программиста... Помню ещё в советских газетах писали злорадные новости, что знаменитый теннисист Джон Маккинрой после карьеры оказался никому не нужен, и теперь за 50 долларов специально проигрывает гейм всем желающим, которые потом хвастаются победной фоткой. А других знаменитых спортсменов -- например, боксёра Джо Луиса и бейсболиста Микки Мантла, нанимали пожимать руки туристам в казино Лас-Вегаса... Что тут можно сказать? Если вам под/за 50? Сделать акцент на опыт ("всю эту фигню и бардак что у вас я уже видал и исправлял десяток раз"). Хотя конечно опыт Delphi ну такое себе ) Не браться за новые темки, пытаться выехать на сильных имеющихся скиллах (например, С++ -- в 90-е на персоналках писали только на нём). Смириться с потерей статуса и дохода - на хх раньше не раз видал как 70-летний дед ищет любую работу программистом на полставки. А пытаться не проиграть в деньгах - это уже 100% проигрышная стратегия. В 45+ надо забыть про "качать права", цепляться нужно за любую возможность, рассчитывая хоть на какой-то рост через год... Хотя всегда вопрос, а где же ты раньше был, милок? Это всё однозначно хорошие и полезные рекомендации, а главный их минус, что они смешивают реальную ситуацию ("даже в 35+ сегодня уже опасно качать права") и заведомо проигрышную позицию ("остаётся только рабски прибедняться"). Главный плюс сегодняшней ситуации, что a абсолютно непонятно, что будет в ИТ даже через год, и b абсолютно понятно что сегодня любой разработчик может за неделю с помощью AI запилить MVP вполне качественного серьёзного сервиса, на создание которого ранее требовались многие человеко-месяцы профессиональных программистов. Поэтому моя рекомендация: создавайте своё дело, начьните с небольших услуг по автоматизации небольшим организациям. Изучите 1C. Сейчас в рамках импортозамещения и тотального навязывания искусственного идиотизма просто огромный спрос на автоматизацию того, что теперь формально считается "автоматизировано" по закону (но ни хрена не работает, и целый отдел девочек заполняет формы вручную). = Ладно, в честь праздника дарю всем вам, дорогие, мой материал с курса карьеры для ментатов "Вкат начинающего ИТ-предпринимателя в 2025-м" На прошлой неделе (август 25) я разговаривал с владельцем малого бизнеса (продажа мотоаксессуаров), который буквально тонул в электронных таблицах. Каждую пятницу он сидит допоздна и вручную копирует строки из Excel в Яндекс-Таблицы (зачем? я хз:). Кроме того, ему приходится отвечать на одни и те же сотни писем и сообщений каждую неделю. Для него это похоже на пытку... А для меня это выглядит как 100,000 рублей, которые ждут, когда их заберут. И для вас это тоже должно быть точно так. Малому бизнесу нет дела до гигантских приложений, и даже до облачных систем… Они заботятся об экономии времени и сокращении рутинной работы. Но конечно сперва придётся прилично попахать. ...И достаточно скоро у вас появится свобода, рычаги влияния и карьера, о которой вы всегда мечтали -- работа и жизнь на ваших собственных условиях.

От метапрограммирования к DDD через DSL. Модель мира Django: Всё есть таблица. Всё есть запись. Всё есть JOIN. Где это ломается? Например домен - документооборот с версионированием и ветками (как в Git). Он естественно описывается как направленный граф версий (теория графов + частичный порядок). Но Django тащит нас в Document - FK - Version - FK - Parent... И ты начинаешь бороться с фреймворком: рекурсивные запросы, CTEs, костыли для обхода графа через ORM (который для этого не создавался...). Путь Django: ты думаешь на языке домена, переводишь в голове в таблицы, пишешь ORM - и теряешь исходную структуру... Путь DSL: ты думаешь и пишешь на языке домена, нейронка транслирует в код, и ты всегда остаёшься на правильном уровне абстракции. DDD говорит, что делать: - выдели bounded context - найди ubiquitous language - сделай aggregate root Алан Кэй объяснял, почему это работает: потому что ты нашёл правильную математику домена и сделал её явной в виде DSL. А я в "Функциональных архитектурах" поясняю, как это делать.

Продолжаю работу с ментатами 🤓 Я больше не хочу экспериментировать с реорганизацией своего проекта и в очередной раз просить агента перетащить модуль из одного пакета в другой. Гораздо лучше правильно организовать этот и все следующие проекты в виде направленного ациклического графа модулей и зависимостей... Компания активно продвигает подход: сначала AI, потом все остальное, с чем мне пока сложно согласиться. Если задача занимает 2 минуты времени, то делаю ее на опыте без участия AI, пока не понял, есть ли в этом проблема... Чтобы AI делал работу за программиста - это иллюзия, нигде такого нету, если совсем не примитивные рутинные задачки. Это к сожалению ещё одна очередная тема, доказать менеджерам абсурдность которой невозможно. Разве что втягивать их в конкретику через рекомендацию "ну если AI может всё сделать, вот и делайте с ним сами". Мой код почти полностью соответствует примеру Говнокод / Спагетти / Школьный стиль. За несколькими исключениями имеет те же плюсы и минусы... TDD до сих пор не привычный подход для меня подход и если он эффективен, возникает вопрос - почему этому не учат сразу? Этот вопрос можно задать всему мэйнстриму в целом, подставив вместо TDD любую из 100500 полезных фич программной инженерии :) Каждый раз, проходя такие курсы, жалею, что в универе не было толкового обучения по ФП:) Подсадили на ООП... Честно говоря, в начале я думал, что уровень реализации — это «для разминки», всё очевидно. Оказалось, что нет. Самое интересное — это не if вместо if/else if и не кортеж вместо DTO. Самое интересное — это то, что каждая из этих проблем прячет потерянное намерение... Закончил курс по архитектурам, больше всего впечатлили функциональные концепции. Как же много можно достичь на уровне синтаксиса, какой элегантности. Очень понравились уроки про state monad, AST, DSL и capabilities. Аж F# решил в конце потрогать. Если, конечно, к этому и математику еще прикрутить… В какой-то момент поймал себя, что одну строчку кода пишу две 25 минутные помидорки. При этом конечно был уже сделан, тест, закомментирована его большая часть, и убирал комментарии увеличивая тестовую часть. Во время работы с ним стало появляться ощущение понимания Django... Смотря на все эти защитные трюки "от дурака" понимаешь, что если ты начинаешь в самом начале проектировать дизайн и типы как надо, то и нет необходимости на низком уровне делать какие-либо дополнительные проверки. Это все идёт из-за спешки, в погоне за временем и результатом. И стоит остановиться и посмотреть, что ты написал и начинаешь понимать, что тут проверка на проверке, хоть это и не асерты... Понравилась цитата Торвальдса из материала: Плохие программисты думают о коде. Хорошие программисты думают о структурах данных и взаимосвязях между ними Недавно разбирал большой кусок легаси-кода и вспоминал эту цитату. Код сначала казался страшным и очень запутанным. Но потом я постарался подняться немного выше и сосредоточить своё внимание на данных и том, что с ними происходит в целом. После этого всё стало гораздо проще, я увидел, как и куда перемещаются данные, понял зачем это делается. И как будто бы разглядел даже некоторую красоту в этом куске легаси, потому что на уровне данных вся картина воспринимается проще и ты начинаешь понимать, что здесь приняли неплохие решения, с учётом стоявших проблем. Цитата Торвальдса меня зацепила, поскольку она напоминает о том, что важно на самом деле. Буду стараться чаще смотреть на проект в первую очередь с точки зрения данных и их связей... Последний суб-модуль который я переписывал за уже уволенным пакистанецем, я просто по промпту из функционального проектирования взял и сделал отличный расширяемый парсер инвойсов))) Спасибо вам большое! Очень здоровый код, пусть не совсем про порт-адаптер, но зато если клиенты принесут новые форматы документво и там LLM как ocr-parser понадобиться – я смогу добавить его за минут 30 работы... Я использую реализацию паттерна "самодукоментррубщицся код", но через добавление логирования...

Хорошая новость-1: Начинаю индивидуальные консультации по теме Функциональных архитектур (пока бесплатно). Залифтим всю мощь теории типов, теорката и др math/cs с примитивного уровня PhD до ваших сложнейших, уникальных и неповторимых тикетов (рефакторинг легаси-сервиса с монолитной транзакции на saga с компенсирующими операциями... написание dto-маппера на 64 поля с разной вложенностью и агрегацией... генерация idempotency-ключа для массового импорта, хранить в редисе с ttl 24 часа...). Товарищи ментаты, кто а занимается на формате 2 карьеры, б активно использует в работе AI для написания кода, в чувствует что в результате всё лишь сильнее запутывается / впустую сжирается неимоверное количество токенов / агенты больше вредят / ну и вообще ничего не получается => пишите мне как обычно в рабочий чат, разберёмся :) Получите вашу любимую пошаговую инструкцию. Хорошая новость-2: Начинаю индивидуальные консультации по теме "как стать инди-хакером и создать соло-стартап на миллиард долларов" с вас 50% будующего бизнесса :) (пока бесплатно). Для тех же, кто пп. а и б из Хн-1. = Посмотрю сколько будет желающих если много, пока возьму несколько единичных первых (много званных, да мало избранных:).