Код ревью

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

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

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

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

Третья проблема: ревью долгое 😐. И часто ребята, которые пишут фичи, иногда делают ревью на 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++ каждый день. Я очень часто забываю даже очень тривиальные концепции из языка. Но вот правило "не суй, если не знаешь зачем тебе" со мной навсегда. Прежде чем заиспользовать какие-то хитрые или около того конструкции, я всегда подробно изучаю насколько "ок" это сделать 🙃.

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

Немного анонсов с работы ☺️

Сначала подумал, чтобы написать пост про каждое из событий отдельно, но потом решил, что в этом нет особого смысла, лучше позже расскажу про интересности с constexpr. В целом, это лично моя инициатива, потому что я всегда горю тем, что делаю, и очень заинтересован в развитии сервисов, команд и компаний 🙃. Так что не судите строго.

Я решил поучаствовать в рабочей группе трека ML в рамках Yandex Cup. Вместе с большой командой готовим для вас соревнование. Приходи участвовать, будет весело (иногда сложно и больно 👨‍🦳). Призы в целом тоже кайфовые. Ну и мне тоже будет приятно!

Я в СПб ищу себе стажера, с которым будем решать нескучные задачи OCR, в первую очередь связанные оптимизациями нейронных сетей (как по объему, так и по скорости исполнения) 🔼. Если тебе уже знакомы слова Python, C++, Pytorch, Tensorflow, Git и на практике успел пошаманить с нейронками — приходи, пообщаемся!

Ну а если ты уже имеешь рабочий опыт в CV или NLP, можешь рассказать моей бабушке, что такое трансформеры 😃 и любишь решать нестандартные и очень хардкорные задачи, приходи пообщаться по поводу позиции в штат!

И если тебе не сложно, поделись с другом, мало ли он что-то захочет из этого списка 😁!

constexpr родимый

Чтобы ты понимал, почему C++ — это сложно, просто вспомни про ключевое слово constexpr 👨‍🦳. Про него все знают, его все уважают, но мало кто использует. Почему? Не знаю. А он есть. С C++11 🙃.

Недавно читал статью про то, как влияет constexpr на размер бинаря. Автор проводит несколько тестов где:
— Сравнивает одну и ту же функцию без и с ключевым словом constexpr;
— Делает сначала тесты с одной единицей трансляции, а потом с несколькими; причем на нескольких два вида сборки: сборка сразу всех файлов в один бинарник и сначала сборка файлов по библиотекам, а потом линковка вместе.

Результаты чарующие 😧: практически нигде нет профита между функциями без constexpr и с ним, кроме одного случая — где сборка сначала происходит в библиотеки, а потом происходит линковка. Там профит почти на 30%...😳

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

constexpr functions and constexpr constructors are implicitly inline.

Чтобы функция в хедере была аналогичной, я вместо constexpr писал inline. Но как ты можешь увидеть из сноски выше — в плане разрешения имен это одно и то же (напомню, что inline это ключевое слово, которое позволяет сделать исключение из ODR и сделать одно определение на все единицы трансляции). Потому заявленное свойство constexpr — это свойство inline 🥲. И как автору в сборке с "профитом" удалось сделать это самое улучшение — я не понял. Если кто знает, помогите 🥺!

Но всё же одна плюшка (кроме основной — возможное вычисление в compile-time) мне понравилась: можно зафорсировать вычисления констант, а это позволяет избегать штуки, по типу деления на 0 ☺️.

Смешное про С++

В рамках подготовки к семинарам по C++ для студентов ШАД я в обязательном порядке повторяю материалы из большого количества источников 😊 :
— мои личные заметки;
— лекции лектора, чтобы понимать, о чем говорить на семинаре;
— различные ролики на youtube от известных спецов.

И вот я досматриваю очередной ролик, смотрю в комментарии, а там просто очень классная переделка всем известной песенки 😂:

Аа, в C++ указатели на память вот такой ширины,
Аа, в C++ шаблоны классов вот такой вышины,
Аа, прострелянные ноги,
Аа, нам с UB не по дороге,
Аа, и no more попугай,
Аа, и expired попугай.

Про попугая здесь отсылка к известному скетчу, упоминаемому в рамках лекции в разговоре про провисшие ссылки (возвращаем или/и используем ссылку на уничтоженный объект) 🤓.

Про цели, время, работу, славу

В октябре выдалось много работы 🙃. Собеседования ребят на проект в ШАДе, семинары в ШАДе, личный менторинг, завершение старых и старт новых проектов на работе. Кажется, немного, но хватает, чтобы иногда не спать сутки.

Я слышал недавно фразу: "если вы целыми днями работаете, то у вас нет времени менять этот мир." Звучит с одной стороны разумно, а с другой стороны — удел ли каждого менять мир? Явлется ли это моей целью? Или твоей? Решать каждому. Но звучит очень громко — поменять мир 🤔.

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

🔼 Например, Рентген открыл одноименное излучение, просто случайно заметив. Но мало ли он проводил в лаборатории времени?

🔼 Ну или более хайповая нынче тема с LLM (aka ChatGPT), где ребята из OpenAI решили попробовать, а что если обучить модель с большим количеством параметров на большом количестве данных. В итоге нашли удивительные свойства этого семейства моделей.

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

Ставить как цель получить какую-то славу или успех лучше не стоит. Это очень абстрактно. Ставить цель ради цели также бесполезно, вы будете думать больше о ней, чем о реальных делах 😔. Отвяжитесь от себя, если не можете поставить цель — это нормально. Мне кажется в этом мире, дико перегруженном методиками продуктивности, стоит просто не забывать кайфовать от работы, себя и жизни ☺️.

А если вы любите своё дело, всё придет — и слава, и мир поменяете 🔼. Ну а если нет, то возможно оно вам и не нужно было 😐? Как минимум у вас уже есть своё любимое дело ☺️.

Проект с нуля

На днях с коллегой общался на тему: как стартовать проект с нуля 🤔. Мне был интересен сам фреймворк принятия решений на основе накопленного опыта. Здесь опишу кратко свои мысли после всей нашей беседы.

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

Во-вторых, твоя позиция в проекте может быть разная 👨‍💻. В каком-то случае, ты сам себе программист, дизайнер и проджект, а в каком-то ты стараешься сделать так, чтобы верстка на фронте не поехала. Разница лишь в том, как много контекста нужно держать для решения задач. 🤪

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

Я уверен, что можно писать бесконечно этот список, но я был удивлен, что в целом принимать решения во всем этом многообразии можно примерно одинаково 🙃:

1. Ты понимаешь что нужно делать, чтобы запустить проект прямо сейчас? 🤔
2. Если да 💃, то поздравляю, ставь таски, часть делегируй, часть делай.
3. Если нет 🤔, обратись к одному из своих инструментов декомпозиции задач и по каждая задача становится мини проектом. Вернись в п.1 и повтори алгоритм.

Ну и всё. Для меня всегда казалось, что в таком плане чего-то не хватает. Но после общения с несколькими более опытными (по моему мнению) товарищами я понял, что он вполне годный 🔼. Его можно усложнить, конечно, но оно тебе надо?

А пока ничего сложного! Хотя... "инструменты декомпозиции задач" странный термин 🤓. Но в какой-то мере он может определять ваш опыт. Потому что важно не только про них знать, но и уметь их использовать.

Про эти инструменты я, пожалуй, напишу уже в одном из следующих постов!😁

Runway. Motion Brush in Gen-2

Офигеть 😮. Просто не надо слов. Смотрите демку. Если будет так (это видосик из анонса) — это будет невероятная фантастика.

Ребята обещают запилить кисточку в своем редакторе, которая приводит в движение выделенную область на картинке. Да 🙃, это делали и до этого, но если в таком качестве — то вроде никто.

Да, я понимаю, что артифакты есть и они будут. Но если у вас динамичный продакшн и вам нужно на секунду показать какую-то динамику — то это просто шикарнейший инструмент 🔼.