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

Но что гораздо печальнее — многие программисты уже и сами разучились, или даже забыли научиться тому, что там было написано.

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

• Что именно не получается?
• Что ты делаешь?
• Какую ошибку видишь?
• Как уже пытался исправить?
• Почему мне приходится задавать эти вопросы?

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

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

• Что не получается?
• Делал всё что ты рекомендовал, выводится ошибка.
• Какая ошибка-то?
• Ошибка с файлом aaa.json, текст которой ты просил в прошлый раз.
• Так я первым пунктом предложил прибить этот файл и посмотреть какая будет новая ошибка. Ты сказал что всё попробовал. Ну и?

молчание, конец сеанса связи

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

И всё.

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

Но оказалось, что в Drupal 8 эта проблема начинается уже с экспорта. Экспортированный ru.po с сайта, где с плюрализацией всё в порядке, внезапно содержал дефолтную английскую формулу. Попытка выкачать и вставить нормальную формулу со старого сайта на Drupal 7 тоже не помогла. При импорте просто ничего не происходило, формула оставалась дефолтной.

Пришлось поковыряться в коде и оказалось что в Drupal 8 формула плюрализации хранится (в state) не в виде строки, а в виде массива вариантов. Пришлось сделать сначала

drush eval "print_r(\Drupal::state()->get('locale.translation.formulae', []));"

на нормальном сайте для получения русской формулы.

После чего оформить её в правильный массив и выполнить вот такой код:

$formula = Array(
  'ru' => Array(
    'plurals' => 3,
    'formula' => Array(
      1 => 0,
      2 => 1,
      3 => 1,
      4 => 1,
      21 => 0,
      22 => 1,
      23 => 1,
      24 => 1,
      31 => 0,
      32 => 1,
      33 => 1,
      34 => 1,
      41 => 0,
      42 => 1,
      43 => 1,
      44 => 1,
      51 => 0,
      52 => 1,
      53 => 1,
      54 => 1,
      61 => 0,
      62 => 1,
      63 => 1,
      64 => 1,
      71 => 0,
      72 => 1,
      73 => 1,
      74 => 1,
      81 => 0,
      82 => 1,
      83 => 1,
      84 => 1,
      91 => 0,
      92 => 1,
      93 => 1,
      94 => 1,
      101 => 0,
      102 => 1,
      103 => 1,
      104 => 1,
      121 => 0,
      122 => 1,
      123 => 1,
      124 => 1,
      131 => 0,
      132 => 1,
      133 => 1,
      134 => 1,
      141 => 0,
      142 => 1,
      143 => 1,
      144 => 1,
      151 => 0,
      152 => 1,
      153 => 1,
      154 => 1,
      161 => 0,
      162 => 1,
      163 => 1,
      164 => 1,
      171 => 0,
      172 => 1,
      173 => 1,
      174 => 1,
      181 => 0,
      182 => 1,
      183 => 1,
      184 => 1,
      191 => 0,
      192 => 1,
      193 => 1,
      194 => 1,
      'default' => 2,
    )
  )
);

\Drupal::state()->set('locale.translation.formulae', $formula);

Тогда нормальная формула вернулась на место.

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

Время от времени бывает необходимо организовать файловое хранилище за пределами /public. Например, для того, чтобы контролировать доступ к файлам (недоступным по прямой ссылке) по неким правилам.

Сходу из коробки в Laravel 6 такая фича на 100% не предусмотрена, но сделать её руками достаточно нетрудно.

Для начала разобьем задачу на части. Нам нужно:

1. Определить, где будут храниться файлы (private storage).
2. Прикреплять файлы к некой модели, чтобы на основе этой модели управлять доступом.
3. Обеспечить сохранение файлов в private storage.
4. Реализовать, собственно, контроль доступа и выдачу файлов по некоему пути.
5. На закуску добавим автоматическую генерацию миниатюр.

Далее мы разработаем приватное файловое хранилище с управлением файлами с помощью библиотеки spatie/laravel-medialibrary.

Несколько лет назад прикупил вместо поднадоевшего Нетбинса прогрессивную среду разработки под названием PHPStorm. С тех пор пользуюсь постоянно, и время от времени нахваливаю.

А недавно заметил, что некоторые фокусы, которые в PHPStorm (и других IDE этого производителя) мне уже привычны, для кого-то могут быть неочевидными. Все мы уже взрослые, опытные, образованные и поэтому мануалы читаем только когда что-нибудь уже сломалось. А то бы и так знали все эти мелочи, а не находили опытным путем, или подглядев у кого-нибудь.

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

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

Важное уточнение: если я говорю про хоткей (он же шорткат), то есть про комбинацию кнопок — она по умолчанию у вас может быть выключена. В таком случае нужно искать её в настройках IDE, благо там есть поиск по всем существующим настройкам.

В первой части статьи мы строили бэкенд на Laravel для вывода разнородных событий на календаре. В этой части мы рассмотрим построение фронт-энда на Vue.js с помощью FullCalendar, для которого есть интеграция fullcalendar-vue. Получится примерно как на картинке.

Что вообще должен делать наш фронт-энд?

Во-первых, загружать из бэк-энда события по созданному ранее пути /api/calendar.

Во-вторых, отображать эти события в соответствии с установленными для них датами.

В третьих, как-то визуально отличать одно событие от другого, чтобы было нагляднее.

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

Будем считать эти четыре пункта нашим ТЗ на фронт-энд и приступим к реализации.

В данной заметке из трёх частей рассматривается построение календаря, отображающего события, связанные с разнородными сущностями системы. Бэк-энд реализован на Laravel, фронт — на Vue.js. Календарь сделаем с помощью Full Calendar и соответствующей интеграции fullcalendar-vue.

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

В результате получится примерно вот так:

Когда-то давно, ещё в аспирантуре, один ученый муж всё время говорил мне: «Роман, делай правильно. Выполнил работу — оформи её. Напиши статью».

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

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

Некоторое время назад обнаружил статью, где показывалось, что трейт RefreshDatabase в тестах позволяет им (тестам) работать с MySQL быстрее, чем с Sqlite в режиме memory. Это выглядело странно и почти немыслимо, но оказалось, что, действительно, так и есть. Перевёл в нескольких проектах юнит-тесты с Sqlite на MySQL, заменил трейт с DatabaseMigrations на RefreshDatabase, и полный пакет тестов стал выполняться в среднем на ~30% быстрее (плюс большая совместимость с реальной средой достигается).

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

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

Решить эту проблему, однако, очень просто. Нужно в «режиме TDD», то есть при запуске отдельного теста, использовать другой конфиг. В котором вместо MySQL подставлен sqlite:

<env name="DB_CONNECTION" value="sqlite"/>
<env name="DB_DATABASE" value=":memory:"/>

И запускать тест так:

phpunit -c phpunit_sqlite.xml <путь к тесту>

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

alias tdd="phpunit -c phpunit_sqlite.xml"

Понятно, работать будет не для всех случаев. Например, если какой-нибудь из пакетов (spatie/laravel-tags, скажем) использует нативную поддержку JSON в MySQL, тесты этого функционала в sqlite работать вообще не будут. Но в целом этот трюк на длинной дистанции (особенно, с не очень быстрым компьютером) сэкономит прилично времени.

Есть такая известная парадигма в ООП — сервис-контейнеры. Суть её в том, чтобы получать реализацию того или иного сервиса, который тебе зачем-то нужен, из некоего контейнера. То есть не задумываясь о деталях, о том, что это за класс и т.д. Обращаешься к контейнеру — а контейнер сам определит, что надо, и вернет нужный сервис. Очевидно, если заранее не знаешь, о чем речь, из такого пояснения ни фига толком не ясно. Обычно эти пояснения иллюстрируются примерами. В доках Ларавела, скажем, используется пример EventPusher-а и его реализации через Redis.

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

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

Допустим, вы в своих проектах практикуете TDD. И у вас, помимо всех остальных тестов, проверяющих всё на свете, есть тест создания какой-нибудь модели через API Post, или просто через форму. И вот внезапно вам понадобилось подцепить на эту форму проверку reCAPTCHA против спаммеров. Реализовать саму логику работы во фронте (на Vue.js) и проверку полученного токена в бэке — нетрудно (вот пример).

А вот тест создания модели (и все связанные с этим роутом/формой тесты) — немедленно поломаются. Потому что где вы возьмете валидный ключ капчи для проверки, если он в тестовом режиме не прилетает из фронта?

Можно было бы попытаться организовать прохождение капчи для бэк-энд тестов (хотя я не совсем понял, как это именно в случае reCAPTCHA сделать). Но: — от этого нет пользы помимо тестирования; — у нас нет задачи тестировать гугл-капчу в каждом тесте бэкенда, который проверяет работу методов post/put у каждой защищенной капчей формы; — для тестирования внешнего сервиса достаточно одного теста интеграции — что мы верно всё подключили — а остальное есть забота разработчика внешнего сервиса; — если каждый тест формы будет проверять ключ капчи через сервис гугла, тесты внезапно станут значительно дольше работать.

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

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

Метод morphWith

Конкретно этот метод есть в доках, но он появился совсем недавно, в версии 5.8.22 (а текущая — 5.8.25) и не сразу нашёлся именно поэтому. Суть вот в чем. Допустим, у нас есть модель Event, которая радостно полиморфирует с другими моделями. Для неё отношения описаны так:

class Event extends Model
{
    protected $with = ['parent'];

    public function parent() {
        return $this->morphTo();
    }

    // ...
}

Как мы видим, благодаря свойству $with модель будет сразу загружаться с родителем, независимо от того, что это за родитель. Однако что, если нам нужно разом загрузить и какие-то отношения этого (неопределенного пока) родителя с другими моделями. Допустим, модели Payment и Deadline связаны полиморфно с Event, и в то же время модель Payment связана с моделью Order, а Deadline — скажем, с моделью User. Примерно так:

class Payment extends Model
{
    public function events() {
        return $this->morphMany('App\Event', 'parent');
    }

    public function order() {
        return $this->belongsTo(Order::class);
    }

    // ...
}

// (в другом, конечно, файле)

class Deadline extends Model
{
    public function events() {
        return $this->morphMany('App\Event', 'parent');
    }

    public function User() {
        return $this->belongsTo(User::class);
    }

    // ...
}

И мы хотим, чтобы платежи грузились с заказами, а дедлайны — с пользователями. Конечно, мы могли бы воспользоваться свойством $with для моделей Payment и Deadline. Но что если в Order и User уже используется свойство $with для загрузки платежей и дедлайнов? Тогда мы не сможем воспользоваться этим свойством, поскольку уйдем в рекурсию.

Тут-то и поможет нам метод morphWith():

$events = Event::query()
            ->with(['parent' => function (MorphTo $morphTo) {
                $morphTo->morphWith([
                    Payment::class => ['order'],
                    Deadline::class => ['user'],
                ]);
            }])
            ->get();

То есть что мы тут делаем? Мы вызываем для отношения MorphTo метод morphWith() и для каждого класса родителя, для которого нужно грузить его отношения, указываем массив из этих отношений. И они грузятся.

А что если надо отменить eager loading

Может возникнуть и прямо противоположная проблема. Допустим, мы автоматически грузим модель Payment из Order через свойство $with — это будет работать всякий раз, когда модель заказа загружается. Но что если нам в данном конкретном случае нужно автоматически загрузить заказы для группы платежей, и не попасть при этом ни в рекурсию, ни в «проблему N+1 запросов»?

Очевидно, нужно отключить eager-loading. Вот два примера, как можно это сделать.

1) Если может возникнуть рекурсия из-за $with, можно отключить автозагрузку прямо в объявлении отношения:

public function order() {
    return $this->belongsTo(Order::class)->setEagerLoads([]);
}

Здесь мы говорим, что при загрузке заказов для данных моделей, не нужно автоматически грузить никакие модели, связанные с заказами (и перечисленные в Order::$with). Кстати, вместо пустого массива мы можем передать массив из отношений, которые всё же нужно загрузить, ограничив таким образом автозагрузку заданным списком.

2) Если же мы прогружаем отношения явным образом с помощью метода load(), можно отключить автозагрузку вот так:

$payment->load(['order' => function ($query) {
    $query->setEagerLoads([]);
}]);

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

Не нужно, в общем, торопиться с оптимизацией.