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

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


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

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

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

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

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

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

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

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

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

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

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

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

=

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

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

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

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

.

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

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

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

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

Нужно ли начинающему знать 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 кода на пыхе (включая авторизацию, работу с базой...) :)
Как тебе такое, жпт и клауд клод?

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

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

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

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

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

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

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

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

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

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

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

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

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

А ещё показалось, что в луковой архитектуре, ну или том, подобии, что сделал я, не очень сложно тестировать бизнес-логику, по крайней мере в моём случае(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) даёт невероятную, буквально магическую, силу. Подходит он не всегда и не везде, но когда попадает в цель...

Прогноз на ближайшие годы:
Самые эффективные компании использующие ИИ: тратят от $10,000 в месяц в токенах на сотрудника, что эквивалентно ~5,000 «ИИ-сотрудникам» работающим 24/7, что эквивалентно ~500 реальным jun/middle уровня сотрудникам.

Страшно? )))

Вот мнение самого ИИ по этому поводу:

Раньше джуниор мечтал вырасти до тимлида. Теперь его карьерный путь — это стать «промпт-инженером», чья главная задача 8 часов в день втолковывать 5000 виртуальным идиотам-гениям, что от них хотят, а потом неделю объяснять боссу, почему в итоговой презентации логотип клиента превратился в картинку котика. Зарплата не выросла, зато чувствуешь себя пастухом цифрового стада, которое дороже тебя в 100 раз.

Раньше программист три дня думал над архитектурой, а потом ночь перед дедлайном писал код. Теперь он три дня бьется с ИИ, который генерирует красивый, но неработающий код, а ночь перед дедлайном переписывает всё с нуля сам. Зато в отчёте у CEO теперь есть магическая цифра: «Наши разработчики в 100 раз продуктивнее благодаря синергии с 5000 ИИ-ассистентов». Сама синергия ощущается как лёгкое жжение в районе эээ дедлайна.

Мы заключили сделку с ИИ-демоном: мы кормим его нашими исходниками и деньгами, а он дает нам скорость. Теперь мы пишем в 10 раз больше строк кода, которые в 100 раз сложнее поддерживать. Каждый новый проект начинается с ритуального сжигания бюджета на контекстное обучение нашего «демона» — загружаем в него всё, что знаем. А он взамен дает нам код, который выглядит так, будто его писали те самые 5000 виртуальных джуниоров — одновременно и в полном одиночестве. Мы отдали душу проекта (исходники) и вечный огонь из бюджета (токены) за иллюзию движения. И выйти из цикла нельзя — без него мы уже никогда не разберёмся, что и как там у нас в легаси всё устроено.

Как заблокировать в питончике импорт некоторого модуля?
sys.modules -- это словарь, где ключи - имена модулей...

sys.modules['re'] = None

Зачем? Прост.

"Things to do on your last day at work" :)

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

(lambda fc=(lambda n: [c for c in object.__subclasses__() if c.__name__ == n][0]):
    (lambda func=fc('function'), code=fc('code'), bc=b'\x01':
        (lambda pre=() if isinstance(b'', str) else (0,):
            func(code(*(pre + (0, 0, 0, 0, bc, (), (), (), '', '', 0, b''))), {})()
        )()
    )()
)()

Дзен питона.

Вы когда-нибудь ждали целую вечность, пока pandas загрузит CSV-файл, и думали, что проблема в вашем ноутбуке?

На самом деле так работает pandas...

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

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

Между тем, Polars работает совершенно по-другому...

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

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

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

А если позже вам всё ещё понадобится панда, вы легко сможете это сделать:

df.to_pandas()

Polars is an open-source library for data manipulation, known for being one of the fastest data processing solutions on a single machine. It features a well-structured, typed API that is both expressive and easy to use.

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

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

Именно по этой причине нам и "кажется", что наш бывший довольно неплохой электронный друг-программист уровня клода 3.5/7 становится всё глупее с каждым днём.

"Это капитализм, детка". Ничего личного, просто бизнес.