Ох уж эти конфликты: Консоли против ПК, Linux против MacOS, новостные каналы против здравого смысла.

Весь код, сгенерированный при помощи Cursor AI, вам не принадлежит!

Видели, да, такие заголовки? Я последнее время ловлю себя на мысли, что чем громче заголовок, тем больше это пиздеж. Основной поинт в статье был, что в соглашении курсора есть пункт, который в оригинале звучит так:

"…Notwithstanding the foregoing, you acknowledge that Suggestions are generated automatically by machine learning technology and may be similar to or the same as Suggestions provided to other customers, and no rights to any Suggestions generated, provided, or returned by the Service for or to other customers are granted to you under these Terms"

Который почему-то перевели что "Вы не получаете права на предложения ИИ", т.е в смысле что вам не принадлежит сгенерированый код. Но если читать внимательно, то смысл в том, что вы не получаете права на предложения, которые получили другие пользователи, даже если они совпадают с вашими. Вы не можете заявить, что кто-то "украл" у вас ответ, если ИИ дал такой же кому-то ещё.

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

Варианты, как ускорить пайплайны.

Ладно, продолжим по CI. Переходим к более практическим темам.

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

При этом первый вариант, который нужно рассмотреть для ускорения пайплайнов, — тупо купить лучшее железо для Runner и увеличить число самих Runner'ов. Это будет один из самых дешёвых вариантов. Если же вы уже упёрлись в железо, вот только тогда на сцену выходят они:

👉 Предпочитаем CLI вместо Gradle. Упоминал про это тут. Суть в том, что мы часто делаем через Gradle вещи, которые можно написать в 10 строк кода на Python и не тратить время на инициализацию. Поэтому золотое правило: если что-то можно делать без Gradle, лучше делать без Gradle.

👉 Параллелизация (динамические пайплайны). Упоминал этот вариант ещё в посте про тесты на CI. Мы можем ускориться, запуская тесты не в одной job, а, например, в трёх, которые будут выполняться параллельно. Да, потребляем больше runner’ов, но повышаем скорость пайплайна. Можно делать фиксированное количество job, а можно использовать динамические пайплайны, чтобы количество job зависело ещё и от количества тестов.

👉 Импакт-анализ. Работает только в больших проектах с множеством модулей. Зачем нам запускать линтер на весь код проекта, если мы изменили только один модуль? Запускаем линтеры и тесты только на изменённых модулях.

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

👉 Специфика GitLab CI. В GitLab CI есть два варианта, как задать зависимости между job: dependencies и needs. Работают они по-разному. dependencies ждёт не просто указанную job, а вообще весь предыдущий stage. Из-за чего вы могли уже запустить какой-нибудь linter, но ждёте весь stage с билдом. needs же игнорирует предыдущий stage и запускает job сразу, как только закончила выполняться зависимая job. Поэтому предпочитайте needs, а не dependencies в пайплайнах.

Расскажу про свой проеб с памятью. Делал я одну систему для импакт анализа. В этой системе нужно было хранить Coverage, чтобы потом по нему определять, какие тесты были затронуты. Изначально структура представляла собой вот такой json:

{
  "ru.package.SomeClassName": [
    {
      "line_number": 1,
      "tests": [
        {"testId": 1},    
        {"testId": 2}]
    }
  ]
}

Я упростил структуру, чтобы впихнуть в пост, но суть сохранил. Поясняю: для каждого класса мы храним номера строк, и у каждой строки — массив объектов-тестов.

Загадка от Жака Фреско: где тут проблема?

Проблема в том, что у каждой строки мы храним именно объекты, которые ещё и дублируются для каждой строки. Стоит добавить какое-то поле в этот объект — и размер этого JSON сразу улетает в космос. Первая версия структуры весила 1 ГБ.

Фикс заключается в том, что мы выносим объекты тестов в отдельный массив, а в строках оставляем только ID. Это уже позволило сократить размер в 4 раза.

Затем я подумал: «Вот, Google же придумал более оптимальный формат — Protobuf. Бинарный формат, который вообще должен ещё в разы сократить Coverage».

Я был мал и глуп, не видал больших залуп, поэтому просто перевёл структуру на Protobuf. В kotlinx serialization это делается просто подключением зависимости.

После Protobuf структура стала весить около 200 МБ. Не значительная экономия памяти, но неплохо. Я решил, что это максимум, который можно выжать. Инфра у нас быстрая, Coverage скачивался за секунды, и я не видел смысла что-то ещё копать.

До того момента, пока не пришёл матёрый iOS-ник и не сказал:

— Ты шо, ебанутый? Почему просто не использовал gzip?

Честно говоря, у меня не было ответа на этот вопрос. Я почему-то думал, что Protobuf эффективнее gzip. Однако на самом деле Protobuf вообще не про компрессию — он вообще другие проблемы решает.

Попробовал я gzip на нашей структуре. Угадаете результат?

Да, 20 МБ.

Дэээ… Что сказать… Скиллов убавилось, количество хромосом возросло.

Поэтому перед переходом на модные структуры пробуйте для начала дедовские методы — они чаще всего работают лучше.

Если смотреть на статистику моего канала, то можно увидить, что посты, которые набирают максимальное количества просмотров, комментариев и реакций это посты где есть упоминание: собесов и качалки (что не удивительно 90% мужской аудитории).

Поэтому для вашего удобства я собрал посты про собесы, вдруг вы какие-то пропустили:

👉 Советы по прохождению алгоритмической секции
👉 Как избавится от волнения перед собесом
👉 Как перестать боятся графов
👉 Разборы задачек: раз и два
👉 Самый забавный собес в карьере

P.S посты про качалку я в другой раз соберу, а то пока там мало совсем, поэтому ждите. erid: 2W5zFGw3MPe

Чисто мои будни

Несмотря на то, что я — Android-разработчик (пока ещё), последние лет семь пользуюсь только iPhone. В этом нет никакой сложной причины — мне просто так удобнее. При этом я не считаю, что все Android-устройства — херня из-под коня, каждый выбирает под себя.

Самое забавное вот в чём: все эти семь лет я слышу одно и то же — «Ты же Android-разработчик, чего ты с iPhone ходишь?» Я, если честно, вообще не понимаю, в чём тут связь и почему я должен ходить именно с Android-устройством? Знать фичи системы? Так они практически идентичны, друг у друга концепции тырят.

Прикол ещё в том, что до такого можно доебаться только до мобильного разработчика. Представьте, как было бы забавно, если бы с такими комментариями обращались к ребятам из других сфер.
– «О, ты ML-инженер и используешь ChatGPT? А чего свою модель не обучил?»
– «О, ты разработчик embedded-систем, а чего вообще смартфон купил, а не собрал в гараже свой?»
– «О, ты ведущий Android подкаста, а не подскажешь какой стол купить? Я все никак выбрать не могу(»

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

Оставим за скобками мудаков, которые начали меня оскорблять за использование операционки, которая им не нравится. Помимо этого, было много слов про вовлечённость, ценности и даже предательство. Вы, блядь, «Россию 1» что ли насмотрелись?

На фоне такой ожесточённой дискуссии я захотел накидать пару строк про вовлечённость — тема-то интересная. Все мы боимся показаться не «вовлечёнными», иначе очередная Xsolla придёт и уволит нас одним днём.

Есть такое понятие, как dogfooding, означающее, что разработчики используют свой же продукт. Это позволяет им встать на место пользователя и увидеть неочевидные на первый взгляд проблемы. Dogfooding — хорошая практика, и вам отчасти повезло, если у вас такое есть.

Однако dogfooding не подразумевает, что ты будешь пользоваться только той платформой, под которую разрабатываешь. Почему ты «не вовлечён», если используешь свой же продукт, но через другую платформу? В этом случае я точно так же могу прийти к разработчикам и зарепортить им баг.

Представим ситуацию: ты фронтендер и работаешь над банковским сайтом. Помимо фронта у банка, разумеется, есть мобильные приложения. И что, теперь ты вынужден пользоваться только браузером, иначе ты «не ценишь свою платформу», предатель?

Думать, что dogfooding возможен всегда, — это крайне узкий взгляд на индустрию. Вот я работаю над приложением для ИП и ООО. У меня нет бизнеса, я в принципе никак не могу пользоваться своим творением, но это не мешает мне делать свою работу хорошо.

Есть приложение для девушек Flo, позволяющее отслеживать цикл. Ну че, пацаны, как тут будем вовлечённость поднимать?) А если я разрабатываю приложение для знакомств, но у меня счастливый брак?

Бизнесу по большей части похуй, насколько ты вовлечён. Есть только один показатель: ты либо приносишь бабки, либо нет. Если ты не приносишь прибыль компании (напрямую или косвенно), то тебя уволят, и неважно, насколько ты там лояльный и «вовлечённый» сотрудник. Кричать про предательство и вовлечённость — это похоже на каприз маленького ребёнка.

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

На чистоту, найти работу было в разы проще, чем девушку. Вспомните вот эти мемы, где у девочек в Tinder'е — 100500 предложений, а у мальчиков в LinkedIn.

Ну так вот, кажется мы в том промежутке времени, где работу найти сложнее.

{1/2} Подходы для отладки пайплайнов

Сейчас будет лонгрид, на две части, так что соберитесь!

Как только я сел писать данный пост, я понял один прекол. Все мои best practices работают только для GitLab CI и GitHub Actions. Для остальных систем эти советы могут быть не особо актуальны.

В GitLab CI и GitHub Actions конфигурация пайплайнов хранится в репозитории вместе с основным кодом. Это дает плюсы вроде: версионирования, коллаборации, документированности и того, что вся конфигурация находится в одном месте. Минусы же такого подхода в том, что ты не можешь протестировать пайплайн, не смержив новые изменения.

На примере: у тебя есть Job с билдом и Job с тестами. Job с билдом работает хорошо и стабильно, а Job с тестами ты пытаешься настроить. В CI системах у тебя нет возможности изменять Job с тестами, используя результаты из Job с билдом. Для проверки правильности твоих изменений тебе нужно запускать весь пайплайн, и это главная проблема в их отладке.

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

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

{2/2} Подходы для отладки пайплайнов

👉 Делаем дебажное правило, которое позволяет запускать пайплайн на любой ветке по API. В GitLab CI выглядит примерно так:

rules:
    # Тут будут основные правила запуска
    - if: $PIPELINE_TYPE == "DEBUG_MR" # это правило позволяет запустить пайплайн на любой ветке, без создания МРа через API

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

👉 Используем конструкцию с echo, чтобы понять, с какими аргументами запустили программу. Например, вы в Job вычисляете какие-то параметры, чтобы потом запустить Gradle. У Gradle, как вы знаете, логи ублюдские, поэтому проще узнать, а с каким параметром мы вообще его запустили. По умолчанию в логах Job не будет этой информации, однако вот такая конструкция легко позволяет ее получить:

echo "./gradlew some-task $args"
./gradlew some-task $args

👉 Канарейка. Внезапно, да, можно использовать канарейку и в CI/CD. Может возникнуть вопрос, нахера в CI/CD-то оно нужно. Дело в том, что на большом проекте, когда у вас орда разрабов, которые что-то постоянно пушат и создают МРы, вам желательно (но не обязательно) не косячить в пайплайнах. Мы помним, что при обновлении пайплайнов не все сразу перейдут на новую версию.

Поэтому, когда вы, например, добавляете новую экспериментальную Job, очень крутой подход — сделать эту Job под флагом. Флагом, который вы в случае чего можете быстро выключить в консоли CI системы:

rules:
    - if: $FEATURE_NEW_JOB_ENABLED == "true"

👉 Проектируйте логи. В разработке CLI нужно проектировать то, что вы будете выводить в консоль, также тщательно, как вы проектируете UI для приложений. Ничего лишнего, только самое нужное. Помимо этого, у вас должна быть возможность включить прям максимум логов, чтобы отследить каждый шаг.

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

👉 База. Ну и, разумеется, очевидные советы, вроде: используйте cat и echo в скриптах, чтобы понимать, что происходит, в bash-скриптах не забывайте использовать set -x, чтобы видеть все команды, не забывайте проверять наличие файлов перед их использованием.

И самое главное, ни при каких обстоятельствах, чтобы не происходило с вашей карьерой, не ешьте желтый снег!

Меня так бесит, когда я описываю идею какой-то статьи, и меня спрашивают:
— "А какую проблему решает твоя статья?"
Да никакую, блять! Это же не бизнес-идея, почему она вообще должна что-то решать?

Когда писатель садится писать книгу, он разве задается вопросом: "Какую же проблему мне бы решить моей книгой?". Нет! Он просто пишет, что ему по кайфу, и чтобы потом было по кайфу читать. На этом всё, никаких глубоких вопросов.

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

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

Продолжаем забавные истории с собесов

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

Представили их лица после этого? Вот с такими лицами они собеседование проводят. Полное отсутствие коннекта и каких-либо проявлений эмоций с их стороны. На каждом этапе я себя чувствовал, будто меня собеседует машина. Опять-таки, возможно, мне так повезло, возможно, сейчас там всё иначе, но конкретно в тот момент это прям было жестко.

Этапы были такие: HR → Android и Kotlin → Алгоритмы → Системный дизайн.

На Android и Kotlin были базовые вопросы и куча вот этих пазлеров про многопоточку. Помню, что я тогда прям задротил всё, что связано с многопоточностью, и точно ответил на все вопросы. Однако мне всё равно поставили Middle. Не знаю почему, возможно, я где-то промахнулся.

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

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

На системном дизайне нужно было спроектировать библиотеку аналитики. Про саму задачу и её решение я сделаю отдельный пост. Из интересного был только вопрос от собеседующего: «Как тестировать либу для аналитики?»

Хороший вопрос на подумать, ведь обычно мы баги отслеживаем по аналитике, а как понять, что баг именно в либе для аналитики? Ну, я предложил два вектора защиты:

👉 Системные логи, которые мы можем получить вместе с другими логами приложения.
👉 Интеграционные тесты, в которых мы прям бэк мокаем, чтобы проверить полностью работу либы.

Однако в фидбеке мне написали, что эти способы не являются оптимальными. ХЗ, уже много времени прошло, я так и не понял, какой способ оптимальный.

Собственно, как-то так. Если меня читают ребята из Авито — если что, без обид, я же любя ❤️

Ну что ребятки, финалим эту серию про CI, какие задачи лучше не делать в CI.

Присаживайтесь поудобнее мы погружаемся в инфраструктурный хардкор.

Лакмусовой бумажкой того, что задаче не место в CI — если в Job не нужно получать последнюю версию кода. Если для ускорения выполнения Job вы хотите отключить клонирование мастера, задачу точно нужно выносить в другую систему.

Например вы хотите пинговать разработчика, если у него упал пайплайн на МРе. Это не CI-задача, и нет смысла занимать под неё целый runner.

В идеале я бы советовал развернуть на серверах компании какой-нибудь n8n. Вы тогда получаете гибкий инструмент в котором можете развлекаться как хотите без влияния на пайплайны.

Требуется гибкая логика повторных запусков. В Gitlab и похожих системах есть retry, но весьма тупой. Он не позволяет задать условия повторного запуска, основанные на типах ошибок или внешнем состоянии.

Нельзя например сказать: «Повтори, если ошибка 500», «Повтори с экспоненциальной задержкой».

В этом случае лучше подойдут системы c возможностью описывать, при каких условиях и сколько раз нужно повторять шаг вроде Airflow, Prefect или Temporal.

Вас не устраивает линейная структура. Если у вас возникает желание, ах вот если бы сюда поставить if или какой-нибудь while, то это явно не про CI. Платформы вроде GitLab CI поддерживают только линейное выполнение без предусловий. Airflow, Prefect и Dagster позволяют описывать не только последовательность действий, но и условия, при которых они должны выполняться.

Вам нужен гибкий cron с историй запусков. В CI системах есть примитивный cron вроде: «запускай вот этот пайплайн каждый день в 12 ночи». Однако в задачах вроде дообучения моделей или каких-то бизнес процессах могут возникнуть потребность: «выполнять cron только по будням», «пропускать запуск, если нет входных данных», «догнать пропущенные даты если была ошибка».

Помимо этого в Gitlab CI еще и историю запусков по cron нельзя просмотреть, показывается только последний запуск, а этого может быть мало.

Пайплайн должен реагировать на внешнее событие. Поступление файла, вебхук, изменение записи в базе — CI не предназначен для этого. Он реагирует только на изменения в коде или cron.

Если логика основана на событиях извне, её проще и надёжнее реализовать в n8n или Prefect, где предусмотрены подписки на события, задержки и отложенные действия.

Подводя итог: CI нужен для тестов, сборок и деплоя. Всё, что выходит за рамки «выполни скрипт и проверь результат», особенно если это связано со временем, входными данными, внешними событиями или сложными зависимостями — должно выполняться в отдельных специализированых системах.

Если же данный пост показался вам слишком перегруженным и вы потерялись в названии кучи сервисов записывайтесь на мой авторский курс «Батя инфры» на котором я научу вас работать с данными системами и зарабатывать миллионы.

Меня это конечно задело. В прошлом посте был комментарий, что из-за того, что в постах у меня много длинных тире "–" вот таких. Велика вероятность, что пост сгенерирован через LLM.

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

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

Ну и я как тревожная личность пошел в другие каналы, в которых я на 100% уверен, что они ведутся людьми и посмотреть что там со стилем. Ну в 90% постов используются длинные тире, и либо мы все генерим контент через LLM, либо все же нужно смотреть на другие признаки.

Попалась в одной статье вот такая картинка.

Не ней расположены ожидания даты появления AGI от различных экспертов по искусственному интеллекту. Думаю вы сразу обратили внимание на ожидание от Джеффри Хинтона.

Сперва пару строк, кто вообще такой Хинтон. Хинтон – ученый, который по факту может считаться батей всего ML, ведь это он изобрел подход backpropagation, который является прям базой для всего глубокого обучения.

Так вот, вам не кажется, что его оценка, скажем так... немного читерская?) Ее буквально можно перевести как: "Ну хз, возможно появится в следующем году, а возможно через лет 30, че вообще доебались?". И вот он либо гений, либо очень не хочет прогадать с ошибкой)

Недавно слушал один подкаст, в котором очень матёрые ребята обсуждали книгу Дяди Боба. Кто меня давно читает, знает, как я к ней отношусь. Если что, вот серия постов.

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

👉 В "Чистом коде" рекомендуется делать маленькие функции, по 5–10 строчек, не более. Это дичь, а не совет. Делайте функцию не короткой, а понятной. Если у вас сложная логика, то пусть будет функция на 500 строк кода, но зато не нужно будет бегать по другим функциям, туда-сюда теряя контекст и не понимая, что происходит.

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

👉 Unit-тесты с моками. Я уже делал серию постов про тесты. Если кратко, unit-тесты в привычном понимании, про которые идёт речь в "Чистом коде" или книге по TDD, почти ничего не дают на практике. Да, сейчас их проще писать с LLM, и иногда это прям нужно. Однако в подавляющем большинстве случаев они только мешают. Всю свою карьеру я слышу: "Если ты поменял код, меняй и тесты". А толку от этих тестов, если они не позволяют делать рефакторинг без регресса?

Ну и в конце была очень крутая фраза. Можно по-разному относиться к чистому коду, однако будем честны: написать книгу, которую вся индустрия будет критиковать даже спустя 30 лет — это прям мощно...

Я всё-таки решил зайти в код Telegram. Задание выложили, и я подумал: дай-ка посмотрю, насколько там всё сложно. До этого я лишь пробегался мельком и особо не углублялся в кодовую базу.

Какой же это карнавал боли и страданий! Я правда готов признать: разрабы Gradle, вы чёткие ребята. Мне кажется, значимая часть компенсации разработчика, который работает с кодом Telegram, уходит на психиатра. Вот тут действительно современные знания Android-разработки идут по направлению нахуй, они вообще тут бесполезны.

Я бы в readme к проекту написал: «Оставь надежду, всяк сюда входящий».

Итак, качалка.

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

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

На текущий момент мой максимум 115, но на прошлой трене у меня уже 110 получается выжать на 3 раза, что означает, что 120 маячит вот уже прям перед носом.

Возможно, было бы и больше, если бы я не вьебал себе плечо на верёвочном парке месяц назад, но это уже отдельная история.