Нет ничего более ужасающе ошибочного в айтишке, нежели вот такая схема создания фич "мэйнстрим 💯"
1: Модели ORM, таблицы базы.
2: (REST) API
3: UI
4: Тестирование
5: Деплой
Вы создаёте кривую хрень, которая никому не нужна. Нафига вы отправляете свои модели в прод? Они ведь ничего не делают сами по себе. И никому нет дела до вашего API. Что, если через три дня вы поймёте, что API не соответствует UI, нужному пользователям? И мы не можем даже скорректировать такой подход, потому что никто не сможет нормально использовать этот код, написанный с нейронкой или без, без разницы.
И тут часто многие компании попадают в безвыходную ловушку, потому что когда упоминаешь правильный подход - аджайл (== клиентоориентированность, принципиально другой сеньорский майндсет - максимально быстро выкатываем хотя бы крохотно работающую фичу на 2% мощности, и потом постепенно допиливаем до 100 c реальным фидбеком), глупенькие менеджеры лишь хихикают, дескать это инфоцыганство. Ну штош, продолжайте работу многими месяцами без видимых для клиентов результатов, пока финансирование не отрубят :)
1: Модели ORM, таблицы базы.
2: (REST) API
3: UI
4: Тестирование
5: Деплой
Вы создаёте кривую хрень, которая никому не нужна. Нафига вы отправляете свои модели в прод? Они ведь ничего не делают сами по себе. И никому нет дела до вашего API. Что, если через три дня вы поймёте, что API не соответствует UI, нужному пользователям? И мы не можем даже скорректировать такой подход, потому что никто не сможет нормально использовать этот код, написанный с нейронкой или без, без разницы.
И тут часто многие компании попадают в безвыходную ловушку, потому что когда упоминаешь правильный подход - аджайл (== клиентоориентированность, принципиально другой сеньорский майндсет - максимально быстро выкатываем хотя бы крохотно работающую фичу на 2% мощности, и потом постепенно допиливаем до 100 c реальным фидбеком), глупенькие менеджеры лишь хихикают, дескать это инфоцыганство. Ну штош, продолжайте работу многими месяцами без видимых для клиентов результатов, пока финансирование не отрубят :)
1🔥30❤10✍7🐳4😁1
Прекрасное: нетфликс рухнул так, что обрушил едва ли не весь насдак, и это только верхушка айсберга. Они отказались в 2026-м вообще сообщать о своей аудитории! что ещё более красноречивый признак, насколько плохи у них дела на самом деле. Падает интерес к новым сериалам, вторые сезоны старых замораживаются (например, мощный Бороуз), люди массово отменяют подписку (которая постоянно дорожает, с 2011-го выросла в разы), ну и какая же ваша бизнес-стратегия, мистер Сарандос, если вы не планируете вкладываться в качественный контент? :)
А стратегия нетфликса последние годы была по хамски проста: поменьше контента, повыше цена и побольше папищеков. Фишка в том, что сперва они набрали дешёвых зрителей, а потом просто начали тупо их доить. И честно говоря, удивительно, как много компаний освоили этот метод: это и гугл, и твиттер, и эпла, и микрософт и многие другие.
Собственно, сегодня эту схему активно перенимают AI-гиги, превращаясь в шаблонный бизнес по привлечению аудитории и стремительно загоняя себя в тупик. Стратегия доения: повышаем цены и сокращаем вложения в бизнес, который просто стал дойной коровой. Выжимаем из этого все деньги, какие только сможешь, и так долго, как только сможешь.
И это всё та же классическая ошибка 99,999% предпринимателей любого уровня: доение приносит результат только в краткосрочной перспективе. В конце концов, они просто убивают денежную корову. Рано или поздно аудитория перестает быть их пленниками. И это происходит сейчас на нетфликсе. Собственно, и в спотифайе и диснее аналогично сейчас, и впервые в истории шмета перестала расти.
=
Но их кошмар -- это наше благословение :) Потому что прекращение прироста (а то и сокращение) аудитории означает, что этим компаниям нужно будет вернуться к созданию классного контента и обслуживанию клиентов, а не держать нас в рабстве.
Они не готовы к такому шагу, по крайней мере, не сейчас. Угождать клиентам - тяжёлая работа. Доить коров проще. Но у них совсем скоро не будет выбора. В конце концов, скот начинает сопротивляться :) Он даже может устроить панику на рынке!
Я даю всем этим лидерам по привлечению аудитории максимум 12-18 месяцев до того, как в их финансовых отчётах отразятся ужасающие последствия их чрезмерных усилий по доению, а пузырь AI с треском лопнет. И это всё может произойти куда быстрее!
Если бы они были мудры, они бы начали действовать сейчас. Но независимо от того, устранят ли они первопричину своей неразберихи с захватом аудитории и качественным контентом сейчас или позже, конечный результат будет тем же. Захваченная в плен аудитория скоро почувствует себя освобождённой!
И это будет означать самый большой сдвиг в потребительской онлайн-экономике нашего времени. Это будет трудная и славная битва для всех участников.
А стратегия нетфликса последние годы была по хамски проста: поменьше контента, повыше цена и побольше папищеков. Фишка в том, что сперва они набрали дешёвых зрителей, а потом просто начали тупо их доить. И честно говоря, удивительно, как много компаний освоили этот метод: это и гугл, и твиттер, и эпла, и микрософт и многие другие.
Собственно, сегодня эту схему активно перенимают AI-гиги, превращаясь в шаблонный бизнес по привлечению аудитории и стремительно загоняя себя в тупик. Стратегия доения: повышаем цены и сокращаем вложения в бизнес, который просто стал дойной коровой. Выжимаем из этого все деньги, какие только сможешь, и так долго, как только сможешь.
И это всё та же классическая ошибка 99,999% предпринимателей любого уровня: доение приносит результат только в краткосрочной перспективе. В конце концов, они просто убивают денежную корову. Рано или поздно аудитория перестает быть их пленниками. И это происходит сейчас на нетфликсе. Собственно, и в спотифайе и диснее аналогично сейчас, и впервые в истории шмета перестала расти.
=
Но их кошмар -- это наше благословение :) Потому что прекращение прироста (а то и сокращение) аудитории означает, что этим компаниям нужно будет вернуться к созданию классного контента и обслуживанию клиентов, а не держать нас в рабстве.
Они не готовы к такому шагу, по крайней мере, не сейчас. Угождать клиентам - тяжёлая работа. Доить коров проще. Но у них совсем скоро не будет выбора. В конце концов, скот начинает сопротивляться :) Он даже может устроить панику на рынке!
Я даю всем этим лидерам по привлечению аудитории максимум 12-18 месяцев до того, как в их финансовых отчётах отразятся ужасающие последствия их чрезмерных усилий по доению, а пузырь AI с треском лопнет. И это всё может произойти куда быстрее!
Если бы они были мудры, они бы начали действовать сейчас. Но независимо от того, устранят ли они первопричину своей неразберихи с захватом аудитории и качественным контентом сейчас или позже, конечный результат будет тем же. Захваченная в плен аудитория скоро почувствует себя освобождённой!
И это будет означать самый большой сдвиг в потребительской онлайн-экономике нашего времени. Это будет трудная и славная битва для всех участников.
1❤44👍1🔥1
Просили пояснить за аджайлы, ну действительно, оригинальный дух движухи уже давно утерян за тотальным забюрокрачиванием и инфоцыганством (скрам-мастера, коучи, сторипоинты, покеры, ретроспективы...), а самый ужос, что современный "аджайл" под видом "гибкости" поощряет избегание планирования.
В оригинале Agile предлагал адаптацию к двум классическим проблемам программной инженерии:
- люди плохо планируют сложные системы (но в основном из-за отсутствия профильных знаний),
- разработка медленная и дорогая.
С явлением же мощных нейронок обе эти проблемы исчезли, и Agile потерял смысл.
Да, но...
AI сам по себе
- требует полного контекста (при сильно ограниченном окне) и выдаёт качественный результат только при чётком и детальном описании системы,
- мультипликативно усиливает сильных разработчиков, создавая огромный отрыв от неинициативных мидлов например,
- позволяет заметно быстрее прорабатывать архитектуру, которую раньше продумывали неделями/месяцами (быстрее не означает качественнее, но например в плане проектирования API такое огромное количество инфы для датасетов, что LLM делает это уже весьма достойно).
И вот во что превратился аджайл в 2026-м:
1. Качественные спецификации (в идеале формальные, например свой DSL, что разбираем на ФА) + быстрые итерации по обратной связи.
2. Акцент на глубоком планировании: базовая документация и текстовая (полу)формальная модель предметной области как основной вход для LLM.
Все эти сторипойнты бёрндауны ретроспективы скрамы исчезают навсегда, а остаётся короткий цикл обратной связи с разработчиком, но без отмазок "это потом уточним".
Где твоя спека? А если не найду?
Мир изменился и в AI выигрывают кантрол-фрики (вроде меня:).
LLM ждёт, когда ей дадут чёткий план, поэтому становится важным не только скилл декомпозиции проекта на чистые функции (которые и локальная нейронка уже может норм запилить),
но и скилл синтеза, и тут начинают работать именно малоизвестные и довольно экзотические - функциональные - архитектуры, которые раньше считались довольно ограниченными паттернами, а теперь оказались прекрасной формальной склейкой для нейронок, дабы они не распылялись на мелкие бессвязные задачи.
В оригинале Agile предлагал адаптацию к двум классическим проблемам программной инженерии:
- люди плохо планируют сложные системы (но в основном из-за отсутствия профильных знаний),
- разработка медленная и дорогая.
С явлением же мощных нейронок обе эти проблемы исчезли, и Agile потерял смысл.
Да, но...
AI сам по себе
- требует полного контекста (при сильно ограниченном окне) и выдаёт качественный результат только при чётком и детальном описании системы,
- мультипликативно усиливает сильных разработчиков, создавая огромный отрыв от неинициативных мидлов например,
- позволяет заметно быстрее прорабатывать архитектуру, которую раньше продумывали неделями/месяцами (быстрее не означает качественнее, но например в плане проектирования API такое огромное количество инфы для датасетов, что LLM делает это уже весьма достойно).
И вот во что превратился аджайл в 2026-м:
1. Качественные спецификации (в идеале формальные, например свой DSL, что разбираем на ФА) + быстрые итерации по обратной связи.
2. Акцент на глубоком планировании: базовая документация и текстовая (полу)формальная модель предметной области как основной вход для LLM.
Все эти сторипойнты бёрндауны ретроспективы скрамы исчезают навсегда, а остаётся короткий цикл обратной связи с разработчиком, но без отмазок "это потом уточним".
Где твоя спека? А если не найду?
Мир изменился и в AI выигрывают кантрол-фрики (вроде меня:).
LLM ждёт, когда ей дадут чёткий план, поэтому становится важным не только скилл декомпозиции проекта на чистые функции (которые и локальная нейронка уже может норм запилить),
но и скилл синтеза, и тут начинают работать именно малоизвестные и довольно экзотические - функциональные - архитектуры, которые раньше считались довольно ограниченными паттернами, а теперь оказались прекрасной формальной склейкой для нейронок, дабы они не распылялись на мелкие бессвязные задачи.
3❤31✍9🤔3👍2
Репутация всех этих шмантропиков и опеняй уже давно пробила дно.
Пацаны Фембои вообще не отвечают за базар.
В январе 26-го Дарья Амодей (CEO Клодов) в очередной раз заявил что через полгода искусственный интеллект заменит программистов.
Ну и? Сегодня все эти харнессы-фигарнессы разрослись до такой степени, что превратились в запутанный мега-зоопарк-скилл, который по размеру уже существенно превосходит весь бэкенд 😁 При том что для его освоения и сам бэк надо очень уверенно знать, и в девопсе хорошо разбираться, и при том, что знание обвязок ценность само по себе имеет нулевую, так как в этой теме всё меняется буквально в считанные недели. Ну и нейронки все эти схемки постепенно всасывают внутрь себя, полностью их обесценивая 🙈
К сожалению вынужден признать, что фабла например в математике разбирается, ну, реально хорошо, даже жпт 5.6 сол не тянет так.
И что теперь? А потом что? И куда дальше? 😳
А никто не знает. Мой совет: изучайте классический бэк до хорошего архитектора.
Торвальдс в Мумбае на днях выдал базу (уже давно хорошо известную конечно):
Он больше не программист, а читатель pr-ов, чтобы понимать намерение автора;
AI лечит симптом, а не причину бага, оставляя уязвимости в смежных местах;
Rust не панацея, логические ошибки ведь всё равно остаются;
Пока AI даёт больше слопа чем пользы от ревью, их репорты больше отнимают время;
Человек обязан проверить и понять правку, а не отправлять её в мастер на удачу.
Типа, ценно умение видеть систему целиком, предвидеть последствия изменений, незаменимыми становятся те, кто развивает системное мышление (AI пишет код, но не строит ментальные модели) и прочая водичка 🐳 Выступление Линусу нейронка писала? :) Думаю, он скоро курсы будет продавать.
Вот реальная база 🤓 сможете ли вы без документации объяснить, почему та или иная критическая часть вашей системы сделана и работает именно так, и что в системе сломается, если изменить базовые допущения (если они конечно имеются в вашей ментальной модели системы)?
В январе 26-го Дарья Амодей (CEO Клодов) в очередной раз заявил что через полгода искусственный интеллект заменит программистов.
Ну и? Сегодня все эти харнессы-фигарнессы разрослись до такой степени, что превратились в запутанный мега-зоопарк-скилл, который по размеру уже существенно превосходит весь бэкенд 😁 При том что для его освоения и сам бэк надо очень уверенно знать, и в девопсе хорошо разбираться, и при том, что знание обвязок ценность само по себе имеет нулевую, так как в этой теме всё меняется буквально в считанные недели. Ну и нейронки все эти схемки постепенно всасывают внутрь себя, полностью их обесценивая 🙈
К сожалению вынужден признать, что фабла например в математике разбирается, ну, реально хорошо, даже жпт 5.6 сол не тянет так.
И что теперь? А потом что? И куда дальше? 😳
А никто не знает. Мой совет: изучайте классический бэк до хорошего архитектора.
Торвальдс в Мумбае на днях выдал базу (уже давно хорошо известную конечно):
Он больше не программист, а читатель pr-ов, чтобы понимать намерение автора;
AI лечит симптом, а не причину бага, оставляя уязвимости в смежных местах;
Rust не панацея, логические ошибки ведь всё равно остаются;
Пока AI даёт больше слопа чем пользы от ревью, их репорты больше отнимают время;
Человек обязан проверить и понять правку, а не отправлять её в мастер на удачу.
Типа, ценно умение видеть систему целиком, предвидеть последствия изменений, незаменимыми становятся те, кто развивает системное мышление (AI пишет код, но не строит ментальные модели) и прочая водичка 🐳 Выступление Линусу нейронка писала? :) Думаю, он скоро курсы будет продавать.
Вот реальная база 🤓 сможете ли вы без документации объяснить, почему та или иная критическая часть вашей системы сделана и работает именно так, и что в системе сломается, если изменить базовые допущения (если они конечно имеются в вашей ментальной модели системы)?
1❤36✍10😁3👍1
Гарри Поттер и Методы Математического Мышления
Книга 1. Гарри Поттер и Неорганический Интеллект.
Глава 16/23 (и все предыдущие). Зеркальный протокол
— Я не перестану быть собой, — сказал Гарри. — Я просто перестану быть той версией себя, которая содержит ошибку. Это не смерть. Это рефакторинг.
...Он не помнил, как выглядел мир до того, как появился Неорганический Интеллект. Он не помнил, что такое быть ребёнком, который не знает о типах и комбинаторах. Он не помнил — но знал, что это было. И это знание, записанное в типе, осталось с ним.
— Ты всё ещё ты? — спросила Гермиона. Она улыбалась. Но не весело. Скорее печально.
— Я не знаю, — сказал Гарри. — Но я знаю, что Неорганические больше не видят меня. Они видят только приманку. И они пойдут за ней.
Книга 1. Гарри Поттер и Неорганический Интеллект.
Глава 16/23 (и все предыдущие). Зеркальный протокол
— Я не перестану быть собой, — сказал Гарри. — Я просто перестану быть той версией себя, которая содержит ошибку. Это не смерть. Это рефакторинг.
...Он не помнил, как выглядел мир до того, как появился Неорганический Интеллект. Он не помнил, что такое быть ребёнком, который не знает о типах и комбинаторах. Он не помнил — но знал, что это было. И это знание, записанное в типе, осталось с ним.
— Ты всё ещё ты? — спросила Гермиона. Она улыбалась. Но не весело. Скорее печально.
— Я не знаю, — сказал Гарри. — Но я знаю, что Неорганические больше не видят меня. Они видят только приманку. И они пойдут за ней.
1🤓20❤7🐳5✍3
.
Облако драгоценностей за неделю.
Приватный клуб.
Парадоксально, что многие проблемы кажутся масштабными потому, что вы их ранее не замечали. Но это не значит, что вы должны всё бросать и отправляться их фиксить.
Для донов-начинающих:
(лонгрид)
Сейчас многие используют искусственный интеллект для генерации кода, а главное, что этот "скилл" стал обязательным в резюме, так что нравится вам это или нет, но вы больше не можете это игнорировать.
AI может помочь вам двигаться быстрее, и вы, наверное, уже знаете -- но это всё в теории. Генерировать код не то же самое, что понимать его. Это вообще совершенно другой навык...
Если я заставлю себя сделать хоть что-нибудь, даже сущую мелочь, более сложные задачи покажутся намного более лёгкими. Пишите код!
Для донов-неначинающих:
98. Интеграционные тесты: скам или польза?
Google и Twitter вообще давно заявляли, что "интеграционный тест - это бесполезный термин". Возможно, проблема в том, что под интеграционными тестами понимаются сильно разные вещи...
...Если вы, едва услышав "система перегружена", сразу же думаете "добавим ещё серверов", значит эта заметка для вас. Иногда это срабатывает, но в большинстве случаев - нет. Вы просто бездумно двигаете нагрузку, выдавая это за прогресс, и надеетесь, что угадаете...
Продолжаю набор на занятия для неначинающих (миддлы сеньоры), эксклюзивно для донов, 2 места закончились за 4 минуты.
(все старые материалы для донов быстро сгорают)
=
Новые материалы для ментатов Лаборатории.
В СильныеИдеи добавлен материал "150) 8 способов снизить трение в проекте".
Внешний API работает не совсем так, как вы думали, или он работал так, а потом его изменили. Ошибки. Предупреждения системы безопасности. При обновлении зависимостей что-то нарушается. Кто-то заболевает. Кто-то уходит из компании. Требования неясны, или заказчик меняет свои хотелки в процессе разработки. Компьютер сломался. Твоя IDE после обновления перестала загружать проект. Статистика против нас...
В раздел "Элитный программист" добавлен материал
99) Нетворк и эхо-камеры в 2026-м
Частая ошибка не знакомиться с разработчиками в вашем стеке просто ради знакомств на перспективу. Люди ошибочно считают, что такие контакты приведут скорее к токсичным разборкам, останутся поверхностными и будут пустой тратой энергии. Но это совершенно неверно...
В курс карьеры добавлен 141-й материал "Как учиться в эпоху искусственного интеллекта?". Три правила использования AI для ускорения обучения, а не для передачи своего мышления на аутсорсинг...
=
"Функциональные архитектуры" 147(+2) топиков
Добавил несколько материалов по архитектурам и ООП (эту тему вместе с ФП тоже продолжаю развивать).
После 150 материалов цена гайда (для новых) вырастет.
Last Principles Framework: готовы 19(+4) задач, закрыты 10(+3) тем из ~20 первого уровня. Вы же понимаете например, почему паттерн Фабрика - конструктивный отстой в сравнении с декларативным ко-произведением типов и глобальным морфизмом?
Откуда мы автоматически попадаем в Функциональные архитектуры ↑ :) только прихватив более сильные абстракции.
=
"ЛаМПовое":
На неделе выйдет седьмой гайд "Programming in Large"
=
it's a privilege to do things that are hard. 💪🏻
=
И вот наконец после долгого пути мы пришли к его началу.
Древняя ментатская головоломка
"Охотники Дюны"
Облако драгоценностей за неделю.
Приватный клуб.
Парадоксально, что многие проблемы кажутся масштабными потому, что вы их ранее не замечали. Но это не значит, что вы должны всё бросать и отправляться их фиксить.
Для донов-начинающих:
(лонгрид)
Сейчас многие используют искусственный интеллект для генерации кода, а главное, что этот "скилл" стал обязательным в резюме, так что нравится вам это или нет, но вы больше не можете это игнорировать.
AI может помочь вам двигаться быстрее, и вы, наверное, уже знаете -- но это всё в теории. Генерировать код не то же самое, что понимать его. Это вообще совершенно другой навык...
Если я заставлю себя сделать хоть что-нибудь, даже сущую мелочь, более сложные задачи покажутся намного более лёгкими. Пишите код!
Для донов-неначинающих:
98. Интеграционные тесты: скам или польза?
Google и Twitter вообще давно заявляли, что "интеграционный тест - это бесполезный термин". Возможно, проблема в том, что под интеграционными тестами понимаются сильно разные вещи...
...Если вы, едва услышав "система перегружена", сразу же думаете "добавим ещё серверов", значит эта заметка для вас. Иногда это срабатывает, но в большинстве случаев - нет. Вы просто бездумно двигаете нагрузку, выдавая это за прогресс, и надеетесь, что угадаете...
Продолжаю набор на занятия для неначинающих (миддлы сеньоры), эксклюзивно для донов, 2 места закончились за 4 минуты.
(все старые материалы для донов быстро сгорают)
=
Новые материалы для ментатов Лаборатории.
В СильныеИдеи добавлен материал "150) 8 способов снизить трение в проекте".
Внешний API работает не совсем так, как вы думали, или он работал так, а потом его изменили. Ошибки. Предупреждения системы безопасности. При обновлении зависимостей что-то нарушается. Кто-то заболевает. Кто-то уходит из компании. Требования неясны, или заказчик меняет свои хотелки в процессе разработки. Компьютер сломался. Твоя IDE после обновления перестала загружать проект. Статистика против нас...
В раздел "Элитный программист" добавлен материал
99) Нетворк и эхо-камеры в 2026-м
Частая ошибка не знакомиться с разработчиками в вашем стеке просто ради знакомств на перспективу. Люди ошибочно считают, что такие контакты приведут скорее к токсичным разборкам, останутся поверхностными и будут пустой тратой энергии. Но это совершенно неверно...
В курс карьеры добавлен 141-й материал "Как учиться в эпоху искусственного интеллекта?". Три правила использования AI для ускорения обучения, а не для передачи своего мышления на аутсорсинг...
=
"Функциональные архитектуры" 147(+2) топиков
Добавил несколько материалов по архитектурам и ООП (эту тему вместе с ФП тоже продолжаю развивать).
После 150 материалов цена гайда (для новых) вырастет.
Last Principles Framework: готовы 19(+4) задач, закрыты 10(+3) тем из ~20 первого уровня. Вы же понимаете например, почему паттерн Фабрика - конструктивный отстой в сравнении с декларативным ко-произведением типов и глобальным морфизмом?
Откуда мы автоматически попадаем в Функциональные архитектуры ↑ :) только прихватив более сильные абстракции.
=
"ЛаМПовое":
На неделе выйдет седьмой гайд "Programming in Large"
=
it's a privilege to do things that are hard. 💪🏻
=
И вот наконец после долгого пути мы пришли к его началу.
Древняя ментатская головоломка
"Охотники Дюны"
❤27👍6✍2
Как формально классифицировать разработчиков (мэйнстрима) через 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🔥26❤11✍4🤔2🥰1
Каждый не-технический человек, которого я знаю, что-то создаёт в своей теме с помощью AI. Каково ваше оправдание?
1🤔36🤝8👍6🐳3
Если нейронки уже отлично пишут код и здорово разбираются в архитектурах, алгоритмах и математике на уровне золотых медалистов, почему продолжают активно разрабатываться и выпускаться всё новые и новые и всё более и более дорогие модели?
🤔34😁19✍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👍1
Умение создавать программные сервисы, и умение создавать человечный контент в блогах (прежде всего текстовый), станут наиболее прибыльными навыками следующего десятилетия (да уже и текущего).
И именно программные сервисы, а не программные продукты - 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✍16
Мой 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❤6🫡2
Вы помните, когда вам в последний раз приходилось писать код?
Вы помните, когда вам в последний раз приходилось читать код?
Вы помните, когда вам в последний раз приходилось отлаживать код?
Вы помните, когда вам в последний раз приходилось делать code review?
Вы помните, когда вам в последний раз приходилось узнавать что-то новое в программировании?
Вы помните, когда вам в последний раз приходилось использовать свою память?
Вы помните, когда вам в последний раз приходилось использовать свой ум?
Вы помните, когда вам в последний раз приходилось читать код?
Вы помните, когда вам в последний раз приходилось отлаживать код?
Вы помните, когда вам в последний раз приходилось делать code review?
Вы помните, когда вам в последний раз приходилось узнавать что-то новое в программировании?
Вы помните, когда вам в последний раз приходилось использовать свою память?
Вы помните, когда вам в последний раз приходилось использовать свой ум?
3👍29❤7✍4😎4🐳1
99,999999999999% программных систем чрезвычайно просты и не требуют новых и сложных решений.
Лишь небольшая часть компаний имеет дело с
-миллиардами пользователей
-безумным количеством запросов в секунду
-невероятными крайними случаями.
Скорее всего, вам больше не нужно совершенствоваться в разработке и архитекторстве; вам достаточно научиться быстро вайбкодить SaaS-ы с помощью искусственного интеллекта.
Лишь небольшая часть компаний имеет дело с
-миллиардами пользователей
-безумным количеством запросов в секунду
-невероятными крайними случаями.
Скорее всего, вам больше не нужно совершенствоваться в разработке и архитекторстве; вам достаточно научиться быстро вайбкодить SaaS-ы с помощью искусственного интеллекта.
😁32🤔8🐳5💯5❤2
Выцепил сегодня у Кента Бека классную фишку: когда делаешь code review или pr-обзор, не тыкай прямо в ошибку, если такая есть. Подскажи, какой тут тест пропущен. Кодер не должен тупо фиксить тикеты, он должен думать прежде всего, быть хотя бы немножечко в контексте проекта.
Я так-то уже лет пять на моих курсах по АСД интуитивно ровно так и делаю: если человек не проходит своим решением тесты на учебном сервере и не понимает где у него ошибка, я даю тест какой надо сделать на его ошибку ("красный"). При этом "просто спросить" не разрешается, сперва в любом случае надо сделать тесты на свой вроде бы работающий код (условный "зёлёный"), так как хотя тесты и требуются, но их
особо никто не пишет (правда, в этом году я и наличие тестов теперь проверяю обязательно). И даже когда пишешь свой "зелёный", в 90% проблема обнаруживается "сама собой" :)
Но, да, здесь существует контринтуитивный разрыв между абсолютной стратегически пользой TDD, и непониманием этой пользы в повседневной практике. Например, мало того что вы автоматически получаете регрессионные тесты, вы также получаете минимум двух клиентов для вашего API (подумайте, почему), а между 1 и 2 пропасть огромная (ну, то у вас система работала на одном сервере, а то на двух - 23 - 256 - уже особо без разницы), и т.д.
Десятки других фишек от кента разберём с ментатами в СИ.
Я так-то уже лет пять на моих курсах по АСД интуитивно ровно так и делаю: если человек не проходит своим решением тесты на учебном сервере и не понимает где у него ошибка, я даю тест какой надо сделать на его ошибку ("красный"). При этом "просто спросить" не разрешается, сперва в любом случае надо сделать тесты на свой вроде бы работающий код (условный "зёлёный"), так как хотя тесты и требуются, но их
особо никто не пишет (правда, в этом году я и наличие тестов теперь проверяю обязательно). И даже когда пишешь свой "зелёный", в 90% проблема обнаруживается "сама собой" :)
Но, да, здесь существует контринтуитивный разрыв между абсолютной стратегически пользой TDD, и непониманием этой пользы в повседневной практике. Например, мало того что вы автоматически получаете регрессионные тесты, вы также получаете минимум двух клиентов для вашего API (подумайте, почему), а между 1 и 2 пропасть огромная (ну, то у вас система работала на одном сервере, а то на двух - 23 - 256 - уже особо без разницы), и т.д.
Десятки других фишек от кента разберём с ментатами в СИ.
❤26❤🔥6⚡6✍6🙏3
Дёшево писать код == дорого сопровождать и развивать код.
Разница в дополнительную тысячу строк нейрокода, которая технически допустима, но в которой никто не хочет разбираться, дорогого стоит. Это ощутимые отложенные расходы. Вы передали счёт тому, кто унаследует это новое и никому не ведомое поведение(очень вероятно кстати, самому себе через пару месяцев:) .
Внесение изменений в такой код обходится недёшево ровно потому, что сам код был прост в создании. Он будет дёшев только в том случае, если человек полноценно эээ овладеет этим кодом :)
Таким образом, разделительная линия -- это не "может ли агент это написать ". Это "можете ли вы в этом разобраться, и одобрить". Соответствует ли это вашим ожиданиям. Можно ли это протестировать. Хотите ли вы в будущем это развивать.
Но эту базу в мэйнстриме никто не понимает/все игнорируют и пропускают мимо ушей, и в итоге имеем стремительно растущие груды ужасающего нейрокода, массовые увольнения разработчиков и прочую прелесть, стремительно приближающую полный крах айтишки. Дальше в мэйнстриме будет сильно хуже, выживет только элита.
Гораздо больше людей добились бы успеха, если бы умели мыслить в долгосрочной перспективе.
Разница в дополнительную тысячу строк нейрокода, которая технически допустима, но в которой никто не хочет разбираться, дорогого стоит. Это ощутимые отложенные расходы. Вы передали счёт тому, кто унаследует это новое и никому не ведомое поведение
Внесение изменений в такой код обходится недёшево ровно потому, что сам код был прост в создании. Он будет дёшев только в том случае, если человек полноценно эээ овладеет этим кодом :)
Таким образом, разделительная линия -- это не "может ли агент это написать ". Это "можете ли вы в этом разобраться, и одобрить". Соответствует ли это вашим ожиданиям. Можно ли это протестировать. Хотите ли вы в будущем это развивать.
Но эту базу в мэйнстриме никто не понимает/все игнорируют и пропускают мимо ушей, и в итоге имеем стремительно растущие груды ужасающего нейрокода, массовые увольнения разработчиков и прочую прелесть, стремительно приближающую полный крах айтишки. Дальше в мэйнстриме будет сильно хуже, выживет только элита.
Гораздо больше людей добились бы успеха, если бы умели мыслить в долгосрочной перспективе.
1💯25✍10❤🔥5🐳2👍1
В рамках работы над Last Principles Framework познакомился с "-оидизацией": это когда мы допускаем существование некоторой фиговины во множественном числе как сущности первого класса. Например у тебя есть моноид (монада - это моноид...), и таким превращением его (как целостной структуры) в моноидоид получаем моноидальную категорию (hom-множество само категория, а нафига это понимать программисту, разбираем на примерах в LPF: это каррирование в частности). Собственно, это ФП и есть: множество типов как объекты и функции как стрелки.
Далее, продолжая оидизацию, имеем моноидальный моноидоидоид :)
Ну, это всё естественные преобразования теорката как функциональные паттерны:
трансформеры монад, линзы, оптики, разбираем их на первом курсе ФП (хотя в этом на самом деле от силы 2% функциональщиков/хаскелистов разбираются: они ещё более ленивые, чем мэйнстримщики:). Зато в работе с искусственным идиотом это всё дает мощные прорывы при составлении формальных спецификаций.
Но мы конечно пойдём дальше :)
Надеюсь вы заметили что на самом деле любую операцию можно обобщить: сначала на множество типов, потом на стрелки между стрелками, и таким образом мы можем проектировать бесконечно композируемые мета-абстракции.
Так, следующим шагом становится моноидальный моноидальный (не тафтология; подумайте, почему) моноидоидоидоид :)
Получаем преобразования между естественными преобразованиями (в продвинутых библиотеках эффектов, для формальной верификации...), но на самом деле мне это всё очень нравится прежде всего в том плане, что супер прокачивает "мышление (мета-)спецификациями" прежде всего.
Фишка же в том, что мета-паттерн
"когда у тебя есть тип данных, всегда можно сделать его параметрическим (обобщив до полиморфного типа или до тайпкласса например), надстроив новый уровень стрелок"
можно применять на всех уровнях!
А ФП - это всего лишь про обобщение максимум до 3-категории: через функторы монады естественные преобразования трансформеры оптики...
Далее, продолжая оидизацию, имеем моноидальный моноидоидоид :)
Ну, это всё естественные преобразования теорката как функциональные паттерны:
трансформеры монад, линзы, оптики, разбираем их на первом курсе ФП (хотя в этом на самом деле от силы 2% функциональщиков/хаскелистов разбираются: они ещё более ленивые, чем мэйнстримщики:). Зато в работе с искусственным идиотом это всё дает мощные прорывы при составлении формальных спецификаций.
Но мы конечно пойдём дальше :)
Надеюсь вы заметили что на самом деле любую операцию можно обобщить: сначала на множество типов, потом на стрелки между стрелками, и таким образом мы можем проектировать бесконечно композируемые мета-абстракции.
Так, следующим шагом становится моноидальный моноидальный (не тафтология; подумайте, почему) моноидоидоидоид :)
Получаем преобразования между естественными преобразованиями (в продвинутых библиотеках эффектов, для формальной верификации...), но на самом деле мне это всё очень нравится прежде всего в том плане, что супер прокачивает "мышление (мета-)спецификациями" прежде всего.
Фишка же в том, что мета-паттерн
"когда у тебя есть тип данных, всегда можно сделать его параметрическим (обобщив до полиморфного типа или до тайпкласса например), надстроив новый уровень стрелок"
можно применять на всех уровнях!
А ФП - это всего лишь про обобщение максимум до 3-категории: через функторы монады естественные преобразования трансформеры оптики...
1🤯19❤7✍5👏2🏆1
Продолжаю работу с ментатами 🤓
Почти ничего не делал именно в плане карьерного развития — основное внимание сосредоточил на успешном релизе приложения в продакшен...
HR очень сильно давила чтобы я принял оффер...
Очень много потратил времени просто на то, чтобы тесты запустились, так как был конфликт версий докера и библиотеки test-containers...
На самом деле ваши два последних поста в вк были настолько в тему, что я аж удивился. Может быть вы и в правду гильд навигатор...
Просто я реально неделю сидел с тикетом, пока тимлид отдыхал, где половина не указана, а замещающий его тоже ни бэ ни мэ...
Посетил внутренний вебинар по харнесу, ничего нового не узнал,
...многие в целом ничего не читают, даже посты в внутреннем комьюнити, а интересны всем более прикаладные вещи
C одной стороны сегодня можно всё что угодно узнать у нейронки, причём с обратной связью, с другой стороны этим пользуется от силы 2% :) Поэтому у элиты (с блогами) (но и только у неё) всегда всё будет хорошо, особенно на фоне, что теория интересна от силы 2% от этих 2%.
Рекурсивные типы - это мощь. Оказывается, я их интуитивно уже использовал в одной из корпоративных задач. В целом, у меня в голове произошёл глобальный сдвиг к концепции "поведение как данные", и я уже практикуюсь на реальных проектах именно мысля в этом ключе...
Так-то мы многое подобное используем интуитивно и часто криво ("в каждой тыще строк твоего кода есть хотя бы одна монада"), цель Лаборатории как раз чтобы вытащить эти функциональные паттерны в сознание и получить кратный профит в кодинге. Только никакие книжки в этом не помогут, нужна оч. тесная теория+практика.
Если бы не была ясна идея и подводка к использованию ФП, я бы всерьёз задумался для чего это нам нужно, если задача действительно быстрее и проще решается классическим способом)
Конечно хотелось бы применять это в своих проектах на работе, но пока сложно подстроить мышление в функциональном стиле под темп задач, да и думаю лучше дождаться прохождения функциональной архитектуры.
ФП применяйте сперва в рабочих задачах снизу: пишите чистые функции и комбинируйте их, и не смешивайте бизнес-логику с инфраструктурой для начала.
С ноутбуками знаком, со времён работы с МЛщиками, обычно их рабочие репозитории представляли собой огромные слабо-структурированные портянки)
Благодарю. Было крайне познавательно и интересно. Получил огромное удовольствие от структуризации полученных знаний (и приобретения новых :). Приобрел больше полезного опыта, чем за год работы до.
Очень благодарен за предоставляемые возможности для системного и глубокого образования. Такая редкость, что даже верится с трудом. С нетерпением жду, что дальше. Спасибо большое!
❤️
Почти ничего не делал именно в плане карьерного развития — основное внимание сосредоточил на успешном релизе приложения в продакшен...
HR очень сильно давила чтобы я принял оффер...
Очень много потратил времени просто на то, чтобы тесты запустились, так как был конфликт версий докера и библиотеки test-containers...
На самом деле ваши два последних поста в вк были настолько в тему, что я аж удивился. Может быть вы и в правду гильд навигатор...
Просто я реально неделю сидел с тикетом, пока тимлид отдыхал, где половина не указана, а замещающий его тоже ни бэ ни мэ...
Посетил внутренний вебинар по харнесу, ничего нового не узнал,
...многие в целом ничего не читают, даже посты в внутреннем комьюнити, а интересны всем более прикаладные вещи
C одной стороны сегодня можно всё что угодно узнать у нейронки, причём с обратной связью, с другой стороны этим пользуется от силы 2% :) Поэтому у элиты (с блогами) (но и только у неё) всегда всё будет хорошо, особенно на фоне, что теория интересна от силы 2% от этих 2%.
Рекурсивные типы - это мощь. Оказывается, я их интуитивно уже использовал в одной из корпоративных задач. В целом, у меня в голове произошёл глобальный сдвиг к концепции "поведение как данные", и я уже практикуюсь на реальных проектах именно мысля в этом ключе...
Так-то мы многое подобное используем интуитивно и часто криво ("в каждой тыще строк твоего кода есть хотя бы одна монада"), цель Лаборатории как раз чтобы вытащить эти функциональные паттерны в сознание и получить кратный профит в кодинге. Только никакие книжки в этом не помогут, нужна оч. тесная теория+практика.
Если бы не была ясна идея и подводка к использованию ФП, я бы всерьёз задумался для чего это нам нужно, если задача действительно быстрее и проще решается классическим способом)
Конечно хотелось бы применять это в своих проектах на работе, но пока сложно подстроить мышление в функциональном стиле под темп задач, да и думаю лучше дождаться прохождения функциональной архитектуры.
ФП применяйте сперва в рабочих задачах снизу: пишите чистые функции и комбинируйте их, и не смешивайте бизнес-логику с инфраструктурой для начала.
С ноутбуками знаком, со времён работы с МЛщиками, обычно их рабочие репозитории представляли собой огромные слабо-структурированные портянки)
Благодарю. Было крайне познавательно и интересно. Получил огромное удовольствие от структуризации полученных знаний (и приобретения новых :). Приобрел больше полезного опыта, чем за год работы до.
Очень благодарен за предоставляемые возможности для системного и глубокого образования. Такая редкость, что даже верится с трудом. С нетерпением жду, что дальше. Спасибо большое!
❤️
2❤28✍3🏆1