Laravel

Интеграция Доктуриста с Точкой

graker — Mon, 08 Jun 2026 22:30:00 +0000

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

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

Дано

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

Задача: нужно сделать что-то более автоматизированное, чем старательно переписывать входящие платежи из банк-клиента. То есть получать входящие платежи в Доктуристе.

Кроме того, агенты часто принимают оплату по ссылкам: создают в банковском приложении ссылку на оплату определенной суммы картой и/или СБП и отправляют туристу. Это такой облегченный эквайринг, когда можно не делать полноценную форму оплаты. И банк не против (если соблюсти определенные правила). Задача 2: почему бы не дать пользователям возможность создавать ссылки на оплату прямо из интерфейса Доктуриста. Чтобы они могли копировать их и отправлять клиентам, а банковское приложение открывать было не нужно.

Вот что конкретно мы научили Доктурист делать:

— получать уведомления от банка о каждом входящем платеже;
— автоматически привязывать платеж к бронированию (если это возможно);
— давать пользователю привязывать платеж к бронированию вручную (если автоматически не вышло);
— создавать ссылки на оплату картой и/или СБП.

С чем столкнулись в процессе

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

Вебхуки как подписанный JWT

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

Контроллер читает сырое тело запроса и декодирует JWT через библиотеку firebase/php-jwt:

$token = $request->getContent();
$pem   = config('services.tochka.jwt_public_key_pem');
$data  = JWT::decode($token, new Key($pem, 'RS256'));

При любой ошибке декодирования — логируем и тем не менее отвечаем http 200. Это важно: Точка интерпретирует любой не-200 как сбой и будет повторно доставлять уведомление. А так — бизнес-логика не выполняется, но и банк не уходит в цикл отправки.

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

Умная авто-линковка

Когда платёж приходит от банка, система пытается найти бронь автоматически — по тексту назначения платежа (например, «Оплата по бронированию ДЕМ-001»). Здесь возникает классическая проблема строкового поиска: если в агентстве есть брони ДЕМ-10 и ДЕМ-100, то поиск ДЕМ-10 найдёт обе. Но мы не хотим ошибиться при связи броней с платежами, поэтому автоматически связываем только если найден ровно 1 результат.

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

Очень умная авто-линковка

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

После некоторых исследований оказалось, что хотя платежи в банк-клиенте показываются с нормальным назначением типа Оплата тура ФИО, номер брони, как мы задумали, в вебхук почему-то вместо этого прилетает Оплата по QR-коду ID QRABCD12345678 …. Пришлось реализовать дополнительный метод из API, который при получении платежа с таким описанием дергает Точку еще раз, чтобы получить инфу о данном QR-коде. В этой информации назначение платежа уже правильно отражается и по нему можно линковать платеж к брони.

Валютная конвертация при привязке

Точка естественно присылает суммы в рублях, поскольку расчёты в России могут быть только рублевые. Но брони в Доктуристе могут быть заведены и в USD, и в EUR, так как туроператоры могут работать в этих единицах, а платежи принимать по курсу. Когда пользователь вручную привязывает рублёвый платёж к заявке в EUR, система должна рассчитать сумму в EUR, чтобы записать её в правильной валюте. При этом у каждого туроператора свой курс конвертации.

Для этих случаев сделали два сценария:

Валютная заявка + override → пользователь вводит вручную, какое количество USD/EUR получается из платежа (например, «150 EUR»), мы используем это значение в сохраняемом платеже по брони и вместе с ним сохраняем расчетный курс валюты.
Валютная заявка, без override → берём последний курс ЦБ (он обновляется каждый день). В таком случае мы отмечаем связанный платеж как требующий внимания, поскольку авторасчет по курсу ЦБ это примерный расчет, а курс у операторов всегда выше.

Дефолтные значения при создании платежных ссылок

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

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

Песочница

В самом начале разработки из документации на API Точки выяснилось, что у них нет полноценной песочницы, позволяющей проводить «игрушечные» платежи, есть только фиксированный набор тестовых запросов, которые, если сделаны верно, возвращают фиксированные ответы. Тестовые запросы конечно небесполезны, но без песочницы невозможно, например, провести полный тестовый цикл: генерация платежной ссылки → её оплата → получение платежа → разбор и линковка к брони. Только по частям.

Собственно, создание ссылок пришлось по большей части тестировать наживую, поскольку оно работает только на аккаунтах, для которых уже активирован эквайринг, а для остальных аккаунтов кидает ошибку 403 "Forbidden by consent".

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

Результаты

100+ тестов на разные случаи жизни. Мы сделали верификацию JWT-подписи, дедупликацию, авто-линковку с граничными случаями, валютную конвертацию, права доступа. Интеграция API работает с Laravel Horizon, то есть все входящие и исходящие процессы (уведомления о платежах, создание платежной ссылки, регистрация пользователя в системе, регистрация вебхуков) запускаются асинхронно в очередях. А для уведомления ожидающих пользователей используются вебсокеты через Reverb.

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

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

Про пакет Canvas в Laravel

graker — Thu, 16 Apr 2026 07:00:00 +0000

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

Решил, что этого конечно мало и какой-никакой джентльменский набор функций для постинга надо иметь. Хотя бы:
— редактор с форматированием и загрузкой картинок
— рубрики и/или теги
— редактируемые адреса страниц
— минимальную админку, чтобы из панели Orchid туда заходить

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

Поиск и чат жопотэ присоветовали пакет Canvas для Laravel, его и взял. Редактор Quill внутри, небольшая админка на Vue.js с тёмной темой, есть немного лишних приблуд типа счётчика просмотров, есть базовое SEO, топики и теги. В общем, достаточно, чтобы не делать самому.

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

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

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

Стали делать — чото не работает, патченые контролы не собираются. И тут Клод такой: Je m'en fous, не патчатся исходники — я тебе попатчу билд! И написал скрипт на питоне, который транслит и ручные слаги просто втыкает в минифицированный джаваскипт. И прописал в пост-инсталл скрипты композера.

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

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

P.S. Ещё недавно на другом проекте поработал с BookStack — прикольным wiki-решением для документации. Но оно для моих целей чересчур. И к тому же не прокатывает как ещё одна зависимость: её надо на отдельный сабдомен втыкать. И композером не обновляется — авторы предлагают обновления через git pull ставить.

Доктурист — CRM и документооборот для турагентов

graker — Sun, 29 Mar 2026 12:05:00 +0000

Ну что ж, прошло несколько лет, ковидов, и других катаклизмов — и я открыл-таки регистрацию в нашей туристической crmке, которая называется Доктурист. Ура!

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

Теперь можно вернуться в нормальный режим постепенной подготовки и накатывания обновлений. По чуть-чуть, но непрерывно, добавлять, улучшать, допиливать и даже переделывать. Как оно и должно было быть у нормального программного обеспечения. Continuous integration, continuous delivery. Continuous joy.

В ближайшее время на очереди — открытие раздела статистики и подключение сервиса оплаты картами (сейчас пока можно только запросить счёт для оплаты по реквизитам).

По технической части (у нас же здесь технический бложек) Доктурист — это Laravel, Vue.js, Redis / Horizon / Supervisor для очередей, Reverb для вебсокетов, Pulse для быстрого ревью чо-как в системе, Canvas для новостей и статей, и ~1000 тестов по методике TDD для лучшей поддерживаемости. Vue.js используется версии 2. Прежде чем пытаться апгрейдить фронт на 3 (серьезная работа) — нужно было довести до ума что есть. В конце концов, я только в прошлом году апнул Laravel с 5 до 12.

В общем, если вы турагент, добро пожаловать! На сайте https://docturist.ru есть также ссылки на телеграм-канал и чатик. А если нет — можете просто за меня немножко порадоваться. Не каждый день удается отбросить сомнения и все-таки запустить проект, который начал делать еще в прошлом десятилетии. Есть повод порадоваться.

Laravel и тайна потерянного global scope

graker — Thu, 05 Feb 2026 20:30:00 +0000

Если у вас к модельке в Ларавеле был прикручен global scope и работал как часы, как вдруг в новой функции потерялся, или сломался — посмотрите, не используете ли вы raw-методы. Например, whereRaw(), или orderByRaw() в этой новой функции.

Global Scope — это класс, в котором можно один раз определить условия и затем применять их автоматически ко всем eloquent-запросам той или иной модели (то есть к запросам через Model::). Например, можно написать global scope для ограничения моделей по автору, чтобы к любому запросу типа Order::all() автоматически добавлялось ->where('user_id', '=', Auth::user()->id).

Так вот, оказывается, global scope чувствителен к наличию «сырых» запросов. Но это не значит, что их нельзя использовать вместе, можно. Всё дело в том, что билдер запроса не изолирует «сырые» условия от «нормальных». И если у вас есть например вот такое условие в whereRaw():

(DAYOFYEAR(date_of_birth) - DAYOFYEAR(?) BETWEEN 0 AND 30) OR (DAYOFYEAR(date_of_birth) - DAYOFYEAR(?) BETWEEN -365 AND -335)

то билдер не добавит за вас никаких скобочек и пристыкует условие из скоупа как есть:

(DAYOFYEAR(date_of_birth) - DAYOFYEAR(?) BETWEEN 0 AND 30) OR (DAYOFYEAR(date_of_birth) - DAYOFYEAR(?) BETWEEN -365 AND -335) AND (user_id = 3)

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

Решение, как теперь очевидно, простое: всегда, когда требуется использовать whereRaw() нужно всё условие целиком оборачивать в скобочки.

А ещё можно пойти дальше, переписать класс билдера, добавив скобочки в whereRaw() автоматически, и в своих моделях указать использовать этот новый билдер. Как вот здесь сделали.

P.S. Собственно, это же может произойти и просто если использовать одновременно whereRaw() и where(). Так что, следите за скобочками.

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 есть вывод моделей в таблицы, который довольно легко и удобно собирается, при этом столбцы таблицы можно сделать фильтруемыми и сортируемыми — тоже легко. Вот, например, объявили колонку «Название» с сортировкой и фильтром (по фрагменту текста)…

О выборе между CMS и фреймворками и некоторых мифах этого выбора

graker — Fri, 14 Nov 2025 14:50:00 +0000

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

— CMS только для несложных / шаблонных проектов;
— если нужна нестандартная логика — поможет только фреймворк.

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

CMS — Content Management System, система управления контентом. Популярные CMS — это Wordpress, Drupal, ModX, Joomla и, конечно же, 1С-Битрикс. В CMS предполагается наличие административного интерфейса и настроек.

Фреймворк (framework) — это набор инструментов, библиотек и способов написания кода, который обычно не предполагает уже существующих настроек и конфигураций, а предполагает их программирование. Популярные фреймворки веб-разработки — это, например, Laravel, Symfony, Django, Yii, Ruby on Rails, Next.js.

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

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).

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

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

Сериальный телеграм-бот TV Botopotamus

graker — Thu, 02 Oct 2025 08:25:00 +0000

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

Со временем всё самое хорошее, что уже было снято, посмотрел и стал смотреть новое. В связи с чем встал вопрос отслеживания выхода новинок. Долгое время отслеживал с сайта addic7ed.com, где добрые люди неустанно изготавливают для сериалов субтитры. Причём, делают это крайне быстро, так что в списке последних добавленных сабов обычно и видны все новинки.

Помню, когда-то таким образом отловил «Шерлока» — того что с Камбербетчем и Фриманом — и посмотрел через несколько часов после выхода. Понравилось, написал заметку, а через пару месяцев права на показ купил Первый канал, и я еще долго на эту заметку собирал трафик, поскольку написал про сериал чуть ли не первый.

Продолжаю работать над CRMкой

graker — Sun, 21 Sep 2025 10:55:00 +0000

Есть такой сервис Qui-Quo, им турагенты пользуются, многие — если не все. Позволяет с помощью браузерного плагина организовывать удобные подборки предложений для отправки клиентам. Ну и еще всякое полезное.

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

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

Ляпота. Когда-нибудь я психану, перестану смотреть в бэклог, запилю CRMке какой-нибудь лендос и открою регистрацию.
Да.
Да.

Да что такое этот ваш процентиль

graker — Tue, 16 Sep 2025 08:00:00 +0000

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

Для начала немного определений и полезного матана.

Процентиль P — это такое число, что P% значений в наборе данных меньше или равны этому числу. Например, в наборе [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] число 8 — это 90й процентиль, т.к. 90% чисел в этом наборе меньше или равны 8. Из других примеров, 0й процентиль — может быть вам известен как минимум, 100й процентиль — максимум, а 50й процентиль вы можете знать под именем медиана.

Процентили — это, кстати, частный случай квантилей. Квантили — примерно то же самое, только выражены не в процентах, а в долях от 0 до 1 (ну или в вероятностях, если так удобнее). Процентиль — это квантиль*100%.

Численный показатель (не)годности статьи или заметки в блог можно было бы назвать (не)адеквантилем.

Итак, нафига нам эти процентили.

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

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

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

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

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

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

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

Обновление с Laravel 5 до Laravel 12

graker — Mon, 21 Jul 2025 20:10:00 +0000

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

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

Без лишних прелюдий, дано:

Legacy-код на Laravel 5;
набор из 580 тестов (код разрабатывался по TDD);
Cursor AI бесплатная версия — чтобы было видно, что с ней, на автовыборе модели, тоже можно.

Нужно: обновить код до Laravel 12 так, чтобы он не сломался.

TL/DR если не хочется читать технические подробности:

ИИшечка помогает, но есть нюансы (внутри заметки).

Без ИИшечки я бы ещё очень долго это откладывал.

А без пакета заботливо написанных при разработке тестов скорее всего вообще не стал бы.

Задача была выполнена.

Суммарное время выполнения составило около 8-9 часов.

Итак, нам нужно обновить Laravel 5 до 12. Делаем мы это по шагам, то есть так: 5 → 6 → 7 → 8 → 9 → 10 → 11 → 12, всего 7 обновлений. Для каждого разработчики Ларавела заботливо написали roadmap по апгрейду. Вот например для апгрейда до Laravel 6: https://laravel.com/docs/6.x/upgrade

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'].

CRM для туристических агентств

graker — Thu, 03 Jul 2025 15:15:00 +0000

В 2017 году уговорил жену открыть турагентство, взяли домен, собрал сайт на OctoberCMS, и так появилось туристическое агентство AlayTravel. После чего, поскольку программировать я люблю, искать лёгких путей — нет, а жена вообще хотела всё записывать в эксель, сел писать для агентства систему CRM/документооборота. Взял Laravel и Vue.js, методику Test Driven Development, и через какое-то время написал. Жена начала пользоваться, а я — потихоньку дорабатывать первую «наивную» реализацию и думать, что с этим дальше делать. Ну, потому что писать целую CRM имея в виду работу одного агентства — это немножечко ~~overkill~~ чересчур.

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

И только я опять хотел вернуться к своей цеэрэмке, как началась СВО. И полетные программы несколько подсократились, и понимание чего там дальше будет немножко размыло. Но, видимо помня короновирус, туристы очухались и полетели. И в принципе стало ясно, что будут летать дальше (тьфу-тьфу-тьфу). К этому моменту у меня уже на CRM было не очень много времени, так что она работала себе и работала — для одного агентства.

Но несколько месяцев назад, когда на Ближнем Востоке активно летали ракеты, я подумал:

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

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

Совпадения айдишников в тестах

graker — Sun, 04 May 2025 08:25:00 +0000

Когда мы пишеем тесты на бэкенд-путь, который возвращает данные с отношениями, ($order, в нём $order→user, в нём $order→user→plan и т.д.) — следует избегать проверять отсутсвие тех или иных id через assertJsonMissing(['id' => $order2->id]) и ему подобные методы. Когда тестов окажется много, и мы их запустим разом, инкремент-айдишники в таблицах побегут и в какой-то момент внутри $order, который в json есть, внезапно окажется $user у которого id такой же как у $order2, и тест не пройдет.

Имеется в виду запуск всего пакета тестов, например, в Laravel с включенным трейтом RefreshDatabase: таблицы БД после каждого теста чистятся, но структура заново не пересоздается. Это и быстрее, и более похоже на «живую» среду.

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

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

Неправильно:

  $response->assertJsonMissing(['id' => $order2->id]);

Этот код будет искать по содержимому всего json и рано или поздно найдет вложенную зависимость со случайно совпавшим id.

Правильнее будет например:

  $data = $response->decodeResponseJson('data');
  $this->assertNotContains($order2->id, array_map(function ($order) {
    return $order['id'];
  }, $data););
  // так мы явно показываем, на каком уровне вложенности тестируем
  // также можно использовать замыкания внутри assertJson(), позволяющие ходить по уровням структуры документа