Объявление свойств в конструкторе [перевод]

Larry Garfield пишет отличную серию статей о том, что из себя представляет PHP 8: о скорости, атрибутах, свойствах в конструкторе и многом другом. Сегодня посмотрим на его статью о объявляемых в конструкторе свойствах.

https://platform.sh/blog/2020/php-80-feature-focus-constructor-property-promotion/

Возможно, наиболее существенное улучшение PHP 8, в плане удобства разработки, это объявление свойств в конструкторе. Синтаксис в основном заимствован из Hack — PHP-форка от Facebook, но похожий синтаксис используется и в других языках, например TypeScript или Kotlin.

Сразу приведу простой пример. Рассмотрим типичный класс в современном приложении:

class FormRenderer
{
    private ThemeSystem $theme;
    private UserRepository $users;
    private ModuleSystem $modules;

    public function __construct(ThemeSystem $theme, UserRepository $users, ModuleSystem $modules) {
        $this->theme = $theme;
        $this->users = $users;
        $this->modules = $modules;
    }

    public function renderForm(Form $form): string
    {
        // ...
    }
}

Класс имеет 3 зависимости. Название переменной для каждой зависимости повторяется 4 раза: при описании аргумента конструктора, при описании свойства класса, при описании ссылки на свойство внутри конструктора и при инициализации этой ссылки. Получается очень громоздко, и хотя большинство IDE решают такие задачи авто-подстановкой, это всё ещё боль. Я знаю, что многие люди избегают инъекцию зависимостей из-за громоздкого описания.

В PHP 8 вышеописанную запись сократили до:

<?php

class FormRenderer
{
    public function __construct(
        private ThemeSystem $theme, 
        private UserRepository $users, 
        private ModuleSystem $modules,
    ) { }

    public function renderForm(Form $form): string
    {
        // ...
    }
}

Перемещение области видимости свойства в конструктор говорит PHP «Этот параметр — свойство, ты должен назначить ему значение». Эффект во время выполнения точно такой же, как в первом примере, но для такой записи нам потребовалось в 4 раза меньше текста.

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

<?php

class FormRenderer
{
    private User $currentUser;

    public function __construct(
        private ThemeSystem $theme, 
        private UserRepository $users, 
        private ModuleSystem $modules,
    ) { 
        $this->currentUser = $this->users->getActiveUser();
    }

    public function renderForm(Form $form): string
    {
        // ...
    }
}

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

Объявление свойств в конструкторе удобно использовать для простых объектов. Простые объекты — это объекты с некоторым количеством свойств и геттеров/сеттеров для этих свойств. Для таких объектов весь класс можно свести к конструктору:

<?php

Class MailMessage
{
    public function __construct(
        public string $to,
        public string $subject,
        public string $from,
        public string $body,
        public array $cc,
        public array $bcc,
        public string $attachmentPath,
    ) {}
}

Для внутреннего (не являющегося частью API) объекта public-свойства вполне могут использоваться. Если же объект является частью API или взаимодействует с какой-либо внешней системой, то свойства нужно инкапсулировать, и добавить методы для работы с ними. В любом случае код станет компактнее и удобнее.

При объявлении свойств в конструкторе нужно учитывать несколько моментов:

  • Определение области видимости применимо только к конструкторам, использование их в любой другой функции приведёт к ошибке;
  • Свойство не может быть объявлено как в конструкторе, так и за его пределами.

Спасибо Никите Попову за этот RFC, хотя поводом послужила моя запись в начале года в этом блоге, так что я требую себе 0.1% 🙂

Мы уже в плотную подошли к релизу PHP 8 и вот-вот сможем увидеть на практике что из себя представляет объявление свойств в конструкторе.

Парсинг сайтов с помощью PHP [перевод]

Оригинал — https://www.scrapingbee.com/blog/web-scraping-php/

Вероятно, вы видели один из наших предыдущих туториалов о том, как парсить сайты, например: Ruby, JavaScript или Python и думали: а как же насчёт самого часто-используемого языка для серверного web-программирования, который очень редко используют для этой задачи? Настал этот час — сегодня посмотрим, как парсить сайты на PHP!

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

Для примера мы попробуем получить список людей, у которых совпадает день рождения. Если вы хотите повторять примеры кода вместе с нами, удостоверьтесь что у вас установлена последняя версия PHP и composer.

Читать далее →

Поиск по триграммам

Этим материалом я открываю серию статей по методам полнотекстовых поисков. Будем разбирать:

  1. Elasticsearch — один из самых востребованных, судя по вакансиям, инструмент. Многое умеет, быстро ищет, поставляется со своим личным стеком утилит. Будем разбираться в следующей статье.
  2. Sphinx. Да-да, он вроде как уже мёртв, а вроде много где используется, хорошо работает, имеет адаптеры под разные языки и фреймворки. Так что — имеет право быть.
  3. Поиск по триграммам — интересный поиск, наименее затратный в плане реализации, и весьма эффективный. Работает благодаря расширению, подключаемому в Postgres. Именно он и будет темой сегодняшней статьи.

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

Читать далее →

Golang: Почему быстрее php и nodejs?

В 2020 у меня стоит цель — если не свичнуться в разработку на го в плане работы, то хотя бы сделать этот язык одним из основных в своём стеке.

Сейчас прохожу курс по go. Разбираясь в теме первых нескольких лекций, решил набросать конспект, сравнить логику работы Go с логикой работы PHP и nodejs, прежде всего затем, чтобы самому запомнить эту информацию. Может быть кому-нибудь это будет полезным 🙂 В ближайшее время изредка будут выходить небольшие, вроде этой, заметки с тем, что мне показалось неочевидным или интересным.

Читать далее →

Тесты, ревью и флоу вокруг разработки

В одной из компаний, где я работал, была замечательная надпись на стене — «97 дней без багов». Это была одна из немногих компаний, где ревностно следили за чистотой кода, за процессом деплоя и флоу вокруг программирования, что позволяло выдавать стабильность работы всего портала. А портал был далеко не маленький.

Сейчас я опишу эти практики и, надеюсь, кто-то возьмёт их себе на вооружение.

Читать далее →

Паттерн Transactional outbox

Что может быть сложного в логировании? Создал инстанс какого-нибудь Monolog’а, навтыкал $logger->info() под каждой строчкой, выполнение которой хотелось бы запечатлить в истории, и сиди себе посматривай в журнал. А вдруг где-то будет ошибка, лог не сохранится, а логируем мы данные банковских операций?

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

Читать далее →

Fullstack

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

Я скептично относился с полностэковым парням, пока не произошло два события: сначала мне пришлось начать писать на Vue, которые зашёл на удивление быстро (хотя отвращение к бесконечным async ещё осталось). А через какое-то время я посмотрел интересный доклад на TED, рассказывающий о такой идее:

Ты можешь всю жизнь пытаться стать лучшим в одной сфере, но шанс попасть в 1-5% — крайне мал, потому что всегда найдутся те, кто работают и понимают больше, чем ты. (конечно он есть, я не спорю) А можешь развиваться в двух или более направлениях и через какое-то время стать одним из, скажем, 15-ти % лучших в этих сферах.

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

«Нет, fullstack’ов не бывает!» — скажет читатель, уверенный в том, что описанная выше позиция заранее неверна. Может быть, может быть. Но я посмотрел достаточно компаний и людей, где фронтендер лихо утирал нос ведущим бэкам, а в ином месте бэкендер писал vue-логику быстрее и более красиво, чем глава отдела фронта. Мне кажется, что это лишь вопрос времени и сил. Если ты готов выделять хотя бы час времени в день на развитие себя как специалиста (помимо основной работы, конечно), если ты читаешь умные книжки и решаешь реальные кейсы на работе — ничего не помешает тебе стать абстрактным senior по Python и знать React на уровне middle+, чтобы понимать тех, кто пишет фронт для проекта, над которым ты работаешь и общаться с ними на одном языке.

Лично я для себя выбрал такой стек: PHP, как основной язык, Golang сейчас в стадии активного изучения и временами Vue, когда нужно сделать небольшой модуль или фронт для личного проекта. Основной акцент идёт на back, потому что к этому меня больше тянет, но читать статьи/документацию/книги по js/vue — тоже занятно, и порой я нахожу на это время.

А что ты думаешь по этому поводу?

Lumen + Docker + Websockets

Image for post

Последнее время работаю с Lumen. Lumen — это урезанная версия Laravel, аля symfony-skeleton для Symfony. По этой причине большинство решений, описанных для Laravel-систем, к Lumen’у прикрутить бывает сложно, а что-то и совсем невозможно, без переопределения vendor-пакетов.

Сегодня расскажу, как и с помощью чьей матери мне удалось завести web-сокеты в Lumen и успешно интегрировать их с Vue-клиентом.

Читать далее →