Как формально классифицировать разработчиков (мэйнстрима) через n-гомотопии.
Джун: 0-путь (объекты) и 1-путь (морфизмы).
Пишет функции.
Мидл: 2-путь (комбинирование функций, эквивалентности):
контракты/ограничения/абстракции/паттерны.
Сеньор: 3-путь (комбинирование паттернов, факторизация через ко-предел как клей, верификация): может доказать, что совместная работа новых частей не сгенерирует противоречий в 2-путях (например что сочетание шардирования и кэширования не приводит к скрытым проблемам).
(Формальная) верификация на уровне типов. Оркестраторы.
Архитект: 4-путь (мета-уровень).
Ум как порождающая парадигма: создание оригинального архитектурного стиля под всю систему. Придумывает DSL (хотя бы на уровне спек, как - изучайте ФА) и новые правила композиции (фактически, создание модели высшего порядка). Видит, какие 2-пути и 3-пути надо делать простыми, а какие сложные и как их упростить. Понимает, как их композиции повлияют на долгосрочное развитие системы.
Метрикой связности тут и становятся формальные гомотопии. Например если слишком много высших путей (запутанных зависимостей), значит придуманная конструкция хрупковата.
5-путь -- это чистая теория (зависимых) типов, HoTT как язык программирования и т.д. Засада в том, что реальный код полон побочных эффектов и багов, а требования постоянно меняются, и тем самым стирается когерентность выше 4-пути.
...И здесь мэйнстрим упирается в тупик. Мы же в (Meta) Principles Framework пойдём куда дальше: топологическим сдвигом изменим размерность самой задачи. Сеньор строит лабиринт из паттернов; мы будем строить карту, на которой лабиринт превращается в прямую линию.
Джун: 0-путь (объекты) и 1-путь (морфизмы).
Пишет функции.
Мидл: 2-путь (комбинирование функций, эквивалентности):
контракты/ограничения/абстракции/паттерны.
Сеньор: 3-путь (комбинирование паттернов, факторизация через ко-предел как клей, верификация): может доказать, что совместная работа новых частей не сгенерирует противоречий в 2-путях (например что сочетание шардирования и кэширования не приводит к скрытым проблемам).
(Формальная) верификация на уровне типов. Оркестраторы.
Архитект: 4-путь (мета-уровень).
Ум как порождающая парадигма: создание оригинального архитектурного стиля под всю систему. Придумывает DSL (хотя бы на уровне спек, как - изучайте ФА) и новые правила композиции (фактически, создание модели высшего порядка). Видит, какие 2-пути и 3-пути надо делать простыми, а какие сложные и как их упростить. Понимает, как их композиции повлияют на долгосрочное развитие системы.
Метрикой связности тут и становятся формальные гомотопии. Например если слишком много высших путей (запутанных зависимостей), значит придуманная конструкция хрупковата.
5-путь -- это чистая теория (зависимых) типов, HoTT как язык программирования и т.д. Засада в том, что реальный код полон побочных эффектов и багов, а требования постоянно меняются, и тем самым стирается когерентность выше 4-пути.
...И здесь мэйнстрим упирается в тупик. Мы же в (Meta) Principles Framework пойдём куда дальше: топологическим сдвигом изменим размерность самой задачи. Сеньор строит лабиринт из паттернов; мы будем строить карту, на которой лабиринт превращается в прямую линию.
5🔥25❤11✍4🤔2🥰1
Каждый не-технический человек, которого я знаю, что-то создаёт в своей теме с помощью AI. Каково ваше оправдание?
1🤔35🤝8👍6🐳3
Если нейронки уже отлично пишут код и здорово разбираются в архитектурах, алгоритмах и математике на уровне золотых медалистов, почему продолжают активно разрабатываться и выпускаться всё новые и новые и всё более и более дорогие модели?
🤔34😁17✍8👌1🏆1
opencode - лучший опенсорсный AI-агент для кодинга
opencode - продукт с 7,5 миллионами пользователей в месяц
opencode - репа на гитхабе со 188 000 звёздами
opencode - компания с одним лысым инди-хакером
p.s. а я ведь говорил месяц назад: пилите ai-джуниора(и пофиг, что получится карго-культ :) , всё остальное вторично.
opencode - продукт с 7,5 миллионами пользователей в месяц
opencode - репа на гитхабе со 188 000 звёздами
opencode - компания с одним лысым инди-хакером
p.s. а я ведь говорил месяц назад: пилите ai-джуниора
😁27🤔12
Умение создавать программные сервисы, и умение создавать человечный контент в блогах (прежде всего текстовый), станут наиболее прибыльными навыками следующего десятилетия (да уже и текущего).
И именно программные сервисы, а не программные продукты - API-as-a-Service, и желательно не в json, а в более структурированном и при этом более компактном формате, например toon.
Почему? Потому что к 2030-му 98% пользователей софта будут AI-агенты, а нафиг им нужен твой UI? Им подавай Network APIs.
И именно программные сервисы, а не программные продукты - API-as-a-Service, и желательно не в json, а в более структурированном и при этом более компактном формате, например toon.
Почему? Потому что к 2030-му 98% пользователей софта будут AI-агенты, а нафиг им нужен твой UI? Им подавай Network APIs.
1❤30✍15
Мой 7-й гайд "Programming in Large" (по материалам СильныхИдей для ментатов), основной акцент на избавлении от зависимости от зависимостей.
Силлабус:
Избавляемся от зависимости от зависимостей
Сколько раз вы пытались удалить некоторую зависимость из проекта, но не были уверены, что сделали это успешно? Чтобы ваша кодовая база не зависела от чего-то конкретного? Или чтобы она "зависела от интерфейсов, а не от реализации"? Или старались следовать SOLID по инверсии зависимостей?
Избавляемся от зависимости от зависимостей - 2
Ключевой вопрос любой зависимости независимо от её типа, очевидно, такой: "Зависит ли А от B?".
Избавляемся от зависимости от зависимостей - 3
В первом материале по этой теме мы разобрали 9 видов зависимостей, а во втором материале изучили три характеристики любой зависимости, и как правильно о них думать. Теперь вернёмся к исходным 9 видам, и рассмотрим, как с ними разбираться. Но предварительно дадим точное и практическое определение зависимости.
Избавляемся от зависимости от зависимостей - 4
Итак, у нас есть универсальное определение зависимости. Рассмотрим теперь в его свете 9 типов зависимостей, причём в некоторых случаях мы получим ответ вида "это не зависимость, но часть зависимости".
Как извлечь пользу из сторонних зависимостей
Скорее всего, в вашем проекте имеется не одна зависимость от сторонних библиотек, на которые достаточно серьёзно опирается ваше приложение, но вы либо боитесь, либо по каким-то другим причинам не хотите (нету времени...) заглянуть под капот и изучить её исходный код.
Изоморфизмы и программирование
Чем больше вы тренируете свою способность формально рассуждать об изоморфизмах, тем больше расширяется ваша способность видеть вроде бы несвязанные вещи эквивалентными, и формировать интересные связи между ними.
Что такое баг?
Через некоторое время обнаруживается, что разработчики совершенно неправильно поняли интерфейс API...
Пишем безошибочный код с помощью Typestate-Oriented Programming
ООП позволяет достаточно хорошо моделировать мир, но основополагающим для качественного моделирования становится состояние объекта, которое, с другой стороны, частая причина ошибок и запутывания кода.
Логика бьёт порядок
Сценарии (прежде всего use cases и user stories) сегодня тотально доминируют в технических заданиях. Они опасны тем, что обманчиво хорошо смотрятся с точки зрения здравого смысла, однако не могут претендовать на универсальность прежде всего потому, что им не хватает абстракции, даже если мы предварительно тщательно формируем "проектную онтологию предметной области"...
Дополнительная сложность -- мать всех запашков кода
Я учу видеть такие недостатки в коде, которые большинство сочтёт безобидными, и программировать на более высоком уровне, чем многие вообще могут себе представить. Но, как ни странно, ещё труднее поднимать на такой уровень код.
44 правильных вопроса при разбирательстве с легаси-системой
Само по себе изучение кода проекта "в вакууме" довольно абстрактно и бессмысленно. Вместе с кодом у вас должна быть работающая система, сформированная из этого кода, с которой вы взаимодействуете через UI.
Как развивать хакерское мышление
Главная рекомендация, что тут как раз надо забыть/забить на классические принципы проектирования, и действовать от противного.
=
12 материалов,
130 кб чистого текста,
цена до завтрашнего дня 1900 рублей,
купить на бусти
+ этот 7-й гайд добавлен в бандл (кто уже покупал бандл, просто скачайте и этот гайд себе бесплатно, и так и дальше будет с новыми - доплачивать не надо),
цена бандла пока старая 14999 рублей, завтра соответственно вырастет.
=
Предыдущие материалы (в бандле все эти материалы с большой суммарной скидкой + новый данный):
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-26
4. Вайб-проектирование
5. Software Design с акцентом на Programming in Large
6. Programming in Large: продолжение
7. this :)
Силлабус:
Избавляемся от зависимости от зависимостей
Сколько раз вы пытались удалить некоторую зависимость из проекта, но не были уверены, что сделали это успешно? Чтобы ваша кодовая база не зависела от чего-то конкретного? Или чтобы она "зависела от интерфейсов, а не от реализации"? Или старались следовать SOLID по инверсии зависимостей?
Избавляемся от зависимости от зависимостей - 2
Ключевой вопрос любой зависимости независимо от её типа, очевидно, такой: "Зависит ли А от B?".
Избавляемся от зависимости от зависимостей - 3
В первом материале по этой теме мы разобрали 9 видов зависимостей, а во втором материале изучили три характеристики любой зависимости, и как правильно о них думать. Теперь вернёмся к исходным 9 видам, и рассмотрим, как с ними разбираться. Но предварительно дадим точное и практическое определение зависимости.
Избавляемся от зависимости от зависимостей - 4
Итак, у нас есть универсальное определение зависимости. Рассмотрим теперь в его свете 9 типов зависимостей, причём в некоторых случаях мы получим ответ вида "это не зависимость, но часть зависимости".
Как извлечь пользу из сторонних зависимостей
Скорее всего, в вашем проекте имеется не одна зависимость от сторонних библиотек, на которые достаточно серьёзно опирается ваше приложение, но вы либо боитесь, либо по каким-то другим причинам не хотите (нету времени...) заглянуть под капот и изучить её исходный код.
Изоморфизмы и программирование
Чем больше вы тренируете свою способность формально рассуждать об изоморфизмах, тем больше расширяется ваша способность видеть вроде бы несвязанные вещи эквивалентными, и формировать интересные связи между ними.
Что такое баг?
Через некоторое время обнаруживается, что разработчики совершенно неправильно поняли интерфейс API...
Пишем безошибочный код с помощью Typestate-Oriented Programming
ООП позволяет достаточно хорошо моделировать мир, но основополагающим для качественного моделирования становится состояние объекта, которое, с другой стороны, частая причина ошибок и запутывания кода.
Логика бьёт порядок
Сценарии (прежде всего use cases и user stories) сегодня тотально доминируют в технических заданиях. Они опасны тем, что обманчиво хорошо смотрятся с точки зрения здравого смысла, однако не могут претендовать на универсальность прежде всего потому, что им не хватает абстракции, даже если мы предварительно тщательно формируем "проектную онтологию предметной области"...
Дополнительная сложность -- мать всех запашков кода
Я учу видеть такие недостатки в коде, которые большинство сочтёт безобидными, и программировать на более высоком уровне, чем многие вообще могут себе представить. Но, как ни странно, ещё труднее поднимать на такой уровень код.
44 правильных вопроса при разбирательстве с легаси-системой
Само по себе изучение кода проекта "в вакууме" довольно абстрактно и бессмысленно. Вместе с кодом у вас должна быть работающая система, сформированная из этого кода, с которой вы взаимодействуете через UI.
Как развивать хакерское мышление
Главная рекомендация, что тут как раз надо забыть/забить на классические принципы проектирования, и действовать от противного.
=
12 материалов,
130 кб чистого текста,
купить на бусти
+ этот 7-й гайд добавлен в бандл (кто уже покупал бандл, просто скачайте и этот гайд себе бесплатно, и так и дальше будет с новыми - доплачивать не надо),
=
Предыдущие материалы (в бандле все эти материалы с большой суммарной скидкой + новый данный):
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-26
4. Вайб-проектирование
5. Software Design с акцентом на Programming in Large
6. Programming in Large: продолжение
7. this :)
2👍26❤5🫡1
Вы помните, когда вам в последний раз приходилось писать код?
Вы помните, когда вам в последний раз приходилось читать код?
Вы помните, когда вам в последний раз приходилось отлаживать код?
Вы помните, когда вам в последний раз приходилось делать code review?
Вы помните, когда вам в последний раз приходилось узнавать что-то новое в программировании?
Вы помните, когда вам в последний раз приходилось использовать свою память?
Вы помните, когда вам в последний раз приходилось использовать свой ум?
Вы помните, когда вам в последний раз приходилось читать код?
Вы помните, когда вам в последний раз приходилось отлаживать код?
Вы помните, когда вам в последний раз приходилось делать code review?
Вы помните, когда вам в последний раз приходилось узнавать что-то новое в программировании?
Вы помните, когда вам в последний раз приходилось использовать свою память?
Вы помните, когда вам в последний раз приходилось использовать свой ум?
3👍27❤6✍4😎3🐳1
99,999999999999% программных систем чрезвычайно просты и не требуют новых и сложных решений.
Лишь небольшая часть компаний имеет дело с
-миллиардами пользователей
-безумным количеством запросов в секунду
-невероятными крайними случаями.
Скорее всего, вам больше не нужно совершенствоваться в разработке и архитекторстве; вам достаточно научиться быстро вайбкодить SaaS-ы с помощью искусственного интеллекта.
Лишь небольшая часть компаний имеет дело с
-миллиардами пользователей
-безумным количеством запросов в секунду
-невероятными крайними случаями.
Скорее всего, вам больше не нужно совершенствоваться в разработке и архитекторстве; вам достаточно научиться быстро вайбкодить SaaS-ы с помощью искусственного интеллекта.
😁30🤔7🐳5💯5❤2
Выцепил сегодня у Кента Бека классную фишку: когда делаешь code review или pr-обзор, не тыкай прямо в ошибку, если такая есть. Подскажи, какой тут тест пропущен. Кодер не должен тупо фиксить тикеты, он должен думать прежде всего, быть хотя бы немножечко в контексте проекта.
Я так-то уже лет пять на моих курсах по АСД интуитивно ровно так и делаю: если человек не проходит своим решением тесты на учебном сервере и не понимает где у него ошибка, я даю тест какой надо сделать на его ошибку ("красный"). При этом "просто спросить" не разрешается, сперва в любом случае надо сделать тесты на свой вроде бы работающий код (условный "зёлёный"), так как хотя тесты и требуются, но их
особо никто не пишет (правда, в этом году я и наличие тестов теперь проверяю обязательно). И даже когда пишешь свой "зелёный", в 90% проблема обнаруживается "сама собой" :)
Но, да, здесь существует контринтуитивный разрыв между абсолютной стратегически пользой TDD, и непониманием этой пользы в повседневной практике. Например, мало того что вы автоматически получаете регрессионные тесты, вы также получаете минимум двух клиентов для вашего API (подумайте, почему), а между 1 и 2 пропасть огромная (ну, то у вас система работала на одном сервере, а то на двух - 23 - 256 - уже особо без разницы), и т.д.
Десятки других фишек от кента разберём с ментатами в СИ.
Я так-то уже лет пять на моих курсах по АСД интуитивно ровно так и делаю: если человек не проходит своим решением тесты на учебном сервере и не понимает где у него ошибка, я даю тест какой надо сделать на его ошибку ("красный"). При этом "просто спросить" не разрешается, сперва в любом случае надо сделать тесты на свой вроде бы работающий код (условный "зёлёный"), так как хотя тесты и требуются, но их
особо никто не пишет (правда, в этом году я и наличие тестов теперь проверяю обязательно). И даже когда пишешь свой "зелёный", в 90% проблема обнаруживается "сама собой" :)
Но, да, здесь существует контринтуитивный разрыв между абсолютной стратегически пользой TDD, и непониманием этой пользы в повседневной практике. Например, мало того что вы автоматически получаете регрессионные тесты, вы также получаете минимум двух клиентов для вашего API (подумайте, почему), а между 1 и 2 пропасть огромная (ну, то у вас система работала на одном сервере, а то на двух - 23 - 256 - уже особо без разницы), и т.д.
Десятки других фишек от кента разберём с ментатами в СИ.
❤20❤🔥5⚡5✍5🙏3
Дёшево писать код == дорого сопровождать и развивать код.
Разница в дополнительную тысячу строк нейрокода, которая технически допустима, но в которой никто не хочет разбираться, дорогого стоит. Это ощутимые отложенные расходы. Вы передали счёт тому, кто унаследует это новое и никому не ведомое поведение(очень вероятно кстати, самому себе через пару месяцев:) .
Внесение изменений в такой код обходится недёшево ровно потому, что сам код был прост в создании. Он будет дёшев только в том случае, если человек полноценно эээ овладеет этим кодом :)
Таким образом, разделительная линия -- это не "может ли агент это написать ". Это "можете ли вы в этом разобраться, и одобрить". Соответствует ли это вашим ожиданиям. Можно ли это протестировать. Хотите ли вы в будущем это развивать.
Но эту базу в мэйнстриме никто не понимает/все игнорируют и пропускают мимо ушей, и в итоге имеем стремительно растущие груды ужасающего нейрокода, массовые увольнения разработчиков и прочую прелесть, стремительно приближающую полный крах айтишки. Дальше в мэйнстриме будет сильно хуже, выживет только элита.
Гораздо больше людей добились бы успеха, если бы умели мыслить в долгосрочной перспективе.
Разница в дополнительную тысячу строк нейрокода, которая технически допустима, но в которой никто не хочет разбираться, дорогого стоит. Это ощутимые отложенные расходы. Вы передали счёт тому, кто унаследует это новое и никому не ведомое поведение
Внесение изменений в такой код обходится недёшево ровно потому, что сам код был прост в создании. Он будет дёшев только в том случае, если человек полноценно эээ овладеет этим кодом :)
Таким образом, разделительная линия -- это не "может ли агент это написать ". Это "можете ли вы в этом разобраться, и одобрить". Соответствует ли это вашим ожиданиям. Можно ли это протестировать. Хотите ли вы в будущем это развивать.
Но эту базу в мэйнстриме никто не понимает/все игнорируют и пропускают мимо ушей, и в итоге имеем стремительно растущие груды ужасающего нейрокода, массовые увольнения разработчиков и прочую прелесть, стремительно приближающую полный крах айтишки. Дальше в мэйнстриме будет сильно хуже, выживет только элита.
Гораздо больше людей добились бы успеха, если бы умели мыслить в долгосрочной перспективе.
1💯15✍6❤🔥5🐳1