<rmcreative>

1 октября в Ульяновске расскажу про тренды в веб-разработке, PHP и фреймворки. Также поделюсь историей создания Yii и планами по его дальнейшему развитию.

Конференция бесплатная, но необходима регистрация.

Среди информации по построению REST API встречаются две рекомендации на тему сортировки и фильтрации. Сортировку делать вот так:

GET /users?sort=-created_at,username

Сортируем по убыванию по дате создания и по имени пользователя в алфавитном порядке.

Фильтры делать вот так:

GET /tickets?status=open&assignee=123

Получаем открытые тикеты, назначенные на пользователя с ID=123.

Вроде всё красиво, но что если у очередного ресурса появится поле sort? GET-параметр уже зарезервирован для сортировки, использовать его для фильтрации не получается. Выхода два: либо заставить пользователя никогда не использовать поле sort (а к нему со временем добавится like и ещё что-нибудь) либо ввести для фильтрации отдельный параметр filter. Значение лучше всего описать в формате JSON: не придётся заботиться о специальных правилах экранирования, да и поддержка его есть во всех клиентах.

GET /tickets?filter={"status": "open", "assignee": 123}

В случае отдельного параметра, хоть синтаксис и не настолько интуитивен, конфликт имён исключается.

Когда Composer ещё не стал стабильным, API его довольно часто менялось. Из за этого отваливались плагины. Одним из самых ярких примеров был постоянно ломавшийся fxp/composer-asset-plugin, используемый в Yii 2.0 и попивший немало крови. С релизом Composer проблема практически ушла, но к Yii 2.1, из за скорости установки и самой необходимости ставить плагин, было решено исследовать альтернативы. fxp, как и прежде, работает не быстро.

Читаем

Пару месяцев назад мне написали из школы английского EnglishDom и предложили их попробовать. Как-то давно у меня и Антона Исайкина была идея запустить подобную школу, работающую исключительно удалённо, но в процессе стало ясно, что мы это не потянем. Так вот, чтобы удовлетворить свой интерес и заодно проверить, можно ли рекомендовать учить там английский IT-шникам, я согласился.

Читаем

29-31 июля в Одессе пройдёт конференция WebCamp. В секции PHP выступит Дмитрий Науменко (SilverFire) из команды Yii с докладом «Рецепты для Yii 2».

Каждая технология имеет свои особенности, зная которые, можно создавать хороший код, который не стыдно показывать людям и удобно поддерживать. Рассмотрим хорошие идеи для Yii 2, пройдёмся по неудачным, научимся организовать структуру проекта, использовать модульный подход при разработке.

Билеты уже продают

В комментариях к посту про модули Дмитрий задал вопросы про AR.

Объем записей в таблицах от 500к, почти каждый запрос это 2-3 JOINa. Раньше делал через геттеры AR, выборка за раз порядка 100 записей. Но заметил такую штуку, что если использовать createCommand, то память заметно меньше расходуется и скорость быстрее. К сожалению, сейчас не могу показать реальные тесты, так как тестировали это месяц назад, но в итоге, большую часть моделей мы переписали на DAO, отказавшись от AR.

Память уходит на хранение данных в объектах. Скорость теряется из за необходимости эти объекты инстанциировать.

Так, так ли плох AR или его использование подходит для небольших проектов? У нас также постоянно идет вставка, порядка 5000 записей в час. Пока для этого используем AR.

Когда использование AR уместно, а когда нет?

AR отлично подходит для удаления, обновления или добавления небольшого количества записей по одной за раз. Чрезвычайно удобно. К тому же, поддержка dirty attributes, то есть сохранения только того, что изменилось, позволяет хорошо разгрузить базу данных и скрыть до лучших времён многие моменты при параллельном редактировании. Если у вас в приложении нет сильно сложной логики и не требуется дополнительных абстракций для сущности, то AR для этого подходит идеально.

Для простых выборок с целью отображения до сотни записей на страницу, в принципе, AR тоже подходит. Да, с массивами через query builder или с asArray() получается быстрее и меньше кушает памяти, но работать с ними не столь удобно.

Для сложных выборок AR не рекомендуется. Сложные выборки у нас обычно возвращают какие-либо агрегаты или преобразованные данные, которые ну никак не вписываются в изначальную модель AR. В этом случае лучше делать выборки через query builder.

Для импорта-экспорта также лучше использовать query builder.

В Воронеже несколько раз в месяц мы собираемся небольшой компанией, которую окрестили клубом «Deep Refactoring», рассказываем интересное из мира IT в виде доклада и горячо обсуждаем после. В начале месяца я рассказывал «Безопасность: от базовых принципов до особенностей PHP». Доклад я первый раз прочитал на английском в Стамбуле, затем на DevConf и последний раз в клубе.

Слайды всё те же с DevConf, а вот рассказ отличается. Во-первых, рассказывал в небольшой компании, так что задавали вопросы по ходу и меняли ход рассказа. Во-вторых, дело было в пабе :)

Слушайте на YouTube. Посмотреть особо не удастся. Темно.

Кстати, докладов было прочитано за время существования клуба уже не мало, все их можно посмотреть там же на YouTube.

Релизнули Yii 2.0.9. Анонс можно прочитать на хабре.

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

13 июля Intellectsoft с 18:00 по 22:00 организуют встречу по Yii 2, Codeception и тестированию. Пройдёт она по адресу Киев, Лейпигская 15, БЦ MERX-2. Встречу ведёт Михаил Бондарчук, автор Codeception.

Читаем

На тостере в комментариях к вопросу спросили, как получить mock ActiveRecord, чтобы он не пытался лезть в базу и возможно ли.

Возможно. В случае PHPUnit делается так:

$post = $this->getMockBuilder('\app\model\Post')
    ->setMethods(['save', 'attributes'])
    ->getMock();
$post->method('save')->willReturn(true);
$post->method('attributes')->willReturn([
    'id',
    'status',
    'title',
    'description',
    'text'
]);

Особенность заключается в том, что перекрыть надо ещё и метод attributes() потому как ActiveRecord лезет за схемой в базу данных, что нам не нужно.