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

Начнём как положено, с тестов. В tests/Feature/Auth у нас есть AuthenticationTest.php, в котором уже находятся дефолтные тесты аутентификации. Выберем главный опорный тест, на базе которого проведем изменения...

В Ларавеле есть удобный хелпер-метод: firstOrFail(), позволяющий получить по заданному запросу из БД первую найденную модель, либо вывалиться в 404, если моделей не найдено. Удобство в том, что использование хелпера позволяет избавиться от необходимости отдельно проверять наличие результата.

$page = ContentPage::where('slug', $slug)->firstOrFail();

вместо

$page = ContentPage::where('slug', $slug)->take(1)->get();

if ($page->isEmpty()) abort(404);

Очевидно, первый вариант лаконичнее и читабельнее.

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

Для этого можно написать макрос. В Laravel есть такой трейт, Macroable, и классы, которые его используют, можно расширять своими макро-методами. Расширим класс Illuminate\Database\Eloquent\Builder. Добавим в AppServiceProvider:

public function boot(): void
{
    // ...

    Builder::macro('getOrFail', function () {
        return tap(
            $this->get(), 
            fn ($results) => abort_unless($results->count(), 404)
        );
    });
}

теперь мы можем писать, например, так:

$contentPages = ContentPage::where('slug', $slug)->getOrFail();

и получим либо коллекцию моделей ContentPage, либо ошибку 404, без необходимости отдельно проверять, что коллекция не пустая.

P.S. Да, slug в данном примере не уникальный, может быть несколько моделей с одинаковым slug. Вместо этого у меня есть уникальный ключ ['slug', 'language'].

На днях начал работу над новым проектом, и выдался хороший случай попробовать Livewire и Volt с ним, с последней версией Laravel. Про Livewire в последних версиях Ларавела я раньше слышал и читал, но руки как-то не доходили. А теперь дошли и сейчас мы познакомимся с ним поближе.

Что такое Livewire

Что вообще такое Livewire? Это фреймворк, позволяющий разрабатывать динамичные интерфейсы прямо на PHP. Как гласит главная страница фреймворка:

Powerful, dynamic, front-end UIs without leaving PHP.

То есть «мощные, динамичные фронт-энд интерфейсы, не покидая PHP». Ничего не понятно, но очень интересно. Ну, я немного разобрался (прочитал документацию!) Этот фреймворк позволяет нам, путём вставки специальных директив типа wire:model.live="filter" прямо в blade-шаблон, в html какого-нибудь инпута, сделать этот инпут динамическим. Или, как раньше говорили, его аяксифицировать.

То есть заставить элемент отправлять запросы на сервер без перезагрузки страницы и обновлять соответствующий view по данным в ответе на запрос

И это — без необходимости писать JavaScript-код, вообще. И хотя мы в примере ниже немного JS-кода напишем, это, строго говоря, действительно необязательно.

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

Для определенности уточню, что использую я плагин Codeium для Visual Studio Code под Linux, тариф бесплатный. Никаких дополнительных настроек не применял, на сайте указано что плагином используются Chat GPT, Claude, DeepSeek и Gemini. Проект, с которым я работаю, написан на Laravel, в нём есть такая функция — на определенный route можно отправить post-запрос с сообщением, и это сообщение будет отправлено телеграм-ботом в соотвествующий чат.

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

Вот для написания данного feature-теста я и применю ИИ. Открываем подходящий для теста файл, жмём Ctrl+I. Чат жопотэ, поехали!

В новостях все чаще появляются заголовки типа «Растратбанк уволил и больше не нанимает младших разработчиков». Внутри обычно намёк на повальное применение ИИ-ассистентов, дескать они легко заменяют младших разрабов (джунов) и экономят деньги. Ну с банками всё понятно, они не обеднеют. А что делать нам, маленьким студиям, скромным командам и компаниям-из-одного?

Если вы фанат отдачи строгих инструкций «Напиши класс A в котором есть вот этот список методов b(), c(), d(), e(), а также вот этот список тестов для них» и с пристрастием, до буквы проверяете результат, то только ИИ позволит сохранить остатки рассудка. Кодить надо строго одному, и желательно где-нибудь в глухом лесу.

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

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

Когда-то немножко писал про TDD в целом. По-прежнему считаю методику очень годной. Особенно когда каждый раз начинаешь плясать от Feature/Integration test, а не от Unit test (что было бы все-таки уныло). Поэтому постоянно, когда есть возможность, её применяю.

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

Например. Делаем мы, скажем, набор классов с наследованием, понадобится фабрика, дерево подклассов, перегруженные функции, инъекции зависимостей и все такое. Наиболее правильным (и с точки зрения TDD тоже) представляется есть этого слона по кусочкам:

1. Сделать первый подкласс, добиться чтобы он выполнял свою функцию (сразу после написания теста на этот подкласс, разумеется).
2. Сделать второй подкласс, добиться чтобы и он работал.
3. Посмотреть, что между ними общего, провести рефакторинг, вынести общие места в базовый класс, или создать еще один слой абстракции.
4. Убедиться что после рефакторинга всё по-прежнему работает.
5. Повторить с пункта 2.
6. Когда задача 1–5 решена, провести еще один рефакторинг, добавить инъекции зависимостей, дописать интерфейсы к конкретным сервисам и т.п.

Однако неуемное воображение постоянно заставляет разработчика, еще не доделав 2, сразу переходить к 4. Потому что мозг видит потенциально общий метод в подклассе и немедленно говорит: — так, это мне нужно будет еще в тех трех классах, но нужно будет учесть еще два нюанса, щас мы с тобой такую абстракцию забабахаем!

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

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

Вот чтобы этого не было, помогает обозначенный эффект TDD: консолька как бы говорит — пока у тебя красные тесты, пиши то что тесты говорят! А помечтаешь когда всё исправишь.

Вот нашёл я библиотеку, неплохая вроде библиотека, позволяет делать, условно говоря, кофе. Описываешь рецепты, вызываешь $coffeeManager→makeCoffee('espresso'), и все работает. Но вот незадача — в библиотеке все рецепты кофе хранятся и загружаются из конфиг-файлов (типа .env). А мне вот хочется, чтобы пользователи могли добавлять свои рецепты, чтобы их было много, чтобы раф с бананом на молоке единорогов, и это вот всё. А хранить их тогда надо в базе данных.

Казалось бы, можно унаследовать класс CoffeeManager и перегрузить метод загрузки рецептов, чтоб вместо Config::get() там было обращение к БД. Но вот разработчик хрен пойми зачем объявил класс как final CoffeeManager { … Зачем? А хер его знает. Прочитал наверное где-то про страшные длинные цепочки наследований и подумал, что это к его библиотеке как-то относится. А до конца не дочитал, подумал — поставлю final и черт с ним, пусть пользуются как я задумал.

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

А всего-то надо было, если душа требует final, сделать интерфейс, который этот класс реализует, и нормальную вставку зависимостей через этот интерфейс:

final CoffeeManager implements CoffeeManagerInterface {
    // ...
}

и тогда я мог бы просто свою реализацию интерфейса написать и в контейнере сервисов подменить.

А без интерфейса — либо свой форк делать, либо другую библиотеку использовать. Не надо так.

В Ларавеле можно из отношения «один ко многим» сделать отношение «один к одному». Например, у нас есть модель Monitor, у которой может быть много дочерних моделей MonitorCheck:

class Monitor extends Model
{
    /**
     * Monitor can have many checks
     * @return \Illuminate\Database\Eloquent\Relations\HasMany
     */
    public function checks() {
        return $this->hasMany(MonitorCheck::class);
    }

}

тогда мы можем объявить отношение для получения последней модели MonitorCheck так:

    /**
     * Monitor has a last check
     * @return \Illuminate\Database\Eloquent\Relations\HasOne
     */
    public function lastCheck() {
        return $this->checks()->one()->latestOfMany();
    }

Однако если мы захотим объявить отношение для последней модели с условием, так сделать не получится. Допустим, мы хотим последнюю модель MonitorCheck с проваленным тестом.

public function lastFailedCheck() {
    return $this->checks()->where('passed', '=', FALSE)->one()->latestOfMany();
}

Такой вариант не сработает, будет возвращать null. Причем, если убрать latestOfMany(), то отношение будет работать и вернет MonitorCheck с проваленным тестом, только не последний. А с latestOfMany() не будет работать, запрос будет составляться неправильно (точнее, не так, как мы хотели бы).

А правильно объявлять данное отношение так:

public function lastFailedCheck() {
    return $this->hasOne(MonitorCheck::class)->OfMany(
        ['id' => 'max'], 
        function (Builder $query) {
            $query->>where('passed', '=', FALSE);
        }
    );
}

Вместо id в ['id' => 'max'] можно использовать и другие поля, например, created_at, главное условие аггрегации описать.

На днях погонял Codeium на генерации юнит-тестов. Что сказать, отлично ассистирует. Например, быстро сканирует и улавливает специфику — мок-классы, prophecy, методы, генерирующие тестовые структуры — и тут же их использует. Не всегда, конечно, понимает на 100%, какой вызов надо тестировать (тут специфика сказывается, если бы тестировал простой REST API, думаю бьло бы сильно лучше). Но вот подготовку данных и проверку результатов заполняет почти точно.

Также Кодиум отлично генерирует «обратные» тесты. Если, например, есть уже написанный и рабочий тест users_can_delete_their_data(), то достаточно написать Test that user cannot delete another user's data и тест сразу генерируется в точности какой нужно.

В целом, на мой взгяд, относиться к данному явлению — генерации кода AI — следует как к усовершенствованному, ускоренному, интегрированному прямо в пальцы IDE интерфейсу к StackOverflow. И работать с этим кодом так же. То есть если просто вставлять сгенерированный код без анализа, получится такое же говно, как если не читая копировать «решения» со стэковерфлоу. Поэтому лично я использую в данный момент генерацию для того, чтобы AI написал за меня то, что я и так примерно (хотя бы) знаю как написать, просто роботом писать немножко быстрее. После чего сразу пропускаю код через себя, проверяю, анализирую и правлю. Соответственно, поскольку я знаю, что хотел, мне сразу видно, что нужно поправить, что получилось нормально, а что даже лучше, чем я думал.

Кстати, стоит отметить и встроенный в VS Code интеллисенс, или как его там. Это тоже ИИ, как я понял, в первую очередь нужный для умных автодополнений. В начале работы с VS Code (давно, когда только для C# и Unity его использовал) я как-то не заметил особых плюшек и не вспоминал про него. А тут по мере продвижения по проектам заметил, что он становится всё умнее в плане контекста. И если поначалу он мог разве что предложить (хоть и довольно удачно) название для переменной или функции, то теперь когда я пишу в коде комментарий типа

// if subcommand corresponds to a form element key, run form element request handler

под ним интеллисенс немедленно предлагает код

if (in_array($this->subcommand, array_keys($this->getForm()))) {
}

и этот код в точности соответствует тому, что я хотел написать. И мне нужно только нажать Tab для выражения согласия. Полагаю, если бы я заранее реализовал "form element request handler", то в условном блоке он бы тоже уже был вызван.

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

Перешел не так давно на VS Code с phpstormа, работает неплохо, плагины есть, в целом доволен. А сегодня поставил Codeium — ИИ-плагин, чтобы вкалывали, значит, роботы, а не человек.

Сначала говорю ему: — чат жопотэ, напиши чтобы я нажимал на иконку, а из неё плашка выпадала с уведомлениями!

Он написал. И даже once не забыл, и переделывать почти не пришлось. Потом попросил сделать плашку белой, с синим скругленным бордером и тенью. 2 секунды, сделал, про position absolute сам догадался.

Решил попробовать что-нибудь друпальное. Вот что я получил по промпту Count workflow notifications where recipient is current user id and viewed is NULL.

$query = $this->entityTypeManager->getStorage('workflow_notification')->getQuery();
$count = $query
    ->condition('recipient', $this->currentUser->id())
    ->condition('viewed', NULL, 'IS NULL')
    ->count()
    ->execute();
return $count;

Никакой специальной подготовки, плагин сам все нужные Drupal API увидел. Просить просто «for current user, not viewed» не стал — забоялся. Причем не знаю, чего больше — что не поймет и придется второй раз вбивать, или что все равно поймет и сделает. Попросил сгенерировать к этому коду комментарий, оказалось, всё понимает:

 /**
   * Count the number of workflow notifications that belong to the current user
   * and are unread.
   *
   * @return int
   *   The number of unread notifications.
   */

В целом этого достаточно уже, чтобы пользоваться повседневно. Как говорится, the future is here this is how I disappear.

Завтра заставлю роботов писать за меня юнит-тесты. А также нажму манящие кнопки Refactor и Explain рядом с кодом.