Каковы самые прохладные функции Ruby on Rails, почему выбирают его? [закрытый]

• Динамические средства поиска ActiveRecord:

  Person.find_by_name_and_company_id('Jorge Luis Borges', 42)
  

• rjs, пишущий JavaScript в рубине:

  page['element_id'].insert_html :bottom, :partial => 'comment'
  

• Обзор ActiveRecord

  class Shirt < ActiveRecord::Base
    named_scope :red, :conditions => {:color => 'red'}
    named_scope :dry_clean_only, :joins => :washing_instructions, :conditions =>  ['washing_instructions.dry_clean_only = ?', true]
  end
  

вызов Shirt.red запросит дб с "цветом = 'красное'" условие прохладная часть, это, если Вы комбинируете больше чем один объем, например:

      Shirt.red.dry_clean_only

это создаст всего один запрос, со всеми условиями и присоединяется необходимый для удовлетворения обоих объемов.

• Миграции ActiveRecord, способность управлять структурой дб и данными с помощью активной записи, точно так же, как в коде приложения, с минимальным sql использованием.

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

Некоторые из конкретных проблем, которые он решал:

• Начало быстро. Если вы хотите быстро запустить веб-приложение, что может быть лучше, чем инфраструктура, которая задает существующую структуру каталогов (основанную на MVC), с большим количеством генераторов кода и уже сделанным выбором для вас: такие компоненты, как библиотека JavaScript, поддержка тестирования, ORM и т. д. Вы можете не согласиться со всеми вариантами выбора, но вы можете принять их и иметь что-то, что будет работать для 80% или более проектов, и что-то поменять позже, если у вас есть предпочтения.

• Долгосрочная ремонтопригодность. Миграции дают вам возможность перемещать данные вперед по мере изменения кода, что происходит в любом реальном приложении, но большинство фреймворков не учитывают это вообще. Разделение всех частей вашего приложения в уже настроенной иерархии каталогов с областями для тестирования, базы данных, конфигурации и т. Д. Снова помогает долгосрочному обслуживанию вашего проекта.

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

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

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

Назвать несколько объектов:

• Многочисленное сообщество разработчиков (не говоря, что Python не делает),
• Конвенция по скалам конфигурации
• Может использоваться с JRuby/Warbler, чтобы заставить направляющие работать на серверах JAVA-приложения. Очень важный при попытке перетащить Предприятие в 21-й век (Django может использоваться с Jython для работы с серверами приложений, но менее опытен).
• Платформа MVC помогает сохранить Ваше приложение структурированным.
• Леса и генераторы для получения перемещения проекта.

Направляющие не пытаются быть единственным способом сделать веб-приложения, это не намерение. Это выполняет определенный набор потребностей.

Это не сравнение с Python - это - общий список вещей, которые я люблю.

• Я пишу намного меньше кода, чем я был бы в Java
• ... И код, который я делаю правильно, очень читаем и удобен в сопровождении
• Я очень редко должен думать, где некоторый код живет или как справиться с общей задачей - он просто имеет свое место (например, миграции встроены),
• Вы не заканчиваете тем, что использовали партию различных технологий на одном проекте (Java, EJB, В спящем режиме, JSP, SQL DDL, Муравей, XML, taglibs),
• Интерпретируемый, а не скомпилированный сохраняет Вас много времени разработки

Честно, мне нравится дизайн Django больше затем направляющие, но мне нравится рубин больше затем Python. Это - персональная вещь, потому что я знаю много людей, которые чувствуют противоположный путь, но я нахожу, что рубин один из самых изящных языков, которые я когда-либо использовал.

Одна из главных причин для меня - это возвращение удовольствия в веб-программирование. Внезапно все становится простым и доступным. вам не нужны месяцы хруста кода и не нужно тонны написанного кода. Вы можете сделать несколько довольно удивительных вещей всего несколькими строчками.

И это приятно :))

Моя основная мотивация для использования направляющих является рубиновой. Я коснулся большого количества языков, прежде чем я нашел рубин, и я никогда не чувствовал, что хорошо работал в любом из них. Когда я встретил рубин, все просто имело смысл. Это - красивый язык; Легкий выучить лишь трудно ведущему устройству.

Я использую направляющие, потому что это удовлетворяет моим потребностям как веб-разработчику и очень многофункционально.