Стандартный PHP API для работы с HTTP запросами давно устарел. Программисты научились не использовать глобальные переменные, но стандартные суперглобалы как $_GET, $_SERVER все еще напоминают нам о далеком прошлом. Конечно фреймворки инкапсулируют эту информацию в свои Request\Response классы, но таких реализаций очень много и пока еще не было единственного стандарта. Стандарт PSR-7 от PHP-FIG как раз должен привести репрезентацию HTTP протокола к единственному знаменателю что позволит писать Middleware который будет работать сразу на многих фреймворках. Он пока еще не принят, но досрочное голосование показало практически единоголосную поддержку нового стандарта. PHPixie готовясь к релизу версии 3.0 уже приняла и имплементировала PSR-7, а также предоставляет обертки для упрощенной работы с интерфейсом. Если вы хотите создать свой микрофреймворк то взяв PHPixie HTTP за основу, сможете добиться результатов уже за один вечер.

Месяц назад на Sitepoint был опубликирован опрос популярности PHP фреймворков. За это время всего проголосовало 7800 людей, и вот его результаты:

На работе



В персональных проектах


Больше различной статистики на самом сайте

Из интересного еще замечу, что в России самым популярным остается Yii2, в Украине же победил PHPixie. Также PHPixie стал самым популярным фреймворком в возрастной групе до 18 лет.

Сегодня стала доступна еще одна библиотека от PHPixie, на этот раз это шаблонизатор. Как и в предыдущей версии как язык используется сам PHP, но теперь добавились новые возможности включая блочный подход к наследованию шаблонов. Об этом мы поговорим позже, а сейчас о самом вкусном: компиляции произвольных форматов. PHPixie Template позволяет использовать практически любой формат, достаточно лишь предоставить компилятор который транслирует его в PHP, а подгрузка файлов, их кэширование итд. будет сделано за вас. Также, это значит, что можно одновременно использовать несколько форматов в одном проекте.

Итак попробуем подружить Template с HAML. Для этого используем пакет mthaml/mthaml

Уже закончен долгообещанная третья версия PHPixie ORM компонента. Он теперь полностью независим от фреймворка и может спокойно использоваться сам по себе. В связи с этим, пока продолжается работа над другими компонентами и пишется документация, разработчики составили небольшой туториал для того чтобы можно было уже начать работу с ОРМ. Ниже я предоставлю его перевод и добавлю несколько вещей от себя, но сначала давайте посмотрим чем полезным порадует нас эта версия:

• Большинство ORM используют Model классы, которые используются как для выполнения запросов так и для репрезентации самых записей в базе данных. Например так делают Kohana и Laravel. PHPixie разделила модель на Repository, Entity и Query, каждая из которых имеет строго свое предназначение.
• Кроме SQL баз данных (SQLite, PostgreSQL, MySQL) полностью поддерживается также Mongo. Вы сможете связать отношениями модели с SQL баз данных с моделями хранящимися в коллекциях Mongo.
• Чтобы поддерживать связи между разными базами ( например между таблицами в разных базах в MySQL ) много ORM используют отдельные запросы вместо join-ов и субзапросов. PHPixie же использует субзапросы всегда где это возможно.
• Поддержка встроенных сущностей в Mongo
• На 97% покрыта юнит тестами ( планируется 100% до конца этой недели), и еще на 75% функционалными тестами.
• Эффективное использование Query позволяет уменьшить число запросов к базе. Например вам надо связать все топики автора с какими-то тегами. В большинстве ОРМ вам придется сначала найти топики, потом теги и тогда связать их ( 3 запроса к БД ). PHPixie позволяет сделать это за один запрос. Кстати пример этого есть в туториале снизу

Надеюсь я смог вас заинтересовать, теперь посмотрим на пример с ссылки вверху в переводе:

Вышел еще один полезный инструмент для тестирования, PHPixie Illusion.
Если ваше приложение зависит от внешних API то вы наверняка сталкивались с проблемой как представить их в своих тестах. Как раз эту проблему и решает Illusion. Она создает отдельный HTTP сервер на указанном порте и позволяет вам легко управлять его роутами и результатами включая HTTP заголовки.

Некоторое время назад был опубликован пост с подробным описанием уязвимости функционала «remember me» в фреймворке Laravel. Она позволяла имперсонировать любого пользователя путем создания поддельного кука логина. Разработчики тогда сказали что дыру закрыли. Но более подробный взгляд показывает что гидре отрубали лишь одну голову. Даже если вы не используете данный фреймворк вам все равно будет полезно узнать как не надо имплементировать такой функционал у себя на сайте.

Пока еще только ведутся работы над третьей версией фреймворка PHPixie, но уже можно точно сказать что он сильно изменится в лучшую (как по мне) сторону:

• Полный переход на стандарт PSR-2
• Поскольку фреймворк будет являть собой набор библиотек, то его компоненты можно будет использовать в любом проекте без самого PHPixie.
• 100% покрытия кода тестами. При чем в данном случае 100% не просто фигуральное слово а реально просчитанный «code coverage», то есть отношение строк которые вызываются при исполнении тестов ко всем строкам кода, кстати у Laravel это всего-лишь 53%.

Вчера стали доступны две библиотеки которые войдут в PHPixie 3, они полностью готовы и их уже можно использовать с любым проектом. Это сделано Подробнее об этом можно почитать в посте на сайте, а я здесь опишу то что мне больше всего в них нравится.

Сегодня я написал последний тест для версии 3.0 модуля доступа к БД для PHPixie. Когда я начал казалось что это займет всего несколько недель, но на самом деле все растянулось на где-то 2 месяца из-за огромного количества рефакторинга и переписывания сначала. Зато теперь мы имеем расширяемую библиотеку, которую можно использовать даже вне самого фреймворка (то есть если вас заставят писать на каком-то другом фреймворке или CMS вы сможете захватить свою любимую библиотеку с собой).

Я сделаю релиз после того как закончу модуль ORM и поправлю существующие модули для работы с новым API. Но если вам интересно вы можете заглянуть в ветку 3.0 на гитхабе (следует однако предупредить что документации там пока нет, она появится вместе с ORM). А теперь давайте посмотрим на новые возможности.

Для тех кто еще не знаком с тестами веб фреймворков которые регулярно проводит Techempower очень рекомендую сделать это сейчас заглянув по ссылке www.techempower.com/benchmarks

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

Но пока Techempower предоставила лишь некое preview результатов 7-го раунда, дабы дать разработчикам возможность внести последние изменения или исправить баги. Если вам тоже интересно как покажет себя ваш фреймворк в 7-м раунде вы можете ознакомится с последними результатами тут www.techempower.com/benchmarks/previews/round7

P.S. Практически все PHP фреймворки возвращают ошибки, что свидетельствует о проблеме с инсталляцией PHP или MySQL на сервере. Надеемся что ее исправлят.

Я уже много раз писал о фреймворке PHPixie и программировании на нем. В этот раз мы заглянем внутрь и посмотрим жизненный цикл приложения, к счастью простота и линейность кода позволяют сделать это с относительной легкостью.

Как и например Symfony, PHPixie состоит из двух частей: библиотеки компонентов и базового проекта, правда в случае PHPixie базовый проект более тонкий и состоит всего из нескольких файлов. Он здесь исполняет роль примера и поэтому изменение его под себя не только приветствуется но в некоторых случаях даже необходимо. Именно для этого важно понимать что и как происходит в системе. Используя свои несколько ограниченные умения в области рисования я подготовил диаграмму обработки запроса

Одной из самых нужных вещей при написании юнит тестов является создание mock-ов и stub-ов для объектов которые используются тестируемым классом. Здесь стоит упомянуть о важном отличии: если «mock» является исходным объектом в котором замены одна или несколько методов, то «stub» это некий фейк который полностью заменяет исходный объект. в зависимости от сценария иногда намного легче создать стаб чем сделать подходящий mock. В этой статья я покажу как эффективно и быстро создавать стабы используя небольшой класс Sylph от создателей фреймворка PHPixie.

В проекте который мы сейчас разрабатываем много работы с фотографиями, в результате чего скорость графической библиотеки является фактически главным фактором при оптимизации сайта. Не секрет что ImageMagick давно стал стандартом разработки на PHP, хотя уже некоторое время его оттуда сталкивает форк под названием GraphicsMagick. Мне стало интересно насколько сильно они отличаются и сколько форы могут дать старому доброму GD. К счастью как раз недавно вышел графический модуль для PHPixie который поддерживает все три библиотеки, что и позволило мне провести достаточно интересные тесты.

Вчера на своем блоге EllisLab объявил о поисках нового владельца для своего фреймворка CodeIgniter (ссылка). Решение было принято исходя из ограниченности ресурсов и желании сконцентрироватся на других продуктах компании. Ни для кого не секрет что CI довольно медленно шел в ногу со временем и для того чтобы снова сделать из него современный фреймворк его надо было бы полностью переписать, чего EllisLab делать не собирается.

После моего предыдущего поста о выборе легкого Фреймворка я погуглил и увидел что для некоторых из них нет ни одного русскоязычного туториала. Так вот я решил написать серию постов дабы заполнить эту нишу. Я думаю стоит начать с тех на которых я в конце остановился, а так как для Silex написано уже достаточно много то этот пост будет посвящен PHPixie.

Для тех кто не читал моего сравнения фреймворков, PHPixie — маленький и по моим меркам очень быстрый фреймворк с модульной структурой, хорошо реализованным DI, отсутствием статиков и простой архитектурой.

Для начала скажу что я очень большой любитель что-то попатчить и потвикать, даже если для этого нету особой необходимости. И вот недавно рассматривая статистику XCache на своем сервере я подумал что смог бы оптимизировать объем памяти который он тратит на опкеш (opcache) файлов различных фреймворков. Сделать это просто — переписать все используя только один, файлы которого были бы общими для всех сайтов, каких у меня порядка 20-ти, но в большинстве они довольно простенькие и особого труда их переписать мне бы не предоставило. И тут я начал поиск того самого фреймворка, который в идеале имел бы достаточно фич чтобы разработка была простой, и в тоже время был легким и быстрым. Вот те которые мне понравились и мои мысли о них.