Что нового в Rails 4

Четвёртая версия фреймворка Ruby on Rails уже не за горами. Хотя официальной даты релиза еще нет, многие ожидают release candidate уже в начале этого года.
Эта версия фреймворка разрабатывается уже год и представляет из себя множество изменений во внутренней архитектуре. Фреймворк эволюционировал и прибрёл более модульный формат, большинство из нововведений раскидано по отдельным джэмам, для того, чтобы основной код оставался чистым. Таким образом, устаревший функционал можно официально не поддерживать, но использовать, если такая необходимость возникнет.

Во время написания этих строк Engine Yard пока что официально не поддерживает Rails 4 в наших облачных продуктах. Однако, если вы хотите таки их опробовать, вы, конечно, же сможете. Однако будьте внимательны — некоторые возможности, особенно live streaming, скорее всего не будут работать.

Если вы столкнётесь со сложностями при попытке развёртывания приложений на Rails 4, то их нужно регистрировать как feature requests, а не как баг, так как мы ещё не закончили интегрирование Rails 4 в наши продукты.

Заметные изменения в Rails 4

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

Ruby 1.9.3 Minimum

Одно из самых заметных изменений в Rails 4, на которое все разработчики должны обратить внимание, это то, что теперь Ruby 1.9.3 является минимальным требованием. Поддержка 1.8.7 была полностью прекращена, но, учитывая, что большинство из нас используют 1.9.3, нет причин волноваться о поддержке 1.9.2. Фактически, этот commit от Jose Valim прямо говорит пользователю, что Rails 4 требует Ruby 1.9.3+ и прерывает работу немедленно, если RUBY_VERSION < 1.9.3.
Что это означает для вас? Во-первых, если вы используете 1.8.7 или Ruby Enterprise Edition (что фактически является 1.8.7 с небольшими возможностями настройки производительности), вам стоило бы обновиться в любом случае. Обновление с 1.8.7 до 1.9.3 может быть как безболезненным, так и достаточно сложным – всё зависит от программы, её зависимостей и того, что могло устареть между этими двумя релизами. Проследите за тем, чтобы у вас было хорошее покрытие кода, переключите интерпретатор в development mode на 1.9.3 ( с RVM это крайне просто), и запустите тесты. Если вас интересуют дополнительные советы, как перейти с 1.8 на 1.9, прочитайте эту статью моего коллеги из Engine Yard, Anthony Accomazzo.
В любом случае, я крайне рекоммендую всем использовать только последние стабильные версии интерпретатора с последними доступными обновлениями для достижения лучшей производительности и уровня безопасности.

Больше нет vendor/plugins

Папка vendor/plugins отсутствует в Rails 4. Вместо этого, вам нужно использовать Bundler с нужным путём или Git зависимостью.
Многие устаревшие вещи переместились в отдельные джемы

Hash-based и методы dynamic finder

Вы возможно помните, что в последних версиях Rails постоянно выдавались предупреждения деприкации “старого” синтаксиса запросов ActiveRecord. Например:

User.find(:first, :conditions => { … }) 

Поддержки такого синтаксиса в Rails 4 больше нет. Чтобы добавить эту функциональность в вашу программу, вам придётся установить следующий джем activerecord-deprecated_finders gem: github.com/rails/activerecord-deprecated_finders

ActiveRecord::SessionStore

Хранение сессий в базе данных — это интересная особенность многих полезных программ, особенно это касается конфиденциальной информации, но, в большинстве случаев, это не столь эффективно, как использование простого cookie. Итак, ActiveRecord::SessionStore отсутствует в Rails 4. Используйте activerecord-session_store джем, чтобы вернуть этоту фунциональность: github.com/rails/activerecord-session_store.
Если уж быть дотошным, хранить конфиденциальную информацию в cookie — это плохая идея по многим причинам. Отсутствие шифрования (или слабое шифрование) является лишь одной из них. Лучшим решением хранения такой информации было бы использовать базу данных (защищённую сетевым уровнем доступа и самим приложением), а затем просто ссылаться на ID в объекте сессии. То бишь вместо установки целого объекта в сессии или даже мета информации об объекте, вы можете сохранить объект в базе данных и просто ссылаться на его ID внутри сессии пользователя (и поместить его мета информацию в memcached или PostgreSQL hstore).

ActiveResource

ActiveResource это ORM (Объектно-реляционное отображение) для сервисов, основанных на REST. Оно было удалено из Rails 4 и больше не будет выходить вместе с ним. Guillermo Iguaran сообщил в Yeti Media блоге, что мотивацией для этого было то, что его поддержке не было выделено то необходимое количество любви и внимания основной команды разработчиков, которого оно заслуживает. После того, как ActiveResource был отделён, им занялась отдельная команда разработчиков во главе с Jeremy Kemper. С момента отделения было добавлено много новых возможностей, так что для всех поклонников ActiveResource это должно было стать скорее хорошей новостью. Это также стало полезным для тех, кто хотел бы использовать функциональность ActiveResource без необходимости использовать для этого весь Rails. Для использования ActiveResource просто включите ‘activeresource’ джем: github.com/rails/activeresource.

Rails Обозреватели (Observers), Кэширование страниц и действий

Возможность кэширование страниц и действий была удалена из Rails 4 в пользу кэширования под кодовым названием “Матрёшка” (Russian Doll). У DHH (David Heinemeier Hansson) есть джем, который объясняет, как работает такое кэширование (см. github.com/rails/cache_digests для дополнительной информации).
Учитывая отсутствие кэширования страниц и действий, необходимость в обозревателях практически отсутствует. Во многих случаях эти обозреватели используются для истечения срока кэша, который, благодаря схеме кэширования в Rails4, не так уж и необходим. Также обозревателями зачастую злоупотребляют, используя их как свалку для персистентных операций (persistence operations), где callback был бы гораздо более уместен. Так что Rails 4 выйдет без кэширования страниц, действий и обозревателей.
Чтобы включить их в программу, взгляните на:

github.com/rails/actionpack-action_caching
github.com/rails/actionpack-page_caching
github.com/rails/rails-observers

Dalli вместо memcache-client

Dalli используется теперь вместе с memcached вместо memcache-клиента. Это нововведение будет одобрено многими разработчиками, так как Dalli намного шустрее, чем memcache-клиент, и позволяет использовать параллелизм (многопоточность) — тема, которая вызывает большую озабоченность в руби сообществе. Чтобы использовать эту функциональность вам нужно добавить джем “dalli” в ваш Gemfile, если он там до сих пор отсутствует и указать mem_cache_store как ваш cache store.

New Default Test Locations

Новички Rails и TDD (разработки через тестирование) зачастую смущены настройками по умолчанию и наименованиями. “Моделям” соответствуют “юниты”, тестам “контроллеров” — “функциональные” тесты и т.д. В Rails 4 это изменится для большей ясности. Наименования местонахождения тестов по умолчанию будут более схожими с наименованиями rspec конвенции для тестов на Rails:

app/models -> test/models (было test/units)
app/helpers -> test/helpers (было test/units/helpers)
app/controllers -> test/controllers (было test/functional)
app/mailers -> test/mailers (было test/functional)

Если у вас будет настроение, и вы захотите почитать о наименованиях тестов и их предназначении, то вам обязательно нужно прочитать или поучаствовать в этой дискуссии. В начале комит был предназначен для переименовывания теста “интеграции” (test/integration) в “acceptance” тест. Хотя остальная часть этого запроса была принята положительно, конкретно это изменение вызвало множество дискуссий, что является “acceptance” тестом, а что нет. В конце концов автор коммита blowmage решил оставить название таким, какое есть, чтобы не задерживать утверждение коммита, чем вызвал одобрение нескольких основных разработчиков Rails.

Глагол PATCH

Rails использовал “PUT” HTTP метод для изменения существующих ресурсов достаточно давно. Однако спецификация семантики HTTP подразумевает под PUT полную презетнацию ресурса. Другими словами, PUT, говоря семантически, должен содержать полную презентацию объекта, который нужно изменить. Следовательно, с технической стороны, мы делали это “неправильно” уже достаточно долго, посылая кусочки объекта, который нужно поменять, когда совершали RESTful обновления с помощью PUT.
Именно поэтому в Rails 4 эта функциональность изменена, и нужно использовать глагол PATCH. Как само название подсказывает нам, PATCH предназначен для того, чтобы пересылать кусочки информации об объекте на сервере без его полного описания. Это точнее соответствует семантике HTTP, как это описано в RFC 5789.
Как и при использовании всех RESTful форм в Rails, будет сгенерировано скрытое “_method” поле с указаниям того, что метод “PATCH” будет использован вместо “PUT”. И как и ожидалось, маршрутизация свяжет метод PATCH с “update” действием в контроллере.
Для того, чтобы осталась обратная совместимость, бывший метод PUT также будет направлен к “update” в Rails 4.0, чтобы существующие APIs могли продолжить свою нормальную работу.
В блоге Rails можно узнать больше информации о методе PATCH. Это отличное изменение, и то, что было подумано об обратной совместимости, облегчит разработчикам процес обновления.

Threadsafe по умолчанию

Ruby разработчики уже давно стремились достичь настоящей многопоточности без использования GIL, и авторы Rails понимают, что MRI это не единственный способ запуска приложений в производство. Многопоточность серверов и приложений позволяет значительно увеличить производительность путём использования общих сегментов памяти и позволяет одновременное выполнение кода.
Однако, стандартный интерпретатов руби, известный как “MRI”, не является по-настоящему многопоточным. Он может выполнять код одновременно, если один поток ожидает ввода/вывода, что может позволять основным библиотекам C выполнять код одновременно, но сам код руби всё равно выполняется последовательно из-за присутствия GIL.
В Rails уже давно есть возможность запускать код многопоточно, но эта функциональность не была включена по умолчанию и это будет изменено в Rails4. Это не такое уж и большое изменение, учитывая, что вы можете включить многопоточность в большинстве Rails приложений прямо сейчас немного изменив настройки и перезапустив threadsafe сервер. Однако это стоит выделить по той причине, что сообщество руби всё больше и больше понимает необходимость одновременного выполнения кода.
Aaron Patterson обсуждает config.threadsafe! более подробно в следующей статье:
tenderlovemaking.com/2012/06/18/removing-config-threadsafe.html

Postgres H-Store

ActiveRecord в Rails 4 будет поддерживать расширение PostgreSQL hstore. Это расширение для базы данных позволяет создавать новый тип данных в колонках PostgreSQL, который будет называться ‘hstore’, который представляет собой string-only хэш. Для большинства намерений и целей это похоже на сериализацию данных в текстовом столбце, но то, что это является теперь нативным типом данных, даёт нам солидную прибавку производительности и возможность посылать прямые запросы к этому типу данных. Это означает, что у вашего приложения будет частично non-schematic база данных без необходимости использования MongoDB, CouchDB, Riak или другого non-schematic datastore.
Hstore расширение, хоть и не является полномасштабным non-schematic решением, его интеграция в Rails будет прекрасным дополнением для многих приложений. Бывают ситуации, когда большинство ваших данных нормализировано для конкретной модели, но на некоторую информацию нужно ссылаться на лету. Вот где hstore может по-настоящему себя проявить.

Давайте приведём простой пример. Допустим, вашему приложению нужно определять новые пары типа “ключ/значение” на лету – определять схему объекта, которая будет разной у различных пользователей. Может быть это будет определённый тип формы в CMS. Приёмная доктора может захотеть узнать информацию о пациенте, а эвент-менеджеру нужна совсем другая информация. В прошлом это решалось сериализацией, но благодаря hstore у нас для этого есть нативный способ, что облегчает создание запроса.
Вы можете начать использовать hstore в PostgreSQL с помощью activerecord-postgres-hstore джема. Ryan Bates создал подкаст на эту тему, где очень хорошо объясняет, как это работает и показывает множество примеров использования и создания запросов. Вы также можете узнать больше о hstore, читая официальную PostgreSQL документацию. Хотелось бы отметить, что вы можете использовать hstore на платформе Engine Yard используя PostgreSQL 9.1+, как вашу среду базы данных. Для этого вы можете использовать созданные Chef скрипты в разделе postgresql9-extensions на GitHub.

Array, MACADDR, INET, CIDR

Раз уж мы говорим о новых типах данных, поддерживаемых PostgreSQL и Rails, стоит отметить, что ActiveRecord вместе с Rails 4 будут поддерживать в PostgreSQL следующие типы данных: Array, MACADDR, INET и CIDR. Хотя они обычно хранятся как строки в большинстве баз данных, PostgreSQL предостовляет поддержку нативных типов данных для каждого из них, а ActiveRecord сможет это использовать.
Типы данных INET и CIDR будут преобразованы в инстансы класса IPAddr, массивы будут массивами, а MAC адреса на запросы будут возвращаться строками.

Live Streaming

Aaron Patterson представил новую функциональность в Rails 4, называемую Live Streaming. Это фактически позволяет транслировать контент в браузер подсоединённых пользователей напрямую с сервера с помощью длинных опросов (long-polling) в браузере. И тот факт, что браузер имеет решающее значение для этого процесса должны намекнуть вам об очевидной проблеме: Internet Explorer это еще не поддерживает. Это может быть исправлено в будущих версияю IE, однако на данный момент live streaming не работает в браузере Microsoft’а.
Live Streaming в Rails 4 также открывает множество интересных возможностей для вашего приложения. Наибольшую пользу это принесёт приложениям, использующим информацию, получаемую в реальном времени: биржевые сводки и финансовые приложения, игры и т.д.
Engine Yard пока что не поддерживает live streaming по ряду причин. У нас есть на выбор два веб сервера: Unicorn и Passenger. Ни один из них это пока что не поддерживает. Passenger 4 Enterprise, разрабатываемый в данный момент компанией Phusion, будет поддерживать live streaming в Rails, и мы будем интегрировать Passenger 4 в наш стэк, как только от достигнет release статуса.
Этим мы не хотим сказать, что Live Streaming не доступно у Engine Yard, просто это не будет работать out-of-the-box, и требует дополнительной настройки. Мы планируем изменить это добавив возможность использования других серверов приложений. К примеру, Puma уже доступна, как Early Access, точно также, как и Rubinius.

Cache Digests (aka Russian Doll Caching)

Сache digest джэм автоматически добавляет цифровую подпись к каждому фрагменту, закэшированному в вашем приложении.
Например в вашем приложении кэшируются Authors и Posts:

<b id="internal-source-marker_0.9843547998461872">class Author < ActiveRecord::Base  has_many :posts end  class Post < ActiveRecord::Base  belongs_to :author, touch: true end</b> 

( хочу отметить, что добавление touch: true к ассоциации belongs_to является крайне важным, так как заставляет также менять updated_at у Author, когда любые посты author’а обновляются)
Обычно вы бы фрагментировали кэш следующим образом:

<!-- app/views/authors/show.html.erb --> <% cache [‘v1’, @author] do %> <h1><%= @author.name %>’s posts:</h1> <%= render @author.posts %> <% end %>  <!-- app/views/posts/_post.html.erb --> <% cache [‘v1’, post] do %> <div><%= link_to post.title, post %></div> <% end %> 

Проблема в том, что вам нужно обновлять ключи внутри массива каждый раз, когда вы хотите изменить фрагмент кэша. Благодаря “cache digest” в Rails 4 вы можете просто просто опустить массив и Rails автоматом сгенерирует вам контрольную сумму MD5 для кэша. Когда файл изменяется, одновременно меняется и контрольная сумма, что выливается в новый “cache digest”.
Всё вышесказанное можно продемонстрировать следующим образом:

<!-- app/views/authors/show.html.erb --> <% cache @author do %> <h1><%= @author.name %>’s posts:</h1> <%= render @author.posts %> <% end %>  <!-- app/views/posts/_post.html.erb --> <% cache post do %> <div><%= link_to post.title, post %></div> <% end %> 

Ryan Bates объясняет это более подробно в своём скринкасте (бесплатном), и вы уже можете использовать эту функциональность в Rails 3.2 приложении с помощью cache_digests джема.

Безопасность

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

Mass Assignment защита в контроллере

Лично я рад, что mass assignment защита была перенесена в контроллер. Этого осуществимо простым добавлением атрибутов объекта в черный или белый список внутри контроллера. Взгляните на простой пример.
Допустим, вы создаёте небольшое веб приложение, чтобы принимать рецепты (кулинарные). Любой, кто создаёт рецепт, становится известен, как “chef” и у рецепта есть имя, ингредиенты и описание. Ради оперативности мы будем подразумевать, что вопросы авторизации и аутентификации уже решены.

<b id="internal-source-marker_0.9843547998461872">class RecipesController < ApplicationController  def create    @recipe = Recipe.new(recipe_params)    @recipe.chef = current_user # explicitly assign it to the right user    if @recipe.valid? and @recipe.save      redirect_to @recipe,                  :flash => { :notice =>                  “Your recipe was added to the cookbook. Mmmm, tasty!” }    else      render :action => :new    end  end  private   def recipe_params    params.require(:recipe).permit(:name, :ingredients, :directions)  end</b> 

Применяя этот новый способ защиты mass assignment, мы говорим Recipe.new принять хэш, который вернул нам метод recipe_params, который является частным (private) методом контроллера. Этот метод отделяет всё ненужное, что недозволенно “recipe” параметрами. Если я бы захотел послать следующее к этому контроллеру (представленному хэшем):
{name: “Texas Chili”, ingredients: “hot stuff”, chef_id: “123”}
“chef_id” параметр был бы удалён методом recipe_params, потому что он не разрешён, и затем “прошедший санабработку” хэш передался бы к Recipe.new. Это предотвратило бы произвольное присвоение объекта Recipe любому “chef” (автору), которого бы выбрал аттакующий.
Это солидное изменение, в сравнении с тем, как mass assignment обрабатывался в предыдущих версиях Rails. Вместо того, чтобы пихать эти проблемы в модель, теперь они решаются внутри контроллера. Это может быть несколько спорным по ряду причин.
Я помню, что разговаривал с одним из участников на Austin Web Bash по поводу разногласий, где же находятся ответственности поведения объекта. По теории пуризма, могло бы быть возможным направить любую информацию к объекту и верить, что объект сам знает, что с этим делать. Так работала защита mass assignment в предыдущих версиях Rails с его attr_accessible/attr_protected. Вы могли передать объекту любую информацию (тесты, live production данные по HTTP, и т.д.) и объект был ответственен за её обработку.
Однако это палка о двух концах. Rails является фреймворком для веб приложений. Это означает, что, по сути, информация подаётся из двух каналов: пользователем и разработчиком. Разработчику стоило бы верить, а пользователю — нет. Так как единственным местом атаки со стороны пользователя является контроллер, это было бы логичным местом для защиты информации, вместо того, чтобы делать это внутри самой модели. В большинстве проектов вы столкнётесь с ситуациями, которые потребуют доступа через консоль или манипуляций с информацией (то же мигрирование). Набор руками ‘object.method = “foo”’ для различных специфических свойств каждый раз, когда это нужно, является пустой тратой времени, превращает вас в зомби и убивает продуктивность. С защитой mass assignment в модели это то, что вас ожидает. Даже в случае программных миграций и тестов, всё равно есть шанс возникновения непредвиденных проблем в разработки тестировании из-за mass assignment защиты на модельном уровне, даже если вы манипулируете информацией в бэкенде безопасным способом. Переместив эти задачи в контроллер, мы избавляемся от этой проблемы и одновременно сохраняем чистоту пользовательского ввода.
По сути, это выбор: или более гибкие операции с данными, следя за чистотой ввода при помощи контроллера, или менее гибкие, но с сохранением желаемого дизайна объекта. Если вы всё же хотите использовать attr_protected/accessible, используйте protected_attributes джем в вашем Rails 4 приложении.
Если вы хотите начать использовать защиту на уровне контроллера, взгляните на strong_parameters джем, совместимый с Rails 3.2.x.

Default Headers

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

config.action_dispatch.default_headers = { 'X-Frame-Options' => 'SAMEORIGIN', 'X-XSS-Protection' => '1; mode=block', 'X-Content-Type-Options' => 'nosniff' } 

Вы также можете установить и другие. Больше об этом можете почитать в посте — edge guide on security.
Это также может быть полезно разработчикам мобильных приложений. Вы сможете влключать мета-данные по умолчанию во все запросы, и затем построить своё приложение так, чтобы она искала эти мета-данные. И хотя вы всегда можете добавить заголовки к каждому запросу через контроллеры, эта опция позволит вам делать это автоматически для каждого запроса.

Encrypted Cookies

Здесь описано как работают зашифрованные cookies в Rails 4. Если кратко, то у вас будет новая session_store опция под названием ‘encrypted_cookie_store’. Этот session store зашифрует cookies когда отсылает их, и расшифрует, когда приложение будет готово их считать. Это предотвратит фальсификацию со стороны конечного пользователя и будет служить дополнительным уровнем защиты вашего приложения.
Однако даже с этой опцией, я всё равно бы предостерёг вас от хранения конфиденциальной информации в cookies. Алгоритм используемый для за/дешифровки вроде бы основан на SHA, это означает, что кластер GPU и немножко программирования на CUDA, и конфиденциальная информация внутри cookie всё равно может быть выужена достаточно быстро, так как на всё семейство SHA алгоритмов не требуется очень много вычислительных ресурсов, как, например для bcrypt. И если обобщать, хранение конфиденциальной информации на стороне пользователя является плохой идеей. Лучше хранить это в какой либо базе данных, защищённой сетевым уровнем доступа и вашим приложением.
В любом случае, возможность зашифровывать ваши cookies крайне полезна для предотвращения фальсификаций, и этот способ хранения cookies/сессий в Rails 4 выставлен по умолчанию.

Чего же не будет в Rails 4?

Есть пару очень ожидаемых нововведений, которые, судя по всему, не будут включены в Rails 4.0. Возможно из включат в 4.1.

Фоновые очереди

Rails 4 поначалу имел возможность фоновых очередей в API, и Sidekiq и/или Resque могли бы интегрировать это в свою работу. Однако этот коммит перенёс эти возможности в отдельную от главной ветку, ссылаясь на то, что эта возможность была еще “полусырой”. Rafael Franca отмечает, что этот функционал был неким препятствием для выхода Rails 4, и он отложил его дебют, чтобы не задерживать основной релиз.

Асинхронный ActionMailer

Так как API c поддержкой фоновых очередей был отложен, поддержка асинхронного ActionMailer также была отложена, так как его функционал зависит от функционала, предоставляемого фоновыми очередями через API.

where.like и where.not_like

Многие ожидали возможности обращаться к ‘not_like’ методу в модели, например, Book.where.not_like(title: “%Java%”), однако этот коммит отодвинул выход этого функционала из ActiveRecord. DHH приводит причины, вызвавшие это решение, хотя, кажется, не все с ним согласны. Он предлагает, чтобы комьюнити вынесла это в отдельный джем, вместо того, чтобы делать это частью ActiveRecord. Один из его аргументов было нежелание продвигать дальше DSL в такие вещи как “greater_than_or_equal”, потому что использование знака процента похоже на странный синтаксический конфликт в Ruby, и что LIKE запросы в общем-то достаточно редки.

Заключительные мысли

В Rails 4 есть много нового и интересного, что позволит вам создавать более безопасные, семантически правильные и эффективные приложения. Я бы порекомендовал всем начать обновлять их кодовую базу до Rails 4, как только он выйдет, однако делать это нужно должным образом.
Тем, кто всё ещё использует Rails 2.x, я рекомендую обновить свою кодовую базу хотя бы до Rails 2.3.15 (последняя версия со всеми патчами), а затем до Rails 3.2. Вы можете мигрировать релиз за релизом, чтобы не спешить и всё сделать аккуратно, или, если вам хватает смелости, сразу обновитесь до 3.2 и разбирайтесь со всем проблемами по мере их возникновения. Естественно, хорошее покрытие кода в тестах будет ключевым фактором при обнаружении проблем до запуска приложения в производство, и мы всегда советуем сначала запускать приложение в отладочной среде (клонируя рабочую) перед окончательным развертыванием приложения.
Тем из вас, кто уже использует 3.2 обновиться будет проще всего, так как многое в Rails 4 является переработанными возможностями с некоторыми встроенными нововведениями. Используйте преимущества зашифрованного cookie store и измените свою защиту mass assignment, и переместите её на уровень контроллера (если только вы действительно не против такого подхода и желаете использовать вместо этого вышеупомянутый джем).
В целом, Rails 4 будет отличным релизом со многими улучшениями фреймворка, который мы знаем и любим. Я с нетерпением его ожидаю, и, надеюсь, я не одинок.
Для дальнейшего изучения:

blog.remarkablelabs.com/2012/11/rails-4-countdown-to-2013
blog.wyeworks.com/2012/11/13/rails-4-compilation-links/
weblog.rubyonrails.org/2012/11/21/the-people-behind-rails-4/
edgeguides.rubyonrails.org/4_0_release_notes.html
rubyrogues.com/081-rr-rails-4-with-aaron-patterson/
Rails 4 Whirlwind Tour: vimeo.com/51181496

Эта статья является переводом статьи на нашем официальном блоге.
Часть 1, Часть 2.
Автор — J. Austin Hughey
Перевод — мой

Я планирую переводить все важные новости нашей компании и все интересные статьи, появляющиеся в нашем блоге. Было бы крайне интересно выслушать пожелания и советы.
Я постараюсь ответить на возможные вопросы. Если мне не хватить технических знаний — переспрошу у наших инжинеров. Спасибо!