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

У людей, которые что-то сделали, периодически возникает необходимость об этом рассказать — в статье, презентации, в обычном человеческом разговоре. В этот момент у них часто можно наблюдать любопытные симптомы своеобразного синдрома самозванца: они считают, что в их работе нет ровным счётом ничего интересного, сделать её мог вообще кто угодно, а поэтому зачем, собственно, о ней рассказывать? Лучше и не рассказывать вовсе.

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

1. Fabrizio Sebastiani. Machine Learning in Automated Text Categorization, 2002 год. Важнейшая работа для тех, кто занимался классификацией текстов в нулевых. Работа обзорная, из неё можно узнать: какие встречаются постановки задач и наборы данных; какие известны методы; каким образом эти методы исследуются, какие метрики являются общепринятыми; каковы результаты сравнения всех этих методов на известных наборах данных; какие основные работы по теме написаны, что нужно читать дальше, если хочется углубиться.
2. Christopher J.C. Burges. From RankNet to LambdaRank to LambdaMART: An Overview, 2010 год. А это — одна из важных работ для тех, кто занимается обучением ранжированию. Тут излагается теория, лежащая в основе знаменитых алгоритмов; некоторые алгоритмические трюки для ускорения вычислений; причины, по которым эти алгоритмы можно считать эффективными.

Что нового изобрели авторы в этих работах? Ничего! Полезны ли эти работы? Разумеется!

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

Поэтому делитесь своими знаниями, добытыми долгим трудом. Если вы «всего лишь» потратили кучу времени на то, чтобы что-то понять — вы можете сэкономить эту кучу времени другим людям, если поделитесь результатами своих изысканий. Не страшно, что в процессе вы не изобрели ничего, что сами считали бы новым или прорывным. Иногда даже простое знание о том, что определённый способ что-то сделать сработал, очень помогает.

Алексей Шаграев

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

Как после этого можно всерьез утверждать, что ML инженерам можно не знать математику?

15 лет назад мы с пацанами по соседству потратили месяц и все карманные деньги, чтобы соединить три компьютера из одного подъезда. Благодаря этому, мы могли скачивать друг у друга такие ценные файлы, как, например, смешные видеоролики. Это казалось практически чудом - раньше, чтобы пополнить свою коллекцию, нужно было доставать из компьютера жесткий диск и идти в гости. Отдельной заботой был ответ на сложный вопрос "а места на диске хватит?".

Сейчас, лежа на кровати в Калифорнии, я захожу по SSH на компьютер в Беларуси через сервер в Орегоне, который тысячами скачивает видео с нескольких CDNов и складывает на копеечный жесткий диск, чтобы потом скормить нейросети. И этот пайплайн вовсе не кажется удивительным: запустить это все - задача примерно того же уровня сложности, как приготовление завтрака.

Примерно такие сравнения приходят на ум, когда кто-то начинает канючить "в этих ваших кампьюктерах никакого прогресса".

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

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

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

Нейросети, конечно, не при чем. Каждый, кто занимался задачей колоризации или хотя бы думал о ней больше 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), да и сделать на ее основе что-то свое, кажется, проще.