В эфире снова моя любимая рубрика "Критика нейросетей". На этот раз под раздачу попали сервисы по колоризации, увеличение разрешения и подобным улучшениям картинки.

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

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

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

Automatic image colorization consists in adding colors to a new greyscale image without any user intervention. The problem, stated like this, is ill-posed, in the sense that one cannot guess the colors to assign to a greyscale image without any prior knowledge. Indeed, many objects can have different colors: not only artificial, plastic objects can have random colors, but natural objects like tree leaves can have various nuances of green and turn brown during autumn, without a significant change of shape.

Automatic Image Colorization via Multimodal Predictions, 2008 год. Наверняка писали и раньше, но мне лень искать глубже.

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

На небе только и разговоров, что о коронавирусе…

COVID-19 стал идеальной темой для всяких праздных разговоров - за обедом, на вечеринке, в чатике друзей. У темы есть множество ответвлений - можно поговорить о политике (действительно ли авторитарные режимы лучше справляются с карантином?), об экономике (рынки волатильны, фабрики частично простаивают), о работе из дома и многом другом.

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

А если вы не любите всякую заумь, зато предпочитаете мыслить глобально, то наверняка уже читали Coronavirus: The Black Swan of 2020 от Sequoia Capital.

Наконец-то дочитал Code Complete by Steve McConnell. Эта книга входит в кучу списков с пафосными заголовками типа Top N Books Every Software Engineer Should Have Read. Забегая вперед: думаю, что не зря.

На чтение ушло добрых полгода. По трем причинам: книга большая, не особенно захватывающая, если не сказать, что местами занудная, и, наконец, я ее читал преимущественно в поездах и самолетах.

Книга написана в 1993, хоть и значительно дополнена перед вторым изданием (2004 год). Это накладывает определенный отпечаток: книги про программирование обычно лежат на спектре от “вечная классика, будет актуальна еще долго” (например, Introduction to Algorithms Кормена и компании) до “устаревает после выхода новой мажорной версии хипстерского фреймворка”. Code Complete - книга про хорошие software engineering практики, потому она лежит где-то на середине этого спектра. Как следствие, кое-что уже слегка устарело по нынешней моде.

Некоторые идеи кажутся банальностями за авторством Капитана Очевидность. Некоторые главы хочется вызывают ощущение “дед опять забыл выпить таблетки” (например, долгие витиеватые рассуждения, что в современных языках лучше не использовать goto, но иногда все-таки можно). Кстати, о языках: в примерах используется C++, Java и Visual Basic (!) - я даже забыл о существовании последнего. И несмотря на это, в оставшемся материале много актуального по сей день - о проектировании, тулинге, тестировании, дебаггинге и т.п.

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

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

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

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

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

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

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

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

Кстати, это хороший пример продукта для той самой "цифровой трансформации", менее очевидного и потенциально более полезного, чем just another project management SaaS.

К чему может привести избыток свободного времени в карантине: vim cubed.

Кстати, код настолько компактен и читабелен, что прям самому хочется что-нибудь написать на Nim. Делать этого я, конечно, не буду.

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

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

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

Отдельно добавлю, что внедрять CI до написания тестов - это телега впереди лошади 🐴

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

Хороший пример такого безумия с уклоном в нашу профессиональную сферу обнаружился на Реддите, хотя я бы не удивился увидеть такое на ebanoe.it.

Когда программисты видят, что в интернете кто-то не прав.

TL;DR: "В этом вашем академическом проекте нет нормальных тестов, потому давайте считать невалидными все результаты, полученные на базе этого проекта".

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

Оказалось, что я заметил только верхушку айсберга. Но нашелся менее ленивый и более компетентный человек, который разобрал эту историю детальнее: Code Review of Ferguson’s Model и Second Analysis of Ferguson’s Model.

Why we at $FAMOUS_COMPANY Switched to $HYPED_TECHNOLOGY

История n% технологических миграций и шаблон для k% статей на hackernews

Заметил, что айтишников можно разделить на классы почти также, как в классических РПГ.

Lawful Good - Я написал юниттесты, прогнал их у себя, провел с соседом ревью, убедился, что покрытие тестов полное, прогнал интеграционные тесты, закоммитил код, помог товарищу, протер стол, навел порядок у соседа - пойду-ка я обновлю документацию!

Lawful Neutral - тэксь, код соответствует гайдлайнам, юниттесты есть, прекоммит процедуру прогнали - можно и по чайку. Баг? Ну ок, баг. Ща допью только.

Lawful Evil - Код спеке соответствует? Соответствует. Подтверждающие это тесты есть? Есть. Ревью пройдено? Пройдено. Не работает? Идите в жопу.

Neutral Good - Вообще, эти две либы вместе нормально не работают. Но я придумал шикарный костыль...

True Neutral - Глобальные переменные - зло? Зло. Паттерн "обсервер" добро? Добро. Вот и держите оба в одном коммите, как раз норм.

Neutral Evil - Заказчики - пидоры, команда - пидоры, один я тут солнышко!

Chaotic Good - Мужики! Я тут на последний рилиз глобальный код ревью сделал, 255 комментов написал! Что значит "кто такой"? Я в соседней конторе работаю. Сантехником. В говне копаюсь. А тут ваш код нашел - такой интересный!

Chaotic Neutral - Кто играл в "викингов" и смотрел видосики целый день, я? Ну и что, важна эффективность! Смотри, чо написал!

Chaotic Evil - пока вы спали, я все спортировал на линукс и постгре, сменил облачного провайдера, доменное имя и офис-менеджера. Зачем? Но ведь так наш код будет на 1.5% эффективнее!

Карантин заставил большое количество людей и компаний впервые попробовать удаленку, что спровоцировало вал статей в духе "Как мы успешно практикуем удаленную работу". Большая часть этих людей практикует эту самую удаленку 1-2 месяца, но разве это преграда для того, чтобы делиться мудростью?

Мне эта задача досталась в усложненном варианте со звездочкой: за день до объявления локдауна в Калифорнии я улетел обратно в Минск, а потому последние пару месяцев работаю удаленно (что для меня совсем не в новинку), с десятичасовой разницей во времени (такое тоже бывало), будучи единственным человеком в команде в этом или близком часовом поясе (а это уже что-то новенькое).

Вместо того, чтобы делиться инновационными подходами (у меня их нет), расскажу о впечатлениях.
TL;DR: это охуенно!

Чтобы это работало, нужно соблюдать некоторые требования:
- "одинокий" человек должен обладать некоторым уровнем ответственности и следить за тем, чтобы не оказаться так или иначе заблокированным в начале своего рабочего дня - без задач, нужных доступов, ответов на ключевые вопросы и т.п.;
- остальная команда по какой-то причине (например, культура здорового уважения в компании, или повышенный окситоцин) должна быть склонна к сотрудничеству ("ок, давайте попробуем по возможности начинать митинги пораньше");
- все участники забега должны уметь в среднесрочное планирование и назначать важные обсуждения слегка заранее (стремиться назначать митинги не на "через час", а хотя бы на следующий день).
- митингов должно быть не фатально много (ежедневные обязательные стендапы в вечернее время слегка утомляют, но когда их всего 2-3 в неделю, совершенно не доставляют проблем).

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

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

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

Неплохая иллюстрация к притче о том, что надо вовремя точить пилу, а не только бесперебойно пилить фичи.

Самый оригинальный заход рекрутера за последнее время:

If you’re not looking but know someone who may be interested please do pass on my contacts - we plant 5 trees in your name for every introduction.

🌳🌲🌳🌲🌳

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

Google выложил свой аналог еще три месяца назад. Впрочем, в Snap-линзе побольше фичей (например, есть occlusions), да и сделать на ее основе что-то свое, кажется, проще.

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

Постепенное снятие карантинов порождает новый холивар: может ли компания оставаться на удаленке навсегда и оставаться продуктивной. С одной стороны кричат "все пробовали fully remote, и никто толком не смог!", с другой - тыкают примерами Gitlab, Basecamp и прочих HashiCorp.

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

P.S. Еще вспомнился такой актуальный в наше время комикc от Oatmeal.

Узнал новое для себя слово HARKing - hypothesizing after the results are known. Иными словами, подгонять задачу под ответ.

Наткнулся на это слово в отличной статье HARK Side of Deep Learning - From Grad Student Descent to Automated Machine Learning, в которой авторы критикуют современные проблемы академического ML ресерча вроде отсутствия воспроизводимости или мнимой генерализации (авторы прикручивают трюки, чтобы побить метрику на популярном датасете, но эти трюки оказываются бесполезны вне этого датасета).

---

Вообще, HARKing свойственен далеко не только академическому миру - в бизнесах этого не меньше.

Слабые маркетологи объясняют локальные успехи флуктуации своими кампаниями, плохие продакт-менеджеры репортят наверх результаты некорректно посчитанных A/B тестов, премии выдаются, почти все счастливы. Даже если босс знает словосочетание "статистическая значимость" по книжке "Статистика для успешных менеджеров", метод "сделать 20+ A/B тестов без поправки Бонферрони и найти ложноположительный результат" в целом работает.

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

Я в меру интересуюсь темой беспилотных автомобилей (с удовольствием катался и посещал тематический митап Яндекса, но за новостями не слежу). Но выступление Андрея Карпатого с последнего CVPR не мог не посмотреть - он отличный спикер, на его лекциях с CS231n выросло немало CV инженеров, включая меня.

Как и любой человек, склонный к confirmation bias, я вынес такие основные тезисы:
- маленькая R&D команда с хорошей инфраструктурой лучше, чем толпа R&D чуваков без инфраструктуры;
- если что-то можно выучить end-to-end вместо эвристик поверх сырых данных (или результатов моделей попроще), это надо делать;
- метрики - это новые юнит-тесты (при этом важно покрыть метриками все кейсы, а не выдрачивать одно число);
- алгоритм подбора новых семплов для обучения и прочий active learning важны.

Люблю хвастаться багами, которые сам же и сделал.

Недавно я обновил одну AWS Lambda функцию, которая делала инференс некой модели. И, внезапно, скорость выполнения просела вдвое.

Расследование показало, что виноват пулл реквест с рефакторингом, который состоял из кучи тестов и двух строк в основном коде. Одна из строк была довольно безобидной на вид, вроде logger.info('Loading model from {}'.format(model_weights)).

Если копнуть чуть глубже, оказалось, что конструктор модели был примерно таким:

class Model:
    def __init__(self,
                 model_weights: Union[str, BytesIO],
                 ...
                 )

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