Когда спроектировал правильную архитектуру, и тимлид тебя спрашивает:

- Как остановить работу наших serverless воркеров?

- Никак. Они бессмертны.

- Можно ли убить узел, на котором они работают?

- Да, но он быстро вернётся и продолжит работу с того места, на котором остановился.

- Что же я могу сделать, чтобы вырубить воркеры??

- В любом случае ты сдашься раньше, чем они.

"LLM просто занимаются предсказанием следующего слова" -- говорит человек, который понятия не имеет, откуда в его собственных устах берётся следующее слово.

Программисты NASA явно не проходили мой курс Ясный код )))

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

Серия 9. Больше программирования и оптимизации.

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

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

Вот же она, золотая жила! :) Вдобавок хайп здесь легко ловится.

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

Например, один из самых популярных AI/ML фреймворков PyTorch (по нему у меня скоро будет курс) написан, очевидно, на Python :) что уже намекает.

Вот наглядный пример:
https://news.ycombinator.com/item?id=35171527

Некто переписал llama.cpp (это не файл, а порт фейсбуковской лламы на сишечке, для автономного запуска на своём компе, хотя по сути один основной файл и есть) на раст, и сразу привлёк к себе внимание. Посмотрите, он уже на 8-м месте в рейтинге, хорошо поднимается, и в мете его наверняка заметили:
https://ossinsight.io/collections/chat-gpt-alternatives/

llama . rs работает (вроде бы) быстрее чем порт на плюсах, экономнее в плане памяти и, что весьма важно, надёжно и безопасно (для чего раст и создавался). Оригинальный код llama.cpp кстати в целом простой, никакой особой логики, но надо хорошо понимать сам алгоритм и структуры данных. В данном случае на расте запилили высокоуровневые абстракции, где используются структуры данных из сишной тензорной либы ggml, и затем ей передаются веса для вычислений. PyTorch используется для конвертации оригинальных весов.

Где и что несложное для начала можно попробовать пооптимизировать, спросите например LLaMA, и попросите её помощь )

P.S. Карпатый, кстати, на днях нафигачил инференс llama2.c , впихнув его в автономные 500 строк кода, после чего запустил на какой-то овощеварке )))

Задачка на выходные:
- переписать эти 500 строк на расте,
- запустить на bare metal,
- запостить в комбинатор,
- профит

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

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

А также всегда масштабируются вертикально.

При отличной подготовке практически любой нормальный человек может превзойти талантливого человека с нормальной подготовкой.

Именно это я и стараюсь обеспечить.

Сейчас программистские вакансии на 300k/секмес хочут большую кучу всего, и при этом кандидатов отбирают (пока ещё) достаточно придирчиво. Да, но это всего лишь три тысячи долларов (и далее будет, вероятно, ещё меньше); в США джуниоры получают больше, а за аналогичное множество скиллов платят от 150 тыс. долл. в год.

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

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

Восточный подход однако совсем другой, и на продвинутых темах по software design я стараюсь использовать уже его. Сперва учитель даёт множество странных задачек, решение которых вы находите с трудом, и фактически не понимаете, зачем они вообще нужны ("а что мне это даст на практике?" :). Однако со временем, через многие десятки задач, вы внезапно обнаруживаете, что казавшееся ранее сложным рабочее задание по проектированию или архитектурам выглядит совсем простым и лёгким для реализации.

Так, кстати, устроены некоторые топовые курсы по computer science лучших университетов мира.

"Даже если AI будет сверхразумом, существуют фундаментальные ограничения! Он не сможет творить магию!"

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

Единственное предсказание, в котором мы можем быть уверены: когда AI станет в 1000 раз умнее нас, он будет достаточно умён, чтобы перехитрить нас.

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

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

А ещё в прошлом году большинство экспертов считали, что AGI появится не ранее, чем через 20+ лет. Временные рамки стремительно сокращаются.

+ Ещё немного прогнозов от Metaculus (платформа прогнозирования научно-технических достижений)

- Когда выйдет GPT-5? Декабрь 2024 г.

- Насколько вероятна "зима AI" (заморозка всех исследований) к 2025-му году? 4%

- Будет ли первый AGI основан на глубоком обучении? 90%

- Будет ли один из первых AGI "сознательно" претендовать на наличие сознания? 70%

- Когда мы создадим "слабый AGI", сколько времени пройдет до появления сверхразумного AI? 9 месяцев

- Когда AI пройдёт IQ-тест MENSA (в мире таковых около 150 тыс. человек)? Июнь 2025 г.
Попробуйте кстати пройти, а вдруг вы действительно считанный гений?

- Создадим ли мы AI человеческого уровня к 2040-му? 92%

- Когда AI сможет писать программы для самоулучшения? 2026-й

- Будет ли GPT-5 обладать способностью автономной репликации? 22%

- Убьёт ли AI онлайн-покер? 12% (хоть это хорошо :)

P.S. Из этого всего, кстати, следует важный нюанс: гонка технологий AI между странами -- это полная противоположность гонке вооружений. При гонке вооружений одна из сторон выигрывает, а при создании AGI выигравших не будет: мир сразу захватят неорганические существа с невероятным интеллектом. Пока же топовые научные команды, конкурируя, спешат изо всех сил поскорее создать Разрушителя Миров...

На днях уважаемый Максут Шадаев сообщил, что ширится программа массового обучения программированию, и само по себе это безусловно хорошо:

- в прошлом году на курс по изучению современных языков программирования были зачислены 130 тыс. школьников с 8 по 11 класс. В этом году рассчитываем зачислить еще 140 тыс. человек...
-- количество ежегодно открываемых бюджетных мест в вузах на ИТ-специальности -- 117 тыс. Всего сейчас обучается почти 350 тыс. будущих ИТ-разработчиков и инженеров...
- на цифровые кафедры в вузах было зачислено 112 тыс. студентов...
- за время работы Школы-21 обучение прошли 25 тыс. человек, сейчас учатся еще 5 тыс...

Всего в российском ИТ работает 740 тыс. человек, и нехватка составляет 500-700 тыс. человек.

Скилл программирования по жизни весьма полезный в любом случае.

Но есть нюанс.

"На выходе мы получаем разработчиков высокого класса, которые без проблем трудоустраиваются в ведущие ИТ-компании..."

Вам в это верится? Моё оценочное суждение такое, что проблема российского ИТ совсем не в том, что не хватает 700 тыс. разработчиков, и надо готовить на всевозможных курсах всё больше и больше человек. Проблема в том, что ребят, потенциально готовых для работы в ИТ, полным полно (и число их быстро растёт), однако устроиться на первую работу джуниором без опыта сегодня крайне сложно. Причина ровно в том, что 98% компаний сейчас боятся инвестировать в развитие, в набор малоопытных ребят, в дальнейший рост которых надо вкладываться. И через сколько лет у компаний этот страх роста пройдёт, никому не ведомо.

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

Сэм Альтман подался в инфоцыганы, в тему успешного успеха? :)

13(!) правил how-to-be-successful

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

Темплейты C++ статически утинно типизированы )))

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

Хорошая человеческая заметка.

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

Лайфхак: я иногда тестирую адекватность спроса в ИТ, и публикую выдуманные резюме. Пока один из лучших результатов получается, когда я в дополнение к стандартному списку скиллов пишу, что самостоятельно с нуля написал клиент-серверный проект на 30,000 строк кода на C# с использованием MS SQL Server.
(Так то я писал и на 300 тыс. строк, но когда ставишь всего 2-3 года опыта, надо соблюдать адекватность :)

За полдня получил пять офферов. причём один был такой добрый и вкусный, что мне прям жалко было отказываться ))))

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

Техдира/тимлида впечатлит именно ваш не очень удачный опыт (кто говорит, что всё было хорошо, врут 98%) + объём кода: раз вы более-менее успешно нафигачили десятки тысяч строк, значит точно сможете нормально долгосрочно трудиться.
Но 3-5 тысяч строк будет маловато.

Есть и другой лайфхак: для курсантов я выложил материал "9 крутых и необычных сайд-проектов", после которых рекрутеры будут ползать за вами на коленочках :) Они по объёму меньше, но зато впечатлительны в плане сложности. Например, написать свою среду запуска контейнера (container runtime).

Лучше всего, конечно, сделать и то, и то.

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

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

При работе с хорошим кодом думать почти не нужно.

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

Традиционная разработка бэкенда по сути своей ориентирована на серверы: мы мыслим в парадигме серверов.

Однако по мере распространения безсерверных систем нам необходимо учиться мыслить в терминах воркеров.

Мой курс "Ясная архитектура" в помощь.

В Java реализована динамическая диспетчеризация, которая "сама" решает непосредственно во время выполнения программы, какую реализацию метода запускать. Узнать это с помощью статической типизации невозможно.

В чистых функциональных языках вместо интерфейсов предлагается концепция тайп-классов, рассказывал:
Тайп-классы и алгебраические структуры
Тайп-классы

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

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

Да, но как тогда мы можем рассуждать о коде в Java на третьем логическом уровне, если не знаем точно, какой код будет выполняться? На помощь приходит принцип подстановки Лисков (точнее, его идеология). Подробнее эту тему разбираю для курсантов в материале "LSP с т.зр. ФП".

Вкратце, абстракция LSP гласит: разработчик! не удивляй своих коллег! )))

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

Кстати да

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

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

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

90% правильного программирования -- это молчаливое думание.