Лично-профессиональный канал
Я долго прикидывал, насколько мне всё это вообще надо.
Канал, да ещё и профессиональный, да ещё и с которого происходят попытки авторитетно вещать - есть у каждого третьего-встречного-поперечного.
При этом контент такого уровня, что не пролистываю и слежу с интересом у ~4/30 техноканалов из всех подписанных
Одна мысль о вливании в подобную суету вызывает приступы тлетворности бытия. Но и несколько любопытных гипотез напопробовать призывает тоже
Как я представляю себе контент?
- Относительная краткость 70% контента, 3-7 абзацев без растекания мыслью по теме.
- Содержит некоторую техническую ценность, связанную с моей профессиональной деятельностью
- Неструктурированные заметки, кодсемплы, скрины
- Дозволительно иметь явный эмоциональный окрас/личностную субъективную оценку, куски поверхностных и поспешных суждений в моменте
- Часть контента может быть самозабвенно стянута извне и вольно интерпретирована
Я долго прикидывал, насколько мне всё это вообще надо.
Канал, да ещё и профессиональный, да ещё и с которого происходят попытки авторитетно вещать - есть у каждого третьего-встречного-поперечного.
При этом контент такого уровня, что не пролистываю и слежу с интересом у ~4/30 техноканалов из всех подписанных
Одна мысль о вливании в подобную суету вызывает приступы тлетворности бытия. Но и несколько любопытных гипотез напопробовать призывает тоже
Как я представляю себе контент?
- Относительная краткость 70% контента, 3-7 абзацев без растекания мыслью по теме.
- Содержит некоторую техническую ценность, связанную с моей профессиональной деятельностью
- Неструктурированные заметки, кодсемплы, скрины
- Дозволительно иметь явный эмоциональный окрас/личностную субъективную оценку, куски поверхностных и поспешных суждений в моменте
- Часть контента может быть самозабвенно стянута извне и вольно интерпретирована
Существенное о себе
Активно практикующий, почти не выгорающий широкопрофильный специалист
Успел поработать в крайне разных по зрелости процессов, скорости разработки и опыту людей командах. От минихалтурок до вполне себе масштабных систем. Разве что до MANGA пока не добрался
Что-то успел позапускать прям со старта, прям с нуля. Часть оного до сих пор умудряется работать
На текущем этапе карьеры выполняю спектр работ между техническим архитектором тимлидом и python backend.
И на этом поле ещё существенно стоит подрасти
Подход к работе в двух словах: "Было бы хорошо - меня бы не позвали"
Чем занимался и что умею:
Robotics - Еще в студенческие времена потрогал роботов за манипуляторы.
Знал что-то про кинематику и еë задачи. Немного задротил графы и алгоритмы.
Python backend - практически основное и регулярное моё занятие во всех его проявлениях
Покатался Django->aiohttp->fastapi
Computer Vision - писал аналитику под данные с радаров, лидаров, стерео камер, веб-камер, специализированных CV камер.
Самое сложное и наукозависимое чем я занимался ever - как раз было из этой области.
Как запихнуть целый каскад разнообразной аналитики в небольшую автономную камеру.
Как связать 8 таких камер в единую систему и не поехать крышей
Боты/парсеры - писал маленьких, писал больших и нагруженных, владею хорошим арсеналом способов не палиться (что ты бот) в интернетах. Вряд ли сейчас этим кого-то удивишь. Много работал с платформой telegram
GenAI/LLM - побывал СТО исследовательской лаборатории, Активно ресёрчил и проводил кучу экспериментов с LLM, их бенчмаркингом, поведением в условиях ограниченного контекста. Собрал и довёл до релиза полноценный RAG.
Технологии поиска/биометрии - что-то знаю про поисковые системы, алгоритмы поиска и индексации на больших объемах данных
Возможно причастен к созданию некоторых СКУД(не государственных)
Текущая занятость:
TeamLead, full time. Команда 8 человек. + sides
Проект: система интерактивного голосового общения/опроса абонентов под крайне разные языки, Voice/VoIP/GenAI технологии
Сферы интересов:
- Python и вся его экосистема
- Web, backend и сопутствующие технологии
- GenAI, LLM, agents
- Собесы/техскрининг, и как проводить их так, чтобы после никому не было слишком стыдно или слишком больно
- Организация рабочего контекста и его паттерны
Активно практикующий, почти не выгорающий широкопрофильный специалист
Успел поработать в крайне разных по зрелости процессов, скорости разработки и опыту людей командах. От минихалтурок до вполне себе масштабных систем. Разве что до MANGA пока не добрался
Что-то успел позапускать прям со старта, прям с нуля. Часть оного до сих пор умудряется работать
На текущем этапе карьеры выполняю спектр работ между техническим архитектором тимлидом и python backend.
И на этом поле ещё существенно стоит подрасти
Подход к работе в двух словах: "Было бы хорошо - меня бы не позвали"
Чем занимался и что умею:
Robotics - Еще в студенческие времена потрогал роботов за манипуляторы.
Знал что-то про кинематику и еë задачи. Немного задротил графы и алгоритмы.
Python backend - практически основное и регулярное моё занятие во всех его проявлениях
Покатался Django->aiohttp->fastapi
Computer Vision - писал аналитику под данные с радаров, лидаров, стерео камер, веб-камер, специализированных CV камер.
Как запихнуть целый каскад разнообразной аналитики в небольшую автономную камеру.
Как связать 8 таких камер в единую систему и не поехать крышей
Боты/парсеры - писал маленьких, писал больших и нагруженных, владею хорошим арсеналом способов не палиться (что ты бот) в интернетах. Вряд ли сейчас этим кого-то удивишь. Много работал с платформой telegram
GenAI/LLM - побывал СТО исследовательской лаборатории, Активно ресёрчил и проводил кучу экспериментов с LLM, их бенчмаркингом, поведением в условиях ограниченного контекста. Собрал и довёл до релиза полноценный RAG.
Технологии поиска/биометрии - что-то знаю про поисковые системы, алгоритмы поиска и индексации на больших объемах данных
Возможно причастен к созданию некоторых СКУД(не государственных)
Текущая занятость:
TeamLead, full time. Команда 8 человек. + sides
Проект: система интерактивного голосового общения/опроса абонентов под крайне разные языки, Voice/VoIP/GenAI технологии
Сферы интересов:
- Python и вся его экосистема
- Web, backend и сопутствующие технологии
- GenAI, LLM, agents
- Собесы/техскрининг, и как проводить их так, чтобы после никому не было слишком стыдно или слишком больно
- Организация рабочего контекста и его паттерны
❤1👍1🍌1
заметки, кейсы, Личные Базы Знаний и что с ними не так
Я какое-то время думал/пробовал профессиональные заметки вести. Всё упёрлось что в нужное время их фиг достанешь - даже свои для себя -и надо либо очень тщательно оформлять в конкретные (оптимизированные под дальнейший поиск, извлечение данных) кейсы с кучей сопровождающего кода и комментов, либо оставлять в формате минидока-кодекса со ссылками + оглавлением, к которым вернёшься практически никогда.
Слабоструктурированный текст, даже с гиперразметкой и найти невозможно и польза с течением времени стремится к нулю
так и забил пытаться что-то полезное в формат ЛБЗ преобразовать.
Тут есть ещё идеологические вопросы - для себя поддерживать ЛБЗ как будто бы зачастую и не всралось, не хватает дисциплины. Вся инфа или уже у тебя в голове или устарело или рольнёт только через полгода.
Шитпостить в канал как-то благодарнее получается
Я какое-то время думал/пробовал профессиональные заметки вести. Всё упёрлось что в нужное время их фиг достанешь - даже свои для себя -и надо либо очень тщательно оформлять в конкретные (оптимизированные под дальнейший поиск, извлечение данных) кейсы с кучей сопровождающего кода и комментов, либо оставлять в формате минидока-кодекса со ссылками + оглавлением, к которым вернёшься практически никогда.
Слабоструктурированный текст, даже с гиперразметкой и найти невозможно и польза с течением времени стремится к нулю
так и забил пытаться что-то полезное в формат ЛБЗ преобразовать.
Тут есть ещё идеологические вопросы - для себя поддерживать ЛБЗ как будто бы зачастую и не всралось, не хватает дисциплины. Вся инфа или уже у тебя в голове или устарело или рольнёт только через полгода.
Шитпостить в канал как-то благодарнее получается
👍1
Ну, почти всё как у людей.
Разрабатывали сервис выгрузки эвентов под кафку, а потом выяснилось, что эвент не эвент, в кафку нам нельзя, документации под неё не будет. Надо что-то более классическое
Разрабатывали сервис выгрузки эвентов под кафку, а потом выяснилось, что эвент не эвент, в кафку нам нельзя, документации под неё не будет. Надо что-то более классическое
🤯3😁1
Стремящийся к идеальному интерфейс
Немного идеологии к которой я хочу апеллировать в дальнейшем.
Итак, я один, а технологий в этом мире много. Частью моей работы должно являться расширение технического кругозора, выражающееся в трогании всего нового и слежении за апдейтами старого. К сожалению, работу мечты, где я мог бы делать это на фултайм без отвлечений, я пока не нашёл, а значит возможности на этом поле мои ограничены. Да и в целом такая активность идёт чаще всего бонусом от избытка времени и сил.
Если сузить: Оценивая что-то свеженькое и достаточно сырое, как прикинуть потенциал?
Кратко вывел для себя
0) насколько это тебя возбуждает
1 )Насколько предложенная технологией идея/интерфейс решает существующую проблему/облегчает жизнь.
2) Насколько интуитивно она это делает. Если начать ей пользоваться - будет оно ощущаться на кончиках пальцев или скорее как успех вопреки.
3) Насколько стабильно она развивается, есть ли шанс дойти до сколько-то зрелого состояния в обозримые сроки?
Немного идеологии к которой я хочу апеллировать в дальнейшем.
Итак, я один, а технологий в этом мире много. Частью моей работы должно являться расширение технического кругозора, выражающееся в трогании всего нового и слежении за апдейтами старого. К сожалению, работу мечты, где я мог бы делать это на фултайм без отвлечений, я пока не нашёл, а значит возможности на этом поле мои ограничены. Да и в целом такая активность идёт чаще всего бонусом от избытка времени и сил.
Если сузить: Оценивая что-то свеженькое и достаточно сырое, как прикинуть потенциал?
Кратко вывел для себя
1 )Насколько предложенная технологией идея/интерфейс решает существующую проблему/облегчает жизнь.
2) Насколько интуитивно она это делает. Если начать ей пользоваться - будет оно ощущаться на кончиках пальцев или скорее как успех вопреки.
3) Насколько стабильно она развивается, есть ли шанс дойти до сколько-то зрелого состояния в обозримые сроки?
👍1👏1
VectorDB и актуальность третьего пункта предыдущего поста
Для иллюстрации - один несуразный кейс из личного опыта
В запрошлогодние времена было очень модно собирать RAG, чьим необходимым компонентом являлась векторная БД. Путём некоторого сёрча было решено выбратьFAISS+MongoDB между ChromaDB и Milvus. Хрома в тот момент была совсем свеженькой вундервафлиной с понятным интерфейсом и юзкейсами, ну и в целом хорошим быстродействием при своей простоте. И эмбеддер ещё кастомный можно было легко запихнуть.
Меня особенно привлекла роадмапа и обсуждение на gh, где активно стояла повестка добавления BM25 -> FTS и Hybrid search. Из всего этого мне вырисовывалась интересная идея легковесного тулза, заточенного под нужды нарастающего тренда GenAI/агентных систем. А такое надо бы пробовать и брать на вооружение
Именно этот RAG-проект из чего-то экспериментального решил вырасти до более солидных размеров, а chroma так и оставалась основной векторной БД. Надо отдать должное, вытягивала нагрузку.
Но мои ожидания, как водится, остались только моими. Команда сфокусировалась на создании managed инфры, что, имхо, видится немного странным решением при присутствии гораздо более развитых в т.ч. технологически систем с внушительной базой комьюнити.
И всё. Это не история пожара или какого-то былинного проёба.
При этом смысла выбирать/оставаться именно Chroma на перспективу - принимать риски использования ранних версий и возможного свитча в будущем - не оказалось.
Для иллюстрации - один несуразный кейс из личного опыта
В запрошлогодние времена было очень модно собирать RAG, чьим необходимым компонентом являлась векторная БД. Путём некоторого сёрча было решено выбрать
Меня особенно привлекла роадмапа и обсуждение на gh, где активно стояла повестка добавления BM25 -> FTS и Hybrid search. Из всего этого мне вырисовывалась интересная идея легковесного тулза, заточенного под нужды нарастающего тренда GenAI/агентных систем. А такое надо бы пробовать и брать на вооружение
Именно этот RAG-проект из чего-то экспериментального решил вырасти до более солидных размеров, а chroma так и оставалась основной векторной БД. Надо отдать должное, вытягивала нагрузку.
Но мои ожидания, как водится, остались только моими. Команда сфокусировалась на создании managed инфры, что, имхо, видится немного странным решением при присутствии гораздо более развитых в т.ч. технологически систем с внушительной базой комьюнити.
И всё. Это не история пожара или какого-то былинного проёба.
При этом смысла выбирать/оставаться именно Chroma на перспективу - принимать риски использования ранних версий и возможного свитча в будущем - не оказалось.
🥰1
Страх и ненависть в Cursor
Тренды идут, а я не в трендах. Да и кодинг навыки в бытность мою лидом начали практиковаться значительно меньше 4-6 часов в день, необходимых для поддержания формы.
Потому, вдохновлённый опытом Валеры, моего любимого соратника-затейника, я самоорганизовался в недельный хак-интенсив безудержного AI кодинга.
Центральная идея
Глобально - Возможно ли за счёт скорости и экспертизы AI написать качественный код в сроки демки?
Если так, AI кодинг при должных навыках способен открыть прямой и быстрый прыжок от демо-прототипа к MVP.
Почему это важно:
Сейчас демки собираются либо на коленке, либо на морально волевых. И потом, как правило, переписывается под 0, часто уже другой командой, ибо говнокод, противно и нерасширябельно.
MVP - уже достаточно развитая система с проработанным и зафиксированным наборов бизнес-фичей, пригодная для стабильного запуска на малой аудитории, достаточно качественная и корректно организованная технически для комфортной итерационной разработки/развития в будущем.
С чем стартовал:
Ящик энергетосов и репо мне на растерзание. Как здесь, только страшнее, с повышенным содержанием сенситивных данных, хардкода ссылок и невменяемого .env. Это результат ~30 часов ИИ кодинга специалиста, не занимающегося промышленным программированием. Буду далее называть его легаси кодбазой.
Здравый смысл и начавший подёргиваться глаз подсказывали не ввязываться с этим кодом.
Тем не менее, это был вполне рабочий(!) проект, демонстрирующий все основные интересные мне сценарии. Некоторая исследовательская жилка ИИ артефактов всё-таки взыграла.
Да и потом, откуда ещё получить и поделиться бесценным опытом. Насколько бесценным? БД проекта выглядела вот так.
Не знаю как у вас, а у меня сразу вызывает желаниежить замерить, насколько сложнее/дольше будет отстроиться от этого чем писать нуля.
Задачи интенсива
- Разработать систему транскрибации, как можно ближе сходящуюся к уровню MVP по зрелости и качеству кода и технической архитектуры.
Небходимые целевые фичи:
* Гугл авторизация
* Получение транскрипта файла (в базу взяли WhisperX)
* Получение разбиения по спикерам (pyannote)
* Аналитический отчёт по содержанию файла ( LLM + proдуманный prompt)
* Запись встреч (ввиду сжатых сроков пришли к идее google extension - запись вкладка+микро, что мне кажется гениальным в своей универсальности)
* Развёртывание на сервере, Docker базовая инфра
- Посчитать выигрыш в своей скорости относительно плана реализации вручную.
- Выявить для себя правила оптимального использования ИИ
- Разобрать кейс доработки "легаси" кодбазы.
Как оно было
С чем столкнулся, к чему пришёл, что посчитал и как оно в итоге - будет дальше.
Тренды идут, а я не в трендах. Да и кодинг навыки в бытность мою лидом начали практиковаться значительно меньше 4-6 часов в день, необходимых для поддержания формы.
Потому, вдохновлённый опытом Валеры, моего любимого соратника-затейника, я самоорганизовался в недельный хак-интенсив безудержного AI кодинга.
Центральная идея
Глобально - Возможно ли за счёт скорости и экспертизы AI написать качественный код в сроки демки?
Если так, AI кодинг при должных навыках способен открыть прямой и быстрый прыжок от демо-прототипа к MVP.
Сейчас демки собираются либо на коленке, либо на морально волевых. И потом, как правило, переписывается под 0, часто уже другой командой, ибо говнокод, противно и нерасширябельно.
MVP - уже достаточно развитая система с проработанным и зафиксированным наборов бизнес-фичей, пригодная для стабильного запуска на малой аудитории, достаточно качественная и корректно организованная технически для комфортной итерационной разработки/развития в будущем.
С чем стартовал:
Ящик энергетосов и репо мне на растерзание. Как здесь, только страшнее, с повышенным содержанием сенситивных данных, хардкода ссылок и невменяемого .env. Это результат ~30 часов ИИ кодинга специалиста, не занимающегося промышленным программированием. Буду далее называть его легаси кодбазой.
Здравый смысл и начавший подёргиваться глаз подсказывали не ввязываться с этим кодом.
Тем не менее, это был вполне рабочий(!) проект, демонстрирующий все основные интересные мне сценарии. Некоторая исследовательская жилка ИИ артефактов всё-таки взыграла.
Да и потом, откуда ещё получить и поделиться бесценным опытом. Насколько бесценным? БД проекта выглядела вот так.
class DatabaseService:
"""Сервис для работы с JSON базой данных"""
def __init__(self):
self.lock = threading.Lock()
def load_database(self) -> Dict:
"""Загрузка базы данных из JSON файла"""
with self.lock:
if DATABASE_FILE.exists():
try:
with open(DATABASE_FILE, 'r', encoding='utf-8') as f:
data = json.load(f)
# Обеспечиваем структуру базы данных
if 'transcriptions' not in data:
data['transcriptions'] = {}
if 'users' not in data:
data['users'] = {}
if 'sessions' not in data:
data['sessions'] = {}
return data
Не знаю как у вас, а у меня сразу вызывает желание
Задачи интенсива
- Разработать систему транскрибации, как можно ближе сходящуюся к уровню MVP по зрелости и качеству кода и технической архитектуры.
Небходимые целевые фичи:
* Гугл авторизация
* Получение транскрипта файла (в базу взяли WhisperX)
* Получение разбиения по спикерам (pyannote)
* Аналитический отчёт по содержанию файла ( LLM + proдуманный prompt)
* Запись встреч (ввиду сжатых сроков пришли к идее google extension - запись вкладка+микро, что мне кажется гениальным в своей универсальности)
* Развёртывание на сервере, Docker базовая инфра
- Посчитать выигрыш в своей скорости относительно плана реализации вручную.
- Выявить для себя правила оптимального использования ИИ
- Разобрать кейс доработки "легаси" кодбазы.
Как оно было
С чем столкнулся, к чему пришёл, что посчитал и как оно в итоге - будет дальше.
🔥20❤4
Начало
Продолжу описывать процесс работы длиной в (предыдущую) неделю,мысли подходы в формате:
* Затраченное время
* Какие изменения вносил
* Какие выводы сделаны/инсайты получены
пнд-втр, 10+14=24ч.
- Загружен проект, проведена первичная оценка имеющейся кодбазы. У меня есть целый гуглдокумент на 9 страниц с говной, где я выписывал как на ревью все проблемы исходника.
Мы хотели во имя науки скормить его в таком виде ИИ чтоб он составил себе подробное ТЗ и по нему прошёлся, закрыв дыры
Эксперимент признан неудачным
Сводка самых критичных моментов:
- отсутствие БД(!), консистентного хранилища состояния.
- Фронт на сырых HTML шаблонах
- ЯндексS3 как единственное хранилище файлов (я не планировал использовать внешнее S3)
- Также наблюдалось огромное количество дыр в безопасности и производительности: по моим подсчётам, оно не должно было вытягивать больше 2-3 человек одновременно
- Модели кэшировались очень частично и вызывали зависания на несколько минут из-за подгрузки гигабайтов весов каждый первый запуск
- В некоторых кейсах происходили очень неявные критические баги. К примеру, если первая задача в систему не была с флагом на разделение спикеров, то ни одна последующая эту функцию запустить уже не сможет
Я очень недооценил на старте сырость исходника.
Вместе с тем, и это очень важно, Оно работало! Легаси кодбаза уже выступала в роли технического концепта желаемого функционала, а значит все ответы и фичи, хоть и реализованные криво уже были в ней, и моей задачей стал перепил структуры и организации кодбазы
Инсайты
- Я долго пытался понять, с какого бока приступить, это было очень сложной задачей - найти точку входа для изменений на легаси в 2-3к строк. Начал с фронта, философски отнесясь к бэкенду как к чёрной коробке с публичным контрактом, и потом уже переходить к бэку
- Фронт перепилился в TS+Vite приложение на удивление спокойно. Я, как совсем не фронтендер, не догадываюсь, какие ужасы там творились. Оно и к лучшему.
Самый важный инсайт - если позаботиться о хороших подробных описаниях-промптах и приложить референсы - ИИ может осилить даже объёмные структурные изменения.
- Хорошо показал себя метод, где сначала ИИ переписывает всё в один более большой файл и потом уже разбивает на несколько маленьких отдельной цепочкой рефакторинг промпт-задач
- Бэк представлял собой зрелище, не самое страшное в моей практике, но опасное ввиду неявно заложеннных бомб
ИИ плохо справляется с уменьшением сложности/вложенности кода и не всегда понимает проблему асинхронности, организации IO/Heavy задач.
Фокус на локальном решении текущей мелкой проблемы осложняет использование общих абстракций, моделей. Это должно фокусироваться отдельно через Rules, промпты.
Ненужная вложенность кода (функция обращается к функции которая обращается к функции и на каждом этапе размазан какой-то минимум важного кода) - характерная особенность ИИ стиля
- Очень приятный момент, можно спокойно писать "форму с логином" или "таймер в главном окне рядом с окном загрузки" - ИИ прекрасно оцифровывает и меняет нужные компоненты
- Курсор очень хорош в поиске и анализе кода. Можно спокойно спрашивать за незнакомый код и получать качественные вменяемые ответы
- Нужно следить за обезличенностью речи и не давать ему понять, что ты не согласен с решением/говнишься. ИИ тут же начинает всё срочно переделывать.
Никогда не спрашивайте ИИ напрямую, почему оно что-либо сделало, оно засчитает это за предъяву
- Курсору можно относительно доверять в аспекте консистентности изменений, в большинстве случаев он ничего не забудет поменять. Впечатляет, что я забываю менять какие-то импорты или куски логики в соседних файлах чаще чем ИИ
- Под конец вторника оно всё ещё было ужасно, никак не хотело заводиться, а я это очень нервно воспринимаю. На 14ом часу работу едва ли не в кровавые слёзы. Эффективнее по нервам, качеству и скорее всего по времени был бы подход - начать делать полностью с нуля, подкидывая исходники как референс для ИИ вдохновения
Продолжу описывать процесс работы длиной в (предыдущую) неделю,мысли подходы в формате:
* Затраченное время
* Какие изменения вносил
* Какие выводы сделаны/инсайты получены
пнд-втр, 10+14=24ч.
- Загружен проект, проведена первичная оценка имеющейся кодбазы. У меня есть целый гуглдокумент на 9 страниц с говной, где я выписывал как на ревью все проблемы исходника.
Мы хотели во имя науки скормить его в таком виде ИИ чтоб он составил себе подробное ТЗ и по нему прошёлся, закрыв дыры
Эксперимент признан неудачным
- отсутствие БД(!), консистентного хранилища состояния.
- Фронт на сырых HTML шаблонах
- ЯндексS3 как единственное хранилище файлов (я не планировал использовать внешнее S3)
- Также наблюдалось огромное количество дыр в безопасности и производительности: по моим подсчётам, оно не должно было вытягивать больше 2-3 человек одновременно
- Модели кэшировались очень частично и вызывали зависания на несколько минут из-за подгрузки гигабайтов весов каждый первый запуск
- В некоторых кейсах происходили очень неявные критические баги. К примеру, если первая задача в систему не была с флагом на разделение спикеров, то ни одна последующая эту функцию запустить уже не сможет
Я очень недооценил на старте сырость исходника.
Вместе с тем, и это очень важно, Оно работало! Легаси кодбаза уже выступала в роли технического концепта желаемого функционала, а значит все ответы и фичи, хоть и реализованные криво уже были в ней, и моей задачей стал перепил структуры и организации кодбазы
Инсайты
- Я долго пытался понять, с какого бока приступить, это было очень сложной задачей - найти точку входа для изменений на легаси в 2-3к строк. Начал с фронта, философски отнесясь к бэкенду как к чёрной коробке с публичным контрактом, и потом уже переходить к бэку
- Фронт перепилился в TS+Vite приложение на удивление спокойно. Я, как совсем не фронтендер, не догадываюсь, какие ужасы там творились. Оно и к лучшему.
Самый важный инсайт - если позаботиться о хороших подробных описаниях-промптах и приложить референсы - ИИ может осилить даже объёмные структурные изменения.
- Хорошо показал себя метод, где сначала ИИ переписывает всё в один более большой файл и потом уже разбивает на несколько маленьких отдельной цепочкой рефакторинг промпт-задач
- Бэк представлял собой зрелище, не самое страшное в моей практике, но опасное ввиду неявно заложеннных бомб
ИИ плохо справляется с уменьшением сложности/вложенности кода и не всегда понимает проблему асинхронности, организации IO/Heavy задач.
Фокус на локальном решении текущей мелкой проблемы осложняет использование общих абстракций, моделей. Это должно фокусироваться отдельно через Rules, промпты.
Ненужная вложенность кода (функция обращается к функции которая обращается к функции и на каждом этапе размазан какой-то минимум важного кода) - характерная особенность ИИ стиля
- Очень приятный момент, можно спокойно писать "форму с логином" или "таймер в главном окне рядом с окном загрузки" - ИИ прекрасно оцифровывает и меняет нужные компоненты
- Курсор очень хорош в поиске и анализе кода. Можно спокойно спрашивать за незнакомый код и получать качественные вменяемые ответы
- Нужно следить за обезличенностью речи и не давать ему понять, что ты не согласен с решением/говнишься. ИИ тут же начинает всё срочно переделывать.
Никогда не спрашивайте ИИ напрямую, почему оно что-либо сделало, оно засчитает это за предъяву
- Курсору можно относительно доверять в аспекте консистентности изменений, в большинстве случаев он ничего не забудет поменять. Впечатляет, что я забываю менять какие-то импорты или куски логики в соседних файлах чаще чем ИИ
- Под конец вторника оно всё ещё было ужасно, никак не хотело заводиться, а я это очень нервно воспринимаю. На 14ом часу работу едва ли не в кровавые слёзы. Эффективнее по нервам, качеству и скорее всего по времени был бы подход - начать делать полностью с нуля, подкидывая исходники как референс для ИИ вдохновения
❤14👍11🔥2❤🔥1
Предыдущее тут
3/5 пост =)
Среда-Четверг, 10+11=21ч
Был получен минимальный рабочий сценарий с файлами. Весь день посвящён структурированию бэка, разделению логики web бэкенда и аналитического бэкенда на разные сервисы, devops активностям, закладыванию моделей БД. Затянуты Mongo - основная БД, Minio - локальный S3 и Redis как БД коммуникации и шеринга состояний между сервисами
Моей ошибкой, унёсшей ~4 часа времени стала попытка сделать по-быстрому локальное хранилище вместо S3. ИИ запутался в папках и роутинг раздачи файликов не взлетел.
Нужно было сразу брать minio и на лету перепиливать S3 на S3 по сути. Пришлось отбросить/вырезать некоторое количество кода. Слава Git
Переработал LLM суммаризацию. Основная работа заключалась в вынесении конфига и ограждению курсора от попыток сменить схему SO с рабочей на нерабочую. В исходной кодбазе с неё всё было хорошо
На конец дня реорганизованный минимальный пайплайн работал на более стабильных и понятных основах, полностью собирался и обновлялся в докере. от легаси кода бэка и фронта осталось в лучшем случае 20%
Инсайты
- ИИ имеет свойство плодить кривые конфиги в разных местах. Это должно подвергаться контролю за счёт Rules, темплейтов проекта
- Нельзя вайбкодить сложную задачу. (вайбкод - не вдумываясь принимать изменения ИИ). С каждой следующей итерацией и уточнением, особенно если что-то не получается, ИИ заходит всё дальше в дебри и пишет всё более локальноориентированный структурно хреновый код
И это как будто бы базовое правило coding with AI. Ты должен вмешаться, проанализировать и выбрать корректный подход прежде чем ИИ затронет слишком многое. Возможно принять решение запустить всё с самого начала.
- Генеративный подход - когда создаёшь новый код над старым, в разы менее затратен с ИИ чем обратный, где нужно рефакторить/убирать излишки старого. Для меня, как человека, проще работать с существующим на изученной кодбазе
- ИИ затрагивает широкий набор изменений в рамках своей работы, часто работаешь над 2-3 параллельными задачами/направлениями изменений. Это осложняет классическую историю ведения гита. Очень важно регулярно уделять внимание регрессу и делать отсечки, которые пойдут коммитом в гит.
В курсоре можно откатываться на чекпоинты чатиков, но это не всегда работает и неудобно.
Уверенность, что я могу надёжно откатиться на рабочую версию - залог спокойной работы
Как итог, считаю, что мастхэв должен быть шаблон проекта, адаптированный под ИИ, где уже организована и тщательно описана желаемая организация проекта:
* Конфиги и их место
* Лучшие практики инфры вплоть до шаблонов докеров,
* Заложены примеры привычных схем, ролей, моделей.
* Подключены на уровне низкоуровневых адаптеров человекописные базовые внешние модули типа БД, web-сессий, сокетов и т.д.
* Продумана и заложена механика проброса зависимостей и централизованной инициализации модулей.
* Оно позволяет вносить изменения уже отсраиваясь от лучших практик, более точечно
ИИ склонен тупо херачить глобальные объекты и начинает творить лютую дичь как только ловит от этого сложности
На конец четверга, четвёртый физический день работы, уже проходили все базовые сценарии проекта, завязанные непосредственно на ЛК и обработку звуковых файлов. UI принял околофинальные очертания, вырисовалась более стройная организация и инфраструктурная обвязка. Проект билдился в докер и запускался на сервере
3/5 пост =)
Среда-Четверг, 10+11=21ч
Был получен минимальный рабочий сценарий с файлами. Весь день посвящён структурированию бэка, разделению логики web бэкенда и аналитического бэкенда на разные сервисы, devops активностям, закладыванию моделей БД. Затянуты Mongo - основная БД, Minio - локальный S3 и Redis как БД коммуникации и шеринга состояний между сервисами
Моей ошибкой, унёсшей ~4 часа времени стала попытка сделать по-быстрому локальное хранилище вместо S3. ИИ запутался в папках и роутинг раздачи файликов не взлетел.
Нужно было сразу брать minio и на лету перепиливать S3 на S3 по сути. Пришлось отбросить/вырезать некоторое количество кода. Слава Git
Переработал LLM суммаризацию. Основная работа заключалась в вынесении конфига и ограждению курсора от попыток сменить схему SO с рабочей на нерабочую. В исходной кодбазе с неё всё было хорошо
На конец дня реорганизованный минимальный пайплайн работал на более стабильных и понятных основах, полностью собирался и обновлялся в докере. от легаси кода бэка и фронта осталось в лучшем случае 20%
Инсайты
- ИИ имеет свойство плодить кривые конфиги в разных местах. Это должно подвергаться контролю за счёт Rules, темплейтов проекта
- Нельзя вайбкодить сложную задачу. (вайбкод - не вдумываясь принимать изменения ИИ). С каждой следующей итерацией и уточнением, особенно если что-то не получается, ИИ заходит всё дальше в дебри и пишет всё более локальноориентированный структурно хреновый код
И это как будто бы базовое правило coding with AI. Ты должен вмешаться, проанализировать и выбрать корректный подход прежде чем ИИ затронет слишком многое. Возможно принять решение запустить всё с самого начала.
- Генеративный подход - когда создаёшь новый код над старым, в разы менее затратен с ИИ чем обратный, где нужно рефакторить/убирать излишки старого. Для меня, как человека, проще работать с существующим на изученной кодбазе
- ИИ затрагивает широкий набор изменений в рамках своей работы, часто работаешь над 2-3 параллельными задачами/направлениями изменений. Это осложняет классическую историю ведения гита. Очень важно регулярно уделять внимание регрессу и делать отсечки, которые пойдут коммитом в гит.
В курсоре можно откатываться на чекпоинты чатиков, но это не всегда работает и неудобно.
Уверенность, что я могу надёжно откатиться на рабочую версию - залог спокойной работы
Как итог, считаю, что мастхэв должен быть шаблон проекта, адаптированный под ИИ, где уже организована и тщательно описана желаемая организация проекта:
* Конфиги и их место
* Лучшие практики инфры вплоть до шаблонов докеров,
* Заложены примеры привычных схем, ролей, моделей.
* Подключены на уровне низкоуровневых адаптеров человекописные базовые внешние модули типа БД, web-сессий, сокетов и т.д.
* Продумана и заложена механика проброса зависимостей и централизованной инициализации модулей.
* Оно позволяет вносить изменения уже отсраиваясь от лучших практик, более точечно
ИИ склонен тупо херачить глобальные объекты и начинает творить лютую дичь как только ловит от этого сложности
На конец четверга, четвёртый физический день работы, уже проходили все базовые сценарии проекта, завязанные непосредственно на ЛК и обработку звуковых файлов. UI принял околофинальные очертания, вырисовалась более стройная организация и инфраструктурная обвязка. Проект билдился в докер и запускался на сервере
❤11🔥4👍2👎1🤝1
Отвлекаясь от длиннопостов
Как понять, что справляешься как лид бодрой RnD команды?
Если отлучаешься на пару недель и больше - ни у кого ничего не горит и не подгорает. Активности команды не начинают падать на пол.
С лёгким напрягом начинаю планировать двухнедельный августовский отпуск. Предыдущие однонедельные эксперименты отсутствия себя проходили почти успешно. Если не считать того, что список дел наобсудить и вгрузиться после возращения в понедельник возрастал до неприличных размеров
В понедельник же происходит самый ответственный виклик, где надо собрать всю оперативную инфу и соединить всех со всеми.
Легко догадаться, какой день недели стал моим самым нелюбимым. Вот так люди и становятся суеверными.
Как понять, что справляешься как лид бодрой RnD команды?
Если отлучаешься на пару недель и больше - ни у кого ничего не горит и не подгорает. Активности команды не начинают падать на пол.
С лёгким напрягом начинаю планировать двухнедельный августовский отпуск. Предыдущие однонедельные эксперименты отсутствия себя проходили почти успешно. Если не считать того, что список дел наобсудить и вгрузиться после возращения в понедельник возрастал до неприличных размеров
В понедельник же происходит самый ответственный виклик, где надо собрать всю оперативную инфу и соединить всех со всеми.
Легко догадаться, какой день недели стал моим самым нелюбимым. Вот так люди и становятся суеверными.
❤4👍4🔥2😁1🤯1
4/5 пост, дальше только выводы
предыдущее
Пятница, 12ч
Realtime транскрипт, правки, сущности, баги, рефакторинг
Я надеялся в пятницу уже получить полностью рабочую сборку, но оставалось слишком много дел по работе системы, google extension ещё и не был начат.
Зафиксировал опоздание в день.
По привычке закопался в алгоритм и протокол realtime транскрибации - как копить буфер, корректировать транскрипт на лету. Закопаться нормально при классической разработке, но непозволительно в условиях интенсива. Стало ещё одной моей крупной ошибкой, стоившей 6 часов. Но хотя бы отловил пару проблем в процессе.
Инсайты
- На примере realtime протокола, ИИ не может алгоритмический код без очень точного описания.
Напутать индексацию пакета, поставить условие сброса кэша туда, куда его ставить НЕЛЬЗЯ, забыть, как используются счётчики. Ещё засунуть открытый сокет в хранилище сокетов сессий и получить обсёр в моменте, когда фронт отсоединяется первым от "активной" сессии... Напомню, что чем больше ты его поправляешь тем хуже становится код.
По итогу всю эту часть я делал ручками. Вдумчиво и внимательно.
- ИИ в общем случае очень плохо пишет схемы данных без очень конкретного аналитического описания. Легче продумать самому, а ИИ уже отдать на интеграцию.
Это в целом хорошая гигиеническая практика - Писать HLD и примерную схему данных до начала разработки.
Суббота, 8 часов
Гугл расширение, минификсы и завершение этапа проекта
Абсолютно новый для меня зверь. Без ИИ я такое расширение написать физически бы не смог. Поработал скорее как аналитик - где в первую очередь нужно описать и донести, что ты хочешь, подсобрать ожидания и хотелки хотя бы у себя в голове.
Так как осталось время, запилил допфичу по шерингу транскриптов наподобии гугл доков.
ИИ умудрился сломаться на несложном расширении модели БД, но с полпинка починился и адекватно написал миграцию.
Инсайты
- Структурированное МиниТЗ с просьбой составить план изменения, а потом ему следовать - хороший способ брать в выполнение сложные фичи
- ИИ владеет хорошей базой знаний по технологиям. Если перед реализацией в коде обсудить-посёрчить через него варианты, это может дать качественное решение
- Эмодзи в логах это на удивление прекрасно, если их не становится слишком много. Надо взять себе в боевые практики. С визуально-цветовыми ассоциациями проще выхватывать нужные моменты в общем потоке
На этом жизнеспособном этапе я закрыл активную разработку и все основные задачи интенсива. Дальше оставалось подведение итогов и горделивая беготня с демонстрациями во всех инстанциях.
Спустя неделю тестов на людях в гугл расширении обнаружилась критичнейшая вещь, очень подло и бесследно дропавшая запись спустя 20-40мин от начала.
ИИ по косвенным репортам и логам не справился - также пришлось погружаться самому. Теперь я знаю и умею вытворять с хромиум браузером гораздо больше интересных вещей.
П.с. извиняюсь за качество демок. Изначально они предназначались для околорабочих чатиков. NDAшу как могу.
предыдущее
Пятница, 12ч
Realtime транскрипт, правки, сущности, баги, рефакторинг
Я надеялся в пятницу уже получить полностью рабочую сборку, но оставалось слишком много дел по работе системы, google extension ещё и не был начат.
Зафиксировал опоздание в день.
По привычке закопался в алгоритм и протокол realtime транскрибации - как копить буфер, корректировать транскрипт на лету. Закопаться нормально при классической разработке, но непозволительно в условиях интенсива. Стало ещё одной моей крупной ошибкой, стоившей 6 часов. Но хотя бы отловил пару проблем в процессе.
Инсайты
- На примере realtime протокола, ИИ не может алгоритмический код без очень точного описания.
Напутать индексацию пакета, поставить условие сброса кэша туда, куда его ставить НЕЛЬЗЯ, забыть, как используются счётчики. Ещё засунуть открытый сокет в хранилище сокетов сессий и получить обсёр в моменте, когда фронт отсоединяется первым от "активной" сессии... Напомню, что чем больше ты его поправляешь тем хуже становится код.
По итогу всю эту часть я делал ручками. Вдумчиво и внимательно.
- ИИ в общем случае очень плохо пишет схемы данных без очень конкретного аналитического описания. Легче продумать самому, а ИИ уже отдать на интеграцию.
Это в целом хорошая гигиеническая практика - Писать HLD и примерную схему данных до начала разработки.
Суббота, 8 часов
Гугл расширение, минификсы и завершение этапа проекта
Абсолютно новый для меня зверь. Без ИИ я такое расширение написать физически бы не смог. Поработал скорее как аналитик - где в первую очередь нужно описать и донести, что ты хочешь, подсобрать ожидания и хотелки хотя бы у себя в голове.
Так как осталось время, запилил допфичу по шерингу транскриптов наподобии гугл доков.
ИИ умудрился сломаться на несложном расширении модели БД, но с полпинка починился и адекватно написал миграцию.
Инсайты
- Структурированное МиниТЗ с просьбой составить план изменения, а потом ему следовать - хороший способ брать в выполнение сложные фичи
- ИИ владеет хорошей базой знаний по технологиям. Если перед реализацией в коде обсудить-посёрчить через него варианты, это может дать качественное решение
- Эмодзи в логах это на удивление прекрасно, если их не становится слишком много. Надо взять себе в боевые практики. С визуально-цветовыми ассоциациями проще выхватывать нужные моменты в общем потоке
На этом жизнеспособном этапе я закрыл активную разработку и все основные задачи интенсива. Дальше оставалось подведение итогов и горделивая беготня с демонстрациями во всех инстанциях.
Спустя неделю тестов на людях в гугл расширении обнаружилась критичнейшая вещь, очень подло и бесследно дропавшая запись спустя 20-40мин от начала.
ИИ по косвенным репортам и логам не справился - также пришлось погружаться самому. Теперь я знаю и умею вытворять с хромиум браузером гораздо больше интересных вещей.
П.с. извиняюсь за качество демок. Изначально они предназначались для околорабочих чатиков. NDAшу как могу.
🔥8🤔3❤1
Синк о том, как нормально развернуть prod с участием меня, кубера, переменного количества видеокарт, Ray, VLLM, нейросетей разного масштаба, двух дальнеродственных проектов, которые шерят ресурсы.
Итак, у нас есть:
- Ray фреймворк предполагает резервирование видеокарт под собой и в общем случае является ключом к их эффективному использованию
- Мы не уверены до конца, насколько он подружился с нашим кубером
- Видеокарты в общем случае резервируются, но нужно понимать подо что и насколько
- Первые 4 видеокарты резервируются легко и надёжно. Остальные - дольше и не так надёжно
- Под задачи проектов по моей оценке хорошо бы иметь в доступе 6-8 от нагрузки
- Дальнеродственные проекты хотелось бы разместить на том же кластере, но изолированно инфраструктурно
- Мне уже жаль бедного девопса, перед которым встанет задача это всё прикрепить к текущему CI/CD
Задачи такого рода отношу к комплексно-неприятным ибо прямого понятного решения не предвидится, начинаешь закапываться в трейдоффы, а конечное предложение в любом случае пожрёт ресурсы команды с неясной перспективой.
Когда-нибудь я точно смогу делать это рутинно, а пока - та ещё головоломка получается.
Пришли к тому, что для расширения видеокарт нужно эффективно занять существующие, а на существующие влезает примерно половина комфортно желаемой конфигурации системы.
Looks like предстоит интересный эксперимент по плотному утрамбовыванию всего и вся в минимальное количество H100. В целом, не самая ненужная метрика.
Как же не хватает под рукой какого-то крайне сеньорного сеньора, который бы пришёл и всё порешал, пока я внимал его мудрости.
Итак, у нас есть:
- Ray фреймворк предполагает резервирование видеокарт под собой и в общем случае является ключом к их эффективному использованию
- Мы не уверены до конца, насколько он подружился с нашим кубером
- Видеокарты в общем случае резервируются, но нужно понимать подо что и насколько
- Первые 4 видеокарты резервируются легко и надёжно. Остальные - дольше и не так надёжно
- Под задачи проектов по моей оценке хорошо бы иметь в доступе 6-8 от нагрузки
- Дальнеродственные проекты хотелось бы разместить на том же кластере, но изолированно инфраструктурно
- Мне уже жаль бедного девопса, перед которым встанет задача это всё прикрепить к текущему CI/CD
Задачи такого рода отношу к комплексно-неприятным ибо прямого понятного решения не предвидится, начинаешь закапываться в трейдоффы, а конечное предложение в любом случае пожрёт ресурсы команды с неясной перспективой.
Когда-нибудь я точно смогу делать это рутинно, а пока - та ещё головоломка получается.
Пришли к тому, что для расширения видеокарт нужно эффективно занять существующие, а на существующие влезает примерно половина комфортно желаемой конфигурации системы.
Looks like предстоит интересный эксперимент по плотному утрамбовыванию всего и вся в минимальное количество H100. В целом, не самая ненужная метрика.
Как же не хватает под рукой какого-то крайне сеньорного сеньора, который бы пришёл и всё порешал, пока я внимал его мудрости.
❤3🔥2
Пост 5/5, финалочка
Предыдущий
Наконец-то время подвести черту всей затее
Общий итог:
Первое и самое важное -порядочно освежил коднавыки и страты работы на форсаже.
Изначально без ИИ я бы оценил эквивалентный проект с нуля в 4 недели + фронтенд (ибо я не могу во фронтенд, но примерно заложил бы 2-3 недели). + финальная интеграция и пусконаладка (пусть 1 неделя) В сумме 8 недель
Для дальнейшего развития текущих наработок я бы заложил + пару недель рефакторинга (в итоге даст 4.5 недели на ИИ разработку, если не форсажить по 65 часов в неделю, как я)
В итоге получается ускорение на 43.75%, если очень грубо посчитать
Все намеченные изначально фичи и даже чуть больше были выполнены с опозданием в день относительно плана.
Проект вполне живой. Крутится, показывается, функционирует. Вокруг него уже задумчиво ходит пара продактов и тыкают палкой. Баги появляются, ловятся и фиксятся в основном незначительные/связанные с проблемами личного сервера
Сложно подобрать метрику качества для такой кодбазы, но в целом имеем ~3к строк вполне прогнозируемого кода (кроме, опять же, фронтенда, я хз как там)
Основным стандартам качества оно соответствует ~70%. Что значит ~ за 2 итерации ревью можно довести до вполне качественного кода.
Существенные проблемы/компромиссы:
* Сильно не хватает универсальности и некоторой доли абстракций. Условная замена Minio на какой-либо внешний S3 вероятна, но потребует переписывания многих вещей
* Масштабирование воркеров практически необходимо в будущем, но я не могу дать гарантий его бесшовной работы сейчас. Чует моё сердечко, что-то там перемудрили мы с Курсором.
* Оставлено некоторое количество проблем/компромиссов, которые не были бы допущены при изначально человеческом подходе.
* Избыточность и неравномерность логов, наличие артефактов в коде - любой другой разработчик кроме меня вынужден будет немного пострадать при онбординге
* Где-то в районе google extension есть большой простор для багов т.к. оно выступает в роли клиентской части и зависит от браузеров пользователей
* Через какое-то время вскрылся существенный баг между плеером и minio - как он подгружает большие аудио
Пока свободную версию щупать здесь https://speechcoreai.com/
Предыдущий
Наконец-то время подвести черту всей затее
Общий итог:
Первое и самое важное -порядочно освежил коднавыки и страты работы на форсаже.
Изначально без ИИ я бы оценил эквивалентный проект с нуля в 4 недели + фронтенд (ибо я не могу во фронтенд, но примерно заложил бы 2-3 недели). + финальная интеграция и пусконаладка (пусть 1 неделя) В сумме 8 недель
Для дальнейшего развития текущих наработок я бы заложил + пару недель рефакторинга (в итоге даст 4.5 недели на ИИ разработку, если не форсажить по 65 часов в неделю, как я)
В итоге получается ускорение на 43.75%, если очень грубо посчитать
Все намеченные изначально фичи и даже чуть больше были выполнены с опозданием в день относительно плана.
Проект вполне живой. Крутится, показывается, функционирует. Вокруг него уже задумчиво ходит пара продактов и тыкают палкой. Баги появляются, ловятся и фиксятся в основном незначительные/связанные с проблемами личного сервера
Сложно подобрать метрику качества для такой кодбазы, но в целом имеем ~3к строк вполне прогнозируемого кода (кроме, опять же, фронтенда, я хз как там)
Основным стандартам качества оно соответствует ~70%. Что значит ~ за 2 итерации ревью можно довести до вполне качественного кода.
Существенные проблемы/компромиссы:
* Сильно не хватает универсальности и некоторой доли абстракций. Условная замена Minio на какой-либо внешний S3 вероятна, но потребует переписывания многих вещей
* Масштабирование воркеров практически необходимо в будущем, но я не могу дать гарантий его бесшовной работы сейчас. Чует моё сердечко, что-то там перемудрили мы с Курсором.
* Оставлено некоторое количество проблем/компромиссов, которые не были бы допущены при изначально человеческом подходе.
* Избыточность и неравномерность логов, наличие артефактов в коде - любой другой разработчик кроме меня вынужден будет немного пострадать при онбординге
* Где-то в районе google extension есть большой простор для багов т.к. оно выступает в роли клиентской части и зависит от браузеров пользователей
* Через какое-то время вскрылся существенный баг между плеером и minio - как он подгружает большие аудио
Пока свободную версию щупать здесь https://speechcoreai.com/
❤6👍3🔥2
proxy_selenium.py
10 KB
Понадобилось мне кое-что автоматизированно нагуглить, а случился внезапный закоп.
Не очень понимаю, почему и как, но в селениумный хром драйвер аномально сложно пропихнуть авторизованную проксю.
Оно жалуется, что не может захавать из-за авторизации
А если её пропихнуть без авторизации, то закономерно же отлетает уже сама прокся, запрашивая basicauth.
Не первое откопанное решение, но ставшее первым рабочим, оказалось с оригинальным применением гугл расширения: оно запускает только бэкграунд, вешает listeners на любые авторизационные окна и пытается их заполнять.
Есть мнение, что хватило бы инит скрипта авторизации т.к. дальше бы прокся закешировала свои кредсы, но тогда бы не получилось такого забавного хака.
Раз появившись в предыдущей моей затее, google extensions начинают меня преследовать. Так и порождаются специализации.
Не очень понимаю, почему и как, но в селениумный хром драйвер аномально сложно пропихнуть авторизованную проксю.
Оно жалуется, что не может захавать из-за авторизации
chrome_options.add_argument(f'--proxy-server=https://{proxy.username}:{proxy.password}@{proxy.ip}:{proxy.port}')А если её пропихнуть без авторизации, то закономерно же отлетает уже сама прокся, запрашивая basicauth.
Не первое откопанное решение, но ставшее первым рабочим, оказалось с оригинальным применением гугл расширения: оно запускает только бэкграунд, вешает listeners на любые авторизационные окна и пытается их заполнять.
Есть мнение, что хватило бы инит скрипта авторизации т.к. дальше бы прокся закешировала свои кредсы, но тогда бы не получилось такого забавного хака.
Раз появившись в предыдущей моей затее, google extensions начинают меня преследовать. Так и порождаются специализации.
❤3👍2🥰2