Pragmatic ML

Cloudflare — пример того, как нужно решать вопросики.

Даже за вычетом их крутых продуктов, которыми пользуется весь мир, (например 1.1.1.1 и CDN), они идут в сторону своей миссии — открытого и безопасного интернета для всех.
Они пишут очень крутые постмортемы (рекомендую прочитать последний), делают крутые партнерки (serverless деплой модельки с HF на CDN), а также сражаются с патентными троллями, о чем и сегодняшний пост восхищения.

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

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

Для меня патентная система в текущем виде выглядит как рудимент, который позволяет людям, неспособным на развитие, блокировать прогресс просто на корню. Компании, вместо того чтобы создавать конкурентное преимущество развитием, пытаются придушить конкурентом бумажкой. И я очень рад, что Cloudflare своим примером показывает, что с этим можно и нужно бороться.

В одной из первых домашек курса Efficient Deep Learning Systems предлагается порешать маленькие задачки, чтобы научить глубже понимать, как работает код на GPU – https://github.com/srush/GPU-Puzzles. 14 небольших задач на Python+NUMBA – несколько прекрасных вечеров, проведенных за решением этих головоломок, вам обеспечены. У srush много подобных занимательных задач, есть и про распределенное обучение, и про трансформеры
Но если вам хочется еще глубже покопаться вокруг CUDA, то можно стартануть с источника, упомянутого недавно в LDT

На фоне того, что Цукерберг скупает сотни H100 для обучения новых версий LLama, все остальные начинают страдать от нехватки high-end видеокарт.
А что делать бедным ресерчерам, у которых нет доступа к таким ресурсам?
Ну например, пробовать дообучать большие модели через децентрализацию, как делают в Petals.
Или, как предложили те же авторы Petals, обучать их, используя SWARM Parallelism.
Сегодня разбор именно этого подхода.

Ссылка на статью – SWARM Parallelism: Training Large Models Can Be Surprisingly Communication-Efficient

У автора этой статьи в том числе есть прекрасный курс под названием “Efficient Deep Learning Systems”, который я однозначно рекомендую всем, кто хочет погрузиться в DL с инженерной стороны. Есть и про менеджмент экспериментов, и про деплой на сервера/девайсы, и про профайлинг/мониторинг кода.

Наверное, стоит отдельно рассказать про топ 1 решение Kaggle соревы из поста выше.
Не буду вдаваться глубоко в детали моделей, так как победители одновременно являются сотрудниками компании Owkin, которая занимается почти такой же задачей. Так что они использовали обученный у себя ViT(Phikon) как backbone для генерации признаков.

Идея понятная — несколько разных ViT-like моделей как генераторы эмбеддов из кусков большой картинки. Дальше, ансамбль MIL (Multiple Instance Learning) моделей (опять один из вариантов — их личная идея, даже статью написали 3 года назад, об этом ниже).

А теперь о интересном:
— Написали свою тулзу на C и libpng, чтобы быстро делать random access в png, выделять кусок картинки и сохранять его на диск в виде png картинки;
— Заюзали Ray (такой низкоуровневый фреймворк для качественного распараллеливания python кода) внутри кернела, чтобы быстрее процессить картинки. Запускали 2 процесса, каждый использует по 0.5 P100, ускорили процессинг картинок с 10 часов до 7. Я дико топлю за Ray, в первую очередь как замену Spark, сделаю отдельный пост скоро;
— Вспомнили, что вообще-то старый CV не сильно мертв, и определять, есть ли на картинки клетки или мы опять фон нарезали, можно с помощью Otsu thresholding в HSV space.

Кстати, что такое MIL — часто бывает ситуация, что у нас дана одна метка на некоторую группу объектов. Это могут быть данные из разных источников, или, как в случае соревы, множество картинок, вырезанных из большой картинки.
Авторы топ 1 решения еще в 2020 году написали статью об интерпретируемом подходе построения MIL модели (Chowder), который все еще является SoTA для медицинских срезов.
В общем, супер молодцы, заслуженная победа, применили свой богатый опыт и свои же модели.

Про аугментации.

Я довольно давно не копался в CV. Последнее, что я помнил — albumentations лучшие в плане скорости работы и ассортимента методов в API.
С тех пор не сильно что-то изменилось, кроме того, что я успел подергать torchvision в Мете, и он мне реально понравился в плане удобства и скорости работы.

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

Ну во-первых, все решили, что для foundational моделек аугментации не нужны, так как данных и так достаточно.

Дальше появились интересные решения вида kornia и NVIDIA DALI с возможностью делать аугментации прямо на GPU, за счет чего получать весомый буст в производительности.
Мне очень не нравится бенчмарк, предоставленный albumentations. Ровно потому что они:
— сравнивают отдельно по операциям;
— оценивают скорость в количестве обрабатываемых картинок в секунду.
Это логично, если мы исходим из предположения, что весь пайплайн аугментаций работает со скоростью самой медленной операции в нем. Ну и, дополнительно, из предположения, что аугментации происходят сразу после загрузки, по одной картинке за раз (то есть MixUp и CutMix выпадают).
Но кажется, что на самом деле первое утверждение не совсем корректно, так как не учитываются оверхед самого фреймворка аугментаций и вероятностная природа применения разных аугментаций в пайплайне. Дополнительно — техника развилась настолько, что уже выгоднее обрабатывать картинки батчом, а не по одной.
Уже больше нравится бенч от Kornia, но они, таким образом, просто пытаются показаться свою главную фишку — аугментации батчей прямо на GPU.

Короче, очень хочется собрать ultimate бенчмарк для аугментаций и посмотреть, кто из списка torchvision/albumentations/kornia/augmentor/solt/dali лучше, может быть вы что-нибудь подкинете из идей?

Про бенчмарки загрузки png картинок.

Ужасно сгорел, перебирая разные способы загрузки png картинок. Настолько, что сел искать разные замены PIL. Так я наткнулся на бенч из поста выше и решил немного допилить его под png.
Сводные результаты для картинок размером около imagenet (300х300) и огромных (10к х 10к) прикрепил.
Ссылку на код закину в комменты.

Из интересного:
— Torchvision стабильно аутперформит всех и вся (почти) для jpeg и png. Кажется, что вместе с аугментациями из torchvision.transforms вообще имба;
— Pyspng (обертка над libpng) — тоже хорош для png, но ограничен в плане API, только чтение/запись и все;
— Pyvips расстроил совсем; насколько сильно я наслаждался удобством и скоростью работы imgproxy (под капотом libvips), настолько же сильно я расстроился от скорости работы pyvips :(

Поучаствовал в прошлом месяце в UBC-Ocean сореве вместе с Димой. Больше ради того, чтобы вспомнить (а где-то и узнать), что там такого в компьютерном зрении происходит.

Суть соревнования простая — есть снимки проб человеческих тканей, надо распознавать тип рака.
Но, конечно, есть несколько нюансов:
— Есть два типа картинок: WSI (whole slide images) и TMA (tissue microarrays). TMA — это 40-кратный зум среза, при этом картинки “небольшого” размера — 4к на 4к. WSI же без зума, но и размер дичайший — в среднем 40к на 40к пикселей, самая большая — 50к на 105к, 4.7 Гб в uncompressed png. Довольно часто 50% картинки просто фон, надо было еще поискать, где на картинке клетки;
— Жуткий перекос распределения типа картинок в трейне (95% WSI и 5% TMA). При этом в тесте 50/50 соответственно.

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

Пара полезных ссылок:
— прекрасный рассказ от бывшего коллеги про transforms второй версии в torchvision. Пользуйтесь активнее, они вышли в стейбл, быстрее, чем первая версия, и, по моему субъективному мнению, быстрее, чем albumentations;
— хороший бенчмарк по загрузке больших картинок, разобраны jpeg и tiff, я дописал этот бенч для png формата.

Я потихоньку копаю историю про затачивание LLM-ок под свои задачи, желательно с инференсом на ноутбуке/смартфоне. Очень зацепила история про то, как дообучать большие модели меньшими ресурсами.
Собственно, про LoRa и QLoRa сейчас из каждого утюга, я вам принес разбор первой.
LoRA (Low-Rank Adaptation of Large Language Models) — это один из способов дообучать любую большую модель меньшим ресурсом (впрочем, можно применять и для большой линейной регрессии). Активно используется в файнтюнинге LLM-ок и диффузионных моделей. К тому же это прекрасное обобщение самой идеи дообучения моделей, ведь, если сложить все шаги градиентного спуска в процессе, мы получим такого же размера матрицу, агрегирующую все изменения.
Ссылка на статью
Мой разбор

Channel photo updated

Этот год был тяжелым во всех смыслах. Но в то же время он был вдохновляющим и интересным.
В отпуске в Шотландии у меня было время поразмышлять о том, каким будет следующий год. И вот к каким мыслям я пришёл:

— мы все больше будем видеть применение больших моделек на персональных девайсах. Вычислительная фотография там уже давно, ждём звук и текст. Мне нравится движение вокруг ollama comfyui. Компании медленно начинают выпускать статьи про дешевый инференс моделей (Apple — про shared memory , китайцы про cpu+gpu инференс). В общем, я лично жду суммаризацию текста или локальный перевод в следующем релизе айоси;

— рыночек видеокарт наконец-то разрешится, и Nvidia начнет делать свое облако. Что-нибудь на уровне цен vast.ai, но sla получше. Кто, как не Nvidia, знает, как правильно настраивать сеть/вычисления?

— все больше крупных компаний будет стараться вкладываться в опенсорс. При этом мы чаще будем видеть мелкие модели, заточенные под определенные задачки (вроде поиска по налоговому кодексу РФ).
Кстати, из ближайших примеров Ferret — свежий дроп от Apple, мультимодальная ллмка, по сути другая опенсорсная моделька (Vicuna), немного дообученная;

— также мы увидим много новых продуктов, выстроенных вокруг опенсорса. В целом это новый старый тренд, строить продукт вокруг открытого кода. Посмотрим, что из этого получится, мы уже проходили Nginx, Aerospike, Databricks, Hortonworks;

— больше продуктов, использующих большие модельки, перейдёт из стадии ресерча в продакшн. Жду генерацию дашбордов в Tableau по одному сообщению продакта в телеге или автоматический Speech to Text в Goodnotes;

— уже к маю рассчитываю на несколько исков по новоиспеченному EU AI Act. Возможно, даже попробуют подушить TikTok на раскрытие работы их рекомендательной системы, под предлогом влияния на человеческое поведение;

— больше всего я радуюсь тренду на MLOps тулзы, надеюсь, он продолжится. MLOps сейчас будто те самые лопаты во времена золотой лихорадки. Хотите MLOps платформу как расширение к Postgres — держите PostgresML. Может вам хочется удобный мониторинг для своих фичей/моделек — держите Evidently.
Мы в sanas.ai сделали свой cli для запуска распределенного обучения/сервинга моделей, но даже под такое есть стартап — dstack.
В общем, я безумно рад такому усиленному вниманию к вопросам продуктивности и психологического здоровья ML инженеров.

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

Коротко про навыки ML инженера

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

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

Инфраструктура обычно скользкий вопрос.
Авг ответ: а зачем я должен разбираться в этом, есть же специально обученные люди?
Ну в целом и ответ тоже базированный: может быть тогда проще научить девопса запускать фитпредикт? Заодно сэкономим на ФОТ.

Если вы понимаете, как работает инфра — вы можете быть более продуктивны. В целом считаю, что написать Gitlab CI пайплайн — это не так сложно. Уметь писать докерфайлы — базовый навык инженера уже.

В общем, теперь всегда на собесах спрашиваю что-то наподобие:
- в чем разница между cmd и run в dockerfile?
run описывает как надо собирать образ, а cmd — что нужно по дефолту запускать при старте контейнера;
- в чем разница между докер образом и докер контейнером?
Образ — описание, как нужно будет запускать исполняемую «виртуальную» среду, а контейнер — сама исполняемая среда.

Если хочется детальнее поизучать про Docker и Kubernetes, рекомендую почитать «Kubernetes в действии» Марко Лукша. Книга не первой свежести (2018 год), но все еще актуальная, хорошо описывает базу.

Рекомендаций книг пост

В 2020 году я прочитал «Проект Феникс». Увидел множество рекомендаций этой книги в чате ctodaily (чат при канале Самата, ведущего подкаста «Запуск завтра»), так и дополз.

Эта книга написана в довольно интересном жанре «бизнес-роман». Если вкратце про жанр – это попытка донести какую-то бизнес-концепцию с помощью незамысловатого сюжета. Другие интересные примеры этого жанра – «Цель» Голдратта про оптимизации процессов и «Deadline» ДеМарко про управление проектами.

Книга в целом пытается донести до вас философию DevOps (по состоянию на 2013 год) и как научиться управлять разработкой, чтобы продуктивность вашей команды была на высоте.

Книга написана от лица менеджера, который должен в срочном режиме выкатить продукт. Этот продукт разрабатывался предыдущие два года без нашего менеджера и на 90% состоит из говна и палок. А ещё у него огромный бэклог техдолга и неправильных решений. Ничего не напоминает?

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

Недавно разговаривал с другом, который только читает книгу, забавно, что у нас схожие впечатления от прочтения.
Решил прогуглить, оказалось, что в 2019 году вышла вторая книга «The Unicorn Project». Это не совсем продолжение, скорее другой взгляд на события первой книги глазами разработчика этого продукта. Так как книга более свежая, она учитывает рост екома и появление новых технологий около devops. Пока прочел только треть, но чувствую опять прилив мотивации в стиле: да, продуктивность разработки супер важна, локальность и простота изменений, погнали.

TLDR: хотите вновь прочувствовать, почему вы так любите разработку – прочтите "Проект Феникс".

За годы работы я прошел несколько стадий принятия оркестрации ML/Data пайплайнов.

Сначала в моей жизни был планировщик Windows. Это была Lamoda, я обкачивал Google Adsense и Google Analytics ежедневно и складывал это в Postgres, развернутый рядом. Волшебное время, Windows может в хорошие решения (иногда).

Потом в Mail.ru был Luigi в качестве контроллера исполнения DAG’ов и Jenkins в качестве контроля расписания. До сих пор вспоминаю Luigi с теплотой, тогда он казался мне вершиной инженерии. Удобный визуализатор, возможность локально потестить код, свободная передача данных между задачами в одном DAG’е — очень приятно и очень удобно.
Из минусов — приходится ставить на расписание отдельным сервисом (cron, Jenkins, etc).
Интересный факт — когда я устроился в другое подразделение Mail.ru через год, мне продолжили приходить письма о падениях DAG’ов, которые я написал несколько лет назад.
С — стабильность.

Следующим был шаг обратно к истокам — помесь bash и python скриптов, которые деплоились и ставились на крон на конечные физические машины с помощью самописного аналога Ansible. Ад редкостный, особенно в разрезе мониторинга падений (его не было).

Дальше был Сбермаркет с Airflow+K8s. Проблемы с тестовыми стендами, невозможность запустить код локально, опять разделение кода исполняемого и кода DAG’а — все это приводит к фрустрации и снижению скорости разработки. Еще из минусов: мне крайне негативно отношусь от концепции XCom (cross-communications). Выглядит как огромный костыль для возможности передачи данных между задачи в DAG’е (и не только в нем).
Есть, конечно, плюсы: расписание из коробки, возможность отвязаться от физических машин (только благодаря куберу), удобные средства мониторинга падений.

В последние годы появилось множество других оркестраторов — Prefect, Dagster, Metaflow, Flyte. Каждый имеет свою специфику и область применения, конечно, но приятно, когда есть выбор.
Если вы вдруг задумались, какой планировщик вам выбрать сейчас — я определенно посоветую вам Dagster. Супер приятный, все лучшее, что можно взять из Luigi, Cron, Airflow — все это есть в нем. Особенно радует возможность протестировать код прямо локально, довольно просто развернув мини Dagster локально (одной командой!).
Мой коллега как раз недавно рассказывал на Dagster community day про то, как мы мощно прогоняем за пару часов миллионы аудио файлов через несколько нейронок с помощью Dagster+Ray.
Стоит упомянуть проблемы:
– Backfill задач пока experimental фича;
– Есть автоматериализация downstream задач при запуске upstream, но наоборот — придется повозиться.

TLDR: Берите Дагстер, не пожалеете

Кстати, что такое RAG?
В последнее время напридумывали множество новых терминов, под которыми скрываются давно придуманные истории.
Собственно, RAG — Retrieval Augmented Generation. Если говорить простым языком, это попытка предоставить внешние знания, например документацию по какому-то продукту или весь уголовный кодекс РФ, напрямую в LLM. Зачем? Чтобы удерживать ее внимание в рамках нужной нам задачи. По сути, мы говорим: генерируй ответ только на основе предоставленной тебе информации.
Сразу представляется волшебный мир будущего:
Пользователь — Как мне правильно оформить декларацию для налогового вычета?
Сервис — Чтобы корректно оформить налоговую декларацию по форме 3-НДФЛ, вам нужно перечислить все ваши доходы от различных источников с указанием типов деятельности.
Любая базовая LLM модель скорее всего выкинет странный ответ, не только неправильный, но и возможно вредный. Вот поэтому надо ограничивать генерацию источниками информации
Есть разные подходы, как это делать:
– Взять уже обученную модель, для каждого входного запроса предварительно искать в нашем корпусе кусочки текста, похожие на запрос пользователя, и хитро подставлять их в конечный инпут модели;
– Дообучить базовую модель на нашем корпусе, надеясь, что она все запомнит и не будет галлюцинировать;
– Взять уже обученную модель, для пользовательского запроса искать похожие кусочки текста, потом той же моделью одним промптом просить перевести в единый укороченный контекст, затем подставить этот контекст в следующий промпт для получения финального ответа;
– Дообучить модель, используя промпты как в первом подходе.


В 99% случаев, когда вам продают RAG, это будет первый подход. По сути, зумеры прикрутили к промпту быстрый поиск ближайших соседей, и вот как раз для этого нужны векторные базы данных. Что-то похожее делали 10-20 лет назад разрабы из Гугла/Бинга/Яндекса/etc. Раньше сильно беспокоились за качество выдачи, за точность ответа, но в 2022 OpenAI показали нам, что на это можно забить, продукт важнее, чем неправильные ответы.

Копаясь в различных реализациях RAG пайплайнов, задался вопросом: А почему в векторных базах данных считается нормой передавать вектора эмбеддингов (некоторый набор чисел с плавающей точкой) через HTTP JSON API?
Я, конечно, понимаю, что очень просто сбоку прикрутить FastAPI/Tornado/Flask/etc, но как же потеря точности при сериализации/десериализации объектов?
Каюсь, раньше и сам так делал, храня сериализованный json как значение в Redis, типичная особенность MVP.
Как это можно обойти — уйти от REST с тасканием туда-обратно строк в сторону бинарных форматов. Лучше всех здесь смотрится GRPC, причем вы из коробки получите более надежное и быстрое взаимодействие с сервисом. Еще можно посмотреть FlatBuffers, но могут возникнуть сложности.
Что еще вы получаете от GRPC — типизацию из коробки (Pydantic не нужен), меньший объем данных за счет бинарного формата, отсутствие потерь точности. А также зафиксированный контракт обмена данными с вашим сервисом.
Прошерстив документацию 10 самых популярных vector database (растут как на дрожжах), пришел к неутешительному выводу — половина этих баз либо не имеют GRPC API, либо такой функционал только в бете.
Отдельно хочется отметить две базы:
1) Qdrant — написанная на Rust с нуля, очень приятно смотрится в бенчмарках(1000+ rps, в 3 раза больше weaviate или milvus, wow).
2) LanceDB — опять же Rust, к тому же можно делать serverless(наподобие RocksDB, SQLite). Ребята написали свой собственный формат хранения и выложили в опенсорс, что не может не радовать.
Немножко пояснил за protobuf-ы отдельно:
https://telegra.ph/Proto-Explanation-12-10

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

Что дальше? Наверняка через пару дней/спринтов к вам придет продакт и потребует улучшений, так бейзлайн хорош, но недостаточно.
Можно начать копать в сервисы, можно попробовать поулучшать текущую модель.
Есть прекрасная идея от моего бывшего коллеги: давайте обучим две модели.
Одна — простая, линейная регрессия на расстоянии, другая — большая (например, бустинг), на большем наборе признаков, какие вы только можете придумать, за исключением расстояния. Примеры признаков — различные агрегаты, вроде средних скоростей доставки,сборки,количества айтемов, заказываемых из точки.
Дальше просто, ваше предсказание — это ax+b+GB(y). Что мы можем сделать? Конечно же посчитать b+G(y) разово для магазина и заливать как один из параметров в базу.
Затем повторяете это упражнение раз в 1-3 дня, и качество вашего предсказания становится ощутимо лучше, чем предыдущий бейзлайн. Не забудьте измерить качество в оффлайне и онлайне.

Мне кажется, что самое важное в жизни любого ML-щика — умение строить бейзлайны (простенькие эвристические модели или что-нибудь из класса линейных).
Прежде чем строить огромные космолеты, которые требуют кластер из 64 Nvidia H100, построй свой маленький бейзлайн. В идеале что-то простое, наподобие “ax+b” или “a if x>b else c”. Дальше на этом можно измерить оффлайн метрики, выкатить в прод или в АБ/свитчбек тест, посмотреть продуктовые метрики.
Такая база позволяет выстраивать корректную систему оценки не только экономического эффекта, но и всех последующих улучшений в разрезе Reach, Impact, Confidence и Effort. Про RICE в планировании ML расскажу как-нибудь отдельно.
Легковесные бейзлайны к тому же позволяют довольно просто интегрироваться в обычную продуктовую разработку.
В итоге одни плюсы:)

Всем привет, меня зовут Сергей Чепарухин, я ML инженер, иногда менеджер, а в данный момент DL/ML Ops консультант.
Как-то на закате третьего десятка меня настиг кризис самоидентификации.
Интересно обнаруживать себя в ситуации, когда тебя перевезли в Лондон, дали достаточно денег и уволили. Сразу зажигается огонек в заднем проходе и желание доказать всем, что ты можешь еще лучше. Главное понять, чем ты хочешь заниматься в будущие пару лет (мы же не размениваемся по пустякам, да?).
Собственно, на волне размышлений о том, чему я научился за предыдущие 9 лет и как это можно использовать в будущем, я решил создать этот канал.
Постараюсь делиться здесь своими мыслями, статьями и странными идеями для проектов.

Channel created