#лабораторный_журнал
Нам привезли сервер с четырьмя GPU на 24GB видеопамяти. Эта штука стоит посреди офиса и звучит как турбина самолета. Когда она включена становится невозможно разговаривать.
Казалось бы, зачем такая махина для двух человек, у которых даже нет данных? На самом деле это часть политического хода. Люди на фабрике с трудом пускают нас ставить роботов с камерами, потому что для них это лишние подвижные части, которые не приносят пользу. Их интересует поставлять салат на прилавки. С ML всегда возникает эта проблема курицы и яйца: машинлернерам нечем заняться пока нет данных, данных не будет пока нет машинлернеров.
Поэтому наш менеджер сначала нанял нас, заказал этот громадный сервер, а теперь пушит экзеков: “Смотрите, у нас есть два дорогих специалиста и графические карты, но нам нужны данные.” Настоящее связующие обязательство.
Тем временем я придумал как нам получить разметку. У агрономов есть процесс осмотра части фабрики, который занимает три часа каждый день. То есть люди куда-то идут, записывают проблемы на листочке, потом возвращаются, вносят их в эксель, потом обозначают проблемы маркерами на бумажной доске и рассказывают про них на специальной встрече. Мы предложили: что если у вас будет интерфейс, где вы сможете осматривать те же части на фото? Никуда идти не надо, сидишь за компьютером, свайпаешь картинки и помечаешь их: есть проблема или проблемы нет. Далее показываем карту с проблемами на экране. По нашим подсчетам процесс можно ужать до полутора часов без ML и до 10 минут, если натренировать модель отлавливать те же проблемы. Агрономы получают экономию времени и клеток мозга, мы получаем разметку, вин-вин.
Нарисовали схему, показали агрономам, им понравилось. Теперь надо сделать. На самом деле я удивлен, что так много было сделано за пару недель. Пусть мы не написали ни строчки прод кода, но схема хранилища изображений сформирована и план ML проекта намечен.
Нам привезли сервер с четырьмя GPU на 24GB видеопамяти. Эта штука стоит посреди офиса и звучит как турбина самолета. Когда она включена становится невозможно разговаривать.
Казалось бы, зачем такая махина для двух человек, у которых даже нет данных? На самом деле это часть политического хода. Люди на фабрике с трудом пускают нас ставить роботов с камерами, потому что для них это лишние подвижные части, которые не приносят пользу. Их интересует поставлять салат на прилавки. С ML всегда возникает эта проблема курицы и яйца: машинлернерам нечем заняться пока нет данных, данных не будет пока нет машинлернеров.
Поэтому наш менеджер сначала нанял нас, заказал этот громадный сервер, а теперь пушит экзеков: “Смотрите, у нас есть два дорогих специалиста и графические карты, но нам нужны данные.” Настоящее связующие обязательство.
Тем временем я придумал как нам получить разметку. У агрономов есть процесс осмотра части фабрики, который занимает три часа каждый день. То есть люди куда-то идут, записывают проблемы на листочке, потом возвращаются, вносят их в эксель, потом обозначают проблемы маркерами на бумажной доске и рассказывают про них на специальной встрече. Мы предложили: что если у вас будет интерфейс, где вы сможете осматривать те же части на фото? Никуда идти не надо, сидишь за компьютером, свайпаешь картинки и помечаешь их: есть проблема или проблемы нет. Далее показываем карту с проблемами на экране. По нашим подсчетам процесс можно ужать до полутора часов без ML и до 10 минут, если натренировать модель отлавливать те же проблемы. Агрономы получают экономию времени и клеток мозга, мы получаем разметку, вин-вин.
Нарисовали схему, показали агрономам, им понравилось. Теперь надо сделать. На самом деле я удивлен, что так много было сделано за пару недель. Пусть мы не написали ни строчки прод кода, но схема хранилища изображений сформирована и план ML проекта намечен.
👍46🔥17👏2
#лабораторный_журнал
Теперь я понимаю, почему так не любят нанимать джунов.
Некоторые достижения моего коллеги к данному моменту:
1. Не разобрался в структуре хранения фотографий на S3. Подумал, что там нет интересующих нас лейблов, поэтому полез в инструмент для лейблинга, где эти лейблы были. Вручную сопоставил 1500 изображений,заебался устал и сообщил всем, что данных совсем нет. Провал в том, что рядом с изображениями, в отдельном файле, лежали и нужные лейблы, и куча полезных метаданных. Все это можно было бы узнать задавшись вопросом: “откуда берутся данные?” Оказалось данных у нас вполне достаточно.
Я еще спросил его: “Ладно, сопоставлял изображения между двумя инструментами, но зачем руками? А питон на что?” Он мне: “Предлагаешь использовать Selenium (инструмент имитирующий браузер, обычно используют для скрейпинга сайтов или тестов)?” То есть он подумал, что мы будем скрейпить веб интерфейс собственного хранилища. Из которого можем скачивать напрямую, потому что это же наше блин хранилище. Короче простых путей не ищем.
2. Попросил его набросать в миро схему процесса, который мы будем строить, чтобы потом мы могли презентовать его агрономам. Так же прикинуть, сколько времени мы можем им сэкономить с применением модели. Он сделал неплохую схему, но как ее делать в основном рассказал я. Он накидал туда много терминов понятных нам и непонятных агрономам (напр. “false positive”, “positive class”, “negative class”), описал все простынями текста, а так же перепутал местами false positive и false negative. Так что пришлось проверять и объяснять как поправить.
3. Дал ему задачу понять, как составить из фотографий от робота целое изображение интересующей области. Дано много фотографий, пересекающихся между собой, и для каждой даны координаты камеры. Коллега не разобрался, как робот движется и что попадает на изображение, а пошел пробовать библиотеки для склеивания изображений (такие как используются для спутниковых снимков). Пришлось дать более конкретную задачу: выяснить что и как фотографирует робот, руками сопоставить изображения для одной области, чтобы понимать как вообще выглядит результат, далее сделать ноутбук с примерами разных решений.
4. Попросил его настроить на нашем мегасервере CUDA. Он сказал мне, что все готово, но вскользь упомянул, что была какая-то проблема с CUDA toolkit. Позже я пытался завести обучение и не понимал, почему код не видит GPU. Выяснилось, что CUDA toolkit не установлен. Проблема решилась просто выполнением комманд по инструкции с сайта nvidia, проще некуда.
Джун тем отличается от не-джуна, что результату его работы нельзя доверять. Нужно ставить пошагово расписанные задачи, проверять результат, а так же следить, чтобы исполнитель не забуксовал где-то в процессе. Помню, что и сам таким был: тыкался куда-то бессистемно пока не заработает. Джуну нехватает не технических знаний, а стройного подхода к решению проблем. Например для джуна не очевидно, что если работаешь с какими-то данными, стоит сначала изучить откуда они берутся, а не запихивать их в любимые ML фреймворки. Нехватает в голове модели того, как работают вещи. Думаю это и есть загадочный “опыт работы”, который все так ценят.
Парень очень умный и супер мотивированный: глубоко закапывается, на выходных пишет micrograd по видео урокам, проходит курсы. Из-за этого кажется, будто ему можно дать задачу вида: “вот проблема, надо решить”. Так вот — нельзя. Приходится снижать свои ожидания, напоминать себе, что парня надо сначала обучить.
В комментариях написали про необходимость доверительных отношений, чтобы джун задавал вопросы, а не молчал до последнего. Это правда! Поэтому я поставил с ним регулярные 1х1 встречи, отвечаю на все вопросы, хвалю за любые мелочи и стараюсь все объяснять.
Теперь я понимаю, почему так не любят нанимать джунов.
Некоторые достижения моего коллеги к данному моменту:
1. Не разобрался в структуре хранения фотографий на S3. Подумал, что там нет интересующих нас лейблов, поэтому полез в инструмент для лейблинга, где эти лейблы были. Вручную сопоставил 1500 изображений,
Я еще спросил его: “Ладно, сопоставлял изображения между двумя инструментами, но зачем руками? А питон на что?” Он мне: “Предлагаешь использовать Selenium (инструмент имитирующий браузер, обычно используют для скрейпинга сайтов или тестов)?” То есть он подумал, что мы будем скрейпить веб интерфейс собственного хранилища. Из которого можем скачивать напрямую, потому что это же наше блин хранилище. Короче простых путей не ищем.
2. Попросил его набросать в миро схему процесса, который мы будем строить, чтобы потом мы могли презентовать его агрономам. Так же прикинуть, сколько времени мы можем им сэкономить с применением модели. Он сделал неплохую схему, но как ее делать в основном рассказал я. Он накидал туда много терминов понятных нам и непонятных агрономам (напр. “false positive”, “positive class”, “negative class”), описал все простынями текста, а так же перепутал местами false positive и false negative. Так что пришлось проверять и объяснять как поправить.
3. Дал ему задачу понять, как составить из фотографий от робота целое изображение интересующей области. Дано много фотографий, пересекающихся между собой, и для каждой даны координаты камеры. Коллега не разобрался, как робот движется и что попадает на изображение, а пошел пробовать библиотеки для склеивания изображений (такие как используются для спутниковых снимков). Пришлось дать более конкретную задачу: выяснить что и как фотографирует робот, руками сопоставить изображения для одной области, чтобы понимать как вообще выглядит результат, далее сделать ноутбук с примерами разных решений.
4. Попросил его настроить на нашем мегасервере CUDA. Он сказал мне, что все готово, но вскользь упомянул, что была какая-то проблема с CUDA toolkit. Позже я пытался завести обучение и не понимал, почему код не видит GPU. Выяснилось, что CUDA toolkit не установлен. Проблема решилась просто выполнением комманд по инструкции с сайта nvidia, проще некуда.
Джун тем отличается от не-джуна, что результату его работы нельзя доверять. Нужно ставить пошагово расписанные задачи, проверять результат, а так же следить, чтобы исполнитель не забуксовал где-то в процессе. Помню, что и сам таким был: тыкался куда-то бессистемно пока не заработает. Джуну нехватает не технических знаний, а стройного подхода к решению проблем. Например для джуна не очевидно, что если работаешь с какими-то данными, стоит сначала изучить откуда они берутся, а не запихивать их в любимые ML фреймворки. Нехватает в голове модели того, как работают вещи. Думаю это и есть загадочный “опыт работы”, который все так ценят.
Парень очень умный и супер мотивированный: глубоко закапывается, на выходных пишет micrograd по видео урокам, проходит курсы. Из-за этого кажется, будто ему можно дать задачу вида: “вот проблема, надо решить”. Так вот — нельзя. Приходится снижать свои ожидания, напоминать себе, что парня надо сначала обучить.
В комментариях написали про необходимость доверительных отношений, чтобы джун задавал вопросы, а не молчал до последнего. Это правда! Поэтому я поставил с ним регулярные 1х1 встречи, отвечаю на все вопросы, хвалю за любые мелочи и стараюсь все объяснять.
👍68👎2🤔1
Я вам сейчас очень быстро объясню, что такое label drift (или concept drift).
Работая в Я.Толоке я сделал проект по Computer Vision для курса в ШАД. Задача была обучить модель классифицировать автомобильные номера на российские и все остальные.
В этом году мои коллеги запускают проект с той же задачей и получают такой вопрос:
Работая в Я.Толоке я сделал проект по Computer Vision для курса в ШАД. Задача была обучить модель классифицировать автомобильные номера на российские и все остальные.
В этом году мои коллеги запускают проект с той же задачей и получают такой вопрос:
😁32👍6🐳6
# Лихие джуновские 1/2
Расскажу о том, как я был джуном. Это была моя первая фултайм работа. Я устроился full-stack разработчиком в компанию Wroom - агреггатор автосервисов.
Пацаны строили стартап по лучшим практикам:
1. Провентилировать темку (market research)
2. Договориться с кентами из сетей автосервисов (networking)
3. Нанять дешевых фрилансеров склепать имитацию агрегатора (MVP)
4. Построить "аггрегатор", завязанный на девочек на телефоне (гендир отказывался называть их как-то кроме как девочками), которые по запросу клиента гуглят подходящий автосервис (do things that don't scale)
5. Продолжать заниматься обслуживанием машин таксопарков кентов (positive cash-flow from B2B segment)
6. Заметить, что почему-то девочка на телефоне не масштабируется.
7. Нанять свою разработку все разгребать.
6. Продолжать делать все по-старому и закрыться нахер.
План был надежный как швейцарские часы. Наняли CTO. То есть тимлида из Mail.ru, который мечтал влететь в будущий Google и быстренько стать богатым и знаменитым. Назовем его Сергей. Он в свою очередь нанял меня. Назовем меня Борис.
Офис состоял из одной комнаты. Желтые стены, стандартный офисный потолок с квадратными лампами, обшарпанная мебель, которую надо было притащить из съехавшего из сосденего офиса турагентства, винда на компьютерах. Никаких тебе MacBook M1 Pro: для того, чтобы поработать удаленно, надо утащить домой системник и монитор.
Внутри помещались все: "айтишники" (мы), гендиректор (архетипичный кабанчик), исполнительный директор (хипстерского вида мужчина в кашемировом свитере), Аня (head of marketing), Леха (head of B2B sales), колл-центр (от 1 до 3 девушек) и бухгалтер(ша). Стоял постоянный гвалт. Девушки в колл-центре общались с клиентами. Аня-маркетолог орала на них за отклонения от скрипта. Леха вентилировал вопросики. Гендир кричал кому-то в трубку: "Да вы совсем сука охуели там блядь?" У бухгалтерши опять все пропало. Аня разошлась во мнениях с гендиром по поводу качества инфраструктуры (заебала эта старая компьютерная мышь) и ушла, со всей силы хлопнув дверью.
Пока кабанчиковый бизнес процветал, IT бизнес зарождался. "Аггрегатор" представлял из себя сайт с заполненными вручную автосервисами и имитацией активности. У каждого автосервиса был рейтинг, но он формировался не по отзывам пользователей, а просто был записан в базе данных. Ключевым элементом была форма, которая позволяла указать свою машину и требуемые услуги, а в обмен предлагала позвонить в колл-центр. Нам предстояло полностью переписать бекенд, скорее всего переписать фронтенд, организовать деплоймент. Долгосрочная цель: сделать масштабируемую систему интеграций, позволяющую подтягивать списки автосервисов из баз сетей автосервисов. Короче, автоматизировать добавление автосервисов на сайт.
Политическая обстановка была непростая: фрилансеры отдали компании только код фронтенда, а код бекенда оставили на своей стороне. Моей первой задачей было изучить, что за проблема недавно появилась с базой данных. Зашел на сервер, где размещались фронтенд и бд. Увидел всю красоту: деплой руками через загрузку архива, node сервер запущенный в debug режиме, незапороленная MongoDB и порты торчащие в интернет. Мы так и не узнали кто снес бд: школьник, китайский робот-паук или кто-то еще. К счастью у кого-то на компьютере обнаружился "бекап" данных, смогли что-то восстановить.
Фрилансеры очень неохотно помогали мне решить проблему. Я разговорился с ними и подтвердилось то, что я подозревал: они считали, что им не заплатили (lean startup, хуле), поэтому они не отдавали код бекенда, а нас с Сергеем наняли их заменить. Так я узнал, что для гарантированной оплаты труда в этой компании мне нужно иметь сильную переговорную позицию.
Продолжение через 4 часа.
Расскажу о том, как я был джуном. Это была моя первая фултайм работа. Я устроился full-stack разработчиком в компанию Wroom - агреггатор автосервисов.
Пацаны строили стартап по лучшим практикам:
1. Провентилировать темку (market research)
2. Договориться с кентами из сетей автосервисов (networking)
3. Нанять дешевых фрилансеров склепать имитацию агрегатора (MVP)
4. Построить "аггрегатор", завязанный на девочек на телефоне (гендир отказывался называть их как-то кроме как девочками), которые по запросу клиента гуглят подходящий автосервис (do things that don't scale)
5. Продолжать заниматься обслуживанием машин таксопарков кентов (positive cash-flow from B2B segment)
6. Заметить, что почему-то девочка на телефоне не масштабируется.
7. Нанять свою разработку все разгребать.
План был надежный как швейцарские часы. Наняли CTO. То есть тимлида из Mail.ru, который мечтал влететь в будущий Google и быстренько стать богатым и знаменитым. Назовем его Сергей. Он в свою очередь нанял меня. Назовем меня Борис.
Офис состоял из одной комнаты. Желтые стены, стандартный офисный потолок с квадратными лампами, обшарпанная мебель, которую надо было притащить из съехавшего из сосденего офиса турагентства, винда на компьютерах. Никаких тебе MacBook M1 Pro: для того, чтобы поработать удаленно, надо утащить домой системник и монитор.
Внутри помещались все: "айтишники" (мы), гендиректор (архетипичный кабанчик), исполнительный директор (хипстерского вида мужчина в кашемировом свитере), Аня (head of marketing), Леха (head of B2B sales), колл-центр (от 1 до 3 девушек) и бухгалтер(ша). Стоял постоянный гвалт. Девушки в колл-центре общались с клиентами. Аня-маркетолог орала на них за отклонения от скрипта. Леха вентилировал вопросики. Гендир кричал кому-то в трубку: "Да вы совсем сука охуели там блядь?" У бухгалтерши опять все пропало. Аня разошлась во мнениях с гендиром по поводу качества инфраструктуры (заебала эта старая компьютерная мышь) и ушла, со всей силы хлопнув дверью.
Пока кабанчиковый бизнес процветал, IT бизнес зарождался. "Аггрегатор" представлял из себя сайт с заполненными вручную автосервисами и имитацией активности. У каждого автосервиса был рейтинг, но он формировался не по отзывам пользователей, а просто был записан в базе данных. Ключевым элементом была форма, которая позволяла указать свою машину и требуемые услуги, а в обмен предлагала позвонить в колл-центр. Нам предстояло полностью переписать бекенд, скорее всего переписать фронтенд, организовать деплоймент. Долгосрочная цель: сделать масштабируемую систему интеграций, позволяющую подтягивать списки автосервисов из баз сетей автосервисов. Короче, автоматизировать добавление автосервисов на сайт.
Политическая обстановка была непростая: фрилансеры отдали компании только код фронтенда, а код бекенда оставили на своей стороне. Моей первой задачей было изучить, что за проблема недавно появилась с базой данных. Зашел на сервер, где размещались фронтенд и бд. Увидел всю красоту: деплой руками через загрузку архива, node сервер запущенный в debug режиме, незапороленная MongoDB и порты торчащие в интернет. Мы так и не узнали кто снес бд: школьник, китайский робот-паук или кто-то еще. К счастью у кого-то на компьютере обнаружился "бекап" данных, смогли что-то восстановить.
Фрилансеры очень неохотно помогали мне решить проблему. Я разговорился с ними и подтвердилось то, что я подозревал: они считали, что им не заплатили (lean startup, хуле), поэтому они не отдавали код бекенда, а нас с Сергеем наняли их заменить. Так я узнал, что для гарантированной оплаты труда в этой компании мне нужно иметь сильную переговорную позицию.
Продолжение через 4 часа.
🔥66😁14👍5❤1
# Лихие джуновские 2/2
CTO на обедах рассказывал про преимущества Burger Heroes над FARШ и в целом не вписывался в заповедник 90-х. Вскоре я стал краем глаза замечать на экране Сергея hh.ru. Небольшое расследование обнаружило анонимное резюме некого CTO Wroom, который открыт к предложениям. Я вызвал Сергея на приватный разговор. Он был впечатлен моими детективными способностями, признался, что ищет работу, и сказал, что мне тоже надо начинать искать. Я был впечатлен его способностью решать за меня, что мне делать, но покивал и промолчал. Там, где другие видят проблемы, самоуверенный и глуповатый джун видит возможности (которых нет). На тот момент у меня еще волосы не отросли после армии. Я в цирке не просто не смеялся, а мог дирижировать, выступать, продавать билеты, все что угодно. Я был непробиваемый. К тому же не хотелось уходить с работы не поработав даже пары месяцев.
На той же неделе гендир принес в наш офис пару новых компьютеров для колл-центра и поставил CTO задачу "накатить винду". Сергей осведомился, где взять лицензионные ключи, на что генеральный и исполнительный директора от души поржали и сказали ему просто скачать пиратку. Сергей удалился на свое рабочее место. В течение дня постепенно багровел. Чуть после обеда, дойдя до малинового оттенка, он встал, собрал вещи, попрощался со мной, пожав руку дольше обычного, и вышел. Больше его никто не видел. Спустя неделю я получил от него сообщение: "Ты все видел, пиратство это преступление, я не хочу сесть, удачи." Две недели все делали вид, будто отсутствие CTO это само-собой разумеющееся дело. Потом мне сообщили, что Сергей нас некрасиво покинул, и что до появления нового CTO технологиями буду заведовать я. Как я и предполагал, нового CTO не появилось, потому что всех устраивало как я заведывал технологиями.
Спустя день я стер все, написанное мной и Сергеем на его любимом Typescript. К концу недели я перенес данные в PostgreSQL. Фрилансеры так и не вернули нам бекенд, поэтому я написал новый на любимом Flask. Приходилось восстанавливать логику бекенда по запросам от фронтенда. Я покрыл все тестами, сделал миграции, настроил деплой и конфигурацию через Ansible, настроил бекапы бд в Azure. Кабанчиковая часть компании не знала, что означают слова "технический" и "долг" в одном словосочетании, но я все равно писал отличный софт. Потому что мне было лень потом переделывать. Ничего никогда не падало, бекапы накатывались, на серверах был настроен фаервол и уж тем более порты не торчали в интернет. Я был незаменимым сотрудником, поэтому у меня не было таких проблем, как у фрилансеров. Я был настолько священной коровой, что даже пиратскую винду накатывал гендир, а не я. Не жизнь, а сказка, если не считать цирка вокруг.
Невероятно, но компания продолжила заниматься херней, зачем-то оптимизировать конверсии колл-центра, делать баннеры на сайты автосервисов, крыть кого-то хуями по телефону и в целом делать все что угодно кроме масштабируемого продукта. В определенный момент меня перевели на удаленку (системник был тяжелый), затем перевели на статус фрилансера, а затем я ушел и нашел нормальную работу. Wroom больше не существует, а я время от времени захожу посмотреть на linkedin Сергея. Сейчас он Expert Technical Manager with Experience of Leading Teams Up To 200 people.
Ни о чем не жалею. Я отрефлексировал этот ценный опыт, сделал выводы, понял кое-что очень важное и решил:пошло все нахуй, я в machine learning.
CTO на обедах рассказывал про преимущества Burger Heroes над FARШ и в целом не вписывался в заповедник 90-х. Вскоре я стал краем глаза замечать на экране Сергея hh.ru. Небольшое расследование обнаружило анонимное резюме некого CTO Wroom, который открыт к предложениям. Я вызвал Сергея на приватный разговор. Он был впечатлен моими детективными способностями, признался, что ищет работу, и сказал, что мне тоже надо начинать искать. Я был впечатлен его способностью решать за меня, что мне делать, но покивал и промолчал. Там, где другие видят проблемы, самоуверенный и глуповатый джун видит возможности (которых нет). На тот момент у меня еще волосы не отросли после армии. Я в цирке не просто не смеялся, а мог дирижировать, выступать, продавать билеты, все что угодно. Я был непробиваемый. К тому же не хотелось уходить с работы не поработав даже пары месяцев.
На той же неделе гендир принес в наш офис пару новых компьютеров для колл-центра и поставил CTO задачу "накатить винду". Сергей осведомился, где взять лицензионные ключи, на что генеральный и исполнительный директора от души поржали и сказали ему просто скачать пиратку. Сергей удалился на свое рабочее место. В течение дня постепенно багровел. Чуть после обеда, дойдя до малинового оттенка, он встал, собрал вещи, попрощался со мной, пожав руку дольше обычного, и вышел. Больше его никто не видел. Спустя неделю я получил от него сообщение: "Ты все видел, пиратство это преступление, я не хочу сесть, удачи." Две недели все делали вид, будто отсутствие CTO это само-собой разумеющееся дело. Потом мне сообщили, что Сергей нас некрасиво покинул, и что до появления нового CTO технологиями буду заведовать я. Как я и предполагал, нового CTO не появилось, потому что всех устраивало как я заведывал технологиями.
Спустя день я стер все, написанное мной и Сергеем на его любимом Typescript. К концу недели я перенес данные в PostgreSQL. Фрилансеры так и не вернули нам бекенд, поэтому я написал новый на любимом Flask. Приходилось восстанавливать логику бекенда по запросам от фронтенда. Я покрыл все тестами, сделал миграции, настроил деплой и конфигурацию через Ansible, настроил бекапы бд в Azure. Кабанчиковая часть компании не знала, что означают слова "технический" и "долг" в одном словосочетании, но я все равно писал отличный софт. Потому что мне было лень потом переделывать. Ничего никогда не падало, бекапы накатывались, на серверах был настроен фаервол и уж тем более порты не торчали в интернет. Я был незаменимым сотрудником, поэтому у меня не было таких проблем, как у фрилансеров. Я был настолько священной коровой, что даже пиратскую винду накатывал гендир, а не я. Не жизнь, а сказка, если не считать цирка вокруг.
Невероятно, но компания продолжила заниматься херней, зачем-то оптимизировать конверсии колл-центра, делать баннеры на сайты автосервисов, крыть кого-то хуями по телефону и в целом делать все что угодно кроме масштабируемого продукта. В определенный момент меня перевели на удаленку (системник был тяжелый), затем перевели на статус фрилансера, а затем я ушел и нашел нормальную работу. Wroom больше не существует, а я время от времени захожу посмотреть на linkedin Сергея. Сейчас он Expert Technical Manager with Experience of Leading Teams Up To 200 people.
Ни о чем не жалею. Я отрефлексировал этот ценный опыт, сделал выводы, понял кое-что очень важное и решил:
👍55🔥23😁16👎1
Вспомнил еще топ деталь: компания проходила государственный акселлератор, поэтому три раза в неделю весь топ-менеджмент уезжал на обязательные тренинги по продажам, маркетингу и аджайлу.
😁34
Помогу в поиске IT работы в EU/US за 25% от первой зарплаты.
Идея возникла когда я писал серию постов про поиск работы и люди присылали мне резюме. Такая модель помощи очень популярна у консультантов, почему бы не опробовать ее в IT? Для первого эксперимента возьму не более трех человек, посмотрим, что получится.
Если вы читали посты, то знаете про мой подход. Что я могу предложить:
1. Помощь с резюме и презентацией опыта работы.
2. Референсы к знакомым.
3. Пробные собеседования.
4. Помощь в переговорах. Помните как мне помогло послушать умного друга, не вовлеченного в ситуацию?
5. Ощущение, что вы не одни в этом аду.
Дисклеймеры: не могу помочь совсем джунам, не могу помочь с Российским рынком, коучинга не будет, не могу помочь с FNAAG, гарантий нет, но и потерь в случае провала нет.
Алгоритм такой:
1. Пишите мне в лс (@btseytlin), присылайте резюме, кратко опишите, что ищете.
2. Если я не могу вам помочь, то сразу об этом скажу и мы попрощаемся.
3. Созваниваемся, намечаем план работы.
UPD: не удержался, взял пятерых, больше не потяну, сори
Идея возникла когда я писал серию постов про поиск работы и люди присылали мне резюме. Такая модель помощи очень популярна у консультантов, почему бы не опробовать ее в IT? Для первого эксперимента возьму не более трех человек, посмотрим, что получится.
Если вы читали посты, то знаете про мой подход. Что я могу предложить:
1. Помощь с резюме и презентацией опыта работы.
2. Референсы к знакомым.
3. Пробные собеседования.
4. Помощь в переговорах. Помните как мне помогло послушать умного друга, не вовлеченного в ситуацию?
5. Ощущение, что вы не одни в этом аду.
Дисклеймеры: не могу помочь совсем джунам, не могу помочь с Российским рынком, коучинга не будет, не могу помочь с FNAAG, гарантий нет, но и потерь в случае провала нет.
Алгоритм такой:
1. Пишите мне в лс (@btseytlin), присылайте резюме, кратко опишите, что ищете.
2. Если я не могу вам помочь, то сразу об этом скажу и мы попрощаемся.
3. Созваниваемся, намечаем план работы.
UPD: не удержался, взял пятерых, больше не потяну, сори
👍34🔥18😱5😁2
Борис опять pinned «Помогу в поиске IT работы в EU/US за 25% от первой зарплаты. Идея возникла когда я писал серию постов про поиск работы и люди присылали мне резюме. Такая модель помощи очень популярна у консультантов, почему бы не опробовать ее в IT? Для первого эксперимента…»
#лабораторный_журнал
Время закатать рукава и сделать что-то полезное: написать API для базы данных с изображениями.
Больше года не писал API, но я съел на этом столько собак, что код сам вылетает из под пальцев.
Мой любимый сетап:
* DB - PostgreSQL
* ORM - SqlAlchemy
* Миграции - Alembic
* API - Flask
* Сериализация- Marshmallow
* Валидация - covador
* Тесты - Pytest
* Форматирование кода - Black
* Деплой - Nginx + UWSGI, которые общаются по файлу-сокету как описано здесь. Такой сетап работает даже быстрее, чем uvicorn, потому что быстрее NGINX с настроенным кешированием просто некуда.
Разработка ведется через Docker.
Этот надежный как швейцарские часы сетап покрывает все нужды типичной API. При необходимости к нему без труда прикручиваются другие приблуды типа RabbitMQ + Celery для асинхронных тасок.
Есть только одна загадка: зачем нужен Django?
Время закатать рукава и сделать что-то полезное: написать API для базы данных с изображениями.
Больше года не писал API, но я съел на этом столько собак, что код сам вылетает из под пальцев.
Мой любимый сетап:
* DB - PostgreSQL
* ORM - SqlAlchemy
* Миграции - Alembic
* API - Flask
* Сериализация- Marshmallow
* Валидация - covador
* Тесты - Pytest
* Форматирование кода - Black
* Деплой - Nginx + UWSGI, которые общаются по файлу-сокету как описано здесь. Такой сетап работает даже быстрее, чем uvicorn, потому что быстрее NGINX с настроенным кешированием просто некуда.
Разработка ведется через Docker.
docker-compose run —rm —service-ports app bash поднимает локальный postgres, контейнер с приложением, контейнер с NGINX. Код передается в контейнер через volume. Разрабатываешь внутри контейнера, даже никаких venv/poetry/conda не надо - докер обеспечивает environment. Если надо можно подключиться к постгресу любым DB клиентом. Все это целиком повторяет то, как система выглядит в продакшне, поэтому нет проблемы “но на моем компьютере-то работает!” Тесты запускаются в такой же среде, используя реальную тестовую бд. Деплой можно организовать через запуск такого же docker-compose.yml, только с другими параметрами.Этот надежный как швейцарские часы сетап покрывает все нужды типичной API. При необходимости к нему без труда прикручиваются другие приблуды типа RabbitMQ + Celery для асинхронных тасок.
Есть только одна загадка: зачем нужен Django?
👍38🔥8🐳6
Кстати на весь этот сетап можно посмотреть здесь: https://github.com/btseytlin/cowork-19
Здесь еще datadog и sentry до кучи.
Это сайт с резюме и вакансиями, который я сделал в Первый Ковид, чтобы помочь сокращенным друзьям найти работу.
Здесь еще datadog и sentry до кучи.
Это сайт с резюме и вакансиями, который я сделал в Первый Ковид, чтобы помочь сокращенным друзьям найти работу.
GitHub
GitHub - btseytlin/cowork-19
Contribute to btseytlin/cowork-19 development by creating an account on GitHub.
🔥7👍4👎1
Борис опять
Время посмотреть на JPX Tokyo Stock Exchange Prediction, могут ли кагглеры предсказывать рынок?
Хоба, сработала отложка. Посмотрим как там кагглеры предсказали поведение рынков. Приватный лидерборд все еще недоступен, ждем.
👍4👎1
Forwarded from DLStories
В MIT исследовали феномен гроккинга (grokking) и, кажется, нашли этому эффекту правдоводобное объяснение
Grokking — это эффект, при котором уже после стадии переобучения модели (при возрастающем test лоссе и падаюшем train) при дальнейшем обучении test loss вдруг начинает падать, и сеть лучше генерализуется. Такой эффект наблюдали уже давно (например, вот тут), но, чаще всего, на малых, “игрушечных” датасетах (например, на такой простой задаче как сложение чисел). Никакого сильно убедительного объяснения эффекту не было (насколько я знаю), а также не удавалось повторить эффект на реальных, не игрушечных данных.
Ребята из MIT подошли ближе к пониманию природы grokking’а и даже смогли воспроизвести эффект на разных больших датасетах.
Авторы связывают эффект гроккинга с устройством поверхности лосс-функции. В недавней работе из Стенфорда было показано, что у этой поверхности существует сферическая область, в которой достигается оптимальная генерализация модели: то есть, для модели с параметрами из этой области train и test loss малы, переобучения при этом не наблюдается. Эту сферическую область ребята из Стенфорда назвали Goldilocks zone (“зона Златовласки”, показана на картинке зеленым). Так как область сферическая, она соответствует параметрам модели с определенной нормой. Внутренность это сферической области соответствует параметрам с меньшем нормой, область вне сферы — параметрам с большей нормой.
Далее: оказывается, grokking начинает проявляться, если в какой-то момент параметры сети имели большую норму (то есть, соответствовали точке поверхности вне сферы Златовласки). В этом случае параметры из этой точки быстро скатываются в точку локального минимума, которая также чаще всего находится за пределами сферы Златовласки, т.е. вне той области, где достигается оптимальная генерализация модели. Лосс на train становится малым, лосс на test остается большим: наблюдается переобучение.
Далее происходит следующее: если у модели нет никакой регуляризации (weight decay, к примеру), то на этом обучение модели заканчивается. Лосс не выходит из точки минимума, grokking не наблюдается, переобучение остается. Но если к модели применяется регуляризация, это выталкивает веса модели из локального минимума, и они начинают стремиться к зоне Златовласки. Обычно регуляризация применяется не очень сильная, поэтому проходит довольно много эпох обучения, прежде чем веса модели достигают точки внутри зоны Goldilocks и модель начинает генерализоваться. Это и объясняет эффект гроккинга: когда через достаточно долгое время после переобучения лосс на тесте вдруг падает и модель начинает лучше обобщаться.
Кстати, если у модели регуляризация довольно сильная, grokking’а тоже не будет: веса модели будут сразу быстро приходить внутрь зоны Златовласки, не задерживаясь в локальном минимуме вне сферы. Модель просто сразу достаточно хорошо генерализуется.
Теперь, почему grokking часто наблюдают на “игрушечных” датасетах, и почти никогда — на реальных. Во-первых, обычно веса любых нейросетей инициализируют значениями с довольно малой нормой, т.е. лежащими внутри зоны Златовласки. Однако на суперпростых датасетах при обучении модели наблюдается более быстрое увеличение нормы весов, потому что градиентный спуск быстрее выталкивает веса модели в локальную точку минимума трейн лосса сильно за пределами сферы. При обучении больших моделей этот эффект не такой сильный, и веса нечасто выходят за пределы зоны Златовласки вообще, и grokking не наблюдается.
Чтобы подтвердить гипотезу об описанном происхождении гроккина, исследователи обучили несколько моделей для разных задач CV и NLP с разными нормами весов. Оказалось, что увеличение нормы весов действительно приводит к возникновению эффекта grokking’а, пусть все же и не настолько выраженно, как на более простых датасетах.
Подробнее читайте в статье
Изначально новость нашла тут
Grokking — это эффект, при котором уже после стадии переобучения модели (при возрастающем test лоссе и падаюшем train) при дальнейшем обучении test loss вдруг начинает падать, и сеть лучше генерализуется. Такой эффект наблюдали уже давно (например, вот тут), но, чаще всего, на малых, “игрушечных” датасетах (например, на такой простой задаче как сложение чисел). Никакого сильно убедительного объяснения эффекту не было (насколько я знаю), а также не удавалось повторить эффект на реальных, не игрушечных данных.
Ребята из MIT подошли ближе к пониманию природы grokking’а и даже смогли воспроизвести эффект на разных больших датасетах.
Авторы связывают эффект гроккинга с устройством поверхности лосс-функции. В недавней работе из Стенфорда было показано, что у этой поверхности существует сферическая область, в которой достигается оптимальная генерализация модели: то есть, для модели с параметрами из этой области train и test loss малы, переобучения при этом не наблюдается. Эту сферическую область ребята из Стенфорда назвали Goldilocks zone (“зона Златовласки”, показана на картинке зеленым). Так как область сферическая, она соответствует параметрам модели с определенной нормой. Внутренность это сферической области соответствует параметрам с меньшем нормой, область вне сферы — параметрам с большей нормой.
Далее: оказывается, grokking начинает проявляться, если в какой-то момент параметры сети имели большую норму (то есть, соответствовали точке поверхности вне сферы Златовласки). В этом случае параметры из этой точки быстро скатываются в точку локального минимума, которая также чаще всего находится за пределами сферы Златовласки, т.е. вне той области, где достигается оптимальная генерализация модели. Лосс на train становится малым, лосс на test остается большим: наблюдается переобучение.
Далее происходит следующее: если у модели нет никакой регуляризации (weight decay, к примеру), то на этом обучение модели заканчивается. Лосс не выходит из точки минимума, grokking не наблюдается, переобучение остается. Но если к модели применяется регуляризация, это выталкивает веса модели из локального минимума, и они начинают стремиться к зоне Златовласки. Обычно регуляризация применяется не очень сильная, поэтому проходит довольно много эпох обучения, прежде чем веса модели достигают точки внутри зоны Goldilocks и модель начинает генерализоваться. Это и объясняет эффект гроккинга: когда через достаточно долгое время после переобучения лосс на тесте вдруг падает и модель начинает лучше обобщаться.
Кстати, если у модели регуляризация довольно сильная, grokking’а тоже не будет: веса модели будут сразу быстро приходить внутрь зоны Златовласки, не задерживаясь в локальном минимуме вне сферы. Модель просто сразу достаточно хорошо генерализуется.
Теперь, почему grokking часто наблюдают на “игрушечных” датасетах, и почти никогда — на реальных. Во-первых, обычно веса любых нейросетей инициализируют значениями с довольно малой нормой, т.е. лежащими внутри зоны Златовласки. Однако на суперпростых датасетах при обучении модели наблюдается более быстрое увеличение нормы весов, потому что градиентный спуск быстрее выталкивает веса модели в локальную точку минимума трейн лосса сильно за пределами сферы. При обучении больших моделей этот эффект не такой сильный, и веса нечасто выходят за пределы зоны Златовласки вообще, и grokking не наблюдается.
Чтобы подтвердить гипотезу об описанном происхождении гроккина, исследователи обучили несколько моделей для разных задач CV и NLP с разными нормами весов. Оказалось, что увеличение нормы весов действительно приводит к возникновению эффекта grokking’а, пусть все же и не настолько выраженно, как на более простых датасетах.
Подробнее читайте в статье
Изначально новость нашла тут
🔥22👍5😱1
Forwarded from Empty Set of Ideas
полезная картинка, раньше я всегда просто пользовался пиклом, теперь буду брать npy или npz для спарсных данных
https://github.com/mverleg/array_storage_benchmark
https://github.com/mverleg/array_storage_benchmark
🔥13👍6
Борис опять
Сейчас идет другое похожее соревнование про предсказание стонксов, где метрика больше про заработанные деньги. Проверка будет так же осуществляться на реальных рыночных данных. Сейчас заработок скор решения 317527.084. В октябре посмотрим, что будет при столкновении…
Результаты соревнования финализированы. Кагглеры должны были предсказывать цены стоков на день вперед. Модели тестировались на реальных рыночных данных в течение 3 месяцев.
Для меня было интересно понять, предсказуемы ли рынки. Кагглеры способны предсказать все, что предсказуемо, так что если они сделают модель, обгоняющую индексы, значит рынки неэффективны и предсказуемы. Я лично считаю, что массовые рынки непредсказуемы, так что это был способ проверить мое мнение.
Так вот, изучив результаты соревнования, я могу уверенно заявить: хрен его знает, вообще ничего не понятно.
Я сломал себе мозг пытаясь понять, как считается скор соревнования и как его перевести в термины “сколько бабла на этом можно заработать или потерять.” У меня не получилось. Если вы готовы забуриться в задротство, то в следующем посте разбор метрики.
Для меня было интересно понять, предсказуемы ли рынки. Кагглеры способны предсказать все, что предсказуемо, так что если они сделают модель, обгоняющую индексы, значит рынки неэффективны и предсказуемы. Я лично считаю, что массовые рынки непредсказуемы, так что это был способ проверить мое мнение.
Так вот, изучив результаты соревнования, я могу уверенно заявить: хрен его знает, вообще ничего не понятно.
Я сломал себе мозг пытаясь понять, как считается скор соревнования и как его перевести в термины “сколько бабла на этом можно заработать или потерять.” У меня не получилось. Если вы готовы забуриться в задротство, то в следующем посте разбор метрики.
👍22🔥2