Почему в software engineering так сложно с оценками сроков? Потому что зачастую практически невозможно на глазок оценить глубины кроличьей норы, если речь идет о чем-то сложнее перекраски кнопки на лендинге.

Вот небольшой пример. Есть сервис на питоне, в котором некоторые запросы начали тормозить. Хочется найти эти запросы, для этого - добавить в логи какой-то request_id.

Но в мире асинхронного питона нельзя просто хранить какой-то id на уровне треде, т.к. тред может переключаться между запросами в процессе await, нужно использовать ContextVars. Чтобы прикрутить ContextVars, нужен Python 3.7+, нужно обновиться. В процессе обновления выясняется, что некоторая старая версия библиотеки официально не поддерживает новый питон, нужно собрать ее руками. Методом проб и ошибок находим коммит, с которого собиралась старая версия для старого питона, собираем для нового питона - результаты не сходятся, тесты падают!

Для начала нужно собрать минимальный воспроизводимый пример (в моем случае получился Dockerfile на 50 строк и примерно столько же Python-кода). Разбираем билд и видим, что библиотеке нужен с десяток shared зависимостей, для которых не всегда указаны версии. Можно найти какие-то древние логи на CI-сервере, который собирал библиотеку для старого питона, и из них достать какие-то куски информации. Их не хватает, и версии приходится перебирать бинарным поиском. Версии подобраны, они конфликтуют друг с другом, и склеить их вместе можно только странным перебором apt install ... && apt remove ... && apt install.

На все эти развлечения ушло уже три дня, и я не могу сказать, что приблизился к заветным request_id. А ведь сторонний наблюдатель с навыками эффективного менеджера вполне мог бы возмутиться: "че там делать вообще? завел переменную и клади в лог, делов-то".

Рубрика "Бесполезные находки": оказывается, существует unicode-символ "Больше или равно или меньше или равно" ⋚.

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

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

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

Здесь могла быть классическая картинка про многопоточность.

Один мой кореш (кстати, автор канала @autopilot_disengaged) недавно осваивал Haskell, и по этому поводу мы устроили дискуссию на одну из вечных холиварных тем: действительно ли функциональное программирование прочищает мозги и заставляет впоследствии писать менее грязный код? Естественно, к общему знаменателю мы так и не пришли, но я сформулировал некоторый тезис.

Кажется, что распределение плохого кода бимодально.

Одна мода - натурально говнокод, написанный недалекими программистами. Это ребята, которые не умеют в абстрактное мышление, постоянно копипастят, не знают базовые алгоритмы, не могут осилить более сложные фичи языка, чем if и for. Так вот, если их бить монадами по ебалу заставлять писать композиции функций поверх иммутабельных коллекций вместо беспорядочного ковыряния глобального стейта, зачастую их код становится лучше. (И тут я вспоминаю, как некий map-reduce фреймворк в Яндексе выпрямлял мои собственные руки).

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

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

Так вот, я периодически ныл пацанам, что за последний год не сделал ничего технически интересного. Никакого тебе state of the art, обмазывание старых моделей новыми эвристиками, кругом самоповтор. Но недавно осознал, что вообще-то кое в чем я поднатаскался: just make it work. Собирать древние версии библиотек в окружениях, совершенно не поддерживаемых с точки мейнтейнеров этих библиотек, по кускам наводить порядок, обеспечивая вопроизводимость с точностью до 1e-5, манкипатчами дебажить мистические баги, воспроизводимые только в продакшене...

Последний баг, с которым я возился, был связан с многопоточностью: некая операция запускается в отдельном треде. Расследование показало, что там она на уровне библиотек пытается раскидать свои сабфункции по новым тредам, а каждая сабфункция внутри дергает низкоуровневые OpenBLAS API, которые - сюрприз-сюрприз - в неявном виде тоже могут использовать многопоточность. Иными словами, на море на океане есть остров, на том острове дуб стоит, под дубом сундук зарыт, в сундуке — заяц, в зайце — утка, в утке — яйцо, в яйце игла — смерть Кощея микросервиса.

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

(Картинка для привлечения внимания)

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

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

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

Что важнее, GANы более или менее поехали в прод, и не только в узкоспециализированных стартапах. Из относительно простых примеров - DeepHD Яндекса, которому примерно два года. Сложно сказать, как давно GANы появились в эффектах Snapchat, но явно не меньше года. Наконец, относительно свежий релиз платформы для видеозвонков от NVidia (кстати, они собирают и развивают прям серьезную экспертизу в этой нише, что неудивительно: с одной стороны, массовое распространение ганов может стать еще одним драйвером роста для видеокарт, с другой - у них есть ресурсы для экспериментов).

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

Если этот пост вызвал у вас fear of missing out, посмотрите на эту специализацию. Сам я, конечно, ее еще не прошел, но syllabus выглядит неплохо.

Я закончил прошлый пост фразой про fear of missing out, а на этих выходных FOMO накрыл и меня, и захотелось слегка разобраться, в чем суть трансформеров, почему про них все говорят и действительно ли они значимы за пределами мира NLP (TL;DR - скорее да).

Если вам тоже любопытно потратить пару-тройку часов на ознакомление, очень рекомендую два выступления Григория Сапунова: https://www.youtube.com/watch?v=KZ9NXYcXVBY и https://www.youtube.com/watch?v=7e4LxIVENZA. Они очень обзорные - от самой идеи трансформера до свежих трюков по разным направлениям, все обильно приправлено ссылками. В общем, хорошая точка входа.

Опубликовал на Хабре статью по мотивам своего последнего выступления на Дата Фесте. Это обзор, цель которого - слегка сориентировать всех тех людей, которые регулярно задают вопросы вида "как в 2020 делают наложение маски на лица в видео?"

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

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

Более того, это все применимо не только к менеджерам, но и к individual contributors. В компаниях, где процессы поощряют героизм, бывают прецеденты, когда инженер в одно лицо делает что-то классное, получает свою долю славы и материальных ништяков, но поддерживать этот код решительно невозможно. И хорошо, если герой остался и его сакральные знания можно использовать для спасения проекта.

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

See also: почему героизм в инженерных организациях - это не ок.

С удовольствием прочитал The Phoenix Project.

Такой жанр по-английски обычно называют business fable, впрочем, что-то в нем есть и от производственного романа. Что-то среднее между популярными The Goal Голдратта и The Deadline ДеМарко.

Так или иначе, это история менеджера, который вычищает авгиевы конюшни IT operations в некой большой вымышленной нетехнологической компании, наступает на грабли, но благодаря deus ex machina строит дивный новый мир, соответствующий канонам devops-культуры. Половину книги протагонист тушит пожары на продакшене и пытается соорудить что-то, их предотвращающее. Окружение - классический энтерпрайз - изо всех сил этому сопротивляется.

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

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

Минутка диплернинга.

Сколько-то интересуюсь темой self-supervised learning в компьютерном зрении. Раньше ее называли просто unsupervised, а потом стали выделять в отдельную подзадачу; на пальцах задача выглядит так: "как получить такие representations, которые улучшат качество конечной модели (например, классификации), за счет неразмеченных данных". Последние пару лет там появилось много прорывных работ (SimCLR, MoCo, BYOL, SwAV...), эксплуатирующих contrastive learning подход, а до этого исследователи в основном пытались придумать такую остроумную задачу, которой не нужна дополнительная разметка. Обзор по теме.

Рядом с этой задачей стоят попытки использовать в обучении синтетические (обычно рендеренные) данные, и чаще всего это не работает в лоб - выученные представления плохо обобщаются на реальные данные без отдельных, довольно сложных трюков (см. domain adaptaion).

И вот сегодня я впечатлился статьей, авторы которой замахнулись на некую смесь этих задач - "как эффективно предтренировывать сеть вообще без реальных данных?". TL;DR: авторы сгенерировали разнообразный датасет фракталов 🌿, учатся на них и доучиваются на основной задаче. Конечно, пока не state of the art (но и совсем не плохо) в плане метрик, зато полет мысли прекрасен.

Пишите в комментариях, какие статьи про self-supervised learning и около того, впечатлили вас в последнее время!

Главный скандал недели в околоML тусовке - это, конечно, увольнение Timnit Gebru из Google за неавторизованную публикацию статьи на тему ethical AI.

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

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

Достаточно нейтральное изложение событий можно почитать на MIT Tech Review. И отдельно отмечу этот прекрасный комментарий.

Рубрика "Нифига себе как бывает": фреймворк для multi-animal body part position estimation. Особенно доставляют анимированные маски ползающих мух.

Задумался, каково живется в современном мире людям, далеким от технологий, и кажется, что им можно посочувствовать.

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

Указание неместного телефонного номера может поместить заказ в некий лимб - он будет висеть в статусе "в обработке" примерно вечно. Кнопки "переключить язык" на сайтах часто ведут на главную страницу, и оказывается, что нужная фича в принципе недоступна на неосновном языке. Платежи с неместных карточек могут проходить или не проходить, и узнать об их судьбе можно только вооружившись dev консолью в браузере. Типичное сообщение об ошибке выглядит как "Something went wrong; please try again".

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

Свежая работа OpenAI по генерации картинок лично меня впечатляет даже больше, чем та самая GPT-3.

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

Важный скилл, который зачастую отличает зрелых senior инженеров от зеленых щеглов, - умение мыслить в problem space, а не solution space. Разобраться в проблеме на достаточном уровне, а не пойти сразу чинить (чем попало).

Например, недавно в одном чатике наблюдал, как один разработчик начал жаловаться, что его БД не справляется с нагрузкой, а тамошние "галерные сеньоры" наперебой начали советовать добавить индексов, перейти на MongoDB и запустить еще инстансов в облаке, не удосужившись разобраться, что именно у него тормозит и почему.

Казалось бы, это слишком очевидно. Но на самом деле, за собой нужно следить, чтобы случайно не попасть в эту ловушку из-за когнитивного искажения. Я недавно слегка облажался в таком ключе.

Итак, за два дня до нового года я обновлял большой кусок инфраструктуры - рантайм в AWS Lambda, несколько хитро собранных библиотек, в общем, дело обещало быть хрупким. Потому, когда мониторинг начал ругаться на таймауты, я пожалел дежурного по проду, все откатил и пошел за мандаринами.

Уже в этом году первым делом устроил суровое нагрузочное тестирование, которое показало неожиданное: новые лямбды ничем не отличаются от старых по latency и подобным метрикам. Новый деплой, новые таймауты, новый rollback. Наконец, более внимательное изучение логов показало, что таймауты и деплои никак не связаны, обновление ничего не ухудшило. Просто так совпало - примерно в то же время один из сервисов-пользователей изменил профиль нагрузки и начал иногда отправлять тяжелые (примерно в 10 раз тяжелее) запросы.

Отличная обзорная статья об автоматизации программирования: от автодополнения до генерации тестов. Автор работает в JetBrains, а потому явно понимает, о чем говорит, но при этом не зацикливается на инструментах, которые уже есть в их IDE.

Для расширения кругозора я иногда отвечаю на Linkedin-приглашения поговорить от рекрутеров и стартаперов. В 2021 поговорил с двумя, и оба разговора получились едва ли не образцом того, что такое хорошо и что такое плохо.

Хорошо:

Компания пилит open source продукт с надеждой продавать коммерческую версию. Рекрутер обнаружил, что я лайкнул их репозиторий и написал мне. Рассказал про продукт и планы, команду и ожидания от нанимаемых инженеров. Сразу честно обозначил зарплатную вилку (не очень большую) и опцию выбора между берлинским офисом и удаленкой. В качестве тестового задания предложил сделать PR в их репозиторий. Конечно, тут лень победила любопытство, и на этом мы распрощались, но впечатления остались положительными.

Плохо:

Харизматичный CEO небольшого стартапа из Калифорнии написал в Linkedin, кое-как назначил звонок, на котором усердно питчил продукт, хвастался вооот такими перспективами рынка AR-рекламы и неумело льстил "Arseny, we need people with great CS education as you have!". И только после этого прислал tech job denoscription, составленный техлидом из одной гордой восточноевропейской страны; тут всплыло, что от computer vision инженера они в первую очередь ожидают глубокого знания JavaScript и браузерных API 🤦‍♂️

Не претендую на объективность, но есть ощущение, что в последние год-два академический ML-код стал значительно лучше и приблизился к production-ready качеству.

Еще недавно было нормальным или не выкладывать код к статье, или выкладывать жуткое поделие, хоть как-то запустить которое было серьезным вызовом. Эзотерические фреймворки, неуказанные зависимости, неочевидные форматы датасетов, слабовоспроизводимые результаты.

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

В общем, https://paperswithcode.com/ делает для индустрии очень много.

мне подсказывают, что в этом тоже может быть заслуга алгоритмов, а не людей (на самом деле, пока, конечно, нет)

https://twitter.com/GuillaumeLample/status/1361663915072118784