Короче, ребята я решил признаться. Несмотря на мою искреннюю любовь к typescript и качалке, мне нравятся женщины!

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

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

Итак, я навайбкодил себе синтаксический анализ кода Kotlin

У меня за последние два дня произошёл крутой AI-момент. Есть у меня одна CLI-тулза, которая ищет тесты на проекте. Ищет она их тупо, пробегаясь по всем файлам. Заглядываем в файл, пробегаемся по всем методам и вытаскиваем все, у кого есть аннотация "Test" и "AllureID".

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

Поэтому, чтобы не париться и при этом сделать стабильное решение, я затащил Kotlin embedded compiler. Он даёт полный карт-бланш на работу с AST. Однако есть ложка дёгтя — compiler весит под 70 MB. При этом я использую максимум полпроцента функционала.

Поэтому я решил: а дай-ка я навайбкодю себе свой анализ, который будет делать самый минимум, который мне нужен. В этом мне поможет мой безмолвный напарник в виде Aider и Claude под капотом.

Когда я дал Claude задачу верхнеуровнево, он, как и полагается ленивому разрабу, попытался всё сделать через regex. Пришлось его явно просить о том, чтобы он сделал машину состояний, а также сначала разбил код на токены и только потом провёл анализ и вытащил нужные мне данные. Я, конечно, знатно удивился, но он всё сделал с первой попытки – от меня потребовалась лишь правка в одном месте.

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

Далее я пошёл и вручную отрефакторил его код в более читаемый вид – сгенерированные тесты помогли убедиться, что я ничего не сломал.

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

В итоге я сделал нужную мне штуку за полтора дня. Без LLM я бы, наверное, потратил примерно неделю.

Что из этого можно вынести:

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

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

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

Короче, LLM не заменит разраба. Однако разраб, который умеет грамотно работать в паре с LLM, вероятнее всего заменит :)

Короче, я тестировал VK-знакомства в течении недели и вот, что я понял!

В целом, смерть в одиночестве не самая плохая альтернатива.

Недавно вспомнил, что хотел поделиться с вами одной статьёй – пожалуй, единственной, которая за последние несколько лет действительно отозвалась у меня в душе. Называется она: "Я программист, и я тупой"

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

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

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

Иду домой, зная что второго свидания не будет, но теперь она знает почему делать интерфейсы с одной реализацией – плохо

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

Еще я понял, что возможно нужно перестать писать посты из спортзала)

Первое место работы

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

Для меня, тогда ещё "зелёного" студента, мечтающего попасть в IT, это была буквально дверь в Нарнию. Куча людей за компьютерами: кто-то пишет код, кто-то обсуждает задачи, кто-то проверяет стенды на стенах (о них чуть позже). Одного взгляда на всё это было достаточно, чтобы понять – я должен приложить все усилия, чтобы попасть сюда.

Это была небольшая томская контора, которая делала медиакомплексы для автобусов и электричек. Те, кто живёт в Москве или Питере, возможно, даже замечали эти "телики", показывающие маршрут, погоду и новости. Многие думают, что это просто заранее записанное видео, но на самом деле всё устроено куда интереснее.

Медиакомплекс — по сути, машина под Linux, на экране которой на полный экран открыт браузер. Браузер ходит на локальный сервер за данными, а тот через MQ связывается с сервером контента. Локальный бэк подключается к "материнскому кораблю", чтобы обновить информацию.

Я пришёл туда на позицию полутестера–полуразработчика на Java. За год работы там было всё:

👉 Абсолютно безумный гендир, который раз в месяц залетал с идеями вроде: «А давайте сделаем приложение, чтобы пассажиры могли менять подсветку в автобусе».
👉 Самый саркастичный архитектор за всю мою карьеру — смысл советов которого до меня доходит только сейчас.
👉 Проектировщик интерфейсов, который вейпил, крутил спиннеры, делал свою настойку, и я клянусь — я ждал, когда он приедет в офис на гироскутере.
👉 Фронтендер с личным стилистом, который подкатывал ко всему, что движется.
👉 Тестировщик, который блять, оставил у себя Кольцо Всевластия, потому что вообще не стареет, и с которым мы каждый час ходили на турник.
👉 HR, которая при увольнении пугала тем, что занесёт в «чёрный список», и тогда тебя вообще больше нигде не возьмут на работу.
👉 Главный бухгалтер, которая в свои 40 лет выглядела так, что поднимала настроение (и не только) у всего мужского коллектива.

И при всей своей всратости условий — я всё равно вспоминаю эту работу с какой-то ностальгической теплотой.

Detekt

Кто-нибудь заглядывал в исходники Detekt? Если вы этого не делали, то я рекомендую заглянуть туда хотя бы одним глазком, потому что это реально произведение искусства. В репозитории — просто кладезь крутых подходов: как работать с Gradle, с Classloader, с Serviceloader, и как правильно проводить архитектурные границы. Помимо этого есть примеры того, как писать тесты на Gradle плагин.

Все привыкли воспринимать Detekt как плагин для Gradle. Вы замечали, что у него довольно странная инициализация? Сначала нужно установить плагин, а затем отдельно указать версию Detekt. Возникает вопрос — нахера? Я же уже установил плагин, почему я должен ещё раз указывать версию?

Если посмотреть на первые коммиты, то Detekt изначально не имел ничего общего с Gradle — он создавался просто как CLI. И до сих пор его можно использовать без Gradle. Без Gradle будет геморойнее настроить работу, но зато не будем тратить время на конфигурацию.

Фишка в том, что весь плагин Detekt для Gradle сводится к тому, чтобы просто вызывать CLI-версию с информацией, которую мы прописываем через Gradle-плагин. Другими словами, плагин Detekt для Gradle — это просто платформа, которая скачивает CLI и затем его вызывает. Именно поэтому и получается такая странная инициализация: она позволяет изменять версию Detekt без изменения версии самого плагина.

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

Итак, сплав

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

Как это присходит: мы летим в Пермь в четверг, затем в пятницу утром мы грузимся в автобус и фигачим 4-5 часов в глушь. После берем свои вещи, упаковываем в гермомешки, грузим их на плоты и гребем по реке до вечера. Если вы работали в аутсорсе, для вас ничего необычного.

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

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

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

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

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

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

В итоге активность 10/10, но не рекомендую если вы в своем уме)

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

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

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

Истории с собесов:
👉 Самый забавный собес в моей карьере
👉 Собес в Авито
👉 Собес в Aliexpress
👉 Советы по прохождению алго-секции
👉 Как уменьшить волнение перед собесом

Истории и рофлы:
👉 Мой каминг-аут
👉 Про первое место работы
👉 Как я попал в инфру
👉 Какого это работать в БигТехе
👉 Приключения мобильного разраба в мире инфры

Для любителей сериалов:
👉 Про CI
👉 Про тесты
👉 Про DI

Немного базы про разработку:
👉 База программирования в одном посте
👉 Советы, как не проебаться в работе
👉 Как я навайбкодил синтаксический анализ
👉 Оцениваем сроки
👉 Что такое архитектура
👉 Разгоняем про логи
👉 В IT нет научного подхода

Boost канала для неравнодушных

Топ 3 мифа, веря в которые вы гарантировано проебетесь по жизни:
👉 Хороший продукт/блог сам себя продаст
👉 Хорошего работника сами заметят и продвинут
👉 Любовь сама себя найдет

Вам разумеется может повезти, но если вы в своей стратегии полагаетесь на удачу, то вы лудоман!

Итак, погода.

Короче город дождей этим летом вообще не оправдывает свою репутацию. Ощущение такое, что на фоне уже должен играть Мик Гордон.

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

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

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

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

Вот парочка самых простых шаблонов:

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

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

Поиск в глубину / ширину – делал про это пост, там всё не так сложно, как кажется. Пример задачи.

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

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

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

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

При этом большая часть людей, которые меня читают, подписались именно тогда, когда я писал только про Android.

Поэтому, по старой памяти, хочу рассказать вам про вот такую папочку с блогами именно про Android-разработку – возможно, кого-то из вас это заинтересует.

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

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