Итоги 2022

За этот год я выполнил 22 цели из 34 поставленных в прошлом году ☺️. 31 декабря, пока салаты будут делаться, кола питься, чипсы кушаться и прочие радости жизни происходить, я буду планировать цели на 2023.

А вот главные достижения этого года:
🔼 Я закончил свой длительный цикл образования и получил степень магистра с отличием;
🔼 Написал полностью свою научную статью и выступил на конференции — понял, что наука вообще не моё;
🔼 Перешёл на работу в Яндекс — больше отвественности, более серьезные задачи и требования;
🔼 Занялся личными финансами и инвестициями — недавано закончил составлять инвестиционную стратегию на ближайшие 10 лет;
🔼 Проработал множество моментов с личным психологом и стал просто лучше себя понимать.

И еще пару инетерсных вещей, которые точно заслуживают вашего прочтения, о которых вы узнаете совсем скоро 😉.

В будущем году я постраюсь копать глубже в интересные мне направления и технологии — это и оптимизация софта верхнеуровневая, низкоуровневая; проектирование масштабируемых высоконагруженных сервисов. Но в любом случае, не забывать про развитие вширь: изучать вокруг всё и вся 🙃!

В будущем году я постраюсь лучше отдыхать (а не работать 24/7), настроить свой сон и отладить систему time-management (у меня что-то типа GTD).

В будущем году постараюсь больше быть с людьми. Люди — самый ценный актив 🥰!

UPD: на выходных можете почитать про базовые концепции аллокаторов. Я буду вместе с вами!

Аллокаторы?

Итак, я всё же прочитал статью про аллокаторы. А вы🙃? Я не то, чтобы специалист по ним, но всё же давайте поясню, зачем нам нужен этот зверь. Если кратко: для управления памятью 👨‍🦳. А теперь подробнее.

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

Теперь представьте ресторан. Когда вы приходите, обычно встречающий вас персонал старается выделить столик именно под вас: если вас двое — столик на двоих; трое или четверо — столик на четверых; а для целой компании обычно заготовлен огромный стол или отдельный банкетный зал — такую роскошь редко дадут паре человек, как бы они того не хотели. А еще иногда столики соединяют — всё ради гостей заведения. И казалась бы тут тоже есть фрагментация, но есть один нюанс 🙃.

В обоих случаях есть своя система распределения (аллокации) ресурсов. Только вот в случае кино вы делаете всё сами: и выбираете места, и боритесь за них 🫡, и оставляете пустое пространство рядом. В случае ресторана всё делают за вас 🔼: вам лишь необходимо сказать сколько вас пришло. А ресторан уже сам там решит, куда вас поместить, что нужно сделать и самое главное — с максимальной выгодой для себя.

В программировании всё то же самое. Распределением памяти занимается аллокатор. Самый стандартный для C++ аллокатор практически ручной — он создан специально таким образом, чтобы выполнить свою главную задачу: просто выделить память пользователю.

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

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

Студенты

Помните я вам писал про пару интерсных вещей, которые произошли в прошлом году? Так вот одна из них заключается в том, что я теперь являюсь практиком по C++ у студентов ПМИ ФКН НИУ ВШЭ ☺️. Мне кажется это классная возможность прокачать свои софт скиллы, поработать с множеством людей и возможность вглянуть на обыденные вещи свежим взглядом 🤔.

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

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

В общем, пока всё классно! Думаю, напишу еще постик о преподавании после того, как подойдем к финалу. Глянем, как изменятся мои взгляды на всё это!

О важности инструментов

В своей жизни я слушал несколько раз курсы по одним и тем же языкам программирования 🤪. Это были C++, Python, SQL, и т.д. И если в первый раз я посещал пары для того, чтобы понять какие-то основы и хитрости этих инструментов, то в следующие разы для меня важно было ознакомиться с инфраструктурой вокруг языка: инструменты для анализа, кодогенераторы, различные профилировщики и т.п. Я всё еще так скажем в начале этого пути (как мне кажется) 🤓, но сейчас о другом.

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

В современном С++ понятно (о чем и пишет автор) как сделать, а вот для C или смеси двух этих языков — не всегда очевидно. И в целом как это делать — это предмет поста автора, а мне вот что было интересно: в конце статьи указывается, что один из способов растит размер программы очень сильно. Мне сходу понятно, в чем проблема: я уже видел много такого. А что делать новичку? И что я вообще делаю в таких случаях, даже если уверен, что происходит? 🤔

Я посещаю инструменты, о которых мне рассказали на одном из курсов по C++. Считаю, это просто must have инструменты для любого C++ разработчика. Это godbolt.org и cppinsights.io. Первый позволяет смотреть на дизассемблер кода, второй — позволяет поглядеть на код, после того, как компилятор сделает с ним множество магических штук 🙃.

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

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

Без инструмента нужно всё равно подумать, даже если опыт есть. А инструмент тебе приносит готовый результат очень быстро: тем самым можно потратить время на что-то другое, не менее полезное 🔼.

Оператор "Космический корабль" 🚀

В С++20 появился новый вид оператора — космический корабль. Выглядит он так: <=>. Это трехстороннее сравнение, которое позволяет в большинстве случаев уменьшить количество кода, который сравнивает два элемента одного типа. Подробнее про мотивацию можно прочитать здесь.

Иногда для того, чтобы реализовать этот оператор для структуры с некоторым числом полей, используют функцию std::tie. Это не просто так: она позволяет создать кортеж ссылок на элементы. А так как у кортежа уже реализован оператор <=>, то остается его всего лишь использовать 👨‍💻.

Давайте запишем на С++ как это обычно происходит:
struct Date {
int year;
int month;
int day;

auto operator<=>(const Date &date) const {
return std::tie(year, month, day) <=> std::tie(date.year, date.month, date.day);
}
};

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

На днях мы со студентами обсуждали вопрос, а добавляет ли всё же std::tie какой-нибудь нагрузки на наше железо? Мой ответ был консервативным: скорее всего да 🙃. У студентов ответ был: вроде как нет?

Я написал бенчмарки для двух компиляторов, где нужно было посортировать структурки (они далеки от идеала, но порядки соотвествуют локальным замерам): GCC и Clang.

В них сравниваются 4 варианта:
🦆 BenchDefault — это если необходимое сравнение реализовывать ручками;
🦆 BenchTieInside — это если использовать std::tie как я описал выше;
🦆 BenchTieInsideDefault — это если попросить компилятор самим сгенерировать всё как он считает лучшим;
🦆 BenchTie — это если реализовывать оператор отдельно от стурктуры.

Если глянуть на построенные диаграммы, то есть два любопытных момента:
🤔 На Сlang версия с собственной реализацией работает лучше, нежели чем использовать std::tie;
🤔 На GCC как-то очень странно себя ведет BenchTie — он работает существенно дольше остальных.

Для искушенных читателей приложу сюда Godbolt:
🦆 Clang — генерирует странности и на простом кейсе, когда идет сравнение, и на сложном, когда идет сортировка.
🦆 GCC — с одной стороны кажется, что он прям реально выдает странности, потому что при случае сортировки и внутреннего представления, там вообще не понятный дизассемблерный код, тогда как с внешним оператором — лакончный. У меня есть предположение, судя по тому, что мне удалось прочитать, каким-то чудным действием компилятор все же докидывает свою хитрую магию.

Я подумал, с чем может быть связано такое поведение для BenchTie на GCC и немного погодя решил в опции копилятора докинуть: -finline-limit=0. Грубо говоря, попросить компилятор максимально не инлайнить функции (т.е. встраивать код функции, вместо вызова этой функции) ☺️. На GCC теперь дизассмеблерный код стал выглядеть по другому.

Видимо GCC каким-то хитрым способом использует инлайнинг 😮. И делает это замурчательно. Правда его параметры у компилятора настроены не очень, вот GCC и не оптимизирует нашу функцию. Давайте дадим ему рекомендацию:

Вместо
auto operator<=>(const Date &date1, const Date &date2) {
return std::tie(date1.year, date1.month, date1.day) <=> std::tie(date2.year, date2.month, date2.day);
};

Напишем:
inline auto operator<=>(const Date &date1, const Date &date2) {
return std::tie(date1.year, date1.month, date1.day) <=> std::tie(date2.year, date2.month, date2.day);
};

Теперь на GCC все варианты работают примерно одинаково. Но всё равно все они медленнее, если реализовывать сравнение ручками на Clang 🤔. Кажется, что в Clang нужно еще допиливать std::tie, чтобы он был хорош (или где-то я не прав 🤔). Такие вот дела.

Бенчи с изменением: GCC и Clang.

Поиск по архивам

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

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

В самом проекте задействовали очень много людей. Все очень сильно старались: что-то ломалось — мы находили баги и исправляли; что-то вызывало ВАУ и мы просто гордились собой🙃. За время реализации проекта было очень много локальных мемов, очень много неопределенностей и это было реально атмосфера стартапа в рамках большой компании😊.

Подробнее про то, что наша команда сделала, можно почитать в блоге.
Ну и ссылка на сам проект.

Антон, ты опять всё сломал?

На прошедшей неделе я столкнулся с очень интересным явлением: ошибка точности в числах с плавающей точкой. Как и что это вообще 😳? Давайте по порядочку.

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

В современных процессорах есть различные инструкции, которые позволяют производить вычисления с вещественными числами чуточку быстрее, нежели чем без них, например: AVX, SSE и т.д. Не будем вдаваться в подробности как они работают, нам лишь нужно понимать что для их использования необходимы определенные условия. Для этого компилятор пытается всяческими способами оптимизировать наш код, чтобы удалось использовать эти инструкции: перестановка инструкций местами, использование различных правил расстановки скобок и т.д. 😁

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

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

Интересно то, что я получил этот тензор во время квантезации. До квантезации результаты всегда были предсказуемыми и одинаковыми. Получается, что процесс квантезации вносит сильную нестабильность в вычислительный процесс. И получается, что я опять всё сломал 🥺?

Ну ничего, починим.

Кажется, взрослею 🤔

На днях столкнулся с выражением, которое меня заставило задуматься на множество часов:
Взросление — это отказ от потенциалов, которые возможны.

Я стал анализировать свой жизненный путь и подумал, что это возможно одно из самых справедливых утверждений, с которым очень сильно не хочется соглашаться. Ведь можно сделать так много, можно стать профессионалом в огромном числе сфер, просто нужно... постараться 😉. Так ли это?

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

Да далеко ходить не надо: основной причиной сложности программирования на C++ считается ручной контроль памяти. Хотя казалось бы — свобода действий. И да, благодаря такому подходу можно более четко контролировать ресурсы, но на деле? Куча кода, который делает то, что в других языках записывается одной строчкой. Непонятные падения приложения, постоянные утечки. Бррр 😂

Будучи разработчиком мне уже пришлось сделать множество отказов, чтобы стать профессиональнее в том, что я считаю наиболее важным. Я писал Web приложения, но в итоге я не Web-разработчик; я писал свой графический движок, но я не стал game developer; я писал хитрые алгоритмы, но я не разработчик структур данных; я обучал нейронки из кучи разных доменов, но сейчас занимаюсь только компьютерным зрением... 👨‍💻

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

Рекурсия в метапрограммировании 🤣

Метапрограммирование — это тонкая материя. В целом вообще всё "мета-" оборачивается в слова "подумайте 100 раз нужно ли вам это, потом спросите коллег нужно ли оно вам и если всё же нужно — делайте". Но мы же просто любим всё ломать, так что пропустим эти слова и пойдем дальше 😆.

Давайте представим, что нам нужно во время компиляции посчитать следующую функцию:

f(N) = N + f(N - 1) - F (N - 2)

Ну и сделаем какую-нибудь базу, допустим:
f(1) = 1
f(2) = 3

В C++ на текущий момент я знаю 3 инструмента, которые могут помочь вычислить эту функцию на этапе компиляции:
🧐 шаблоны — позволяют писать обобщенный код, а т.к. параметрами шаблонов могут быть целые числа, то нам это подходит;
🧐 constexpr функции — даёт рекомендацию компилятору исполнить функцию во время компиляции;
🧐 consteval функции — функция обязана выполниться только на этапе компиляции.

На шаблонах это будет примерно так:

template <int N>
struct Fun {
static const int value = N + Fun<N - 1>::value - Fun<N - 2>::value;
};

template <>
struct Fun<2> {
static const int value = 3;
};

template <>
struct Fun<1> {
static const int value = 1;
};

При маленьких значениях этот код действительно будет работать (примерно до 450, зависит от параметров компилятора). Но потом выдаст ошибку, мол дерево рекурсии очень велико и превышает лимиты 😔. Хорошо, тогда добавим в компилятор опцию -ftemplate-depth=200000 и как минимум до 100000 выражение будет работать. Класс 😂.

Тогда напишем функцию для constexpr / consteval (они одинаковы, поэтому можно раскомментировать одну часть и закомментировать другую):
constexpr /* consteval */ int Fun2(int val) {
if (val == 1) {
return 1;
}
if (val == 2) {
return 3;
}

return val + Fun2(val - 1) - Fun2(val - 2);
}

Уже при маленьких значениях Fun2 в случае constexpr не будет работать на этапе компиляции. Оно заполнит наш бинарь кодом для вычисления этой функции и во время исполнения запустит реально считать эту функцию, что ну такое себе — мы этого не хотели, совсем не "мета-" 😑.

В случае consteval Fun2 уже при маленьких значениях безбожно уничтожит наш процесс компиляции. Оно не удивительно, ведь Fun2 имеет вычислительную сложность O(3^n * n!). Но почему работает тогда версия на шаблонах? 🤨

consteval Fun2 будет пытаться по честному посчитать каждый вызов функции, тогда как версия на шаблонах генерирует код, который переиспользуется. Если попытаться попросить компилятор выдать нам код после инстанциирования шаблонов — там будет простыня больше чем на 50к строк для не очень больших значений 🤣.

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

Мораль сей басни такова: если вы не можете (ну или не хотите) оптимизировать рекурсию, а она может быть очень большой — от метапрограммирования на шаблонах не убежать. А так лучше использовать consteval — код получается приятнее ☺️.

Рассказал про нейронки в ИТМО 🙃

Совсем недавно ребята из ИТМО попросили меня немного рассказать про нейронные сети. Как по мне, вопросы были интересные, а отвечать на них каждый может по разному ☺️. Но мою позицию вы можете прочитать в блоге ИТМО в ВК: https://vk.com/wall-94_54899

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

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

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