Вот эту строчку подредактируйте пожалуйста: ssh -T postgres$NEW_MASTER touch $TRIGGER_FILE, вместо неё надо ssh -T postgres@$NEW_MASTER touch $TRIGGER_FILE, без @ он ругается:(
Ну с дизайном то понятно, как раз появится финансирование на дизайнера, если конечно достаточно продонатят, кстати можно было бы сделать как на кикстартере если собирается больше определенной суммы, то фичу можно сделать…
Очень интересная Orm, а вот если предположить, что у нас не цветок, как уникальная единица, а тип цветка с множеством свойств, тогда на уровне БД нам понадобится связь многие-ко-многим, по сути нужна таблица связки, и вопрос в том, сколько потребуется orm запросов, чтобы вывести все цветочки у какой либо феи, ну и наоборот у цветочка, посмотреть, каким феям он интересен, тоже один?
ну это форк, а не официальная версия, но в принципе они делают переупаковку, как я понимаю официальной версии, чтобы можно было, как раз использовать rebar. Спасибо, теперь жизнь станет проще!
Знаю о нем, но там кроме как распарсить html, нужно было регулярками пройтись и вырезать определенные кусочки, при разных условий, и использовать для этого erlang у меня не хватило времени.
Но это выдаст ошибку
Cloning into 'rabbitmq_erlang_client'…
ERROR: Dependency dir 1/deps/rabbitmq_erlang_client failed application validation with reason:
{missing_app_file,«1/deps/rabbitmq_erlang_client»}.
Как я понял на гите в папке src нет ни одного файла с расширением *.app.src. И собственно он конечно загрузит rabbit_common и даже rabbitmq_erlang_client, но далее не продвинется. И единственное решение, которое мне пришло это просто установить все, как написано в официальной инструкции www.rabbitmq.com/build-erlang-client.html. Если вы знаете, как это сделать через rebar, поделитесь.
Честно говоря, не хотел грузить особенно описанием задачи, и последовательностью принятия тех или иных решений. Возможно в следующей статье буду использовать спойлер с максимально, на сколько это возможно, детальным описанием проекта в целом.
Была идея написать сначала на нем, чтоб вообще не париться, но через некоторое время, начинала течь память, да конечно оптимизировать и так далее, но все равно, php не очень хорошо для этого. Была статья habrahabr.ru/post/179399/, очень подробно расписывается данная проблема.
А вот почему Erlang, а не java например, вот это интересный вопрос :) Я конечно могу вам сказать, что в subscribe на Erlange сразу вызывается swapn для дальнейшей обработки, и таким образом скорость достаточно приличная получается…
Но в целом, вопрос религиозный, можно было и на чем то другом написать, ради разнообразия, да и сравнить консюмеры на разных языках, какой будет лучше справляться…
Вы должны понимать, при такой архитектуре, я могу менять любой из этих модулей.
И один из бонусов, отказ 90% серверов с демонами Erlanga, повлияет в плане снижения скорости, но не более… RabbitMQ не дождется подтверждения, отправит задачи на другой сервер. Поверьте решения принимаются не просто так.
В простейшем случае, это выглядит вот так "
Плюс дополнительно есть например очереди удаления пользователей, обработка которой полностью проходит без участия php, и другие…
Ну да, его для этого создавали вообще-то, в основном php мне нужен был по той причине, что приложение клиентов добавляла задачи используя rest. Плюс я для обработки, а точнее для для распаривания html страниц, так как erlang не очень хорошо умеет работать с текстом, а там достаточно сложная модель. По сути обработчик или говорил все ок, пользователь нечего не поменял, отправляй меня в конец очереди, или изменились данные и нужно сделать ещё 5-10 запросов к источнику информации, чтобы определить изменившиеся данные, ну и уведомление пользователю заодно посылает.
Сама идея использование Rest, в будущем позволит изменить обработчик, сделать его более эффективным, написать на любом языке.
Просто хранить очередь в файле, как это делает кролик, не очень продуктивно — могу ошибаться, но FIFO в примитивном описании работает, как запись в начало файла, считывание с конца и все. А СУБД, в частности Mysql -> InnoDB например в конечном итоге записывает все в один файл, но тут мы тратимся дополнительно на саму прослойку взаимосвязи с СУБД.
Gearman предоставляет чуть больше возможностей — это да, реализовывать отложенные задачи на RabbitMQ приходится, немного костыльным способом.
Как я понимаю вы предлагаете что-то типо вот этого
Но это выдаст ошибку
Cloning into 'rabbitmq_erlang_client'…
ERROR: Dependency dir 1/deps/rabbitmq_erlang_client failed application validation with reason:
{missing_app_file,«1/deps/rabbitmq_erlang_client»}.
Как я понял на гите в папке src нет ни одного файла с расширением *.app.src. И собственно он конечно загрузит rabbit_common и даже rabbitmq_erlang_client, но далее не продвинется. И единственное решение, которое мне пришло это просто установить все, как написано в официальной инструкции www.rabbitmq.com/build-erlang-client.html. Если вы знаете, как это сделать через rebar, поделитесь.
А вот почему Erlang, а не java например, вот это интересный вопрос :) Я конечно могу вам сказать, что в subscribe на Erlange сразу вызывается swapn для дальнейшей обработки, и таким образом скорость достаточно приличная получается…
Но в целом, вопрос религиозный, можно было и на чем то другом написать, ради разнообразия, да и сравнить консюмеры на разных языках, какой будет лучше справляться…
И один из бонусов, отказ 90% серверов с демонами Erlanga, повлияет в плане снижения скорости, но не более… RabbitMQ не дождется подтверждения, отправит задачи на другой сервер. Поверьте решения принимаются не просто так.
Плюс дополнительно есть например очереди удаления пользователей, обработка которой полностью проходит без участия php, и другие…
Сама идея использование Rest, в будущем позволит изменить обработчик, сделать его более эффективным, написать на любом языке.
Gearman предоставляет чуть больше возможностей — это да, реализовывать отложенные задачи на RabbitMQ приходится, немного костыльным способом.