PHP *

Service Manager (SM, CM) в ZF2.

Service Manager — это один из ключевых компонентов Zend Framework 2, который существенно облегчает жизнь разрабочика избавляя его от дублирования кода и рутинных операций по созданию и настройки сервисов, позволяя их конфигурировать на максимально высоком уровне. СМ, по своей натуре, является реестром сервисов, основная задача которого — создание и хранение сервисов. Можно сказать, СМ является очень продвинутой версий компонента Zend_Registry из Zend Framework 1.
СМ реализует паттерн Service Locator. Во многих частях приложения (например, в AbstractActionController) можно встретить функции getServiceLocator(), которые возвращают класс Zend\ServiceManager\ServiceManager. Такое несоответствие названия метода и возвращаемого типа легко объясняется тем, что getServiceLocator() возвращает объект, реализующий интерфейс ServiceLocatorInterface:

Доброго времени суток, %habrauser%!

Недавно встала задача, хранить в базе данные GPS с дальнейшей возможностью применения различных геометрических функций mysql. Управление координатами должно осуществляться из sonata-admin. Что из этого получилось можно прочитать под катом.

Задача

Настроить использование RBAC в Yii2.

Условия

Список возможных ролей:

• guest — не авторизованный юзер;
• BRAND — авторизованный юзер, наследует разрешения роли guest и имеет свои уникальные разрешения;
• TALENT — авторизованный юзер, наследует разрешения роли guest и имеет свои уникальные разрешения;
• admin — авторизованный юзер, наследует разрешения ролей guest, BRAND и TALENT и имеет свои уникальные разрешения.
• Роль определяется полем group в модели UserExt;
• Роли имеют вложенную структуру — одна роль может наследовать разрешения другой;
• Используется yii\rbac\PhpManager;
• Не использовать назначение роли юзеру по его ID — вместо этого использовать несколько предустановленных ролей (defaultRoles);
• Генерирование конфига «роль-разрешения» будет делать консольная команда yii;
• Будут использованы расширенные правила (Rules) для разрешений.

Предварительная настройка

app/config/console.php

'components' => [
    // ...
    'authManager' => [
        'class' => 'yii\rbac\PhpManager',
    ],
    // ...
],

app/config/web.php

'components' => [
    // ...
    'authManager' => [
        'class' => 'yii\rbac\PhpManager',
        'defaultRoles' => ['admin', 'BRAND', 'TALENT'], // Здесь нет роли "guest", т.к. эта роль виртуальная и не присутствует в модели UserExt
    ],
    // ...
],

Создать директорию @app/rbac — именно в ней будут находиться разрешения и правила.

Продолжая рассказывать о технологиях, которые используются в нашем сервисе email-маркетинга Pechkin-mail.ru, мы просто обязаны упомянуть об автоматическом определении пола подписчика по имени. Еще в 2007 году, разрабатывая сервис sms-рассылок, мы очень хотели реализовать возможность автоматического подставления окончаний в прилагательные “Уважаемый”, “Дорогой” и так далее. Обычно такая подстановка осуществляется на основании дополнительного поля в адресной базе клиента. Однако, как нам кажется, это полный отстой.
На это есть 3 причины:

1. заставлять подписчика задавать свой пол глупо (чем больше полей в форме, тем ниже вероятность ее заполнения)
2. определять вручную — долго, а значит дорого
3. от ошибок человек не застрахован ровно так же, как и машина.

Но мы не лингвисты, поэтому реализовать такой модуль было бы слишком сложно для нас, да и функция “не первой необходимости”. Но недавно, работая над склонениями текстов бесконечных актов, договоров и прочих юридических документов, мы вспомнили об используемом нами уже 2 года сервисе Морфер. Это прекрасный лингвистический сервис, специализирующийся на русском языке и позволяющий склонять по падежам слова, целые предложения, числительные, а также получать текст из цифр. В общем, потрясающая разработка всего одного человека — Сергея Слепова.

В предыдущей части этой серии мы понизили связанность симфонийского контроллера и фреймворка, удалив зависимость от базового класса контроллера из FrameworkBundle. А в этой части мы избавимся от некоторых неявных зависимостей, которые появляются из-за аннотаций.

Долгожданный выход Yii 2.0 Beta дал стимул многим разработчикам, использующих Yii, к переходу на вторую версию фреймворка. Разработчики фреймворка указали, что постараются не трогать обратную совместимость и в основном будут сосредоточены над исправлением ошибок и заканчивать документацию. Это дает еще больший импульс к использованию Yii2 в реальных проектах.

Мы решили не отставать от новшеств и выбрали именно вторую версию замечательного фреймворка Yii. При разработке проекта возникла необходимость в организации мультиязычности на сайте.

PHP-разработкой я занимаюсь уже довольно давно, и за это время научился использовать преимущества этого языка и избегать, по возможности, его недостатков. Но что мне никогда не нравилось в PHP — это встроенный механизм шаблонизации. Обилие символов “<?php … ?>” и многословных языковых конструкций бьет по глазам, возможность использования в шаблоне произвольного PHP-кода не способствует соблюдению принципа разделения логики и представления.

Поэтому я благодарен судьбе (и сообществу разработчиков, конечно) за то, что существуют альтернативные движки шаблонизации, с гораздо более приятным синтаксисом при тех же функциональных возможностях. Ну, а поскольку большая часть PHP-проектов у нас, в Центре Высоких Технологий, разрабатывается на Symfony2 Framework, то нашим любимым шаблонизатором стал Twig. Помимо указанных выше преимуществ, он еще и безгранично расширяемый, что очень часто помогает в работе.

Но жизнь частенько преподносит сюрпризы. Вот и на меня недавно свалился небольшой, но довольно интересный проект, делать который нужно было на… Битриксе! К счастью, работать с Битриксом мне уже приходилось, но было это давно (и неправда), поэтому я воспринял проект как возможность посмотреть на свой прошлый опыт с новой точки зрения, применить накопленные знания и навыки в несколько ином контексте.
И первое, что мне захотелось сделать — “прикрутить” Twig, чтобы не мучиться с нативной шаблонизацией.

Вот что из этого получилось.

Пока еще только ведутся работы над третьей версией фреймворка PHPixie, но уже можно точно сказать что он сильно изменится в лучшую (как по мне) сторону:

• Полный переход на стандарт PSR-2
• Поскольку фреймворк будет являть собой набор библиотек, то его компоненты можно будет использовать в любом проекте без самого PHPixie.
• 100% покрытия кода тестами. При чем в данном случае 100% не просто фигуральное слово а реально просчитанный «code coverage», то есть отношение строк которые вызываются при исполнении тестов ко всем строкам кода, кстати у Laravel это всего-лишь 53%.

Вчера стали доступны две библиотеки которые войдут в PHPixie 3, они полностью готовы и их уже можно использовать с любым проектом. Это сделано Подробнее об этом можно почитать в посте на сайте, а я здесь опишу то что мне больше всего в них нравится.

Здравствуйте, уважаемые читатели!

Картинка, кратко и аллегорично передающая смысл описанного в посте скрипта:


У меня есть несколько сайтов, на которых в какой-то момент начал появляться вредоносный код, выглядящий как отдельные php-файлы либо дополнительные строки с длинными eval() в существующих файлах.

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

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

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

До тех пор, пока у нас не было большого количества всевозможных данных, мы не имели каких-то нестандартных проблем и все решения были достаточно прямолинейными. Но проект разрастался, и размер собираемой информации, хотя сначала и не очень быстро, но все же увеличивался. Росла и кодовая база. И через некоторое время мы осознали весьма печальный факт — из-за всяких костылей и быстро-фиксов мы нарушили почти все возможные принципы проектирования. И если сначала организация кода была не столь важна, то со временем стало понятно, что без хорошего рефакторинга далеко мы не уедем.

Сегодня я написал последний тест для версии 3.0 модуля доступа к БД для PHPixie. Когда я начал казалось что это займет всего несколько недель, но на самом деле все растянулось на где-то 2 месяца из-за огромного количества рефакторинга и переписывания сначала. Зато теперь мы имеем расширяемую библиотеку, которую можно использовать даже вне самого фреймворка (то есть если вас заставят писать на каком-то другом фреймворке или CMS вы сможете захватить свою любимую библиотеку с собой).

Я сделаю релиз после того как закончу модуль ORM и поправлю существующие модули для работы с новым API. Но если вам интересно вы можете заглянуть в ветку 3.0 на гитхабе (следует однако предупредить что документации там пока нет, она появится вместе с ORM). А теперь давайте посмотрим на новые возможности.

Как правило, мнения расходятся касательно того, хорошей ли практикой является использование публичных свойств в PHP классах или всё же стоит использовать геттеры и сеттеры (и хранить свойства приватными или защищёнными). Ещё одно, компромиссное мнение, состоит в том, чтобы использовать магические методы __get() и__set().
У каждого из подходов существуют свои достоинства и недостатки, давайте взглянем на них…

Это третья (последняя?) часть статьи, посвященной разработке простого приложения при помощи Zend Framework 2. В первой части я рассмотрел структуру ZendSkeletonApplication, во второй части привел пример разработки простого модуля. Эта часть посвящена работе с пользователями, а также я прикручу к проекту шаблонизатор Twig.

Работа с пользователями

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

Zf Commons

Для Zend фреймворка написано достаточно много модулей, решающих стандартные задачи, найти их можно на специальном сайте: modules.zendframework.com. Вместо разработки своих велосипедов для решения стандартных задач я считаю более правильным использовать/адаптировать под себя готовые решения (по крайней мере готовые решения нужно изучить прежде чем браться за разработку велосипеда).

Среди множества разработчиков модулей выделяется команда ZF Commons, ребятами из этой команды разработан ряд очень полезных модулей, которые мы будем использовать в этом проекте: github.com/ZF-Commons. Рассмотрим некоторые из них, которые необходимы нам на данном этапе.

12 марта стала доступна новая версия PhpStorm 6.0

Работаю с Redis относительно недавно и вот возникла необходимость изменения одного ключа несколькими потоками одновременно. Для работы с Redis в php использую клиент Rediska. Еще когда читал мануал по Rediska видел раздел про транзакции, а сегодня пришло время почитать внимательнее.

Введение

На определенной стадии изучения серверного программирования мне захотелось написать свой простенький фреймворк. Я рассчитывал, что это поможет более глубоко понять идеологию MVC и Zend Framework в частности. Когда дело дошло до части представления и генерации html я вспомнил о паттерне Компоновщик (Composite pattern). Возможно я несколько исказил его применение, но мысль пошла оттуда.

Начнём с идеи

Например, вы зашли на сайт в поисках чего-либо. Доступ к контенту ограничен. Есть два варианта: зарегистрироваться или поискать тот же контент на другом сайте. Велика вероятность, что данный сайт вам больше не пригодится, и захламлять свою почту спамом, да и просто делать какие-то лишние действия (регистрация, подтверждение) мало кому захочется. В таком случае, вы вводите адрес сайта в сервисе, и смотрите, есть ли свободные аккаунты для данного сайта. Свободным аккаунтом может быть любой логин и пароль, который другой пользователь посчитал не нужным, и решил поделиться им с другими, дабы сократить их время.
Идея сайта родилась в процессе трудового дня. На разработку потребовался один рабочий день. Мотивация – желание доказать что есть люди, готовые помогать другим пользователям интернета бесплатно, и подобного рода проекты могут жить.
Сервис создавался с помощью all-in-one фреймворка Next Code. Кому интересно как — добро пожаловать под кат.

По иронии судьбы, видео с самой первой — первопроходческой конференции 2010 года до сих пор пылилось в архиве (даже в неоцифрованном виде).

В предверии очередной конференции (ZFConf 2012, которая пройдет 21 апреля в Москве) мы решили заполнить этот пробел. Надо заметить, что большинство из докладов даже не потеряло своей актуальности.

Довольно часто при написании модульных тестов нам приходится сталкиваться с тем, что тестируемый класс зависит от данных из внешних источников, состояние которых мы не можем контролировать. К таким источникам можно отнести далеко расположенную общедоступную базу данных или службу, датчик какого-нибудь физического процесса и пр. Либо нам необходимо убедиться, что некие действия выполняются в строго определенном порядке. В этих случаях к нам на помощь приходят Mock объекты (mock в переводе с английского — пародия), позволяя тестировать классы в изоляции от внешних зависимостей. Использованию Mock объектов в PHPUnit посвящается эта статья.

Все мы тут собрались умные, образованные, красивые и опытные. И на сегодняшний день, мне кажется, почти все используют тот, или иной вид RPC между JavaScript и PHP, который работает на API из того, или иного фреймворка. Кое кто даже разрабатывает какие-то свои костыли и подпорки. Я не исключение, конечно же. Правда пошел я по пути наименьшего сопротивления и, собственно, речь в этой статье пойдет как раз об этом — об очередной реализации XML\JSON RPC для JavaScript и PHP.

Предыстория такова, что мне необходимо было разработать некую систему управления данными. Естественно, что данные хранятся в СУБД, а управлять ими надо через веб. Привязываться к фреймворкам готовым очень не хотелось, потому выбор был не велик — PHP-быдлокодинг, или MVC с рендерингом на основе готовых разработок вроде smarty. Однако, примерно в то же время, я обратил внимание на такие проекты как extJS (он же Sencha теперь) и qooxdoo, которые позволяют создавать полноценные веб-приложения минуя утомительную HTML-верстку, генерацию HTML/XML, XSLT преобразования и многие другие «страшные» вещи, характерные для MVC и PHP-быдлокода. Потому созрел следующий план действий.: