What's New in Ruby: July 2013

Every month, Kansas City Ruby (#kcruby) reviews a subset of Peter Cooper's fantastic Ruby Weekly selections, along with other items picked up around the web.

Rails 4.0 Final is out!

A big focus has been on making it dead simple to build modern web applications that are screaming fast without needing to go the client-side JS/JSON server route. Much of this work was pioneered for Rails in the new version of Basecamp and focuses on three aspects:

  1. Make it super easy to do Russian Doll-caching through key-based expiration with automatic dependency management of nested templates (explored first in the cache_digests plugin).
  2. Speed-up the client-side with Turbolinks, which essentially turns your app into a single-page javascript application in terms of speed, but with none of the developmental drawbacks (except, maybe, compatibility issues with some existing JavaScript packages).
  3. Declarative etags makes it even easier to ensure you're taking advantage of HTTP freshness.
Also:
Active Resource, Active Record Observers, and Action Pack page and action caching are all examples of things that are no longer in core, but lives on in plugins.
We encourage you to peruse the CHANGELOGs for all the Rails frameworks and delight over the hundreds of improvements we've made to Rails 4.0: Action Pack, Active Model, Active Record, Active Support, Rails.
Finally, you can check out the upgrade guide or the Railscast screencast.

If Your Business Uses Rails 2.3 You Need To Move To A Supported Option ASAP

Executive summary for your CTO: If your company runs Rails 2.3 apps, switch to Rails LTS, a commercially supported fork of Rails. If you do not do this, and do not take one of the more elaborate mitigation steps as described below, your Rails applications will be compromised, you will lose the servers you run on, and your business will suffer substantial losses.
Your Options If You Are Currently On Rails 2.3.X
  1. Do nothing and, with probability of 100%, get your server owned.
  2. Rewrite your applications for Rails 3 or Rails 4, which are currently supported.
  3. Support Rails 2.3 yourself
  4. Pray that someone supports Rails 2.3 for you
  5. Pay for a commercial fork of Rails 2.3

Removing Turbolinks from Rails 4

If you don't want to use Turbolinks with your Rails 4 application, it's easy! Just do this:
  1. Remove the gem 'turbolinks' line from your Gemfile.
  2. Remove the //= require turbolinks from your app/assets/javascripts/application.js.
  3. Remove the two "data-turbolinks-track" => true hash key/value pairs from your app/views/layouts/application.html.erb.
Done!

Free one-month course on fixing common Rails vulnerabilities, via email

You’ll get a new lesson every few days for the next month. By the end, your critical Rails app will be a veritable Fort Knox.

What you’ll learn:

Lesson 1: Three Rails security risks you won’t find in the official guide
Lesson 2: The attack vector behind 87% of one year's detected vulnerabilities
Lesson 3: Surprise! Rails is still vulnerable to SQL injection
Lesson 4: Catching security issues before they reach production
Lesson 5: The power of automated security audits
Lesson 6: Three surprising ways that Ruby's dynamic nature is a risk
Lesson 7: A few Bad Ideas you might have accidentally implemented

What's New and Awesome in Ruby 2

Faster
Ruby 2 has a few patches that dramatically improve performance. The biggest of these is a substantial optimization to Kernel#require, which speeds up Rails startup dramatically.
UTF-8 By Default
All Ruby scripts now default to UTF-8 encoding. This makes the #encoding: utf-8 magic comment no longer necessary.
And more: keywork arguments, lazy enumerators, literal symbol array syntax.

Established 2005 · Databasically © 2016

sitemap