Выпуск №9 — Александр Макаров (core Yii)

Это специальный выпуск — интервью с Александром Макаровым (@sam_dark) — одним из ведущих разработчиков PHP фреймворка Yii.

Поговорили про PHP-FIG и PSR стандарты, текущие и будущие.

Про планы на Yii 2.1: лучшая поддержка PHP 7, трейты вместо бихевейров, изменения на клиент-сайде.

Про проект, над которым Александр работает сейчас: stay.com — сайт для путешественников.

Про язык Go, микросервисы и сервер очередей в одной из будущих версий Yii.

Немного юмора в конце подкаста: «Шокирующее интервью с разработчиком сайтов».

Дорогие слушатели, если у вас есть пожелания, кого бы вы хотели услышать в гостях подкаста или конкретные вопросы к обсуждению, пишите в комментариях к этому выпуску!

Под катом читайте полную текстовую расшифровку.

Сегодня у нас необычный выпуск. Сегодня в гостях у подкаста Александр Макаров (@sam_dark) – один из ведущих разработчиков Yii и мы обсудим разные темы, связанные с Yii и не только. Саша, привет!

Привет!

Для начала давай расскажем, как появилась идея записать такой совместный подкаст. Вот я, например, недавно был на конференции DevConf и там ко мне подошел чувак, Андрей, и говорит: «Это ты записываешь Пятиминутку PHP?». А я был в футболке с логотипом подкаста. Я говорю да, слушайте, подписывайтесь… И он мне рассказал историю, что пытался с ребятами уже несколько раз что-то начать, но никак не могли выбрать темы, о чём говорить. В итоге Андрей собрал несколько человек в скайпе и мы договорились с Сашей о сегодняшней записи. А как у тебя это было?

Я, к сожалению, на DevConf в этом году не попал. Мне в скайп постучал Андрей и сказал, что есть такой замечательный подкаст «Пятиминутка PHP» и что собираются записать выпуски с гостями, предложил мне записаться.

Отлично! А ты раньше уже пробовал подкасты записывать?

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

В нашем подкасте есть текстовая транскрипция! Так что как раз для тебя и для тех, у кого нет в городе метро.

Начнём с первой темы, а первая тема у нас: php-fig – Framework Interop Group. Я знаю, что ты участник этой группы, расскажи, как она образовалась, какие цели заявлены?

Группа образовалась в 2009 году. Кто были первые проекты я уже не помню, но сейчас там участвует 40 проектов. Все проекты – это довольные крупные фреймворки и CMS, такие как Yii, Laravel, Symfony, в общем, там представлены практически все фреймворки, которые вы можете перечислить. Как следует из названия, группа пытается сфокусироваться на том, что пытается принять стандарты.

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

Да, это классная идея. Когда я впервые прочитал про PHP-FIG в далеких годах, подумал, конечно, идея правильная, но кто этим будет пользоваться, ведь так трудно всем договориться. Но как показала история, действительно, многие стандарты выстрелили и сейчас их практически все используют. Какие самые успешные, на твой взгляд?

На мой взгляд, самые успешные стандарты – это практически все, которые приняты на данный момент.

PSR-0 и PSR-4, то есть автозагрузка, которая дала огромный толчок инфраструктуре PHP и вылилась в создание composer.

PSR-1 и PSR-2, которые наконец-то закончили холивары на тему, что использовать табы или пробелы.

PSR-7 тоже очень неплох.

Я слышал такое мнение, что PSR-0 сам по себе не был бы так популярен, если бы не выстрелил composer, который именно его утилизировал. Что ты думаешь по этому поводу?

Я думаю, что это примерно так и есть, но стоит все-таки помнить, что PSR-0 был сделан до того, как был сделан composer и composer без PSR-0 скорей всего не выстрелил бы. Например, у такого фреймворка, как Fuel, который является форком CodeIgniter был свой менеджер пакетов. У каких-то других фреймворков были свои менеджеры пакетов и, соответственно, не очень правдоподобным звучала такая мысль, что все фреймворки со своих пакетов перейдут на какой-то другой стандарт. Особенно учитывая то, что этот стандарт нигде не описан.

Интересно, я вот не знал про менеджеры пакетов в Fuel. А какой самый провальный из принятых стандартов, на твой взгляд?

Из уже принятых, я думаю, что самый провальный это PSR-3 по сравнению с остальными стандартами. Плюс из того, что сейчас в обсуждении, несколько стандартов довольно спорные. Например, кэширование — он очень сложный. Там решается очень много таких интересных проблем, но эти проблемы не возникают в 99% случаев работы с кэшем. Его стоит почитать, его стоит изучить, потому что стоит знать, чего ждать от кэша и как работают всякие разные кэш бэкенды. Но группа понимает, что этот стандарт достаточно сложный, поэтому будет выпущен не только этот стандарт, но и стандарт попроще, который поддерживает только key и value.

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

Чаще всего нет, то есть бывает, что действительно, кто-то один пишет, бывает, что пишут группами. Вообще, работа происходит очень четким заданным циклом. Сначала работа идет как бы в тени, либо это обсуждается в группе, либо где-то еще. Люди работают над метадокументом и основным текстом стандарта, и дальше выставляют саму идею или черновик стандарта на входное голосование. И все эти 40 проектов, которые там есть, начинают голосовать: нравится / не нравится, сделает оно что-то хорошее для PHP, в целом и для фреймворков, в целом, или нет. Если этот черновик прошел, то начинаются интерактивные обсуждения и процесс улучшения этого документа. И когда эта дискуссия более-менее утихает, и улучшений уже не видно, этот черновик или более-менее чистовая версия выставляется на еще одно голосование, чтобы принять или не принять его как стандарт. Если он принят, соответственно, его публикуют на сайте, ему присваивают какой-то номер. Если его не публикуют, возможно, его забросят совсем, либо его отправят в полную переработку, то есть переработают все концепты и опять выставят на входное голосование.

А где происходит это общение? Может ли человек со стороны почитать или даже написать в группу?

Да, конечно. Если зайти на сайт PHP-FIG (http://www.php-fig.org), то там есть ссылочка на группу Google, он же mailing list. Общение все публичное, читать может кто угодно и писать может тоже, кто угодно. Единственное, что дает членство в этой группе, это возможность голосовать. Остальное все, что происходит, может делать любой человек.

Расскажи, какие стандарты сейчас реально используются в фреймворке Yii? Планируете ли вы поддержку следующих, которые уже выпущены или планируются к выпуску?

У нас широко используется автозагрузчик, то есть PSR-4. Раньше использовался PSR-0, но мы с него, естественно, перешли на PSR-4, потому что он полностью совместим и более современный. Мы используем PSR-1 и частично PSR-2, то есть у нас весь ход хорошо форматирован. Там есть небольшие отличия от PSR-2, но незначительные. PSR-3 – не планируется, потому что наш интерфейс для логирования проще и понятней, по крайней мере, мы так думаем, как команда Yii.

PSR-7 — очень интересная штука. Возможно, мы его введем в версии 2.1 или позже, но он ломает обратную совместимость, поэтому в версии 2.0 его точно не будет.

А тот самый черновик кэширования key-value, как ты думаешь, войдет когда-нибудь?

Кэширование в сложном виде, которое не key-value, скорей всего не войдет. Оно слишком сложное и то, что есть уже в Yii, дает больше возможности и проще. А key-value вариант, скорей всего – да. Там поправить, максимум, нужно будет одно или два имени метода.

Отлично, практически все стандарты в Yii, кроме самых стрёмных. А есть ли у тебя идея или мнение, в какую сторону следует развивать экосистему PHP? Какие стандарты нам нужны в будущем?

Нам очень нужен стандарт на PHPDoc, потому что сейчас многие IDE работают с PHPDoc по-разному. Тот же PhpStorm допускает любое написание PHPDoc, а, например, NetBeans может работать только с устаревшей схемой, то есть порядок типов и самих имен переменных, он разный, текущий и тот, который поддерживается в NetBeans – это все очень сильно портит. Сейчас в разработке есть еще один PSR по PHPDoc. Я очень надеюсь, что его примут как можно скорее. Кстати, все могут туда комментировать (по PHPDoc), это очень просто, потому что мы все его используем и у каждого может быть свое мнение по этому поводу.

Плюс еще один стандарт — это стандарт информирования об уязвимости, то есть security. Тоже очень важная штука, потому что замечательно, просто замечательно было бы иметь, какую-нибудь утилиту, которая говорит нам, что «вот ваш код имеет уязвимость и сделайте, пожалуйста, composer update, чтобы вытянуть новую версию, которая ее зафиксила». На самом деле Fabien из команды Symfony сделал некую подобную штуковину, но она пока еще не стандартизирована, поэтому у нее не так много провайдеров данных.

Это интересная идея. А для конечного разработчика, это как-то пригодится или это именно для разработчиков фреймворков?

PHPDoc для конечного разработчика, естественно, пригодится. А вот security репорты для конечного разработчика, ему, конечно, все равно, каким способом фреймворки представляют эту информацию, каким способом эта утилита сообщает ему, что нужно обновиться. То есть это для разработчиков фреймворков очень нужная штука.

А в этом году уже что-то на подходе есть? Что в ближайшем мы можем увидеть из стандартов?

На подходе PHPDoc. Я очень надеюсь, что его в этом году дожмут и доделают. Security уже, в общем-то, в нормальном состоянии, то есть уже выбран протокол, уже написан метадокумент и часть документа стандарта. Я думаю, что его тоже вполне могут дожать. Кэш под вопросом, то есть там очень сложная штука, а за key-value как-то пока никто пока не принимался.

Он должен быть очень простой, но, соответственно, так как все, кто занимается кешем, занимается этой сложной штукой, пока не ожидается, что его примут прямо сейчас. С ним все не очень понятно.

А ты сам сейчас принимаешь активное участие в доработке какого-то из стандартов? Например, в PHPDoc контрибьютишь?

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

А в связи с этим, хватает ли у тебя времени на разработку фреймворка Yii? Как там, вообще, идет процесс?

Сейчас процесс несколько замедлился, но, в принципе, идет нормальными, замечательными темпами. Основную версию 2.0 мы уже выпустили. До замечательного, стабильного состояния мы уже ее довели, то есть мы уже правим баги, которые касаются каких-то совершенно краевых ситуаций, совершенно безбашенных. Улучшаем наши инструменты, то есть генераторы кода, дебагеры и т.д. Сам фреймворк хорош и стабилен. Документация тоже практически вся написана. Не покрыт JavaScript и, наверное, все. Но у нас на данный момент не очень все хорошо с сайтом проекта, то есть он не в полной мере отражает то, что есть на github. Например, на сайте нет переводов документации по Yii 2.0, хотя на русский документация переведена практически полностью. Времени у меня лично, нормально, то есть кое как позаниматься багами, принять pull request’ов хватает.

Может тогда расскажешь нашим слушателям, как помочь проекту? Где-то послать pull request на сайт или с переводом документации?

Сайт пока не публичен, то есть я даже не знаю, будем ли мы, в принципе, открывать код сайта. Он в приватном репозитории в разработке. А сам фреймворк, конечно, можно помочь с переводом документации на русский. Например, не переведен пока еще раздел по ActiveRecord, что странно. Это как бы одна из основных вещей. Мы всегда ждем pull request’ов на тему фиксов, багов. Лучший pull request – это тест, который фейлится. Это самая лучшая форма pull request’а, но если pull request прилетает с отличным описанием, мы тоже говорим огромное «спасибо», потому что это супер, супер экономит нам время!

Вопрос на миллион долларов. Yii 2.1 – когда ждать? Что нового?

Когда ждать, пока не очень понятно, потому что мы сейчас все сфокусированы на полировании 2.0 и на инфраструктуре, то есть на том, чтобы поднять новый сайт с переводами, с новыми комментами и более сфокусированы на версии 2.0.

Планы по 2.1 уже есть. Они очень интересные: это выделение большего количества интерфейсов, несколько более строгая типизация.

Возможно, мы будем использовать такую вещь, как super closure, чтобы позволить сериализацию замыканий. С ней бывают сейчас некоторые проблемы в версии 2.0.

Возможно, выкинем бихеверы, но это еще не факт, и будем использовать вместо них трейты.

Возможно, немного изменим систему объектов, попробуем сделать так, чтобы работать с Yii можно было очень легко начать без шаблона приложения. Сейчас это можно, но там есть некоторые особенности.

На тему клиент-сайда, скорей всего избавимся от composer плагина, потому что он делает нам некоторые такие проблемы. И, возможно, либо немного поубавим количество клиент-сайда которым Yii пытается разобраться, либо, соответственно, добавим в требования, использование какого-нибудь менеджера пакетов вроде bower, то есть, чтобы все это дело вытягивалось привычным для клиент-сайда способом, а не нашими какими-то своими изобретениями. Даже если они неплохо работают, как это происходит сейчас.

Есть еще некоторые планы по мелким изменениям в моделях по переупорядочению некоторых классов. Есть план, чтобы все это дело работало с PHP 7. Оно и так на самом деле работает, но у нас есть несколько мест, которые, когда выйдет PHP 7.1, он начнет ругаться, то есть вещи, которые внезапно стали depricated, хотя ничего не предвещало беды.

Возможно, мы еще добавим поддержку конфигурирования наших приложений при помощи такой стандартной вещи, как .ENV или забирания переменных из окружения.

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

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

Это не будет так, как было с Yii 2.0, то есть между 1.1 и 2.0 прошло просто дикое количество времени. Это было исключительно потому, что мы взяли и переписали практически все с нуля. В случае с 2.1, естественно, за основу будет взят 2.0 и большинство API, большинство идей, большинство всего, что там есть, оно останется неизменным.

Отлично. Тогда пожелаем им продуктивной работы. Будем ждать.

Спасибо.

Расскажи немного о своем текущем проекте. Чем ты сейчас занимаешься? Что нового узнал, открыл для себя недавно, например?

Ок. Текущий проект… У меня много текущих проектов. Есть проекты личные, вроде блога RMCreative или проект gostash (уже закрыт), который я сейчас помогаю его автору его запустить, поддерживаю. Это что-то типа Twitter, но для кода с соревновательным элементом.

И есть, соответственно, основной проект, который я делаю за деньги на коммерческой основе. Это stay.com — проект для путешественников. Он дает возможность собрать, когда едешь в какой-нибудь европейский или другой большой город, чаще всего это столица, собрать из предложенных гидов, из предложенных мест, которые там есть, самые классные в городе, набрать себе их в свой личный гид. Слить приложение для телефона. Нажать кнопку «заофланить» и это всё! Соответственно, когда мы приезжаем в этот самый город, мы отключаем wi-fi, отключаем сотовые данные, всякие 3G, 4G. У нас ничто не работает с сотовыми сетями, ничто не кушает наш любимый трафик, ничто не кушает наши любимые деньги. При этом у нас есть полная оффлайновая карта города. Мы всегда знаем, где наш отель, где мы остановились. Мы знаем, куда нам идти. Вся эта карта замечательно работает. Мы всегда знаем, где мы находимся, сколько у нас займет переход туда, переход туда, никогда не потеряемся.

Слушай, это супер актуально, просто супер!

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

А по технологиям, с которыми я там познакомился… Сам проект, он написан, ядро и API, они на PHP, на Yii версии 1.1. Обновляться мы пока не можем, потому что разработка идет слишком быстро и у нас просто не хватает на это времени, то есть мы держимся на последней версии Yii. Соответственно, на API оно используется приложениями на Android и iOS. Оба эти приложения совершенно нативны, потому что вот эта карта, все эти векторные данные, нам их нужно рендрить в оффлайн режиме и, соответственно, никакое приложение типа PhoneGap нам не подходит. И сам рендринг карт в векторном режиме, он довольно таки нагруженная штука, поэтому нам нужен нативный код. Я провел полтора года, работая кроме вэба еще и над Android приложением.

И у нас есть сервер, который создает картинку, он написан на Go production! На прошлой неделе я занимался небольшими правками по этому делу и хорошо вник в Go, наконец.

И как тебе Go, в двух словах?

Go – очень интересная штука. Go – я бы даже сказал, замечательная штука, но он очень глубокий, то есть чтобы понять его основы, сделать это очень просто. Для этого нужно прочесть пару тройку страниц мануала и, если мы знаем, что либо, о каком либо языке программирования, то все эти основные концепты — они всем знакомы. Они отлично работают. Они просто работают и все. Там немного отличается синтаксис, но это не беда. Но если мы начнем копать дальше, то там неисчислимое количество возможностей, неисчислимое количество официальных и замечательно работающих пакетов, отличный компилятор, отличные тулы.

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

Go – штука классная. В нем есть замечательные возможности, типа делать возврат в нескольких значениях сразу. Та же обработка ошибок, например, как делается обычно? Обычно в Java или в С++ всё кидается в исключения и мы должны делать try/catch. В PHP возвращается одно значение и нам нужно потом его проверять, а результат получать потом какой-нибудь другой функцией. В Go возвращается несколько значений и это обязательно. Когда мы вызываем функцию, мы должны присвоить ее, то, что оно выдаст, сразу двум переменным. И, одна из этих переменных, чаще всего — это ошибка. То есть Go с одной стороны дает нам возможность не делать этих бесконечных try/catch, try/catch, как в Java, а с другой стороны, он как бы заставляет нас нормально обрабатывать ошибки, что очень и очень хорошо.

Да, я тоже Go чуть-чуть трогал и это спорный момент. Некоторые говорят наоборот: «Как же мы без Exceptions будем все время в if/else проверять эту переменную с ошибкой?»

На самом деле try/catch, try/catch не лучше, чем if/else, if/else — это просто другая запись. Ошибки так и так нужно проверять.

Что правда, то правда. К теме веб разработки. Например, фреймворк Yii достаточно популярен и наворочен для того, чтобы быстро запустить крутое веб приложение или вебсайт. Есть ли что-то похожее на Go или может ли на нем такое появиться?

На нем, в принципе, может такое появиться, но на сколько я знаю, такого сейчас нет и, в принципе, на нем писать сложнее. Он больше требует, больше требует думать. Что еще? Сам факт того, что его нужно компилировать для production и компилировать, соответственно, локально, чтобы его запустить. Как в PHP подправить и посмотреть, получилось или нет за 2 секунды, не получится, то есть это что-то средние между PHP, где мы просто замечательно подправили, посмотрели, работает, протестили в production, вообще, супер. Или на staging сервер, потом протестили еще раз и в production. Это быстро, это классно и сильно экономит время. Это прекрасно.

В Go – это что-то среднее между супер быстрым и Java, где мы запустили компилятор и пошли, и попили кружку кофе. Собственно на логотипе Java изображена кружка кофе, которая обозначает, что извините, подождите 5 минут, пока я компилируюсь. Go — это что-то среднее. Компилится он реактивно, по крайней мере, на маленьких проектах, но это нужно делать и это отвлекает.

Да, это интересное наблюдение. Есть такая предыстория, что разработчики Go якобы задумали его, когда устали ждать, когда у них соберется очередной С++ проект.

На самом деле, да. Он собирается очень, очень быстро, то есть на Go, практически, нет зависимости, что компилится, компилится в один бинарник. Бинарник достаточно жирный, то есть в пару мегабайт он будет даже, если программка очень простенькая, но все это работает. Компилятор быстренький. Ошибки выдает быстро. В принципе, это будет гораздо быстрее, чем та же компиляция на Сях или компиляция Java. И работает все это дело очень шустро, то есть скорость обработки данных, процессинга изображений или подсчитывания статистики будут очень впечатляющие, если это сделать на Go.

То есть, ты рекомендуешь микросервисы? Микросервисы на Go?

Микросервисы – это очень хорошая идея, то есть если что-то можно сделать потом или сделать в фоне, это всегда надо стремится сделать потом или сделать в фоне. Таким образом, выделяя через очереди, какие-то точки обработки. Эти точки обработки, да, они потом выльются в микросервисы. Микросервисы имеют один большой плюс. Плюс в том, что они маленькие. И как только наш микросервис, который написан на PHP, перестает нас удовлетворять по скорости, мы берем Go и пишем тоже самое. То есть штуку, которая работает с той же самой очередью, которая имеет тот же самый внешний интерфейс, соответственно, делает те же самые вещи более эффективно. Или пишем это на Сях или еще на чем-нибудь, на Java, на PHP — это не имеет значения. Микросервисы дают нам ту свободу, что программа маленькая и мы ее можем переписать на чем угодно.

Да, да, согласен. И тут мы ждем от Yii какой-то системы очередей!

Да, система очередей, на самом деле, сейчас разрабатывается. Идет дискуссия неслабая на тему, какой она должна быть. Сейчас мы все сходимся к тому, что нужно, во-первых, нескорый интерфейс для, соответственно, очередей и сообщений, и поверх него уже что-то такое, что будет включать в себя и все эти дела, чтобы как-то абстрагироваться для высокоуровневых приложений. Занимается всем этим делом Александр Кочетов, известный по нику creocoder. Так что штука должна быть хорошая, но может быть не прямо скоро, не прямо сейчас.

Одним словом, креативная штука от «креокодера».

Креативная штука от «креокодера», но он всегда делает очень качественно, но занимает это прилично времени, потому что он продумывает все от и до.

Пожалуй, все вопросы, которые мы хотели обсудить, мы обсудили. Хочешь ли в конце добавить что-то для наших слушателей, какую-нибудь новость или ссылку?

Для слушателей я добавлю свой обычный совет, то есть не стоит слепо верить тому, что говорят какие-то авторитетные люди, разработчики, даже тот же Мартин Фаулер. Всегда думайте над тем, что сказано, пытайтесь это дело подвергнуть сомнению и если сомнения оно не вызывает, то только тогда принимайте.

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

Да, это было бы интересно.

А вам, дорогие слушатели, спасибо, что нас слушаете. Читайте на сайте текстовую расшифровку. Правда это длинный выпуск, посмотрю, как у меня получится его расшифровать и от себя под конец добавлю небольшую ссылку: «Шокирующее интервью с разработчиком сайтов» — видео YouTube, посмотрите, очень весело :)

И, к следующему совместному выпуску, возможно, у вас есть свои вопросы или пожелания, кого бы вы хотели видеть в гостях? Пишите в комментариях на сайте 5minphp.ru Спасибо, что были с нами. Пока, пока.

Пока, пока.