https://t.me/tg_5minphp/1008

Ох как любит народ оптимизировать такты процессора и байты оперативки. Особенно, когда это не нужно) На реальном хайлоад веб-проекте оператор new будет где-то в конце третьего десятка причин тормозов. Там тормоза в основном из-за I/O - базы данных, кеши, диски. Банально закешить грамотно запрос будет в миллионы раз эффективней, чем убрать какой-нибудь new.

Я до сих пор с содроганием вспоминаю как смотрел видео, где один из core-разрабов yii2 делал метрики и доказывал, что код без интерфейсов выполняется на наносекунды быстрее, поэтому “интерфейсы не используйте” (https://youtu.be/x7-G4tHFSj8?t=1809 - вот здесь).

Бывают, конечно, задачи называемые “числодробилками”, где I/O операций мало, зато куча вычислений. Но это весьма и весьма нетипичная для PHP задача и часто ее выделяют и реализуют отдельно на каком-нибудь go (отсюда и мода на него в последние годы).

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

Сделал одну вот фичу и сижу думаю: а что мешало ее сделать давным-давно?

https://t.me/laravel_idea/38

ChatGPT - новая разработка от OpenAI. Такого логичного обьяснения от человека сложно получить. Все еще уверены, что писать код - это перспективная профессия?)

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

Начал потихоньку готовить код Laravel Idea к работе в команде. CI с прогоном тестов и проверкой на совместимость со штормом уже давно стоит. Второй по важности пункт - натравить на проект проверятор стиля кода и тоже гонять его в CI. Несмотря на кажущуюся малую полезность, для командной разработки это чуть ли не must-have. Договориться разок о стиле(а то и деспотично назначить самому 😈), прописать в конфиге стайл-фиксера, и все. Если поддержка в IDE есть - совсем шик.

В пхп есть php-cs-fixer. В СиШарпе помню лет 10 назад был StyleCop. Для Котлин есть detekt.

Первый прогон - 2900+ ошибок. Борюсь с ними сейчас. Довел до 428.

Встретил тут один каламбур, отчего и решил написать этот пост. Function getModelFqnDeeply is nested too deeply.

Это я фиксил те 2900+ ошибок стиля, которые нашел detekt. Больше половины - автоматические замены(форматированием IDEA и маленьким своим пхп-скриптом), но и самому пришлось поработать.

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

Теперь все иммутабельное, пересчитывается на лету. Вместо codeGeneration.baseClass, теперь codeGeneration.getBaseClass(settings). Со стороны можно сказать, что стало хуже, но теперь все явно(нужны настройки, чтобы получить базовый класс) и цикл жизни простой - это неизменяемый объект с дефолтными значениями, но перекрываемыми из настроек.

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

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

Помните выражение "тесты как документация"? Типичный случай сейчас был.

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

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

Захотел я вспомнить как эта функция себя ведет в некоторых кейсах(а писал я ее больше 3 лет назад) - просто сделал Find Usages и прямо в этом окне сразу увидел все, что нужно. Даже не заглядывая в тесты. Документация!

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

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

Можно придраться к тому, что первые условия(> 0.0, >0.1) и так всегда будут true, но диванные твиттерские компиляторщики сказали, что оптимизаторы нынче умные и этот код оптимизнут тоже.

Пишу на Котлине и радуюсь null-safety. Везде он прикроет, не даст получить NullPointerException и все прекрасно. Опасная наивность. Нашел сегодня баг, где я спокойно складываю пустые строки, и получаю строку “null”! Причина в том, что первая строка оказалась null, а вторая - “”. Случалось это редко, поэтому нашел только сейчас, спустя три года.

Какая тут мораль? Доверяй, но проверяй? Не. Лучше так: и эти люди иногда катят бочку на PHP?!

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

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

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

Конкретно мой пример: chess.com дает бесплатно порешать 5 шахматных задачек. Когда я попытался решить шестую он, вместо нормальной ошибки стал выдавать “Insufficient permissions” и больше ничего! Ладно я сразу понял прикол, но рядовой юзер вообще в шоке наверно был)

P.S. Исправили уже сегодня. Молодцы.
P.P.S. Мне не жалко премиум купить, но я тогда по полдня буду эти задачи решать) Покупал уже…

Просто предупреждаю о том, что сегодня 1 апреля. А то народ уже забеспокоился, что Тейлор меня засудит и бросился спрашивать что со мной будет теперь)

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

Сегодня с утра в американских газетах было объявлено о судебных исках компании Laravel против множества частных лиц и компании. Их обвиняют в нарушение прав интеллектуальной собственности на торговую марку Laravel в сети Интернет. Известно, что обвинения предъявлены: Spatie — у них под сотню пакетов, использующих бренд Laravel (Laravel Permission, Laravel Ignition, Laravel Medialibrary и т.д.), Caleb Porzio — за Laravel Livewire, Spartner — Laravel-Excel, а также множеству других лиц и компаний.

Первоначально было известно и о Barry vd. Heuvel, но, как говорят, он успел переименовать свои пакеты в Debugbar for Laravel и IDE Helper Generator for Laravel и его исключили из списков.

В рунете пока известно о двух людях, получивших иски. Это Andrey Helldar за Laravel Lang и Adel за Laravel Idea.

Общую сумму ущерба Отвел оценил в десятки миллионов долларов, заявив: «Люди, которые используют подобные поделки, думают, что их написал я. Ведь они называются Laravel. А это моя зарегистрированная торговая марка. Только я могу получать за неё деньги! Это мой Laravel. Я его придумал и написал. Не нужно за мой счёт зарабатывать себе славу и деньги. Это опенсорс — либо ты помогаешь мне, либо уходи! Создай свой уникальный бренд и зарабатывай на нём. Вы отнимаете хлеб у моих детей.»

На данный момент известно, что Гитхаб закрывает все репозитории, принадлежащие обвиняемым лицам. Позже они будут либо удалены, либо переданы компании Laravel.

Где-то в ноябре я решил побыть настоящим свободным художником и поработать в шезлонге у бассейна. Но судьба быстро дала понять, что всю жизнь мне суждено быть офисным или максимум домашним работником. Пацану лет 3 было скучно и он окатил мой ноут с водяного пистолета. Я успел посидеть там минуты две) Тогда с ноутом ничего не произошло, но на днях моник просто погас и все.
Отнес на ремонт - поменяют материнку, займет две недели. Там остались незапушенными 3 коммита. И я 2 дня вспоминал что в них было. Вспомнил. Восстанавливаю.
Мораль - пушьте свою работу в гит. Он в том числе и для этого создан.

Был в Laravel Idea кусок кода, который раздражал. 150-200 строк некрасивых, которые разбирали все возможные вариации Route::resource(<тут names, only, except>)->only()->names() подобную вот конструкцию и получали из нее список имен роутов. Я несколько раз думал рефакторить этот кусок, но всегда убеждался, что там все слишком завязано друг на друге и нормально отрефакторить нереально.

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

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

Вот во что отрефакторился тот 150-200строковый кусок. Красиво!

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

PHP (Rus) — https://t.me/addlist/R7i3akzlB2kwZTMy
PHP (Eng) — https://t.me/addlist/yNksksLVT6M5NGEy

Давно хотел перевести книгу https://github.com/adelf/acwa_book_ru обратно на английский и нашел идеального переводчика - ChatGPT. После него править почти не надо. Решил еще разок проревьюить её - добавить всякие новые фичи, которые появились в PHP за эти 3-4 года. Ну и дописать пару мыслей. Приведу тут пару отрывков нового.

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

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

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

1. Разные интерфейсы к одним и тем же действиям (Web, API, Console, различные боты). Тут вынесение общей логики просится само.
2. Разросшиеся и сложные логики обработки веб-запроса, например, и бизнес-логики. В данном случае разделение логик по разным местам может заметно улучшить связность кода. Как правило, это ведет к повышенной багостойкости кода.

PHP-народ сегодня активно обсуждал нововведение в PHP 8.3 - #[Override] атрибут. Такой же как в Java. Он позволяет указать тот факт, что этот метод перекрывает метод у класса-родителя. Подробнее по ссылке - https://t.me/sergei_predvoditelev/33

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

Поговаривают, что в 9 или 10 версиях это может стать обязательным. Но обязательным оно наверняка станет одновременно и с обязанностью в классе-родителе указывать то, что метод может быть переопределен. Как в Котлине, Яве и куче других языков. В котлин если метод неабстрактный, но может быть переопределен в потомках, надо указать ключевое слово open. open fun method() и тогда в классе-потомке можно будет его переопределить override fun method() - тот самый override.

Для чего, кроме строгости, это нужно? Для оптимизации вызовов этих методов. Методы, про которые мы знаем точно, что их никто не перекрывает, вызывать легко. В давние стародавние времена я разбирался с тем, как выглядит вызов обычного и виртуального(так назывались те, которые можно перекрыть) методов в C++ коде(от C++ Builder компилятора). Ассемблер код вызова простого метода(забьем на параметры) - call method <aдрес где сидит код того метода>
Вызов динамического - найти в обьекте ссылку на таблицу виртуальных методов, там найти указатель на нужный метод, и вызвать метод. Для тех времен это была серьезная оптимизация, поэтому виртуальными старались делать только те методы, которые надо.

В PHP все методы виртуальные - их можно перекрыть. Но если ввести обязательное указание виртуальности метода(open/override или както иначе), то можно получить более оптимальный опкод. Насколько большим будет прирост на реальных проектах судить не берусь. Понимаю только, что это очень серьезный BC - ломает совместимость прям сильно. Сомневаюсь, что на это пойдут.

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

Картинку взял с корейского обьявления. Там логотип Laravel Idea кажется самым главным)

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

Вообще, isEnabledAndVisible это котлиновский сахар. На самом деле он превращается в вызов Java-метода setEnabledAndVisible, который сам по себе просто сахар над вызовом двух методов.

public void setEnabledAndVisible(boolean enabled) {
setEnabled(enabled);
setVisible(enabled);
}

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

Мораль: разной логике(даже мелкой) лучше лежать в разных местах. Оно облегчает изменения и улучшает будущий код.