Дело тут в том, что в работе то как раз все стабильно. Проблемы возникают при очередном деплое (техпроцесс работы с Rails подразумевает, что достаточно часто авторы программы в автоматическом режиме выкладывают последний срез кода из репозитория на веб-сервер). Что-то где-то добавилось, где-то кто-то описался и все. Пока не трахнут мозг девелоперам, никто даже откатывать не будет.

В чем же проблема того, что чаще чем, скажем, на PHP (вроде бы) возникает такой Application Error. Большинство софта на PHP написано в кондово процедурном стиле. Когда в функцию приходят переменные, ее автор, наученный горьким опытом, пишет целый экран проверок.

function strlen($string) { if(is_null($string)) { return 0; } … }

Что вместо этого будет на Ruby:

class String def size … end end

Никакой проверки внутри кода size на наличие объекта класса String нет и быть не может. Как же быть? «Крах объектной парадигмы!» возопит чудо типа Расмуса, которое ничего толком про ООП и не знает. Ничего подобного.

Таких казусов с Basecamp не происходит. Почему? Тестирование, тестирование и еще раз тестирование. Перед коммитом код должен быть проверен. Если нет интеграционных тестов на простейшие пользовательские ситуации, сам дурак. Если нет функциональных тестов на самые часто используемые урлы, сам дурак. Дурак, дурак и еще раз дурак. Что бы им не быть и судорожно не набирать в консоли rake rollback, пишем тесты.

Я обычно как в таких случаях делаю. На каждую такую ошибку после деплоя, завожу функциональный тест, если его еще не было и завожу соответствующий юнит-тест, если нужен.

Т.е. это не приложения на RoR менее стабильны, просто на них более отчетливо проявляется, что приложение из себя представляет аморфную разваливающуюся нетестированную массу.