Внимание! В подкасте ошибка: set_error_handler может хендлерить деление на ноль.

В этом подкасте о Slack и их приверженности PHP (+ миграция на Hack), что в себя вобрал PHP из других языков, Dropbox API, Yunpan и 36Тб бесплатного места, Throwable и его наследники, а также о 12-факторном приложении по версии Heroku.

Скачать mp3 (44Мб)

Примечательная статья от гиганта чат-месседжинга Slack об их отношении к PHP Автор говорит, что использовать PHP для стартапов сегодня — это лучший выбор. Автор отнес PHP к самоизобретенному термину MDPDL (Mixed-Paradigm Developer Productivity Language) языков. Очевидные преимущества, на которые обратил внимание автор:

• stateless и как следствие простота и высокая скорость создания продукта;
• concurrency, о которой не надо заботиться разработчику на PHP;
• programmer workflow намного быстрее по причине think -> edit -> roload the page цикла.

Из недостатков языка — может быть кто забыл — следующие:

• порой неожиданное приведение типов (например, 0123 != “0123abc”);
• примитивные типы передаются по значению как и в большинстве языков, а объекты по ссылке (Java-путь, а не, скажем, C++);
• обработка реквеста любой ценой, например, игнорируя ошибки вроде деления на 0 (в PHP7 деление на 0 выбрасывает Warning, который можно как-то хендлерить юзер-функцией set_error_handler);
• неоднородность в нейминге: C-стиль 6-буквенных функций (strlen, например), неймспейсы через “_” (json_decode), неймспейсы в Java-стиле.

В качестве гармоничного продолжения PHP в компании завершают миграцию на Hack. В четвертом подкасте мы обсуждали преимущества Hack. Если коротко, то это статическая типизация. К слову, Symfony дружит с Hacklang’ом (см. конфиг travis’а). Находил также статьи про то, что и Laravel заводят на HHVM, но как-то не бодро и в .travis.yml упоминаний hack’а нет.

Также замечательны комменты к статье. Ну и завершу этот обзор цитатой Бьерна Страуструпа: “Есть всего два вида языков: те, о которых все жалуются и те, которые никто не использует”.

Я  скорее апологет диверсификации знаний и расширения кругозора. Язык, как мне видится, здесь далеко не главное. Если вы понимаете суть дизайн паттернов и кейсы, когда их использовать вы будете изящно решать задачи на PHP и на Java, к примеру. Понимая десяток концепций ФП вы сможете его эффективно использовать и на PHP, но не будете сильно изнурены его использованием в Scala.

Замечательное улучшение в Symfony для простого перехода со страницы с исключением прямо на нужную строчку кода в любимой среде разработки (поддерживаются большинство популярных сред разработки)

Свежая статья об использовании Dropbox API. Ничего необычного. Пожалуй стоит сказать, что в бизнес-тарифах на дропбоксе можно коллаборироваться и работать группой надо документами и генерить по факту репорты. По прежнему компания выделяет 2Гб бесплатно на попробовать. К слову китайский Yunpan дает 36Тб! бесплатно. У китайцев свой взгляд на реальность :).

Небольшой ликбез по исключениям в PHP7+. Добавлен Throwable (нельзя напрямую расширять), который является родительским классом для всего, что можно catch. Также появился класс Error, у которого есть 4 главных наследника: ArithmeticError, TypeError, ParseError, AssertionError.

Поговорим о 12 факторах разработки SaaS. Если вы хотите снизить сложность деплоя, улучшить портируемость (в том числе на облачные платформы), уменьшить разбег между prod/dev окружениями, а также масштабироваться в рамках выбранного технологического стека, то эти факторы специально для вас! Эта методология появилась как естественный результат обширного опыта инженеров из Heroku.

Предварительно могу порекомендовать также отличное видео о приложении этих факторов в приложении на Spring Framework.

Фактор 1 / Одна кодовая база для одного приложения

Избегаем монолитов! Коротко можно резюмировать как один репозиторий = одно приложение. Если у вас несколько приложений используют одну кодовую базу, то её нужно вычленить в библиотеку и включать в код приложений через менеджер зависимостей. Если же у вас несколько кодовых баз в одном приложении, то имеет смысл задуматься об архитектуре микросервисов. При всем этом деплой не является отдельным приложением.

Фактор 2 / Dependencies

Главная интенция — сделать деплой идентичным/идемпотентным. Если вы используете composer, то уже следуете этому фактору. Декларация всех зависимостей. И изоляция зависимостей. Изоляция гарантирует отсутствие неявных зависимостей в вашем приложении (например, зависимость из глобального контектса). Ваше приложение использует curl? А есть ли явная декларация этого инструмента в каком-либо манифесте? Если вы используете Docker и пишете Dockerfile самостоятельно, то это шаг в правильном направлении.

Фактор 3 / Configs

Конфигурация через переменные окружения. Выводить все меняющиеся от рантайма к рантайму конфигурации в переменные окружения.

Фактор 4 / Backing services

Сервисы, от которых зависит ваше приложение — БД, очередь сообщений, key-value хранилище, Twitter, etc… — считаются частью системы и неотделимы от неё. Ваше 12-факторное приложение не должно различать локальные и сторонние ресурсы. К примеру вы используете Redis для кеша, но ничего не мешает вам прямо сейчас заменить локальный Redis на Amazon Elasticache. Вопрос лишь в смене URL эндпоинта в конфиге.

Фактор 5 / Design, build, release, run

Строго разделять стадии приложения на разработку, сборку (build), релиз (release = build + config для прода) и рантайм (run; непосредственно работа приложения). Фактор о том, чтобы сделать невозможными непосредственные правки в рантайме, а также. Деплой изменений должен проходить через некий однонаправленный workflow.

Фактор 6 / Stateless processes

В 12-факторном приложении процессы не должны разделять (share) ресурсы. Все разделяемые данные должны храниться сторонними сервисами (см. фактор 4). Если у вас есть данные которые хранятся на рантайме, то вам прийдется заниматься также роутингом при горизонтальном масштабировании.

Фактор 7 / Port binding

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

Фактор 8 / Concurrency

Процессы — first class citizen в 12-факторном приложении. Разные задачи выполняют разные процессы. Процессы не разделяют общих ресурсов. Это чрезвычайно способствует масштабированию. Избегать самостоятельно демонизации, но использовать средства ОС.

Фактор 9 / Disposability

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

Фактор 10 / dev/prod parity

Dev-среда должна быть максимально близка prod-среде. Стремиться к уменьшению разбега между dev & prod. Если говорить прямым текстом, то используйте Docker или Vagrant.

Traditional appTwelve-factor appTime between deploysWeeksHoursCode authors vs code deployersDifferent peopleSame peopleDev vs production environmentsDivergentAs similar as possible

Фактор 11 / Логи

Логи писать в STDOUT / STDERR. Само приложение не должно заниматься менеджментом логов. Для этого целесообразно использовать сторонние сервисы. По возможности избавляться о головной боли куда писать логи: в файлы ли, в БД или в облако.

Фактор 12 / Админские процессы

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