Что делают на ruby on rails. Установка RoR на Ubuntu. Установка RoR на Windows

Решил посмотреть насколько отличается статистика год спустя.

Интересные (на мой взгляд) куски из статьи:

Список проектов работающих на Rails:

Когда вам нужен Rails?

Вы разрабатываете обычное веб-приложение. Вы ожидаете, что проект будет жить долго. Вам нужно, чтобы инструмент продолжал развиваться и жить, нужна поддержка от сообщества или от какой-нибудь компании, возможность нанять специалиста. В таком случае, Rails - прекрасный выбор. Альтернатив хватает, выбирать есть из чего. Но вы все равно выберете Rails, ведь это по-прежнему модно;-)
Вы предполагаете постоянное изменение требований и функционала, вектора развития проекта. У вас нет постоянной концепции продукта, она меняется и зависит от обратной связи с пользователями. Rails в этом случае отличный выбор.
Вам нужно “быстрое прототипирование”. Rails до сих пор хорош для этого. Альтернативы, конечно же, найдутся, но Rails очень хорош и в этом.

Когда вам не нужен Rails?

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

Таблицы я обновил
Вот эта забавная таблица сравнений по критериям популярности репозитория на GitHub и количества вопросов на StackOverflow (hotframeworks.com) говорит что Rails всё ещё в топе:

Согласно Google Trands , Rails тоже популярен в поисковых запросах в сравнении с сопоставимыми фреймворками.

Что может предложить стек Ruby/Rails менеджеру проекта

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

Важно понимать, что Rails предлагает не только стабильный и зрелый стек технологий и экосистему. Он предлагает постоянное развитие. Rails привносил и популяризировал много удачных решений и подходов. Он повлиял на многие фреймворки, иногда даже очень сильно. Просто вбейте в google "rails like + language". Rails-like фреймворки росли как грибы после дождя для многих популярных платформ - Java, Scala, NodeJs, PHP и даже Erlang. Вообще вся экосистема Ruby/Rails оказала влияние на инструменты разработки на других платформах. Инструменты развертывания приложений, пакетные менеджеры, менеджеры зависимостей, шаблонизаторы и препроцессоры. Если вы хотите быть на острие веб-технологий и не собираетесь ждать, пока это портируют на вашу платформу, тогда Rails - ваш выбор. Постоянное развитие, функциональность и помощь сообщества делают Rails отличным и надежным инструментом.

Что может предложить стек Ruby/Rails разработчику

Одна из особенностей подхода Rails это подход Convention over configuration. На практике это означает, что пока вы следуете соглашениям, вы избавлены от конфигурирования и настройки. Во всех компонентах и слоях абстракций. Если какое-то соглашение вам не подходит - окей! - у вас всегда есть способ настроить всё под себя. Фреймворк скрывает от вас сложность проблем и пока вы следуете соглашениям, все работает как по волшебству. Сложности начинаются когда соглашение вам не подходит.

Rails это удивительно модульный и настраиваемый инструмент. У вас есть штатный (предусмотренный разработчиками) способ расширить/переопределить поведение тех или иных компонентов. Вы можете встроиться в процесс отправки писем и модифицировать письмо. Например, вам нужно изменить тему письма так, чтобы на тестовом сервере все письма приходили с постфиксом "". Вам надо поддерживать визуальные темы для веб-страниц и динамически определять путь, откуда будут браться html-шаблоны? Легко - вам нужно просто переопределить отвечающий за это компонент (path resolver). Вам надо выполнять какой-то служебный код до начала обработки запроса вашим кодом? Встраиваете свой middleware в очередь стандартных.

Каждый, кто сталкивался с выбором фреймворка или стека технологий, в конце концов приходил к какому-то чек-листу возможностей, и выбор делался исходя из того, поддерживает конкретный фреймворк ту или иную возможность. Давайте посмотрим, что вы получаете, выбирая Rails. Вы получаете ORM - ActiveRecord. Как можно догадаться, используется одноименный шаблон доступа к данным. Вашу жизнь сильно облегчат принятые соглашения. Вам не надо ничего конфигурировать. Пока вы руководствуетесь стандартными соглашениями, вы не напишите ни строчки конфигурации (я вру, конечно, вы всё равно должны сконфигурировать доступ к базе данных, указать username, password итд). Пример классов-моделей, они представляют конкретные таблицы базы данных из документации:

class Customer < ActiveRecord ::Base
has_many :orders
end

class Order < ActiveRecord ::Base
belongs_to :customer
end

И это все. Это работает без единой строчки конфигурации. По умолчанию предполагается, что в базе у вас есть таблицы orders и customers. В orders есть внешний ключ с именем customer_id. Первичные ключи называются id. На этом все. Вы соблюдаете соглашения именования и все само работает. Теперь вы можете строить и выполнять SQL-запросы совершенно очевидным и естественным способом:

customer.orders
#=>
order.customer
#=> customer

Окей, идем дальше. Маршрутизация запросов (routes). Это поразительно. Вы можете все, и очень многое из этого “всего” бесплатно. Но это если вы руководствуетесь соглашениями. Пример маршрута из документации

resources :books

Благодаря магии Rails эта одна скромная строчка способна создать пачку маршрутов для CRUD:

$ bundle exec rake routes | grep book
books GET /books(.:format) books#index
POST /books(.:format) books#create
new_book GET /books/new(.:format) books#new
edit_book GET /books/:id/edit(.:format) books#edit
book GET /books/:id(.:format) books#show
PATCH
PUT /books/:id(.:format) books#update
DELETE /books/:id(.:format) books#destroy

Опять-таки, по соглашениям именования у вас должен быть классBooksController и аналогичные методы index/create в нём, т.е. books#index соответствует BooksController#index. Добавьте к этому ограничения (constraints), пространства имен (namespaces), модули (modules).

Продолжение можно найти

Прошло около года с момента публичного дебюта Ruby on Rails в 25 июля, 2004. За этот довольно короткий срок, Rails превратилась из уже достаточно впечатляющей версии 0.5 в устрашающе-вдохновляющую, готовящуюся к выходу версию 1.0, которой удалось сохранить свою простоту использования и продуктивность, в то же время добавив будоражащий ум массив новых возможностей. Эта статья познакомит вас с компонентами грядущей версии Ruby on Rails 1.0 и постарается рассказать, о чём же собственно столько разговоров.

Я не намереваюсь учить вас как использовать Rails для создания веб приложений. Для этого, вам скорей всего следует начать со статьи Rolling with Ruby on Rails. Эта статья, является введением и картой к огромному количеству возможностей Rails.

Высокая продуктивность и высокая скорость разработки

На уровне возможностей, Ruby on Rails не предлагает ничего нового. Существующие веб фреймворки уже всё это делали. В чём же тогда дело? Различие лежит в том, как это делает Ruby on Rails. Когда вы можете закончить простое веб приложение за дни вместо недель и более сложное за недели вместо месяцев, люди обращают на это внимание!

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

Внимание также оказалось бы недолгим, если бы Ruby on Rails не имела глубины - то есть, если бы раз попробовав использовать её для чего-то сложнее самого простого веб приложения, вы сразу натыкались бы на стену, не имея возможности продолжить из-за ограничений системы. Опытные разработчики, которые знают толк во всемирной паутине и программировании не перестают повторять, что для Rails это не так. К примеру, автор Tomcat, Ant и Servlet API, James Duncan Davidson недавно написал:

Rails это самая хорошо продуманная среда веб разработки которую я когда-либо использовал. И это за десять лет моей работы веб разработчиком. Я разрабатывал свои фреймворки, помогал разрабатывать Servlet API, и создал больше пары веб серверов с нуля. До Rails, никто раньше так не делал. Я не хочу сказать что они всё сделали правильно. Ни под каким видом она не совершенна. У меня есть несколько придирок к тому как всё собрано вместе. Но дело не в совершенстве. Дело в том, что Rails позволяет работать очень быстро, при том что есть глубина которая помогает вам двигаться вперёд. И у Rails это очень хорошо получается.

Может быть сложно поверить в то, что это возможно без какого-то значительного недостатка. К счастью, вам не придётся верить мне на слово (также как кому-либо ещё). Вы можете легко доказать себе за день или меньше просто пройдя через учебник по Ruby on Rails и тут же разработав скромное приложение на свой выбор. В конце концов, лучше один раз увидеть, чем сто раз услышать. Если вы не хотите смотреть на себя сверх продуктивного, вы всегда можете посмотреть на кого-то ещё, кто за вас делает всё это в новом Rails видео.

Как Rails это делает?

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

Большая часть мощи Rails кроется в языке программирования Ruby. Уникальный дизайн Ruby делает легким создание языков для разных предметных областей и метапрограммирование. Rails пользуется этим на полную катушку.

Полная реализация MVC

Rails это MVC (модель, вид, представление) фреймворк, она предоставляет компоненты для каждого уровня которые безупречно работают друг с другом. Другие фреймворки часто реализуют только часть решения, обязывая разработчика интегрировать несколько различных фреймворк в приложение, а затем заставить их работать вместе. (К примеру, Java разработчик может использовать Hibernate, Struts и Tiles для полной поддержки MVC.)

Соглашение вместо конфигурации

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

Меньше кода

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

Генераторы

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

Быстрая отдача

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

Скаффолдинг (Scaffolding - строительные леса, подмости. Прим. пер.)

Rails может автоматически создать полный набор CRUD (Create, Retrieve, Update, and Delete) операций и представления для любой таблицы базы данных. Эта функциональность называется скаффолдингом и помогает вам быстрее начать манипулировать своими таблицами. Со временем, вы можете постепенно заменить сгенерированные операции и представление своими собственными - которые, разумеется, будут намного красивее и функциональнее.

Компоненты Rails

Rails сама по себе состоит из нескольких компонентов, которые вы можете установить и использовать отдельно. Хотя они были спроектированы так, чтобы работать как единое целое, и разработчики почти всегда используют их вместе:

* Active Record это слой объектно-реляционного отображения (ORM) который связывает бизнес объекты (модели) с таблицами базы данных. Это реализация паттерна активная запись описанного Мартином Фаулером.
* Action Pack это компонент который реализует два слоя архитектуры MVC: контроллер и представление. Контроллер управляет входящими запросами от браузера пользователя и отправляет их к соответствующему методу класса-контроллера. Представление строит ответ браузеру используя шаблонную систему на подобии ASP или JSP.
* Prototype это компонент который реализует Ajax, drag’n’drop и визуальные эффекты на ваших страницах.
* Action Mailer это тот компонент который отвечает за отправку и получение электронной почты.
* Action Web Service позволит вам легко добавить API веб службы к своему приложению. Action Web Service поддерживает SOAP, XML-RPC и WSDL.

* Active Record is the object-relational mapping (ORM) layer that connects business objects (models) to database tables. It is an implementation of the Active Record pattern described by Martin Fowler.
* Action Pack is the component that implements both the view and controller portions of the MVC architecture. The controller part handles incoming requests from the user’s browser and routes them to the correct method of a controller class. The view part builds the response to send back to the browser using a templating system similar to that of ASP or JSP.
* Prototype is the component that implements the Ajax, drag-and-drop, and visual effects within your web pages.
* Action Mailer is the component that handles the sending and receiving of email.
* Action Web Service is the component that makes it easy to add web service APIs to your web application. Action Web Service supports SOAP, XML-RPC, and WSDL.

Основные возможности

У Rails есть некоторые основные и специфичные характеристики.

Веб серверы

Rails можно запустить практически на любом веб сервере который поддерживает CGI. Однако, производительность CGI никуда не годится, поэтому предпочитаемый способ развёртывания это использование FastCGI. Довольно хорошо протестирован способ развёртывания Rails приложений на Apache и LightTPD. Кстати, недавно появился новичок, SCGI, который предоставляет производительность FastCGI без сложностей его установки.

Во время разработки, чаще всего самым простым способом является использование WEBrick - веб сервера который поставляется вместе с Ruby.

Базы данных

На данный момент Rails поддерживает следующие СУБД:

* MySQL
* PostgreSQL
* SQLite
* SQL Server
* DB2
* Oracle

Сам адаптер базы данных состоит из примерно 100 строк Ruby кода, поэтому расширить этот лист ещё одним элементом не составит большого труда.

Отладка

Когда что-нибудь в вашем Rails приложении идёт не так как надо, обычно вы получите довольно детальное сообщение об ошибки в вашем браузере (если вы работаете в режиме разработки). Часто, этого достаточно чтобы обнаружить проблему. Если нет, то у вас есть следующие варианты отладки:

* Вставить отладочный вывод в контроллер. Например:

render_text «Дошёл до сюда»

render_text «объект user = » + user_obj

* Проверить логи Rails. (Используйте tail на *nix системах.) Посмотрите на файлы development.log, production.log и fastcgi.crash.log. Помните, что ваш веб сервер тоже ведёт логи.
* Использовать брейкпоинты.
* Использовать коммерческую среду разработки (такую как ArachnoRuby) со встроенным отладчиком.

Настраиваемые (красивые) URL

То, как Rails по умолчанию привязывает URL к действиям контроллера очень просто понять. Rails очень старается чтобы пользователь видел только «красивые» URL адреса. URL в Rails простые и понятные, а не длинные и зашифрованные.

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

Система роутинга Rails это чистый Ruby код который позволяет вам использовать даже регулярные выражения. Поскольку Rails не использует возможности веб сервера при привязке URL (например mod_rewrite в Apache), ваша схема привязки URL будет работать одинаково на любом веб сервере.

Модульное тестирование

Rails активно навязывает (в хорошем смысле, прим. пер.) разработчику модульное тестирование:

* Генерация новых контроллеров, моделей и скаффолдига, также создаёт соответствующие скелеты модульных тестов.
* Чёткое следование архитектуре MVC как результат приводит к хорошо тестируемым действиям и компонентам.
* Rails включает в себя Rake (Ruby Make) скрипт, который может автоматически запускать все ваши модульные тесты.

Детали процесса подробно описаны в Руководстве о тестировании в Rails.

Active Record

Active Record это часть Rails которая отвечает за автоматическую динамическую привязку таблиц вашей базы данных к объектам моделей. Это буква M в MVC, и это реализация слоя ORM в Rails.

Для самых распространённых случаев использования (и не таких уж распространённых), вам никогда не придётся видеть или писать SQL код для доступа к или обновления вашей базы. Цель Active Record - работать исключительно с реляционными базами данных; она не пытается абстрагироваться от использования SQL. Когда надо, Active Record облегчает использование ваших собственных SQL запросов, для тех сложных случаев где это необходимо. Но даже в таких случаях, часто можно обойтись без написания SQL кода вручную.

Автоматическая привязка

Active Record автоматически привязывает таблицы к классам, строки к объектам (экземплярам класса модели), и поля к аттрибутам объекта. Например код:

class Product < ActiveRecord::Base end

автоматически привязывается к таблице с именем products, такой как:

CREATE TABLE products (id int(11) NOT NULL auto_increment, name varchar(255), PRIMARY KEY (id));

а также автоматически создаёт аттрибут name который вы можете использовать так:

my_product = Product.find(:first) STDOUT.print my_product.name my_product.name = "Название нового продукта"

Active Record использует правила плюрализации английского языка для привязки классов к таблицам. Имя класса модели состоит в единственном числе и пишется с заглавной буквы, а имя таблицы в множественном и в нижнем регистре. Вот несколько примеров:

* Класс модели Invoice привязывается к таблице invoices.
* Класс модели Person привязывается к таблице people.
* Класс модели Country привязывается к таблице countries.
* Класс модели SecurityLevel привязывается к таблице security_levels.

Соглашение о единственных/множественных числах выливается в довольно натурально читаемый код. Заметьте как разумна привязка в своём использовании правил плюрализации английского. Также обратите внимание, что имена классов используют CamelCase (правило Ruby), в отличии от таблиц, имена которых все в нижнем регистре со знаками нижнего подчёркивания между словами.

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

Документация класса ActiveRecord::Base описывает процесс автоматической привязки подробней.

Ассоциации

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

class Firm < ActiveRecord::Base has_many:clients has_one:account belongs_to:conglomerate end

позволяет вам написать следующий код:

my_firm = Firm.find(:last) STDOUT.print my_firm.account.name STDOUT.print my_firm.conglomerate.employee_count for c in my_firm.clients STDOUT.print "Клиент: " + c.name + "n" end

Этот код будет работать корректно если в базе данных есть таблицы clients и accounts в каждой из которых есть поле name, и таблица conglomerates с полем employee_count.

Документация модуля ActiveRecord::Associations подробно объясняет все тонкости ассоциаций в Rails.

Валидация

Поскольку вы скорей всего не хотите хранить в своей базе что попало, вы скорей всего захотите проверить свои данные перед сохранением. Active Record содержит набор макро-подобных валидаторов которые вы можете добавить к своей модели.

class Account < ActiveRecord::Base validates_presence_of:subdomain, :name, :email_address, :password validates_uniqueness_of:subdomain validates_acceptance_of:terms_of_service, :on => :create validates_confirmation_of:password, :email_address, :on => :create end

Если встроенные макросы валидации не могут дать вам то, что нужно, вы всегдо можете написать свой метод для валидации.

class Person < ActiveRecord::Base protected def validate errors.add_on_empty %w(first_name last_name) errors.add("phone_number", "has invalid format") unless phone_number =~ /*/ end def validate_on_create # only runs the first time a new object is saved unless valid_discount?(membership_discount) errors.add("membership_discount", "has expired") end end def validate_on_update errors.add_to_base("Изменений не было") if unchanged_attributes? end end person = Person.new("first_name" => "David", "phone_number" => "what?") person.save # => false (and doesn"t do the save) person.errors.empty? # => false person.count # => 2 person.errors.on "last_name" # => "can"t be empty" person.errors.on "phone_number" # => "has invalid format" person.each_full { |msg| puts msg } # => "Last name can"t be emptyn" + "Phone number has invalid format" person.attributes = { "last_name" => "Heinemeier", "phone_number" => "555-555" } person.save # => true (и person сохраняется в базе данных)

Если метод validate существует, Rails вызовет его прямо перед записью любого объекта в базу данных. Если валидация провалилась, она не запишет объект в базу. Методы validate_on_create и validate_on_update похожи, за исключением того, что первый вызывается только тогда когда Rails создаёт в базе новую запись, тогда как последний вызывается только когда Rails собирается обновить существующую.

Документация модуля ActiveRecord::Validations подробно описывает все тонкости.

Обратные вызовы

Вы можете наблюдать за тем, как Active Record создаёт и удаляет объекты модели, создаёт и изменяет их в базе данных, используя методы обратных вызовов (callbacks). Вы можете использовать обратные вызовы для того, чтобы позаботиться о сложной бизнес логике, изменить данные перед тем как Rails запишет их в базу (или после того как Rails прочитает их из базы), или в любой другой момент который вам нужен.

К примеру, метод save который сохраняет данные объекта модели в базу данных, имеет восемь методов обратного вызова:

1. before_validation
2. before_validation_on_create
3. after_validation
4. after_validation_on_create
5. before_save
6. before_create
7. after_create
8. after_save

Это даёт вам полный контроль над объектами модели тогда, когда он вам нужен.

class CreditCard < ActiveRecord::Base # Выдрать всё, кроме цифр, так чтобы пользователь мог ввести "555 234 34" или # "5552-3434". Чтобы оба варианта значили "55523434" def before_validation_on_create self.number = number.gsub(/[^0-9]/, "") if attribute_present?("number") end end class Subscription < ActiveRecord::Base before_create:record_signup private def record_signup self.signed_up_on = Date.today end end class Firm < ActiveRecord::Base # Уничтожает ассоциированных клиентов и людей, когда уничтожается фирма before_destroy { |record| Person.destroy_all "firm_id = #{record.id}" } before_destroy { |record| Client.destroy_all "client_of = #{record.id}" } end

Документация модуля ActiveRecord::Callbacks подробно рассказывает о методах обратного вызова.

Транзакции

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

Транзакции уровня базы данных, показанные выше, не допустят снятие денег со счёта David’а в случае если не получится зачислить эти деньги на счёт Mary. Однако, это не защитит объекты david и mary от изменения. Чтобы добиться этого, вам следует использовать транзакции уровня объектов:

Любой сбой в этом коде вернёт назад предыдущее состояние объектов, также как и базы данных.

Документация модуля ActiveRecords::Transactions объясняет подробнее.

И это далеко не всё

Active Record содержит в себе намного больше, чем я могу здесь описать. Чтобы узнать больше, загляните в Active Record API.

Action Pack реализует уровни контроллера и представления в Rails.

Шаблоны представления

Шаблоны представления формируют HTML который возвращается в ответе браузеру. Шаблоны являются файлами rhtml (HTML со встроенным Ruby) которые очень похожи на ASP или JSP файлы. Текст внутри <% %> это Ruby код который будет запущен, а текст внутри <%= %> это Ruby код который будет также запущен и результат запуска которого будет подставлен обратно в HTML.

Счета для <%= @name %> <% render_partial "invoices_by_customer" %>

По умолчанию, Rails попытается найти шаблон чьё имя совпадает с действием которое сейчас выполняется. Если например, Rails выполняет действие edit в вашем InvoiceController, тогда она попытается найти и вывести шаблон представления …/app/views/invoices/edit.rhtml.

Вы можете также конструировать XML (или HTML) вывод в действии вашего контроллера. Это полезно, к примеру, для построения RSS лент или ответа на XML-RPC запросы. В следующем примере, xm это экземпляр класса XmlMarkup.

xm.em("подчёркнутый") # => подчёркнутый xm.em { xmm.b("emp & bold") } # => emph & bold xm.a("A Link", "href"=>"http://onestepback.org") # => A Link xm.div { br } # =>

xm.target("name"=>"compile", "option"=>"fast") # => # ВНИМАНИЕ: порядок аттрибутов не сохраняется. xm.instruct! # xm.html { # xm.head { # xm.title("История") # История } # xm.body { # xm.comment! "HI" # xm.h1("Заголовок") #

Заголовок

xm.p("параграф") #

параграф

} # } #

Роутинг URL

Запрашиваемый URL всегда привязывается к какому-то действию внутри контроллера. Контроллер это простой класс Ruby и каждое действие реализованное контроллером это публичный метод этого класса. По умолчанию, URL привязан к действию по следующей схеме:

/:controller/:action/:id

Это легче всего объяснить на примере. Если Rails получает URL http://myapp.com/invoices/show/37, то она автоматически привяжет его к классу-контроллеру InvoicesController и к методу этого класса под именем show. Rails также передаст значение 37 в метод как часть хэша параметров под именем id. Хэш параметров содержит в себе значения полей запроса(взятых из URL) и данные элементов форм. Код может выглядеть следующим образом:

class InvoicesController def show @invoice = Invoice.find(params[:id]) end end

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

Если стандартный способ привязки URL вас не устраивает, вы можете с лёгкостью указать свои правила роутинга, даже используя регулярные выражения. Поскольку Rails реализует свой механизм URL роутинга, вам не надо связываться с Apache mod_rewrite и ваши правила роутинга будут работать одинаково на всех веб серверах.

Правила роутинга URL в Rails это простой Ruby код. Вот пример:

map.connect "date/:year/:month/:day", :controller => "blog", :action => "by_date", :month => nil, :day => nil, :requirements => {:year => /d{4}/, :day => /d{1,2}/, :month => /d{1,2}/}

С этим правилом роутинга становятся рабочими следующие адреса:

http://myblog.com/date/2005
http://myblog.com/date/2005/08
http://myblog.com/date/2005/08/01

Это правило разбивает URL содержащий дату, которую, блог может использовать для отображения постов за конкретное число. URL который совпадает с правилом будет привязан к классу BlogController и к методу by_date. Хэш параметров будет содержать значения для года из четырёх цифр(/d{4}/ это регулярное выражение Ruby) и месяц и день из двух. Также, месяц и день не обязательны; если значение не присутствует, в хэше параметров будет сохранено значение по умолчанию - nil.

Смотрите руководство по роутингу в Rails для подробного описания.

Фильтры позволяют вам выполнять предварительный код перед тем как Rails выполнит действие, а также после его выполнения. Это может быть полезно для таких вещей как кэширование или аутентификация перед вызовом действия, и компрессия или локализация ответа после его вызова. Фильтр before_filter может либо разрешить действию быть выполненным в нормальном режиме, возвратив true, либо отменить вызов вернув false (или выполнив операцию render или redirect).

Например:

class BankController < ActionController::Base before_filter:audit private def audit # записать действие и параметры в лог для аудита end end class VaultController < BankController before_filter:verify_credentials private def verify_credentials # убедиться что пользователь имеет доступ в хранилище end end

Остальные детали в документации класса ActionController::Filters.

Помошники (helpers)

Помошники это умные методы (функции) которые помогают вашим шаблонам представления генерировать HTML. Они используют ваши объекты модели и классы контроллеров для создания HTML и в дальнейшем, избавят вас от траты лишнего времени и усилий. Конечно, это также значит что вам придётся писать меньше строк кода, но держу пари, об этом вы уже итак догадались.

Вы можете создавать своих собственных помошников, но как вы могли догадаться несколько помошников поставляется встроенными в Rails. Помошник link_to, например, генерирует тэги ссылок которые ссылаются на контроллеры и действия. Пример:

<%= link_to "Помощь", { :action => "help" } %>

<%= link_to "Содержание справки", { :controller => "help", :action => "index" } %>

<%= link_to "Удалить этот счёт", { :controller => "invoices", :action => "delete", :id => @invoice.id }, :confirm => "Вы действительно хотите это удалить?" %>

Это создаст ссылку на метод delete в классе InvoiceController, и передаст параметр id (в качестве указателя на то, какой счёт нужно удалить). Здесь также используется специальная опция confirm которая создаёт всплывающее окно подтверждения через JavaScript.

Существует большой набор помощников для создания форм просмотра и обновления значение объектов ваших ActiveRecord моделей, то есть — для значений в вашей базе данных. Предположим что в вашей базе данных есть таблица people со столбцами для имени, пароля, описания и булева значения определяющего женат человек или холост (ОК, довольно странная табличка вышла:). Вот часть шаблона с примером тэгов формы которые можно было бы использовать. (Допустим что переменная @person содержит объект класса Person, считанный из строки в таблице people.)

Данный код генерирует следующий HTML ответ:

Есть помощники для создания тэгов option для списков select из набора строк считанных из базы данных; помощники для работы с датами, числами и валютой; и много других.

* Active Record Helpers
* Asset Tag Helpers
* Benchmark Helpers
* Cache Helpers
* Capture Helpers
* Date Helpers
* Debug Helpers
* Form Helpers
* Form Options Helpers
* Form Tag Helpers
* JavaScript Helpers
* Number Helpers
* Pagination Helpers
* Tag Helpers
* Text Helpers
* Upload Progress Helpers
* URL Helpers

AJAX и JavaScript помощники

Rails включает в себя JavaScript библиотеку Prototype для реализации своей поддержки AJAX, визуальных эффектов и drag-n-drop возможностей.

Модель того, как Rails реализует AJAX операции проста и надёжна. Как только браузер обработал и отобразил первоначальную страницу, различные действия пользователя могут вызвать либо отображение новой страницы (как в традиционных веб-приложениях) либо инициировать AJAX действие:

1. Срабатывает триггер. Это может быть кликом пользователя на кнопку или ссылку, изменение данных в форме или поле, или просто временный триггер (на основе таймера).
2. Клиент асинхронно отсылает данные ассоциированные с триггером (поле или целую форму) к действию-обработчику на стороне сервера через XMLHttpRequest.
3. На стороне сервера действие-обработчик выполняет какие-то действия над данными и возвращает HTML фрагмент в качестве ответа.
4. JavaScript на стороне клиента (код генерируется Rails автоматически) принимает этот HTML фрагмент и использует его для обновления конкретной части HTML текущей страницы, часто фрагмент подставляется содержимым в тэг

Вся прелесть в том, как просто Rails позволяет реализовать всё это в вашем веб-приложении. Следующий простой пример добавляет новые элементы в список:

Демонстрация списка с AJAX <%= javascript_include_tag "prototype" %>

Добавить к списку с помощью AJAX

<%= form_remote_tag(:update => "my_list", :url => { :action => :add_item }, :position => "top") %> Текст нового элемента: <%= text_field_tag:newitem %> <%= submit_tag "Добавить элемент через AJAX" %> <%= end_form_tag %>

Начальный элемент... добавьте ещё!

Статья AJAX on Rails и API JavaScript помощников рассказывают о поддержке AJAX в Rails более подробно.

Библиотека Prototype также предоставляет Rails разработчику целый набор визуальных эффектов на стороне браузера. Script.aculo.us содержит документацию и живую демонстрацию эффектов Prototype. Prototype также позволяет легко добавить к своему приложению drag-and-drop функциональность, об этом также можно узнать на сайте script.aculo.us.

Макеты (Layouts)

Макеты позволюят вам указать набор основных элементов для отображения на каждой странице выдаваемой контроллером. Это обычно полезно для вывода общей шапки, низа и боковых панелей. По умолчанию, Rails смотрит в свой каталог layouts в поисках rhtml файла чьё имя совпадает с именем контроллера. Шаблон макета может выглядеть вот так:

<%= @page_title %>

Шапка для этого макета

<%= @content_for_layout %>

Низ этого макета

Rails подставит HTML который сгенерируется действием в этот макет, в то место где написано @content_for_layout.

Контроллер также может прямо указывать какой макет следует использовать для всех его действий. Это упрощяет задачу использования одного макета для нескольких контроллеров. Вы можете менять шаблон макета даже динамически, в режиме runtime. Например, использовать разные макеты для пользователей вошедших в систему и для анонимных посетителей.

Чтобы узнать о макетах больше, смотрите документацию ActionController::Layout.

Partials и компоненты

Компоненты и partials (части, отрывки. прим.пер.) позволяют вам разделить ваши шаблоны представления на модули.

Проще всего использовать partials, которые позволяют вам выделить общую часть шаблона в отдельный файл и затем отображать его из множества других шаблонов (или много раз в одном шаблоне).
Шаблоны partials всегда имеют знак нижнего подчёркивания (_) перед названием их файла, чтобы было легче отлечить их от полных шаблонов.

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

<% for ad in @advertisements %> <%= render:partial => "adview", :locals => { :item => ad } %> <% end %>

Это отобразит шаблон partial _adview.rhtml несколько раз (по разу на каждый элемент массива @advertisments). Для каждого отображения, Rails будет передавать в _adview.rhtml локальную переменную с именем item которая содержит объект ad.

Документация ActionView::Partials содержит подробную информацию. На Pointstorm есть более детальная презентация partials, но она несколько устарела, поскольку использует устаревший синтаксис вызова partials.

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

<%= render_component:controller => "calendar", :action => "today" %>

Загляните в раздел Компоненты руководства по Rails если хотите узнать больше.
Скаффолдинг (scaffolding)

Скаффолдинг позволяет вам получить быструю реализацию CRUD (Create, Retrieve, Update, and Delete) операций для любой таблицы базы данных. Они не очень красивы, но позволяют получить немедленный доступ через веб-интерфейс к вашим таблицам. С течением времени, вы можете постепенно заменить сгенерированные операции и шаблоны на свои.

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

$ ruby script/generate scaffold invoices

Эта команда найдёт таблицу invoices в вашей базе данных и использует её схему для генерации модели, контроллера и всех шаблонов представления, скелетов для модульного тестирования и другой всячины. По мере хода процесса на экран будет выводиться список сгенерированных файлов.

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

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

class AccountController < ActionController::Base scaffold:account end

И много всего другого

Также как и в Active Record, в Action Pack очень много вещей о которых я не могу здесь рассказать. Если хотите узнать больше, посмотрите на Action Pack API.

Action Mailer это простая технология для отправки и приёма email в вашем веб-приложении. Вот метод для отправки email с вложением:

# отправляем email с вложением def signup_notification(recipient) recipients recipient.email_address_with_name subject "Информация о новом аккаунте" from "[email protected]" attachment:content_type => "image/jpeg", :body => File.read("an-image.jpg") attachment "application/pdf" do |a| a.body = generate_your_pdf_here() end end

Узнать больше можно в Action Mailer API и главе 19 книги Agile Web Development with Rails.

Action Web Service

Action Web Service реализует серверную поддержку для протоколов веб-служб SOAP и XML-RPC, позволяет просто создавать свои API и публиковать их через WSDL.

Вот часть MetaWeblog API реализованного Typo (open source блог система написанная на Rails):

class MetaWeblogApi < ActionWebService::API::Base api_method:getRecentPosts, :expects => [ {:blogid => :string}, {:username => :string}, {:password => :string}, {:numberOfPosts => :int} ], :returns => [] api_method:deletePost, :expects => [ {:appkey => :string}, {:postid => :string}, {:username => :string}, {:password => :string}, {:publish => :int} ], :returns => [:bool] end class MetaWeblogService < TypoWebService web_service_api MetaWeblogApi def getRecentPosts(blogid, username, password, numberOfPosts) articles = Article.find_all(nil, "created_at DESC", numberOfPosts) articles.to_a.collect{ |c| article_dto_from(c) } end def deletePost(appkey, postid, username, password, publish) article = Article.find(postid) article.destroy true end end

Этот отрывок показывает только два из семи методов API определённых Typo в этом классе.

Если хотите узнать больше, прочтите руководство по Action Web Service

Мысли о разделении

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

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

Последние ~14 рабочих часов провёл исключительно на Ruby on Rails, программируя простенький проект “Ы”, так сказать, такую рамку небольшую. Всё причём идёт под…

Что такое Ruby on rails и почему его так любят.

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

Вы словно творец, создаете, что вам угодно. Ведь главное в разработке ставить цели и добиваться их, при этом знать, что путь по которому вы идете к достижениям самый лучший!
Так, что же такое rails и что делает его таким совершенным?

7 китов совершенства ruby on rails

Первый, Ruby On Rails это Ruby
Ruby on Rails - фреймворк написанный на самом лучшем языке программирования Ruby.
Красота и удобность программирования просто не описуема словами. Ruby on Rails дополняет этот совершенный язык новыми методами, классами для взаимодействия объектов, классов.

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

Второй, Ruby on Rails использует MVC

MVC - это архитектурный шаблон (паттерн) который предусматривает разделение кода приложения на три части: Model (модель), View (представление) и Controller (контроллер).

Модель содержит математическую логику приложения, здесь указываются ассоциативные связи между моделями, различные callback"и и основной код приложения.
Представления используются для отображения информации пользователю, представлением является, графический интерфейс приложения или веб-интерфейс веб-приложения. Здесь различные html формы, css стили и javascript.
Контроллер занимается связыванием модели с представлением и обработкой запроса пользователя приложения. Здесь вы с помощью раутов(routes) настраиваете маршрутизацию вашего приложения.
Использование MVC позволяет писать более чистый и структурированный код, что значительно ускоряет разработку и при этом облегчает поддержку приложения.

Третий, Ruby on Rails использует CoC
CoC - Convention over Configuration (Соглашение превыше настройки) - вся идея состоит в том, что по умолчанию фреймворк уже отлично настроен. Ruby on Rails поставляется с набором крайне удобных соглашений, которые позволяют начинать разработку приложения сразу же после установки Ruby on Rails и создания нового проекта. При необходимости можно изменить настройки по умолчанию (они то и называются соглашением) и использовать свои, однако это, как правило, не только является лишним, но и зачастую вредным.

Четвертый кит, DRY
DRY - Don’t Repeat Yourself (Не повторяйся!) - еще один принцип разработки положенный в основу веб-фреймворка Ruby on Rails и самого языка ruby. Этот принцип предписывает разработчику выявлять в коде повторяющиеся фрагменты и выносить их в отдельные методы, классы или модули в зависимости от ситуации. В Ruby on Rails этот принцип проявляется во многих местах, что позволяет писать меньше кода, меньше тестов и легче поддерживать разработанный код. Например в представлении доступны к использованию различные partial"ы - это шаблоны для повторения кода, которые просто вызываются в коде например для Форм. Это не только улучшает читаемость кода, но и добавляет гибкость к изменению или добавлению новой информации.

Пятый кит это CRUD

CRUD - create, read, update, delete - «создание, чтение, обновление, удаление») методология используемая для создания контроллеров. Использование стандарта, с помощью которого вы можете четко определить экшены контроллеру для полной манипуляции с любым объектом. Также вы можете без проблем дополнить своими экшенами.
Также в rails используются не только POST и GET запрос, а такие как PUT и DELETE. Давая вам больше возможности манипулирования данными

Шестой кит ORM

ORM (object-relational mapping) - технология программирования, которая помогает работать с базой данных на языке программирования, не используя различный sql языки для манипуляции с базой данных. Здесь использует объектно-ориентированное программирование на языке ruby.
Вся идея в том, что таблица является классом, ее строки это объекты, столбцы - свойства объектов.
Методы классов выполняют операции над таблицами.
Методы объектов выполняют операции над отдельными строками.

Седьмой кит haml sass/less
Идея использовать упрощенные и более функциональные языки такие как haml и sass/less. Которые увеличивают читаемость кода, делая разработку наиболее удобной и автоматически интерпретируются в своих родителей html и css.

А также существует еще множество плюсов, например установка различных дополнительных библиотек (gem"ов) в одну команду. Отличный бесплатный Heroku, дающий вам наблюдать за работоспособностью вашего локального приложения в продакшене на удаленном облаке. Различные готовые решения, из документации Ruby on Rails. И возможность генерации кода, для более быстрой развертывания веб-приложения.

Целью было представить основные возможности фреймворка Ruby on Rails. Надеюсь вас заинтересовало, и в веб мире скоро появиться еще один крутой рубист!

Гэри Гэри Полличе (Gary Pollice)
Опубликовано 27.05.2008

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

В поисках большей отдачи на единицу трудовых затрат

С тех пор, как программисты начали создавать программы, они не перестают думать о том, как вложить больше потребительской ценности в программы при тех же трудовых затратах. В последние пятьдесят лет появилось немало теорий о том, как этого добиться. Мы, безусловно, стали свидетелями эволюции языков программирования высокого уровня. Но постепенное совершенствование высокоуровневых языков вряд ли заставит нас подпрыгнуть на стуле, хлопнуть себя по лбу и воскликнуть "ну надо же!" Даже динамичные языки программирования, которые в 90-е годы были отнесены к категории "языков сверхвысокого уровня" (Very High Level Language, VHLL), не смогли предложить тех преимуществ, которые большинство из нас хотели бы получить и которые необходимы для обеспечения соответствия все возрастающим требованиям к программному обеспечению.

Мы предлагали идеи по поводу того, как повысить производительность труда программиста при помощи многократно используемых инфраструктур, перекрестных технологий, например, аспектно-ориентированного программирования, компонентной разработки, сервис-ориентированных архитектур, архитектуры, управляемой моделями, и многое другое. Все это давало определенный прирост производительности при условии правильного применения. Хотя мы до сих пор не создали технологии,которая позволила бы создавать программы без участия программиста (а именно об этом мечтают некоторые специалисты), мы сделали большой шаг вперед в направлении повышения производительности труда программистов. Тем не менее, мы все еще не получили 10-100 кратного повышения производительности, о котором мы мечтаем.

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

Что такое Rails?

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

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

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

Простой пример

Вероятно, каждая статья или книга о Rails начинается простым примером. Я не стану приводить такой пример и подробно его описывать, просто продемонстрирую вам особенно яркие моменты примера из самой популярной книги по Rails, Agile Development with Rails (Динамичная разработка при помощи Rails), авторы Томас (Thomas) и Ханссон (Hansson). Этот пример представляет собой основу сайта интернет-магазина. Продукты, которые мы хотим продавать, имеют наименование, описание, изображение и цену. После того, как я потратил полчаса на чтение и изучение текста, я нашел в приложении точку, в которой можно добавлять продукты в базу данных, изменять информацию о них и удалять их. Это приложение использует обычную архитектуру Model-View-Controller (Модель-представление-контроллер), а Rails облегчает сохранение разделения ответственностей, поскольку эта инфраструктура автоматически генерирует корректные исходные файлы в отдельных каталогах, что делает очевидным их назначение.

Тело окончательной Web-страницы, которую я создал, показано на рисунке 1. В моем каталоге на данный момент только два продукта, но на этой странице мы можем увидеть некоторые моменты. Если продукт имеет изображение типа моей схемы механизма по наклейке этикеток, оно отображается на странице. Отображается первая часть описания продукта вместе с разметкой HTML. Рядом с каждым продуктом имеются три ссылки, чтобы можно было увидеть, как выглядит продукт, когда мы отображаем его, редактируем элемент или удаляем его. Кроме того, имеется ссылка на страницу создания нового продукта. Мы явно не готовы предъявить эту Web-страницу миру, но зато можем приступить к работе с заинтересованными лицами, которые предъявляют требования к нашему приложению. Это позволяет нам использовать итеративный подход к получению определенных требований, их реализации, анализу работы и внесению изменений перед следующей итерацией.

Рисунок 1. Страница управления каталогом продукции

Внешняя отделка моей Web-страницы вряд ли может кого-либо удивить, но то, что мне пришлось сделать к этому моменту, отличается поразительно малым объемом. Я измеряю объем работы количеством команд, которые мне пришлось ввести с терминала, количеством строк кода на языке Ruby, HTML и встроенного Ruby (ERb), которое мне пришлось написать. Я немного сократил работу, скопировав файл CCS (Cascading Style Sheets, каскадная таблица стилей) из загружаемых файлов к книге Томаса и Ханссона, поэтому в своей оценке трудовых затрат эти строки я не учитываю. В таблице 1 представлены результаты моих подсчетов.

Таблица 1. Трудовые затраты на управление каталогом продукции

Цифры в таблице 1 были округлены, поскольку я немного экспериментировал с кодом. Но если бы я даже написал в два раза больше строк кода на языке Ruby, общее количество строк, введенных мной в редакторе или строк команд в оболочке терминала было бы гораздо меньше 100. Вы можете спросить, а что я на самом деле получил, написав несколько десятков строк программного кода? Вот список:

Кроме того, я обнаружил еще более восхитительные моменты, которыми мне не пришлось заниматься:

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

Я не являюсь разработчиком Web-приложений. (Я не слишком преуспел в изучении технологий, поскольку уделял больше внимания другим аспектам разработки программного обеспечения. В одно и то же время можно сделать лишь определенный объем вещей из всех доступных.) Но, имея явно недостаточные знания языков Ruby и HTML, я произвел хорошее впечатление на своих студентов, демонстрируя свои познания в области Web-разработки.

Принципы Rails

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

Model-View-Controller (Модель-представление-контроллер)

Разработчикам программного обеспечения хорошо известна архитектура Model-View-Controller (Модель-представление-контроль). Эта архитектура лежала в основе ранних систем графического интерфейса пользователя (GUI) типа интерфейса среды Smalltalk-80. Концепция не отличается сложностью: система делится на три разных части (см. рисунок 2).

Рисунок 2. Архитектура Model-View-Controller

Архитектура MVC делит сферы ответственности в приложении на три разных части. Модель отвечает за обслуживание состояния приложения. Оно не только извлекает и хранит данные, но также гарантирует их целостность. Бизнес-логика, которая должна применяться к этим данным, инкапсулирована в модель. Представление отвечает за отображение модели для пользователя в одном или нескольких форматах. Это позволяет отображать модель различными способами, в зависимости от потребностей пользователя. Контроллер отвечает за обеспечение того, чтобы другие компоненты осуществляли нужные действия в нужное время. Он получает запросы от пользователя и распределяет их по соответствующим компонентам. MVC - надежная, эффективная архитектура для многих типов приложений, в том числе, для клиент-серверных Web-приложений.

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

Рисунок 3. Фрагмент структуры приложения

На данный момент разработки у нас всего один контроллер, контроллер admin. Rails получает информацию о том, какой контроллер необходимо вызвать, из текущего URL в адресной строке браузера. В данном случае, это указывается в URL после адреса Web-cервера. Тестируя приложение, я указываю в адресной строке браузера URL http://localhost:3000/admin , после чего localhost:3000 подключается к используемому мной серверу -- в данном случае, к серверу по умолчанию WEBrick, который поставляется с Rails. Контроллер приложений Rails направляет запрос классу AdminController. Если вам интересно содержимое этого класса, можете изучить файл в архиве, прилагаемом к данной статье. Вы сможете сопоставить большую часть методов этого класса со ссылками на Web-странице, показанной на рисунке 1. Большая часть реальной работы сделана классом ApplicationController, который расширяет класс AdminController. Не беспокойтесь, если вы не понимаете всех деталей. Файл, содержащий определение класса AdminController, admin_controller.rb - это один из самых больших файлов в приложении, и я не написал ни одной строки в этом файле. Он был полностью сгенерирован Rails по одной моей команде.

Представлением Web-приложения являются Web-страницы, которые отображаются перед пользователем. Rails генерирует для вас большую часть Web-страниц, но вы все же должны иметь базовые знания HTML и обладать достаточными навыками программирования на языке Ruby, чтобы написать несколько строк ERb. В представлении в Rails нет ничего уникального. Просто для каждого действия мы должны создать файл.rhtml (Ruby HTML).

К этому моменту модель моего приложения достаточно проста, в базе данных имеется только одна таблица для продуктов, а продукт имеет четыре свойства, о которых я уже говорил ранее. Я решил сделать URL изображения необязательным свойством, поэтому для него не предусмотрена проверка корректности. Для всех остальных полей производится проверка корректности. Ниже представлен полный текст файла product.rb. Правда, он не слишком велик?

class Product < ActiveRecord::Base validates_presence_of:title, :description validates_numericality_of:price validates_uniqueness_of:title, :message => "We already have that in our catalog" protected def validate errors.add(:price, "must be worth something") if price.nil? || price < 0.01 end end

Первые три метода validates_ methods являются встроенными методами Rails, при этом метод проверки корректности автоматически вызывается для любого продукта, поступающего в систему. Я добавил проверку, чтобы гарантировать, что цена любого продукта будет не менее 0,01 доллара.

Возможно, вы поинтересуетесь, как была создана таблица для записи продуктов, если я не написал ни строки SQL? В Rails есть достаточно волшебный компонент, который называется Active Record. Active Record представляет собой объектно-реляционное отображение (object-relational mapping, ORM), использующее стандартную ORM-модель. В своей основе он представляет собой абстрактную реализацию шаблона проекта ActiveRecord. То есть, таблицы отображаются в классы, объекты отображаются в строки, а свойства объектов отображаются в столбцы. Active Record, как и Rails в целом, использует стандартный способ управления отображением. Он не поддерживает полной универсальности без определенной дополнительной работы. Однако если вы намерены использовать его стандартные возможности по умолчанию, то вам придется сделать совсем немного. Следующий код представляет содержимое файла, который создает таблицу:

class CreateProducts < ActiveRecord::Migration def self.up create_table:products do |t| t.column:title, :string t.column:description, :text t.column:image_url, :string end end def self.down drop_table:products end end

Все, что я написал в этом коде - это три строки t.column.... . Они определяют свойства наименование, описание и URL изображения. Чтобы получить готовую и настроенную базу данных, я выполнил следующие действия:

В командной строке я ввел команду:
Mysqladmin -u root create depot_development
В результате этой команды была создана база данных для моей разработки;
Я перешел в корневой каталог приложения и ввел следующую команду:
Ruby script/generate model product
В базе данных была создана таблица PRODUCT. Кроме того, было создано несколько файлов, в том числе, файл 001_create_products.rb в каталоге db/migrate приложения. Именно этот файл был показан в предыдущем листинге;
Я отредактировал файл, добавив в него три определения для столбцов;
Я ввел команду:
Rake db:migrate
В таблице PRODUCT были созданы столбцы. Команда rake - это аналог команды make, который используется в Rails.

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

На этом мы закончим изучение архитектуры MVC, основы приложения Rails, и перейдем к другим принципам.

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

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

# MySQL (установки по умолчанию). Рекомендуется использовать версии 4.1 и 5.0. # # Установка драйвера MySQL: # gem install mysql # На MacOS X: # gem install mysql -- --include=/usr/local/lib # На Windows: # gem install mysql # Выберите сборку win32. # Установите MySQL и поместите сборку в каталог /bin, указанный в переменной path. # # Убедитесь, что вы мспользуете новый стиль хэширования пароля: # http://dev.mysql.com/doc/refman/5.0/en/old-client.html development: adapter: mysql database: depot_development username: root password: host: localhost # Внимание: База данных, определенная как "test", будет стерта и #сгенерированна повторно из вашей разработанной базы данных, когда вы запустите "rake". # Не присваивайте этой БД того же имени, которое было при разработке # или при реальной эксплуатации. test: adapter: mysql database: depot_test username: root password: host: localhost production: adapter: mysql database: depot_production username: root password: host: localhost

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

Принцип DRY

Последний принцип, который используется в приложениях Rails - это принцип DRY (Don"t Repeat Yourself, не повторяйся). Хорошие проектировщики и программисты используют этот принцип на практике. Они знают, что если что-то делается один раз, в одном месте, то проекты становятся более простыми, а работа гораздо более управляемой.

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

Но будет ли приложение масштабируемым?

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

Один из моих коллег по Вустерскому политехническому институту (Worcester Polytechnic Institute) занимался разработкой интеллектуальной обучающей системы под названием Assistments, которая должна была помочь преподавателям и студентам различных курсов в изучении и преподавании различных предметов. Так же, как во многих штатах, учащиеся начальной и средней школы нашего штата в процессе обучения должны сдать серию стандартизированных тестов, что, в конечном итоге, необходимо для получения документа об образовании. Эти тесты, так называемые тесты MCAS , предлагаются на каждой ступени обучения, чтобы можно было оценить уровень подготовки учащихся по основным учебным дисциплинам. Обучающая система Assistments показала свою эффективность в помощи учащимся в получении необходимых знаний и навыков. В прошлом году система Assistment использовалась небольшой группой студентов в Вустере, штат Массачусетс, но группе моего коллеги, которая занималась Assistments, скоро пришлось готовиться к более масштабному развертыванию.

Assistments представляет собой типичное клиент-серверное Web-приложение. Оно не только помогает учителям и студентам себя использовать, но также поддерживает исследователей в разработке новых обучающих методик и предоставлении функций оценки. В прошлом году система Assistments насчитывала больше 50 000 строк программного кода, главным образом, на языке Java. Код включал множество пакетов и классов, которые были разработаны за несколько лет аспирантами и студентами. К сожалению, группе разработчиков не доставало последовательности, поэтому код превратился в крайне неуправляемый - то есть, с каждым днем становился все более хрупким. Что могла предпринять группа для обеспечения качества, необходимого для крупномасштабного развертывания?

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

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

Ему удалось убедить всех. Группа утвердила процесс разработки и приступила к работе. Новая система имеет все функции старой системы и несколько новых, в том числе, улучшенный пользовательский интерфейс. Согласно последней полученной мной информации, группе пришлось написать и обслужить меньше 5 000 строк кода. Это означает более чем 10-кратное повышение производительности, при этом количество дефектов, обнаруженных в системе, меньше, чем средний показатель.

Да, Rails - это не игрушка.

Вместо заключения

Идея автоматической генерации программ не нова. Однако в последние годы мы значительно усовершенствовали эту технологию. Rails - это одна из очень эффективных инфраструктур для создания определенного вида программ понятным, непротиворечивым способом с минимальными трудовыми затратами. Можно ожидать появления систем, подобных Rails, для других предметных областей. Это совсем неплохо в экономическом смысле. Фактически, в сфере создания Web-приложений существует еще два явления. Это две похожих на Rails инфраструктуры, написанные на языке PHP. Они называются Symfony и CakePHP. Недавно появилось еще одно интересное явление в этой области, это Project Zero, инкубаторный проект IBM. Project Zero не является генератором приложений, но он предоставляет соглашения и структуру, напоминающую Rails

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

Примечания

1 На этом пути вам могут помочь многочисленные учебные руководства. Некоторые из них перечислены в разделе Ресурсы в конце этой статьи. Изучите учебное руководство, и вы удивитесь, насколько просто можно создать Web-приложение.

2 Первая бета-версия Rails была выпущена в июле 2004 года. Rails 1.0 увидела свет в декабре 2005 года. В примерах, приведенных в данной статье, используется версия 1.2.2.

10 Massachusetts Comprehensive Assessment System (Комплексная обучающая система Массачусетского университета) См.

Добрый день, друзья. Не так давно мы с друзьями-коллегами решили поизучать Ruby on Rails – что это такое и с чем едят – для использования в будущем при разработке своих проектов.

Так как знаний по данной теме не было вообще, то и двигаться решили постепенно. При начальной установке Ruby с Rails 3.0 мы столкнулись с некоторыми трудностями, о которых в мануалах так сходу никто не упоминал. Поэтому я решил написать это небольшое руководство (которое является обобщением собственного опыта и перевода мануала на guides.rubyonrails.org/getting_started.html) по изначальной установке и настройке Ruby on Rails 3.0 для того, чтобы помочь таким же начинающим как я найти полезную информацию в одном месте и сэкономить свое время.

Манипуляции проводились на системе Windows XP SP2. На Windows 7 все то же самое, а на Висте рельсы у меня не поставились, но об этом позже.

Итак, для начала надо скачать Ruby installer . Инсталляция там нетрудная и все ясно (только сразу обновите переменную PATH, как это предлагается сделать).

Потом запустить командную строку с поддержкой Ruby.

Теперь нам нужно установить рельсы. В командной строке пишем:

gem install rails

На Висте ничегошеньки не получилось – при запуске этой команды появлялось сообщение о том, что не удалось найти папку C:\Users\Владелец. Наверняка, дело тут было в кириллице в названии папки, но особо в детали я вдаваться не стал.

Мы для своих начальных нужд будем использовать базу sqlite3. Чтобы все прошло корректно, нужно будет скачать 2 архива: и и распаковать их в папку с RoR 3.

Теперь в командной строке набираем:

gem install sqlite3-ruby

После завершении установки библиотек sqlite3 нам надо будет создать свое приложение, в нашем случае блог. В командной строке пишем:

rails new blog

Наш блог создан, теперь надо перейти в папку приложения:

Приложения Rails для управления gem-зависимостями по умолчанию используют Bundler. Так как кроме тех gem’ов, что у нас уже есть, других не требуется, можно просто написать:

bundle install

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

Тут я приведу часть дефолтного файла конфигурации (config/database.yml) с информацией по соединению для среды разработки:

Теперь, после конфигурации базы данных, самое время скомандовать рельсам создать пустую базу. Это можно сделать с помощью команды rake:

rake db:create

После этого в папке db/ будут созданы базы development и test.

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

rails server

Увидеть свое приложение в действии можно если открыть браузер и набрать в адресной строке localhost :3000

Страница «Welcome Aboard» - это тест для Rails-приложения, позволяющий убедиться, что вы сконфигурировали программное обеспечении верно. Посмотреть информации о среде вашего приложения можно кликнув на ссылку «About your application’s environment».

Чтобы заставить Rails сказать «Привет», нужны, как минимум, котроллер и представление (view). К счатью, для их создания понадобится всего лишь одна команда:

rails generate controller home index

Rails создаст несколько файлов, включая app/views/home/index.html.erb. Это образец, который будет использоваться для отображения результатов метода index в контроллере home. Откройте этот файл в текстовом редакторе и отредактируйте таким образом, чтобы он содержал лишь одну строчку кода:

< h1 > Hello, Rails!

Теперь, после того как мы создали котроллер и представление, нам надо как-то сказать рельсам когда отображать страницу «Hello Rails». В нашем случае, мы хотим, чтобы эта страница отображалась по корневому URL нашего сайта localhost :3000, вместо тестовой страницы «Welcome Aboard». Первым делом надо удалить дефолтную страницу из нашего приложения:

Del index.html

Теперь нам надо сообщить Rails, где находится наша нынешняя домашняя страница. Откройте файл config/routes.rb в текстовом редакторе. Это файл маршрутизации нашего приложения, который содержит точки входа, написанные на специальном языке DSL (domain-specific language). В этом файле содержится множество примеров путей (они закомментированы), и один из них как раз показывает как соединить свою корневую страницу с конкретным контроллером и выполнить действие. Найдите строчку, которая начинается с root:to, раскомментируйте её и поменяйте, чтобы она выглядела примерно вот так:

root:to => «home#index» скажет Rails отображать действие root на действие (метод) index контроллера home.

Теперь если вы зайдете на localhost :3000, то увидите надпись «Hello, Rails!»

В Rails есть понятие строительных лесов (Scaffold) - это быстрый способ создания главных частей приложения. Если вы хотите создать модели, представления и контроллеры, то это именно тот инструмент, который следует использовать.

В нашем случае (приложение-блог) можно начать с создания при помощи Scaffolding ресурса Post, который будет представлять собой пост в блоге. Для этого нужно написать такую команду:

rails generate scaffold Post name:string title:string content:text

Один из файлов, создаваемых командой rails generate scaffold это миграция базы данных (database migration). Миграции – это классы Ruby, которые разработаны для того, чтобы упростить создания и изменение таблиц баз данных. Для запуска миграций Rails использует команды rake, и есть возможность отменить миграцию после того, как она была применена к базе данных. Название файла миграции включает в себя временную метку, для того, чтобы легко было убедиться в том, что миграции запускаются в порядке их создания.

Если вы откроете файл db/migrate/20100917061914_create_posts.rb (помните, что название вашего файла будет слегка отличаться), то увидите там следующее:

class CreatePosts < ActiveRecord::Migration

def self.up

create_table:posts do |t|

t.string :name

t.string :title

t.text:content

t.timestamps

def self.down

drop_table:posts

Эта миграция создает два метода up, вызываемых при запуске миграции в базу данных, и down, который используется в случае, когда нужно откатить изменения, сделанные в базе данных этой миграцией. Команда up создает таблицу posts с двумя строковыми столбцами и одним текстовым столбцом. Также она генерирует два поля для временных меток, которые нужны для отслеживания создания записей и изменения данных.

Теперь можно запустить миграцию командой:

rake db:migrate

Rails выполнит эту миграцию и сообщит о создании таблицы Posts.

Чтобы подключить посты к домашней странице, которую мы создали ранее, можно добавить ссылку на неё. Откройте файл app/views/home/index.html.erb и измените его следующим образом:

< h1 > Hello, Rails!

<% = link_to "My Blog" , posts_path %>

Метод link_to - один из встроенных в Rails помощников (helper). Он создает гиперссылку, основанную на тексте, который надо отображать и на том пути, куда надо обращаться – в данном случае путь к постам.

Теперь всё готово для того, чтобы начать работу с постами. Чтобы это сделать, нужно открыть ссылку