Немедленно прекратите всё, что вы делаете "по старинке".

Что вы можете изучить сейчас, чтобы быть готовым к качественно другому будущему, которое уже вот-вот, и счёт идёт на считанные месяцы?

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

(2018) GPT-1: 512 токенов
(2019) GPT-2: 1024 токена
(2020) GPT-3: 2048 токенов
(2023) Claude 2.1: 200 000 токенов
(2024) Gemini 1.5 Pro: 1 000 000 токенов
(2025) Llama 4: 10 000 000 токенов

Даже на логарифмической шкале линия последних лет заметно загибается вверх )))
Это какой-то сверх-экспоненциальный рост.

Наши блогеры на апрель.

Александр Новиков первым завёл Бусти с донами, рекомендую:

"Концентрат IT-литературы.
Cаммари ключевых IT-книг: концентрат идей, разбитый по главам и дополненный реальным опытом.
Идеально для тех, кто хочет разбираться в важном, но не имеет возможности (или желания) тратить долгие часы на чтение и анализ материала."

Очень качественная ручная работа, никакой жпт и близко не стоит.

=

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

Классная игра "Natural Number Game" (an introduction to mathematical proof).
На базе прувера Lean 4.

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

На выходных можно поиграть, а также посмотреть слегка в тему фильмы "21" 2008-го года, и "Поедем с тобой в Макао" Романа Михайлова.

"Почему числа прекрасны? Это всё равно что спрашивать, почему прекрасна Девятая симфония Людвига ван Бетховена. Если вы не понимаете почему, никто не сможет вам объяснить. Я знаю, что числа прекрасны. Если они не прекрасны, то не прекрасно ничто".
-- Пал Эрдёш

Деньги – это заменитель счастья. Когда вы несчастливы, вы пытаетесь заполучить побольше денег, ещё больше денег. Люди, которые очень скупы в том, что касается денег, это очень несчастные люди.

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

С LanguageExt я столкнулся на прошлой работе, на Америку.
Увидел как ребята там мастерски избегают проверок на null, не кидают эксепшены, и балуются с Option и Either, посыпая сверху LINQ. Аж влюбился. Вспомнил и теперь хочу попробовать приноровится к либе на этом проекте...

...По фронту. Долго не верстал и решил попробовать связать Vite + React + Tailwind. Намаялся чтобы все заработало нормально)

...В целом, конечно, даже близко к предложенному решению почти ничего нет, что грустно. С другой стороны какие-то отдельные детали и подходы я все таки выхватил. Ряд логичных предположений и вычислений в актив можно занести.
Не помню чтобы сталкивался (может и никогда не сталкивался) с подходом, когда для аналитического подсчета присоединяются таблицы целиком, без связи (по типу "LEFT JOIN zone_vulnerability zv ON 1=1 -- Join all zones for averaging")
Ну а в целом, это конечно просто космос :)

...Интересно наблюдать как на этих задачах работает мозг после обучения программированию в школе и университете по стандартным программам.
Первым делом хочется вытащить всё из базы через что-то вроде ORM, а потом уже проводить "сложные" вычисления на родном императивном языке.
SQL, наоборот, предельно декларативен и на нём можно написать ту же программу в функционально стиле:
CASE WHEN - это местный map,
SUM, COUNT, AVG, ... - разные варианты reduce.

...Схема базы данных однозначно усложнилась.
Степень реализма поражает, на работе похожую картину увидел как пришёл, только у вас таблицы ещё задокументированы)

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

Раньше я думал, что REST API — это просто CRUD с ID и JSON. Теперь я вижу, что можно строить архитектуру по-разному: данные могут существовать в коде или быть "спрятанными" в процессах сериализации, а API можно организовать без привязки к глобальному хранилищу...

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

Самая провальная попытка, не учтены многие вещи. Многое надо переосмыслить и многое потренировать еще...

...Наконец-то у меня стало получаться! Сам справился со всеми пунктами.

❤️❤️❤️❤️❤️

Отчёт за неделю.

Основной паблик:

...Всё то программистское, что ты знал раньше — ОБМАН. Твои скиллы больше тебя не защитят. Грядёт что-то масштабное — то, о чём тебя никто не предупреждал.
Смейся сколько хочешь. Называй это "ненастоящая работа."
Но когда совсем молодой парнишка щёлкает взрослые рабочие задачки, он щёлкает их существенно быстрее — в РАЗЫ быстрее — чем ты.
Потому что правила игры изменились.
Это не скиллы — это ПРОМПТЫ.
Это не талант от рождения — это новый ВАЙБ.


Для донов-начинающих + по саморазвитию:

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

Набор на мой новый трек для начинающих с полного нуля, 3 места закончились за 1:20. Такие наборы для донов теперь проводятся регулярно.

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

Продолжаю выкладывать материалы СильныхИдей -- доступны моим курсантам, но тут расширенные версии, дополненные множеством примеров.
31. Interface Segregation Principle (ISP)
Это, пожалуй, самый простой принцип из всех пяти: создавая любые интерфейсы, делайте их как можно меньше. Разделяйте большие интерфейсы с кучей возможностей на более мелкие, чтобы каждый интерфейс обеспечивал именно то, что он обещает (SRP), и ничего больше. И наоборот, если вы нарушаете SRP, то ваш интерфейс, скорее всего, тоже станет раздутым из-за ненужных свойств и методов...

Напомню, что первые две дюжины материалов СильныхИдей (по сути две книги) пока доступны на бусти, и пока по очень дружелюбным ценам:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small

=

Первый курс трека "Как понять в программировании всё" перенесён на внешнюю платформу, и теперь несколько раз в месяц для донов-неначинающих буду делать наборы (кто хочет после его прохождения потом попасть в мою Школу).
Вот он про что, подробно.

...Синхронизм: кто-то купил этот курс, пока я ещё только начал утром этот пост )))) хз как чел нашёл ссылку. Я там случайно оставил два места для проверки.
"Ученик "Сергей" оплатил курс "Как понять в программировании всё: БАЗА" Сегодня 10:09" (и уже прошёл 16% :)

Осталось одно, при большом желании можно пройти соответствующий "квест" и его найти. Всё, и второе место кто-то нашёл :)
Потом запись будет только для донов, но регулярно.

Бусти:

Как войти в ML за ОДИН месяц

=

Возобновил работу над курсом "Ясные Системы" (как быстро и легко писать ПРОСТОЙ код систем масштаба ultra-large-scale). Просто систематизированный набор различных эвристик, которые достаточно применять механически, и всё будет супер.
Сейчас 10 23 эвристики, как наберётся 42, дам курсантам доступ.
Стараюсь делать эти эвристики максимально минималистично (несколько фраз, максимум 2-3 абзаца), что оказывается существенно сложнее, нежели расписывать всё подробно )))

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

Суть в том, чтобы улучшить результат, не улучшая навыки.

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

...И вернулся наконец к "Гомотопической теории типов для программистов".
Некоторые определения пока получаются рекурсивными )))

Например когда изучаем абстракции Петель и Путей, приходится добавлять понятие Базовой точки. Так-то все эти понятия по большому счёту на уровне алгебры и геометрии обычной старшей школы. Например, петля — это путь от точки к самой себе :) И третьеклассник поймёт.

Базовая точка здесь принципиально важна, так как именно относительно неё формируется петля, но засада в том, что от базовой точки измеряются все гомотопические эквивалентности, которым соответственно надо дать отдельное определение. Тут мы добираемся до pointed типа, который позволяет определить конструкции, зависящие от конкретной точки отсчёта (например, фундаментальная группа пространства). Теперь надо разобраться с первой гомотопической группой, и с рекурсивными определениями функций из высших индуктивных типов в другие типы, однако до HIT мы ещё не добрались, а когда берём высший индуктивный тип Окружность, смотрим, почему фундаментальная группа окружности изоморфна группе целых чисел Z, откуда возвращаемся к гомотопической эквивалентности и группе петель...

Но что интересно, все эти рекурсивные определения весьма неплохо понимаются 🙃
Просто терминология такая математическая, но на самом деле сами понятия весьма простые, делаем их наглядные реализации на Python.

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

Классический университетский подход к обучению гомотопической теории типов, судя по всему берёт своё начало с 2012-го года, когда в Институте перспективных исследований IAS целый год был посвящен темке "унивалентных оснований математики", который объединил исследователей из разных математических традиций, а результатом стала знаменитая "HoTT Book".

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

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

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

=

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

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

А вот отче наш Гротендик (на фото) в работе "Sur quelques points d'algèbre homologique" использовал категории сразу для определения и построения более общих теорий, которые затем применял к конкретным областям, включая алгебраическую геометрию.

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

Сегодня эти темки особо актуальны: когда я разбирался с реализацией Тора, заинтересовался, что оказывается этот тип эквивалентен произведению двух окружностей, о чём есть соответствующий материал некоей Кристины Соджаковой.
Эта женщина мощный математик, работает конечно же on the formal verification of cryptographic protocols (а также над криптой:), и HoTT в этом одно из ключевых направлений. Правда действующих специалистов в этом в мире вряд ли наберётся хотя бы 5-10 человек.

Вот и хочу поставить такой эксперимент: если обучить этим темкам достаточно большое множество сильных программистов (и только в России), что будет в результате?

а Он придёт и приведёт за собой весну
и рассеет серых туч войска... 🙏🙏🙏

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

"Что это мне даст на практике?" (c)

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

А если взять базу гомотопической теории типов по структурным равенствам математических объектов, то окажется что F# и Java -- совершенно разные языки, а Java и Python -- разновидность одного и того же...

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

Ну и мои курсы по парадигмам программирования (вычислительные модели) -- это примерно то, что пояснял святой Роберт Харпер:
"What, if anything, is a programming paradigm?"
Это ровно про тоже: никакая не таксономия, а просто самые фундаментальные свойства, характерные различным стилям программирования.
Например, ООП -- это программирование с инкапсуляцией, явным состоянием и наследованием (и вполне можно обойтись без классов). Разбираемся в частности, почему и как полноценные объектно-ориентированные программы могут быть написаны практически на любом языке, и т.д.

...Более того, понимание теории типов позволяет нам заявить, что не только F# и Java -- совершенно разные языки, что в принципе достаточно понятно со стороны (F# -- это всё же функциональный язык с алгебраическими типами), но и
C# и Java сегодня -- совершенно разные языки.
Мейнстрим тут способен мыслить лишь на школьном уровне "статическая типизация", "ООП-парадигма" ...

Java строго номинативен: все пользовательские типы (классы) сравниваются по ссылкам, даже если поля идентичны, а проверка структурного равенства (когда эквивалентность типов определяется их поведением, а не именем: формальная версия утиной типизации) требует явного переопределения equals().
В C# же не только есть сишные структуры (для которых структурное равенство работает по определению:), но и с 9й версии - records (автоматическая реализация структурного равенства).

Делегаты C# (Func<T>, Action) — это структурно-совместимые типы функций. Два делегата с одинаковой сигнатурой считаются совместимыми, даже если объявлены по-разному.

В Java же наоборот: функциональные интерфейсы (Runnable, Consumer<T>) номинативно зависимы: даже если сигнатуры методов совпадают, интерфейсы несовместимы без явного наследования.

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

В C# информация о типах при использовании генериков сохраняется в рантайме, что позволяет проверять структурные преобразования динамически. В Java же генерики реализованы через type erasure (на что я уже напоролся в Python при реализации HoTT :), что делает их номинативными и невидимыми во время выполнения.

Гомотопическая теория ближе к идее "типы как объекты", когда преобразования типов можно анализировать на втором логическом уровне.

Короче говоря, в терминах HoTT,
Java навязывает жёсткую иерархию именованных типов,
а C# позволяет работать с типами как пространствами, где изоморфизмы (эквивалентности) могут быть частью самой системы типов!

Отчёт за неделю.

Основной паблик:
Сериал про AI и квантовые вычисления.
2. У компаний, создающих AI-инструменты, нет никакого стимула предупреждать вас о разрушении ИТ-рынка. Они скорее расскажут вам о рептилоидах...
3. Речь идет не просто о совершенствовании AI: речь идет о разблокировке совершенно нового уровня AI и автоматизации в целом.
4. AI и квантовые вычисления: лузеры и победители.

=

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

Продолжаю выкладывать материалы СильныхИдей -- доступны моим курсантам, но тут расширенные версии, дополненные множеством примеров.

Когда наследование лучше композиции (БАЗА)
Всё, что вам рассказывал про ООП мейнстрим, неверно :)

Dependency Inversion Principle (DIP)
В системе, где DIP не соблюдается, более высокие абстрактные модули (например, бизнес-логика) зависят от более низких конкретных деталей реализации (например, файловых систем, конкретных баз данных и т.д.). Поток управления движется сверху вниз, в конкретные модули...
В ФП абстракции -- это стандартный способ работы с кодом. Принцип DIP тут естественен по самому замыслу.

Напомню, что первые две дюжины материалов СильныхИдей (по сути две книги) пока доступны на бусти, и пока по очень дружелюбным ценам:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small

=

Бусти:

Как войти в ETL за две недели
(на самом деле нет :)

=

Курс "Ясные Системы" (как быстро и легко писать ПРОСТОЙ код систем масштаба ultra-large-scale). Сейчас 23 28 эвристик, как наберётся 42, дам курсантам доступ.

Курс "Гомотопическая теория типов для программистов". Понемногу продолжаю, сейчас 22 топика, база в принципе готова, курсантам скорее всего дам доступ, когда смоделируем и разберём зависимые типы и высшие индуктивные типы (в районе 30 топиков).

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

...Буду продолжать развивать LinkedIn. Площадка оказалась неплохая. Даже написать руководитель отдела одного из направлений в VK. Позвал на работу - ну тут профиль оказался сильно не мой. Но тем не менее.

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

...Забавно, что меня почти на всех собеседованиях справшивали про SOLID, а пишем мы в условно функциональном стиле)))

Слишком себя ограничивать одним фреймворком не надо, для карьеры это больше тормоз, а выгодно только вашему работодателю. Как минимум в резюме у вас должен быть опыт не только реакт, а "js сложные проекты", и особенно "ts". Совместите ts с реактом, и сразу вылезет ооп :)

...они взяли моего знакомого с улицы аналитиком, отправили вариться во внутреннюю кухню на 3 месяца, и спустя это время уже пробовали продавать его как сеньера системного аналитика с 5летним опытом.
Да и вообще, для оутсорса самый лакомый кусок - мальчишки выпускники маги технических вузов, опыта нет ни в работе, ни в общении с руководителями, плывут в законах, ТК РФ, легко манипулировать...

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

...В целом у меня все сходится. У Вас красивее сделано) У меня все через костыли. Может следует мне СУБД сменить? Не знаю, посмотрим что будет дальше.
После долгих разборов я выяснил что JSON_ARRAYAGG в Sql Server отсутствует.
Мелкомягкие вынесли ее в Azure...

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

...Только что разбирали инцидент с непроходимостью очереди Селери. Одна задача падала с ошибкой, но была написана таким образом, что генерировала тут же три новых (ретрай + назначение самой себя). Решить смогли только через несколько итераций, через мониторинг и погружение в код чуть ли не каждой задачи. О том, что очередь может так зависеть от задачи мысль пришла сильно позже. Начиналось все просто с обнуления очереди, что, понятно, помогало не на долго.

...Очень круто, не ожидал, что мы в итоге столкнёмся с подобным. Это и страшно и впечатляюще одновременно!

❤️❤️❤️

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

Путь (Path) в HoTT -- это доказательство равенства между двумя объектами, причём по-интуиционистски: учитываем, "как именно" два объекта равны, а не только факт их равенства.

Level 1: путь описывает трансформацию из одного состояния в другое: например, шифрование сообщения с открытым ключом (путь от исходного текста к зашифрованному с RSA).

Level 2: путь между путями допускает разные реализации.
- шифрование с использованием готовой либы OpenSSL
- шифрование с помощью чистой математической реализации RSA на коленке в рамках cтуденческой лабы

Путь lvl2 доказывает эквивалентность этих реализаций (или предлагает методологию перехода от одной к другой с сохранением криптостойкости).

Level 3: пути между путями между путями (разные криптосистемы)

Возьмём например асимметричный подход RSA и симметричный подход с обменом ключами (AES по Диффи-Хеллману).
Путь lvl 3 описывает преобразование между этими фундаментально разными подходами к криптографии: формализует методы перехода от одной криптографической парадигмы к другой, сохраняя безопасность и функциональность. Например, это может быть гибридная криптосистема протоколов защищённой связи: асимметричное шифрование для обмена ключами и симметричное для основного потока данных.

Level 4: пути между путями между путями между путями: мета-методологии криптографической безопасности :)

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

Путь lvl 4 позволяет
- создавать гибридные системы безопасности, адаптирующиеся к изменениям в вычислительных парадигмах (например, переход от классических к квантовым вычислениям)
- формализовать процесс доказательства безопасности при смене базовых предположений
- разрабатывать стратегии перехода от одной философии безопасности к другой в масштабах глобальных и критических инфраструктур

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

Level 5 я не раскрою, а то меня застрелят :)

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

Бросаетесь например "поизучать MCP", хотя эти конкретные протоколы друг с другом часто несовместимы, и более того, когда вы вытаскиваете (или опускаете?) AI API на уровень JSON RPC или Protobuf + gRPC, то фактически просто создаёте себе кучу дополнительных технических проблем вместо ожидаемого упрощения.

Знаете, что такое AI-агент? Это зацикленная LLM, и дофига токенов (и денег), и всё.

Например, PocketFlow - LLM-фреймворк на 100 строк на питоне + подробно разобрана архитектура и абстракции, очень рекомендую!

Другой гайд: 300 строк кода Go и 3 инструмента, и вы сможете успешно общаться с инопланетным разумом, который редактирует и совершенствует ваш код.

Более подробно разбираю это в сегодняшнем посте.

... Просили привести более мэйнстримовский пример для lvl 4 (пути между путями между путями между путями).

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

Имеются два разных подхода к выбору архитектурных решений (которые сами по себе пути третьего уровня):
1. Эволюционный подход: постепенный переход от одной архитектуры к другой по мере роста проекта. Например, плавный переход от простого слоя доступа к данным к многоуровневой архитектуре с дженериками.
2. Трансформационный подход: полное переопределение архитектуры при переходе на новые технологии. Например, радикальная смена подхода при миграции с монолитной архитектуры на микросервисную (а если захотим 💯 вернуться обратно, у нас должна быть уже реализована операция инверсии -- в смысле её полноценного встраивания в подход с самого начала).

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

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


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


p.s. ладно, насчёт вчерашнего lvl 5 применительно к криптографии, завтра таки расскажу, что это такое может быть: битва между метаподходами.
Например,
сюръективный морфизм алгебраических групп с конечным ядром
vs
дифференциальный криптоанализ алгебраических структур шифров.

p.p.s. Кто проходил мой курс по солверу Z3, попробуйте решить задачку с картинки, будет забавно.

А что вы слушаете непосредственно в процессе кодинга?

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

Ставь сердечко ❤️ если тоже слушаешь примерно то же самое за программированием,

ставь китика 🐳 если слушаешь что-то совсем другое,

или что угодно другое 👍 если за работой вообще ничего не слушаешь :)

В список запрета рекламы эзотерических услуг в РФ занесли алхимиков, астрологов, астропсихологов, ведьм, аура-диагностов, биоэнергетических терапевтов, духовных наставников (гуру), игропрактиков, космоэнергетов, кристаллотерапевтов, магов, медиумов, нейрографов, нейрокодировщиков, нумерологов, нутрициологов, практиков осознанных сновидений, расстановщиков, регрессологов, рейки-мастеров, ретритактиваторов, рунистов, рунологов, специалистов по васту, по тантре, по фэншуй, тарологов, хилеров, хиромантов, чакра-терапевтов, чакрологов, ченнелеров, цифровых психологов-астрологов, эзотерических коучей, энергетических очистителей, энергопрактиков, энергосессиологов и энерготерапевтов.

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

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

Ну ок, когда по аналогии крупные российские онлайн-сервисы-монополисты продавят закон по запрету ИТ-курсов и ИТ-менторства без образовательной лицензии и без соответствующего высшего педагогическо--информатико-математического образования, буду маскироваться под нейро-клоуна! 😇🤡👻

1. Кодер-шаман – "Раскодирую вашу карму через рекурсию и сингулярность."
2. Нейроколдун – "Чищу чакры вашего кода с помощью TensorFlow и тёмной магии градиентного спуска."
3. Алгоритмический гуру – "Пробуждаю в вас дух O(1) и просветляю через Big O."
4. Матаномант – "Предсказываю вашу успеваемость по интегралам и рядам."
5. Библиотечный некромант – "Оживляю legacy-код и вызываю духов deprecated-функций."
6. Функциональный экстрасенс – "Чищу callback-ад и изгоняю side effects."
7. Синтаксический хиромант – "По линиям вашего кода предскажу, когда вас уволят."
8. Гик-чакролог – "Балансирую ваши энергетические потоки между frontend и backend."
9. Крипто-астролог – "Предскажу курс биткоина по звёздам и хешрейту."
10. Ментор-регрессолог – "Возвращаю вас в прошлое, чтобы вы наконец выучили pointers."