Программирование

Критическое обновление безопасности PHP

graker — Wed, 21 Oct 2026 08:55:00 +0000

Сегодня в 14:00 UTC (в 5 вечера по Москве) выйдет критическое обновление безопасности PHP https://www.php.net/archive/2026.php#2026-10-20-1

Обновление такой чудовищной критичности, что никаких деталей не раскрывают, чтобы заранее не взломали вообще всех.

Так что заготавливаем консольки, открываем докер-конфиги и вперёд, обновлять всё по кругу.

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

PR на шиссот!

graker — Wed, 07 Oct 2026 18:30:00 +0000

На днях PR на 610 файлов был окончательно повержен и смерджен! На выходе получился полный редизайн Доктуриста. Наружной части (лендинга и блога) немного тоже, но в первую очередь — всего внутряка. Всех страниц, форм и диалогов самой crmки.

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

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

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

Тут уже и показатели всякие, и главное лента с броньками более умная. Хочешь, смотри последние брони по дате, хочешь — требующие определённого внимания.

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

Так или иначе, когда есть новое оформление — остальные страницы оставлять в старом не хочется. И так, страничка за страничкой, компонент за компонентом мы сначала с Claude Design, а затем с Claude Code привели весь сервис к новым стилям. А поскольку просто так перерисовывать скучно, то заодно переосмыслили, доработали и переделали компоненты на страничках.

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

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

— Доктурист запоминает и сразу показывает набор операторов, с которыми часто работает агент, не нужно каждый раз искать по автодополнению.
— / или Ctrl+F немедленно включают поиск по всем данным (повторный Ctrl+F включает нативный поиск).
— Документы по брони можно сгенерировать и подписать прямо из всплывашки с рабочего стола, необязательно в бронь проваливаться.
— Улучшена работа календаря на мобильных устройствах (мобильный календарь просто сделан заново).
— Страница профиля наконец-то разделена на 5 секций по соответствующим тематикам настроек.

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

Доктурист — умный ежедневник турагента

Нейросети и анализ кода

graker — Wed, 22 Jul 2026 09:15:00 +0000

Вчера считал эстимейты на группу из ~40 тикетов. Все сделаны по отчету ИИ об анализе кода большого проекта на Drupal. Проекту около 10 лет, кодовая база развивалась все это время, 20 поддоменов, интеграции, апишки, синхронизация контента, в общем прикольный проект.

Отчет структурированный, нейросеть проверяла всех четырёх всадников попокалипсиса в проекте: Уязвимости, Баги, Тормоза и Грязный код. Изначально из переданного отчета получалось гораздо больше задач, но процентов на 30% я сразу won't fix навесил. Там и глюки нашлись, и непонимание контекста. Но 40 тикетов тем не менее осталось.

Среди них тоже в основном таски с минимальнейшим приоритетом, типа

в кастомном модуле не проставлена зависимость от чего-нибудь типа paragraphs;
где-то в коде наглый программист вызвал \Drupal::service() вместо инъекции зависимостей;
где-то deprecated-версии Друпала не убраны из поддерживаемых версий и тому подобное.

Нашлось и несколько более серьезных претензий:

парочка проблем N+1;
несколько XSS-уязвимостей (доступных только админам, но всё же);
несколько мест, где отсутствуют проверки на наличие ключа в массиве (спамит в лог предупрежденими);
и даже одна уязвимость типа timing oracle.

Да, грязненький код — признак грязненьких мыслей :) Да, хорошо бы всё это почистить. Но за вычетом 3–4 претензий, это получается больше ста часов работы суммарно, а выхлоп — немножко более чистый код, причёсанное legacy, немножко меньше техдолга и warning/debug-записей в логе. Хорошо конечно, когда заказчик не против провести такую генеральную уборку. И честь и хвала аккаунтам, которые могут убедить заказчика в необходимости такой уборки при примерно нулевой ценности для конечного пользователя.

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

Виртуализация локальной разработки, docker-compose и traefik

graker — Thu, 25 Jun 2026 15:20:00 +0000

Когда-то давно описывал довольно простой способ виртуализации проектов, над которыми работаю, чтобы было удобно переключаться и они друг другу не мешали. Прошло уже 7 лет и способ конечно эволюционировал. Когда-то использовать отдельные контейнеры, запускаемые по `docker run` было быстрее и удобнее и поэтому я докерфайлы и docker-compose-файлы не писал. Но прогресс конечно добрался до меня в этом вопросе и победил. Теперь я для локальной разработки тоже использую docker compose.

Инструментами со всякими пресетами типа lando или ddev я, тем не менее, стараюсь не пользоваться. В основном потому что когда с ними сталкивался, они нормально работали — до тех пор пока не надо было что-то в них поменять или сделать нестандартно. После чего начинался вынос мозга, иногда такой, что проще было самому пересобрать сразу.
Кроме того, если собирать «чистые» окружения, есть шанс лучше понять, как это всё работает, а если пользоваться lando, forge, ddev и прочими — наоборот.

Итак, чем docker compose лучше.

Изучаем C# и Unity

graker — Thu, 30 Apr 2026 17:45:00 +0000

Достаточно давно занимаюсь с сыном изучением C# через создание игр в Unity. До этого пробовали Scratch (слишком просто и немного скучно) и Lua с Роблоксом, тоже не зашло. Наверно, ввиду ограниченности применения.

В общем, взялись за игры в Unity и, посмотрев пару-тройку видеоуроков, решили что лучше по учебнику. Купил «Unity и C# Геймдев от идеи до реализации» Джереми Гибсона Бонда. Быстренько прочитал сам и стали заниматься.

Автор, как я понял, преподаёт геймдев в Калифорнийском универе, ну или что-то типа того, не вникал.

Книжку можно разделить на три части:

Некоторая теория и философствования на тему геймдизайна. С точки зрения занятий с детьми часть не очень полезная, но в целом почитать интересно. Вероятно тем кто хочет стать геймдизайнером — может быть полезно.
Теория по программированию на C#. Тут всё как обычно, разбор основных принципов программирования: hello world, переменные и типы данных, циклы, условия, классы и наследование. Учебные примеры, чтобы не заморачиваться, исполняются сразу в Unity.
Разработка игр. Добрая половина книги — после теории — посвящена настоящей разработке настоящих игр. Каждая глава описывает пошагово разработку отдельного прототипа игры с рабочим играбельным результатом в конце. По учебнику можно создать 7 разных игр, в том числе скролл-шутер, пасьянс, клоны Angry Birds и даже старой The Legend of Zelda.

Автор дает как концепции кодинга под Unity, так и использования Unity Editor для создания префабов. Причем, в основном автор создает объекты, пользуясь возможностями самого редактора, а не загружает модельки откуда-то еще.

Обычно основная проблема бумажной литературы о современных технологиях — ты еще не успел купить книжку, а данные в ней уже устарели. Но в данном случае примеры на удивление актуальны. Расхождения с текущей версией Unity есть конечно, в части текстовых лейблов на экране, в части работы с XML, но учитывая год издания (2021) их довольно мало: запускается сразу как в примерах почти всё.

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

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

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

На первом приложенном видео — скролл-шутер, который мы написали по учебнику. На втором — результат упражнения по завершающей теоретическую часть главе. Это стая птиц, которая красиво летит за неким объектом, «роится», но при этом не сталкивается. Управлять ей нельзя, но можно регулировать параметры (скорость, количество птиц и т.д.) Это упражнение сын уже написал по книжке без меня.

Your browser does not support the video tag.

Код пишут роботы, но отвечать за него нам

graker — Wed, 08 Apr 2026 08:20:00 +0000

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

Но кто и раньше умел разрабатывать сам, всё-таки смотрит на предмет немножко под другим углом. Поэтому решил немного растечься мыслями, поворчать, позанудствовать и поразмышлять не о том, как настроить Codex, MCP-сервер, или натравить Claude Code на KWork. А об эффектах, о неизбежных изменениях, которые внесли, вносят и будут вносить в нашу повседневную работу — в разработку программного обеспечения живыми человеческими людьми — нейросети.

Сначала коротко определим наше место в пространстве и времени относительно самого феномена нейросетей (здесь и далее — в разработке ПО). Обсуждать, нужны ли они, помогают ли они, следует ли их использовать — уже поздно. Этот вопрос больше не стоит. Если вдруг еще не начали, надо начать. Кот смотрит на часы и говорит — Пора!

Снежный вайб-кодинг

graker — Thu, 26 Feb 2026 13:50:00 +0000

Если вы живёте за городом, обязательно нужно вайб-кодить. Особенно зимой.

Я тут как-то завёл себе подписку на Claude Code, и он довольно здорово работает. Описал задание, выставил нужные разрешения, чтобы он без лишних вопросов работал, запустил. И всё, можно идти на улицу чистить снег. Если снега много, можно и сразу несколько заданий выставить.

Последнее время использую Клода в хвост и в гриву. Судя по регулярным сообщениям о превышении дневных и недельных лимитов — интенсивнее уже некуда.

Чтобы лимитов хватало чуточку побольше, пользуюсь таким простым методом.

Сначала завожу проекту файлик CLAUDE.md, в котором описываю полезную для иишечки информацию о проекте. Какие технологии, методики, тесты, как почистить кэш и где найти нужные контейнеры. Этот файл принимается нейросетью к сведению при старте каждой новой сессии. В принципе, можно и Клода попросить составить этот файл командой /init, но он понимает сходу о проекте не всё.

MD — это Markdown, удобный способ форматирования текста в обычных текстовых файлах. Удобный и роботам, и человекам.

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

Как упомянул выше, дневные и недельные лимиты иссякают быстрее, чем хотелось бы. Чтобы немножко токенов сэкономить и чуть-чуть продлить беззаботный вайб-кодинг, рекомендую после пары-тройки выполненных задач посмотреть на лог сессий самому, или даже попросить агента порефлексировать. А именно: обновить по логам содержимое CLAUDE.md. Зачастую агент поначалу тупит и не сразу понимает, какой в точности командой правильно запустить тесты, или что не нужно лезть в контейнер, чтобы собрать фронт-энд.

Вот эти команды надо скорректировать, записать в CLAUDE.md тот вариант, с которым агенту удалось справиться с задачей. Чтобы он в каждой новой сессии не перебирал варианты заново.

Попользовался и консольным claude, и плагином в VS Code. Консольный поприкольнее, больше возможностей и команд всяких. К тому же его можно с отключенными проверками запустить — чтобы он не спрашивал, можно ли выполнить rm -Rf *, а сразу делал. Но и плагин тоже ничего. Работает и там, и там иишечка на совесть, месячная подписка, я считаю, окупилась в первые 3 часа использования.

В общем, хорошего вам снежного вайб-кодинга! Ну а летом достанем газонокосилку и займемся вайб-дебагом.

Laravel Reverb, броадкастинг и вебсокеты

graker — Tue, 20 Jan 2026 10:20:00 +0000

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

Ночные тесты и Laravel Scout

graker — Mon, 15 Dec 2025 16:00:00 +0000

Вчера перед сном решил — а ну-ка сейчас за 20 минут добью большую фичу. Долго делал, чуть-чуть осталось. Сел, открыл, и правда — через 20 минут фича была готова. Но чёрт меня дернул запустить после этого все тесты. Пока фичу делал — смысла не было запускать весь пакет. А тут, в ночи, решил запустить.

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

Посмотрел на проде — всё еще работает. Стал разбираться, чего такого я мог сломать. Отключил несколько установленных библиотек — вдруг конфликт у трейта Searchable с чем-нибудь. Включил обратно ту, которую наоборот — стёр за ненадобностью. Не работает.

Откатил контроль версий на точку до начала разработки фичи. Не работает! Подозрительно как-то. Накатил обратно. Обновил зависимости. Не работает.

Поотлаживал классы Скаута — увидел, что почему-то драйвер поиска определяется как null (то есть никакой)! Полез смотреть, оказывается у меня внезапно в .env прописано SCOUT_DRIVER=null! Хотя я просто полагался на дефолтное значение из конфига scout.php (который не менялся), и в .env вообще драйвер не прописывал.

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

В общем, пока нашёл ошибку и вернул нормальный драйвер, прошло уже конечно в разы больше 20 минут. Зато в конце увидел все тесты зелёными. На чем и ушел спать, вот только

Сортировка по json-полю в таблицах Laravel Orchid

graker — Fri, 21 Nov 2025 22:30:00 +0000

Спешно прикручиваю к своей туристической CRMке нормальную админку (которая для админов). Раньше была самописная с фронтом на Vue, из-за этого добавление любой новой страницы или функции требовало слишком много времени. Собрался с мыслями, решил наконец заменить её на Laravel Orchid. Дело пошло значительно быстрее, и в целом могу констатировать очевидное: как бы ни было прикольно играться с фронтом на Vue, какая бы небольшая ни была админка — лучше конечно сразу брать готовую панельку. А с фронтом играться в пользовательской части.

В процессе переноса столкнулся с неожиданной трудностью. В Orchid есть вывод моделей в таблицы, который довольно легко и удобно собирается, при этом столбцы таблицы можно сделать фильтруемыми и сортируемыми — тоже легко. Вот, например, объявили колонку «Название» с сортировкой и фильтром (по фрагменту текста)…

Почему не нужно писать тесты на визуал при разработке

graker — Tue, 11 Nov 2025 07:50:00 +0000

Вопрос касается не только TDD-разработки, но и написания качественных unit-тестов в целом.

В прошлой заметке был тест на проверку отправки юзеру в бот ссылки для входа на сайт. Вот код (я еще про Argument::that() хотел отдельно написать):

/**
 * @test
 */
public function user_issues_login_command_and_gets_a_message_with_login_button(): void
{
    $user = User::factory()->create(['telegram_username' => 'mr_phpunit', 'telegram_id' => '123456789']);
    $bot = Bot::factory()->create(['user_id' => $user->id,]);
    $bot->settings()->create(['register' => TRUE,]);
    $update = $this->generateMessageUpdate('mr_phpunit', '', '/login');

    $webhooksService = resolve(TelegramBotWebhooksInterface::class);
    $webhooksService->processUpdates($this->api->reveal(), $update); 

    // ожидаем что будет вызван метод sendMessage() где в тексте сообщения будет Please click the button below...
    // а ссылка в кнопке Login будет содержать роут быстрого логина
    $this->api->sendMessage(Argument::that(function ($params) use ($user) {
        return $params['text'] === "Please click the button below to log in with your account. You will be automatically redirected to your dashboard." &&
               strpos($params['reply_markup']['inline_keyboard'][0][0]['url'], route('bot.quick-login', ['user' => $user->id])) === 0;
    }))->shouldHaveBeenCalled();
}

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

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

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

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

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

$this->api->sendMessage(Argument::that(function ($params) use ($user) {
    return $params['text'] === __('login_link.description') &&
           strpos($params['reply_markup']['inline_keyboard'][0][0]['url'], route('bot.quick-login', ['user' => $user->id])) === 0;
}))->shouldHaveBeenCalled();

Возвращаясь к Argument::that() — как вы уже могли заметить, этот статичный метод (из мок-библиотеки Prophecy) позволяет проверять в переданных аргументах только то, что действительно нужно проверить. А без него методы типа shouldHaveBeenCalled() будут проверять все аргументы на точное совпадение. Что сделает наши тесты очень деревянными.

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

А для тестирования визуала есть более подходящие способы: инструменты, сравнивающие референсные страницы с заранее сохраненными скринами попиксельно и поднимающие шухер, если вдруг что-то куда-то съехало. Ghost Inspector, например.

Регистрация и логин через telegram-ботов в Laravel

graker — Wed, 05 Nov 2025 22:00:00 +0000

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

Далее немного расскажу, как это технически реализовано на Laravel (на котором написан Botopotamus.Ru).

У Телеграма есть и свой механизм авторизации, но он подразумевает ручную настройку каждого бота, который должен это уметь. А я в данном случае рассматриваю код, который работает для всех ботов разом и его не нужно через Телеграм настраивать. Пользователь просто жмёт «Зарегистрироваться» в боте, а потом жмёт «Войти» чтобы получить ссылку на автологин.

Под катом примеры с кодом.

С Днём программиста!

graker — Sat, 13 Sep 2025 12:40:00 +0000

С Днём программиста, программисты!

Сегодня можно купаться в торрентах и громить интернет-кафе!

Экономичные паттерны разработки

graker — Wed, 10 Sep 2025 08:55:00 +0000

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

Экономим 2 килобайта

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

Экономим две минуты

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

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

Экономим… что-то экономим

Определенно, это жемчужина моей небольшой и беспорядочной коллекции. Нам нужно аяксифицировать кнопочки в Drupal. Чтобы события не навешивались повторно, используется once(), который добавляет элементу атрибут data-once="ajax". Но чтобы враги ничего не поняли, сделаем так:

Кнопочки будем рендерить сразу с атрибутом data-once="ajax"!
В коде JS первым делом удалим этот атрибут!!
Скрестим пальцы и вознадеемся на правильный порядок исполнения и что вызов ajax-биндинга произойдет позже и не заметит удаленных атрибутов!!!

Возможно, таким образом пытались победить какие-то «гонки» в JS. Ведь, как известно, чтобы победить racing condition, нужно самому стать racing condition.

Как новичку попробовать в Test Driven Development

graker — Mon, 04 Aug 2025 07:45:00 +0000

Сегодня поговорим о Test Driven Development, то есть о разработке, движимой тестами. О том, с чего вообще она начинается, как начать писать код, и как продолжить. Для примеров будем использовать Laravel, в этом фреймворке многое заточено под тесты, примеры наглядные и лаконичные. Поехали.

В литературе по тестированию и TDD в частности очень любят приводить в пример тест, что функция sum(a, b) успешно складывает два числа. Сложно представить что-то более вредное для демонстрации методики. Этот пример:

скучный — поскольку по сути ничего не проверяет и ничего не демонстрирует;
практически бесполезный — поскольку изначально не нуждается в тестировании*;
не представляет собой важную функцию в нашем проекте*.

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

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

Laravel Livewire — вход по имени пользователя или электронной почте

graker — Tue, 15 Jul 2025 07:05:00 +0000

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

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

Макрос getOrFail в Laravel

graker — Sat, 05 Jul 2025 11:25:00 +0000

В Ларавеле есть удобный хелпер-метод: 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'].

Вдарим вольтом по лайвваеру

graker — Sun, 15 Jun 2025 13:30:00 +0000

На днях начал работу над новым проектом, и выдался хороший случай попробовать 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-кода напишем, это, строго говоря, действительно необязательно.

Пример разработки feature-теста с помощью ИИ

graker — Thu, 06 Mar 2025 10:30:00 +0000

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

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

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

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

ИИ или младший разработчик?

graker — Tue, 18 Feb 2025 08:45:00 +0000

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

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

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

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