Разумеется, в случае разработки полноценного «большого» приложения со своими хуками и middleware, с использованием конфигов, данная утилита не будет представлять особого интереса. Она ориентирована на ускорение разработки простых, «типичных» приложений (которых, откровенно говоря, большинство), для которых код, ответственный за работу с Ковбоем — рутина.
Что-то мне подсказывает, что суть постов Луговского сводилась не к тому, что на цпп чего-то сделать невозможно, а к тому, что на лиспе это будет проще, элегантнее и быстрее.
Затруднюсь с диагнозом. Попробуйте с гитхаба взять финальный код (git clone git://github.com/chvanikoff/webserver.git) и запустить (cd webserver && make all run) — если заработает, то ищите неточности в следовании материалам статьи, я все перед публикацией проверял. Если нет, то пишите в личку.
Из плюсов основных 2:
-возможность легко патчить удаленную ноду (правишь код на одной — он подхватывается на остальных)
-уведомления через Growl (хотя вроде еще какие-то есть для тех, кто не пользует Growl)
Из минусов основных тоже 2:
-не умеет апгрейдить код из вложенных директорий (например — если есть модули во вложенных в src/ директориях, то они не будут обновляться на лету). Давно собираюсь посмотреть, да попатчить (или разобраться, как его научить этому), но все никак руки не дойдут.
-не особо понятно, как интегрировать свои дополнительные действия на апгрейд кода (допустим применимо к данной статье я бы хотел при обновлении src/webserver_app.erl дергать webserver:update_routes/0), тут снова упираемся в то, что надо патчить сорцы как-то.
Как самый простой вариант. Но все, как всегда, зависит от контекста. В контексте данного треда я хотел показать, что nginx не является обязательным звеном.
Потому что он может не отматчить вернувшееся от application:start(App) значение (например — {error, {not_started, _}}) и тогда мы упадем в функции ensure_started, как и надо поступать в данной ситуации.
Хм… По-моему, cowboy_protocol:recv/3, используемый для получения данных из сокета, без разбору на ситуации ограничивает время их ожидания. Или я что-то путаю и некорректно понял суть проблемы?
3 — не уверен, что нет лучшего варианта, последнее время не так активно слежу за обновлениями Ковбоя (уж больно их много), но, как вариант, можно последовать совету из комментария к проблеме: github.com/extend/cowboy/issues/213#issuecomment-7427912
Спасибо, не знал о такой возможности. А как после изменения шаблона его перекомпилировать? Простой rebar compile сделает это «на живую»? И справится ли с этим Sync?
git clone git://github.com/chvanikoff/webserver.git) и запустить (cd webserver && make all run) — если заработает, то ищите неточности в следовании материалам статьи, я все перед публикацией проверял. Если нет, то пишите в личку.-возможность легко патчить удаленную ноду (правишь код на одной — он подхватывается на остальных)
-уведомления через Growl (хотя вроде еще какие-то есть для тех, кто не пользует Growl)
Из минусов основных тоже 2:
-не умеет апгрейдить код из вложенных директорий (например — если есть модули во вложенных в src/ директориях, то они не будут обновляться на лету). Давно собираюсь посмотреть, да попатчить (или разобраться, как его научить этому), но все никак руки не дойдут.
-не особо понятно, как интегрировать свои дополнительные действия на апгрейд кода (допустим применимо к данной статье я бы хотел при обновлении src/webserver_app.erl дергать webserver:update_routes/0), тут снова упираемся в то, что надо патчить сорцы как-то.
3 — не уверен, что нет лучшего варианта, последнее время не так активно слежу за обновлениями Ковбоя (уж больно их много), но, как вариант, можно последовать совету из комментария к проблеме: github.com/extend/cowboy/issues/213#issuecomment-7427912
2 пофикшено здесь: github.com/extend/cowboy/commit/84d7671e91bb2dee2081172dbf651860134ae75e