<rmcreative>

Выходные прошли сверхпродуктивно. Взяли второе место на хакатоне Мануфактуры, Сбербанка и ФРИИ. Шёл я туда не ради победы. В подобных хакатонах никогда не участвовал и было интересно.

Читаем

24 сентября с 11:00 по 18:00 в Киеве состоится мини-конференция по Yii 2.

Три члена команды Yii расскажут три доклада:

• Безопасность. От базовых принципов до особенностей PHP (Александр Макаров).
• Продвинутое использование ActiveRecord: Cross-DBMS отношения и реляционная выборка (Павел Климов).
• Работа с Dependency injection, Container и Service locator (Дмитрий Науменко).

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

Подробнее узнать о месте проведения и записаться можно здесь.

UPD: отчёт и материалы.

3 сентября в Киеве пройдёт конференция PHP frameworks day. В этом году Yii будет представлять Дмитрий Науменко (@SilverFire). Он расскажет про профилирование PHP-приложений в общем и про Yii в частности.

Программа довольно интересная. Подробности можно найти на сайте. Билеты вроде ещё остались.

Дал интервью на английском компании CloudWays. Чуть про меня, про Yii и про OpenSource в общем.

Читаем

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.