Comments 18
Спасибо за статью, давно хотелось поковыряться в EM, но все руки не доходили, теперь вы меня вдохновили. Кстати, что думаете об js — альтернативе — Node.js?
p.s. Даешь много статей по Ruby, хороших и разных!
p.s. Даешь много статей по Ruby, хороших и разных!
Если хотите поковыряться более детальнее, посмотрите на cramp, в связке с github.com/jcoglan/faye или socket.io/ они могут составить более-мение неплохую конкуренцию node.js.
Я считаю, что голый EM не может конкурировать с node в вебе, а вот с rack — вполне.
Я считаю, что голый EM не может конкурировать с node в вебе, а вот с rack — вполне.
Спасибо за подсказку, обязательно посмотрю на cramp.
Это очень круто, что вы так считаете, вот только ивентмашина не то что бы не конкуретн рэку, она вообще никак с ним не связана. Если пройдете по своей же ссылочке на репо крэмпа, то увидите, и ивентмашину, и рэк живущих вместе.
Зачем столько едкости в вашем комментарии? Я как раз и имел ввиду, что связка EM+Rack может быть конкурентом node.js и именно поэтому привел ссылку на cramp, как один из вариантов.
Основная мысль была в том, что получить «нахаляву» кучу проверенного рельсами middleware и поддержку «старших» вебсерверов из коробки.
Потенциально, cramp способен заменить node в будущих проектах на Руби, но сейчас я бы все равно использовал node, как гораздо более стабильное решение. Например, для использования уже упомянутой Socket.IO в node нужно только поставить пакет и npm, а интеграция с rack далеко не фонтан:
Но для изучения, повторюсь, этого будет достаточно.
Ну и по поводу холиваров (имеющих все основания) на тему синтаксиса js, можно расширить выбор до coffescript + node.js или вообще до elexir/erlang/OTP
Основная мысль была в том, что получить «нахаляву» кучу проверенного рельсами middleware и поддержку «старших» вебсерверов из коробки.
Потенциально, cramp способен заменить node в будущих проектах на Руби, но сейчас я бы все равно использовал node, как гораздо более стабильное решение. Например, для использования уже упомянутой Socket.IO в node нужно только поставить пакет и npm, а интеграция с rack далеко не фонтан:
Super alpha, super experimental, not to be used yet for real work, unless you want to hack in to the code and help me get it to production ready.Последний коммит был в сентябре 2010 года.
Но для изучения, повторюсь, этого будет достаточно.
Ну и по поводу холиваров (имеющих все основания) на тему синтаксиса js, можно расширить выбор до coffescript + node.js или вообще до elexir/erlang/OTP
elixir правильное название, ошибся.
Имели ввиду, но тут:
> EM не может конкурировать с node в вебе, а вот с rack — вполне.
Написано совсем другое, если просто прочитать ;)
> EM не может конкурировать с node в вебе, а вот с rack — вполне.
Написано совсем другое, если просто прочитать ;)
На самом деле, все зависит, от того, что вам необходимо и от ваших предпочтений. Я лично не пользовался node.js, так как код на руби мне кажется намного красивее. Из очевидных преимуществ — это попсовость node.js, что означает больше поддержки, чаще обновления и т.д. и т.п…
UFO just landed and posted this here
1. Нет ничего ужаснее использования ObjectProtocol. Вы не только зачем-то вводите дополнительные знания о протоколе в виде «а вот первый байтик это размер ссобщения», но и сериализуете в формат, который ничто, кроме руби не прочитает. В таком банальном случае простого разделения сообщений переносом строки (т.е. более, чем достаточно LineProtocol) и JSON-сериализации более чем достаточно.
2.
Вы просто так лишний раз создаете тут Proc. Уберите proc {} и два .call, ничего не изменится, вот увидите :)
3. Если убить воркер, то вся система просто ляжет, никаких обработок внеплановой работы. Именно такие кейсы интересны в тестах :)
Я, кстати, джаст фо фан тоже делал это тестовое, получилось 40 строк ;)
pastie.org/private/nilbofrru5xfbpt4duhg
(брокер в моем случае необязателен, можно использовать zmq-device хоть сишный из поставки либы)
2.
def queue_worker_loop
proc{ |connection|
Вы просто так лишний раз создаете тут Proc. Уберите proc {} и два .call, ничего не изменится, вот увидите :)
3. Если убить воркер, то вся система просто ляжет, никаких обработок внеплановой работы. Именно такие кейсы интересны в тестах :)
Я, кстати, джаст фо фан тоже делал это тестовое, получилось 40 строк ;)
pastie.org/private/nilbofrru5xfbpt4duhg
(брокер в моем случае необязателен, можно использовать zmq-device хоть сишный из поставки либы)
1) конечно, он практически бесполезен, но в данном случае использовался для упрощения задачи, так как формат сообщений строго задан (в реальном приложении можно использовать протобуферы, json и т.п.)
2) Да, если убрать, то фактически ничего не изменится, но читаемость кода снизится. А так проще будет организовать фолбек на случай потери коннекта (например, трабла с таймаутом соединения с mysql) и т.д. и т.п.
3) Код писался пару часов, я дольше писал эту статью), да и смысла особого не было доводить до конца, так как писал фо фан. + Цель была просто показать, как можно тестировать такие приложения.
Ну, в принципе и этот код можно ужать строк до 40-50, что вернуло бы его к изначальному виду, просто цели такой не было.
И я не спорю, что ffi полезен))
2) Да, если убрать, то фактически ничего не изменится, но читаемость кода снизится. А так проще будет организовать фолбек на случай потери коннекта (например, трабла с таймаутом соединения с mysql) и т.д. и т.п.
3) Код писался пару часов, я дольше писал эту статью), да и смысла особого не было доводить до конца, так как писал фо фан. + Цель была просто показать, как можно тестировать такие приложения.
Ну, в принципе и этот код можно ужать строк до 40-50, что вернуло бы его к изначальному виду, просто цели такой не было.
И я не спорю, что ffi полезен))
Sign up to leave a comment.
EventMachine прокси демон