Это дело вкуса, я думаю. Очевидно же, что язык, на котором говорят люди в стране, нельзя поменять методом в ООП :)
Насчет второго замечания — это и так возможно: Geographer::setLanguage('ru')
Так как это singleton во фреймворках (Laravel и др), то изменение настроек отразится на всех последующих вызовах
Я еще подумаю насчет language vs locale, спасибо за мысль!
Подозреваю, что это настолько массивная задача, что должна быть Git под-модулем. Вообще, всё, что не глобальное — должно быть опциональным, а не входить в основной пакет
Вспомнил — у меня тесты все в Travis запускаются. И изначально там 5.5 стояло в том числе — оно фейлилось как раз. Сейчас верну в Travis 5.5 и увижу :)
Все равно будет один минус упомянутый выше – команда будет работать на всех instances.
Еще, совсем забыл упомянуть в статье, я использую Docker-вариант Elastic Beanstalk, потому что 1) у Amazon до сих пор нет PHP 7 2) Docker – это удобно.
И тут, насколько я понимаю, .ebextensions сразу отпадает – это команды, которые будут в host OS запускаться, а не в контейнере. Можно, конечно, в Dockerfile установить supervisor, но будет проблема из первого предложения :)
При работе с планировщиком через очереди, как предложено в статье, неудачные задачи будут корректно в Dead Messages очередь перемещены, и не важно сколько в EB инстансов, 1 или 500, каждая задача будет выполнена один раз.
Нет, ничего не перепутал :) Просто эти две функции, как правило, вынесены на worker instances. Поэтому я показал как обе функции развернуть в Elastic Beanstalk.
php artisan queue:listen действительно запускает бесконечный цикл, но как Вы запустите его из worker, без доступа к консоли, supervisor или cron tab?
AWS не хочет, чтобы разработчики на worker работали «напрямую» с очередями.
А Вы обратите внимание на постскриптум в Вашей же ссылке:
Update: There is an issue with this solution when Elastic Beanstalk scales up your instances. For example, lets say you have one instance with the cron job running. You get an increase in traffic so Elastic Beanstalk scales you up to two instances. The leader_only will ensure you only have one cron job running between the two instances. Your traffic decreases and Elastic Beanstalk scales you down to one instance. But instead of terminating the second instance, Elastic Beanstalk terminates the first instance that was the leader. You now don't have any cron jobs running since they were only running on the first instance that was terminated. See the comments below.)
Если этого недостаточно, напомню еще про несимметричную нагрузку в таком сценарии – один instance будет всегда иметь больше нагрузки, чем другие. Кроме того, неработающий скрипт, я предполагаю, не будет показан в health-статусе приложения, а вот если перестанет работать веб-хук, то будет HTTP ошибка и разработчик заметит это по статусу.
Laravel нормально дружит если Вы его запустите, скажем, в EC2. Проблемы начинаются, когда среда приложения – Elastic Beanstalk. В таком случае, Laravel вообще никак не готов, и уже много месяцев на Laracasts пользователи ищут решение :)
В Elastic Beanstalk нельзя (точнее, от Вас этого не ожидается) запускать дополнительные демоны.
1) Сами данные будут подгружаться в режиме ленивой загрузи
2) Если базы станут большими, я думаю детализированные базы по странам можно будет выделить в отдельные репозитории. Тогда в начале разработчику просто 2+ пакета надо будет устанавливать — основной и необходимая база, набор языков
Посмотрел только что — мне кажется это больше в сторону трансляции координат в адрес и наоборот, не увидел ничего про локализацию там (а у меня это основная цель).
Спасибо — посмотрел и то, и другое. Но, IMHO, не хватает падежей (хотя это, конечно, только для русского языка актуально) и возможности выбрать менее формальное название. Причем, они это никогда не добавят, потому что в рамках их библиотек это лишнее.
Если сайт на, скажем, английском, и нужен просто список стран — то можно intl использовать.
А вот что реально было бы хорошо иметь, это разные источники данных, база/файлы/пусть даже интернет. Плюс сделать возможность кеширования тех данных что ты вытаскиваешь.
Про это я уже думаю :)
Поиск по координатам, как я понял устроен топорно и просто сравнивает значения? Это плохо. В некоторых базах есть возможность искать координату приблизительно, да и алгоритмы для поиска есть. Это конечно в пределах пхп работать будет не очень быстро, но хотя бы честно.
Поиска пока нет вообще – он просто показан в примере. В современных БД есть гео-индексы. Как поступить тут и сохранить при этом маленький размер – я ещё думаю.
Вещи типа useShortNames не совсем понимаю зачем? Если можно возвращать в том же массиве оба варианта. Метод inflict мне тоже не понятен, почему это должна делать библиотека, которая используется как база данных?
Сначала так и было – два варианта. Ход мыслей дальше был такой: длинный (полный) вариант есть всегда, короткий иногда. Если возвращать оба поля и одно из них может быть пустым – разработчику придется на своей стороне (приложения) делать условия, а условия уже давно никто не любит.
То есть, если я могу попросить useShortNames(), то после этого я могу просто отображать одно поле, а пакет его выбирает по принципу best effort (старались как могли).
Inflict() – потому что больше половины сайтов до сих пор не умеют правильно склонять слова русского языка. Скажем, у нас есть какая-то лента или стена, и там есть подписи вроде: «Написал Иван 5 минут назад из Владивостока». Где хранить правильную форму имени города?
В общем, проще засунуть эти данные в монгу, взять какой-нибудь ODM, и будет так же хорошо, и даже намного лучше, ибо сложные запросы, поиск по координатам и т.д.
Так все и делают, включая меня – и это занимает много времени, требует установки дополнительных сервисов и так далее. Было бы очень классно иметь легкую, независимую (от внешних демонов) библиотеку, которая покрывает хотя бы все базовые требования.
Да, я уже понял ошибку — неудачно выбрано название.
Как минимум, в примере надо сделать имя переменной $earth, чтобы логика соблюдалась :) И объявить, что другие планеты создавать (как перевести instantiate?) пока нельзя
Насчет интерфейсов — я пока склоняюсь (на GitHub код уже видно) к абстрактному классу для всех видов делений вместо интерфейсов для разных уровней делений. Есть класс Divisible (делимый), и пока что логика планеты, стран и штатов почти полностью совпадает — это решение пока похоже на оптимальное.
Если мой пакет будет полезен даже для 50% приложений – это уже будет прекрасный результат.
А использование собственной разработки или доработки, когда общедоступные реализации немного не подходят – это совершенно нормальное явление, его мы наблюдаем ежедневно. Всем не угодить, задача угодить многим :)
Про оспариваемые территории я пока еще думаю над решением :)
Насчет второго замечания — это и так возможно: Geographer::setLanguage('ru')
Так как это singleton во фреймворках (Laravel и др), то изменение настроек отразится на всех последующих вызовах
Я еще подумаю насчет language vs locale, спасибо за мысль!
Теперь проходят тесты на 5.5
В общем, я уже закомиттил и пометил
Про Laravel/Lumen — да, вероятно вы правы. Кроме того, там настолько простая интеграция — её чуть ли не проще в документации описать :)
Еще, совсем забыл упомянуть в статье, я использую Docker-вариант Elastic Beanstalk, потому что 1) у Amazon до сих пор нет PHP 7 2) Docker – это удобно.
И тут, насколько я понимаю, .ebextensions сразу отпадает – это команды, которые будут в host OS запускаться, а не в контейнере. Можно, конечно, в Dockerfile установить supervisor, но будет проблема из первого предложения :)
При работе с планировщиком через очереди, как предложено в статье, неудачные задачи будут корректно в Dead Messages очередь перемещены, и не важно сколько в EB инстансов, 1 или 500, каждая задача будет выполнена один раз.
php artisan queue:listen действительно запускает бесконечный цикл, но как Вы запустите его из worker, без доступа к консоли, supervisor или cron tab?
AWS не хочет, чтобы разработчики на worker работали «напрямую» с очередями.
В среде EB такой стандартный способ не работает
Update: There is an issue with this solution when Elastic Beanstalk scales up your instances. For example, lets say you have one instance with the cron job running. You get an increase in traffic so Elastic Beanstalk scales you up to two instances. The leader_only will ensure you only have one cron job running between the two instances. Your traffic decreases and Elastic Beanstalk scales you down to one instance. But instead of terminating the second instance, Elastic Beanstalk terminates the first instance that was the leader. You now don't have any cron jobs running since they were only running on the first instance that was terminated. See the comments below.)
Если этого недостаточно, напомню еще про несимметричную нагрузку в таком сценарии – один instance будет всегда иметь больше нагрузки, чем другие. Кроме того, неработающий скрипт, я предполагаю, не будет показан в health-статусе приложения, а вот если перестанет работать веб-хук, то будет HTTP ошибка и разработчик заметит это по статусу.
В Elastic Beanstalk нельзя (точнее, от Вас этого не ожидается) запускать дополнительные демоны.
1) Сами данные будут подгружаться в режиме ленивой загрузи
2) Если базы станут большими, я думаю детализированные базы по странам можно будет выделить в отдельные репозитории. Тогда в начале разработчику просто 2+ пакета надо будет устанавливать — основной и необходимая база, набор языков
Если сайт на, скажем, английском, и нужен просто список стран — то можно intl использовать.
Про это я уже думаю :)
Поиска пока нет вообще – он просто показан в примере. В современных БД есть гео-индексы. Как поступить тут и сохранить при этом маленький размер – я ещё думаю.
Сначала так и было – два варианта. Ход мыслей дальше был такой: длинный (полный) вариант есть всегда, короткий иногда. Если возвращать оба поля и одно из них может быть пустым – разработчику придется на своей стороне (приложения) делать условия, а условия уже давно никто не любит.
То есть, если я могу попросить useShortNames(), то после этого я могу просто отображать одно поле, а пакет его выбирает по принципу best effort (старались как могли).
Inflict() – потому что больше половины сайтов до сих пор не умеют правильно склонять слова русского языка. Скажем, у нас есть какая-то лента или стена, и там есть подписи вроде: «Написал Иван 5 минут назад из Владивостока». Где хранить правильную форму имени города?
Так все и делают, включая меня – и это занимает много времени, требует установки дополнительных сервисов и так далее. Было бы очень классно иметь легкую, независимую (от внешних демонов) библиотеку, которая покрывает хотя бы все базовые требования.
Как минимум, в примере надо сделать имя переменной $earth, чтобы логика соблюдалась :) И объявить, что другие планеты создавать (как перевести instantiate?) пока нельзя
Насчет интерфейсов — я пока склоняюсь (на GitHub код уже видно) к абстрактному классу для всех видов делений вместо интерфейсов для разных уровней делений. Есть класс Divisible (делимый), и пока что логика планеты, стран и штатов почти полностью совпадает — это решение пока похоже на оптимальное.
Если мой пакет будет полезен даже для 50% приложений – это уже будет прекрасный результат.
А использование собственной разработки или доработки, когда общедоступные реализации немного не подходят – это совершенно нормальное явление, его мы наблюдаем ежедневно. Всем не угодить, задача угодить многим :)
Про оспариваемые территории я пока еще думаю над решением :)