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

Заметка на хабре про SOLID -- классический пример
отсутствия университетского образования незнания фундаментальных основ, когда изучаешь темки поверхностно as is, без понимания принципов, заложенных в их основу (SOLID например уже как следствие разбираем на моём треке по ООАП).

А кто просто почитал по SOLID статейки уровня википедии и пытается их бездумно применять, так и будет всю жизнь жутко косячить, думая что SRP - это вот такое =>

"Рассмотрим персонажа ролевой игры (RPG). Он может обладать такими возможностями, как перемещение, атака, взаимодействие с окружающей средой и отображение анимации. Придерживаясь SRP, можно было бы разделить эти функциональные возможности на отдельные классы, такие как CharacterMovement, CharacterCombat, CharacterInteraction и CharacterAnimation."

)))

Многие современные API существуют десятилетиями (например, Windows API наглядный пример). Чем шире используется система, и чем больше требуется совместимости между версиями, тем ситуация печальнее. Например, есть такая глобальная система бронирования авиабилетов SABRE, API которой существует уже 60 лет ))) и если у вас когда-либо был неудачный опыт работы с авиакомпанией, есть шанс, что частично это было связано с её API.

Когда на ваше API завязано множество сторонних ИТ-систем, вы, возможно, уже никогда не сможете изменить поведение вашего API.

Недавно консультировал небольшую команду по теме дизайна API (в области AI, ага :), и в процессе придумал один очень простой, очень поучительный и очень наглядный use case, который считаю особенно умным ))) Скоро расскажу курсантам в СильныхИдеях. Посмотрев на 5 строчек кода (определение типа), вы сразу поймёте важный принцип проектирования долгосрочно развивающихся API.

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

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

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

Ну ладно, хорошо, учат вот такому, более "продвинутому" 🙈 ^^^

Это примерно тот "архитектурный" уровень, которому вы в итоге научитесь на массовых курсах по программированию и веб-фреймворкам за 100 тысяч рублей :)

Ну, да, такое случается с многими каждый раз, когда они решают поизучать гомотопическую теорию типов. Причём, когда вы хотите узнать побольше о HoTT, то ожидаете 690 страниц теории категорий, но на самом деле получаете 890 страниц Agda :)

И в целом, теоркат на пути к HoTT совсем не первый, не второй и не третий шаг.

Иначе вы не въедете в теоркат на уровне универсальных пропертей вроде UMP.

Вы написали метод из 30 строк. В нём вы замечаете фрагменты, которые вроде бы выполняют более мелкие действия. Разбиваете ли вы этот метод на более мелкие методы, по SRP?

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

Если же вы не разбиваете его, то всё будет наоборот: вы избавляетесь от множества методов и внутренней вложенности вызовов, однако явные границы между логикой теряются.

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

Действительно, сейчас такой тренд, что "эксперты по web3" спешно переквалифицировываются в "экспертов по AI" 😂

Кент Бек (автор XP и TDD) внезапно взялся продавать воркшопы по системному мышлению.

Молюсь, чтобы со мной никогда ничего подобного бы не случилось.

Желаю Беку, чтобы он не скатился ещё ниже, до каких-нибудь курсов по раскрытию внутренних резервов :)

Между прочим, согласно легендарному стандарту IEEE-754 (арифметика с плавающей запятой), и нули и бесконечности в языке программирования должны уметь быть с явным знаком. То есть должны явно различаться и +0.0 и -0.0 , которые с одной стороны, равны, но с другой стороны, их знак должен учитываться в некоторых функциях (каком-нибудь арктангенсе).

Например, в Python результаты -1.0 / float('inf') и +1.0 / float('inf') получатся соответственно -0.0 и +0.0, которые "в целом" равны, но "в деталях" использования могут давать разные результаты.

P.S. До массовой поддержки IEEE-754 всё было совсем печально.

6. AI- репетитор: персонализированная помощь в обучении, подробные ответы на вопросы, объяснение концепций по ряду предметов. Дополнительные услуги могут включать составление учебных планов, аналитику обучения и рекомендации ресурсов.

7. SaaS-платформа автоматизации взаимодействия с клиентами по различным каналам (чат, электронная почта, социальные сети). Дополнительные услуги могут включать анализ настроений клиентов, их профилирование и прогнозное моделирование оттока клиентов.

8. Перевод и локализация (в России почти 300 языков и диалектов): мгновенный перевод текстов, а также услуги по локализации -- культурная адаптация контента, SEO на разных языках и консультации по региональному маркетингу.

9. Бизнес-аналитика: анализ данных и предоставления адекватных выводов. Дополнительные услуги могут включать предиктивное моделирование, обнаружение аномалий, визуализацию данных, и даже генерацию аналитических SQL-запросов.

10. Ну, всяческая помощь программистам в реальном времени, автоматическая генерация кода, поиск багов, отладка, тестирование, предложения по оптимизации кода. Дополнительные функции могут включать управление проектами, code review и т. п.

Некоторые из этих уже у нас появились, но конкуренция нулевая.

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

Или всё вышеперечисленное.

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

"Intelligent Machines and Idiotic Humans: A Startup Story"
(идеи для AI-стартапов)

Серия 7. 10 идей по масштабированию стартапа, состоящего из одного человека, с помощью AI

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

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

Вот 5 возможных тем (всё это с помощью API OpenAI, GPT4ALL или подобных)

1. Интеллектуальная платформа для создания контента: генерируем материалы для блогов, статьи, посты в социальных сетях и т. д., и предлагаем такие услуги, как контент-стратегия, SEO-оптимизация, таргетинг аудитории и анализ эффективности.

2. Автоматизированная платформа, генерирующая маркетинговые кампании (электронные письма, посты в социальных сетях, рекламные объявления), дополнительно A/B-тестирование, аналитика, управление кампаниями и персонализация на основе данных о клиентах.

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

4. Конструктор резюме: Сервис для составления резюме и сопроводительных писем в соответствии с конкретными описаниями вакансий. Дополнительные функции могут включать подбор вакансий, инструктаж под собеседования и карьерные советы.

5. Помощь здравоохранению: Формирование возможных диагнозов на основе симптомов + поддержка психического здоровья :)
Можно интегрировать с электронными медицинскими картами для персонализации.

Разработка AI продвигается невероятными темпами, и меня постоянно спрашивают испуганные непрограммисты

С чего мне начать??

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

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

-- Чёткая цель: формулируете, что именно вы хотите получить, с однозначными подробными инструкциями на хорошем английском, осознавая, что AI не может "думать" (его архитектура в принципе не приспособлена для логических рассуждений), хотя и может -- в определённых пределах -- "понимать";

-- Ограничения (пожалуй, самое важное, но сильно недооценённое): что вы не хотите получить (если вы не укажете, что AI не должен делать, то скорее всего получите что-то весьма далёкое от вашей цели, и затем будете долго мучиться многими итерациями);

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

P.S. Надежды на то, что AI в ближайшие 20 лет (а может, и гораздо быстрее) не лишит работы подавляющее количество людей за Земле (98%), примерно аналогичны надеждам того парня, который верил, что википедия и мир опенсорса никогда не будут существовать, потому что дескать никто не станет работать бесплатно, а большинство людей в любом случае глупы.

В 2022-м мировой рынок AI составлял 136 млрд. долл., а к концу текущего десятилетия он вырастет в 13 (!) раз. Уже в ближайшие 2-3 года работу из-за AI потеряет 85 млн. человек, но появится 97 млн. новых (вроде промпт-инженеров).

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

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

Например, что произойдет с криптоиндустрией, когда миллиарды экземпляров продвинутой версии AutoGPT будут управлять параллельной экономикой BTC? Когда стремительно развиваются такие децентрализованные сети, как Lightning?

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

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

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

Композиция вместо этого работает только с интерфейсом внешнего класса и будет надёжной.

Цель каждой строки кода - сделать какой-то факт истинным. Сложность кода вытекает из того, насколько трудно установить факт из того, что уже является истиной.

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

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

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

Весьма достойный в целом материал из вики "Composition over inheritance", разошедшийся по куче статей и учебников, где приведена большая диаграмма наследования из известного учебника по паттернам Фрименов, который я рекомендую начинающим, но в котором, например, самый важный паттерн Visitor вообще не упоминается.

Но посмотрите, тут например Duck выполняет композицию с интерфейсами Flyable и Quackable, а не наследуется от них. Но вы что, собираетесь создавать свободно плавающий экземпляр Flyable в своём проекте? лол

А вот MallardDuck наоборот, зачем-то наследуется от Duck, хотя этого как раз хотелось бы избежать. Опять-таки, главный смысл наследования -- это обеспечить полиморфизм подтипов, но он подразумевает создание экземпляра родителя Duck, ну и зачем он нужен, свободно плавающим объектом в коде, как и Flyable? Тут как раз используйте композицию и паттерн делегирования.

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

Как программисты, люди мы или нет :) , мы должны адаптироваться или умереть.

Когда несколько десятилетий назад Google выпустила свою поисковую систему, программист, способный эффективно её использовать, оказывался в 10 раз продуктивнее того, кто этого не делал.

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

То же самое сейчас относится и к большим языковым моделям: используйте LLM ежедневно в своей работе, или станете "неактуальными".

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

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

Что нам следует делать? Я не знаю. В идеале, надо бы инвестировать в (а лучше всего, срочно создавать самим) компании, которые явно выиграют от появления AI. Как минимум, создавайте свой собственный апворк.

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

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

P.S. Однако я не консультант по инвестициям -- я просто фрик из Рунета :)

P.P.S. Кстати, третье, на что вы можете сделать ставку -- это стать консультантом по этому всему, в первую очередь по AI.

Вот что сказал по поводу "AI vs фриланс" Хейден Браун, генеральный директор Upwork: появляются совершенно новые рабочие роли, такие как промпт-инженеры, на которые формируется взрывной спрос, поскольку практически в каждой отдельной профессии теперь ожидается интеграция инструментов генеративного AI на основе LLM в их работу.

Хейден также утверждает, что благодаря появлению сильного искусственного интеллекта вроде ChatGPT и других LLM, спрос на квалифицированную рабочую силу только растёт.

Развитие AGI в ближайшие годы заставит большинство компаний отказаться от своих традиционных методов и перейти к новым способам организации сотрудников, и тут фриланс как способ такой организации труда будет очень выигрышным.

Изменения неизбежны в ближайшие годы, и более гибкие умом профессионалы получат значительное преимущество. Лучше быть фрилансером с диверсифицированным набором услуг, продающим свои специализированные знания сразу нескольким компаниям по всему миру, чем сотрудником, продающим свои навыки одной организации, что всегда сопряжено с высокими рисками. А если банкротство, увольнение, AI, придёт новый придурошный начальник, как в сериале "Консультант"?