2009-11-16 2 views
10

Я работаю над проектом для клиента ИТ-компании, в которой я работаю, и я убежден, что Rails идеально подходит для этого. У меня есть встреча на следующий день или около того, где я боюсь, что меня обманут «почему Rails?». и, без сомнения, целая куча риторики типа «Rails не масштабируется», «Rails - это просто CMS», а тысячи других мифов, похоже, имеют о Ruby on Rails.Busting Ruby on Rails Myths

У нас все есть аргументы в отношении того, как Rails не масштабируется, его трудно развернуть или он будет взорваться в ваших руках в любой момент. Для тех из нас, кто ежедневно использует Rails, мы знаем это точно так же, как любой другой язык или фреймворк. Похоже, что существует много дезинформации о RoR, и часто Rails получает плохую упаковку. Чтобы помочь мне с этой встречей, я надеялся составить список мифов - возможно, один миф за каждый ответ - и мы можем проголосовать за мифы, которые мы слышали раньше, - чтобы устранить Страх, Неопределенность и Сомнение, которые часто обманывают правду о Rails.

После некоторого поиска в Интернете я нашел this blog post, который является именно тем, что я хотел бы сравнить здесь. Как говорит Дэвид Heinemeier Hansson в посте:

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

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

Давайте уточним!

+8

Возможно, вы захотите попытаться приблизиться к нему с более объективной точки зрения - спросите себя, что такое * потенциальные проблемы, и затем исследуйте, являются ли они проблемами на самом деле, для проектов, которые вы будете делать. Если вы подходите к нему с точки зрения «Rails идеально подходит для этого проекта, любые недостатки должны быть мифами», вы вряд ли получите точную картину. –

+1

Потому что не может быть ни одного правильного ответа, возможно, сделать это сообщество wiki. –

+0

Я признаю, что он не полностью объективен - и что нет единственного ответа (так что я создал сообщество wiki), но его больше узнать о том, какие неправды существуют в Rails, потому что любой аргумент, который я получаю от клиента, о * not * using Рельсы, не собираются исходить из хорошо изученной точки зрения. Я пытаюсь вооружиться против нелогичных или «выдуманных» аргументов против его использования, а не наоборот. – Ash

ответ

6

Миф: «Рубин на Rails не масштабируется»

Бюст: Это не конкретный, ответственный вопрос. Просьба уточнить.

Сказать, что безотносительно технологии «не масштабируется» звучит очень профессионально и очень предприимчиво, но это не ясный вопрос. Это просто ленивый способ отклонить неизвестное/недоказанное. Прошу разъяснений:

«Что именно вы имеете в виду под« шкалой »и как вы измеряете его в данный момент?»

Это может означать:

  • Максимум пользовательских сеансов
  • Среднее время отклика заданная нагрузка
  • Пропускная способность данных параллельных сценариев на сервере в установленное время.
  • ... трудности с организацией проекта, чтобы на нем могла работать большая команда разработчиков.

Существует множество способов иметь дело с «шкалой», но пока вы не знаете, с кем вы имеете дело, не всегда очевидно, что с этим делать.

Есть множество решений рубина на основе, в том числе

  • кэширования фрагментов HTML
  • шардинга приложения на несколько баз данных
  • предварительного вычисления работы, которая разделяется между пользователями
  • толкающих много рендеринг рендеринга в AJAX/Javascript, так что это происходит на клиенте
  • с использованием интерфейсного веб-сервера более эффективно
  • просто используйте больше оборудования (т. время разработчика дорого & цен аппаратных падают), но этот подход зависит от неглубоких темпов роста спроса
  • делает менее интерактивно и иметь больше пакетной работу
  • делает только часть работы в рубине - например, существующий устаревший бэкенд + рельсы фронтэнда, или, может быть, транзакции через функциональную систему программирования + рельсы FRONTEND

Если претендент не может прийти с определенным значением «масштаб», то это не действительный интерес.

Однако если Претендент приходит с что-то конкретным и измеримым, то я бы использовал в ограниченном по времени, спайке решения (http://c2.com/xp/SpikeSolution.html), чтобы вернуться с некоторыми числами - и, возможно, несколько вариантов, как это сделать Это.

4

Сделать аргумент с единственной точки зрения, которую клиент понимает, деньги!

Покажите, как долго вы думаете, что потребуется сделать в Java, JSP или в зависимости от того, какая из них является их нынешней технологией, а также «за» и «против», например, проще получить разработчиков. Затем укажите временные рамки в Ruby, которые наверняка будут более низкими затратами на разработку, но также за счет того, что администраторы должны развернуть другую систему, возможно, сложнее набрать персонал, который знает Rails и т. Д. Свои деньги они дают им факты и позволить им принять решение.

В ответ на конкретные критические замечания, которые компания может иметь против Ruby on Rails по сравнению с их собственными системами, существует множество причин, которые может дать компания, некоторые из которых не являются специфичными для Ruby или Rails, например, они уже имеют много Java-разработок в доме или существующей инфраструктуре, написанной на Java, которая всегда будет проще использовать с той же языковой системой, как Java. В любом случае, чтобы ответить на ваши конкретные вопросы:

1) Почему рельсы? Простые, Rails «спроектированы» для создания веб-сайтов и делают эффективную работу.Найти некоторые статистические данные, чтобы поддержать Вас (я не говорю, что статистические данные в связи являются точными, но номера всегда будет произвести впечатление на клиента)

http://www.theserverside.com/news/thread.tss?thread_id=33120

2) Рельсы не масштабируется

http://trak3r.blogspot.com/2008/03/rails-doesnt-scale.html

3) Rails - это просто CMS? Если они строят CMS, тогда рекомендуем Drupal, а не Rails

Думаю, вам придется думать о своих ногах, когда вы отвечаете на вопросы своих клиентов, и им захочется, чтобы кто-то понимал другие рамки, кроме как только Rails, как использовать подходящий инструмент для работы на правильном пути

+0

Денежные переговоры с типами Corp. +1 –

+0

Это не совсем то, что подразумевается под духом «вопроса». Пока вы делаете действительные баллы, не совсем то, что подразумевалось. – Ash

1

Миф: Трудно нанять хороший рубинский программист Rails.

(На самом деле, я не могу разорить его, что это всего лишь идея потенциального мифа Кто может, пожалуйста, редактировать этот или создать еще один ответ.)

+0

Что в этом плохого? Количество разработчиков Rails - или качество разработчиков Rails –

2

Миф: Rails не доросли чтобы иметь множество затвердевших библиотек с открытым исходным кодом, построенных вокруг него, нужно быстро и надежно реализовать крупномасштабный проект.

Bust: На самом деле, существует огромное количество драгоценных камней и плагинов, доступных для сообщества RoR, многие из которых были опробованы и найдены истинным для активного сообщества. Ресурсы не только там, но и просты в управлении с помощью встроенной плагиновой архитектуры «gem» и Rails. Худший сценарий: вы не можете найти этот идеальный драгоценный камень или плагин. В этом случае вы можете легко написать свой собственный или заимствовать из мира Java, если используете JRuby.