Ruby on Rails, кажется, служит громоотводом для дискуссии. Сердце большинства дискуссий - заявления об удивительной производительности. Автор серии "Пересекая границы" Брюс Тэйт показывает, что Rails не является просто более лучшим молотком; это другой тип инструмента. В данной статье рассматриваются компромиссы и проектные решения, которые были приняты, для того чтобы сделать Rails таким производительным в своей нише продуктов. Затем рассматриваются идеи, инспирированные Rails, которые должны привлечь большее внимание в Java™-сообществе.

Ruby on Rails (также известен как Rails) представляет собой среду Ruby для интернет-приложений, поддерживаемых базой данных. Я сейчас использую Rails для двух различных приложений, а прежде участвовал еще в двух других проектах. Для готовящейся книги "От Java к Ruby" (см. раздел "Ресурсы") я взял интервью у многих Rails-разработчиков (как людей, которые преуспели в использовании этой среды, так и у разочаровавшихся в ней), создателей среды и главного автора флагмана книг по Rails "Динамичная Web-разработка с Rails" (см. раздел "Ресурсы"). Теперь я начинаю понимать, почему среда Ruby on Rails стала такой успешной.

Очковтирательство и скептицизм

Дебаты о Rails в Java-сообществе идут интенсивно, и пока нет признаков их затухания. Сторонники Rails хвастаются невероятной производительностью, по некоторым утверждениям, 10 к 1 по сравнению с Java-разработкой. Как у всякого Java-разработчика, вашей естественной реакцией будет недоверие к любым заверениям о страшной производительности, поскольку вы это слышали и раньше и были разочарованы. Адвокаты Java настаивают на том, что Ruby on Rails является игрушкой, которая не масштабируется, производит плохой код и не работает за пределами простых приложений. Но поскольку восхваления Rails продолжаются (часто, из надежных источников), возможен более благоразумный подход к пониманию того, что Rails делает хорошо, и привнесению этих идей обратно в платформу Java. В данной статье я рассмотрю основные функциональные возможности (скрытую изюминку), составляющие сущность высокой производительности Rails.
    
О данной серии статей

В серии " Пересекая границы " ее автор Брюс Тэйт продвигает идею о том, что современные Java-программисты хорошо поступают, изучая другие подходы и языки. Панорама программирования изменилась после того, как технология Java явно стала лучшим вариантом для всех разрабатываемых проектов. Структуру Java-среды формируют и изменяют другие интегрированные системы, а концепции, с которыми вы познакомились в других языках программирования, могут усовершенствовать ваше Java-программирование. Код на Python (или Ruby, или Smalltalk, или ... заполните многоточие), который вы создаете, может изменить ваш подход к Java-кодированию.

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

Философия Rails

Как бы вы ни напрягали воображение, интегрированная среда Ruby on Rails не является традиционной средой разработки приложений. Основатель Rails Дэвид Хайнемайер Хэнсон (David Heinemeier Hansson) часто называет эту среду самоуверенным (opinionated) программным обеспечением и с радостью разбивает устоявшиеся соглашения. Дэвид принял строгие философские решения, и интегрированная среда четко им подчиняется. Одними из основных решений, пропитавших Rails, являются:

    * Плавная интеграция: Rails блестяще использует наилучшие свойства языка программирования Ruby. Он расширяет Ruby таким образом, что иногда трудно сказать, где кончается Ruby и начинается Rails. Также заметна отличная интеграция Active Record (механизм персистенции Rails) и среды Модель-Представление-Контроллер (model-view-controller - MVC). Например, вы можете написать три строки кода, создать таблицу и затем сразу же сгенерировать пользовательский интерфейс для этой модели.

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

    * Низкая повторяемость: Не повторяйтесь (Don't Repeat Yourself, или DRY) - вот традиционный лозунг в Rails-сообществе. Разработчики среды Rails стремятся абстрагировать повторяющиеся задачи методами, часто выглядящими как расширения языка Ruby. Как вы видели в третьей статье данной серии, стратегия метапрограммирования в Rails усложняет работу каждой строки кода.

    * Немедленная обратная реакция: При работе в Rails большая часть того, что вы делаете, может вызвать немедленную обратную реакцию. Вы пишете строку кода и сохраняетесь, а ваше изменение становится активным при загрузке следующей Web-страницы. Миграции могут стать видимыми немедленно после обновления вашей базы данных.

    
Практический фундамент

Мотивы, лежащие в основе Ruby on Rails, строго основаны на практическом опыте. Среда Rails выросла из практического использования в разработке популярного приложения по управлению проектами Basecamp (см. раздел "Ресурсы").

Концентрация на области применения

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

Я бы высказал догадку, что примерно половина создаваемых в настоящее время Web-приложений использует базы данных. То есть, определенно, Rails - это специализированный продукт, но его специализация велика и важна. Специализация в этой области дает Rails огромные преимущества, объясняющие большой эффект, который он может обеспечить. Концентрируясь на проектах в своей области, Rails-разработчики могут использовать краткие приемы, которые не могут обеспечить другие интегрированные системы. Такая специализация часто жертвует гибкостью ради простоты.

Новые приложения, использующие базы данных, предлагают оберточный (wrapping) подход вместо подхода с отображением. Как вы видели в первой статье данной серии, программы Rails предполагают наличие соглашений в модели данных. Rails-приложениям нужен фрагмент кода модели, используемой в Java-приложениях. Если вы создаете вашу схему специально для Rails-приложений, такая философия работает хорошо. Если вы хотите приспособить существующую схему в Rails, все становится не так гладко.

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

    * Model-view-controller: MVC-среда Rails, называемая Action Pack, настроена на Web-доступ и реализует широко известную стратегию, называемую Model 2 (см. раздел "Ресурсы"). Rails-версия имеет оптимизированную интеграцию между контроллером и представлением, которая минимизирует конфигурацию и автоматически делает доступным для представления переменные экземпляра контроллера.

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

    * Архитектура: Среда Rails упрощает архитектуру, обеспечивая готовые сценарии, генерирующие компоненты приложения, которые придерживаются общих архитектурных решений, таких как страничное и пофрагментное кэширование, двухуровневый дизайн; среда для тестирования, разработки и производства.

    * Инструментарий: Rails-инструментарий специализирован для Web. Системы поддержки ведения журналов, работы с контрольными точками, профайлера и тестирования приспособлены для Web-приложений и разрешены для двухуровневой работы.

Но пневматические молотки никогда не заменят обычный молоток, поэтому мы поступили бы неразумно, ожидая полной замены. Молоток всегда сможет сделать вещи, которые пневматический молоток сделать не в состоянии. Rails никогда не будет инструментом корпоративной интеграции, объектно-реляционного отображения или универсальных Web-служб. Лучшее, что вы можете ожидать от Rails - это то, что он является специализированным инструментом, который отлично работает в своей нише.

Опыт разработчика

Углубившись в детали Rails, вы начинаете понимать, насколько радикально иным может быть опыт Rails-разработчика. Быстрый цикл обратной реакции, интерактивные консоли на каждом шагу, соглашения по конфигурации - все это совершенствует опыт разработчика в направлениях, часто недоступных в Java-системах.

Цикл обратной реакции

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

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

Интерактивность

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

Для просмотра этого средства в действии создайте простое Rails-приложение, сгенерируйте контроллер, запустите сервер и программу работы с контрольными точками. Убедитесь в том, что имеете доступ к окну breakpointer, поскольку будете использовать его тогда, когда Ruby встретит контрольную точку. В системе последовательность действий такова:




Если вы работаете в UNIX® или Mac OS X, просто запустите ваш сервер в отдельном процессе.

Введите или скопируйте следующий код в файл app/controllers/samples_controller.rb:




Протестируйте код, загрузив страницы localhost:3000/samples и localhost:3000/samples/show.

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




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

Вторым средством, упрощающим отладку, является консоль Active Record. В первой статье этой серии вы видели, что Rails поставляется также со сценарием, позволяющим вам работать с персистентными объектами в интерактивном окне Ruby-интерпретатора. Я часто нуждался в такой возможности в моих Java-приложениях. Вы можете кодировать персистентную модель, сделать изменения в базе данных через модель и выполнить какие-либо запросы к базе данных для просмотра их влияния на систему. Было бы неплохо иметь подобную возможность в запросах Hibernate-объектов.

Соглашение по конфигурации

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




Никакой конфигурации не нужно, поскольку Rails сделает предположение о названии таблиц (people), названии идентификатора объекта и первичного ключа (id), названии связанной таблицы (departments), названии внешнего ключа (department_id) и названии внешнего класса (department.rb), основанное на соглашениях по наименованию. Код остается легким, выразительным и очень простым по внешнему виду, независимо от того, что вы с ним делаете, - пишете, читаете или обслуживаете. Замыслы сразу же понятны.


Чему могут научиться Java-разработчики?

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

    * Разрешить горячее развертывание, при котором сокращается цикл обратной реакции, или поддержку сред, которые допускают горячее развертывание. Этот приоритет должен быть намного выше на стороне Java, чем он есть сейчас.

    * Использовать меньше XML и больше соглашений. Соглашения не исключают конфигурации, поскольку вы можете использовать соглашения для указания значений по умолчанию и конфигурации для переопределения соглашения. Используя такой подход, как это делает Rails, вы получаете лучшее: лаконичный код с меньшей повторяемостью без потери гибкости.

    * Работать по включению большего числа языков сценариев, в том числе BeanShell (см. раздел "Ресурсы"), для исследования Java-классов во время процесса отладки.

    * Использовать правильные инструменты для выполнения работы. Не обязательно обращаться к Hibernate только для персистенции, или к Struts только потому, что вам нужно Web-приложение.

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

Автор: Брюс Тэйт
Переводчик: IBM
Сайт переводчика: http://www.ibm.com

[Текст удален]

Это сообщение отредактировал(а) BuShaRt - 2.5.2007, 15:15