Ужасный дизайн

Очень часто слышал в комьюнити плюсовиков что "вот, в С++ есть много мест, где плохой дизайн, ужасный язык" и т.д 😔. Я всегда думал: ну вроде неплохо.. Но вот и меня настиг ужасный дизайн 😮!

В общем-то задачка простая: в хэш-таблицу нужно класть std::string_view без учета их регистров, т.е. строки "ужасный дизайн" и "УжАсНыЙ дИзАйН" — это одинаковые строки.

std::string_view — это некоторый наблюдатель строки. Представьте что вы в окно смотрите на машину. Тогда вы будете car_view 😂. По сути вы ничего не можете сделать с самим автомобилем, но вы можете зашторить часть окна и часть машины пропадет из вашего вида, но при этом с самим автомобилем ничего не будет. std::string_view предоставляет нам интерфейс, чтобы без копирований наблюдать за строкой.

🙏 Самый простой вариант решить задачу — будем создавать копию строк, меняя в них регистры букв на один из вариантов: заглавные буквы или прописные. Минусы очевидны — создаем лишние объекты, лишняя аллокация памяти, тратим впустую время. Более того, std::string_view был создан чтобы бороться с копированиями, а не примыкать к ним 🤔.

👨‍💻 Вариант посложнее — у std::string_view можно в шаблонном аргументе подменить класс, отвечающий за тип символов. Вместо дефолтного определения:
std:: basic_string_view<char, std::char_traits<char>>

Мы сделаем
std::basic_string_view<char, std::custom_char_traits<char>>

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

И кажется, тут мы обошлись без копирований. Но ценой чего? Ценой того, что в С++ нет возможности определить std::hash для нашего типа. Вообще никак. Только заново писать. Самим. Ужасно 😡.

Я не мог поверить своим глазам, что можно было сделать std::hash таким не переиспользуемым. Наверное на то были причины, но мне они не до конца ясны...😔

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

Пока я не нашел способа как решить эту задачку без копирований используюя только стандартную библиотеку. Но может быть знаете вы 🤔?

Simpleperf

Последние недели я был занят завершением работ над фичой, которую начал делать с самого прихода в Яндекс. Теперь нас ждут долгие этапы тестирования и оценки профита в реальной жизни. Но я рад, что всё задуманное получилось ☺️.

А между тем жизнь кипит, работа идет и для точек роста производительности нашего приложения я решил его профилировать. В отличие от обычный server-side приложений, для которых уже придумано 100500 инструментов профилирования, на android их оказалось крайне мало. Ну либо собирать самому из исходников 🤔.

Android Studio позволяет из коробки профилировать apk-приложения или debuggable процессы. Но у меня ни то, ни другое — просто нативное приложение, вызываемое в терминале 🙃. И получается студию никак не использовать. Но как-то работает ведь в ней профилировщик?

Оказывается, уже c версии 5.0 в поставке на всех девайсах есть simpleperf — backend профилировщика, работающего в Android Studio. Его интерфейс очень похож на классический perf. И работает он для всего: и для apk, и для нативных приложений, можно даже к процессу приатачиться.

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

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

Рефлексия о работе в Яндексе

Уже чуть больше полугода я работаю в Яндексе. Удивительно, но сейчас мне уже кажется, что я работаю здесь очень давно. Мне стали привычны внутренние инструменты, я практически перестал спрашивать что, где и как лежит ☺️.

Удивительно, насколько много событий происходит в одной компании. Не всегда за всем успеваешь следить, да и не нужно это. Просто представьте, в моём родном городе населения примерно столько же, сколько во всём Яндексе. Как только об этом думаю — вообще мысли в космос улетают сразу 😮.

Удивительно, как я быстро приспособился. Я на самом деле думал, что всё будет тяжелее и сложнее, потому что это же Яндекс. Но нет, там работают такие же люди, как и я, которые стараются делать качественные сервисы для своих пользователей, в том числе и для самих сотрудников. Инструменты, которые казались мне сложными и неудобными на первый взгляд, оказались просто супер полезными и классными ☺️.

Я успешно поучаствовал в нескольких больших проектах. О некоторых из них я уже писал в своём блоге (здесь, здесь). Сейчас стартуют новые, не менее интересные для меня, для компании и для наших пользователей. Они сложные, правда, но это и больше увлекает! Это же то невероятное чувство, когда ты решил сложную задачу. А когда это получается сделать еще и элегантно — шедеврально 😍!

Спустя какое-то время я стал общаться с большим количеством людей из разных команд: аналитиками, тимлидами, разработчиками. С одной стороны может показаться, что это минус: эти люди могут придти ко мне в обход тимлида и что-то решить со мной лично. Но мне кажется, что это плюс: я решаю задачи самостоятельно, а с тимлидом синхронизируемся только по основным моментам. Я считаю, что в идеале я должен получить задачу по типу "надо вот это", а я такой: "понял-принял, сделаю". Я думаю, что у меня стало это получаться достаточно хорошо 👨‍💻!

Очень классно, что большинство задач у меня перекликаются со сферами моих интересов: C++, Deep Learning, оптимизация времени исполнения. Мне кажется, мало кто на рынке (в плане компаний) вообще может дать такие задачи.

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

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

И также мы сейчас нанимаем. Если у вас есть силы тащить серьезные, нетривиальные проекты с нуля, вы отлично разбираетесь в CV DL, а также любите не только исследовать, но и внедрять решения в реальные приложение — приходите к нам пообщаться 🙃.

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

Дальше — больше!

FPV, ELRS, SX1280

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

🤔 Я очень и очень мало знал. Как и с точки зрения разработки, так и с железной стороны.
🤔 Доставка компонентов была очень долгой. От двух месяцев в лучшем случае.
🤔 Денег у меня не было. А квадрокоптеры — это вообще не дешево.

В итоге долгие годы для меня дроны и вся история с ними оставалась пределом мечтаний. Когда я устроился на работу, чуть ли не на первую зарплату я купил себе квадрокоптер👨‍💻. К сожалению, на 10-ый полет он улетел от меня слишком далеко и я его не смог найти. Это было очень грустно, каждый раз проезжая это место в Питере я всегда вспоминаю об улетевшем дроне 😔.

Времена меняются и в прошлом году я купил себе DJI Mavic Mini 3 Pro. Это классный дрон, мне нравится с ним проводить время в лесу, исследовать окрестности. Иногда получается снимать сногшибательные кадры. Но проблема этого дрона — очень много автоматики, а это этого очень много ограничений. А хочется какого-то драйва, хочется полного погружения 🤔.

И вот я задумался о том, чтобы стать FPV (First Person View) пилотом. Летать в акро-режиме, ощущать свободу полета и действий. Акро режим не так прост и для этого новички тренируются в симуляторе. Естественно для всего этого дела нужна аппаратура управления. Мой выбор пал на TX12 MKII — посмотрел много обзоров, почитал много чатов и форумов. И сейчас я учусь летать — пока сложно 🤪. С каждым часом практики всё становится чуточку проще, но впереди большая дорога.

В процессе изучения FPV индустрии я осознал, насколько она продвинулась вперед. Появились куча Open Source проектов, образовалось множество компаний, которые делают качественные рамы, комплектующие и целые дроны. В мои школьные года всего этого еще не было вообще!!!😮

Пока самый удивительный для меня факт, что в индустрии завовал авторитет производитель полупроводниковых устройств — Semtech. Они запатентовали технологию передачи LoRa, которая позволяет делать передатчики, потребляющие очень мало, при этом работающие на очень большие расстояния с маленькими помехами. Эту технологию они внедрили в массу своих чипсетов, один из них стоит в TX12 — SX1280.

Устройства от Semtech настолько понравились обществу (по крайней мере, я так думаю), что сообщество FPV пилотов и не только, на базе LoRa технологии придумали ELRS — систему радиоуправления с открытым исходным кодом, которая работает не хуже коммерческих аналогов в большинстве кейсов ☺️. Хочется почитать код этого огромного проекта. Как по меня, он сделал мир намного лучше. Для меня и правда удивительно, как дело индустрия ушла вперед за последние 10 лет.

Пойду погоняю в симуляторе👨‍💻, если чего найду интересного в проекте — расскажу!

Скрытый рост

Вчера в команду вышло два стажера. Я этому очень рад, потому что с одним из них буду работать я! У меня, как обычно, грандиозные планы, я думаю мы справимся с большинством задач за время стажировки ☺️.

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

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

Одновременно с этим пониманием приходит осознание, что я вообще не зашиваюсь 👨‍💻. Иногда даже мне хочется подойти к руководителю и сказать, что можно еще задач дать, но я всё же потом останавливаюсь, потому что не надо перегружаться.

И вот возникает вопрос: что это вообще такое? Опыт? Продуктивность? Кайф от работы? А может быть всё вместе?

Одно я знаю точно — это знак прогресса, а значит я точно делаю всё как надо.☺️

Не аугментируешь данные — ошибка, не смотришь на данные после аугментации глазами — фатальная ошибка

В обучении моделей машинного обучения самое главное — данные 🙃. Уже потом идет сам метод машинного обучения (нейронные сети, деревья решений и т.д.). И самое первое, чем нужно научиться — это смотреть на данные и находить дефекты, если таковые есть.

Данных не всегда много (нужно очень много). А поэтому специалисты приходят к искуственному расширению датасетов при помощи различных инструментов аугментации 😁. В картинках это различные трансформации изображения: повороты, сдивиги, кропы, оптические искажения и т.д. И вот с аугментациями нужно быть очень осторожным.

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

А вот будем ли мы делать из картинки вырезать маленький рандомный участок? Возможно, да, но нужно убедиться, что мы не сделали шумных кусочков, на которых тигра вообще нет, а при этом наш ответ на этой картинке — тигр 😁.

Я совершал много таких ошибок и мне кажется, без этого никак 😔. Когда-то по неопытности, когда-то потому что спешил. Но всё это факторы, на которые мы можем повлиять: не торопимся, набираемся опыта. Бывают однако случаи, в которых мы и не подразумевали, что есть какая-то проблема. Зачастую это связано с инструментами, которые мы используем.

Так, недавно обучая нейронку, я наткнулся на баг в своем загрузчике данных. По привычке я уже визуализировал картинки. Смотрю а картинки одинаковые, причем по несколько штук подряд. Думаю, всё, что-то в данных не так. Смотрю на данные — всё в порядке. Думаю, давай дебажить (а при дебаге выставляется число параллельных потоков 0, т.е. один главный поток), вижу в визуализации порядок. Окей, давай запустим еще раз, запускаю с 0 потоков обучения — в визуализации порядок 😧.

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

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

Чего нового?

Как-то давно я не писал. Хочется радовать каким-то контентом, а не повседневной деятельностью 🙃 Возможно, я не прав, и если вам интересно что-то узнать из моей жизни — пишите в комментах.

😡 Я просто лютейше ненавижу OpenCV
У меня начались сложные отношения с OpenCV еще на прошлой работе, когда я пилил систему распознавания для Raspberry Pi. OpenCV достаточно сильно течет, эту либу проблематично использовать в многопоточной среде. Здесь авторы OpenCV пишут, мол да, о проблеме знаем, но вы просто не используйте много потоков. Классное решение, конечно. Я уже не говорю о том, что есть утечки памяти еще в нескольких местах, а также дикие проблемы с перфомансом.

🔼 Ускорились почти в 2 раза
Я недавно инициировал обновление парочки зависимостей, которые мы используем у нас в решениях. И когда обновили, много чего сломали 🙃 Но быстро починили, потому что оказывается сломалась обратная совместимость. После небольших фиксов всё заработало как надо, а некоторые из компонентов ускорились аж в 2 раза! Топчик 🙂

🥺 Потихоньку выхожу из рамок своей команды
Сейчас я работаю с различными командами для того, чтобы сделать наши совместные сервисы лучше. Межкомандное взаимодействие никогда не было простым, но я вроде как справляюсь! Надеюсь, мы в скором времени порадуем наших пользователей новенькими бомбическими фичами!

Век живи, век это делай

Недавно совершенно случайно во время просмотра замечательного доклада про приниципы построения высокопроизводительных систем как ClickHouse, наткнулся на плейлист лекций по C++ для магистров МФТИ 🙃.

Если кратко — мне очень сильно понравился ☺️. Я посмотрел пару-тройку лекций и точно понял, что я дослушаю этот плейлист до конца. Лектор топово и в шутливой манере рассказывает про тонкости языка. Очень классная подача. Курс не для новичков, тем кто хочет влиться на канале автор предлагает посмотреть базовый курс 😊.

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

Код ревью

Пока я работал тимлидом в прошлой компании, мне приходилось каждый день ревьювить много кода. Тогда я задумался о том, какой смысл несет в себе код ревью? Сколько денег мы на него тратим? Что оно дает в целом?🤔

Я пришел к выводу, что начиная с мидла код ревью — это скорее опасная, чем полезная штука 😮. Дело в том, что мидл разработчик должен уверенно писать код. Он не должен ожидать, что если он наплодит багов, то это всё найдется на ревью. Так точно не должно быть, я в этом уверен.

Да, если код пишет джуниор разработчик, то мы ожидаем, что там могут быть проблемы со стилем, могут вылезти какие-то баги. Но вот уже товарищи постарше должны писать код хорошо, должны нести бОльшую ответственность за написанный код 👨‍💻.

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

Третья проблема: ревью долгое 😐. И часто ребята, которые пишут фичи, иногда делают ревью на 100500 строк кода, что невозможно читать. Это ужасно, и даже если у вас есть код ревью, за 100500 строк нужно наказывать — это непорядок.

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

Думаю, что такой подход заслуживает внимание. Кажется, он позволяет разработчикам более ответсвенно относиться к коду ☺️!

P.S. Знаю, что меня читают не только разработчики. Кажется, на ваши профессии тоже можно переложить часть описанных практик!

Синдром самозванца

Это по большей части пост саморефлексии. Он возник отчасти от того, что этим синдромом страдаю я. Как он проявляется? 😧

— Все вокруг знают точно больше, чем я. Неважно, по какой тематике, но всё равно я почему-то считаю, что это так;
— Все вокруг делают больше, чем я. Даже если я буду работать по 12 часов в день, я буду считать, что работаю мало и делаю недостаточно;
— Вокруг так много классных блогов, зачем мне свой? И все классно пишут. А что могу дать я?

Так или иначе общая формулировка такая: "Все лучше меня во всем". Иногда как нахлынет, но как с этим бороться — я пока не придумал. Может быть кто-нибудь подскажет?🙃

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

Тут очень хочется привести аналогию из спорта, где часто влияет не то, сколько ты проводишь время на тренировках, а твоя сила воли и дисциплина. Я недавно тренировался в зале с абсолютным Чемпионом Мира по бодибилдингу и конечно мой вопрос был: "Как ты этого достиг?". Ответ до безумия простой: "Дисциплина, брат. Со мной одновременно тренируются десятки и сотни таких же, как и я. Берут веса даже больше, чем я. Но у меня есть жесткая сила воли и дисциплина, в отличии от многих." 😁

И кажется что путь в избавлении от синдрома в признании что правда в мире очень много таких, как ты. Но как понять, в чем твоя фишка? Делитесь в комментах, интересно почитать. ☺️

Stable Diffusion на RPi 😮

В AI есть сейчас такое хайповое направление как text2image. Это когда мы вводим какой-то запрос, а небеса чудесные в ответ преподносят нам картинку богическую ☺️. В Яндексе — это Шедеврум, в Сбере — Кандинский, а общеизвестный — Stable Diffusion.

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

И я вот на днях обнаружил смельчака, который запустил миллиард параметров stable diffusion на малинке 🔼! Это же жесть как офигенно, хотя и в некоторой степени бессмысленно. Чтобы вы понимали, практически любой современный телефон будет мощнее малинки на несколько порядков.🙃

Основной идеей, как я понял, служит то, что мы получаем необхоимые веса и тензора только тогда, когда нам они действительно нужны. Современные же фреймворки загружают всю модель полностью для минимизации задержки предсказаний. И хоть исполняется это дело на малинке 3 часа, это выглядит капец как круто!😐

Так что вот вам чтиво на вечер: https://habr.com/ru/companies/ruvds/articles/751912/

P.S. Зашел на GitHub, открыл код, ужаснулся и закрыл. Ребята, 5к строк в одном файле, ну вы серьезно? Не надо так.💃

Чертов ADL

В С++ есть такая штука, как ADL — Argument-dependent Lookup. Специальный такой хитрый поиск, который ищет перегрузку функции в зависимости от типов аргумента 🙃. Он может находить необходимую перегрузку функции, которая объявлена вообще в другом месте, но лучше всего подходит под аргументы.

С одной стороны очень полезная штука: hello world выглядит не так страшно, каким может быть. Да и вообще здорово сокращает существующий код. С другой стороны — иногда доставляет так много геморроя во время отладки, потому ожидаемое поведение одно, в итоге получается другое, а в дебаг моде — третье 😡.

Так вот тут статейка попалась мне, где человек пишет: "Хватит это терпеть! Используйте лямбды потому что... они не допускают ADL". Интересная мысль, и примеры классные, но повторять я не буду 😂. От лямбд код разбухает дай боже, дебажить код, который падает внутри лямбы, которая под лямбдой, сверху лямбды — то еще удовольствие. Но если вы особый ценитель — пожалуйста.

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

Чтиво: https://www.foonathan.net/2023/08/stop-writing-functions/#content

P.S. Лябды люблю и уважаю. Особенно IIFE (immediately invoked function expression).

Ускорение, которое вы скорее всего не заметите

Прочитал любопытную статью, в которой описывает поведение компилятора на if выражении 😅.

Чтобы было понятно о чем речь, поговорим про одно поведение процессоров. Каждый из нас всегда стоял перед выбором (ну или видел фрагмент фильма "Матрица" с выбором таблетки, ну или видел мемасик с кнопками — какую бы нажать) 🥲. Согласитесь, не очень классное ощущение в этот момент? Нужно выбрать что-то одно, угадать будет хорошо или плохо 👨‍🦳.

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

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

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

Само чтиво: https://habr.com/ru/companies/stc_spb/articles/752974/

От себя лишь добавлю, что статья покрывает только GCC (что грустно) и не показывает современную реальность. Современные процессоры хорошо предсказывают переходы, и как пишут комментаторы (и я согласен), стоит вместо расстановки использовать PGO (Profile-guided optimization). Но про это как-нибудь потом 🙃.

Мысли про карьерный рост

Недавно дома обсуждали карьерные вопросы. Общая тема была такая: "А что для тебя карьерный рост? Как расти?" 🙃

Это очень интересная тема, на которую я готов дискутировать долго. Но более важно то, что через полгода моё мнение может развернуться на pi радиан, а еще через полгода на 3/4pi. Но все эти мысли будут верны относительно меня, потому что карьерный трек для каждого свой, и любой карьерист должен так или иначе встать на этот путь истинный.

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

Вот я программист и сижу пилю свою фичи, т.е. решаю поставленные на меня конкретные задачи. Расту по грейдам: джун, мидл и синьор. Принимаю более важные решения про то, как запилить то или иное. Чем выше грейд, тем серьезнее решения и их последствия. Но у этого всего есть потолок в виде твоего тимлида/руководителя/etc. Всё-таки они тебе дают задачи и твоё влияние остается локальным в рамках вашего проекта(ов). 🥺

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

Если начать мыслить в таком контексте, начинают приходить интересные идеи о том, как сделать лучше продукт для пользователей, как может выглядеть твой продукт через N месяцев/лет. Отсюда у тебя появляется своя картина мира и развитии. 🙃

Тут важно вовремя остановиться и начать "продуктоощущение" на трек развития компании, на картины мира руководителей, товарищей и т.д. После валидации мыслей скорее всего у тебя останется картинка с четким представлением, что нужно в продукте, чтобы это сделало его круче: пользователи были счастливы, разработчики были счастливы, компания получала больше денег и т.д.😁

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

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

В общем мой посыл в том, что карьерный рост очень сильно завязан на область твоего влияние. Чем выше твоё место в компании — тем глобальнее влияние. Откуда вывод что если хочешь расти — нужно стараться переходить из мышления локального (задачи/фичи в рамках твоего проекта) в глобальное (место твоего проекта в рамках компании и пользователей).🙃

P.S. Кратко бы сказал так: классно когда ты переходишь из плоскости "я сделал эту фичу", в плоскость — "я это придумал". Здесь придумал — это реально придумал, а потом донес свою мысль до кучи людей и убедил их в том, что это нужно сделать, а потом вы все вместе это сделали. 🔼

Командировка в Стамбул

Недавно всей службой ездили в командировку в Стамбул! Служба — это объединение нескольких команд. Я вот работаю в OCR, а еще были команды, которые занимаются Шедеврумом, Визуальным поиском и большим разнообразием других не менее важных CV-технологий. Эта командировка была важна для всех, потому что вся служба уже не собиралась вместе очень давно и все не сильно-таки знакомы с друг другом. 😮

Стамбул прибавил своего шарма. Мы вместе решали, куда сходить и где покушать ☺️. Вместе делали заказы и обсуждали блюда, кухню, культуру. Обозревали культурное наследие, некоторые объекты которого дошли до текущий годов с веков до нашей эры. И это захватыет дух. Хотя сам Стамбул мне не очень зашел, но то, как мы отдыхали вместе со службой — очень классно 🥰.

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

Мы не только отдыхали, но и работали и думали над насущными проблемами. Что в командах хорошо, а что можно сделать лучше? Как видим развитие тех или иных технологий?

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

Ну а вообще кратко мысли о всей командировке такие: "А что так можно было?"🤔

Про API дизайн

Этот пост меня побудила написать интересная статья на хабре. В ней автор рассказывает на интересных примерах как строить грамотный API своего кода. 🤔

Я, надо бы сказать, побывал уже в большом разнообразии стадий построения решений. Когда-то я писал программульки просто так, чтобы они работали.💃 Потом я познакомился с замечательными патернами и, конечно же, оверинженирил по полной. Сегодня я уже могу просто сидеть по несколько часов просто чтобы сделать неплохой дизайн. Ключевое здесь — "неплохой", потому что я знаю, что можно делать лучше и я вижу это в других решениях. 🤓

Когда я начинал свою деятельность, требования для меня были шуткой и что-то из разряда: "профессионалы этим не занимаются, это скучно🤪". Потом ты становишься этим профессионалом и понимаешь, что всё же все эти требования очень важны, причем настолько, что клацание по клавиатуре в попытках написать очередную функцию практически происходят незаметно. Мне каждый день приходится решать задачи, связанных с уточнением и реализацией требований, т.к. у нас достаточно сложный ML сервис. И если честно, я больше сижу и думаю про то, как это сделать хорошо, а пишу код потом уже очень быстро.🔼

Но всё это лирика, давайте к практике. Первое, что вы всегда должны понимать, когда начинаете разрабатывать: "когда я буду использовать этот код еще раз?". Скорее всего, если вы MLщик и пишете очередную функцию для агументации, фитпредикта, трейнлупа, которые вы хотите просто быстро написать чтобы запустить эксперимент и проверить гипотезу — вам не нужна никакая архитектура. Если хотите работаете в jupyter notebook, пишите скрипт для переименования файлов, мерджа картинок, заливки данных и прочих "простых" инструментов — вам не нужна архитектура.🙃

Приведу пример: когда-то я писал скрипт для загрузки данных на сервак. У меня в голове сразу 3 идеи: можно сделать в одном потоке, в нескольких процессах, асинхронно. Данные исчесляются десятками миллионов картинок, а потому в любом из этих вариантов скрипт будет работать ну долго. Просто в случае одного потока это вся ночь, в случае мультипроцессинга — полночи, а асинхронность даст еще 20% ускорения от мультипроцессинга. Вопрос: что выберешь написать? 😂

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

Когда ты строишь production-like решение, пишешь библиотеку, или другими словами делаешь решение "на века", тогда здесь без дизайна не обойтись 😔. Нет, ты конечно можешь быстро что-то написать, упустив половину требований, написав в названии "MyBestFunction", но тебе потом жить с этим (где-то сейчас заплакал человек, внёсший std::vector<bool> в стандарт).

И вот, к сожалению, часто я вижу картинку, что всё наоборот. Когда надо делать хорошо, там всё плохо, а когда не надо, там человек старается и пыхтит. Что тут сделать, как исправиться? 😮 Учиться у профильных коллег. Если ты МЛщик, разраб, девопс, да кто угодно и хочешь научиться писать хорошо API (а это нужно делать, чтобы как минимум по грейду расти), читай код работяг, пишущих сервисы пососедству, приходи к ним и узнавай, почему сделано так, а не по другому. Как говорил классик: "делай это упражнение 2 раза в день, и..."

Плата за плюшки

Наткнулся на короткую заметку про то, как можно легким движением ускорить std::vector::push_back на 10%.🔼

Сначала автор рассказывает, что если создать vector и пушить в него значения — то моя программа будет супер медленной. Для ускорения предлагается использовать reserve, который увеличивает capacity контейнера. И это действительно верное утверждение, особенно если заранее известно количество элементов, которое будет вставлено. В противном случае, при достижении capacity на очередном (но не обязательно финальном) вызове push_back, будет произведена аллокация большего куска памяти, в который сначала переместятся элементы из старого куска памяти, а потом вставится новый элемент. Как ты можешь понять, это будет ну очень долго😐.

Но дальше автор рассуждает: если я резервирую память на заранее известное количество элементов, то имеет ли смысл делать проверки на превышение capacity, если я условно гарантирую такое количество вставок, которое не превысит заданный предел? И вот оказывается, если я напишу альтернативный метод push_back, но без проверок — вставка начнет работать на 10% быстрее. Однако, утверждает автор, если я нарушу контракт и начну вставлять больше элементов, то новая функция будет иметь UB, что очень больно 👨‍🦳.

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

Неужели твой и мой код медленные, модельки можно обучать и инферить быстрее? Да, конечно 🙃! Но посмотри, что мы от этого получаем? Удобные интерфейсы для подготовки пайплайнов, прототипирования моделек и прочих радостей жизни. Давно ли ты что-то писал на TF? Я не думаю😂. Зато как ты любишь Pytorch (и не говори, что нет). Однако, на моей практике, хорошо собранный пайплайн на TF итерацию forward-backward path выполняет быстрее Pytorch, а также занимает меньше памяти. Но совсем незначительно (как и в примере с std::vector), в сравнении с тем, как неудобно этим делом пользоваться.

Или же вспомни классическое нахождение опеределителя матрицы 3х3 🤓. Можно пойти через правило треугольников и получить формулу, которая вычисляется за 12 умножений и 5 сложений. Правило простое и интуитивно запоминается, на экзамене вспоминается чаще. Другой разговор про нахождение определителя через разложение на миноры. Там нужно и матрицу знаков помнить, и вообще что такое миноры, и как у них определитель находить. Но при этом вычисления всего лишь за 9 умножений и 5 сложений. И ничего себе, я вроде как сохранил 3 операции, но какими усилиями.

Потому я всегда думаю при реализации, а какими удобствами могу пожертвовать в угоду эффективности работы приложения. Это отражается и в коде, и в идеях, которые я закладываю при создании той или иной функциональности👨‍💻.

Немножко о себе

Привет! Меня зовут Антон! В этом блоге я пишу про свои похождения в мире IT, делюсь рассуждениями по различным топикам из интересующих меня областей. Вот часть из них:
👨‍💻 С++, Python
🤓 Deep Learning в целом, CV в частности
🔼 Оптимизация вычислений, ускорение чего бы то не было
💃 Управление командами
😐 Эффективность, тайм-менеджмент и прочая эзотерика.

Сейчас я работаю Senior MLE в Яндексе. Занимаюсь развитием технологий распознавания текста на изображениях (OCR). Обычно я представляюсь как "разноработчик" 🙃, потому что занимаюсь далеко не только ML, но и всякими интересными штуками в продакшене. Я большой фанат разработки, дико обожаю когда решение ускоряется в десятки и сотни раз, а также всегда топлю за лаконичные решения. Моя страсть — это мемы, а также холивары про то, как делать что-то лучше в IT 😂.

Органичный рост в командах разработки 🔼

Наткнулся на статью, в которой инженер из одной мета-компании рассказывает, как три инженера развивали в самом начале сервис фоточек и рилсов. Вот ссылочка на чтиво. Принципы, которые они заложили на первый год работы действительно классные и вызывают уважение лично у меня 🙃.

Но вот что самое интересное — это 3 инженера 😮. 3 инженера делали сервис, который в пике на тот момент достиг 14 млн пользователей. Часто ли ты такое встречаешь? Я нет.

Проблема разработки, которую я часто вижу в различных компаниях, которой грешат даже очень популярные люди в индустрии: заливаются все проблемы людьми, невероятно быстро выращивают отделы😔. И все это в надежде выпускать фичи в кратном объеме, чинить баги и пр. Но такой неорганичный рост превращается в разные проблемы, которые не решают поставленные задачи:
1. Думали, что 50 людей == 50 фичей, а получили 10 😐. Потому что чем больше людей, тем больше согласований на разных уровнях, и это затягивается. А также возникает очередь из ожидающих разработчиков, потому что из деятельность просто заблокирована;
2. В условиях быстрого роста очень сложно привить культуру компании, а у каждого свои цели, амбиции и желания, которые влияют на принимаемые решения🤔.

И самое интересное, когда я общаюсь с людьми, которые делают одно и то же, почему-то команды с органичным ростом выпускают фичи быстрее, а решения получаются качественнее. Может быть мне так не повезло, но моя практика такая 🤔. Но как по мне, в команде всегда нужно поддерживать рабочий дух, чтобы люди между собой постоянно обменивались опытом и знаниями, чтобы они просто даже знали друг друга. В быстрым ростом очень сложно хорошо познакомиться с людьми, на мой вкус, от того может страдать коммуникация, принимаемые решения, и как следствие поставляемый продукт.😔

А что думаете вы об этом всём🤔?

Помоги компилятору стать лучше

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

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

Перессказывать доклад не буду, но мне очень понравились рассуждения спикера в конце😊:
— Не нужно оптимизировать там, где это не нужно. Оптимизируй действительно важные и горячие места, в этом тебе может помочь разные инструменты для анализа перфоманса;
— Иногда компилятор может "сказать" тебе, почему он принял то или иное решение, и если у тебя достаточно скилов понять его, ты можешь ответить ему в виде инструкций, часть из которых описаны в докладе, и помочь сделать итоговый бинарь лучше🔼.

И как же я с ним согласен. Я сам пишу код на C++ не так часто, а потому знаю меньше людей, которые пишут на C++ каждый день. Я очень часто забываю даже очень тривиальные концепции из языка. Но вот правило "не суй, если не знаешь зачем тебе" со мной навсегда. Прежде чем заиспользовать какие-то хитрые или около того конструкции, я всегда подробно изучаю насколько "ок" это сделать 🙃.

Что самое жестокое, что иногда в практике на вопрос "зачем так сделал?" получаю ответ "ну вроде же прикольно получилось" 😑. Вот вообще не прикольно, нет.