Как я разлюбил динамическую типизацию 2

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

Тайпскрипт в этом смысле изменил многое. Когда стало понятно что он с нами надолго и уже было понаписано немало типов, я в своих проектах стал подключать комментарий @ts-check который дал бесплатную типизацию в js проектах, самого js и либ, где эти типы были прописаны. И все это бесплатно, код не нужно было никак менять.

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

Где-то там же, стало понятно, что надо весь фронт Хекслета переводить на react (раньше был только кусками), потому что бекендовая шаблонизация начала умирать. Тут удачно появилась inertia.js, которая позволила это делать максимально комфортно. Этот процесс мы стартанули чуть больше года назад и вот вот закончим (в начале марта). Чем больше я работал с этим кодом, тем больше мне становилось некомфортно возвращаться в Rails и особенно шаблоны, где возможности навигации и рефакторинга достаточно ограничены. Да этого сильно больше в больших идехах, но это все заслуга их разработчиков, а не самой экосистемы. Короче не очень надежно и перспективно.

Я не говорю что было прямо совсем плохо, потому что в этот момент мы активно использовали ruby-lsp, а он довольно крут. Но даже этого не достаточно, особенно сильно это стало проявляться когда я активно пересел на агентскую разработку. Уже постфактум могу сказать, что наличие типов значительно улучшает качество генерации и скорость исследования исходников. А пока их совсем не было, агенты часто не угадывали происходящее.

В итоге сошлась кучка факторов: упало значение многих фишек rails, потому что шаблонизация уехала в react целиком, разработка стала вестись через агенты, а им нужны типы, ts сильно повысил планку к возможностям которые дает хорошая система типов вкупе с тем насколько это может быть компактным. Последним и решающим фактором стало то, что агенты отлично пишут типы. Первое время с ts я нехило так мучился, когда надо было дописывать сложные типы самому (всякие хитрые дженерики). Как же это упростилось, когда подключилась генерация агентами.

Закончилось это тем, что я подключил к Хекслету Sorbet это статическая система типов, которую очень необычно (в других языках ваще не так сделано) интегрировали в Ruby. А благодаря агентам и ии автокомплиту мы буквально за неделю описали все типами и весь новый код стали писать только с ними. По пути пришлось менять привычки и подходы, за что наверное на меня рубисты посмотрят косо, но местами код стал напоминать java стиль, с явным созданием dto и отказу от dsl там где это можно сделать безболезненно. Метапрограммирования в общем стало меньше (кому интересно, гляньте гем tapioca, который очень помогает)

За это время я полностью трансформировался. Новые проекты я точно буду начинать только на статически типизированных языках. Мой личный топ для типовых веб проектов kotlin, ts, go (только там где по все остальное не подходит). На уровне фреймворков я буду брать spring boot + react. Про это точно будет отдельный пост. Вот такой вот поворот

Telegram | YouTube | Сообщество

Расходы в штатах. Сколько стоит жить в майами?

Для контекста, мы переехали сюда в 19 году и за это время цены местами выросли в полтора два раза. Когда переехали нас было четыре человека, здесь родили еще одного (первый американец в семье) и теперь нас пятеро. Детям 12, 9 и 2.

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

2000$ - Ипотека (включает в себя налог на недвижку и страховки). И мне повезло, что я ее взял под 2.5% годовых за 230 000$ (127 квадратов) практически на берегу в ковид. Щас цены ваще другие.
900$ - HOA (это комуналка + интернет + обслуживание комплекса, включая бассейн)

Помимо этого в кондо каждый год что-то происходит и собирают деньги на фиксы, недавно качалку восстанавливали после того как ее сожгли, сейчас бассейн ремонтируют, скоро гараж (на тысячи машин) обновляют. Тут доп расходы в год от 1000$ до 5000$ и раз в 10-15 лет могут попросить 20 000$ на капиталку.

250$ - Электричество. Тут даже если уехать не платить нельзя, потому что с выклченным кондеем сразу заведется какая-нибудь плесень и квартире хана. Он работает даже если мы уезжаем.

230$ - Связь. Цена в месяц на одного человека за линию 40, плюс немного устройств

1200$ - Машина в лизинг в месяц. Тут можно было дешевле, долларов на 500$, но очень хотелось поездить на bmw 🙂

250$ - страховка на машину. Это флоридская особенность, здесь страховки в разы дороже чем в других штатах

1300$ - мед страховка на меня с женой. Правда надо понимать что американская страховка на медицину это не 100% покрытие, еще каждый месяц доплачиваем за посещения/лекарства/процедуры сотни долларов (в зависимости от того как часто ходим). Детям с прошлого года стали выдавать medicaid (его в основном дают малообеспеченным, но во флориде иногда включают для всех детей). Иначе еще 1000$ за детей бы добавилось.

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

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

Поехали дальше, переменные расходы

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

1500$ - амазон. Тут все от бытовухи до памперсов и игрушек.

900$ - гимнастика для сына (не каждый день). Забирают прямо из школы (это называется after school, в штатах очень популярно). Еда не входит, кладем ему сами либо можно доплачивать 15$ за прием. Старшая тусует с друзьями, тут экономия 🙂

500$ - кредиты в месяц. В основном техника, обновления телефонов, планшетов и лаптопов

150$ - бензин. Я езжу мало, у нас пешеходный город

100$ - качалка в месяц для жены. Качалка в кондо тоже есть, но она такая, для очень не искушенных

x - женские дела (процедурки как мы любим говорить). Тут не знаю, жена сама решает сколько тратит и когда 🙂

1000$ - просто улетает на всякое, где то ребенок попросил, где-то штраф (один штраф это 150-250), где-то в мол съездили, где-то чайник новый заказали или xbox в ремонт. Услуги в штатах тоже очень дорогие

Опциональные

250$ - любой выезд на выходных куда-нибудь. Как правило на мою семью вход это 100$ на всех плюс прием пищи и перекусы.

Слетать в мексику (как турция для рф) или покататься на круизе (порт прямо тут) выходит где-то 6000$ на неделю.

Ко всему этому прибавляем ежегодные расходы на бухгалтера и налоги (как раз сейчас идет период), которые гуляют от 30% до 40%

Стоит ли оно того? Стоит (но очень нервно)

Telegram | YouTube | Сообщество

Собирайте свои монадки и к нам в ютуб! Продолжаем разбирать Хаскель. В этот раз копаем в побочные эффекты и монады youtube.com/watch?v=B8aFgfBVZnI

Альтернативные ссылки: Аудио | vk

Ребят важный вопрос. Если телегу действительно заблочат, то какой план чтобы не потерять друг друга?

Отношение к задачам по бизнес ценности

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

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

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

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

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

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

Telegram | YouTube | Сообщество

Выпуск про микросервисы уже доступен для просмотра https://youtu.be/Ya5oG9sPVBU?si=Vb77u1CU9IohtOjz Наслаждаемся и машем

Альтернативные ссылки: Аудио | vk

Учимся писать промпты правильно

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

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

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

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

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

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

Для упавшего ci это выглядит так:

Поправь тесты
Прошу посмотреть последний запущенный билд на github actions

Баг в браузере:

прошу открыть страницу (он это делает через mcp chrome) и самому изучить

Для рефакторинга:

Переводим вот это на это
Вот эталон (тут ссылка на файл)

Для фичи:

Нужно реализовать такую фичу
Даю пример или говорю с помощью какого инструмента

И все. Самые продвинутые модели типа opus 4.6 или codex 5.3 справятся самостоятельно с большинством острых углов. Сами спросят объем, посмотрят разные варианты, изучат доку и так далее. Модели по тупее, не сделают глубокого анализа и ничего особо не спросят, но именно тут вы поймете где их надо вести и включать свой мозг чаще. Хотя хорошие модели настолько сильно помогают, что я физически не могу использовать более простые для задач планирования. Они хороши в авторежиме только для работы по аналогии, рефакторинг, написание тестов и так далее.

Даже если вы что-то забудете или пропустите сразу, все это можно будет доуточнить, попросить показать примеры кода, сходить открыть браузер. Если в процессе появляются вещи, которые агент делает из раза в раз, например, пытается выяснить где что-то лежит, как работать с какой-то частью системы, то постепенно это выносится в AGENTS.md и с определенного размера и уровни сложности (когда уже нужны скрипты например и команды) выносится в skill.

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

Telegram | YouTube | Сообщество

Выпуск с лайвкодингом проекта по DDD и заветам чистой архитектуры уже в сети https://www.youtube.com/watch?v=MBSwaH6s7Ig (писали на Kotlin). Посмотрите и скажите что вы думаете про такую архитектуру. Насколько это отличается от того как пишется код в ваших проектах

Альтернативные ссылки: Аудио | vk

Граница абстракций

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

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

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

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

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

Когда вызов допустим: если нижележащий компонент это не еще один application service, а отдельная зависимость с более низким уровнем абстракции: доменный сервис, policy-объект, репозиторий, gateway, publisher событий и так далее. Какой-нибудь сервис отправки писем хороший пример. Я, кстати, по этой причине, вообще бы не называл такие штуки сервисами, иначе происходит жесткая путаница.

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

p.s. А какой подход используется у вас?

Telegram | YouTube | Сообщество

Записал выпуск про агентскую разработку. Прошелся по всему начиная от знаний которые нужны или не нужны, заканчивая паттернами работы с репозиториями и агентами. Если вы еще пишите код руками, то мы идем к вам 🙂 youtube.com/watch?v=Au8ioLEJDOU

Альтернативные ссылки: Аудио | vk

Подкаст уже доступен для прослушивания и просмотра. Тема подкаста будущее баз данных, которую мы разбираем с Константином Осиповым, в прошлом разработчиком mysql и создателем tarantool https://youtu.be/_9JhY63Cvtc?si=FeHn0rEBZXlN3_qe

Альтернативные ссылки: Аудио | vk

Слои или Фичи (Домены)

Существует два основных подхода организации кода в приложениях. Либо по слоям, когда у нас, грубо говоря, в одной папке контроллеры, в другой модели, в третьей тесты и так далее. И подход когда папочки объединяются по фичам/домену, в таком случае в одной папке лежат все возможные элементы приложения (и контроллеры и модели и тесты и что там еще есть в вашей экосистеме). И каждый раз идет срач на тему, а как правильно? Иногда за нас это уже определено.

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

Бывают и гибридные варианты. В той же Django внутри каждой фичи (app) у нас слоистая архитектура. А в rails есть понятие engine, когда часть логики можно вынести как бы в отдельное rails приложение, а затем внедрить его в исходное (для этого есть механизм движков). Его обычно используют для каких-то тем, которые прямо сильно выделяются или реализуются как отдельные проекты, например, так можно подрубить форум или систему мониторинга очередей.

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

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

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

Как вы делаете в своих проектах?

Telegram | YouTube | Сообщество

Как начать использовать агентов бесплатно

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

Прокаченные модели с условно-бесплатным доступом

Copilot. В первую очередь бесплатно (ограниченно) он дает автокомплиты и nes. Если вдруг вы еще не пользуетесь, то хотя бы попробуйте. Поставьте в редактор как расширение и подрубите базовую версию.

Gemini Cli. Free tier: 60 requests/min and 1,000 requests/day with personal Google account. Еще можно попробовать Antigravity (это аналог Cursor от гугл). Там мы уже получаем не только Gemini, но и другие топовые модели.

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

Qwen Code CLI. ~1000–2000 запросов в день через OAuth (зависит от региона/лимитов). Дает доступы к своим моделям (qwen-x)

Kilo Code. Еще один агент, который дает: "Get $20 in bonus credits when you top-up for the first time Credits can be used with 500+ models like Gemini 3.1 Pro, Claude 4.6 Sonnet & Opus, and GPT-5.2" Выглядит очень вкусно.

SourceCraft Coding Agent. Это агент разрабатываемый яндексом у которого сейчас под капотом DeepSeek есть бесплатный тариф и очень дешевый платный. Если вы помните, руководитель этого проекта Дмитрий Иванов был пару раз у меня на подкасте. Ребята общеают какие-то мегаапдейты скоро, будем посмотреть. А еще у нас запланирован с Димой вебинар где мы будем кодить с агентами в районе мая.

Бесплатные модели по проще

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

OpenCode Free Models. На выбор дают (mimo v2 pro, minimax m2.5, nemotron 3 super, big pickle).

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

В целом бесплатный список моделей можно посмотреть на сайте OpenRouter. Дальше регаемся и подключаем через OpenCode или плагин к редактору.

Доступное из платного

Самый вкусный тариф из платных пожалуй дает OpenCode go. Первый месяц 5$, потом 10$.

Напомню что курс стартует 30 марта. А завтра я провожу вебинар про агентскую разработку. Зарегаться можно по ссылке: https://special.hexlet.io/ai-for-developers-2026 Буду ждать 🙂

Telegram | YouTube | Сообщество

Делаем мир чуть чуть лучше

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

Буквально недавно я так дебажил одну рубишную либу и выяснилось что там внутри есть косячки. Не долго думая, прямо в той же сессии я попросил агента собрать ишью дал линк на репу и потом просто скопировал это туда на гитхаб (наверное можно было попросить его сделать ишью автоматом, попробую так в следующий раз). Получилось очень обстоятельно с примерами кода, описанием того где ошибка. При желании можно было бы сразу пулреквест кинуть, но я не был уверен в какую сторону решит пойти автор либы. Вот кстати тот ишьюс: https://github.com/skryukov/rails_vite/issues/5 И фикс был сделан буквально в тот же день.

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

Telegram | YouTube | Сообщество

Выпуск про кризис в IT уже в сети. Разбираем реальные причины падения спроса на разработчиков вместе с Женей Кобзевым, сооснователем и техническим директором бухгалтерского сервиса Кнопка (я был их клиентом в самом начале пути этого сервиса). https://www.youtube.com/watch?v=ZgyE8JDTxSk

Альтернативные ссылки: Аудио | vk

После года рефакторинга, мы переехали на Inertia.js и попрощались Bootstrap

Ну вот и закончился мегарефакторинг, в рамках которого мы переезжали с классической серверной шаблонизации на React SPA, но не через api + фронтенд стейт + клиентский роутинг. Мы взяли тогда еще набирающую популярность Inertia.js, которая работает по похожему принципу как next.js (серверный роутинг, отсутствие api и стейта на клиенте), но где в качестве бекенда выступает фреймворк на любом языке.

Жизнь показала, что мы сделали правильный выбор и с тех пор инерция не только стала популярнее и пошла по всем языкам, но и недавно ребята выпустили третью версию, на которую мы оперативно обновились. Если вы походите по сайту Хекслета, то заметите как плавно переключаются страницы, это они включили View Transition.

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

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

Планируя переход мы сразу целились в максимальную типизацию, поэтому везде ts и mantine, который очень этому способствует (вместо классов props). Плюс сюда же типизированный i18next.

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

В общем я немного выдыхаю и перестаю херачить код как не в себя. Теперь наводим красоту, правим косяки и фокусируемся на контенте. Давно я серьезно не махал шашками, а тут столько курсов надо выпустить :)

Telegram | YouTube | Сообщество

Конец эпохи

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

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

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

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

Что вы обо всем этом думаете? Где находитесь сами и куда мы идем?

Telegram | YouTube | Сообщество

Выпуск про SEO уже доступен на канале. Все что вы хотели узнать про поисковую оптимизацию но боялись спросить. От понятия спроса, до поведенческих факторов и технической оптимизации сайта. Как и зачем собирать семантическое ядро, откуда взялся page rank и зачем делать перелинковку на сайте. Садитесь по удобнее, будет интересно!

https://www.youtube.com/watch?v=gaWh8FSJ0a4

Альтернативные ссылки: Аудио | vk

Entity-based VS Consumer-oriented API

Из всех способов организации апи, можно выделить два основных: ориентированных на клиентов или ориентированных на внутренние сущности и структуру данных системы.

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

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

Немало людей сталкиваясь с этими проблемами, начинают винить REST, что это его ограничения и его природа. Но нет, просто невозможно спроектировать entity-based API как внешний контракт, хорошо подходящее сразу и идеально для всех. Поэтому есть другой способ, это api ориентированное на клиента. Когда API проектируется от конкретных сценариев использования (use cases), а не от структуры данных. В этом случае у нас нет просто общих эндпоинтов, все эндпоинты разделены по своим неймспейсам, одни для админки, другие для мобилки, третьи для клиентской части сайта, ну и классическое апи для внешних клиентов (не браузера и не мобилки).

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

Entity-based API хорошо подходит как внутренний слой (Service API), но в качестве внешнего API почти всегда приводит к усложнению клиентов и росту связности. Consumer-oriented API, наоборот, берет на себя сложность внутри системы и упрощает клиентов, даже если это приводит к дублированию и большему количеству эндпоинтов.

Telegram | YouTube | Сообщество

Вы ведь заметили что последние месяцы я часто говорю про Mantine (React Component LIbrary)? Так вот сегодня в очередном выпуске подкаста будет говорить его создатель - Виталий Ртищев. А еще в подкасте прошлись по tailwind, mui, shadcn и chakra. Наслаждайтесь https://www.youtube.com/watch?v=r0uUJwyBJAc

Альтернативные ссылки: Аудио | vk