Ruby on Rails *

Для начала мы обратим внимание на Rails 2.3.8 — многие из вас слышали о нем, но не все знают, что конкретного там поменялось. К слову, основные нововведения произошли в версии 2.3.6, а .7 и .8 версии лишь исправляли ошибки.

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

1. Переработан флеш, рекомендуется использовать два базовых типа — alert и notice. А еще его можно использовать с редиректом.
Вот как было:

flash[:notice] = 'Статья добавлена'
redirect_to @article

И как можно писать теперь:

redirect_to(@article, :notice => 'Статья добавлена')

Стоит учесть, что если у вас есть свой тип флеша, например, flash[:error], то добавить его к редиректу не получится.

Спустя 6 месяцев после последнего релиза обновился Ruby on Rails до версии 2.3.6. Изменения в основном связаны с исправлениями багов, добавлением нескольких новых функций и подготовкой плацдарма для перехода на Rails 3.0. С полным списком изменений можно ознакомится по ссылке Ruby on Rails 2.3.6

На следующий день вышел Ruby on Rails 2.3.7, который исправил баги с безопасностью HTML, скопированные из Rails 3.0, но добавил баг связанный с rails_xss плагином. Этот баг делал уязвимыми приложения, которые этот плагин не использовали.

Ну и последним на данный момент является Ruby on Rails 2.3.8, в котором все работает как надо.

Шесть последовательных статей о слиянии Rails и Merb были опубликованы на www.engineyard.com с декабря 2009 до апреля 2010 года. Это вторая статья. Первая тут.

Следующим замечательным улучшением, которое мы надеялись внедрить в Rails из Merb, была лучшая производительность. Поскольку Merb появился после Rails, разработчики Merb имели возможность узнать, какие части Rails использовались чаще, и оптимизировать их производительность.

Мы хотели взять из Merb изменения, улучшающие производительность, и перенести их в Rails 3. В этом посте я расскажу о нескольких оптимизационных моментах, добавленных в Rails 3: уменьшение времени работы контроллера и (сильное) ускорение рендера коллекции партиалов.

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

Совершенствование кода и его оптимизация порой отнимает больше времени, чем заняло написание первой версии. Вы часто встречали новый для вас код или интересную реализацию, и говорили себе: «Оказывается, это можно сделать стандартными средствами, а я изобретал велосипед»? Лично я — да. Поэтому в этой статье я собрал свою коллекцию «велосипедов», и рассказал, как от них можно избавиться.

Методы массивов

Простой пример — допустим, у вас имеется массив объектов класса User. У них есть свойство activated, которое выставляется на 1, если юзер активировал свою учетную запись. Вам нужно проверить, все ли юзеры из массива активированы. Не берем во внимание ActiveRecord (там можно и по-другому сделать), моя цель — показать работу с массивами.

Способ первый, самый примитивный:

1. @users = User.find(:all)
2. activated_users = 0
3. foreach user in @users
4.   activated_users += 1 if user.activated == 1
5. end
6.  
7. # если количество совпадает, значит все юзеры активированы
8. activated_users == @users.size

Шесть последовательных статей о слиянии Rails и Merb были опубликованы на www.engineyard.com с декабря 2009 до апреля 2010 года. Это первая из них.

Сегодня ровно год с того дня, как мы объявили о слиянии Rails и Merb. Тогда было много скептических отзывов относительно успешности этого предприятия. Самой распространенной ассоциацией у тех, кто слышал о наших планах, был единорог. На RailsConf в прошлом году, и DHH (Девид Хайнемайер Ханссон, автор Rails. — прим. перев.), и я упоминали единорога в своих докладах, вызывая смех относительно поставленных нами огромных ожиданий и явной невозможности выполнить их для версии 3.0.

Прошел год, настало время отразить то, как хорошо мы потрудились для достижения поставленных целей. На протяжении следующих нескольких дней я детально опишу прогресс, совершенный в сторону каждого из пунктов моего оригинального поста (http://www.engineyard.com/blog/2008/rails-and-merb-merge/).

Этот пост был опубликован 12 ноября 2009 года, но я думаю он не потерял своей актуальности, потому что плагины к Rails (и не только) все так же актуальны.

Последние дни мы с Карлом работали над системой плагинов. В частности, мы прошлись по Rails Plugin Guide. Читая гайд, мы заметили много излишеств в представленных там идиомах.

Я не упрекаю автора гайда; представленные идиомы в точности повторяют те, которые использовались с самых ранних дней Rails. С другой стороны, глядя на них я вспоминал те дни, когда при виде такого кода мне казалось, что Ruby полон магических заклинаний и относительно простые вещи требуют проведения каких-то особых церемоний (вроде танца с бубном. — Прим. перев.).

Вот пример:

Copy Source | Copy HTML<br/>module Yaffle<br/>  def self.included(base)<br/>    base.send :extend, ClassMethods<br/>  end<br/> <br/>  module ClassMethods<br/>    # любой метод здесь будет применяться классом, например, Hickwall<br/>    def acts_as_something<br/>      send :include, InstanceMethods<br/>    end<br/>  end<br/> <br/>  module InstanceMethods<br/>    # любой метод тут будет применяться экземпляром, например, @hickwall<br/>  end<br/>end <br/>

Начнем с того, что send вообще не нужен. Метод acts_as_something будет вызываться в самом классе, что даст ему доступ к приватному методу include.

 

Yehuda Katz опубликовал эту запись в своем блоге 10 января 2010 года.

Огромное количество действительно хорошей функциональности Rails 2.3 скрыты в его монолитных компонентах. Я уже публиковал несколько сообщений о том, как мы упростили код маршрутизатора, диспетчера и некоторых частей ActionController, частично реорганизовав функциональность ActionPack. ActiveModel — еще один модуль, появившийся в Rails 3 после реорганизации полезной функциональности.

-О чём вы, Морфеус?

Количество фреймворков в мире растёт с пугающей скоростью. Тысячи их уже на данный момент. Благо, лучших из низ — не так много. Весь мир Web разработчиков просто подразделился на несколько групп, которые отадют предпочтение тому или иному фреймворку. Я не люблю тёрок и холиваров, так что бог с ним с тем, что лучше. Я лишь хочу поговорить с разработчиками ASP.NET о Ruby on Rails.

Зачем?

Расскажу свою историю. На ASP.NET я пишу с 2004 года. Знаю множество закоулков данной системы и знаю, что она сама по себе восхитительна. Я пережил 3 больших проекта на .NET и написал с 10 сайтов, которые сейчас продолжают стабильно работать. Если говорить о фрейворкнутости, то .NET меня удовлетворял всем. В самых больших проектах я находил решения самых сложных задач. И вот, через 6 лет мне просто захотелось посмотреть, а что же есть другого на рынке? Естественно, первым делом я наткнулся на RoR.

Мне часто не хватает вывода SQL-лога, когда я вызываю метод find у ActiveRecord-модели в консоли. Если добавить следующие строчки в файл ~/.irbrc, то прямо в консоль будет выводиться лог:

Введение

Как вы уже знаете из поста тов. Yehuda Katz об ActiveModel абстракции, в Rails 3.0, ActiveRecord отныне содержит в себе некоторые аспекты ActiveModel, среди которых модули валидации.

И прежде чем мы начнем, давайте вспомним, какие методы валидации у нас уже есть:

• validates_acceptance_of
• validates_associated
• validates_confirmation_of
• validates_each
• validates_exclusion_of
• validates_format_of
• validates_inclusion_of
• validates_length_of
• validates_numericality_of
• validates_presence_of
• validates_size_of
• validates_uniqueness_of

Все они по прежнему в строю, но Rails 3 предлагает несколько новых отличных альтернатив.

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

Что потеряет поддержку в Rails 3.1?

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

В кратце, передача хеша options, содержащего :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from, :lock любому методу класса, предоставленного ActiveRecord’ом отныне считается устаревшим.

Рассмотрим это более подробно.

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

Тем не менее, всё не так просто, как кажется на первый взгяд. Рассмотрим следующий код:

Привет <strong>друзья</strong>!

<%= tag(:p, some_text) %>
<%= some_text %>


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

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

Речь пойдет о:

• http://api.rubyonrails.org
• http://wiki.rubyonrails.org
• http://guides.rubyonrails.org
• http://railsapi.com
• http://apidock.com/rails

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

Заметка не новая, но я уверен, что и сейчас не все знают всё нижеперечисленное (Здесь и далее курсив переводчика).

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

Замер скорости в контроллерах — это очень просто. Используйте метод benchmark в любой модели.

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

STI (Single Table Inheritance) — паттерн проектирования, который позволяет перенести объектно-ориентированное наследование на таблицу реляционной базы данных. В таблице БД должно присутствовать поле идентифицирующее название класса в иерархии. Зачастую, в том числе в RoR, поле называют type.

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

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

Приступим.

Иногда требуется создать форму, данные которой связаны с несколькими таблицами. К примеру, у вас имеется две модели: Owner и Car. При добавлении нового Owner'a хотелось бы, чтобы была возможность сразу добавить машину. С появлением Rails 2.3 это стало проще.

# Старый вариант (приблизительный)
def create
  @owner = Owner.new(params[:owner])
  ...
  if @owner.save
    @car = Car.new(params[:car])
    if @car.save
    ...
end

# Новый вариант, Rails 2.3+
def create
  @owner = Owner.new(params[:owner])
  ...
end

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

Что же такое полиморфные связи и для чего они нужны? В одном из своих скринкастов Ryan Bates уже рассказывал об этом, и я ни в коем случае не хочу рассказывать то же самое. Ситуация была следующей:

у нас есть модели Статьи, Фотографии и События. А еще есть модель Комментарии. А еще очень хочется все комментарии (комментарии статей, фотографий и событий) хранить в одной таблице.

Статей по этой проблеме в интернете очень много, но бывают и случаи «наоборот». Далеко ходить не нужно, давайте попробуем разработать функционал постов Хабрахабра!

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