В пользу RoR.

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

И вот решил свести это все в простенькой web системе. Ну и где-то за дня 1.5 суммарно сделал то, что мне было нужно. Причем вышло даже пристойней чем я ожидал.

Что мне очень понравилось, что если бы мне второй раз понадобилось написать такую программу (с нуля), то заняло бы сейчас это у меня наверное пару часов, а третий раз уже в минут 20 вложился бы.

И это достаточно впечатлительно, как мне кажется, достаточно мало платформу дают такой коэффициент ужатия.

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

Ну и плюс потихоньку читаю Ruby Pickaxe книжку и впечатлен некоторыми возможностями/гибкостью Ruby. Чем-то мне Ruby напоминает по гибкости Perl, но когда я разбирался с ним, я был еще чертовски молод и плохо понимал его прелести.

9 комментариев to “В пользу RoR.”

  1. Denis Kostousov:

    Можно на программку посмотреть?

    • Victor Ronin:

      Кинул на почту.

      Строго судить не стоит — первая проба пера. Плюс, не почищенная (так как не production).

      Если с RoR не сталкивались, то стоит что-то почитать, а потом заглядывать в поддиректорию app, в которой и есть писанное руками. Остальное на 90% сгенеренное автоматом Rails’ами.

  2. ну CRUD много где хорошо реализован… хотя когда первый раз видишь, то кажется — нифига себе моща! 🙂

    • MaxD:

      Можете пару примеров привести где он ещё хорошо реализован?

      Программировал недавно на ASP.NET MVC и хочу сказать что по сравнению с Rails CRUD там реализован просто отвратительно. Нужно написать кучу инфраструктурного кода чтобы сделать элементарный CRUD (нужно прикрутить собственный слой для работы с моделями, придумать как мапить данные со страницы на объекты БД, придумать как мапить объекты БД на объекты представления (если что-то сложное выводишь) и т.п.). Про реализацию более сложных вариантов CRUD (например страницы с nested form) даже говорить не хочется.

      Так что ИМХО Rails разработчики очень грамотно подошли к проблеме сохранения данных со страницы и это экономит огромную массу времени как заметил автор поста выше.

      • ну джанго первое, что приходит в голову, а второе… да любой самопальный фреймворк. КРУД — это настолько элементарно, что он много где хорош.

        в рельсах есть куча другой перелести 🙂

    • Victor Ronin:

      Собственно говоря, для меня пожалуй это первое столновение с CRUD. Очень долго сидел на mobile и слегка на низкоуровневом desktop’ном.

      А тут просто офигел от того, что идея и результат то друг друга отделены часами, а не неделями.

  3. Да, Рельсы это мощь, третья версия так вообще конфетка. Имхо, самая мощная реализация CRUD и MVC, Джанго еще хорош, но все-таки немного уступает RoR. ASP.NET MVC вообще какашка, позор MS за такие продукты, хотя может это конечно ограничения языка накладывает такой отпечаток.

    • antonz:

      в asp net это тоже просто, и может быть сделано автоматом мастером. Однако применять ASP Net для для такого примитива — стрелять из пушки по воробьям.

      • MaxD:

        🙂 lol

        Я так понимаю под мастерами вы понимаете ту убогую функциональность которая генерит вьюхи и контроллеры? Эти «мастера» в ASP.NET про которых вы упоминаете не даелают и половины того что делал scaffold в Rails.

        То что делает мастер в ASP.NET в Rails называлось scaffold. Эта функцинальность помогла очень грамотно пропиарить Rails т.е. показала как сверхбыстро можно делать прототипы приложения на Rails, но к сожалению кроме создания прототипов от неё толку мало. К тому же она создаёт проблемы при попытке перестроить прототип в нормальное приложение (много одинакового кода, разметки и почему то никто не хочет выбрасывать прототип и писать нормальное приложение с нуля :). Поэтому в Rails 2 её выкосили и перенесли в отдельный плагин (если память не изменяет).

        Я пробовал ASP.NET MVC мастера и хелперы которые генерируют страницу или её часть для создания админки, Как и следовало ожидать практически все хелперы в итоге пришлось выкосить т.к. они создают достаточно проблем плюс делают код менее понятным и замусаривают модели классами с метаданными и пачками атрибутов. Ну а разметка сденерированных страниц осталась т.к. особых требований к дизайну не прилагалось. В нормльном приложений (не в админке) я не рискнул их использовать т.к. от сденерированной разметки толку мало и как правило требуется использовать ту разметку и стили которую предоставляют дизайнеры.

        У меня есть только одно объяснение почему мелкомягкие вкрячили эти визарды и хелперы с ASP.NET MCV: дело в менеджерах, евангелистках и подобному сброду которые ездят по всюду и пиарят мелкомягкие продукты. Для привлеяении внимания толпы разработчиков им нужно быстро (буквально 10 мин и меньше) сделать чудо используя их «современные» технологии. Визарды и хелперы дают им эту возможность. Я так говорю потому как не раз это видел. К сожалению технологии созданные для демонстрации чудес как правило не выдерживают проверку в реальной жизни.

        Ну а насчёт примитива скажу так: если фреймворк не позволяет делать примитивные/элементарные вещи на раз-два-три, то нах** такой фреймфорк т.к. сомнительно что при решении более сложныех задач он покажет себя лучше.