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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, благо там есть поиск по всем существующим настройкам.