Mikhail Kashkin

8 лет назад я решил написать учебник по языку программирования Python для полных новичков с нуля. Спустя пару месяцев работы над текстом, я понял, что текста будет не достаточно, а еще надо разобраться как работает мозг при изучении новых вещей. Это запустило невероятно большую цепь событий. Благодаря @kukutz меня пригласили в Яндекс.Практикум и я поучаствовал в создании курса Бэкенд разработки на Python'е который на сегодняшний день прошло больше 10 тысяч студентов. Но мне и этого было мало. Я хотел сделать курс лучше чем команда профессионалов в самом Яндексе. И больше 4х лет я занимался созданием своего собственного учебного курса. Изучал когнитивистику, методолгию, много новых технологий необходимых для создания проекта. Создал свою собственную платформу, строил маркетинг, а когда появились студенты то обучал и делал практику. Прошло время, я изменился и изменился мир. Я оказался не самым талантливым продажником, мне всегда было интереснее создавать и в этом мое благословление и проклятие. Я решил, что лучшее, что я могу сделать — это открыть и отдать учебный курс в открытый мир и посмотреть что произойдет. Поэтому я собрал все материалы создал новый сайт для контента курса, а видео перенес на Youtube. Когда мы анализировали рынок, то оказалось, что мой курс по объему относится к нише учебных проектов стоимостью от 2700 до 4500. Мы анализировали предложения от всех крупных школ представленных на рынке. Да у конкурентов в пакет входит предложение проверки кода, поддержки, мотивации и унижения учеников. Эти обязательства я на себя не беру. Но в остальном я выкладываю свой курс в открытом виде и бесплатно. Вы можете зайти на сайт pylot.me/ и начать двигаться ступень за ступенью. Когда-то я вышел один в поле боя с горячим желанием поменять этот рынок. Но компании с большими бюджетами меня победили. Пусть так, но сейчас я открываю всем свой проект. Вам больше не надо брать кредит на обучение, не надо занимать у родителей и друзей. Теперь вы только наедине с собой и своей дисциплиной. Если вы пройдете этот путь, то сможете выучить прекрасный язык Python и научиться всей небходимой базе. Что я хочу взамен? Мне кажется мир станет немного лучше если у вас будет такая возможность. Я не знаю куда заведет меня этот путь. Подозреваю, что может быть это будет просто классное путешествие. Надеюсь мы все вместе станем лучше в процессе. Пожалуйста поставьте лайк и если можете, то сделайте репост.

Это знакомое с детства простонародное invocationtargetexception

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

Всего 28 тысяч раз за последние 90 дней.

Дарью начали кошмарить, но, судя по выступлению, она не выбирает линейный персонал. А ее работа в поиске топов. У вас есть позиция, от которой зависит благосостояние ~100000 семей (приблизительное количество сотрудников группы по инфе из гугла). И вам надо выбрать принять решение кого брать на эту позицию. Ваш алгоритм? Для линейного персонала нужно выполнять четкие простые требования. Там легко принимать решения на основе простых требований. Для C-Level даже в простом бизнесе уже нет формальных требований. В чеклисте проверить, что человек имеет руки и жопу и линеечкой проверить расстояние между ними не срабатывает. И все правильно, на высоком уровне людей ищут по интуиции. По запаху, если хотите. Не оправдываю, Яндекс удивительно низкоэмпатичная компания, это правда. Но она успешная и активно движется к своей цели. И как организм опережает рынок.

Есть несколько мифических блуждающих багов в истории контупер сайнс. Которые так или иначе проявляются спустя годы. Первый — это попытка найти негра на фотографии. Начиная с фотоаппаратов, которые не фокусировались, и продолжая определять как животных с постоянной частотой. Попытка решить эту проблему привела к тому, что ИИ уже с трудом понимают, что есть люди других рас. Но она еще обязательно вылезет. Вторая — это взлом компьютера с помощью кота, который уснул на клавиатуре. Сейчас опять вылезла эта проблема, если во время ввода пароля кот ляжет на клавиатуру и введет больше 256 символов, то он может взломать ваш сервер Вот очередная инкарнация sshhole.com/

SEO-шники провели исследования и оказалось, что llms.txt на сайте никто не читает. Даже GPTBot, ClaudeBot и похожие. Плюс сайты которые написаны на JavaScript (SPA) индексируются ИИ-ботами хуже. Еще была шиза в том, чтобы ботам отдавать сайты в Markdown формате. Это совершенно бесполезно, потому, что боты в таком формате не запрашивают, увеличивает бюджеты и еще большой шанс получить рассинхрон по контенту, если ваши разработчики буратины. Современные рекомендации оптимизации для ИИ ботов выглядят так: - Не добавлять markdown - Хороший HTML, который рендерится на сервере - llms.txt не нужен - Сделайте читаемый сайт Что полностью совпадает с рекомендациями 2006 года. Cloudflare пытается протолкнуть isitagentready.com, так вот с практической точки зрения все эти рекомендации просто трата времени и не дают реального результата который можно замерить в логах, показах и, в конечном итоге, видимости в результатах агентов.

1.1 миллиона людей смотрят на очереди

Буквально мой день

Мы, видимо, по-разному работаем с проектами. Один из моих примеров, почему мне приходится создавать monohero. Сейчас у меня в фоне работает сессия, которая пишет порядка 200 адаптеров. Каждый из адаптеров это длинный процесс: декомпиляция, реверсинжиниринг, извлечение схемы API, сравнение версий API при выходе нового приложения, в этом случае выпуск новых версий адаптера, при этом еще бывает запуск целевого приложения в специальном эмуляторе для проверки работы и сравнения оттиска клиентов, MITM прокси для перехвата трафика. И как результат получается код на python, который позволяет эмулировать взаимодействие с целевым провайдером по множеству разных протоколов. Реализация и работа с этими адаптерами это одна /goal команда. Которая по мере готовности новых адаптеров вливает в мастер проекта новые куски кода. Которые оркестрируются через планировщик, попадают на дашборды, в базу и т.д. И эта цель работает дни. Иногда ускоряется, иногда может зарываться и делать тяжелые разборы. И если она прямо активно двигается, то частый мердж/ревью цикл может забить все оставшиеся ресурсы на машине. Поэтому мне требуется более сложный инструментарий вместо скиллов. Вообще хочется честно поговорить по поводу скиллов. Пусть это будет звучать цинично, но если я с кем-то обсуждаю какую-то задачу и слышу, что она решается скиллами, то я понимаю, что мы вообще находимся в разных временных рядах. У меня вообще нет скиллов. Скиллы, как и mcp — это brainslug антипаттерн. Мне видится это как практика и прослойка для непритязательных новичков. Более того, сколько бы я ни читал примеры скиллов онлайн, особенно которые рекламируют какие-то инфлюенсеры, я не вижу в них ничего ценного. Скиллы это самый примитивный способ работы с агентами. Вам в реальности не нужно ни одного скилла. У меня есть один для постановки описания задачи, но только потому, что скилл базовичок из коробки хороводинга не может быть сложным. Даже все стандартные review скиллы уже достаточно хороши, чтобы не задумываться о том, чтобы тут что-то улучшать. Но зато я могу совершенно спокойно готовое удачное решение использовать повторно, даже в другом проекте. Например, если я попрошу в каком-то чате между делом настроить новый сервер, то хороводинг настроит firewall, sshd, unattended-upgrades, создаст стандартного пользователя, под которым происходит деплой, и даст ему права на директорию для выкладки приложений без моего напоминания. У меня нет лишних бюджетов на токены и я не могу оказываться в ситуации, когда после одного запроса тратится 70% лимита. Более того, собирая обратную связь от коллег, появляется наблюдение, что программист, который скажет, что у него "80 скиллов, которые решают все проблемы", с большой вероятностью не пройдет на своем окружении кодовый этап собеседования. Пока не готов это утверждать, но статистика набирается именно такая. В общем делюсь своим мнением.

Проекты растут, полные проверки становятся тяжелее. Рост продуктивности при работе с ИИ привел к тому, что в параллели работает несколько агентов каждый в своем worktree: исправляет код, добавляет/меняет что-то, пишет тесты. Пока задачи независимы, всё хорошо. Но узкое место возникает тогда, когда надо влить изменения в основную ветку. С объединением изменений возникает ещё один круг: одна ветка попадает в master, остальным нужно обновиться и снова пройти проверки. Пока они проверяются, вливается следующая ветка — и часть работы приходится повторять. Добавьте сюда постоянные проверки статуса и переговоры между агентами: на координацию уходят и время, и токены. Меня это начало тормозить. Поэтому для локальной работы я сделал Monohero — небольшую локальную очередь для таких процессов. Агенты вместо того, чтобы все запускать параллельно, занимают место в очереди и останавливают свою работу. После того как шаг требующий ресурсов полностью исполнен monohero вызывает следующего агента, чтобы он выполнил свою узкую задачу. Остальные замирают и ждут своего места. Для каждого проекта можно завести отдельную очередь, если вы работаете в параллели с несколькими проектами и в разных worktree. Monohero не отменяет проверки, гардрейлы или хуки. Он просто упорядочивает локально использование ресурсов. Написал его на Rust — хотелось немного поэкспериментировать с языком, тем более что становится прохладно и в чулках теплее. Забрать можно туц github.com/xen/monohero

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

Офигеть! Оказывается на otkuda.com появился первый пост от пользователя и первые комментарии! Праздную новый этап.

Предположу, что это такой ответный твит на мой пост про тестировщиков. Но доказать не могу. Для неспециалистов надо объяснить в чем сыр-бор с тестированием в процессе разработки. Раньше стоимость рабочего часа оказывала давление на процесс. У вас был коллектив каждый час которого стоит как чугунный мост, а в месяц спокойно влетает в стоимость новой квартиры. И поэтому была задача создавать специализацию и экономить. Час работы программиста стоил дорого, значит можем ли мы отобрать у него часть функций и перенести на более эффективных или более дешевых специалистов. Кроме того, множество классических исследований показывали, что чем ближе к разработке исправляется ошибка, тем дешевле она обходится. Представьте, что вы запустили в космос спутник, а в нем из-за ошибки ПО не фотографирует фотоаппарат. А значит вообще хотелось бы выделить человека, задача которого следить за качеством. Ну чтобы не приходилось в ночь с пятницы на субботу надевать скафандр и лететь на орбиту Марса фиксить прошивку. Получалась такая сложная многомерная матрица: - написать руками дополнительный код дорого - исправлять ошибку на стороне клиента дорого - просить программистов выделять отдельно время на чтение второй-третий раз документацию дорого - и т.д. И появилась хорошая идея брать на работу специалистов, которые потратили на обучение не 5–10 лет, а прошли курсы тестировщиков. Может, они и не супер глубоко разбираются, но такая работа давала хорошие результаты, причем почти сразу. И вот вмешался ИИ. Стоимость написания строки кода упала драматически. Более того, тесты покрытия в основном — это очень однообразный и не творческий код. Нет вы, конечно, можете пытаться самореализовываться, но экономическая целесообразность творческих потуг тут не высокая. Для программиста такие тесты работают очень просто: берется каждый обособленный участок кода и проверяется, что он ведет себя предсказуемо. Покрывается весь код и когда вносятся изменения, то проверяется, что код не упал. Дорого обходились еще и интеграционные тесты, когда у вас есть разный код, зачастую разные продуктые которые разрабатывались разными командами и которому надо обеспечить непрерывность выполнения требований. Сейчас и эту задачу ИИ хорошо выполняет. Проверить, что код должен соответствовать требованиям? Подержите мое пиво, загружаешь подписанный договор с приложениями и через часок у тебя список согласования, в котором перечислены пункты договора и ссылки на исходники, в которых эти пункты не выполняются. Ну и последний пункт. Дистрибьюция ПО очень сильно поменялась. Раньше, чтобы исправить ошибку, вам надо было о ней узнать, продиагностировать, создать условия ее возникновения и тогда уже исправить. За последние лет 10 в этой части возникло невероятное количество инноваций: мониторинг, телеметрия, обзервабилити, вам эти слова что-нибудь говорят? Даже просто доставка приложений сильно упростилась. Сейчас для того, чтобы исправить ошибку в проде, вам в большинстве случаев вообще ничего не надо делать. Ну кроме начальной настройки инструментов, которые тоже настраиваются с помощью агентов. Можно говорить о том, что контроль качества формируется в фазе улучшения сбора требований. Но и тут большое поле для автоматизации. Показательный пример. Мне понадобилось найти оптимальную стратегию конфигурирования сложного продукта, который может запускаться на разном железе, но на конкретном должен работать оптимально. Я выделил доступы к ~десятку разных серверов, обсудил варианты того, что можно менять. Получилось что-то типа X^n возможных вариантов. Руками их перебирать было бы сложно. Ставишь задачу хороводингу агентов запустить множество каскадов тестов, чтобы определить, на каком железе какие варианты работают лучше. В результате получено множество графиков, точек отказа, сырых данных конфигурации. Такого качественного сбора информации у меня в жизни не было. А заняло времени меньше, чем если бы я сидел и формулировал аналитику. Я не говорю, что люди, которые были тестировщиками, никому больше не нужны. Если вы прочитали это так, то вопросы к вам. Я говорю, что набор функциональных обязанностей к тестировщикам буквально рассыпался в воздухе как песок через пальцы. Люди нужны, но они будут делать что-то новое и другое.

Запросил цены на ИИ сервера. Прислали цену 1.8–1.9 миллиона долларов. Но есть нюансы: - по одной штуке их не продают, от 50 - продадут только если у меня есть достаточные мощности по электричеству и отводу тепла, а потребление как у завода - предоплата 100%, не факт, что я даже встречусь с этими людьми - цена на сегодня, через месяц это будет 2.2–2.3 миллиона долларов, потому что за всеми доступными серверами очередь - не все карточки такой ценовой категории подходят для обучения моделей, некоторые хороши в инференсе, то есть даже такого уровня железки не закроют все задачи Классная получается история, на сервера надо 100 лямов вперед людям, которых ты не знаешь и даже скорее всего не увидишь. Но, чтобы их воткнуть, надо выстроить здание, желательно рядом с электростанцией. Ну как эклектростанцией. Тоже не каждая подойдет. Например, в этом году Дунай обмелел и атомные станции выключали, потому, что не хватало воды их охлаждать (АЭС Чернаводэ, АЭС Пакш, АЭС Козлодуй). Производитель серверов можно и послать нафиг. Помимо самой ветки электричества нужна уже своя трансформаторная подстанция. Помещение с кучей требований и т.д. В общем датацентр. Конечно, в розницу тоже можно покупать. Но даже на оптовом уровне очереди стоят и выкупают за такую цену.

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

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

Пытаюсь сделать ров. Я выложил демку otkuda.com и на сайте добавил информацию о товарах. Мне пришли люди и написали, что эта инфа есть в numbeo. Это немного разные проекты, но обратная связь это обратная связь. Именно ради нее и спрашивал. Это натолкнуло на мысль. А что, если сделать инструмент, который будет собирать полную базу продуктов для локальных онлайн ритейлеров. В чем же ров? Ну во-первых, сайты у всех разные, для каждого нужен свой адаптер. Во-вторых, сайты парсить сложно. Более стабильно собирать информацию через API, но нет никаких причин выкладывать API публично. Кроме одного особого места. Мобильное приложение работает с бэком через API. Поэтому я сделал форк эмулятора приложений для Андроида, который перехватывает сетевой трафик и позволяет документировать работу с API и на основе этого делать собирать информацию для реверс инжиниринга API. Чтобы делать экспорт продуктовых каталогов онлайн сторов. Пока не знаю, куда меня это выведет. Более того я не знаю, насколько это реалистичный план сам по себе. Но раз мы живем в безумном мире, то давайте посмотрим насколько можно быть более безумным чем окружающая реальность.

По чатикам выложили ссылки на приложение для обучения болгарского с нуля. Подобрали самое подходящее имя на букву М. Жаль нет других кириллических имен для примера на букву М.