В первую очередь хотел бы спросить о работе. Ты работаешь в Stay.com. Подозреваю, что удаленно. Ты также активно участвуешь в конференциях, работаешь над Yii. Как удается совмещать? Это не фулл-тайм? Или что-то сродни когда-то гугловскому «20% на свои проекты»?Да, я работаю в Stay.com. В основном, удалённо. Это fulltime. Yii занимаюсь либо в свободное время, либо когда не очень сильная загрузка по основному проекту.
На тему конференций у меня договорённость: они оплачиваются ровно так же, как и рабочие дни.
Версия Yii на рабочем проекте? ;-) Трудно ли идти в ногу со свежей версией?1.1.17 + немного патчей из master. На 2.0 перейти пока не получается. Переписывание проекта — задача ресурсоёмкая. Проект не маленький. Текущих задач много.
Если проект изначально на 2.0, идти в ногу с релизами фреймворка не сложно. Они не такие частые и если ломают совместимость, то об этом сообщается в специальном файле UPGRADE.
Чем вы занимаетесь в PHP-FIG? Только голосованием за PSR? Полезно ли обычным PHP-разработчикам(не тем, кто делает фреймворки), знать PSR? Если полезно, то чем.Помимо голосования и обсуждений я занимался PSR-12. Новым стилем кодирования на замену PSR-2. Начали мы бодро, но так как он про PHP 7, а семёрку ещё активно не начали использовать, решили немного подождать пока можно будет собрать нормальную статистику.
Прочитать все принятые PSR очень полезно. Многие из них часто встречаются в PHP. Остальные, вроде PSR-6, как минимум интересно и полезно изучить перед разработкой своих решений.
PHP последнее время развивается стремительно. Новая версия, куча различных rfc. И если некоторые изменения — просто гармоничное развитие языка, то такие фичи PHP7 как scalar type hinting and return types сильно приблизили PHP к статически типизированным языкам. Наблюдая за спорами, мне показалось, что PHP-разработчики разделились на два лагеря. Одни приветствуют новые веяния. Другим же не нравится это превращение PHP в Java(C#). Аргумент последних — у PHP всегда была своя ниша, отличная от Java и он всегда был динамически-типизированным языком. Что думаешь на этот счет?Разработка PHP — это OpenSource, где всё решает коллективное голосование. Судя по последним итогам, ярых противников изменений среди имеющих право голоса сейчас не так много. Явную типизацию я приветствую, но не собираюсь её фанатично использовать. Всему своё место. return types в 7.0 для меня практически бесполезны из-за nullable types.
В дополнение к предыдущему вопросу, похоже что у PHP наблюдается какая-то проблема роста. Добавили return types без nullable types. А из последнего — intersection types и union types, которые дадут возможность писать такой код:PHP — это наследие из решений, принятых очень давно. Ломать совместимость сразу и много нельзя: пользователи не поймут. Поэтому и получаются такие вот решение-патчи. Какие-то из них странные, какие-то вполне вписываются.
Лично у меня возникает такое чувство, что такими rfc-заплатками хотят закрыть глубинные проблемы PHP — проблемы с базовыми интерфейсами, и array, который не поддерживает эти интерфейсы. Как современный фреймворк, Yii будет работать на PHP7(ведь так? он уже работает?), но хочешь ли ты, чтобы Yii использовал такие вот фичи PHP7? Да, BC помешает этому в текущей версии. Но если говорить про будущие версии?function RecordsToList(Array | (Countable & Traversable) $input): String { ... }
Yii уже работает на PHP 7 и уже частично использует его возможности, для старых версий PHP откатываясь на собственный код. В будущих версиях требования к версии PHP будут плавно увеличиваться, свой код постепенно убираться в пользу того, что появилось в PHP.
А вообще, как думаешь, когда мэйнстримовые фреймворки начнут ломать свою compatibility с PHP 5.*? Чем PHP7 может заманить?Через 2.5 года: secure.php.net/supported-versions.php
Пока PHP 7 не может заманить разрабочиков фреймворков практически ничем, но совместимость с ним поддерживать однозначно необходимо.
Я последние свои проекты писал на laravel. И там используются два подхода для Inversion of Control — Service locator в виде псевдостатических классов-фасадов и DI в виде Constructor injection, Controller action injection, etc. Т.е. одно и тоже действие почти всегда можно сделать двумя вариантами. Например:Автоматические инъекции уже давно есть, документированы и активно используются теми, кому это близко. Планируется более активно рекомендовать такой подход в официальной документации.
илиMail::send(....)
public function __construct(Mailer $mailer) { $this->mailer = $mailer; } ... public function doSomeAction(...) { $this->mailer->send(...) }
Несмотря на то, что в документации почти везде используются классы-фасады как более простой вариант, опытные laravel-разработчики советуют использовать инъекции. Код с ними намного менее связанный(low coupling) и, я надеюсь, когда-нибудь и в хелпе для новичков будут рекомендовать их. Насколько я знаю, в Yii основной вариант для IoC — Service locator. Но какие-то варианты для DI там тоже есть(используются только внутри фреймворка?). Собираетесь ли вы в Yii вводить автоматические инъекции зависимостей как основной метод IoC?
Вопрос от Grikdotnet:Микроядро будет где-то в 2.2 — 2.3. На модульность не забили. Во-первых, она уже в каком-то виде есть: bootstrap, redis и т.д. Во-вторых, в 2.1 из ядра по плану переедет практически всё, связанное с клиентсайдом.
Почему забили на модульность и когда будет микроядро?
Пора переходить к DevConf. Ты докладываешь про безопасность. Из описания я не сразу понял для кого он. Для админов или программистов?Для программистов. Админского будет мало.
Ты являешься одним из организаторов Yii-хакатона, который будет проведен в рамках DevConf. Поделись информацией. Есть ли уже список тем?Темы будут определены в зависимости от числа желающих поучаствовать. Есть два типа задач. Первый — это то, что будет интересно всему сообществу: допил официального расширения для очередей и другие issue с github, совместный разбор и документирование возможностей, доработки по новому yiiframework.com. Второй — идеи, высказанные в сообществе: блогодвижок с туториалом по его созданию (примерно как это было для 1.1), отдельные расширения, плодотворные обсуждения на тему модных сейчас DDD и сервисного слоя, итоги которых будут оформлены в виде статей или разделов руководства.
Такое вот небольшое интервью. Если будут у вас вопросы к SamDark в комментариях, я попробую пригласить его в топик. От себя добавлю, что хакатон будет проводиться в выходные 18-19 июня и, разумеется, будет бесплатным. О точном времени и месте проведения будет объявлено в ближайшее время.
До встречи на DevConf 2016.
Комментарии (23)
LAV45
20.05.2016 12:23+1SamDark, планируется ли с переходом на Yii 2.1 версию активное использование гинераторов (yield)?
Adelf
20.05.2016 13:02SamDark сейчас направляется в Стамбул, где участвует в http://phpkonf.org/. Ответит на ваш вопрос как сможет. Но как по мне… он уже сказал в интервью, что фичи семерки не настолько круты, чтобы ломать совместимость с пятыми версиями. И ждать появления таких вещей как yield в коде фреймворка надо не раньше, чем через 2,5 года.
ErickSkrauch
20.05.2016 22:29Генераторы появились в PHP с версии 5.5 и, судя по обсуждению в Issues на GitHub (к сожалению не смог найти его, мб убрали?) в 2.1 всё же минимальная версия поднимется до 5.5. Сюда же можно отнести и Issue о использовании ::class, вместо ::className().
Adelf
20.05.2016 22:30Да. Ваша правда :). Не использовал их. Почему-то был уверен, что они из семерки.
Express777
20.05.2016 12:38+1Когда планируется запуск нового сайта YII2.ru?
SamDark
21.05.2016 00:46+1Как доделаем… надеюсь найти сил и времени, как вернусь из отпуска. Можете помочь: https://github.com/samdark/yiiframework-ru
piromanlynx
20.05.2016 14:39+1У меня есть вопрос на тему yii2 и composer.
Yii2 ныне стабильный и хороший фреймворк, готовый и цельный продукт, но почти гвоздями прибит к composer. Сам же composer до последнего времени имел довольно приличное количество багов (которые уже закрыли в стабильной версии, но написали новые). Собственно вопрос к SamDark:
Ввиду того, что использование yii2 без composer неудобно и почти невозможно — команда yii2 будет контрибьютить композер или это предоставится на волю и желание публики?
P.S. может я чего-то не знаю — ткните носом плизAdelf
20.05.2016 14:51+2Честно говоря, сейчас сложно представить серьезный фреймворк без пакетного менеджера. А в PHP другого столько же популярного(соответвенно, богатого пакетами) нет.
А что за баги?piromanlynx
20.05.2016 15:31Вопрос не о замене, а о развитии. Другой который был — умер (pear).
Ну багов там было масса — https://github.com/composer/composer/issues?q=is%3Aissue+is%3Aclosed
Сейчас уже кончено сильно лучше, чем было, он развивается. Но все же — начиная использовать фреймворк — хочется чтобы и все инструменты вокруг были хороши.
У нас на Yii2 написано 6 проектов, да, хорошо, здорово — но вот делать ли на нем «все» — пока вопрос.
Вопрос не только к композеру, такая же история с кодсепшином и другими инструментами вокруг фреймворка — они мягко говоря недотягивают.Adelf
20.05.2016 16:23В интервью говорится о некоей модульности, которую хотят реализовать. Поэтому можно будет заменить инструменты на свои. Но композера, я думаю это не коснется :)
SamDark
21.05.2016 00:48Как альтернатива CodeCeption зреет ещё один фреймворк для тестов. Как будет готов, покажем.
phpclub
Спасибо за отличное интервью. Вы можете оставлять вопросы по Yii хакатону здесь.