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

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

public function loadAccountBalance(AccountInterface $account) {
    // Load site balance if user can administer transactions.
    if ($account->hasPermission('administer transactions')) {
      return $this->loadSiteBalance();
    }
    // Check if issuer balance exists.
    // ...

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

И если 1 человек, глядя на это, скажет — о, как удобно, я как раз так и хотел! То, я уверен, на него придется 99, которые скажут

Ах ты [censored] [censored] [censored] я два часа потратил [censored] [censored] руки этому [censored] оторвать бы

Еще одна клёвая находка в копилку полезных мелочей PHPStorm.

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

1. Создаем несколько строк, ставим курсор в нужное место.
2. Пишем число, с которого должна начинаться последовательность, например 0 или 1.
3. Выделяем это число.
4. Жмём Ctrl+Shift+A для вызова консольки действий над выделенным текстом.
5. Выбираем Create sequence.

Продолжаю не читать мануалы, а то бы сразу всё это знал и было бы неинтересно.

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

Тем не менее. Не делайте так.

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

а) давно;
б) общепринятыми способами;
в) скорее всего лучше, чем вы придумали;
г) наверняка не так, как вы придумали.

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

Поэтому 20 страниц описания тривиальной логики скорее помешают, чем помогут. В худшем случае их наличие приведет к конфликтам на этапе сдачи функционала, т.к. из лучших побуждений будет сделано не так, как было написано. А в лучшем случае — придется потратить изрядно времени на проработку вопросов типа «А вы уверены что нужно при регистрации вводить и никнейм, и ФИО, и почту, а то обычно это стараются упростить, а никнейм у вас вообще нигде не используется?» Или «а вы уверены, что при восстановлении пароля нужно присылать пользователю его пароль по почте, а то это небезопасно и так давно не делают?» Причем, по факту задавания вопросов обычно обнаруживается, что 99% старательно расписанных в ТЗ деталей будущей реализации не имеет никакого значения даже для самого автора документа. Просто так написали, потому что вроде надо было что-то написать, ну и мы старались чтобы солидно выглядело.

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

— нужно реализовать регистрацию на сайте
— при регистрации пользователь вводит электронную почту и телефон
— телефон должен верифицироваться отправкой смс
— после верификации телефона на введенную электронную почту отправляется одноразовая ссылка
— пройдя по ссылке, пользователь автоматически входит в систему и его направляет на страницу настроек
— на странице настроек пользователь должен ввести новый пароль для входа в систему, а также может указать свое ФИО, никнейм и поменять электронную почту
— а еще мы хотим чтобы кроме обычной регистрации была регистрация и вход через гугл, фейсбук, одноклассники и госуслуги с заполнением пользовательских данных из этих сервисов

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

Как же тогда написать длинное ТЗ, спросите вы? А никак. Если у вас нет прожженого продукт-оунера и бизнес-аналитика, съевших хотя бы толстый край собаки на разработке, то вообще не нужно его писать. Напишите коротко, что вы хотите сделать, найдите разработчика, которому вы готовы это доверить. И поговорите с ним. Если разработчик опытный, у него будет кто-то, кто выступит в качестве бизнес-аналитика и напишет требования. И будет кто-то, кто выступит как ведущий разработчик, он эти требования конкретизирует, уточнит противоречия и то чего не хватает (такое есть всегда), и декомпозирует в задачи для непосредственных исполнителей. Возможно, всё это будет даже один человек. Но главное что так всем будет проще.

В дополнение к посту XDebug, PHPStorm и Docker-контейнер. Иногда так бывает, что порт по умолчанию, который мы пробрасываем для работы с xdebug, занят. Например, вебсокетами. Пробросить которые через Docker — отдельная веселая история. В таком случае вот пример быстрой настройки на другой порт:

Вот это запускаем из контейнера с веб-сервером:

export XDEBUG_CONFIG="remote_enable=1 remote_mode=req remote_port=9003 remote_host=172.17.0.2 remote_connect_back=0 idekey=PHPSTORM"
export XDEBUG_TRIGGER=1 && export PHP_IDE_CONFIG="serverName=172.17.0.2"

А это с локалхоста, чтобы пробросить порт:

ssh -R 9003:localhost:9003 root@172.17.0.2

И всё, теперь PHPStorm будет слушать порт 9003.

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

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

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

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

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