PHP подкаст #3

В предыдущем подкасте я много говорил что хорошо и что плохо. Будьте бдительны! Это всего лишь мнения и все определяется бесконечным количеством условий.

Статья недели

https://habrahabr.ru/post/309962/. Про ФП на PHP: функции высшего порядка, кастомные генераторы и как реализовать изящный JSON-парсер.

Конференция по Symfony в Барселоне

Ссылка на видео с конференции: https://www.youtube.com/playlist?list=PLQeCouGk8zAOdUpj_aKgxMUAacV2BD5Eq

Райан Вивер про современный стек JS-разработчика

Сейчас JS — это хипстерская штуковина и о ней говорят из каждого утюга. Проник на Симфони-конференцию доклад от Райана про JS. Но доклад не обычный: весь стек современной профессиональной разработки за 45 минут в умеренном темпе. Best tools на текущий день. Отличный доклад, который можно рекомендовать друзьям, если нужно быстро въехать в тему.

1. ES6 он же ECMAScript 2015.
2. npm.
3. babeljs.io для трансформации в ES5.
4. webpack для импорта файлов: можно разбивать JS по разным файлам и собирать это при помощи webpack’а, делая возможным import модулей.
5. webpack-dev-server для live realod’а.
6. ReactJS. Рекомендованный гайд https://facebook.github.io/react/docs/thinking-in-react.html.
7. JSX -> babel -> JS.
8. И еще горсть технических рецептов что делать с путями к изображениям, как обернуть css внутрь js’а и зачем это нужно. KNPUniversity, который развивает Райан, был им переписан на этом стеке за неделю.

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

Бенджамин Эберлей: Doctrine ORM + NoSQL

Доклад о том, как использовать преимущества неструктурированных данных (документов), используя при этом Doctrine ORM.

Предположим, что мы хотим описать сущность Product. В зависимости от категории, к которой относится продукт он может содержать разный набор аттрибутов. С ростом числа аттрибутов процесс гидрации сырых данных в объект будет занимать все больше времени. Какие решения?

1. EAV.
2. json_array (MySQL & PostgreSQL поддерживают JSON тип; PostgreSQL также поддерживает JSONB). Добавить свой тип данных и DQL-функцию в Doctrine. Хранить immutable value-объекты. Доктрина проверяет объекты по ссылке, а не по значению. Готовая реализация https://github.com/dunglas/doctrine-json-odm.
3. Параллельное существование объектов в реляционной БД и документной.
4. Поиск при помощи ElasticSearch.
5. https://github.com/doctrine/KeyValueStore.

Бернард Шуссек о форм-компоненте

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

• action генерировать в контроллере при вызове FormFactory.
• Глобальные переменные передавать в конструктор форм-билдера.
• Использовать {{ form(form) }} только для быстрого прототипирования.
• Передавать аттрибуты конкретной формы при вызове form_row в качестве второго аргумента.
• Не использовать темы в небольших проектах. рендерить руками.
• Сложную логику реализовать в twig сложно, поэтому переносить её в buildView/finishView. В зале мало разработчиков, кто когда-либо переопределял эти функции :).
• При валидации value-объекта не использовать Assert префикс в аннотациях.
• Использовать трансляционные ключи в addViolation-функции.
• Использовать GroupSequence в качестве значения validation_groups для последовательной валидации.
• Создавайте свои constraints. Можно расширить некий родительский констрейнт и переопределить дефолтные значения. Сомнительный профит.
• Переиспользовать валидаторы, когда создаешь свои кастомные валидаторы.
• Использовать property_path для разделения формы и модели.
• Если модель имеет некий конструктор, то передать значения из формы в него можно через empty_data в configureOptions. Для этого используем кложуру.
• Для работы с VO нужно использовать трансформеры.
• Использовать кастомный DataMapper (методы mapDataToForms, mapFormsToData) для того, чтобы избежать использования стандартный get/set-методов.
• Choices-тип в 3.0+ версии поменял местами ключи и значения. В качестве значений теперь может быть что угодно, например, объекты. А ключи — это текстовые данные, которые видит клиент.
• Для реализации зависимых друг от друга полей нужно использовать EventListener.
• DDD + CQRS: результат хендла формы — комманда.

Пабло Годель о деплое Symfony приложения

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

sudo rm -rf / var/log/*

Fabric, Capistrano, Deployer, Magallanes. Пабло рекомендует Ansible.

Доклад было проще оформить в виде поста с кусками исходников. Больше было похоже на готовый рецепт. Имхо смотреть не стоит. Читайте манулаы по ansible, ansible-galaxy и ansistrano.

Пабло упомянул инструмент для упаковки вашего проекта в deb/rpm/etc https://github.com/jordansissel/fpm.

Типичный деплой выглядит так: вы пушите в гит-репозиторий -> уведомление в Jenkins -> Тесты (QA team, etc, etc, etc…) -> уведомление в Ansible -> деплой -> уведомление на почту, в Slack, etc.

Альберт Кассадемонт о ReactPHP

Если вы еще PHP5, то установите opcache. А еще лучше мигрируйте на PHP7. Проблема только в том, что не все расширения обратно совместимы и до сих пор мейнтейнятся. Альберт показал скрины производительности их сервиса от New Relic. 40 мс и хотят еще быстрее. Посмотрели что выдает blackfire.io. Много съедает autoloading. Проблема в том, что происходит подключение одного и того же файла, который не меняется с течением времени. Т.е. каждый реквест происходит ненужная аллокация памяти под одни и те же ресурсы. Решение: ReactPHP + PPM (PHP process manager поверх ReactPHP). Внедрение этого хозяйства может повысить производительность на 30-40%.

Главный недостаток этого подхода — у вас на весь проект один процесс. Т.е. если PHP-FPM создает для каждого запроса отдельный процесс, то используя Реакт у нас на все один процесс и если он ложится, то ложится весь проект. Т.е. ломается что-то в одном action и мы получаем лежащий проект. Другой недостаток — утечки памяти.

Матиас Нобэк

Кто может быть ориентиром для программиста? “An astronaut’s guide to life on Earth”. Chris Hadfield. Дерево решений: каждое решение приближает или отдаляет от цели. Быть открытым к обратной связи. Спрашивать окружающих что они думают о тебе, чтобы найти недостатки. Избавляться от эго — оно мешает работать в команде, а команды побеждают. Быть подготовленным ко всему — правило астронавта. Невозможно вернуться на Землю за чем-то, что забыл :). Если вы приходите в новую команду, то нужно быть нейтральным ко всему. По аналогии новый астронавт на МКС не может знать всего того, к чему привыкли те астронавты, которые уже тут провели месяцы.

Михаэль Каллам

Доклад о PHP-FIG и о важности коллаборации между разными разработчиками разных экосистем. Composer создавался изначально для PhpBB! PSR = PHP Standards Recommendations. FIG в ноябре будет 7 лет. Неплохая смежная статья про то как закулисно развивается FIG: https://www.sitepoint.com/the-past-present-and-future-of-the-php-fig/.

Джереми Микола: 5 лет бета Doctrine ODM

История о том, что важно привлекать контрибьюторов.