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). После того как в парке были протоптаны дорожки их заливают в бетон, адаптируя интерфейс парка под нужды пользователей.
Вы путаетесь немного. Вы говорите о вводе даты дня рождения и хотите описать его 3мя полями. 3 поля это только интерфейс для ввода одной, единой сущности — день рождения.
Правильней использовать календарь для выбора даты;
Если вам так хочется использовать 3 отдельных поля то вы должны свернуть их в единое целое в контроллере перед началом валидации. Обычно этим занимаются компоненты форм;
Валидировать вам всё равно нужно конечную дату в целом, а не её части и выводить вам нужно сообщение об ошибке для всей даты.
Пример:
2017-04-31 — в апреле 30 дней;
2017-02-29 — не високостный год;
123-13-44 — не валидная дата впринципе. Нет смысла выводить сообщения об ошибке для каждой части даты;
3000-01-01 — день рождения не может быть в будущем.
Ну почему же. Там не всегла все строго логично, люди не только короткий путь выбирают, дорожки бывают замысловатые. Что же это, если не UX?
Так я и не говорю что получившиеся дорожки логичны, хотя логика в них прослеживается. Я говорю что это UX по отношению к парку, а не к дорожкам. После того как UX парка сформировался, мы подстраиваем интерфейс (дорожки) под требования пользователей. Это совсем другая история.
Если мы сами проложим дорожки как мы считаем правильным, то люди будут ходить по ним, не смотря на то что им не удобно. Это и будет UX по отношению к дорожкам. Это именно то что получилось с ссылкой на логотипе. Пользователи подстроились под новые веяния дизайнеров, а того ли они хотели?
Как раз английские дорожки это скорее пример логичности, а не user experience. User experience говорит о том что пользователи подстраиваются под существующие реали, а не интерфейс подстраивается под требования пользователя.
Пользователи научились переходить на главную по логотипу потому что "умные" дизайнеры решили что ссылка "Гланая" пользователям не нужна.
Я не говорю что это плохо. Просто надо понимать от куда ноги ростут прежде чем продвигать эту идею.
DTO это про передачу данных. Я DTO рассматриваю как средство общения доменного слоя и слоя имплементации. Возможно я черезчур связываю DTO и слой реализации и в результате доменный слой оказывается зависимым от слоя реализации через DTO.
К сожалению, я не нашёл другого способа защетить доменный слой от использования его вне бизнесс процессов.
Надо было так и говорит. "Не используйте 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). После того как в парке были протоптаны дорожки их заливают в бетон, адаптируя интерфейс парка под нужды пользователей.
Так я об этом и говорю. Интерфейс должен бодстраиваться под пользователя (модель поведения), а не пользователь под интерфейс
Согласен. Хотя есть календари которые позволяют быстро пролистывать года.
Вы путаетесь немного. Вы говорите о вводе даты дня рождения и хотите описать его 3мя полями. 3 поля это только интерфейс для ввода одной, единой сущности — день рождения.
Пример:
2017-04-31— в апреле 30 дней;2017-02-29— не високостный год;123-13-44— не валидная дата впринципе. Нет смысла выводить сообщения об ошибке для каждой части даты;3000-01-01— день рождения не может быть в будущем.RegisterEnglishCardCommand и RegisterChinaCardCommand не?
Так я и не говорю что получившиеся дорожки логичны, хотя логика в них прослеживается. Я говорю что это UX по отношению к парку, а не к дорожкам. После того как UX парка сформировался, мы подстраиваем интерфейс (дорожки) под требования пользователей. Это совсем другая история.
Если мы сами проложим дорожки как мы считаем правильным, то люди будут ходить по ним, не смотря на то что им не удобно. Это и будет UX по отношению к дорожкам. Это именно то что получилось с ссылкой на логотипе. Пользователи подстроились под новые веяния дизайнеров, а того ли они хотели?
Как раз английские дорожки это скорее пример логичности, а не user experience. User experience говорит о том что пользователи подстраиваются под существующие реали, а не интерфейс подстраивается под требования пользователя.
Пользователи научились переходить на главную по логотипу потому что "умные" дизайнеры решили что ссылка "Гланая" пользователям не нужна.
Я не говорю что это плохо. Просто надо понимать от куда ноги ростут прежде чем продвигать эту идею.
Тут надо понимать что переход на главную по щелчку на логотип это user experience, а не логичное поведение. Это не одно и тоже.
DTO это про передачу данных. Я DTO рассматриваю как средство общения доменного слоя и слоя имплементации. Возможно я черезчур связываю DTO и слой реализации и в результате доменный слой оказывается зависимым от слоя реализации через DTO.
К сожалению, я не нашёл другого способа защетить доменный слой от использования его вне бизнесс процессов.
Еще один аргумент в пользу использования геттеров и сеттеров в DTO
Спасибо за замечание.
Поспешил я, RFC не приняли.
Я пока еще на 5.6 и путаюсь еще в нововведениях 7.x