Мда. Не прошло и года. Длинное эссе на тему следует.

###Скепсис

Поскольку количество людей которые любят “по старому но чтобы работало” (как вариант - которым “ехать и без шашечек”) всегда больше, чем нас (курсив юл.), начнем с удовлетворениях их самых главных сомнений (чтобы никто не подумал напоминать мне об этом в комментариях). Расскажем, ничего не скроем.

Technorati Tags: , ,

####Он нигде не установлен

Rails (равно как и Ruby с минимальным набором модулей) хоть и просто установить, но сделать это на сервере, который вы не контролируете - практически невозможно. Вероятность найти зарубежный хостинг, пригодный для Rails, близка к одной десятой доле процента, вероятность найти таковой в России (и округе) - ноль. Так что если условия хостинга устанавливает заказчик (чего надо избегать как огня) - даже не думайте. Для Rails жизненно необходим либо выделенный сервер, либо VPS, где можно рулить папкой /usr/local на свой вкус. Иначе количество пива/водки/вина, поставленных админу, сильно превысит бюджет вашего проекта. Я бы пока не доверял даже TextDrive. Для таких шашечек (во всяком случае на сегодня) нужен доступ к рулю и педалям.

####Он зеленый

Развертывание готовых Rails-приложений в настоящий момент - порядочное наказание. Как минимум потому, что каждое rails-приложение требует жизни внутри отдельного виртуального хоста, и около десятка папок рядом с htdocs (или как у вас там зовется DocumentRoot). Именно рядом, это важно. Более того - пока нету достаточно надежного способа распространять библиотеки, нужные вам, вместе с приложением – и при малейших проблемах их надо ставить как gems - что при одном ruby-интерпретаторе опять же требует root-овый доступ. Кооторого вам никто не даст, и так далее и так далее и так далее. Плюс - перенастройка Ruby-приложения, работающего под Apache, часто требует оный Apache перезапустить (чтобы обновились все загруженные FCGI-обработчики). Что тоже вам мало кто даст делать (особенно если оный апач наряду с вашим экспериментальным паравозом крутит около сотни чужих сайтов).

####Он медленный

Rails - здоровая штука. То есть - работает он крайне медленно, насколько именно - зависит от способа сервировки. Из-за невероятной динамичности Ruby (сверхдинамичные языки как правило медленнее более простых) и автоконфигурации всего при загрузке приложения. К примеру, среднестатистичекая обработка одного Rails-вызова считает настройки всех таблиц в вашей базе, автоматически сгенерирует целую прорву функций и классов, половина вышеупомянутого - с помощью медленных в любом языке eval-функций. Плюс - будет подключено просто нечеловеческое количество модулей и классов самого Rails, подключен нативный (то есть написанный на Ruby) URL-rewriter и т.д. Если у вас сильно посещаемый ресурс - даже не надейтесь получить от Rails сопоставимые с Java или PHP скорости (имеется в виду популярный в кругах великих “PHP который может читать только другой PHP”, не имеющей ничего общего с - нормальный PHP framework будучи вдвое уродливее Rails обсепечит вполне сопоставимые тормоза, во всяком случае без прекомпилятора).

Что я имею в виду? Очень просто - при загрузке модели оная загрузка - 34 уровень стека вызовов.

Еще одна хитрость связана с тем, о чем мы при пользовании PHP даже не думаем. То есть с mod_php. При запуске Apache в него уже загружен PHP-интерпретатор, при необходимости создается только “песочница” для поступившего запроса. CGI(стандартная настройка Рельсов) при вызове поднимает одну ruby на каждый запрос - пользоваться этим маловозможно даже с одним пользователем на локальной машине. Способов решить это в принципе два. Первый - использовать FCGI (насколько я понял его главная прелесть в том, что он поднимает и “подвешивает” в памяти несколько заранее подготовленных интерпретаторов, которые по мере поступления запросов заменяются новыми). Само собой mod_fcgi не установлен нигде не говоря уже о Ruby bindings для оного. Второй - использовать mod_ruby, но в него можно вгрузить лишь одно Rails-приложение (что никуда, никаким образом не годится), и памяти он кушает изрядно. Другое дело, что парсинг большого PHP-приложения по скорости (без прекомпиляции байткода) сопоставим с подъемом Rails.

Еще один уровень тормозов - ActiveRecord (самая вкусная штука, вшитая в Рельсы). С ним есть целый ряд проблем, который есть также у любого ORM в PHP, Perl и т.д. - ORM который перегружается при каждом запросе неэффективен. Насколько я понимаю, в Java (где загруженные в память ORM-обьекты вполне могут жить в памяти сервлета между запросами и по мере надобности быть оттуда загружены) такой проблемы нет (другое дело что потом все эти обьекты надо синхронизировать с базой). Ни Ruby ни Perl само собой такого не предоставляют, поэтому при каждом запросе грузится новый набор ORM-обьектов, необходимых каждой конкретной странице. Удобно - но относительно медленно, так что выбирайте. Другое дело, что с таким функционалом код получается чуть ли не читаемый человеком (и возможность реализовывать в ORM-классах функционал невероятно полезна). Но это не для великих (то бишь это как раз для нас, скромных любителей шашечек).

Особенность четвертая. Он неуверенный. Попробую объяснить это внятнее. Rails построен на библиотеке CGI, про которую никто, кроме людей, давно пользовавших ее вместе с Ruby, не знает. Никому не известно, какие в этой библиотеке есть дыры и упущения (как вам например, такое - сколько лет назад с этим разобрались в PHP?), и когда и откуда они полезут – неясно. Вполне возможно, что оные дыры полезут именно там, где вы этого совершенно не ожидали. То есть - что будет, если отправить Rails неправильно сформированный запрос, например? На каком уровне это можно отследить? Все это предстоит выяснить “на ходу”, и вероятность того, что “такие шашечки вам не нужны”, близка к 100 процентам.

Он японский

Может звучать странно, но после Ruby я окончательно уверился - надо устроить соревнование между авторами скриптовых языков (и библиотек) под девизом “кто положил самый длинный прибор на поддержку Юникода”.

В Ruby вся поддержка оного суммируется как обеспечение (якобы) безболезненного ввода и вывода (через установку ключа при запуске или глобальную переменную) и библиотеку (на Ruby) которая “как бы” реализует многобайтовую поддержку - на самом же деле она просто перегружает функции класса String своим специфическим образом. Ну и Oniguruma поддерживает Юникод (слава богу), хоть и не полностью.

А вот дальше начинается ой. По сравнению с PHP (казалось бы - как можно поддержку Юникода сделать хуже) Ruby - просто злой гений. Есть например Test::Unit и IRB - чудесные инструменты. Но не стоит ожидать, что они выплюнут что-то, что можно прочитать в юникодном терминале. А именно - у меня почему-то то, что я набираю непосредственно в irb, показывается по-русски, тогда как все остальное (то что указано в исходниках например) корежится нещадно. При этом если вывод того-же Test::Unit переправить пайпом в текстовый редактор - русские буквы опять видно. Ну [insert expletive here]

Помимо этого (к величайшему сожалению) было забито и на поддержку локалей. Хотите русских дат? Перегружайте Date (должно получится - пока не занимался). Хотите strftime? Перегружайте.

В итоге получается довольно некрасивый (и крайне позорный) салат - ну черт возьми, какое же позорище – 2005 год на дворе, а справились с этим вопросом похоже только Python и Perl.

Shame.

А самое обидное? Вряд ли это в ближайшем времени кого-то заколышет. Большая часть разработчиков Ruby - японцы (с японскими же блогами). И у них отлично работает Shift-JIS (что им и требовалось - в том числе и в mbstring для PHP, остальные кодировки просто под руку попали). А в юникоде им глифов не хватает.

В следующей серии – позитив. Потому что Rails - greatest thing since sliced bread. Это я вам как авторизованный любитель шашечек со стажем говорю.