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

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

А ещё показалось, что в луковой архитектуре, ну или том, подобии, что сделал я, не очень сложно тестировать бизнес-логику, по крайней мере в моём случае(Java + Spring). У нас же тут всё на DI и чтобы протестировать логику сервиса я могу просто в тесте вызывать методы этого сервиса, а ответ от БД замокать. И как будто получается почти то же самое, что и при переносе I/O в контроллеры. Также мы можем замокать ответы от сервисов/валидаторов в контроллере. Но возможно, что дело в Spring и его устройстве, а в других стеках всё иначе. Либо у меня пока мало опыта, чтобы осознать почему это плохо даже в Spring с его DI.

1. Какой контроллер мы можем считать "тонким"?
Тот, который вызывает лишь один метод или главное, чтобы такой контроллер не содержал в себе никакой бизнес-логики? И если контроллер будет вызывать валидатор, сервис, маппер, но при этом все эти вещи будут объявлены где-то в другом месте, а в контроллере нет никаких циклов/условий, то этот контроллер можно назвать "тонким".

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

Глубокие вопросы, и действительно есть довольно тонкий и неочевидный нюанс. Тут нужно продвинутое понимание, чем луковичная архитектура отличается от гексагональной; мы думаем, что делаем порты и адаптеры, но нет -- это просто интерфейсы и полиморфизм, сермяга совсем в другом (чистая семантика домена и частично подходы из DDD). Подробно разберём на "Функциональных архитектурах".

Что интересно, если копать эту тему глубже, то мы придём к тому, что доказали ещё 100 лет назад Тьюринг и Чёрч, и даже Гёдель... Может ли быть язык (формальные спецификации), описывающий предметную область, Тьюринг-полным? В целом нет, но в каждом проекте мы можем к этому стремиться.

Мне тут очень нравится подход святого Эдвина Брэдли, автора Idris - языка с завтипами и пруф-ассистанта (см его книгу "Type-Driven Development with Idris"), который он пытается хотя бы немножко, хотя бы на уровне Хаскеля (так-то Idris его рвёт как тузик грелку), вывести в мэйнстрим. Брэдли предложил более прагматичное понятие "PacMan-полный" язык :)

Если мы можем закодить на некотором "тьюринг-неполном" языке игру в пакмэн, значит, он подходит для 80%..98% повседневных задач.

Точно так же и тут: я покажу, как один, по сути, "PacMan-полный" в архитектурном смысле паттерн (не парадигма, не концепция, не универсальность, как в Clean или DDD) даёт невероятную, буквально магическую, силу. Подходит он не всегда и не везде, но когда попадает в цель...

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

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

В рамках ежедневной «работы над собой» продолжаю совершенствовать свой рабочий день в плане продуктивности по ЭП. Сейчас удается стабильно поддерживать сочетание хорошего утреннего планирования с четким следованием практики помидорок (со «скучными» перерывами) что дает очень хороший результат.
На самом деле периодически я просто в ужасе от осознания, сколько времени я тратил впустую – оценивая количество дополнительных дел, тем изучения в лаборатории, которые я успеваю сейчас делать, даже с учетом все равно достаточно низкой производительности. Но даже это небо и земля по сравнению с тем, как я жил до школы!..

Но вот несколько неожиданно очень расслабили длинные выходные. Не удалось сделать даже треть запланированного. Вообще давно уже заметил, что очень сложно: (1) дома и (2) в выходные поддерживать даже просто нормальную производительность (не то что высокую). И дело не в каких-то дополнительных семейных/домашних обязанностях, да и редко меня отвлекают. Просто даже сидя за компьютером как-то сложно сосредоточиться, мысли где-то блуждают...

Общение на уровне спецификаций
Проблема локализуется мгновенно. Мы не тратим время на отладку, а сразу обращаемся к спецификации. Разговор идет о фактах, а не о мнениях;
Сразу становится ясно, на чьей стороне ошибка. Это устраняет споры и взаимные обвинения...

...И я честно пошёл в репозиторий, нажал create issue, подробно описал свою проблему, и тут сработало то, о чём вы неоднократно говорили - мышление письмом. Как только я текстом сформулировал проблему, я сразу понял, где искать решение и вопросы исчезли :)

Изучаю материал "7 неочевидных проектных ошибок" в рамках HW, очень впечатляет. Особенно в части ревью. Как будто заметил там себя, в том месте где говорилось о том, что некоторые программисты боятся нелокальных изменений проекта и либо пишут только новый код, либо заменяют один модуль на другой. Нужно будет ещё и ещё почитать это материал. Чувствуется, что там очень ценные вещи заложены и их нужно хорошо осознать и прочувствовать...

Дочитал новые материалы. Два наиболее мощных момента, которые сразу пошли в дело: это [...] – честно говоря, для меня вообще просто бомба. Сколько раз я сожалел на следующий день, что не смог заставить себя вечером доделать какое-то дело, хотя время еще было. И хотя и признавал это проблемой, как-то даже не знал как к ней подступиться. А оказалось просто...

В этот раз я изучил материал "48) Тайные техники монахов, лучших спортсменов и элитных военных" с курса ЭП, из которого я узнал про концепцию [...]. И она реально работает! Так, я за 2.5 дня выполнил ДЗ по дипломному проекту, которое откладывал целую неделю, потому что задача казалась неподъёмной.
Буду продолжать использовать этот приём...

Сейчас как раз по этой теме продуктивности готовлю новый цикл материалов, математическая база 💪🏻 На неделе начну ментатам выкладывать.

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

Функциональщики, шах и мат! )))

.

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

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

Контейнеризация стала официально легаси-технологией! Будущее в этой сфере вновь за нативными подходами.

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

Нужно ли начинающему знать Far, IDE, линтеры, редакторы кода с подсветкой синтаксиса?

Когда желающим научиться программированию не удаётся достичь цели, в 98% случаев это происходит не из-за недостатка навыков...


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

Перейти на новый стек, попытать счастья в QA, AI/ML или DevOps, заняться другим фреймворком или языком программирования. Кто знает? Может в этот раз повезёт?..

Продолжение трека "Элитный программист": переходим к взрослой теме.
33) Какие принципы лежат в основе идеи экстремальной ответственности.
Ключевой характеристикой экстремальной ответственности становится то, что вы принимаете на себя личную ответственность за любую ситуацию, в которой вы оказались.


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

=

Первые сериалы из существенно переработанных и улучшенных материалов СильныхИдей (по сути четыре книги) доступны на бусти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-25
4. Software Design с акцентом на Programming in Large (new)

=

💪🏻

Мы здесь, потому что это трудно.
it's a privilege to do things that are hard.

"ЛаМПовое": DI в Си, визуализация зависимостей...

=

Для гайда про функциональные архитектуры из-за странных законов делаю новый анонимный движок. В функциональной архитектуре он занял ~150 строк handmake кода на пыхе (включая авторизацию, работу с базой...) :)
Как тебе такое, жпт и клауд клод?

Грэм написал Viaweb на Лиспе, для проектов того времени вообще было характерно использование экзотических технологий, хотя всё же самым массовым уже считались Си и С++, а в России также очень быстро набрала популярность Delphi. Так вот, Грэм безусловно отличался стратегическим бизнес-видением, но не стратегическим техническим. Это была такая своеобразная смесь commitment bias и confirmation bias + endowment effect + sunk cost fallacy.

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

"Для Viaweb мы часто делали три-пять версий в день."

Потом Яхо купил Viaweb, после чего взялся переписывать его с нуля на плюсы, но по тем временам это было чрезмерное заглядывание вперёд -- в частности, из-за полного отсутствия электронных платежей. Проект был переделан в Yahoo! Store, ну и потом молодые эффективные менеджеры, как обычно, фактически угробили сам Яхо :)

=

Так вот, по сути Главный Вопрос: где баланс между глубоким техническим погружением буквально в конкретную версию фреймворка и в один проект с кучей конкретных библиотек с одной стороны, и между хорошим пониманием computer science, теории типов, функционального программирования, и прочего оверинжиниринга?

Я его нашёл математически точно :)

(Ну не то чтобы прямо я сам... через выжимки из выжимок из выжимок трудов десятков святых computer science; кто ещё, физически находясь в России, этим занимается?)

Для ментатов готовлю гайд "Функциональные Архитектуры".

...Но есть один нюанс: Грэм написал Viaweb конечно же на Лиспе :) Это примерно как сегодня закодить SaaS на Хаскеле. Поэтому, необходимое отступление.

10-кратный разработчик -- это в значительной степени миф, поддерживаемый токсичным мэйнстримом, который ценит прежде всего превышение производительности (скорости выката фич) над качеством. Рост производительности в целом иллюзорный: чем больший срок возьмём, тем больше мэйнстрим будет проигрывать по суммарному времени разработки. Ну, это эпистемологический double bind, который эффективным менеджерам объяснять бесполезно.

Я неоднократно работал с так называемыми разработчиками 10x, и многие из них были реально быстры, потому что знали вдоль и поперёк и сам проект, и конкретный фреймворк (точнее его конкретную версию под конкретную убунту...). Но когда дело доходило до оптимизации, быстрой отладки, или даже просто до создания чистого и "ремонтопригодного" кода по фичам, которые хотя бы немного выходили за границы их текущего микростека, они сразу терпели неудачу.

Но ради объективности не могу не признать, что и 10-кратные разработчики с мощным бэкграундом в ФП и computer science -- тоже в значительной степени миф. И после них проекты подчас приходится переписывать заново с нуля -- только уже из-за оверинжиниринга, который никто не понимает. Поэтому я и упомянул Грэма, и поэтому, в частности, и придумали Go, чтобы не допускать таких, как он, к кодингу важных проектов.

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

Пол Грэм, легендарный основатель Y Combinator и пропагандист Лиспа (на хабре немало переводов его статей, а также есть книга "Хакеры и художники", очень рекомендую), как программист стал известен проектом Viaweb, предлагавшим клиентам создавать собственные интернет-магазины. На минуточку, это был 1995-й год! До интернета даже просто дозвониться в буквальном смысле было тяжело, всё делалось в основном в текстовом терминале и ограничивалась э-почтой. Браузеры тоже использовались текстовые, я в основном скачивал всяческие электронные книги и гайды на английском, это была реально очень ценная инфа по тем временам. В команде где тогда работал, был оформлена корпоративная подписка на MSDN (за доллары), несколько CD с документацией и рекомендациями по Windows NT выходили по-моему раз в полгода, поэтому получить живой доступ к подобным материалам было прям очень круто.

И вот на таком фоне кто-то создаёт даже не просто интернет-магазин, а платформу для создания интернета магазинов! Это каким надо было обладать стратегическим мета-бизнес-видением. Но есть одно но...

Как только мы читаем новость, что вышла новая версия нейронки, текущая модель "по квантовой механике" становится "менее" эффективной (как с носками: надел один на левый нога, и другой автоматически стал правым). Ещё вчера всё было прекрасно, но простое сообщение о том, что доступно "более лучшее", внезапно перечёркивает то, что вроде бы норм работало. Так-то я до сих пор использую местами клод 3.5/7, с помощью которого запилил гомотопическую теорию на PHP, только чёт токены ни хера особо ни дешевле :)

"Игра на понижение" про банковский кризис 2008-го очень хорошее кинцо, рекомендую. Примерно то же и с пузырём AI будет. А если будет по-другому, то только уже как в "Чужие среди нас" (1988), очень рекомендую, БАЗА :)


Девяносто процентов всех стартапов – это чистой воды кидалово. Просто их начинают с одной целью – создать видимость движухи, чего-то такого многообещающего и рвущегося в небо, и сразу, пока никто не разобрался, эту видимость продать. Продают в таких случаях, по сути, презентацию с картинками, файл программы «power point», а деньги берут настоящие.
Продемонстрировать рост, сделать отчетность с красивыми цифрами, заинтересовать инвестора, снять лавандос и отчалить. Работают не над идеей, а над слайдом. При этом продают, как правило, клон какого-нибудь клона, только слова подбирают другие, чтобы узнать было трудно…
-- Пелевин

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

...Если бы не e2e. Потому что, оказывается, при экспериментах на H2 я чудом затёр всю основную БД...

У нас в проекте ORM выглядит просто и красиво. Но теперь у меня вопросы, сколько под капотом у нас скрывается n+1? Если один запрос это примерно 20 ms (как показала библиотека логирования), т.е. 100 лишних запросов это 2 лишние секунды?..

Эти ошибки - моя ответственность, т.к. я не ознакомилась со спецификацией библиотек, полагаясь на то, что все будет само работать из коробки...

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

Там монолит на php который писали колумбицы, а сейчас пишут пакистанцы...

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

Текущих разработчиков писать тесты заставить практически невозможно...

У нас на работе на основном проекте Maven, а на дополнительных -- Gradle...

Заминка с настройкой VM Java. Пришлось разбираться. Моя версия Intelige на поддерживает Spring. Пришлось устанавливать Eclipse. В Eclipse не получается запустить даже первое приложение. После долгих попыток исправить ошибку доступа к файлу, обратилась к ИИ. ИИ не помог. Полный аут. Шок. Со сроками с такими обьемными курсами ошиблась. Очень. Что делать непонятно...

"Объемные курсы" имеются в виду сторонние курсы коллег по фреймворкам, которые я немного рекомендую, но честно предупреждаю, что даже на троечку годных курсов увы не знаю ни по спрингу, ни по джанге из многих десятков предлагаемых на рынке, чтобы после их завершения человек мог делать какие-то базовые вещи на джуниорском уровне (REST, ORM модельки...) в формате реальной работы.

Контрвариантность сделал видимо неверно. У меня контрвариантность получилось очень похожей на ковариантность. В целом за контрвариантностью в разы сложнее следить чем за ковариантностью. Линтеры хорошо справляются с нахождением ошибок в контрвариантности...

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

Решила задачу способом, аналогичным предложенному. Причем, в 28 задачах решение было другим, но после теории по алгоритмам решила переписать. Хотелось сделать колесо от радости после того, как прочитала решение :)

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

Так важно действовать.

"Аутсорсинг -- это, по сути, вопрос: где бы нам найти в мире англоговорящего работника с самыми низкими запросами? Мы дадим ему работу, и он выполнит ее так же хорошо, но за гораздо меньшие деньги...

Нам это казалось полной противоположностью тому, что следовало бы делать. И мы решили, что будем нанимать самых дорогих специалистов, которые только есть в мире. [Мы решили], что возможность заключалась в том, что... именно эти люди были оценены рынком наиболее некорректно."

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

Гендиректор OnlyFans объяснила успех компании отказом от мидлов — сотрудников среднего звена. В штате работают только джуны и сеньоры. Новички занимаются рутинными задачами, а ключевые решения принимают опытные сотрудники. Джунов поощряют за выполнение более сложной работы, что снижает предвзятость к молодым кадрам. Около 40 сотрудников обеспечивают компании свыше $7 млрд годовой выручки. @bankser

.

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


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

База по карьере, серия 21:
Темп. Почему кто-то быстрее или медленнее поднимается по карьерной лестнице? Темп зависит от трёх факторов ...


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

65. Как правильно работать с исключениями
Поспрашивайте знакомых программистов, и большинство пожмёт плечами и скажет: просто не вызывайте функцию с пустым списком, для которого надо посчитать среднее. Кто-то более продвинутый уточнит, что для этой конкретной функции надо задать соответствующее предусловие (например, в виде комментария: нужен минимум 1 элемент). То есть ответственность перекладывается на вызывающего эту функцию. А если в системе тысячи подобных вызовов API?
Я не думаю, что это профессиональный подход...

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

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

=

Первые сериалы из существенно переработанных и улучшенных материалов СильныхИдей (по сути четыре книги) доступны на бусти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-25
4. Гайд Вайб-проектирование
5. Software Design с акцентом на Programming in Large (new)

=

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

В СильныеИдеи добавлен материал
"130) Условный вызов чистых функций, или Нечистый эффект наблюдения чистых функций - 2".
Если функциональная композиция компилируется, это работает 100%.

💪🏻

Мы здесь, потому что это трудно.
it's a privilege to do things that are hard.

=

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

#юмор
"...стоимость курса по базовым навыкам работы с ИИ может обойтись в 15–30 тыс. руб., профессиональные курсы для продвинутой работы с ИИ-моделями — в 100 тыс. руб."

Сегодня День онлайн-предпринимателя.

У меня есть 3-4 дополнительных маленьких гайда, которые я зачем-то захостил на сторонней платформе (типа геткурса) просто ради скорости. На скрине виден доход: где-то +4,000 рублей за ноябрь, а до этого последний платёж был в июне, при том что за хостинг там я ежемесячно плачу 5,500 рублей. А тянул потому, что решил там разместить и гайд по "Функциональным архитектурам"...
и вот внезапно случайно! в справке по платформе увидел новую плашку - недавно вывесили - что дескать автор теперь считается оператором персональных данных и должен региться в РКН. А какие там перс.данные? Ну я вижу внутри платформы имейлы (которые можно было скрыть, и они мне нафиг не нужны) и ники, и всё.

Вот у меня (и у тебя :) есть облачная почта, и локальная, где куча имейлов с фамилиями и прочей перс.датой. Есть телефон с кучей контактов, включая рабочие. Я должен регистрироваться как оперсдат? Или блог на 128 человек, где я вижу всех папищеков (телефон, ФИО, фотки) -- это же явная персдата, и им вдобавок я "рассылаю" регулярно свои материалы в блоге.

Нюанс, я так понимаю, в том, что я с этими данными делаю: просто смотрю, или же собираю (не говоря уже о том, что что-то рассылаю). Но это именно нюанс, потому что есть и такое мнение: "...Обработка включает не только сбор, но и любое использование данных, например, просмотр, хранение (даже временное в интерфейсе)...". И есть какое-то мутное п. 2 ч. 2 ст. 22 152-ФЗ, но разве кто-то будет разбираться в деталях?

И так-то получается влепят штраф 300,000 рублей за то, что я просто видал имейлы учеников!!1 Это нормально вообще?

Короче, удалил там всё что было на стороннем. Сколько раз зарекался:
Если хочешь сделать что-то хорошо и безопасно, делай ВСЁ САМ!
А тут решил немного выгадать по времени... Ладно, уже 7 лет мой собственный учебный движок прекрасно работает, и он абсолютно чист: только абстрактные ники и ключ доступа. Надо было только им и заниматься конечно. Придётся теперь кучу времени впустую сливать на трансфер...

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

"Вообще мы честно говоря оху..... Бизнес крутить - это не в ведро сцать. Разные цены, скидки, нюансы. Авторизация, спам в чат, без всего, общий пул… Знать бы все это за месяц до ивента… целый мир."
-- Мэд

p.s. При том, что я вообще не против зарегиться оперсдатом, но в отличие от получения "id блоггера" с этим жуткий гемор и куча документов нужна.

"...один из старших программистов пытался и пытается продать идею, как офигенно делать контроллер с эндпоинтом на ~1к строк, где куча всего делается и поиск багов из прода там превращался просто в треш (+ куча внешних сервисов используемых в этом коде), причем на полной серьезе, типо так читаемость классная. Тыкать в IDE особо не надо, сразу идешь по потоку программы. Поэтому и интерфейсы в топку, иначе тыкнул по интерфейсу в коде и не сразу попал на класс реализации, очень неудобно ему. Очень яркие ощущения были от работы с его кодом."

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

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

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

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

=

...А по поводу самого подхода "контроллер с эндпоинтом на ~1к строк" вот что хочу сказать: а вдруг этот сеньор проходил мой трек по гомотопической теории типов? :)

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

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

Дальше немного поясню, почему это субъективно выглядит очень "читабельно" и комфортно с точки зрения человека, сидящего "внутри" гомотопической модели, и спалю ряд фишек, так и быть, из моего грядущего гайда "Функциональные архитектуры".

"Zig -- это преемник Си / новый Си, хотя ещё недавно считалось, что таким будет Rust."


И вот внезапно Эндрю Келли (создатель Zig) заявил на днях:

"...совершенно очевидно, что инженерное мастерство, которое обеспечило успех GitHub, больше не есть его движущая сила. Приоритеты и инженерная культура [в Microsoft] протухли, и пользователи в результате вынуждены довольствоваться каким-то раздутым и глючным JavaScript-фреймворком "во имя прогресса". То, что раньше было быстрым, теперь работает медленно и часто полностью ломается… Самое главное, что в GitHub Actions есть непростительные ошибки, но при этом они полностью игнорируются."

Эндрю также крайне недоволен нарушениями Microsoft строгой политики Zig "не допускать в прод LLM / AI", которые, по его мнению, связаны с агрессивным продвижением Copilot на GitHub.

Время такое, братишка, время такое :)

Да, самое забавное, что Эндрю полностью ушёл с гитхаба. Куда? Нет, не на сорсфорж, и даже не на gitverse, а на codeberg (узнал только сегодня про его существование :).

Почему база реально важна? Когда на одном конце спектра хорошее понимание computer science, а на другом вайб-кодинг. Ну, главный критерий -- это хрупкость скиллов. В конкретном стеке, в конкретном проекте, во фреймворке конкретной версии, с помощью ЖПТ действительно можно наловчиться быстро-быстро пилить типовые скучные задачки, возможно даже и на сеньорском уровне. Но стоит выйти чуть-чуть за границу, как макбук превратится в powerbook g4, а сеньор в джуниора :)

Условно говоря, пришёл на новое место, где та же джанга, но 5-й версии. И вроде бы то же самое, но если не изучал мой гайд "незримые механизмы логики" с разбором асинхронщины, как сразу все знания полностью ломаются при столкновении с асинхронным ORM-ом, многозадачностью в одном потоке, смешивании синхронного и асинхронного кода, n+1...

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

А потому что =>

"Боец, в критической ситуации ты не поднимешься до уровня своих ожиданий, а опустишься до уровня своей подготовки".

По иронии судьбы цель и смысл социальной жизни состоит в том, чтобы оставаться безработным (в смысле самозанятым/фрилансером) до самого конца.

.

Ну, с Зимой! И с Днём Математика!

=

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

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

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

Работать с Big Ball of Mud ужасно. Если вы чихнете где-то в своей части кодовой базы, то нарушите работу 100500 функций, о существовании которых даже не подозревали. Большой Комок Говнокода сильно замедляет работу, регулярно приводит к ошибкам и вызывает сильное желание психануть и вообще уйти из индустрии...

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

Почему люди с маленьким, а то и с нулевым, опытом разработки, всё равно в конечном итоге получают работу, а у вас это почему-то никак не получается?..

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

Где потренироваться в задачках по программированию?

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

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

Самые большие заблуждения тех, кто с зарплаты 100-150к хочет выйти на 300+к, и как правильно...

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

=

Первые сериалы из существенно переработанных и улучшенных материалов СильныхИдей (по сути четыре книги) доступны на бусти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-25
4. Гайд Вайб-проектирование
5. Software Design с акцентом на Programming in Large (new)

=

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

В СильныеИдеи добавлен материал "129) The Rule of Least Power".
В программной инженерии хорошо известно The Rule of Least Power, которое предполагает выбор наименее мощного языка, подходящего для заявленной цели.
Если мы обобщим это с "наименее мощного языка" на "наименее мощную функцию/инструмент/паттерн/" и т.д., то получим важную эвристику разработки: ...

В раздел "Элитный программист" добавлен материал
83) ...
Вероятно, вы проводите большую часть своего времени, просто пытаясь пережить текущий день или даже текущую задачу, и вам трудно отвлечься и подумать обо всём следующем "годе". Тем не менее, я думаю, что оно того стоит, и это не займет у вас много времени.
Но с чего вообще начать? Отсутствие самого первого ясного шага может легко парализовать ваш анализ и помешать вам вообще что-либо сделать...

💪🏻

Мы здесь, потому что это трудно.
it's a privilege to do things that are hard.

"ЛаМПовое": memory is slow disk is fast, формализация тестирования...

=

Гайд про функциональные архитектуры в активной работе, готово 52 (+2 :) топиков (добавляю жёсткий хейт Чистой архитектуры). Как будет 108, дам ментатам доступ.