Dev Easy Notes

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

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

Что такое Task Queue?

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

Для этого в мобильных системах есть специальные механизмы WorkManager в Android или BGTaskScheduler в iOS. Концептуально одинаковая идея, прописываем логику, задаем условия когда нужно сделать и затем система запустит эту задачу. Ну или не запустит, мобильная разработка хуле.

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

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

Суть в том, что мы сначала сохраняем данные для выполнения задачи в базу. Этим мы уже контролируем что задачу мы не потеряем. Затем отправляем событие в какую-то очередь часто это redis, но также используют Rabbit MQ или kafka. Далее есть воркер который случает очередь и берет таски на выполнение. При этом инстанс который сгенерил задачи и который ее затем исполняет может быть один и тот же.

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

Что общего у бэкенд, мобильной и фронтенд разрабоки? Отсуствие желания жить в трезвом мире подумаешь ты, но нет!

Во всех этих областях хороший разработчик всегда держит в голове, что контекст пойдет по направлению в /dev/null (ну или нахер в простонародье).

В мобильной разработке Activity или UIViewController может быть уничтожена в любой момент. На фронте или компонент умирает в зависимости от фреймворка либо вся страница выгружается браузером.

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

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

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

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

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

Вчера я впервые уперся в лимит рабочего Claude Code. Попытался за 4 часа сделать то, что обычно делают неделю. Нейронки на самом деле приучают тебя к work-life balance. Уперся в лимит, все иди отдыхай.

Конечно можно и руками добить, но руками это придется делать часа 2, а после восстановления лимитов уйдет минут 20. Речь даже не сколько про нейронки, сколько про нашу культуру.

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

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

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

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

Когда же мы сравниваем мобилку и фронт оказывается что в 90% случаев это одно и тоже. Если вы считаете, что это прям супер разные миры, вы вероятно не изучали современный фронт. И там и там это всегда про отправить запрос на бэк, и нарисовать интерфейс (разумеется декларативный), возможно какая-то минимальная логика еще.

Если вы даже на подходы посмотрите, то все best practice которые в 20-х годах на мобилке были ноу-хау, на фронте уже лет 6 как были базой. В мобилке почти все строится на подходах фронта, только улучшенных.

Можете конечно возразить что на мобилке нам доступны вещи типа файловой системы. С одной стороны да, с другой не очень то доступны, и с каждым релизом OS становится все недоступнее. На iOS вообще изначально не сильно от фронта отличалось.

Остаются 10% где реально прям есть отличие. Это уже касается работы с процессами, системными API (типа работы с камерой, гироскопа, шагомера т.д) или той же файловой системы. Правда все это используется, ну в 5% всех приложений. Ну и разумеется разница в доставке, на мобилке это прям геморрой со сторами, на фронте же в cdn закинул и готово.

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

Идем к еще одной причине из-за которой агенты уходят от IDE в сторону терминала или отдельного ПО. Она делится на два основных пункта:

Рынок. IDE в основном используют либо айтишники, либо преисполнившиеся вайбкодеры. Это довольно узкий рынок, а хотелось бы чтобы агентами пользовались и бухгалтеры и финансисты и т.д короче все кому агенты бы помогли, но при этом без кода. Поэтому мы либо делаем терминал (по словам главы Антропика, у них финансовый отдел с кайфом использует Claude Code) либо делаем уже приложение которое будет иметь доступ к файловой системе и может дергать терминальные команды.

Вендоры Ide. Microsoft создала двухуровневую систему для защиты VsCode: Copilot получает доступ к internal API, сторонние инструменты - нет. При этом сама VsCode это open-source, но делать форк это прям заеба, Cursor отстает от последних версий VsCode. У последних по слухам есть целая команда которая занимается исключительно слиянием upstream-изменений. Другими словами у них весь бизнес строится на кодовой базе, контролируемой конкурентом.

JetBrains же напротив пытаются сейчас сделать внедрение плагинов более простым, чтобы не было необходимости делать форк целой Ide. Не говоря уже про то, что ты еще попробуй тут сделать форк, у гугла еле получается, потому как Android Studio работает заметно хуже оригинальной idea (лично по моему опыту, у вас возможно он другой).

Сюда же и относится в целом привычка. Я вот как только не пытался, я не смог работать с VsCode, по сравнению с idea у него отвратительный UX. Держать же целую отдельную ide только для агента можно, но вообще не удобно.

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

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

Короче, касательно того, что "агентам нужен контекст открытого в IDE окна, выделенного текста, последних файлов и т. п.". Ну вообще, не особо нужен, Claude Code и так достаточно хорошо ориентируется даже в большой кодовой базе. Даже если и нужен, для этого не нужно делать прям отдельную IDE, чтобы это получить.

Далее был рофл про то, что у Claude Code терминальное приложение, оказывается, сделано на React (каким херам они его сюда затащили, вопрос отдельный), и им приходится изворачиваться, чтобы ничего не зависало. Ну конкретно тут да, Anthropic, конечно, проебались с выбором языка для CLI, потому как я делал CLI на Go с интерактивными элементами (прогресс-бары, меню и т. д.), и там это делается буквально в пару строк кода. Видимо, в Node.js все довольно хуже с этим.

Ну и финальное, что агенты на самом деле переходят обратно в GUI. Ну, во-первых, GUI у всех агентов это Electron, поэтому, возможно, я и промахнулся с трендом именно на CLI, однако факт, что сейчас почти никто не делает нативные десктопы, остается фактом. Во-вторых, все новые решения появляются именно в CLI. GUI развивается, потому что рядовым пользователям попробуй объясни, как пользоваться терминалом, однако почти всегда сначала идет CLI. В итоге да, тут я промахнулся, сейчас идет тренд именно на гибриды. CLI все равно останется, ведь по-другому ты никак не запустишь агента на удаленном сервере или в CI. Как минимум Cursor тут явный пример.

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

Заметили что все агенты сейчас переходят в терминал? Claude Code сразу сделали cli, OpenAI сначала пошли через WindSurf но сдались и сделали Codex cli, Сursor также недавно выкатил свой. У этого феномена ренессанса терминала есть интересная историческая причина и тупо бизнесовая.

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

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

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

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

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

Ну короче, чтобы сильно не разглагольствовать. Всех с наступающим, заебали 🎄

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

Первая. Яндекс объявил акцию с кешбэком 100 процентов за покупки в определенное время, там было что-то типа окна покупок в пять минут. И разумеется, он не справился с нагрузкой. В сети была куча видео с огромными очередями на оплату. Еще раз подумайте: один из крупнейших провайдеров облаков, на базе которого работает треть всех российских сервисов, не справился с пиковой нагрузкой. Можно было бы предположить, что это сделали специально, но есть у меня наитие, что кто-то просто проебался.

Вторая. Это уже личная история. У меня довольно часто возникали проблемы при оплате яндексовых сервисов их же картой, но я все равно это делаю, так как часто бывает бесплатная доставка. И вот буквально на днях я хочу оплатить доставку еды. На карте Яндекса у меня денег больше, чем нужно, однако вместо кнопки "оплатить" у меня кнопка "пополнить и оплатить". Я сначала подумал, что просто с кнопкой проебались. Но нет, меня реально перебрасывает на страницу оплаты, и знаете на какую сумму? Сумма на карте минус сумма доставки. Они реально перепутали что от чего нужно отнимать!

Это уже даже не смешно, это просто позорище. Ладно, вы баннер с рекламой делаете на полэкрана, ладно вы не можете с нагрузкой справится, но профакапиться с системой оплаты, да еще и вашей же картой, это уже прям мощно.

Касательно LLM-агентов в последнее время меня бесят две крайние позиции.

Первая позиция это адепты того, что AI сейчас всех заменит. Реально, я уже как минимум три раза слышал тезис: "Я вообще не вижу смысла учиться на программиста - уже завтра всех заменят".

Практически всегда это позиция какого-нибудь HR или маркетолога, которые за жизнь ни строчки кода не написали. У них эта идея идёт из того, что у них через ChatGPT получилось запустить локально мелкого Telegram-бота и вот уже программисты им не нужны.

Недавно я такое услышал в программистском подкасте от нормального разраба, и я чуть в голос не орнул: "Да что ты, блять, такое несёшь? Ты-то куда?"

Вторая позиция наоборот, те, кто вообще отрицает их полезность. Современные луддиты, от которых можно услышать тезисы: "Раньше было лучше", "AI всё только хуже сделал". Почти всегда это те, кто даже не пробовал агента запустить. Или же пробовал, но одного из вот этих корпоративных (бесплатных) агентов на базе какого-нибудь Qwen или LLaMA, которые, ну, откровенно сосут по сравнению с Claude или Codex. Их ещё почему-то в ярость приводит мысль о покупке лицензии и проверке на собственном опыте.

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

Под конец года я, как и многие, выгораю в угли. Не только из-за работы – в целом за год обычно накапливается куча событий и стресса, после которых ты отходишь в течение новогодних «каникул». И каждый раз ты обычно думаешь: "прошлый год был говном, но вот следующий год точно будет моим". Однако сейчас есть стойкое ощущение, что не в этот раз…

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

Отчётливо чувствуется вот этот вайб: будто 2026 год – это буран из Frostpunk, который нужно будет пережить. Ключевая ставка по-прежнему довольно высокая, налогов прибавилось поэтому компании будут оптимизировать штат. Это означает, что работу быстро не сменишь, зарплаты не будут расти теми же темпами, что раньше, и есть риски волны сокращений.

Для себя я выделил пару советов – банальных, но сделаю вид, что вы не в курсе:

👉 Сейчас буквально самое плохое время, чтобы уходить в "никуда, отдохнуть и найти себя". Не получится вернуться в любой момент
👉 Если у вас есть премия, я бы отложил существенную часть в финансовую подушку
👉 Лучше избегать очень дорогих и импульсивных покупок
👉 Стоит попробовать поработать с LLM-агентами, если вы еще не пробовали. Модели, разумеется на сделают за вас работу (оно и хорошо), но вас могут обойти те, кто обвязался ими по полной
👉 Также я бы обновил загран паспорт, ну так, на всякий...

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

Рекомендации YouTube сейчас – это что-то невероятное: "Абсолютная база работы с LLM за час", "Не вздумайте писать промпт, пока не посмотрите это видео", "Единственно верный способ работы с LLM"...

Короче, я вам сейчас сэкономлю часы просмотра этих нелепых видосов. Вот база в виде 5-минутного поста:

👉 Бесплатные версии нейронок – говно, берите подписку (желательно, чтобы оплатил работодатель)
👉 Используйте агентский режим. Если вы всё ещё ходите в ChatGPT и копируете оттуда код, то вы прям отстаете. Работа через агентов значительно отличается от простого чата
👉 Все эти "тонкие правила" для промптов по большей части – херня полная. Агенты стараются писать код ровно так, как у вас принято в проекте. Если в кодовой базе говнокод – они будут делать говнокод. Если же с кодовой базой всё в порядке, то и код будет довольно неплохой. Нейронки все равно перепишут ваш промпт
👉 Очень желательно создать доку специально для агента . Так модель быстрее и точнее будет делать сразу то, что нужно
👉 Не доверяйте моделям! Многие разрабы сейчас слишком сильно воодушевлены моделями. Настолько, что перестают смотреть в код. Это большая ошибка: модели всё ещё часто пиздят, спотыкаются о собственный код и принимают настолько БДСМ-ые решения, будто обучены на воспоминаниях Билли Херрингтона
👉 Локальные модели не годятся даже для автодополнения
👉 Claude всё ещё лучшая модель для работы с кодом. У всех тут разное мнение, но по моему опыту даже в рамках Cursor другие модели работают заметно хуже