Мы, PHP-разработчики, горды тем, что пишем на ООП-языке (можно легко здесь заменить PHP на C#, Java или другой ООП-язык). Каждая вакансия содержит требования про знание ООП. В каждом собеседовании спрашивают что-нибудь про SOLID или трех "китов" ООП. Но когда дело доходит до дела — мы получаем просто классы, наполненные процедурами. ООП проявляется редко, обычно в коде библиотек.

Обычное веб-приложение — это классы ORM-сущностей, которые содержат данные из строки в базе данных и контроллеры(или сервисы — неважно), содержащие процедуры работы с этими данными. Объектно-ориентированное программирование — оно про объекты, которые владеют собственными данными, а не предоставляют их для обработки другому коду. Отличная иллюстрация этого — вопрос, который был задан в одном чате: "Как я могу улучшить этот код?"

Техника кеширования позволяет создавать более масштабируемые приложения, запоминания результаты некоторых запросов в быстрое in-memory хранилище. Однако, некорректно реализованное кеширование может сильно ухудшить впечатление пользователя о вашем приложении. Эта статья содержит некоторые базовые понятия о кешировании, различные правила и табу, которые я извлек из нескольких прошлых своих проектов.

Не используйте кеширование.

Ваш проект работает быстро и не имеет никаких проблем с производительностью?
Забудьте о кешировании. Серьезно :)

Оно сильно усложнит операции чтения из базы без каких-либо бенефитов.

Правда, Мохамед Саид в начале этой статьи делает некоторые вычисления и доказывает, что в некоторых случаях оптимизация приложения на миллисекунды способна сэкономить кучу денег на вашем AWS счету. Так что, если прогнозируемая экономия на вашем проекте больше, чем 1.86 долларов, возможно, реализация кеширования — неплохая идея.

На конференции DevConf недавно появилась хорошая традиция ближе к вечеру собирать бесплатные митапы. В этом году я решил провести митап по Laravel где можно будет за чашкой пива послушать пару-тройку не слишком хардкорных докладов, в которых докладчики будут просто делиться своим опытом. Дата-время: 21 июня 17:00

Доклады:

• «Мифы и реальность unit и не-unit тестирования в Laravel» Адель Файзрахманов (Patron Technology)
• «Сохраняем много данных: как не умереть» Виталий Юшкевич (PUGOFKA)
• «Жизнь за пределами Eloquent» Кирилл Несмеянов (Rambler Group)

Крайне желательно зарегистрироваться, если решили пойти — вот ссылка. Митап бесплатный.

Кстати, если есть желание более плодотворно провести этот день, лучше зарегистрироваться на конференцию DevConf.

Один из ключевых разработчиков Yii, Александр Макаров(SamDark), выступит на DevConf с докладом про пакетные метрики и я воспользовался возможностью задать несколько интересующих меня вопросов про новую версию Yii, новую ORM, сбор денег на OpenCollective, фулл-тайм open source разработку и немного про конференции.

Начну с вопроса, который тебе задают постоянно. Что с Yii? Когда Yii 3? Я довольно долгое время наблюдаю активное создание новых пакетов в github.com/yiisoft

С Yii всё нормально. Ну почти. Чтобы объяснить, нужно немного посмотреть назад.

Когда мы делали версию 2.0 мы несколько переоценили свои силы. Оно и понятно, Qiang Xue сворачивал горы каждый день и казалось нам по силам всё и сразу.

Потом, к сожалению, времени на OpenSource у него не хватило, и поддержка сделанного скушало всё время остальной команды. Ну а так как фуллтайм фреймворком никто не занимался, это выливалось в то, что релизы были не частыми и большими. Вдобавок, при проектировании тогда мы наделали ошибок. Сейчас мне они кажутся очевидными, но тогда мы думали, что так хорошо. Их, к счастью, не так много. Они не делают Yii 2.0 плохим, фреймворк вышел хороший. Но они вылились со временем в то, что обещание обратной совместимости, множество фич и дефицит времени дали нам проблемы с развитием фреймворка: внедрением PSR, ухода от закрытости к общим для всего PHP пакетам и библиотекам, улучшением по части применения более сложных подходов к разработке, лучшей тестируемости.

Юбилейный десятый DevConf пройдет в этом году 21 июня в X-perience Hall. Каждый год на DevConf веб-разработчики обмениваются опытом посредством докладов и, что не так заметно, но не менее важно, разговорами в кулуарах.

Еще есть время подать заявку на доклад.

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

Василий Богонатов расскажет как Яндекс строил сервис распределённых очередей на своей новой newSQL базе данных Yandex Database.

Александр Макаров хочет обсудить пакетные метрики.

Порассуждают о вечном вопросе быстроты и качества со стороны back-end (Николай Притульский) и front-end (Дмитрий Лукиянчук) разработчиков.

До встречи на DevConf.

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

<?php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);
}

Однако, в реальных проектах, если репозитории таки было решено использовать, в них часто добавляются методы для выборок записей:

<?php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);

    public function getLastPosts();
    public function getTopPosts();
    public function getUserPosts($userId);
}

Я регулярно вижу статьи в стиле "как использовать шаблон Репозиторий с Eloquent" (одна такая попала в недавний PHP-дайджест). Обычное содержание их: давайте создадим интерфейс PostRepositoryInterface, EloquentPostRepository класс, красиво их забиндим в контейнере зависимостей и будем использовать вместо стандартных элоквентовских методов save и find.

Зачем этот шаблон нужен иногда вовсе не пишут ("Это же шаблон! Разве не достаточно?"), иногда что-то пишут про возможную смену базы данных (очень частое явление в каждом проекте), а также про тестирование и моки-стабы. Пользу от введения такого шаблона в обычный Laravel проект в таких статьях сложно уловить.

Попробуем разобраться, что к чему? Шаблон Репозиторий позволяет абстрагироваться от конкретной системы хранения (которая у нас обычно представляет собой базу данных), предоставляя абстрактное понятие коллекции сущностей.

«Так… мне нужна простая авторизация. Какая-нибудь админская роль, и может роль редактора/модератора. Сейчас погуглим. О! Для laravel уже есть готовые пакеты! zizaco/entrust, spatie/laravel-permission и другие! Давай выберем какой-нибудь!»

Примерно так все и происходит. Потом миграция пакета добавляет в базу 5 табличек для хранения ролей, пермишенов и их отношений. Все правила авторизации, такие как роли 'admin' и 'editor' могут делать 'edit posts', хранятся в этих таблицах. Обычно в проекте много копий базы данных. Копии разработчиков, тестовая база(ы) и продакшен. В итоге все эти правила авторизации вынуждены синхронизироваться между базами данных.

В эту пятницу, 18 мая, состоится профессиональная конференция веб-разработчиков DevConf 2018. Приглашаем принять участие. Очень кратко про программу:

DevConf::BackEnd: Агрегатное мышление, переписывание проекта с Drupal 8 на Yii 2, Yii 2.1, PHP и фреймворки, Service Oriented Architecture, отправка уведомлений, sample profiling, open tracing, Business Intelligence.

DevConf::FrontEnd: HOC в React, WebRTC: видеозвонки из браузера, Headless Chrome, архитектура большого легаси проекта, JSON API, Фреймворк для индивидуального дизайна, Тестируй это, Node.js и бесплатный митап LuaInMoscow.

DevConf::Storage: MySQL/MariaDB/Percona Server: что нового, логическая репликация в PostgreSQL, SphinxSearch, ClickHouse, ProxySQL для отказоустойчивости MySQL, обзорный доклад про разные механизмы сжатия данных от Андрея Аксенова.

DevConf 2018 уже на следующей неделе! В прошлом году Юрий Насретдинов провел интересный обзор перспективных систем хранения данных для highload. Видео с докладом доступно на странице доклада. А для хабра-читателей предлагаю краткий пересказ.

В начале расскажу как нужно подходить к выбору технологии для highload-проекта.

• В первую очередь, должно быть понимание как оно работает. Не только сильные, но и слабые стороны.
• Знание как это мониторить и бэкапить. Без хороших инструментов для этого, эту технологию рано использовать в продакшене.
• Рано или поздно системы «падают»(это нормальная, штатная ситуация) и нужно знать что делать в этом случае.

18 мая в Digital October(Москва) пройдет конференция веб-разработчиков DevConf. Григорий Кочанов поведает про блокчейн. Признаться, я скептик всего этого хайпа, поэтому немного расспросил его.

Начнем с такого вопроса. Где по твоему мнению блокчейн как технология будет лет через 5. К какой точке ближе: Завоюет мир или будет забыта?

Это хайп, но это не пиар одной компании, как с ROR или Mongo. Блокчейн — это топология архитектуры для распределенных приложений. Ничего нового — по CAP-теореме это архитектура класса CP (consistency-partition tolerance). Для сравнения, СУБД — это класс CA ( consistency- availability ). Этот инструмент удобен для решения ряда задач, и он будет использоваться.

18 мая 2018 в Digital October(Москва) пройдет DevConf — большая ежегодная конференция для веб-разработчиков, где обсуждают обо всем самом новом в мире программирования для веб. Программа определяется голосованием за доклады.


В секции BackEnd: будущее PHP, мышление агрегатами, сервис-ориентированная архитектура, немного про блокчейн, трудности переписывания проекта, tracing, profiling, etc.

В секции FrontEnd: React, GraphQL, Node.JS, WebRTC видеозвонки, телевизоры, тесты и разработчик PhantomJs.

В секции Storage: PostgreSQL, MySQL, ProxySQL, SphinxSearch, ClickHouse и немного(много) про сжатие данных.

Под занавес прошлогоднего DevConf Артем Дегтярь и Павел Степанец рассказали как они мигрировали ERP-систему написанную на «голом» PHP5.3, работающую на винде, в Symfony + PHP7, и построили на его основе облачный сервис в сфере b2b. Видео доступно по ссылке доклада. А я представлю текстовый, немного сжатый, вариант.


Мы работали над большой системой, которая позволяла создавать заявки и менять статусы, плюс биллинг, учет ТМЦ и много всего. Сегодня мы расскажем как рефакторили эту систему, мигрировали ее в Symfony. Первоначально система была написана на чистом PHP, и имела много «особенностей». Например, этот пятиуровневый тернарник на слайде весьма оригинально работал с датой, пришедшей от юзера.

DevConf 2018 состоится 18 мая в Москве, в Digital October. А мы продолжаем публиковать доклады с прошлогодней конференции. На очереди доклад Алексея Акуловича из ВКонтакте, где он поведает о том, о чем внимательные читатели уже догадались по сабжу.


В 2015 году мы использовали стороннее решение. Мы встраивали(embed) его плеер на сайт как youtube и оно работало. Работало не идеально, но на тот момент оно нас устраивало по объему трансляций, который через него можно было пустить, а также по качеству и задержкам, которые оно давало. Но мы из него довольно быстро выросли.

18 мая 2018 года в Digital October состоится DevConf 2018. И мы решили пересказать некоторые интересные доклады с прошлогодней конференции. Там был доклад с несколько холиварным заголовком: "О чём молчит политрук: к дискуссии о переходе Uber с PostgreSQL на MySQL". В нем разработчик MySQL Алексей Копытов рассмотрел различия InnoDb и PostgreSQL на самом низком уровне, включая организацию данных, памяти и репликаций. Предлагаем вашему вниманию краткий пересказ доклада.

История вопроса

Uber перешел с MySQL на Postgres в 2013 году и причины, которые они перечисляют, были во-первых: PostGIS — это геоинформационное расширение для PostgreSQL и хайп. То есть, у PostgreSQL есть некий ореол серьезный, солидная СУБД, совершенный, без недостатков. По крайней мере, если сравнивать с MySQL. Они мало что знали о PostgreSQL, но повелись на весь этот хайп и перешли, а через 3 года пришлось переезжать обратно. И основные причины, если просуммировать их доклад — это плохие эксплуатационные характеристики при эксплуатации в production.

Так зачем же мы пишем этот плохой код, который изо дня в день замедляет нашу работу?
Потому, что мы тогда вынуждены были сделать что-то быстрее!
Я оставлю вас наедине с это логической несостыковкой…
_{На одной из лекций Роберта Мартина}

У нас на DevConf будет не самый обычный мастер-класс. Там не будут рассказывать о новых технологиях или хайлоаде. Будут говорить о коде. Хорошем, плохом. Называется он Принципы хорошего кода на реальных примерах. Расспросим немного автора.

Кто ты и чем занимаешься?

Меня зовут Адель. Я фрилансер. Обычно занимаюсь backend-разработкой. Еще иногда пишу и дописываю плагины для PhpStorm. Из популярных Laravel plugin и .env files support.

Что тебя побудило на такой мастер-класс?

Удрученность текущей ситуации в отрасли. Все одержимы технологиями. В последнее время облачными. Читаешь вакансию, перечисляют используемые технологии, необходимый опыт (который почти никогда, на самом деле, не нужен). Очень круто звучит на собеседованиях. Приходишь на проект. Смотришь на код… и он печально говорит тебе: «Пристрели меня». Смотришь глубже и понимаешь всю его печаль. Он смертельно болен. Как раковые опухоли разрослись классы, которые кто-то, словно в шутку, назвал контроллерами. Как метастазы везде расползлись копипасты. На психологию кода давит то, что он лишь жалкая обвязка для крутых облачных технологий. Но пристрелить дорого.

Мы любим делать интервью с нашими докладчиками. На этот раз — интервью с Андреем shodan Аксеновым, создателем поискового движка SphinxSearch(не знаю как сейчас, но раньше хабр использовал именно этот движок для поиска по сайту) и, как оказалось, еще пары движков. На нашей конференции он будет рассуждать на извечную тему: Devs vs CTO vs CEO. Само интервью вышло довольно интересным. Андрей честно и откровенно ответил на вопросы, за что ему большой респект :)

Я тебя знаю как разработчика Sphinxsearch, но, как показывает твоя краткая биография, которую ты дал в описании доклада, похоже компьютерная графика — твоя главная страсть?

Все одновременно проще и сложнее, какой-то главной мегастрасти нету :) Есть сколько-то интересные области, есть безразличные. Делать всякий низкий уровень, типа поискового движка, 3D игры, обработки видеозахвата, крохотного недогипервизора (V8086), патчить MySQL или ядро операционки, писать спецмодули к Апачику, улучшать известный алгоритм сжатия или даже просто ковыряться с особо толстыми и тормозными SQL запросами — все это бывает довольно интересно (а бывает нет! но чаще интересно). А вот рисовать формочки для GUI, неважно, на моднейшем Node.js или дохлом Delphi, или там править унылые отчеты в 1C — таки не очень. Говорю по личному опыту, тк. в какой-то мере занимался всем вышеперечисленным и еще всяким.

Представляем небольшое интервью с одним из докладчиков DevConf 2016 Александром Макаровым aka SamDark. Он является членом Yii core team c 2010 года и представителем Yii в PHP-FIG. Автор книги Yii Application Development Cookbook.

В первую очередь хотел бы спросить о работе. Ты работаешь в Stay.com. Подозреваю, что удаленно. Ты также активно участвуешь в конференциях, работаешь над Yii. Как удается совмещать? Это не фулл-тайм? Или что-то сродни когда-то гугловскому «20% на свои проекты»?

Да, я работаю в Stay.com. В основном, удалённо. Это fulltime. Yii занимаюсь либо в свободное время, либо когда не очень сильная загрузка по основному проекту.
На тему конференций у меня договорённость: они оплачиваются ровно так же, как и рабочие дни.

У нас сотни программных проектов на поддержке, некоторые из них поддерживаются нами почти десять лет. Нетрудно догадаться, что понятие maintainable кода (переведу это понятие как код, легкий в поддержке) является у нас одним из основных. По счастливому стечению обстоятельств легкий в поддержке код также является и легким для (unit-)тестирования, легким для освоения новыми членами команды и т.д. Скорее всего, это связано с тем, что для создания maintainable кода приходится озаботиться хорошей архитектурой проекта и завести несколько хороших привычек.
В этой статье и поговорим о таких привычках, благодаря которым часто хорошая архитектура получается сама собой. Постараюсь также иллюстрировать все хорошими примерами.