Rails или Sinatra: лучшее из двух миров?

Original author: Darren Jones
  • Translation
Из года в год на мир Ruby снисходило благословление – здесь появилось завидное количество фреймворков для разработки веб-приложений. Однако двое из них недавно стали явными лидерами этой сферы. Большинство читателей этого сайта наслышаны о Ruby on Rails. Он был разработан Дэвидом Хайнемайером Хенссоном в 2004 и представляет собой MVC фреймворк, который помогает повысить продуктивность и сделать при этом разработчиков счастливыми. Sinatra был создан Блейком Мизерани в 2007, является предметно-ориентированным языком (domain-specific language), который выступает обёрткой для уровня легковесных HTTP запросов и ответов поверх Rack. Его минималистичный подход изящен и элегантен. Статистика на RubyGems.org наглядно показывает, насколько популярны оба этих фреймворка: Rails был скачан 7 миллионов раз, а Sinatra – 1.5 миллиона. Именно Rails вовлёк меня в веб-разработку на Ruby, но на протяжении нескольких последних лет я гораздо чаще использовал Sinatra (и вот 7 причин, из за которых я его люблю). На поверку оказалось, что мне для построения приложения нужен лишь Sinatra вместе с несколькими гемами. Это заставило меня поразмыслить над тем, а можно ли с Sinatra осилить любой проект. Когда лучше всего использовать Sinatra, а когда наилучшим выбором будет Rails? Пытаясь найти ответ на этот вопрос, я спросил у знаменитых Ruby разработчиков, что они думают по этому поводу.

Константин Хаас, который в настоящий момент занимается поддержкой Sinatra, считает что, каждый из инструментов отвечает требованиям приложений своего вида:
Каждый из них решает различный ряд проблем, даже не смотря на то, что они, в действительности, сопрягаются на этом поприще. В то время, как Rails является фреймворком, который с фокусирован на написании модельно-ориентированных веб-приложений, Sinatra – библиотека для обработки HTTP на серверной стороне. Если вы мыслите терминами запросов/ответов HTTP, то Sinatra станет идеальным инструментом. Если вам необходима полная интеграция и как можно больше библиотечных шаблонов, то Rails в этом случае будет для вас превосходным выбором.

Дэвид Хайнемайер Хенссон также считает, что для каждого из них есть своё место, но полагает, что, выбирая между ними, следует руководствоваться размером своего приложения:
Sinatra великолепно подходит для микро-стиля, а вот Rails – нет. До тех пор, пока вы придерживаетесь минимализма, Sinatra превосходит Rails. Если вы выходите за рамки оного, то Rails бьёт Sinatra.

Действительно, большинство людей, скорее, согласятся что Rails более ориентирован на большие проекты, в то время как Sinatra лучше подойдёт для микроприложений и API. Дэвид продолжает, поясняя правило выбора между Rails и Sinatra, которое он приобрёл с опытом:
Если в вашем приложении 5-10 конечных точек, то выгодно использовать Sinatra для собственноручного решения. Особенно, когда сама структура контроллеров может поместиться на 1-2 страницах кода, – великолепно, если это можно запустить одним файлом.

Рик Олсон с Github подтверждает, что Sinatra действительно является великолепным выбором для небольших проектов:
Sinatra действительно замечательно работает как API, а также на малых сайтах (внутренние приложения, Github Jobs и т. д.)

Дэвид Хайнемайер Хенссон объясняет, почему Rails становится настолько хорошим выбором, когда дело касается построения больших веб-приложений:
Rails позволяет людям делать выбор между лучшими технологиями (“лучшими” их окрестил я и сообщество Rails) и в этом кроется большая часть его успеха… Я изменяю Rails каждую неделю, чтобы он лучше соответствовал идеальному, в моём представлении, фреймворку.

Константин Хаас делится своим энтузиазмом по поводу Rails и его философии:
Я люблю Rails. Rails созидал наше представление о веб-приложениях. Rails решает для вас такие проблемы, которые Sinatra решить не в силах, поскольку он может сделать больше предположений о вашем приложении. Для вас уже всё установлено вне зависимости от того, понадобится оно вам или нет, самый большой изъян в архитектуре Rails – принятие того, что всё должно решаться с помощью одного инструмента.

Полученным возможностям, которые вам, в общем-то, в Rails и не нужны, определённо сопутствуют потери, последние, однако, компенсируются тем, что вы обретаете большое количество возможностей, в которых действительно нуждаетесь. В конце концов, это может себя оправдать, особенно когда дело касается большого проекта. Однако, не все согласятся с тем что большой проект может быть реализован только на Rails. Джоффри Грозенбах из Peepcode Screencasts считает что это “устаревший взгляд, который справедлив лишь для Sinatra в 2008, но, определённо не в наши дни”. Он обратил внимание на великолепное приложение Gaug.es, построенное на Sinatra, как на пример, который доказывает, что он (Sinatra) более чем подходит для создания эксплуатируемых крупномасштабных сайтов.

Несмотря на вышесказанное, Константин Хаас обращает внимание на потенциальную проблему при использовании Sinatra для создания больших приложений:
Создание более сложных приложений на Sinatra (или, скорее, использование Sinatra среди числа прочих приложений) заставит разработчика значительно больше времени потратить на обдумывание архитектуры и инструментария. Это как преимущество, так и недостаток.

Некоторые разработчики наверняка к этому отнесутся как к преимуществу, если они предпочитают строго контролировать происходящее в своём приложении и осознавать то как это всё соответствует друг другу. Джоффри Грозенбах считает, что это жертва, которая себя оправдывает:
Стабильность – наибольшее преимущество Sinatra. Вы жертвуете своими собственными дизайнерскими решениями ради удобств от нескольких генераторов Rails. Написание на Sinatra может подарить разработчикам и бизнес API стабильность, поскольку фреймворк меняется редко. Вы владеете своим кодом, и вы решаете, когда его стоит изменить.

Он продолжает объяснять, почему Sinatra является превосходным кандидатом для построения приложений:
Каждое из моих новых приложений начинается с Sinatra и, обычно я прихожу к выводу, что кроме Sinatra вместе с несколькими Rack плагинами, мне больше то ничего и не нужно, небольшая CouchDB библиотека и Backbone.js в качестве фронт-энда.

Соу Шеонг Чанг из Yahoo и автор Клонирования Интернет Приложений с Ruby придерживается простой модели разработки:
Sinatra выполняет всё что мне нужно на базовой платформе, а всё остальное либо уже обеспечено облачными платформами и сервисами (например, Heroku и его экосистема аддонов), либо я могу реализовать с помощью гемов. А для всего оставшегося я могу написать код собственноручно.

На самом деле эту идею можно было бы использовать как более совершенный подход в применении Sinatra – создания своего собственного специального фреймворка, который полностью удовлетворяет ваши нужды. Начните с Sinatra, а затем добавьте гемы, которые реализуют нужные вам возможности, чтобы создать собственный индивидуальный фреймворк. Нечто подобное реализовано в проекте Padrino.

Дэвид Хайнемайер Хенссон не видит в этом смысла:
Разбиение всего на маленькие частицы и принуждение разработчиков к собственноручному сбору всего и вся является антитезисом всего того ради чего создавался Rails и того как он победил в игре фреймворков. Были затрачены десятки тысяч человеко-часов ради того, чтобы мы достигли этой цели. Попытка это воспроизвести – пустая затея.

Хотя контроль над происходящим внутри вашего приложения может быть хорошей идеей, Константин Хаасе предупреждает, что это может отнять много вашего времени:
Главным недостатком Sinatra, который не решает за вас проблему, является именно то, что Sinatra её не решает. Вы должны самостоятельно с нею разобраться. Это может привести к тому, что вы затратите неоправданно большое количество времени, пытаясь её решить.

А если у разработчиков ограничен бюджет, то у них этого времени банально может и не быть. Дэвид Хайнемайер Хенссон обеспокоен, что применение Sinatra при попытке заново изобрести колесо чревато потерей огромного количества времени впустую:
Скорее всего, вся та работа, которую вам предстоит сделать, ради воспроизведения решений, уже предоставленных в Rails, незамедлительно перечеркнёт простоту использования Sinatra. Мне жаль того человека, который пытается в одиночку построить Basecamp, GitHub, Shopify или какие-либо другие крупные приложения в Sinatra. Rails — огромный и запутанный инструмент, т. к. он содержит решения большинства проблем с которыми сталкиваются большинство людей, которые трудятся над созданием приложения такого масштаба. Попытка воссоздать все эти решения вручную – всё что угодно, но только не простота.

Райан Бейтс, ведущий Railcasts считает, что преимущество при использовании Rails состоит в сбережении времени, когда проект начинается с нуля:
Стандартное приложение Rails предоставляет многое из того что мне нужно и что потребовало бы дополнительных установок в Sinatra. А это придаёт дополнительную быстроту при разработке на Rails.

Это же мнение высказывает Рик Олсон, который считает, что Rails облегчил воплощение проекта GitHub.
Я думаю, что в течение первого года Rails был главным инструментом для основателей [GitHub]. Им удалось воспользоваться преимуществами некоторых возможностей Rails более высокого уровня и быстро выполнить итерацию.

Чад Фоулер (со основатель RubyConf) цитирует мантру Rails о “соглашении по конфигурации” как ещё одну причину благодаря которой Rails ускоряет разработку больших проектов:
Генераторы и структуры Rails дают соглашения, которые не предоставляет Sinatra.

Проблема в том, что эти соглашения иногда сродни смирительной рубашке, Rick Olson обращает внимание на такие случаи:
Rails хорош, если для вас приемлемы его догматичные соглашения и вы придерживаетесь “золотого пути”.

В отличие от него у Sinatra нет каких-либо ограничений, Сатиш Талим из Ruby Learning привел великолепную цитату Арона Квинта, которая это поясняет:
“Sinatra следует абстрактному шаблону: НННВШ (Нам Не Нужны Вонючие Шаблоны). НННВШ означает, что Sinatra более чем гибок и не предопределяет то, каким образом вы будете организовывать доменную или бизнес логику. У него нет явно заданной структуры папок, отсутствует абстракция баз данных по умолчанию и нет ограничений касательно того где и как его применять”.

Sinatra наиболее привлекателен там, что позволяет определять как и каким образом от и до структурировать приложение. Построение на Sinatra может дать свободу, т. к. вы не ограничены в размере, структуре или потоке работ. Вы можете построить API, веб-приложение или запаковать свой код в гем.

Возможно, некоторых удивит тот факт, что Дэвид Хайнемайер Хенссон тоже обожает простоту Sinatra:
В прошлом я применял Sinatra и мне он очень нравился. Он предлагает совершенно другой подход, который великолепно подходит для решения задач значительно меньшего круга, однако решает их действительно превосходно.

Так есть ли у Sinatra такое преимущество, которые бы ему захотелось перенести в Rails?
По сути, в Sinatra нет ничего такого из за чего бы мне захотелось переделывать Rails по-другому.

Однако он всё же признает, что в Rails практически полностью скопирована одна из самых крутых возможностей Sinatra:
Мы хотели добавить в Rails режим единого файла (single-file mode), но отказались от этого, зачем нам оптимизировать то, с чем Sinatra и так прекрасно справляется?

Вне всякого сомнения, Rails предоставляет огромное количество возможностей, но нередко среди них имеются те, в которых вы не нуждаетесь или они не работают именно так, как вам необходимо. В Rails 3 была предпринята попытка сгладить это настолько, насколько это возможно – путём разъединения некоторых из возможностей различного вида, что в результате может дать более лёгкий и конфигурируемый продукт, на что и обращает внимание Чад Фоулер:
Сам по себе Rails не такой уж и “тяжёлый”, особенно если принять во внимание его текущую возможность уменьшения в размере по своему усмотрению.

Rails 3 привнёс много конфигурационных опций, позволяющих подстроить приложение под выполняемую для вас задачу. Несмотря на то, что существует возможность избавится от хлама, Константин Хаас предупреждает, что оставить всё как есть нередко кажется слишком заманчивым, что приводит к раздуванию:
В моей практике приложения на Rails часто становятся единым монолитным приложением. [Отказ от Rails] даёт в итоге модульность, гибкость, быстроту на тестах и масштабируемость. Однако вы можете добиться такой же архитектуры, если будете аккуратно конструировать Rails приложения, дело в том, что поступить иначе (не делать этого) слишком заманчиво.

Дэвид Хайнемайер Хенссон не видит в этом проблемы и полагает, что вне зависимости от того пользуетесь ли вы всеми возможностями или нет, Rails подойдёт в любом случае:
Физически удалив участок кода Rails, который вы не используете, вы не получите ничего полезного. Никто не заставляет вас пользоваться всеми возможностями. [Многие возможности Rails] всецело опциональны и могут быть полностью отключены, если они вам настолько мешают.

Rails становится легче, а Sinatra показал что может справится с тяжёлыми задачами, это означает что они всё больше сопрягаются. Чад Фоулер считает, что на самом деле и Sinatra и Rails могут применяться в широком кругу проектов:
Я думаю, что на самом деле каждый из них можно использовать в любом из противоположных случаев. Полагаю, что в конце концов, это субъективный выбор.

В целом все согласятся, что “для работы должен быть подобран подходящий инструмент”, но их сопряжение означает, что решение часто сводится к персональному выбору. Sinatra может дать больше контроля над архитектурой, но будут ли дополнительные усилия достойной тратой вашего времени (или вашего клиента, что более важно)? Райан Бейтс подводит итог касательно типов личности и того какой фреймворк они выбирают:
Я полагаю, что в конце концов это зависит от того что вы предпочтёте: начать налегке и добавлять по надобности, или начать с тяжёлого, а потом удалять что-либо, если необходимо избавиться от веса.

Джоффри Грозенбах предполагает, что существует два абсолютно разных типа разработчиков:
Я думаю, что среди Ruby разработчиков есть существенное различие: есть те, кто предпочитают малый размер, легковесность, быстроту, эксплицитность (explicit) и расширяемость; а есть те, кто предпочитает фреймворки с полным набором возможностей. Sinatra удовлетворяет запросы первых, а Rails – вторых. Так что я не думаю, что Sinatra вытеснит Rails. Просто это другая философия, которая нравится определённому виду разработчиков.

Но, возможно, вам не потребуется совершать выбор между ними. Автор, Дейв Кеннеди, член Ruby Source, обращает внимание, что Rails и Sinatra в общем то довольно неплохо вместе работают:
Если в процессе разработке 2 фреймворка стали друг друга дополнять, то это говорит о том, что я в настоящий момент работаю над многоарендным приложением (multi-tenant), которое интенсивно эксплуатирует Sinatra внутри Rails, крутая вещь. Sinatra позволил мне придать своему приложению модульность, прежде сделать это настолько просто было мне не по силам.

Множество людей поняли, что благодаря возможности встраивать Sinatra в Rails 3+ приложения, действительно можно получит лучшее из того, что предлагают два мира. Чад Фоулер считает, что концепция выбора между одним и другим бессмысленна сама по себе:
Вам не стоит слишком беспокоиться о выборе, он совершается за вас благодаря возможности встраивать Sinatra приложения в приложения на Rails 3.

Джоффри Грозенбах полагает, что это придаст приложениям более модульный вид:
Много людей встраивают Sinatra приложения в приложения на Rails. Это имитирует дизайн Django фреймворка, где (основное) приложение состоит из множества более мелких приложений, каждое из которых ответственно за определённую часть в оном (и часто могут быть повторно использованы другими приложениями).

Дэвид Хайнемайер Хенссон также считает, что это было бы неплохим способом для выполнения задач:
У вас даже может быть микроприложение на Sinatra внутри Rails структуры. Такое применяется на Github для решения нескольких задач. Замечательная модель.

Рик Олсон объясняет насколько часто на GitHub используется эта пара в тандеме:
Я очень рад, что Rack и Sinatra настолько тесно интегрируются с [Rails]. Вместо того, чтобы подстраивать Rails под свою волю ради специфической возможности, вы можете перенаправить запрос на Sinatra или оконечную точку Rack и выполнить именно то что необходимо.

Все согласятся с тем, что для каждого из этих двух фрейморков в экосистеме Ruby есть определённое место. В сущности, они превосходно вместе работают, и до определённой степени дополняют друг друга множествами способов. Похоже, немало людей считает, что наилучшим образом два фреймворка работают именно вместе, и удовлетворяют различные нужды в общем плане. Различные виды разработчиков совершают свой выбор по вкусу если решение лежит в поле сопряжения инструментов. Каждый из двоих делает лишь то, с чем хорошо справляется, и каждый является исключительным примером хорошей практики; настолько хорошей, что эти инструменты были скопированы в другие языки бесчисленное множество раз. Джон Нунемакер с GitHub красиво и лаконично это подытожил:
У каждого из них есть своё место. Rails будет лучшим вариантом в том случае, если вам просто необходимо разобраться с задачей. Для простых вещей лучшим выбором будет Sinatra, а также тогда, когда вы хотите всё контролировать и придерживаться собственных взглядов.

Нам, как сообществу, несказанно повезло, что у нас есть настолько хорошо разработанные инструменты, с такой хорошей поддержкой, да ещё и в открытом коде. И Rails и Sinatra превосходно справляются со всеми аспектам задач, поэтому можно с уверенностью сказать, что благодаря им у нас есть лучшее из двух миров.

А вы как считаете – вы пользуетесь каждым из них, или предпочитаете один другому? Думали ли вы над созданием собственного фреймворка, как альтернативе Rails? Оставьте внизу комментарий.

Оригинал статьи можно посмотреть здесь.
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 26

    +5
    Sinatra — замечательная штука, чтобы собрать что-то на коленке. Но это же просто набор методов, которые можно использовать для взаимодействия с клиентом по HTTP. Всё остальное придется писать руками, изобретать тысячу велосипедов.

    Как вообще можно сравнивать Sinatra с Rails? Это все равно, что сравнивать мотоблок с автомобилем.
      0
      Аналогичное мнение высказывалось в статье.

      Но это у Вас уже есть собственный опыт и сформированные взгляды. А как быть тем людям, которые только делают первые шаги по стезе Ruby? Я, к примеру, когда начинал изучать Ruby, понял, что браться сразу за Rails не стоит. И я не знал, что Sinatra — на самом деле не фреймворк. И я тоже задавался вопросом зачем придумали каждый из инструментов. В статье собрано множество различных мнений. В комментариях, будут ещё. Думаю, другим новичкам это будет на пользу.

      Про мотоблок и автомобиль спорить не буду.

        –2
        тем, кто делает первые шаги, нужны только безусловно и исключительно рельсы. Никаких сомнений и «но» здесь нет. В рельсах всё работает, есть всё что нужно и интернет наполнен ответами на все вопросы.

        Синатра — это для тех, кто представляет себе, как написать рельсы с нуля и очень хочет этим заниматься.
          +3
          вы меня, конечно, извините, то руби — это не только ваши рельсы, и далеко не всегда web-приложения.
            0
            Вы меня тоже извините, но для 90% новичков руби = рельсы. И я поддержу товарища выше, если бы мне в начале пути пришлось все писать руками вместо использования рельс, то наши пути бы разошлись. Это уже потом находишь всякие подводные камни и прочее, но в начале должны быть именно рельсы, имхо.
              –2
              не смешите меня рассказами про то, что есть руби вне рельс. Это такая же профанация, как ObjC вне Эппла.
                0
                Как Вы себе пресдавляете ситуацию, в которой Вы бы могли сказать: «Да, руби вне рельс есть»?
                Puppet, chef, vagrant, еще куча приложений — это не руби? Или их нет?
                Понятно, что объемы кода несопоставимы, но все же, отрицать наличие руби отдельно от рельс — как-то не очень корректно.
                  –1
                  например, у питона нет такой явной консолидации. У Руби есть.

                  Пока не появились рельсы, никому кроме вредного японца руби был нафиг не нужен
                    0
                    Почему же? Было и есть ему применение вне веб. Было бы оно никому не надо никто бы не писал для него расширения и не создавалось бы несколько реализаций (загляните не wiki).

                    А чего Вы Юкихиро Мацумото вредным называете? :-D
                      –2
                      Мацумото вредный, потому что он длительное время целенаправленно вредил рельсам.

                      С самого начала взрывного роста популярности рельс Матц испытывал смесь из ревности, раздражения и зависти по отношению к рельсам: ведь никто не воспринимал и не воспринимает его детище в отдельности от рельс.

                      В итоге длительное время на сайте руби вообще не было упоминания рельс. Было всякое невообразимейшее штако, но не рельсы.

                      Дальше пошел саботаж. Например, в 1.8.7-patchNNN Матц втихаря выкатил чудесный патч, поломавший нахрен ассоциации в рельсах. Очень тонко и филигранно: ошибку можно было найти очень не сразу.

                      Потом Матц устроил юникод. В приличных обществах за то, что он натворил, ставят к стенке, а потом отправляют исправлять содеянное, но тут не получилось. Он умудрился на два года (!) сорвать переход на новую версию руби, потому что выкаченные им апдейты принципиально не годятся для современного интернета, который весь на UTF-8.

                      В итоге получилось его угомонить только взяв на формальную работу в Хероку (я не ошибся?), где ему приказали перестать вредить рельсам и его японское чувство ответственности теперь в конфликте с его отношением к гайдзиновской поделке.

                      Всё, что вы видите на ruby-lang — это именно попытка хоть как-то доказать, что не рельсами едиными. По факту это не более чем попытки заявить о существовании у Монголии своей космической программы.
                        0
                        Т. е. Вы хотите сказать что Хайнмайер сделал из штако конфетку?
                          0
                          Да, безусловно.

                          Посмотрите на куски рубийного кода, который был до рельс. Это просто инфернальный ужас какой-то. Только в рельсах появился code conventions и был наложен негласный мораторий на большинство практик из дорельсового руби.

                            0
                            О каких конкретно инструментах идёт речь?
              +3
              Как можно изучать фреймворк, не зная особенностей языка на котором он написан?

              Вот потому я и начал штудировать просто Ruby, попутно пытаясь построить маленькие проекты на Sinatra.

              Собственный фреймворк пишут люди с солидным стажем работы на том или ином языке; те кто знают тонкости как языка так и аналогичных фреймворков на которых он написан.

              Однажды читал статью на хабре (жаль, не могу её найти и кинуть ссылку), так там рассказывалось о том, что когда у программиста знания достигают определённого уровня возникает искушение создать собственного «наполеона». Некоторые конторы даже вкладывали солидные суммы денег на создание собственного детища. Да вот только далеко не всегда получается настолько практичный инструмент, как ожидается. И для многих эта тема — как больная мозоль.

              Опять таки, подчеркну, речь шла не о новичках, а об уже сформировавшихся специалистах.
                0
                Мне кажется с точки зрения времени на получение результата — Синатра попроще будет.

                Там надо — установить руби, и гем, и заработает простейший hello world, что-то вроде этого:

                1. Установить Ruby

                2. Установить Sinatra:
                $ gem install sinatra
                

                3. Написать hi.rb руби файл:
                require 'sinatra'
                
                get '/hi' do
                  "Hello World!"
                end
                

                4. Стартовать:
                $ ruby hi.rb
                


                5. Результат на http:// 0.0.0.0:4567/hi в браузере увидим:
                Hello World!

                  0
                  А дальше чего? Делаем формочку руками и получаем PHP.
                    0
                    1. Руби
                    2. gem install rails
                    3. rails new blog
                    4. cd blog
                    5. rails g scaffold Post title:string text:text
                    6. rake db:migrate
                    7. rails s
                    8. На localhost:3000/posts у нас уже готовый блог, а не просто непонятная надпись в браузере :)
                      +1
                      Есть два типа людей — одни покупают готовый, отлично выглядящий дом, живут в нем полгода, а когда из подвала начинает вонять дерьмом, берут фонарь и спускаются посмотреть, что же там такое. Оказывается канализацию прорвало, надо чинить.
                      Другие покупают стройматериалы, делают проект, льют фундамент и.т.д.

                      Не имею ничего против ни первых, ни вторых. Просто люди по-разному получают фан.
                        0
                        Ну изначально речь шла о новичках же. Для новичка лучше купить свой дом и начать жить в нем узнавая про канализацию или фундамент, или сидеть на улице обложившись книгами по строительству?
                          +1
                          а зачем нужны глупые аналогии, которые не имеют ничего общего с реальностью?
                            0
                            Во первых, из подвала воняет крайне редко, а канализация может накрыться вне зависимости от метода получения дома в собственность. Во вторых, воторой тип людей исчезающе мал, если вообще существует, так как, если вашу мысль экстраполировать, то и процессоры покупать плохо, нужно паять самому, а то х86 давно морально устарело, а поскольку такого не наблюдается, то и вывод о втором типе людей напрашивается сам. Так что, подход, мягко говоря не живучий.

                            О зле: хватит пиарить второй тип людей! Каждый джуниор хочет быть вторым типом людей, которых не существует или которые вымирают. Скафолды пишут руками сами, якобы чтобы лучше запомнилось, в результате, тратят кучу времени на то, что генераторы им сами нагенерируют, пишут сами авторизацию, когда все уже придумано до нас, засыпали форумы вопросами о хранении файлов при загрузке из браузера. В общем, занимаются эволюцией, забывая про то, что рождаются сразу людьми, а не тратят миллиарды лет для эволюции из бактерии. Это все выростает в велосипедофилию, и выкорчевать из головы это становится крайне тяжело, а делом заниматься вообще некогда.
                  +1
                  Про Padrino даже не упомянули.
                    0
                    Почему же, было упоминание.
                      0
                      Да, прошу прощения, не заметил. Но по-моему сравнивать как раз стоило Rails и Padrino.
                    0
                    Из новых фреймворков, не указанных по первой ссылке, lotus выглядит очень многообещающе; а также roda от Jeremy Evans (автора Sequel), как утверждается, по бенчмаркам обходит даже синатру. Но это, конечно, не лучший выбор для новичков.
                      0
                      В качестве примера создания большой системы, на Ruby, могу привести примеры проектов из CloudFoundry (спонсируемого VMWare), например, BOSH:

                      Cloud Foundry BOSH is an open source tool chain for release engineering, deployment and lifecycle management of large scale distributed services.

                      github.com/cloudfoundry/bosh

                      более 8 тыс коммитов, более 100 контрибутора.

                      На мой взгляд можно достичь дао изучая архитектурное решение, или просто читая код :) И некоторые элементы системы сделаны на базе Sinatra (например: bosh-registry).

                      И вот интересный для изучения пример: Cloud Controller

                      И другой пример — архитектура информационной системы для Британского правительства — AlphaGov так же включает системы на Sinatra, например govuk_content_api (Content API layer for GOV.UK)

                      Only users with full accounts can post comments. Log in, please.