Насчет IronMQ — это же вроде SaaS-решение? Если да, то я таким решениям доверяю только частично, свое железо с сервисами приятней и надежнее. В целом, заслуживают внимания: RabbitMQ — для больших нагрузок (частично и Enterprise), ZeroMQ — для быстрых обсчетов и ActiveMQ — суровый Enterprise (используется в ЦЕРН-е для коллайдера, и будет в РФ электронное правительство.)
Остальные — либо облачные, либо еще в активной разработке.
Да, мсье знает толк в извращениях ) Сдается мне этот пост всплыл после мысли товарища chEbba в прошлом топике.
Решение в ActiveMQ
Хочу замолвить слово за ActiveMQ — в нем эта проблема отсутствует как класс, так как там есть отдельный JMS-шедулер, которому можно спокойно скормить задержку, количество повторов и интервал — все остальное будет сделано самим брокером.
Используем Symfony2. Посещений ~60тыс за день (150к просмотров). Фронты — nginx в нескольких географических ДЦ, Varnish в качестве реверс-прокси с ESI, далее несколько бэкендов на nginx+fpm. Помимо этого, внутри находится мощная SOA сеть из сервисов (около 15инстансов) на базе Symfony2 и шина с очередью сообщений и событий.
Замечательная новость! Но хотелось бы больше специалистов, таких как Lukas Kahwe Smith, Fabien Potencier, Marco Pivetta, Taylor Otwell, Mathias Noback, Kris Wallsmith и других. К сожалению, у нас в России практически нет разработчиков, которые бы делали что-то интересное в PHP. Только ребята из Badoo, да SamDark. Надо развивать общение и php-клуб в целом, собираться в кружках по аналогии с Яндекс-субботниками. Мы должны быть тоже интересными докладчиками!
Изучая литературу, я обнаружил рекомендации по использованию именно полей. Сам фреймворк вызывает контракты в нужном контексте, поэтому сохраняется доступ к защищенным и к приватным полям и методам класса.
Еще один важный момент: в контрактах-инвариантах нельзя использовать проверки на основе публичных методов, так как это приведет к рекурсии (инварианты проверяются после вызова публичного метода)
Именно так все и происходит, кэш генерится в виде отдельных файлов-классов, которые и заменяют оригинальные. Тяжеловестность есть из-за того, что приходится поработать над статическим анализом кода и его обработкой с помощью рефлексии. Но также есть консольная команда прогрева кэша, которая может выполняться в момент деплоя. Она значительно ускоряет старт приложения с аспектами
Тяжеловесно только при первом проходе, все остальные запуски очень быстрые. Чтобы оценить скорость — могу дать ссылку для кода ZF2, в котором перехватываются все методы (публичные, защищенные, статические) и пишется имя класса, метода и аргументы.
Быстро или медленно — решать вам :) хост — обычный бесплатный VPS
Да, тут есть некоторое расхождение, но я не призываю к использованию :) просто поделился тем, что выглядит интересно с моей точки зрения. Как это можно использовать — еще не до конца понятно даже мне, но есть ощущение, что из этого может получиться со временем что-то интересное.
Для этого нужно разобраться в том, как работает аспектный фреймворк Go! :) Если кратко — то он умеет вплетать советы в код конкретных классов до их загузки в память PHP (Load-Time Weaving). И метод становится композитом из оригинального метода и советов к нему. Причем сам код об этом практически ничего не знает.
Уточните свой вопрос :) Данное решение не подразумевает наличие какого-либо фреймворка кроме моего, также не требуется наличие DI-контейнера, для которого нужна генерация специальных проксей.
А так, да, эти проверки — и есть аннотации :)) И от валидации через аннотации ничем не отличается
Для первого вашего вопроса: здесь я выбрал сознательно простой пример. Поэтому да, как настоящий контракт это не стоит рассматривать, я хотел донести лишь идею использования. В настоящих системах этот контракт будет выглядеть значительно сложнее.
Что касательно второго:
… Хочу обратить внимание на то, что предусловия в рамках контрактов служат для проверки логки работы программы и не отвечают за валидность параметров, переданных от клиента. Контракты отвечают только за взаимодействие внутри самой системы. Поэтому пользовательский ввод должен всегда фильтроваться с помощью фильтров, так как утверждения могут быть отключены.
Согласен, что про ассерты я явно не написал, так как думал, что это известный факт. Так как и контракты и ассерты используются только на этапе разработки и девелоперских окружениях.
Да, ожидал этого вопроса :) Он уже многократно задавался, задается и будет задаваться. Ну что же, мое мнение таково, что рано или поздно аннотации будут реализованы на уровне ядра PHP, все к этому идет. Посмотрите на все новые фреймоврки: Laravel, Symfony2, Doctrine2, FLOW3. Везде есть аннотации, они удобны, они дают необходимый инструмент для описания мета-информации. Главное — правильно кэшировать и не анализировать их в рантайме.
Так что мое мнение: метаинформация в комментариях — это путь, от которого мы вряд ли откажемся. Стоит ожидать дальнейшего развития на уровне ядра PHP.
Так как PhpDeal основан на базе аспектов, то там все очень неплохо оптимизировано: кэш проксей, кэш аннотаций, поддержка опкод-кэшеров в боевом режиме, кэширование инстансов рефлексии под методы.
Что касательно тайпхинта — использовать ее однозначно, как и в случае с интерфейсами. Контракты не заменяют тайпхинтинг, а позволяют дополнительно описывать условия верификации при вызове метода.
Сделано это на уровне userland-а, однако работать это будет быстро, не разочарую вас. Если эта идея будет полезна, то есть возможность еще улучшить код, выпилив единственные eval-ы, которые сейчас используются для проверок в составе контрактов. Также есть замечательная мысль — добавить туда поддержку спецификаций на Gherkin-е. Тогда нативная документация к методу станет и контрактом к нему же:
class BankAccount
{
/**
* Deposits fixed amount of money to the account
*
* @param float $amount
*
* @Contract\Verify("Given some precondition and some other precondition")
* @Contract\Ensure("When some action by the actor and some other action, then some result is returned")
*/
public function deposit($amount) {}
}
Ассерты не должны использоваться как окончательные проверки, я об этом в статье как раз писал. Но они используются в момент разработки, т.е. если написать код с соблюдением контрактов, то утверждается, что в боевой среде эти проверки могут быть отключены — и приложение будет работать так, как задумывалось. Но, это не касается проверки параметров, передаваемых от клиента, об этом я тоже написал в статье. Контракты описывают взаимодействие исключительно в коде и обеспечивают корректность при разработке.
Преимущества написания ассертов в eval-стиле дает возможность PHP не интерпретировать код в том случае, когда ассерты отключены. Когда же код в ассерте написан явно — он все время парсится и выполняется движком, даже когда нет потребности в проверке контрактов.
Например, замОчили вы User::save, а потом кто-то поменял класс и добавил туда еще какой-нибудь UserSettings::save. И все, вы в тесте пропустили этот вызов.
С использованием АОП можно замочить все вызовы ->save() у всех сущностей, что может быть полезно для реализации и тестирования всевозможных ActiveRecord-ов, активно занимающихся работой с БД.
Остальные — либо облачные, либо еще в активной разработке.
За деталями можно обратиться к мануалу ActiveMQ: Delay and Schedule Message Delivery
Сайт: www.alpari.ru
Еще один важный момент: в контрактах-инвариантах нельзя использовать проверки на основе публичных методов, так как это приведет к рекурсии (инварианты проверяются после вызова публичного метода)
Быстро или медленно — решать вам :) хост — обычный бесплатный VPS
Здесь да, согласен. Без кофмортной подсветки синтаксиса крайне неудобно работать. Можно только помечтать о том, чтобы написать плагин к шторму.
А так, да, эти проверки — и есть аннотации :)) И от валидации через аннотации ничем не отличается
Что касательно второго:
Согласен, что про ассерты я явно не написал, так как думал, что это известный факт. Так как и контракты и ассерты используются только на этапе разработки и девелоперских окружениях.
Так что мое мнение: метаинформация в комментариях — это путь, от которого мы вряд ли откажемся. Стоит ожидать дальнейшего развития на уровне ядра PHP.
Что касательно тайпхинта — использовать ее однозначно, как и в случае с интерфейсами. Контракты не заменяют тайпхинтинг, а позволяют дополнительно описывать условия верификации при вызове метода.
Сделано это на уровне userland-а, однако работать это будет быстро, не разочарую вас. Если эта идея будет полезна, то есть возможность еще улучшить код, выпилив единственные eval-ы, которые сейчас используются для проверок в составе контрактов. Также есть замечательная мысль — добавить туда поддержку спецификаций на Gherkin-е. Тогда нативная документация к методу станет и контрактом к нему же:
С использованием АОП можно замочить все вызовы ->save() у всех сущностей, что может быть полезно для реализации и тестирования всевозможных ActiveRecord-ов, активно занимающихся работой с БД.