adelf on programming

Новый дивный мир

Пришел issue, в котором юзер жалуется на какое-то несоответствие логики. Но ишью писал явно ИИ. И он, кроме всего, декомпилировал плагин, нашел проблемные места и указал где надо искать ошибку)

https://github.com/laravel-idea/plugin/issues/1383

P.S. Я кстати уже пробовал клода заставить поправить issue, просто указав ему ссылку и попросив написать тесты. И он даже починил, но очень костыльно (там была куча кейсов, в которых работало бы неверно). Пришлось самому логику нормальную писать, но тесты пригодились. Щас попробую еще разок с этим ишью.

Upd: Клод задачку таки ваншотнул. Приятно) Но она реально простая была.

Podlodka #489 – Laravel

Laravel любят за скорость разработки, ругают за магию и регулярно обвиняют в том, что он плодит жирные контроллеры. Вместе с Аделем Файзрахмановым – автором плагина Laravel Idea для PhpStorm и книги «Архитектура сложных веб-приложений. С примерами на Laravel» – разбираемся, что именно делает этот фреймворк лучшим на сегодняшний день способом писать код на PHP. 


🎧 Слушать выпуск

👀 Смотреть выпуск

👉Предложить себя в подкаст

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

Для типичных монолитных по всем координатам приложений где все свалено в одну кучу: модели в одной папке, контроллеры в другой - то мое правило работает. Там если именовать все в стиле Model/User, Controller/User, т.е. ClassType/Feature, то быстро образуется бардак.

Однако продвинутые системы, в которых много классов, быстро переформатируются в папки по доменам, или контекстам, или фичам. И получается, например, домен тот же самый User, папка App/Domain/User, а классы мы именуем DomainName/ClassType. Классы будут App/Domain/User/Controller, User/Handler, User/Model, etc.

Поскольку логика приложения красиво разорвана на эти куски, то User/Model редко когда юзают в одном и том же файле с Post/Model, например(это вам не Eloquent модели!). И неудобств не возникает, код занимает на пару байт меньше памяти, его чуток быстрее читать и т.д.

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

Часто слышу мнение в стиле "неймспейс это тоже часть имени класса. Используйте его"

И, как правило, это выливается в такие классы как App\Controllers\User, App\Models\User, App\Resources\User.

Не надо так.

Upd: Люди потребовали деталей. Надо примерно так: UserController, UserResource. Вообще, по логике и UserModel надо бы, но один ключевой тип классов можно выделить как основной и суффиксы там не добавлять.

Хранение дефолтных значений

Для новой фичи мне нужно хранить токен Sentry и домен, где этот Sentry работает. Почти у всех он sentry.com, не так много кто использует self-hosted решения. Есть в общем два варианта как хранить эти данные. Либо мы храним все:

  "token": "<token>",
  "domain": "sentry.com(или свой какой-то)"
}

Либо, когда у нас само вырисовывается некое значение по умолчанию, которое будет у большинства, мы можем хранить только токен, если домен у нас sentry.com. А значение домена храним только тогда, когда оно отличается от дефолтного.

  "token": "<token>" // предполагаем, что домен стандартный
}

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

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

P.S. токены мы все равно храним в защищенном хранилище, а не в открытую :)

Исследую сейчас исходники Livewire4. Прекрасный пример, когда две совсем разные логики пытаются всунуть в один метод.

Тут можно добавить компонент либо на основе класса, либо на основе вью. И эти две логики не имеют ничего общего.

Весь этот код буквально плачет и кричит: тут должны быть два метода! addClassComponent() и addViewComponent()

public function addComponent($name = null, $viewPath = null, $class = null): void
{
    // Support $name being used a single argument for class-based components...
    if ($name !== null && $class === null && $viewPath === null) {
        $class = $name;

        $name = null;
    }

    if (is_object($class)) {
        $class = get_class($class);
    }

    // Support $class being used a single named argument for class-based components...
    if ($name === null && $class !== null && $viewPath === null) {
        $name = $this->generateHashName($class);
    }

    if ($name == null && $class === null && $viewPath !== null) {
        throw new \Exception('You must provide a name when registering a single/multi-file component');
    }

    if ($name) {
        if ($class !== null) $this->classComponents[$name] = $this->normalizeClassName($class);
        elseif ($viewPath !== null) $this->viewComponents[$name] = $viewPath;
    }
}

Вчера вышел PhpStorm 2025.3 со встроенной Laravel Idea на борту. JetBrains даже небольшую видюшку на этот счет сняли. https://www.youtube.com/watch?v=AZoOX6_mcZw

У меня была когда-то мысль сделать отдельный продукт. Типа PhpStorm + Laravel Idea и продавать это как Laravel IDE. А теперь сам шторм стал этим продуктом. А я буду сосредоточен на разработке. Там есть над чем голову поломать.

Издательство BHV опубликовало мою книгу!

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

Где можно купить:

В книжных магазинах, например Читай-Город.

На сайте издательства: https://bhv.ru/product/arhitektura-clozhnyh-veb-prilozhenij-c-primerami-na-laravel/

На Озоне: https://www.ozon.ru/product/arhitektura-clozhnyh-veb-prilozheniy-s-primerami-na-laravel-fayzrahmanova-r-2834482220/ (кто-то накосячил там с моим именем)

На сайте Читай-города: https://www.chitai-gorod.ru/product/arhitektura-cloznyh-veb-prilozenij-s-primerami-na-laravel-3125294

С 2010 по 2019 годы каждое лето, не считая одного, я участвовал в организации большой конференции в Москве - DevConf. Она выросла из PhpConf на идее создания конфы о веб-разработке вообще, не взирая на язык программирования. Она собирала пхпшников, рубистов. питонистов, жсников. Даже явисты с сишарперами заглядывали.

По сравнению с популярной конференцией для веб-разработчиков Highload, DevConf была лампово простой. Потребности закрывались в стиле Getting Real или Lean Startup. В зале часто могло просто не быть ведущего. Докладчики сами делали доклад и передавали слово следующему. Единственным излишеством была отличная еда. Часто это был шикарный шведский стол с шоколадным фондю и прочими необязательными вещами. Но это лишь помогало главному - тому самому общению, которое и есть главная польза конфы! Конференцию посещают не столько ради докладов. А ради общения с коллегами из других контор или смежных областей, шарить идеи, расширять кругозор и это вот все. У нас этого было более чем. Везде толпы народу общались друг с другом. Было круто.

Другим отличием от HighLoad был ценник. Раз в 4-5 ниже. Весьма существенное отличие.

Конфу организовывал Саша Смирнов - главный phpклубер планеты, который своей харизмой и мне неизвестно чем привлекал кучу пхпшников и другого люда делать доклады и ходить на конфу. До сих пор помню как еще до релиза PHP 7.0 Дмитрий Стогов рассказывал на девконфе в чем там оптимизация и как все круто и быстро будет работать. В какойто момент Саша решил отойти от этих дел, передал конфу мне и я за два года благополучно ее угробил) ни харизмы, ни организаторских способностей, ничего такого у меня нет.

К чему я это все решил вспомнить? Валентин Удальцов после нескольких пыхапов решил попробовать провести конференцию и на вид должно получиться хорошо: доступно, лампово и полезно. А именно:
* Куча отличных спикеров (из них примерно человек 10 на девконфе выступали).
* Цена 15 тысяч до 30го августа. У Хайлоада сейчас ценник 89 тысяч(сравнивать некорректно, но тем не менее).
* Организатор горящий идеей и тратящий кучу времени на ее реализацию.

Меня приглашали, но я не смогу быть в Москве 19го сентября. Но если вы сможете - рекомендую.

https://conf.phpyh.ru/

История одного бага, который тормозил шторм последние года два.

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

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

Опять начал пробовать AI для генерации кода. Попросил Junie написать метод, чтобы прошвырнулся по сервис провайдерам Laravel проекта и нашел там Model::unguard(). И если есть, просто вернуть true. Он сделал несколько запросов по поиску фраз в моем проекте, типа "service provider". Проанализировал тот код, и в итоге выдал решение, используя именно мои классы для работы с service provider. Умный.

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

Laravel Idea стала бесплатной. Многим интересны детали, но ничего сообщить не могу. Только то, что будем продолжать работать над ней как раньше.

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

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

https://t.me/tg_5minphp/1413

Тут Петр Мязин из пятиминутки PHP удивляется, что старая монолитная IDEA оказалась более гибкой, чем модный опенсорсный VsCode. Я знаю как работает экосистема IDEA (ну плюс-минус) и видел как выглядят плагины к VsCode. Не особо удивлен. Ну может только добавить могу, что основная платформа IDEA - тоже давным давно открытая.

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

Плагин к Идее - это скомпиленый Java JAR-файл. Там все статично и если загружаешь его на маркетплейс там сразу идет проверка на совместимость с обьявленными версиями IDEA. Поймает любое неверное обращение к методу, классу и чему угодно. Сразу предупредает, что скоро удалят некоторые вещи. Весьма полезная вещь, да и локально можно запускать(у меня на CI крутится). Команда Идеи там довольно четко меняет интерфейсы когда надо, добавляет новые. Один раз только удивили сильно, но я тут об этом уже писал.

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

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

P.S. 1655 Deprecated calls - это из-за моего старого обфускатора. Ни на что не влияет.

Инкапсуляция или почему важно прятать как можно больше информации внутри обьектов

Большинство комплишенов моего плагина подсказывают параметры внутри методов. $foo->bar('тут комплитим'); в процессе вырисовался обьект CompletionContext, в котором есть обьект Parameter, и обьект ParameterList - это уже внутренние объекты PhpStorm. И юзались они везде и часто.

Теперь возникла мысль, что $foo['тут комплитим'] и $foo('тут комплитим') - это тоже вызовы методов! И если на них смотреть по-другому, как $foo->offsetGet('тут комплитим') и $foo->__invoke('тут комплитим'), то все станет сильно проще для меня. Но внутренние объекты шторма там другие, поэтому надо обьект CompletionContext абстрагировать немного. Но не получается. Он был открыт, все лезли в его внутренности и построить абстракцию, когда там не метод, а вызов массива или __invoke, не получается.

Сижу теперь делаю поля приватными и методы как можно более абстрактными. За 5 лет там много накопилось.

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

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

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

P.S. Просто нытья пост.

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

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

Я тоже методы подсказываю кое-где и вот сейчас повторяю эту логику.

Это все-таки произошло. JetBrains забирает мой плагин себе!

Как-то давно, лет 8 назад, я решил написать проект с нуля, без фреймворков. Надо было приспособить его для разных сред и я заюзал .env файлик и пхп-пакет для него. И был неприятно удивлен, что комплишена для ключей то нет! Быстренько наваял плагин для комплишена, назвал его .env files support и запушил его в маркетплейс. А потом сделал подсветку синтаксиса и JetBrains стал рекомендовать его ставить всем. А сейчас по общему рейтингу плагинов он вообще стоит на первом месте! Недавно JetBrains предложил включить его в поставку IDE и я согласился.

https://blog.jetbrains.com/phpstorm/2025/01/support-for-env-files/

Случайно обнаружил, что можно проектам кастомные иконки делать. Можно прямо на проекте правой кнопкой кликнуть и там выбрать пункт, либо просто скопировать icon.svg(или png) в папку .idea.

Ездил на прошлой неделе в Австралию на ларакон. Увидел свой продукт как спонсора на плакате. Был доволен как ребенок. Michael Dyrynda со сцены еще отдельно выделил, что плагин помог им сделать сайт и приложение для конфы.

P.S. Австралия - классное место. Конкретно город Брисбен утопает в зелени и парках. На каждом шагу публичные библиотеки, где можно посидеть с ноутом сколько хочешь. Я там захотел жить.

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

У меня еще не такой большой. Средний. Чуть больше 4 мегабайтов кода. Котлин весьма компактный язык.

Recent Files popup - это Cmd(Ctrl)-E. Удобно вместо табов, ибо они не нужны.