Меня начала раздражать малорелевантная реклама на Youtube, и потому я полез смотреть, что там Google нахимичил в определении моих интересов. Если кто не в курсе, по этой ссылке можно найти список ваших интересов и прочих атрибутов, используемый в таргетинге.

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

- Age. На работе мне 18-44, а вне работы - гораздо точнее, 25-34 (на самом деле мне 31);
- Education status. На работе у меня как будто "Bachelor's Degree", а вне работы - Advanced Degree (на самом деле меня отчислили со второго курса). Кажется, это сигнал, что можно быть поамбициознее в работе!
- Marital status. "Старый" аккаунт все еще считает, что я married, а новый - что я in a relationship (как будто старый аккаунт давно не пересчитывал фичи!)
- Rental status. Оба аккаунта сходятся в том, что я renter, т.е. мою квартиру в Минске как будто недвижимостью назвать сложно :(
- Относительно узкие профессиональные интересы типа Machine Learning and Artificial Intelligence и Distributed & Cloud Computing есть в основном аккаунте, но отсутствуют в рабочем. Наверное, это следствие того, что я стал реже гуглить всякое типа deep learning for dummies.

Оба аккаунта ожидаемо достаточно хорошо поняли, что я работаю в Technology Industry, интересуюсь компьютерами, нон-фикшеном, экономикой, видеоиграми и жратвой.

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

Извините, это пост затрагивает две чрезмерно захайпованные темы - политику и COVID-19. Хотя вообще он про анализ данных.

Некий председатель комитета по здравоохранению сегодня сказал дословно следующее:
Начиная с 21−22 августа, регистрируем рост заболеваемости COVID-19. Инкубационный период у коронавирусной инфекции в среднем две недели. Во второй декаде августа в городе стали проходить массовые акции. А любые массовые мероприятия способствуют распространению коронавируса — не соблюдается социальное дистанцирование.

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

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

Очевидно, что инкубационный период - это не одно число, а какое-то распределение: у кого-то из зараженных симптомы проявятся раньше, у кого-то - позже. Не менее очевидно, что карантин служит для того, чтобы у подавляющего большинства потенциально зараженных успели проявиться симптомы. Если, например, половина зараженных выйдут из карантина, имея высокую вероятность заболеть в следующие дни, карантин не имеет никакого смысла. Следовательно, срок карантина должен покрывать большую часть распределения, т.е. заканчиваться в районе 95..99 перцентиля.

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

Хватит гадать, пойдем читать интернет. Запрос "covid-19 incubation period distribution" приводит нас к такой картинке с плотностью вероятности. Очевидно, что по всем исследования среднее такого распределения не может находиться в районе 14 дней. А для тех, кто сомневается в своей способности читать графики, можно найти прямое пояснение от ВОЗ:

The incubation period of COVID-19, which is the time between exposure to the virus and symptom onset, is on average 5-6 days, but can be as long as 14 days.

Q.E.D. Вышеупомянутый чиновник не только не знает важные факты по своей специальности, но и не замечает, как его слова не выдерживают проверку здравым смыслом.

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

Почему в 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.