Значение, для свойства объекта доменной области, может быть перечисление (enum). Для контроля за этим перечислением его удобно описать в виде объекта значения (ValueObject). Получается что-то вроде:
$my_type = TicketType::priority();
if ($ticket->type()->equals($my_type)) {
}
Посмотрел код проекта. Оказалось все еще хуже чем я думал. Список доступных значений для ENUM получается с помощью рефлексии наследующего класса. Метод valueToString вообще мастерский говнокод.
Я ENUM в PHP рассматриваю как ValueObject и отношусь к нему соответствующе. В сущностях храню сам объект, а не его значение, список доступных значений описываю в явном виде и добавляю методы необходимыми для бизнеслогики.
А нам придется перед каждой функцией и константой писать слеш. Этож сколько проектов начнет заваливать логи нотисами, а потом и вовсе упадет. Тогда уж и для функций языка нужно вводить неймспайсы.
Как мне уже объяснил iSage и я сам об этом подозревал — это Firebase не может отправлять уведомления, а если реализовывать push-уведомления нативными средствами, то все работает. Что у вас и сделано.
А жаль, там много интересного. ) Думаю, я созрел для своей первой статьи для Хабра. :)
Я вижу что описанного материала многим недостаточно. И хотел бы написать статью/продолжение в которой описать больше технических тонкостей и альтернативных реализаций.
Готов уступить вам эту тему.
push-уведомления через Firebase бесплатные. Не знаю с чего вы взяли что за них нужно платить. Если использовать сторонние сервисы для отправки уведомлений такие как OneSignal и PushAll, то естественно это будет стоит денег, о чем я писал в одном из комментариев.
CDN естественно стоит денег. Если вы разместите статику на своих серверах, то это уже будет не CDN, а если вы начнете строить свою сеть CDN, то это выйдет дороже для большинства проектов.
Ну как сказать не автоматизируется. Уведомления это как email сообщения. Они работают через сторонние сервисы. Вопрос осмысленности такого тестирования я не поднимаю.
Некоторые тестируют отправляемые и доставляемые email сообщения поднимая тестовый SMTP сервер. Так и тут. Никто не мешает, при желании, поднять тестовый Service Worker и тестировать уведомления через него.
Тестировать работу самого Service Worker-а уже сложнее так как он работает вне контекста текущей страницы.
1. Заметь, я же нигде не говорил, что очередь не нужна. Но даже в фоне разбирать события курлом — плохой вариант.
Раз пошла такая тема. Нужно определится на чем написан сайт и бизнес логика проекта. Бизнес логика это самое важное в проекте и она определяет как отреагировать на то или иное событие.
Если проект написан на Go, то логично и уведомления отправлять через Go.
Если проект написан на PHP (как это часто бывает), то можно завести вторую очередь. Первая хранит события, а вторая уже готовые уведомления которые нужно отправить. А вот в качестве транспорта для отправки уведомлений из второй очереди, можно в этом случае использовать микросервисы на Go.
В этом случае мы можем потерять в производительности из-за 2 очередей, но зато логика будет прозрачной.
1. Заметь, я же нигде не говорил, что очередь не нужна. Но даже в фоне разбирать события курлом — плохой вариант.
Надо было так и говорит. "Не используйте cURL." Я вас неправильно понял.
2. firebase api — это не стандартное средство. Стандартное — webpush api.
Хорошо. Назовем это так — Библиотека/обертка над нативным интерфейсом. Что в этом плохого?
Согласен, лучше это решать нативными средствами.
Может вы поделитесь с обществом своим опытом в этой сфере?
Отправлять можно откуда угодно, а вот получать уведомления на клиенте без Service Worker нельзя. Уведомления без Service Worker уже не push-уведомления. Это неразделимое целое. Потому я и говорю в статье что push-уведомления это не одна технология, а целый набор.
3. не самая дешевая операция
Да, если делать это (multi)curl'ом на похопе (~250 пушей в минуту). На golang с concurency=200 (столько хочет гугловый http2) получается ~1000 пушей в секунду.
окей. А теперь представим что у вас 5000 подписчиков. Это значит что страница у вас будет открываться на 5 секунд дольше обычного и пользователи будут отказываться от вашего ресурса из-за ожидания, не смотря на то что вы используете супер продвинутый Go. Поставить же событие в очередь займет милисикунды, а разбирать очередь можете на чем угодно в фоне, хоть на PHP, хоть на Go, хоть на C.
4. Стандарт до сих пор не утвержден. И лучше не изобретать свой велосипед, а использовать один из кучи готовых сервисов, которые и о передрягах стандарта позаботятся и поддержку iOS/Safari обеспечат.
А кто изобретает велосипед? Как раз напротив. Я пытаюсь показать как реализовать уведомления используя стандартные средства (в данном случае средствами представленными Google), не прибегая к сторонним сервисам. Сторонние сервисы плохи тем что:
они получают полный доступ к нашему контенту который может содержать конфеденциальную информацию;
они встраивают рекламу в уведомления и им нужно отдельно платить за то, чтоб они этого не делали;
большинство имеют ограничение на количество подписчиков и уведомлений. После выхода за лимит начинают требовать деньги;
сторонние сервисы вообще живут за счет того, что просят деньги за свои услуги.
Внимание вопрос. Зачем платить за то что можно сделать бесплатно? Причем абсолютно легально и стандартизировано.
Я не хочу сказать, что сторонние сервисы это зло. В своем личном, некоммерческом проекте я скорей всего воспользуюсь их услугами. А вот серьезные организации, которым важен престиж и конфиденциальность, такой вариант не рассматривают.
PS: я уже обсуждал тему осмысленности сторонних сервисов для отправки push-уведомлений с автором проекта PushAll BupycNet и не хотел бы возвращаться к этой теме.
Видел и задавался тем же вопросом. В документации не описаны какие либо методы по кастомизации окна. Подозреваю что это делается через какие-то костыли и хуки. Не советую вам это делать. Единообразие интерфейса не есть плохо
Если значение для сущности не набор, а одна еденица и нужно ей добавить функции или ограничить набор допустимых значений, как в случае ENUM, то можно создать свой тип для маппинга в Doctrine.
Вообще DDD в php лучше реализовывать через Doctrine.
Незачет. Конечно спасибо за проделанную работу. Я как-то не подумал кординаты выносить в ValueObject, но вы его использовали неправильно. В конструкторе нужно передавать не 2 кардинаты, а ValueObject кординат. Тогда можно изменить представление кординат не затрагивая LandRover. Можно добавить ту же ось Z не затрагивая LandRover.
Я не знаю как вы собираетесь реализовывать движение марсохода, но в случае использования ValueObject, вам нужно пересоздавать объект для изменения кординат. Эту задачу можно делегировать объекту Coordinates.
В первой статье вы говорили что марсоход может двигаться на один шаг. Вы собираетесь делать защиту от перемещения в произвольную точку? И что у вас является нулевой точкой отсчета? Из комментариев к первой статье я понял что вы ориентируетесь глобально. А не думали ореентироваться локально, относительно точки приземления?
Orientation тоже лучше предоставлять в виде ValueObject, как и любой ENUM тип. Это позволит не проверять каждый раз допустимое ли значение указано. Я так подозреваю этим вы и собираетесь заниматься в следующей статье.
Ещё ValueObject-ы типа ENUM можно кешировать если они часто используются
final class Orientation
{
private $instances = [];
private $value = '';
private __constructor(string $value)
{
// Здесь должна быть валидация
$this ->value = $value;
}
// Именованный конструктор
public static function create($value)
{
if (!isset($this->instances[$value]))
{
$this->instances[$value] = new self($value);
}
return $this->instances[$value];
}
//...
}
А еще валидация данных в домене это не очень хорошо. Рекомендую прочитать статью про опыт использования DDD.
Это ладно. Про бекспейс забывают. А еще сталкивался с таким что при вводе 5 числа тебя перекидывают в следующее поле, но указатель ставят перед введеной цифрой нарушая порядок ввода.
одно с традиционным для локали пользователя форматом
В этом отнашении мне нравится как сделанно поле ввода банковской карты в некоторых платежных системах. Поле ввода одно и вводишь как в одно поле, а визуально номер разбивается на 4 части.
А вот 4 отдельных поля ввода с автоматическим переходом не всегда удобны.
Если вы внимательно читале ветку комментариев, то вы вкурсе что мы говорим о том что полльзователю (user) предоставляется парк без дорожек. Он ходет по ней выбирая наиболее удобный для себя путь составляя свой опыт пользования парком (experience). После того как в парке были протоптаны дорожки их заливают в бетон, адаптируя интерфейс парка под нужды пользователей.
не очень понял вопрос.
Значение, для свойства объекта доменной области, может быть перечисление (enum). Для контроля за этим перечислением его удобно описать в виде объекта значения (ValueObject). Получается что-то вроде:
или так
Посмотрел код проекта. Оказалось все еще хуже чем я думал. Список доступных значений для ENUM получается с помощью рефлексии наследующего класса. Метод valueToString вообще мастерский говнокод.
Я ENUM в PHP рассматриваю как ValueObject и отношусь к нему соответствующе. В сущностях храню сам объект, а не его значение, список доступных значений описываю в явном виде и добавляю методы необходимыми для бизнеслогики.
А нам придется перед каждой функцией и константой писать слеш. Этож сколько проектов начнет заваливать логи нотисами, а потом и вовсе упадет. Тогда уж и для функций языка нужно вводить неймспайсы.
Вы похоже перепутали Firebase Realtime Database и Firebase Cloud Messaging.
На официальном сайте Firebase, в разделе цены, вполне четко описано какие услуги платные, а какие нет
push-уведомления относятся к категории бесплатных услуг.
Еще раз. С чего вы решили что уведомления платные?
Как мне уже объяснил iSage и я сам об этом подозревал — это Firebase не может отправлять уведомления, а если реализовывать push-уведомления нативными средствами, то все работает. Что у вас и сделано.
Я вижу что описанного материала многим недостаточно. И хотел бы написать статью/продолжение в которой описать больше технических тонкостей и альтернативных реализаций.
Готов уступить вам эту тему.
push-уведомления через Firebase бесплатные. Не знаю с чего вы взяли что за них нужно платить. Если использовать сторонние сервисы для отправки уведомлений такие как OneSignal и PushAll, то естественно это будет стоит денег, о чем я писал в одном из комментариев.
CDN естественно стоит денег. Если вы разместите статику на своих серверах, то это уже будет не CDN, а если вы начнете строить свою сеть CDN, то это выйдет дороже для большинства проектов.
Ну как сказать не автоматизируется. Уведомления это как email сообщения. Они работают через сторонние сервисы. Вопрос осмысленности такого тестирования я не поднимаю.
Некоторые тестируют отправляемые и доставляемые email сообщения поднимая тестовый SMTP сервер. Так и тут. Никто не мешает, при желании, поднять тестовый Service Worker и тестировать уведомления через него.
Тестировать работу самого Service Worker-а уже сложнее так как он работает вне контекста текущей страницы.
Раз пошла такая тема. Нужно определится на чем написан сайт и бизнес логика проекта. Бизнес логика это самое важное в проекте и она определяет как отреагировать на то или иное событие.
Если проект написан на Go, то логично и уведомления отправлять через Go.
Если проект написан на PHP (как это часто бывает), то можно завести вторую очередь. Первая хранит события, а вторая уже готовые уведомления которые нужно отправить. А вот в качестве транспорта для отправки уведомлений из второй очереди, можно в этом случае использовать микросервисы на Go.
В этом случае мы можем потерять в производительности из-за 2 очередей, но зато логика будет прозрачной.
Надо было так и говорит. "Не используйте cURL." Я вас неправильно понял.
Хорошо. Назовем это так — Библиотека/обертка над нативным интерфейсом. Что в этом плохого?
Согласен, лучше это решать нативными средствами.
Может вы поделитесь с обществом своим опытом в этой сфере?
Отправлять можно откуда угодно, а вот получать уведомления на клиенте без Service Worker нельзя. Уведомления без Service Worker уже не push-уведомления. Это неразделимое целое. Потому я и говорю в статье что push-уведомления это не одна технология, а целый набор.
окей. А теперь представим что у вас 5000 подписчиков. Это значит что страница у вас будет открываться на 5 секунд дольше обычного и пользователи будут отказываться от вашего ресурса из-за ожидания, не смотря на то что вы используете супер продвинутый Go. Поставить же событие в очередь займет милисикунды, а разбирать очередь можете на чем угодно в фоне, хоть на PHP, хоть на Go, хоть на C.
А кто изобретает велосипед? Как раз напротив. Я пытаюсь показать как реализовать уведомления используя стандартные средства (в данном случае средствами представленными Google), не прибегая к сторонним сервисам. Сторонние сервисы плохи тем что:
Внимание вопрос. Зачем платить за то что можно сделать бесплатно? Причем абсолютно легально и стандартизировано.
Я не хочу сказать, что сторонние сервисы это зло. В своем личном, некоммерческом проекте я скорей всего воспользуюсь их услугами. А вот серьезные организации, которым важен престиж и конфиденциальность, такой вариант не рассматривают.
PS: я уже обсуждал тему осмысленности сторонних сервисов для отправки push-уведомлений с автором проекта PushAll BupycNet и не хотел бы возвращаться к этой теме.
Видел и задавался тем же вопросом. В документации не описаны какие либо методы по кастомизации окна. Подозреваю что это делается через какие-то костыли и хуки. Не советую вам это делать. Единообразие интерфейса не есть плохо
Интересно было бы услышать более детально как вы всё реализовали у себя в PushAll
Если значение для сущности не набор, а одна еденица и нужно ей добавить функции или ограничить набор допустимых значений, как в случае ENUM, то можно создать свой тип для маппинга в Doctrine.
Вообще DDD в php лучше реализовывать через Doctrine.
Незачет. Конечно спасибо за проделанную работу. Я как-то не подумал кординаты выносить в ValueObject, но вы его использовали неправильно. В конструкторе нужно передавать не 2 кардинаты, а ValueObject кординат. Тогда можно изменить представление кординат не затрагивая LandRover. Можно добавить ту же ось Z не затрагивая LandRover.
Я не знаю как вы собираетесь реализовывать движение марсохода, но в случае использования ValueObject, вам нужно пересоздавать объект для изменения кординат. Эту задачу можно делегировать объекту Coordinates.
В первой статье вы говорили что марсоход может двигаться на один шаг. Вы собираетесь делать защиту от перемещения в произвольную точку? И что у вас является нулевой точкой отсчета? Из комментариев к первой статье я понял что вы ориентируетесь глобально. А не думали ореентироваться локально, относительно точки приземления?
Orientation тоже лучше предоставлять в виде ValueObject, как и любой ENUM тип. Это позволит не проверять каждый раз допустимое ли значение указано. Я так подозреваю этим вы и собираетесь заниматься в следующей статье.
Ещё ValueObject-ы типа ENUM можно кешировать если они часто используются
А еще валидация данных в домене это не очень хорошо. Рекомендую прочитать статью про опыт использования DDD.
Это ладно. Про бекспейс забывают. А еще сталкивался с таким что при вводе 5 числа тебя перекидывают в следующее поле, но указатель ставят перед введеной цифрой нарушая порядок ввода.
В этом отнашении мне нравится как сделанно поле ввода банковской карты в некоторых платежных системах. Поле ввода одно и вводишь как в одно поле, а визуально номер разбивается на 4 части.
А вот 4 отдельных поля ввода с автоматическим переходом не всегда удобны.
Если вы внимательно читале ветку комментариев, то вы вкурсе что мы говорим о том что полльзователю (user) предоставляется парк без дорожек. Он ходет по ней выбирая наиболее удобный для себя путь составляя свой опыт пользования парком (experience). После того как в парке были протоптаны дорожки их заливают в бетон, адаптируя интерфейс парка под нужды пользователей.
Так я об этом и говорю. Интерфейс должен бодстраиваться под пользователя (модель поведения), а не пользователь под интерфейс