LINUX.ORG.RU

Интересно собирательное мнение о Rails

 


2

1

Интересен взгляд форумчан на этот фреймворк. Сравнительный анализ с прямыми конкурентами (django, play etc.) и непрямыми (node.js etc.).

Сам rails разработчик уже почти 2 года. С другими технологиями знаком не так тесно, на PHP в свое время не задержался, python тоже не вдохновил (пробовал его параллельно с ruby).

Так же ссылки на интересные библиотеки и прочее - приветствуются. Эпик-стори - тоже.

так на форумах обычно желчь излививают и набрасывают всякое на вентилятор, а не перетирают то, что все устали перетирать лет 5 назад

от себя добавлю, что все перечисленное для хипстеров, а реальные пацаны выбирают java и php

anonymous
()
Ответ на: комментарий от anonymous

Гопники да, они такие, выбирают пхп и жабу и идут отжимать бабло у глупых заказчиков.

anonymous
()

Сравнительный анализ с прямыми конкурентами (django, play etc.)

Такое же мало кому нужное поделие. когда-то все дрочили на Zope ну и где оно ? тоже самое с рельсами, джангами

непрямыми (node.js etc.).

у node.js может быть большое будущее в среднесрочной перспективе.

а так пацаны на текущий момент выбирают java / php. ананимус привет ! :D

anonymous
()
Ответ на: комментарий от anonymous

Я не говорю, что rails будет жить вечно. Но на данный момент там все вполне адекватно и современно.

Zope-бум прошел мимо меня. Молод я еще. Но видимо он отмер как отмер ажиотаж и возбуждение вокруг CMF идеи. Задачи стали сложнее и перестали в нее умещаться. Ровно и так могут сдохнуть рельсы - как сдохнет идея синхронных веб-приложений.

Вот поддержки PHP я никогда не понимал. Не нравится мне его экосистема, вездесущие доллары, стиль языка и толпы быдлокодеров-школьников - хоть убей. Что угодно - женщин, бобров, детей, java'у - но не PHP. Инерция рынка, мать его. Хотя не могу спорить с тем, что достойные фреймворки для PHP таки написали.

Будь прокляты те дни, когда приходилось работать с drupal. И проблема даже не в drupal, а в том, что под него кодят как для говна и продают заказчику.

mr_ffloyd
() автор топика

Самый адекватный ответ в этом направлении заключается в том, что они (эти различные framework'и) примерно равны по возможностям и профиту. rails довольно не плохой framework, но лично я выбрал flask/django, из-за экостистемы питона(много хороших библиотек).

В rails мне очень нравится только ActiveRecord. В Django сетевая подсистема (роутинг etc.).

menangen ★★★★★
()

в play (который RESTful by default), можно, при желании, развести стандартный нифига не-restful срач с глобально живущими в памяти массивами данных. В пыхах это невозможно технически, в питоне и руби возможно с бубнами (да, емнип, там и непринято так делать) Олсо, основываясь на этом, можно более удобно скрещивать сайт с веб-фреймворками, написанными на другой идеалогии (например, Wicket), если проект написан на нескольких непересекающихся или частично пересекающих веб-фреймворках одновременно.

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

можно более удобно скрещивать сайт с веб-фреймворками

благодаря rack, в руби можно внутрь рельс запихнуть, например, приложение на синатре, и вообще любое приложение в конечном счете использующее rack.

special-k ★★★
()
Ответ на: комментарий от special-k

помойму, между реквестами перегружаются экземпляры классов, а не сами классы. Поэтому можно юзать class members:

class ObjectCache
  @@objects = {:beagle => Beagle.new, :poodle => Poodle.new}

  def lookup key
    @@objects[key.to_sym]
  end
end

в продакшене так на автомате, в девелопменте включается ключиком

если не используешь рельсы, знакомые рубисты о какой-то технологии для этого рассказывали, но я не шарю

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

перегружаются экземпляры классов

очевидно, некоторые экземпляры классов.

между реквестами перегружаются экземпляры классов, а не сами классы.

Именно так, только я считаю это «без бубнов». Лучше не использовать @@ без лишней необходимости. Достаточно

class ObjectCache
  @objects = {:beagle => Beagle.new, :poodle => Poodle.new}

  def self.lookup key
    @objects[key]
  end
end

special-k ★★★
()
Последнее исправление: special-k (всего исправлений: 2)
Ответ на: комментарий от special-k

Именно так, только я считаю это «без бубнов».

однажды на сервере закончится память и процессор, и придется эту логику растаскивать по серверам... В жаве с этой проблемой боролись тысячи лет, накоплен большой говноопыт...

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

Руби гораздо менее требователен к памяти, и по части потребления, система очень стабильна. А процу-то с чего кончаться...

special-k ★★★
()
Ответ на: комментарий от stevejobs

rails + erlang/node.js/eventmachine подсистемы - стандартная практика.

Глобальные переменные - для меня это немного дико звучит. Если не конкретизировать. Если фреймворк stateless (rails, django) - то грех таким страдать. Если же экплуатируются websockets etc. - то здесь уже корневой считаю идею заложенную в erlang. В этом случае функциональное программирование тащит. Особенно immutable vars. Ибо ФП на уровне парадигмы решает проблемы масштабирования.

Печалька в том, что на erlang может оказаться плохо писать «цифромешалки». Друг сравнивал в этом плане erlang vm и jvm - по скорости выиграла последняя (более чем в 5 раз). Но архитектура процессов в erlang все же пока самая лучшая (из мной виденного).

node.js же кажется попыткой написать удобную асинхронию для тех, кто ниосилил ФП.

mr_ffloyd
() автор топика
Ответ на: комментарий от special-k

Пиратский сервер вова написан вообще на крестах, но больше 10к людей онлайна еле-еле держит даже на хорошем сервере с последними ксеонами и 128гб оперативки

stevejobs ★★★★☆
()

рельсы будут погибче джанги
больше встроенных возможностей
некоторые хаки рельсов указывают на присутствие некоей магии

kto_tama ★★★★★
()
Ответ на: комментарий от mr_ffloyd

ФП на уровне парадигмы решает проблемы масштабирования.

Главное качество кода и асимптотическая сложность алгоритмов.

Взаимоисключающие параграфы детектед.

tailgunner ★★★★★
()

Медленно. Дыряво.

zz ★★★★
()
Ответ на: комментарий от kto_tama

некоторые хаки рельсов указывают на присутствие некоей магии

Да там и в самих рельсах в некоторых местах куча магии с автогенерирующимися в рантайме методами, которые в итоге не парсятся rdoc'ом и в целом крайне слабо документированы, приходится иногда в исходники лезть, чтоб понять, как эта хрень вообще работает и почему она не работает у меня.

INFOMAN ★★★★★
()

Да нормальный Rails фреймворк. Если и правда интересно, что в Rails не так, то смотри сюда - http://blog.steveklabnik.com/posts/2011-12-30-active-record-considered-harmful и почитай книгу - http://railsoopbook.com/

В ней как раз описано в каких местах rails ломают ООП и почему, где не правильно названы классы (ActiveRecord) и много другого интересно.

Даже после прочтения шквала критики понятно, что такого же удобного аналога Rails нету. Rails отлично справляются со своей задачей, надо понимать когда и где их можно применять + важно знать ограничения ruby, всякие gil/gvm, кто и что может загружать память и как работает gc.

В общем я бы на твоем месте продолжал углубляться в руби и rails , прочитать http://patshaughnessy.net/ruby-under-a-microscope и начать изучать что-то паралельно (erlang/go etc), в конце концов жить только с ruby рано или поздно надоест.

pechorin
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.