Ruby dooby doo

Так получилось, что начал сотрудничать с одной из компаний, которая свои разработки ведёт на Ruby'On'Rails. Специалистов по ROR сейчас на рынке труда не так много (как впрочем и спрос невелик), поэтому в компании решили - PHP-программисты являются вполне годным материалом для изучения ROR и применения
этой технологии в коммерческих разработках.
В целом, мы всегда используем PHP-фреймворк CodeIgniter, который очень схож по структуре с ROR. Я когда взглянул первый раз на структуру руби-приложения, то даже немного удивился - насколько всё похоже. Те же папки app/application, реализация того же паттерна MVC, соответственно папки Models, Views, Controllers. Конечно, ROR в сотню раз более развит и функционален, чем CI. Однако есть моменты, которые мне, как ньюби в этой технологии не очень понравились. К примеру - строгость наименований, включая "человекоплнятную" схему образования объектов на базе таблиц в БД в основе которой лежит правило множественного числа в английском языке (Products=>Product). Когда всё это изучишь - ничего сложного, но приходится запоминать много таких условностей, которые не всегда понятны напрямую из кода. Есть и очень удобные вещи - можно прописать связь объектов (т.е. фактически связать таблицы БД на уровне приложения) и все операции по вставке/правке данных делаются за пять минут, включая не совсем тривиальные вещи вроде загрузки изображения. Есть ещё и такие понятия как Observers, т.е. триггеры на уровне приложения, а не БД. К примеру, на объект Order можно прописать такой вот триггер и при вставке в базу нового заказа (Order) выполнится код триггера, например отправка уведомлений по почте заказчику и администрации. Таких вот деталей много.
Впечатление у меня осталось такое - если хорошо владеть PHP и CI (или каким-то другим развитым РНР-фреймворком), то ROR будет просто обычной альтернативой, нисколько не лучшей и не худшей по своей сути.
Ну и в процессе этого, сделан ещё небольшой проектик. Так что ещё +1