Docker невозможно установить на VPS поднятом на OpenVZ если ядро linux ниже минимальной версии требуемой докером. У меня вот весьма хороший тариф на VPS, но докер я юзать не могу из-за этого ограничения, а платить в 2 раза дороже за аналогичную конфигурацию с SSD на борту вместо HDD как-то не хочется.
Т.е. не каждый VPS поддерживает докер. В итоге получаем неработающую «серебряную пулю».
Сейчас век интернета. Кроме игр на винтах ничего уже не хранится. Фильмы/сериалы и прочее смотрится онлайн и не требует места на диске (temp много не занимает). Для обычного юзера, на которого вроде бы ориентируется оптан, ssd на 512гб — за глаза и за уши. Я еще ни разу за пару последних лет не слышал чтобы кому-то, кто заменил свой hdd на ssd, не хватало места (а там даже 256гб у многих). Для более требовательных пользователей — hdd + ssd не проблема ибо они понимают зачем им нужно столько места и как его использовать. Я маму за 5 минут научил скидывать все скачиваемые файлы на 2й винт, который тупо назвал Media. Даже самые отсталые пользователи это смогут, если им 1 раз объяснить. Да и настроить скачки из браузера/торрента в одну папку может практически любой школьник.
В общем и целом — целевая аудитория оптана не нуждается в нем. Смысла нет — один маркетинг (надо же как-то продавать процы последних поколений и дорогие мамки к ним). Я вот на core i7 2nd gen сижу уже много лет и не вижу смысла его менять — он даже на 80% не напрягается для моих нужд. Видимо многие примерно так же думают и не торопятся скупать новые процессоры, вот им и пытаются впарить ненужные апгрейды такими вот «сверхбыстрыми», но по сути бесполезными в данный момент технологиями.
Тут больше зависит от того имеют ли разные плашки разный размер или соотношение сторон и насколько сильно отличаются шрифты. Может быть еще слишком темный фон может мешать, не тестировал такие варианты. Все остальные украшательства не сильно влияют на распознавание. Самой значительной помехой становится кусок номера аналогичный российскому региону. Вот тут openalpr начинает косячить по-страшному и частенько обрезает регион. К тому же символы региона на российских номерах меньше чем на основном номере что превращает распознавание в откровенную угадайку =(
В остальном openalpr уверенно распознает многие варианты без допиливания напильником.
В openalpr на сколько помню есть из коробки обученная сетка для распознавания австралийских номеров (либо номера / шрифт у них совпадают с США который используется по умолчанию). Так что не удивительно что распознает оно достаточно хорошо.
А вот настраивать openalpr под русские номера — это дикая боль =(
Понятно.
Я правильно понимаю что даже если вручную выполнить запрос SET SESSION TIME ZONE, то зона будет не той, которая задана? Или тут просто проблема в том, что при стандартном поведении системы драйвер для postgresql отрабатывает неправильно и требуется дополнительный код чтобы это исправить?
Установка правильной тайм-зоны в моем понимании не является задачей драйвера и делать свой драйвер только ради этого немного перебор.
Для некоторых Питерских музеев уже есть приложение с навигацией и экскурсиями на основе bluetooth маячков — IndoorGuide называется. Довольно хорошо работает, надо сказать.
3000р в стиме не просят даже AAA проекты. Тем более за пролог. Тем более за Early Access.
Конечная игра, вероятно, и будет стоить столько, но в данной ситуации с теми отзывами, вы не продадите ее за эту цену как бы вам этого не хотелось. По сути вы продаете кота в мешке. Меня игра заинтересовала и я бы ее купил если бы она не стоила так дорого на столь раннем этапе.
Вам стоило бы сделать ее эпизодической — взять тот же Hitman, Life is Strange и еще много игр, которые использовали такой способ и вышли весьма успешными. Сейчас же вы рискуете недополучить необходимое для дальнейшей разработки финансирование.
На мой взгляд от этого легче не становится. Ошибки есть, они не исправлены. Заставлять читателя думать там, где это необязательно, не всегда уместно. Я вот зашел почитать как другой человек работает с событиями и для чего их использует.
Кстати, не вижу особого смысла использовать для этой задачи события. Этим вы только усложняете понимание происходящего т.к. вызов события никак не передает суть того, что оно будет делать. К тому же это событие всегда вызывается из одного и того же места и имеет один обработчик (даже если их будет и несколько, то все равно смысла мало).
Что мешает сделать вот так?
protected function onBeforeSave()
{
//Мы проверяем статус статьи – если он «Опубликован», смотрим на статус оповещения, если он еще не «Опубликован»
if ($this->status == self::STATUS_PUBLISHED
&& $this->notify_status < self::STATUS_PUBLISHED){
//то устанавливаемый статус оповещения в «опубикован»
$this->notify_status = self::STATUS_PUBLISHED;
//и «выстреливаем» событие PostPublishedEvent, передавая в него собственный инстанс.
(new OneSignalHandler())->sendNotify($event->post);
}
}
И при необходимости добавлять сюда действия другого типа одной строчкой.
Ведь подумайте — onBeforeSave() — это по сути обработчик события (префикс "on" на это толсто намекает). А вы пихаете вызов другого события внутрь обработчика события. Жуть просто.
А теперь давайте рассмотрим почему мой вариант лучше на примере того как человек читает код.
Ваш вариант глазами другого человека, который знает Laravel:
Заходим в модель, видим onBeforeSave
Смотрим что метод делает:
2.1. Проверка статусов поста и нотификации (А предполагается ли такая ситуация что пост был изменен после публикации и рассылки?)
2.2. Устанавливаем новый статус нотификации (стоп! какого? мы ж ничего не сделали!)
2.3. Отправляем событие PostPublishedEvent
Так. А что делает это событие и где?
3.1. Открываем класс события (ну как обычно — ctrl+click, привыкли уже). Хм… В нем нет никакой инфы о его деятельности.
3.2. Ааа! Точно! У него ж должен быть listener. Таак и где среди этой сотни обработчиков нужный нам (я это к тому что с таким подходом в более-менее большом проекте обработчиков будет навалом)?
3.3. Нашли! Ура! Итак, наконец-то я узнаю что он делает! (new OneSignalHandler())->sendNotify($event->post);
3.4. Что????? И это все???? И я перелопатил хренову тучу классов/файлов ради этого????
Я утрирую, дальше ведь там будут еще другие действия, но все-равно путь длинноват.
Так… А с чем я там вообще изначально разбирался и где? (потеря концентрации и времени)
Мой вариант:
Заходим в модель, видим onBeforeSave
Смотрим что метод делает:
2.1. Проверка статусов поста и нотификации (А предполагается ли такая ситуация что пост был изменен после публикации и рассылки?)
2.2. Устанавливаем новый статус нотификации (стоп! какого? мы ж ничего не сделали!)
2.3. Отправляем нотификацию через OneSignalHandler (опа! да тут же косяк! статус меняется независимо от того отправилась нотификация или, да еще и отправка происходит до сохранения данных, что вообще-то совершенно неправильно — вдруг не сохраниться?)
Всё понятно. Потенциальный баг найден и будет исправлен.
Надеюсь, вы понимаете что излишнее усложнение ради мнимого удобства приводят к тому что вы не найдете очевидных багов в самых простых местах пока эти баги не вылезут во всей красе. А если проект будет поддерживать другой человек?
События — хорошая штука, но применять их нужно не бездумно везде где захочется — будет только хуже.
Я пока нашел всего 1 применение для очень специфического случая, где без них был бы полнейший кошмар. Больше нигде не применял — не нашлось места. Знаю только что они применяются в коде Laravel, и там это обосновано — не нужно делать 100500 методов onSomeAction(). События удобны для библиотек, когда неизвестно какие действия захочет выполнить использующий либу программист.
Еще:
Почему бы не сделать OneSignalHandler статическим классом? По сути он не хранит состояния. Его задаче — предоставить обертку для отправки пуша. Тестовую отправку можно сделать через аргумент метода sendNotify, хранить этот флаг не вижу смысла. Если же нужно глобально включать/выключать тестовую отправку — это можно организовать через поле static public $testMode или через setter для него.
Разберитесь с очередью (queue) — она для данной задачи необходима намного больше чем событие т.к. значительно увеличит скорость обработки процесса публикации поста (естественно, если будет выполняться в фоне)
Вот не стоит так делать в этом случае. Одно дело — когда в одной статье рассматривается и проблема и ее решение, а совсем другое, когда в 1й статье умышленно делается ошибки/недочет, которые исправляются в другой статье. К моменту выхода 2й статьи уже будет поздно что-либо исправлять, а многие ее и не прочитают, особенно если найдут такие ляпы.
Не думаю что это нужно делать для каждого сайта. Достаточно собрать базу ключевых слов для фильтрации. А потом все запросы с get/post параметрами фильтровать на предмет хаков.
За 1-2 недели их можно насобирать достаточно чтобы обнаружить общие шаблоны и ключевые слова по которым вся эта гадость в последствии фильтруется. Если сайт не связан с программированием, то работает такой фильтр на ура. Производительность при этом просаживается незначительно.
Попробовал, обнаружил что нет нужного мне функционала, отложил до следующей версии.
Чего не хватает:
1. (критично) Нет triggers
2. (отчасти критично) Нет rules, checks для postgresql
3. (не критично) Нет types и operators, непонятно есть ли materialized views (для того же postgresql)
Без 1 вообще очень грустно. Да и без 2 тоже сложно обойтись.
404 на почту грозит вам по несколько сотен (а то и тысяч) писем в день (и это если проект не особо популярный). Большая часть из них — попытки найти дырку в сайте, админку или еще чего. Лучше вести логи фильтруя случайные и специальные ошибки. А потом просматривать это все дело на предмет интересных решений. У меня уже довольно большая коллекция попыток взлома насобиралась.
ALTER TABLE вообще-то имеет кучу разных возможностей, которые нацелены в том числе на расширение существующего функционала, а не только на изменение. Кстати, на эту тему — колонку из varchar в int в postgresql переделать нельзя. Тут тот же принцип: накосячил — страдай.
Давайте на пальцах прикинем частоту использования этих конструкций и их альтернативы:
1. ALTER DATABASE databasename CHARACTER SET enc COLLATE collation — 0.01% (хотя меньше). Для этой задачи есть альтернативный способ решения без потери данных. Трудоемкость способа небольшая — около 4х команд (дамп, удаление бд, создание новой, восстановление из дампа), хотя затраченное время сильно зависит от объема БД. Вероятно, реализация этой команды будет затрачивать аналогичное количество времени.
2. ALTER TABLE table и т.д. — 99.99%. Альтернативный способ слишком трудоемкий для задачи, которая так часто используется.
Вывод: ALTER DATABASE databasename CHARACTER SET enc COLLATE collation — очень редко используемый функционал, требующий довольно сложной реализации (если бы было все так просто — давно бы уже сделали, не из вредности же разработчики не делают его).
Приговор: нет смысла тратить время на его реализацию.
Так оно и есть. Из коробки только английский работал хорошо и без осечек.
Внешнее решение наверняка будет уступать разве что по скорости, зато его намного проще и быстрее поднять. Вот если бы sphinx еще поддерживал нотификации postgresql (NOTIFY) — было бы вообще прекрасно =)
Т.е. не каждый VPS поддерживает докер. В итоге получаем неработающую «серебряную пулю».
В общем и целом — целевая аудитория оптана не нуждается в нем. Смысла нет — один маркетинг (надо же как-то продавать процы последних поколений и дорогие мамки к ним). Я вот на core i7 2nd gen сижу уже много лет и не вижу смысла его менять — он даже на 80% не напрягается для моих нужд. Видимо многие примерно так же думают и не торопятся скупать новые процессоры, вот им и пытаются впарить ненужные апгрейды такими вот «сверхбыстрыми», но по сути бесполезными в данный момент технологиями.
В остальном openalpr уверенно распознает многие варианты без допиливания напильником.
А вот настраивать openalpr под русские номера — это дикая боль =(
Я правильно понимаю что даже если вручную выполнить запрос SET SESSION TIME ZONE, то зона будет не той, которая задана? Или тут просто проблема в том, что при стандартном поведении системы драйвер для postgresql отрабатывает неправильно и требуется дополнительный код чтобы это исправить?
Установка правильной тайм-зоны в моем понимании не является задачей драйвера и делать свой драйвер только ради этого немного перебор.
Так сложно хранить DateTime и timestamp в timestamp with tz и при коннекте к postgresql выполнять запрос SET SESSION TIME ZONE 'Europe/Moscow'?
Конечная игра, вероятно, и будет стоить столько, но в данной ситуации с теми отзывами, вы не продадите ее за эту цену как бы вам этого не хотелось. По сути вы продаете кота в мешке. Меня игра заинтересовала и я бы ее купил если бы она не стоила так дорого на столь раннем этапе.
Вам стоило бы сделать ее эпизодической — взять тот же Hitman, Life is Strange и еще много игр, которые использовали такой способ и вышли весьма успешными. Сейчас же вы рискуете недополучить необходимое для дальнейшей разработки финансирование.
Кстати, не вижу особого смысла использовать для этой задачи события. Этим вы только усложняете понимание происходящего т.к. вызов события никак не передает суть того, что оно будет делать. К тому же это событие всегда вызывается из одного и того же места и имеет один обработчик (даже если их будет и несколько, то все равно смысла мало).
Что мешает сделать вот так?
И при необходимости добавлять сюда действия другого типа одной строчкой.
Ведь подумайте — onBeforeSave() — это по сути обработчик события (префикс "on" на это толсто намекает). А вы пихаете вызов другого события внутрь обработчика события. Жуть просто.
А теперь давайте рассмотрим почему мой вариант лучше на примере того как человек читает код.
Ваш вариант глазами другого человека, который знает Laravel:
2.1. Проверка статусов поста и нотификации (А предполагается ли такая ситуация что пост был изменен после публикации и рассылки?)
2.2. Устанавливаем новый статус нотификации (стоп! какого? мы ж ничего не сделали!)
2.3. Отправляем событие PostPublishedEvent
3.1. Открываем класс события (ну как обычно — ctrl+click, привыкли уже). Хм… В нем нет никакой инфы о его деятельности.
3.2. Ааа! Точно! У него ж должен быть listener. Таак и где среди этой сотни обработчиков нужный нам (я это к тому что с таким подходом в более-менее большом проекте обработчиков будет навалом)?
3.3. Нашли! Ура! Итак, наконец-то я узнаю что он делает! (new OneSignalHandler())->sendNotify($event->post);
3.4. Что????? И это все???? И я перелопатил хренову тучу классов/файлов ради этого????
Я утрирую, дальше ведь там будут еще другие действия, но все-равно путь длинноват.
Мой вариант:
2.1. Проверка статусов поста и нотификации (А предполагается ли такая ситуация что пост был изменен после публикации и рассылки?)
2.2. Устанавливаем новый статус нотификации (стоп! какого? мы ж ничего не сделали!)
2.3. Отправляем нотификацию через OneSignalHandler (опа! да тут же косяк! статус меняется независимо от того отправилась нотификация или, да еще и отправка происходит до сохранения данных, что вообще-то совершенно неправильно — вдруг не сохраниться?)
Надеюсь, вы понимаете что излишнее усложнение ради мнимого удобства приводят к тому что вы не найдете очевидных багов в самых простых местах пока эти баги не вылезут во всей красе. А если проект будет поддерживать другой человек?
События — хорошая штука, но применять их нужно не бездумно везде где захочется — будет только хуже.
Я пока нашел всего 1 применение для очень специфического случая, где без них был бы полнейший кошмар. Больше нигде не применял — не нашлось места. Знаю только что они применяются в коде Laravel, и там это обосновано — не нужно делать 100500 методов onSomeAction(). События удобны для библиотек, когда неизвестно какие действия захочет выполнить использующий либу программист.
Еще:
За 1-2 недели их можно насобирать достаточно чтобы обнаружить общие шаблоны и ключевые слова по которым вся эта гадость в последствии фильтруется. Если сайт не связан с программированием, то работает такой фильтр на ура. Производительность при этом просаживается незначительно.
Чего не хватает:
1. (критично) Нет triggers
2. (отчасти критично) Нет rules, checks для postgresql
3. (не критично) Нет types и operators, непонятно есть ли materialized views (для того же postgresql)
Без 1 вообще очень грустно. Да и без 2 тоже сложно обойтись.
Давайте на пальцах прикинем частоту использования этих конструкций и их альтернативы:
1. ALTER DATABASE databasename CHARACTER SET enc COLLATE collation — 0.01% (хотя меньше). Для этой задачи есть альтернативный способ решения без потери данных. Трудоемкость способа небольшая — около 4х команд (дамп, удаление бд, создание новой, восстановление из дампа), хотя затраченное время сильно зависит от объема БД. Вероятно, реализация этой команды будет затрачивать аналогичное количество времени.
2. ALTER TABLE table и т.д. — 99.99%. Альтернативный способ слишком трудоемкий для задачи, которая так часто используется.
Вывод: ALTER DATABASE databasename CHARACTER SET enc COLLATE collation — очень редко используемый функционал, требующий довольно сложной реализации (если бы было все так просто — давно бы уже сделали, не из вредности же разработчики не делают его).
Приговор: нет смысла тратить время на его реализацию.
Так понятнее моя точка зрения?
Внешнее решение наверняка будет уступать разве что по скорости, зато его намного проще и быстрее поднять. Вот если бы sphinx еще поддерживал нотификации postgresql (NOTIFY) — было бы вообще прекрасно =)