Расскажите какую нишу занимает Ruby On Rails?

Question

[allexe]

Заинтересовался Web разработкой, начал осваивать CodeIgniter. Почитал на Хабре отзывы о RoR. Много восторженных отзывов особенно от тех, кто перешел на него с PHP-фреймоврков. С другой стороны, на сегодня, реальные факты (количество вакансий, размер сообщества и т.п.) не дают повода сказать, что RoR убийца PHP-фреймворков. Я не хочу сравнивать Ruby и PHP. У каждого ИМХО есть своя ниша. Поэтому хотелось понять для себя:

1. Какую нишу сейчас занимает RoR. Какой проект есть смысл делать на RoR (вместо PHP-фреймворка) и почему? Может есть какие-то особенности (типа необходимость AJAX и т.п.) ради которых лучше использовать RoR.

2. Какие требования к хостингу необходимы для проектов на RoR? Какова скорость работы и нагрузка на сервер в сравнении с PHP-фреймворками? Есть ли смысл делать небольшие (типа сайт-визитка) проекты на RoR?

3. Вообщем где эта грань, когда переход на RoR будет оправдан?

Answer 1

[mdevils]

Разработать прототип проекта на ROR легко и быстро, собрать из гемов 80% функционала и интегрировать все. Но если проект собирается идти дальше прототипа, то встает вопрос производительности. Тут приходится делать выбор: либо писать гемы для себя вместо мегауниверсальных, но медленных, и, возможно, частично или полностью уходить от RoR, либо писать проект на системах с более производительными вариантами библиотек, как, например, PHP.

Comments

[dieinzige]

Бла — бла бла) Мифическая производительность. Как до чего то более чем 2кк уников в сутки дойдет, так можно и слейв добавить) И уж точно рельса здесь будет не-при-чем)

[Георгий Хромченко]

Проблема производительности точно не в языке, а в архитектуре. Просто, возможно, PHP поднимет этот вопрос чуть позже чем Ruby, и все. И то не факт.

[Xarakternik]

Twitter на RoR'e, тормозит разве?

[Александр]

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

[mdevils]

Твиттер использовал RoR лишь в начале пути. Сначала столкнувшись с серьезными проблемами производительности, которые не решить ростом числа машин, они долго переписывали RoR до неузнаваемости. Потом пришли к тому, что ruby не подходит, и уходили в сторону Java.

Answer 2

[bubuq]

RoR − наиболее прогрессивная и динамичная технология на сегодняшний день. Освоив её раз, вопрос о PHP не встанет более никогда. Прогрессивность её, в непоследнюю очередь, в стимулировании использования других прогрессивных средств:

HAML (вы больше никогда не будете писать HTML)
SASS/SCSS (то же самое относительно CSS)
git (контроль версий с всеми возможными свистелками)
YAML (формат всего)
«opinionated software» (навязывание лучших практик: называния таблиц всегда во множественном и т.п.)
с версии 3 — дружба с HTML 5 и яваскриптными фреймворками, наподобие jQuery

Из минусов — высокий порог вхождения: фреймворк объёмный, требует освоения (плюс десятилетия PHP, эм, видоизменяют мозг).

Помимо сайтов непосредственно про рельсы, рекомендуются:
github.com (сборище плугинов, да и репозиторий самих рельсов)
heroku.com (уже упомянутый хостинг с бесплатным тарифом)
odesk.com (на предмет вакансий: поищите, предостаточно)
habrahabr.ru/blogs/ruby/28059/ (мой пост с примером чата на рельсах версии 2)

Comments

[Владимир Чернышев]

Читаю введение в RoR и не вижу как там не писать HTML/CSS. Если не брать во внимание мелкие отличия синтаксиса, то .erb файл ничем не отличается от .php. Да и вообще зачем это нужно? Верстать сначала в HTML, а потом переводить вёрстку на другой язык?

Git никто не запрещает использовать в php (правда я с недавних пор предпочитаю hg), а YAML поддерживается стандартными расширения (хотя и велосипед изобрести никто не мешает, или воспользоваться готовыми наработками например из symfony)

[bubuq]

Во введении этого действительно не будет. Среда развивается быстро. На ERB уже мало кто пишет шаблоны. Найдите в сети HAML/SASS. Верстка происходит в HAML, о каком переводе речь?

Что касается git + php, то действительно никто не запрещает. Тут разница скорее между «никто не запрещает» и «заставляет». Фреймворк это не только набор инструментов, но и best practices.

[Владимир Чернышев]

Зачем тогда пишут во введении, причём по новой (вроде) версии? Да и «найдите в сети HAML/SASS» говорит о том, что это не часть RoR (и в доках не нашёл), да и для PHP реализации есть. И много ли верстальщиков знают HAML?

Ну вот я сейчас блог на RoR «пишу» (туториал прохожу), ни слова про git :-/, никто не заставляет, а по «старой» привычке код блога hg контролирует (а для symfony проектов тоже hg, но сам symfony из git через плагины).

[SMiX]

Многие верстальщики уже знают haml. Он сегодня уже существует на всех языках.
А в случае, если исходная верстка в html, я перевожу ее в haml одной командой(html2haml).
Нет, никто не заставляет, просто экосистема потом приучит. Все расширения хостятся на гитхабе.

[Владимир Чернышев]

На free-lance.ru ни одного не нашёл. Прямо-таки на всех? На ассемблере тоже есть? :)

Вот тоже частый аргумент при сравнениях php (хорошо если с учётом фреймворков) с ror — какая-то «экосистема»… Причём тут она? Есть язык, есть фреймворк, садимся и пишем, что есть в ТЗ… Хотя, кажется, по этому поводу мы уже дискутировали в канун НГ ;)

[SMiX]

Ну зачем вы цепляетесь, понимаете же все. Есть реализации для php, питона и прочих языках, подходящих для веба.

Вот поэтому вы не понимаете, потому что у php ее(экосистемы) по сути нет :) там все очень размазано.

[Владимир Чернышев]

Там смайлик стоял, чтобы не принимали за цепляние…

Я не только на PHP писал и не только для веба. Для меня экосистема языка это что-то вроде транслятор+стандартные библиотеки (включая доступ к API ОС)+средства разработки+документация. Те же php-фреймворки для меня в экосистему php не входят, как не входит, например, mfc, qt или gtk+ в экосистему c++, они создают свои экосистемы с экосистемой языка мало пересекающиеся.

В руби я не могу врубиться (сорри за тавтологию :) ) Вроде язык красивый, но куда не ткнись (кроме самых простых консольных/CGI приложений) непонятно как что-то реализовать без использования сторонних библиотек. Да хотя бы без этих вездесущих gem'ов. Ну или понятно — так же как, утрируя, на ассемблере :)

[Георгий Хромченко]

Действительно «Не писать HTML/CSS» — я пока такое видел только на GWT. Но и RoR и PHP, как community-driven проекты не вытянут такой фреймворк, имхо.

Answer 3

[bsboris]

Вы неправильно ставите вопрос. ЛЮБОЙ проект, который можно сделать на Rails — можно сделать и на PHP. Точно также, как его можно сделать. на python, java, .net, etc. Вопрос только в личном удобстве, способностях и затраченных усилиях.

На Rails стоит делать любой проект, в том случае, если он вам нравится больше, чем PHP + фреймворк.

Comments

[SMiX]

На rails разработка быстрее, чем на php-фреймворках. Факт. Хотя всякие Symfony радуют своим стремлением к Agile.

[bsboris]

Так точно, быстрее, но при одном условии — надо прилично знать ruby и сами рельсы=)
Кстати, php фреймворки активно заимствуют фичи из Rails, насколько позволяет язык. В том же Yii сильно чувствуется влияние рельсов. И ему это на пользу.

Answer 4

[Renat Ibragimov]

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

Comments

[allexe]

Вот хотелось бы понять где эта грань и в чем она заключается

[Владимир Чернышев]

Да нет её особо, по-моему. Как мне кажется, все известные мне веб-фреймворки на императивных языках (и голый PHP — он сам по себе содержит многие элементы веб-фреймворков на других языках :) ) делят одну нишу. Выбо обусловлен личными предпочтениями разработчика или заказчика.

Answer 5

[Вячеслав Плиско]

ROR хорошо годиться для малых и средних проектов в режиме write only (как perl). На нём пишется мало кода. но много магии и отсутствие средств контроля за это магией. Классичейский ООП, описанный в сотнях прекрасных книг здесь не пройдёт. Метапрограммирование предлагает свой путь, удобный для написания и невероятно трудный для поддержки и развития legacy code.
Покапайтесь в кишках ROR и решайте, подходит ли их путь вашему, для большинства он идеален

Comments

[gkirok]

согласен с Atrax, вывод несостыковывается с описанием

[Сергей Удалов]

думаю, совет покопаться в кишках тут не подходит :) уж слишком объемная работа. а без опыта применения все равно сложно разобраться что к чему

[SMiX]

Поясните про «трудный для поддержки». Как раз совсем наоборот.

[SMiX]

И все средства есть, как и в юбом другом языке. Дебаггер, очень информативные трейсы и прочее.

[Вячеслав Плиско]

Atrax, в жизни и на форуме пере до мной проходит уйма людей, которые отравили себе мозг классическим ООП, который реально освоить имея либо много-много лет опыта, либо поработав в очень хорошей команде, коих не так много. Получаются сложные и неповоротливые решения-велосипеды.
Вот и приходится выбирать меньшую из зол. ROR c его метопрограммированием и манкей патчингом подходит для большинства веб проектов, потому что многолетняя поддержка нужна очень редко. А возможно и метапрограммирование можно как-то обуздать, но пока я к нему отношусь как в eval.

[SMiX]

Так что не так с поддержкой RoR-приложений-то?

[Вячеслав Плиско]

ой, извини, забыл ответить на твой вопрос.
1. отсутствие интерфейсов и абстрактных классов, соотвественно type hinting невозможен
2. eval
3. mankey patching.
4. проблемы с отслеживанием, где добавили метод. проблемы с коде браузингом.
5. сейчас появилась возможность дефолтные значения параметров ставить не в конце можно целые квесты вырисовывать.
6. ещё что-нить…
n классические грабли, свойственные другим подходам

[SMiX]

eval используется крайне редко. Он просто в руби присутствует так же, как и почти в любом динамическом языке. Monkey patching — если вы работаете с рельсой, то вы знаете, где расположены манки-патчи(например, гемы патчатся в config/initializers, контроллеры из гемов — в app/controllers).
Все остальное — решается документированием методов в формате rdoc или yardoc. А также юзкейсы всегда можно посмотретьв тестах.

[Вячеслав Плиско]

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

[SMiX]

Блоки — это не подмножество евалов. Это подмножество замыканий.
А сахар как раз позволяет вырисовывать целые DSL.

Что за ide вы имели в виду в последнем предложении?

[Виталий Симаков]

github это малый или средний проект?

Answer 6

[Георгий Хромченко]

На мой взгляд — если сравнивать именно PHP с фреймворками и Ruby On Rails, то и ниша, и количество вакансий у RoR больше. Просто огромная масса PHP девелоперов занимаются допиливанием Wordpress, Drupal,Bitrix и прочих CMS. Тут RoR мимо, на мой взгляд.

Comments

[dutchakdev]

На самом деле ситуация такова, что Ruby On Rails реально на данный момент востребовано, хотя я скажу что о вкусах не спорят, поэтому выбор за каждым. А от себя хочется добавить, что среди тех кто занимаются допиливанием Wordpress, Drupal,Bitrix и прочих CMS есть реально очень умные люди, и готовые решения еще не чего не доказывают. Если Ruby On Rails будет развиваться то и его это ждут готовые решения которые будут сунуть куда смогут…

[JeanLouis]

Покажите мне место где вакансий RoR больше, чем на PHP? Нигде такого не наблюдаю.

[Георгий Хромченко]

Чем на «PHP с фрейморками». Ищите RoR или «PHP + CodeIgniter», например. Тогда картина меняется.

Answer 7

[allexe]

>>Хостинг несколько экзотичен, поэтому или долго искать специализированный или разворачивать все на VPS.
Я так понимаю что это сразу отсекает мелкие проекты, когда допустим на одном хостинге может висет 10-20 проектов?

Comments

[kmike]

Про RoR сказать точно не могу, но на vps за 20$ от linode.com десяток-другой проектов на джанге будут уживаться вполне хорошо. Думаю, с рельсам так же, хотя опыта не имел. Сейчас не 2005 год.

[Сергей Удалов]

у нас на linode висит несколько десятков проектов на Ruby on Rails без проблем. в основном небольшие магазины.

[allexe]

Спасибо за хороший коммент по теме. Разрушили часть мифов о RoR.

Answer 8

[benone]

1. RoR разработчики в данный момент существенно дороже PHP. Несмотря на то что часто быстрая разработка на RoR оправдывает вложения, масштабирование усложняется из-за высокой стоимости.
2. ruby безусловно медленнее php
3. У ruby есть много gemов, в php, насколько я знаю, плагины используются реже.

Comments

[Владимир Чернышев]

1. Вакансий Junior RoR разработчиков практически нет на рынке
2.… сам не сравнивал, но некоторые тесты говорят об обратном, по крайней мере для сравнений ror vs php фреймворки
3. Наверное гемов у руби всё же меньше, чем библиотек у php, но используются они, похоже, «концентрированией» чем в php (общее число меньше, но процент использования каждой конкретной от всего сообщества выше). Не знаю с чем это связано, вроде pear/pecl обеспечивают ту же функциональность (не вдавался в нюансы), такое ощущение, что чисто с психологией — в руби, кажется, чаще предпочитают допиливать под себя готовые решения, чем писать свои с нуля, хотя не исключаю, что из-за своего поверхностного знакомства с руби и практически нулевого знакомства с его библиотеками упустил, что допиливать под себя проще, чем в пхп

[zizop]

2VolCH: 3 Думаю это из-за принципа DRY, пропагандируемого в рельсах. Среди руби программеров, как мне кажется, бОльшее количество стремится писать красивый (качественный, оттестированный, совместимый, масштабируемый...) код.

[Владимир Чернышев]

2zizop: DRY тут не причём, по-моему. Скорее NIH :) Сужу по себе — я постоянно выделяю библиотеки (модули, плагины, в последнее время — бандлы) в своих проектах, когда вижу, что аналогичную задачу уже решал, но практически никогда не ищу готовых решений, кроме глобальных типа CMS или полноценной библиотеки ORM. А если даже ищу (и, что немаловажно, нахожу), то смотрю код, высматриваю интересные идеи и ходы, а потом реализую по-своему. Как правило не нравятся интерфейсы, даже если функциональность устраивает, а писать прокси как-то глупо.

[kmike]

В руби/питоне все проще. Ставится все одной командой, код не нужно искать где-то по интернету (все собрано более-менее в одном месте), более-менее решена проблема обновления кода, не нужно думать, куда его поместить и т.д. На том же pypi библиотек раз в 20-30 больше, чем в pear, сами гляньте. Вот вам и популярность php. К тому же библиотеки обычно меньше по размеру (можно прочитать код перед использованием) и узконаправленней (понятно, что делают), а разработка ведется открыто на bitbucket/github/googlecode — ясно, куда отправлять патчи, если что-то не так; можно сделать свой форк и ставить пакет из него, пока изменения не вольют в основную ветку. То, что пакеты не нужно скачивать вручную, а они ставятся отдельно (вне проекта обычно), стимулирует людей делиться своими наработками (меньше соблазн похачить прямо в проекте) => развитие идет быстрее. То, что на pypi нет модерации, стимулирует альтернативные версии пакетов, которые могут отличаться только интерфейсами, есть конкуренция, в которой побеждают (становятся более известными/популярными/о которых пишут и на которые ссылаются/у которых больше фолловеров на bitbucket/github) более удобные пакеты. Разработчики больше читают код друг друга, берут друг у друга хорошие идеи, больше делятся наработками, а не варятся каждый в своем болотце. За годы, которые существует pypi и bitbucket/github/launchpad, это дало все суммарно очень большой эффект, и экосистема в python/ruby теперь приятная, там есть культура совместной разработки. Дополнительный плюс от использования стороннего кода в проекте — снижается объем кода, который требуется поддерживать, и упрощается понимание проекта новыми разработчиками (т.к. часть кода может быть им уже знакома). В текущем проекте у меня, например, в зависимостях более полусотни библиотек, в пару десятков из них я отправлял патчи, десяток-другой — написанных мной, которые я выдрал из проектов (этого и предыдущих) и которые теперь используют и другие программисты (где-то 20тыс скачиваний только с pypi суммарно). И так в ruby/python делают многие, т.к. особых усилий для этого не требуется. А в php так не принято, максимум — какой-нибудь фреймворк изобретет сайт со списком своих плагинов, или кто-то в блоге выложит кусок написанного с ошибками неюзабельного велосипеда. Осталось помножить это на годы разработки, и причина разница в инфраструктуре php и python/ruby становится понятной.

[kmike]

Глянул сейчас на список пакетов в pear — то, что там есть, в питоне покрывается большей частью стандартной библиотекой. Т.е. PEAR — это скорее недоаналог питоньей стандартной библиотеки, который не ставится по умолчанию и которым никто не пользуется. В питоне же знание стандартной библиотеки — вещь обязательная для каждого программиста. А аналога pypi, выходит, и нет совсем?

[Владимир Чернышев]

2kmike: Спасибо за подробный ответ, может действительно стоит посмотреть django/ror не только как «вещь в себе», но и какие-то модули к ним

Answer 9

[allexe]

Попробую уточнить вопрос:
1. Есть ли какая нибудь статистика по RoR проектам? Может там большой процент веб-ориентированных проектов (социальные сервисы, стартапы), где требует быстро и много вносить всяких изменений или больший процент это корпоративные проекты?
2. Есть ли какой-то «портрет» заказчика в RoR проектах (может там в основном какие-то интернет-инвесторы, готовые вкладывать в web) или наоборот, более оффлайн ориентированные клиенты, для которых web является лишь довеском к основному бизнесу? Каков процент российских иностранных заказчиков?
3. Есть ли какой-то средний (минимальный) бюджет?
4. Каков процент agile команд среди RoR и разработчиков на PHP-фреймворках?
5. Каков спрос во фрилансе на RoR?

Comments

[Сергей Удалов]

у нас в основном мелкие проекты и заказчики не имеют требований по реализации, а мы выбираем ror. по моему мненю ror хорош тем, что:
* элегантно реализует mvc, tdd, orm
* основан на удобном языке ruby
* позволяет получать удовольствие от программиования :)

mod_railsm capistrano делают удобным хостить и выкладывать ror-приложение.

[allexe]

Я так понимаю что для мелких проектов (типа простой интернет-магазин без наворотов с минимальным функционалом) RoR вполне подходит. Т.е. он не слишком тяжеловесен для этого.

[chipp]

Твиттер и Гитхаб написаны RoR. Это показатель, IMHO

[Renat Ibragimov]

На счет магазинов посмотрите spreecommerce.com/ вы удивитесь какой функционал он содержит.

Ну и ТОП50 storecrowd.com/blog/top-50-ruby-on-rails-websites/

Answer 10

[Dmitry]

А вот расскажите, как в RoR обстоят дела с готовыми решениями? Допустим у .net и java огромное количество библиотек и фреймворков на все случаи жизни и у меня есть некоторые сомнения насчет руби, ведь у него сравнительно небольшое комьюнити.

Comments

[DevMan]

А вот расскажите, как в RoR обстоят дела с готовыми решениями?

Не путайте ruby и ror.

[SMiX]

У Ruby и RoR — почти для каждой мыслимой и немыслимой задачи есть готовый инструмент. В свое время, когда начинал, был очень этим удивлен. Теперь не удивляюсь. Просто на ruby приятно программировать :)

Answer 11

[allexe]

Пока нашел только такое позиционирование (из рекламы одной веб-студии):
«Программирование проектов выполняется по-разному: есть два основных подхода. Первый — «всё по техническому заданию». Второй — «переделываем всё до победного конца» (он же «гибкий метод», еще его называли раньше «экстремальным программированием»). От задачи зависит способ решения, то есть выбор языка программирования. Для первого случая подойдет любой (чаще всего выбирается PHP), для второго подхода мы используем Ruby on Rails («рельсы»).»

Comments

[SMiX]

Видимо, студия выбрала такую стратегию из-за потрясающей расширяемости проектов, написанных на ruby и большей динамичности кода.
Вносить в проект изменения(как маленькие, так и крупные доработки) очень легко; код так же легко поддается рефакторингу, который нужен довольно реже, чем в php, потому что на ruby быдлокодить сложно.

Answer 12

[zizop]

Вот небольшой анализ Ruby VS PHP, Rails VS Zend Framework. Думаю будет вам полезен.

Comments

[Владимир Чернышев]

Большинство плюсов и минусов какие-то странные.

[Владимир Чернышев]

Даже с точки зрения перехода всё как-то очень странно выглядит, а именно:
— 1 и 2 пункты странно выглядят, MVC сейчас везде практически, а языки активно используемые в вебе почти все интерпретируемые
— 3 и 4 как бы нивелируют друг друга
— 5 и 6 специфичны для Zend у которого и по сравнению с другими php-фреймворками, имхо, не всё в порядке (я его больше воспринимаю как набор классов, чем как полноценный фреймворк)
— 7 и 8 как-то непонятно о чём, то ли об одном и том же, то ли нет и на примере redmine, имхо, не соответствуют действительности
— 9 не соотвествует действительности (хостинг под рельсы найти можно — сам до недавних пор пребывал в таком заблуждении), а вот с vds имхо у руби/рельс всё сложнее, если использовать не CGI
— многие плюсы (типа качественного ООП) очевидны, а минусы (типа разработки под Windows) надуманны (что, на php под виндами удобно?)

[zizop]

Да, действительно это субъективное мнение энтузиаста :-) Я на более не претендую. На данный момент я скорее влюблен в ZF чем в Rails.
По пунктам: 1 — так это и написано, что много где MVС и поэтому будет понятная структура. 5, 6 — так я их и сравнивал. 7 — поясните про redmine. Интересно, какие особенности его установки. 9 — хостеров с rails меньше, чем хостеров с PHP. Разве не так? Последнее: мне под виндами и так и так неудобно. Сравнение субъективное, я лишь описываю свои впечатления, как заядлого php-кодера :-)

[Владимир Чернышев]

Ну просто как-то сравнение идёт то в смысле перехода, то про объективные, то субъективные преимущества, сумбурно в общем-как-то

5,6 — имхо, RoR куда ближе к symfony (в которую я влюблён и уж точно одного упомянутого недостатка ZF она лишена, к тому же предполагает активное использование классов того же ZF ;) ) по идеологии (вернее наоборот :) ), чем к ZF, а значит их сравнение несколько некорректно

7 — www.redmine.org/projects/redmine/wiki/RedmineInstall — по моему несколько проще, чем docs.mantisbt.org/master/en/administration_guide.html#ADMIN.INSTALL.NEW (примерно одного класса приложения)

9 — меньше, но найти их уже не сложно и цены вполне сравнимые

[zizop]

А почему вы считаете, что ZF нельзя сравнивать с RoR?

Answer 13

[Kpoxa]

Как бы ни был замечателен RoR, но это нечто, что:
1. знает мало кто.
2. Поддерживаем мало кто из хостеров.

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

Comments

[chipp]

Знаете, с рельсой обращаться проще, чем с той же коханой, выросшей из приведенного выше CodeIgniter.
Так что насчет гиков еще можно поспорить.
А вот про то, что знает мало кто, вы неправы. А даже если и правы, то любой человек, имевший дело с MVC, разберется очень быстро.

[Xarakternik]

Вы сравнили рор с линуксом 98.
И? Линукс вырос! Убунту/Дебиан уже сейчас вполне реальная альтернативная ось. Все больше и больше железа со старта ставиться без танцев с бубнами.
Так и с рором. Учите руби сейчас, хотя бы ради альтернативы пхп.

[DevMan]

Прикольно апать старые топики?

[Alex]

Пишу вам из 2014 года, тут RoR всем нужен. =)

[medium3001]

Ой йома!!!=)))) всё отлично!