Утро. 9:00. Москва. За окном пробка из сотен авто, томящихся в ожидании того, чтобы продвинуться на метр-другой вперед. Кто-то курит из окна, кто-то разглядывает соседние лица. Все готовятся к суете наступающего дня. По встречке пролетают скорые, отчаянно гремя сиренами, разгоняя водителям остатки сна. Я сижу за столом, смотрю в окно и вспоминаю выходные…

Как приятно вечером в пятницу стоять на вокзале. Забыть на некоторое время о работе и городской суете. Вокзал – это не только бомжи, алкашня, но ещё и путешествия! Погрузившись в поезд я поехал в Киев. Как и в прошлый раз Frameworks Day (который раньше был Zend Framework Day) проходит в Киеве. Вообще хорошо так ездить в выходные, первый день – конференция, а второй – отходняк от неё 🙂 Кстати, в этот раз место проведения конференции немного сместилось.

В прошлом году она была в отеле Казацкий. Из плюсов – прямо напротив выхода из метро “Майдан незалежности”. А вот ложкой дегтя были дурацкие колонны, которые изрядно портили вид. Но в этом году организаторы учли этот момент и конфа проходила в “Украинском доме”. Кстати не так далеко, буквально 10 минут по Хрещатику и вот он, виден издалека. Здание с “короной” на крыше. Отличный ориентир, надо сказать.

В здании проходила ещё одна конференция, что-то связанное с туризмом, а наша была этажом ниже. Очередь на регистрацию я увидел почти сразу, и немного погодя получил свой бейджик и отправился в зал. Зал большой, сцена хорошо просматривается. Я пришел почти к началу, так что сел где-то посередине. Конференция началась, как всегда, с вступительного слова и представления спонсоров. Кстати, в этом году партнером конференции был аж сам Microsoft, что сильно удивляет из-за OpenSource направленности конференции.

PHP, фреймворки, Yii2

Александр Макаров

Александр работает в компании Stay.com и является core-разработчиком фреймворка Yii. Александр попытался объяснить, какую нишу занимает Yii среди всех PHP фреймворков. Он считает (и в некоторых аспектах небезосновательно), что современные фреймворкм (Symfony2, Zend Framework2) слишком монструозны. Для каждой маленькой вещи приходится делать слишком много кода. Код такой гибкий, что его гибкость требует множество слоев абстракции и всё это приводит к overengeneering. Паттерны, паттерны, патерны, адаптеры, фабрики и всё прочее окружает тонюсенький слой бизнес-логики. В качестве примера он приводит Symfony 2. А Yii весь из себя такой легкий, быстрый и т.д. Что я хочу сказать. Да, Yii быстрее. Но он и жестче. Из коробки. Вот хоть убей, не могу понять такого подхода. Берем фреймворк из skeleton app, тестим на Hello World и опа – всё тормозит, куча лишнего и т.д. Нет это даже не синтетический тест, это называется поигрались 5 минут. Ведь для того же Symfony2 Hello World – это очень мало, чтобы разобратсья в теме.

Я, напримере, сделал так. Взял Symfony2 Skeleton из Std поставки, и выпилил оттуда все бандлы 🙂 Хм, как быстро теперь работает! Ой, погодите, не работает:-) Начинаем разбираться, что не работает, подключаем только то, что нужно(!). Например, не нужен мне Twig, зачем его подключать – нафиг его. Следующий. Вот так, точим напильником и получаем…. корпоративный фреймворк, но(!) на базе стандартного Symfony2 со всеми его плюшками в виде подключаемых за 5 минут бандлов, которые покрыват решение почти всех стандартных задач. В результате имеем то, что надо, и значительно увеличиваем скорость разрботки.

Нет, я видел эти красивые графики, где доля Yii растет, как на дрожжах. Я не хочу сказать, что он плох. Но, как верно заметил Александр, у него просто своя ниша. И в этом я согласен с ним на все 100%! Например, начинаем мы маленький проект, и знаем, что он так и будет маленький. Тогда зачем нам сдался этот “огромный” Symfony2? Не нужен, берем Yii или Sliex и да, жизнь будет проще. Но, если мы берем скажем Sliex и нам что-то не хватает, то мы добавляем один компонент, второй, третий и вуаля – у нас своя сборка Symfony. Вот так тихо и наземетно. И на самом деле это круто, это значит, что есть какая-то стандартизация. Не зря Fig (PHP Framework Interop Group) свою работу делают. Но, вот если бы мы сразу взяли Sf2 то в конце было бы легче.

Что же делать в начале разработки? А вот фиг 🙂 его знает. Мне кажется это чисто субъективное решение. Александр ещё сказал такую фразу: “Во-первых фреймворк должен нравится. Если вас от него тошнит, то не стоит работать с ним”. Так что да. Вы верно угадали, мне нравится Sf2. Не весь, и не везде, но больей частью всё же да. А с Yii я работал довольно давно, и сейчас я вижу, как он вырос. Разработчики стараются ради тебя, %username%, чтобы у тебя была свобода выбора… и это здорово!)

About PHP

Rasums Lerdorf
Слайды доклада: http://talks.php.net/show/fwd13/0

Как это модно говорить “главным спикером” конференции был Расмус Лердорф. Да, тот самый Расмус, разработчик нашего PHP. Своим докладом Расмус решил ответить на холиварные вопросы относительно PHP. Например, почему у php-функций разный порядок аргументов. Он у же говорил это на DevConf, а я уже писал об этом. Суть в том, что php – тонкая и быстрая обертка над C++ функциями, какой порядок аргументов там, такой и в PHP. Хотите универсальности – юзайте фреймворки. Ведь, например в Javascript есть Underscored и все этим обстоятельством очень довольны (смотрим на первое место в блоке “most dependended upon” на https://npmjs.org/). А, да , ещё PHP занимает 83% рынка веб-разработки, и в последнее время растёт!)

Расмус рассказал про PHP 5.4 и даже провел небольшой соц.опрос.
– Hey, who use php 5.3 now?
/* где-то четверть зала подняла руки */
– Oh, it’s really depressive. You shouldn’t sit here, you should stay home and upgrading your php 🙂
И по большому счёту он прав, просто обновив php можно получить значительное повышение производительности, трейты и прочие плюшки.

Ещё Расмус расскзал про php 5.5 и что делается сейчас там: password hashing API, обновления по curl и многое другое. Резюме доклада:
• Still running PHP < 5.3? Upgrade!
• Test your code on PHP 5.4 and upgrade soon
• Help us test PHP 5.5
• Contribute!

Микрофреймворк Silex. Берем в дорогу только необходимое

Владимир Дубина

В докладе Владимир пытался дать определение самому понятию фреймворка и провести границу между “библиотекой” и “фреймворком”. В своих умозаключениях он базировался на статьях Igor Wiedler. Кстати, у него есть довольно много инетресных презентаций: https://speakerdeck.com/igorw/silex-symfony-goes-micro
В одной из них написано в частности такое: Silex is not Symfony. Silex is user interface for Symfony. Так вот, что такое фреймворк.

Это:
– Соглашения: стандарты кодирования, структура директорий, комьюнити.
– Библиотеки: решенные стандартные задачи, повторное использование кода.
– Связаность компонентов: базовая конфигурация, связь между библиотеками, общий загрузчик.

А что такое микро-фреймворки. Dustin Whittle сказал по этому поводу:
Use Silex if you are comfortable with making all of your own architecture decisions and full stack Symfony2 if not.
Иными словами, если вы хотите делать свою архитектуру, чувствуете в себе силы – то берите Sliex – и стройте её. Если нет, то вам подойдёт Symfony2 с его готовыми архитектурными решениями. Тут добавлю, что есть и третий вариант, который я озвучил выше. Берем скелет Symfony2 – и под нож его. Строим то, что нам нужно на базе Sf2. Естесственно, Sliex даёт большую свободу, большую гибкость и меньший overhead, чем Symfony, ведь французы тоже не дураки, и не зря его написали.

Например, если у вас SOA архитектура или надо забацать интеграцию с мобильным приложением по REST, то Sliex – то, что доктор прописал. Sliex ведь тоже Фабьен делает. Мне понравилось, как Владимир сказал про Фабьена, что он удивляется, как тот успевате коммитить с такой бешеной скоростью. Как будто у него в подвале сидять 10 программистов и коммитят за него 😉 Вот кстати, ссылка на его профиль в Github: https://github.com/fabpot

TulaCo PHP Framework или построение корпоративного фреймворка на базе ZF2

Даниил Кожемяко

Даниил в докладе поднял очень интересную тему – корпоративные фреймворки. Что такое фреймворки мы уже знаем, а что же такое корпоративные фреймворки. По сути это срез во времени фреймворка общего назначения со всем добавленными в него библиотеками, расширениями и возможно модификациями (если мы форкнули фреймворк) для достижения целей и решения задач внутри компании. Блин, прям для вики определение получилось. Очень часто получается так, что заказчик хочет всего и прямо сейчас. Поэтому нет времени решать по 100 раз типичные задачи, например пагинатора, поэтому очень важно выбрать правильный фреймворк, чтобы избежать проблем будущем.

Итак фреймворк должен быть: хороший :-), удобный, мощный, быстрый, покрытый тестами, легко расширяемый, хорошо документируемый. Как пошутил мой друг – выберите любые два 🙂 В докладе рассматривалась задача, которая очень близка мне. Допустим, у нас есть артист, и у этого атиста есть разные аккаунты в социальных сетях типа Facebook, Twitter, Intagram, LinkedIn и др. Наша задача связать эти аккаунты. Даниил рассказывал, как это сделать Про отношения один-ко-многим и так понятно, а вот про новые компоненты Doctrine\Form которые позволяют сделать выпадабщий список связанных объектов я не знал. Мы это делали вручную. Посмотрев исходники (https://github.com/doctrine/DoctrineModule/blob/master/docs/form-element.md) понял почему. Это ж модуль для Zf2, а у нас… своя коляска)

В общем отличный практический доклад, с удовольствием узнал, что мы делали примерно так же, как и авторы этого модуля. Вообще корпоративные фреймворки и особенности допиливания кода до состояния “как надо” – всегда интересно, потому как реальные задачи и реальные решения.

Йоптыть, а как же мы будем это тестировать? Обзор фреймворков и библиотек для тестирования в PHP.

Михаил Боднарчук

Тестирование. Ых. Больная тема. Да, тестировать надо, да, надо содержать актуальные тесте. Как бы мне всего этого хотелось. Но в реальной жизни всё так быстро меняется, бизнес-логика такая нелогичная, что многие тесты идут прахом. “Всё тлен” – как любит говорить мой друг. Итак когда не надо тестировать:

• Проект меняется редко
• Проект сдан и всё
• Разработчиков мало, то есть я один
• Нам мало платят
• Менеджмент хочет побыстрее и некачественно.

Последний пункт вообще грусть-печаль, но это чугунная задница реальности.
В докладе обозревались следующие фреймворки для тестирования: PHPUnit, atoum, PhpScpec, SPecify, Mockey, AspectMock, Codeception.

    
Собственно Codeception – это и есть разработка Михаила. Подробности можно посмотреть вот тут: http://codeception.com/
Основные возможности:

• Selenium WebDriver integration
• Elements matched by name, CSS, XPath
• Symfony2, Laravel4, Yii, Zend Framework integration
• PageObjects and StepObjects included
• BDD-style readable tests
• Powered by PHPUnit
• API testing: REST,SOAP,XML-RPC
• Facebook API testing
• Data Cleanup after each run
• HTML, XML, TAP, JSON reports
• CodeCoverage and Remote CodeCoverage

После доклада дал себе слово обязательно поиграться с этой библиотечкой. Вообще Михаил (привет!) очень понравился, после конфреренции посидели с ним в баре, поболтали за жизнь и кодинг)

PHP in Windows Azure Cloud – hosting scalable and reliable solutions

Виктор Цикунов, Microsoft

В презентации расказывалось об основных возможностях Windows Azure, как облачной платформы и демонстрировался запуск PHP приложения на ней по разным сценариям.

• Что такое Windows Azure: Web сайты, Виртуальные машины, Хранилища и облачные сервисы
• PHP веб-сайты (демонастрация)
• Готовые образы виртуальных машин
• Что такое Cloud Service?
• Развертывание простого PHP приложения в облаке Azure

Как превратить проект на symfony в боль. Набор практических советов на основе реальных проектов

Роман Лапин, Evercode Lab

Один из тех докладов, которого больше всего ждал, т.к. на Symfony2 сижу уже больше полугода, и с “болью” знаком не понаслышке. Роман – основатель своего стартапа-студии Evercode. Зачем мы используем фреймворки? – спрашивает Роман. Во-первых для лучшей организации кода, во вторых для использования уже существующего кода и более быстрой разработки. Мы можем использовать коммьюнити. Ксати именно поэтому такой параметр как размер и активность коммьюнити так важен при выборе подходящего фреймворка. Ну и наконец, используя фреймворк мы можем сосредоточиться на бизнес-логике, на том, на чем реально стоит сосредоточится.

Почему же Symfony2? В книге по Sf2 и в онлайн документации есть замечательный раздел: Symfony2 versus Flat PHP (http://symfony.com/doc/current/book/from_flat_php_to_symfony2.html). На самом деле он относится не только к Sf, но и к Zend Framework2, да и вообще к любому фреймворку. Итак про боль.

Структура проекта. О да, этот аспект может причинять боль. Самое жесткое конечно, это когда изменяют куски фреймворка. И вроде бы у тебя Zf, а по факту приходится проходить diff-ом по всему коду и выяснять изменения, их причины, устранять их и стабилизировать вызывающий их код. Реально, испытал на себе эту боль. Вот руки бы оторвать).

Окружения. Приложение не должно внутри себя проверять в каком оно окружении и что-то делать в зависимости от этого. Приложение должно конфигурироваться в зависисмости от окружения, настраиваться соответствующим образом. Правда!) Желательно выносить в сооответствующую секцию parametrs.ini то, что зависит от окружения. Не всегда получается следовать этому правилу, но мы стараемся. Коротко этот пункт можно озвучить как: “The application should not be aware of what environment it is running under, it should just be configured a particular way based on its configuration files”

Кэширование и логгирование. Роман привёл интересный кусок кода, функии getCacheDir() в которой был вызов sys_get_temp_dir() и соответственно если у нас на сервере два проекта на Sf2, то получается что кэш у них будет общий, а это неправильно. Ещё проблемы могут быть с неправильными правами на папки с логами и кэшем. Ведь туда иногда писать надо) Смотрим сюда (http://symfony.com/doc/current/book/installation.html#configuration-and-setup) и проникаемся.

Composer. Он существенно облегчает жизнь разработчика, но как я люблю говорить “изговнякать можно всё”. Например написать вот так:
{“scripts”: {“post-install-cmd”: “rm -rf/”}}
Конечно, это утрировано, но теоретически там может быть всё, что угодно. Ещё разгоралось множество споров по поводу добавления composer.lock в git, изменения vendors.

Git. Тут Роман осветил часть ошибок, связанных с использованием этой системы контроля версий. Например, в одном из его проектов, после чекаута в директории образовывались файлы от Acme/DemoBundle из скелетона Sf2-приложения. И да, их поместили в gitignore, Чтобы не мешались 🙂

DI. В качестве примера Роман показал, как в сервис через параметры конструктора пробрасывается сам DI-контейнер, а внутри сервиса дергается DIC, его сервисы и т.д. Как потом такой компонент тестировать – непонятно, ведь на лицо глобальная зависимость. Надо пробрасывать только то, что конкретно нужно. Вообще для опыта полезно просмотривать реализацию самих Sf2-компонентов в этом разрезе.

ACL.
Скажу честно, мне самому как-то не очень нравится этот компонент Symfony2. Имхо, он сильно перегружен. А тут оказалось, что в фреймворке есть модуль Voters, который решает эту задачу гораздо проще и элегантнее. см. http://kriswallsmith.net/post/15994931191/symfony2-security-voters Прям надо почитать.

Кроме всего прочего и всяких общих советов оказалось, что Роман так же, как и я приверженец идеологии тонкий контроллер-тонкая модель-толстый сервис. Кстати? в Doctrine2 этой цели прекрасно служат репозитарии моделей. У нас, например, очень много бизнес-логики живет там.

Phalcon – cамый быстрый PHP Framework. Разработка highload проекта

Александр Торош

Все основные способы ускорения PHP-приложений уже изучены вдоль и поперек: сборка всех файлов фреймворка в один файл, опкод-кэшер, использование Varnish, тюнинг некоторых ресурсоемких частей фреймворка (например роутинг или mvc), кэширование. Но есть и радикальный подход – использовать pecl-фреймворк. Pnalcon – это pecl mvc-фреймворк. Он написан на C и он очень быстрый.

Особенности Phalcon:

• написан на C
• работает как extension для php
• уже скомпилирован и не требует интерпретации
• находится в оперативной памяти
• требует минимум файловых операций
• потребляет очень мало ресурсов
• не требует от разработчика знания Си

А ещё в Phalcon встроен шаблонизатор Volt, синтаксис которого очень похож на Twig, но опять же из-за Сищного происхождения шаблонизатора работает он ну очень быстро, а также хорошо интегрирован с самим Phalcon. А ещё в фалконе есть сишные ORM для MySQL и ODM для MongoDB. Блин, вот и рецепт самого быстрого веб-приложения: Phalcon + MongoDB + шаблоны на Volt. Крутатошка!) Может когда-нибудь поверчу это дело. Но, и это ещё не всё (как любят говорить в телемагазинах). Самой шокирующей новостью для меня было то, что авторы Phalcon взялись разрабатывать (и разрботали уже бета-версию) своего типизированного компилируемого языка веб-разработки Zephyr (http://zephir-lang.com/). На нем можно писать свои расширения для php. Вообще крутатошка. Хочешь свой DI – пиши на Zephyr и он будет супер быстрый. Стольк возможностей для реализации своей фантазии. Прям очень круто. Мне кажется, что так можно не только для Фалкона расширения писать, но и для Symfony2 написать например бандл и скомпилить его потом.

Что касается реализации, то Саша приводил пример сайт gazeta.ua который они переделывают на Phalcon. Ускорение конечно впечатляющее.

Кстати, новая версия Phalcon 2.0 будет написана на том самам Zephyr. Вообще Phalcon имеет очень большие перспективы развития.

Bluz – наш код как музыка

Антон Шевчук
В качестве эпиграфа к выступлению Антона можно привести такую фразу: “Почему стоит изобретать велосипед и чего оно стоит?”.

Антон очень грамотно построил доклад, он предугадал все вопросы типа “А зачем???” и на первый слайд вынес такие вопросы:

• Почему не “as is”?
• Почему не ZF2/Sf2?
• Почему не Yii?
• Почему не Kohana/COdeIgniter?
• Почему не Silex/Slim/etc?
• Почему не Phalcon?

И, надо отдать ему должное, весьма грамотно ответил на все эти вопросы. В общем всё сводилась к той самой идее “корпоративного фреймворка”. Антон довольно доходчиво показал структуру своего фреймворка, разложив по полочкам M, V и C-уровни.

Понравилось то, что у фреймворка минимум зависимостей, только PHPMailer и Gettext, а это значит, что почти весь код – свой. Это и хорошо и плохо. Хорошо то, что не будет проблем с интеграцией внутри фреймворка, а плохо – что возможно проблемы с нешней интеграцией. Ну в любом случае, раз фреймворк юзается и развивается, значит он успешно решает свои задачи.

Закрытие конференции

В этот раз закрытие конференции отмечали в баре Бочка, что на Хрещатике! Было высело и угарно! Очень приятно обсудить все насущные вопросы с коллегами за чашечкой пива.

Было очень круто, и я ни разу не жалею о том, что сорвался и поехал. Ребята молодцы, что вытянули Расмуса!) Даешь Фабьена на следующей конфе!!!))

 Ссылки

Сайт конференции

Фотоальбом конференции в Facebook

Отчёт Саши Макарова