Was curious which is faster.

Rehearsal ----------------------------------------------
<<           0.099701   0.017560   0.117261 (  0.117427)
push         0.110768   0.007844   0.118612 (  0.118719)
------------------------------------- total: 0.235873sec

                 user     system      total        real
<<           0.063531   0.002646   0.066177 (  0.066220)
push         0.099184   0.004992   0.104176 (  0.104228)

Code:

require 'benchmark'

Benchmark.bmbm(10) do |bm|
  bm.report('<<') do
    a = []
    1000000.times do
      a << 'foo'
    end
  end

  bm.report('push') do
    a = []
    1000000.times do
      a.push 'foo'
    end
  end
end

Execute this as the root user. If not, you can always add sudo. Here’s the script:


#!/bin/bash

gem install bundler pry interactive_editor


RSpec 3.1 has been released with some interesting changes. Take a look at the changes here.

It has a ton of good stuff including easy exclude pattern, compound block matcher (this will have the most affects on current specs for me), and etc…

Wildcard routes.

There is a vulnerability in the ‘implicit render’ functionality in Ruby on Rails. This vulnerability has been assigned the CVE identifier CVE-2014-0130.

Versions Affected: All Supported
Not affected: None
Fixed Versions: 4.1.1, 4.0.5, 3.2.18

Impact
——
The implicit render functionality allows controllers to render a template, even if there is no explicit action with the corresponding name. This module does not perform adequate input sanitization which could allow an attacker to use a specially crafted request to retrieve arbitrary files from the rails application server.

In order to be vulnerable an application must specifically use globbing routes[1] in combination with the :action parameter. The purpose of the route globbing feature is to allow parameters to contain characters which would otherwise be regarded as separators, for example ‘/’ and ‘.’. As these characters have semantic meaning within template filenames, it is highly unlikely that applications are deliberately combining these functions.

To determine if you are vulnerable, search your application’s routes files for ‘*action’ and if you find any, use one of the work arounds below.

Releases
——–
The 4.1.1, 4.0.5 and 3.2.18 releases are available at the normal locations.

Workarounds
———–
The simplest workaround is to simply not use globbing matches for the :action parameter. As action methods cannot contain a ‘/’ character, the simple matching should be sufficient. So replace

get ‘my_url/*action’, controller: ‘asdf’

with

get ‘my_url/:action’, controller: ‘asdf’

If your application depends on this functionality, you will need to rename the route parameter and add an explicit action:

get ‘my_url/*template_path’, controller: ‘asdf’, action: ‘display’

Then add an action which renders explicitly:

def display
if !params[:template_path].index(‘.’)
render file: params[:template_path]
end
end

Note: The path check in this example may not be suitable for your application, take care

Patches
——-
To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

* 4-1-directory_traversal.patch – Patch for 4.1 series
* 4-0-directory_traversal.patch – Patch for 4.0 series
* 3-2-directory_traversal.patch – Patch for 3.2 series

Please note that only the 4.1.x, 4.0.x and 3.2.x series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

Credits
——-
Thanks to Ville Lautanala of Flowdock for reporting the vulnerability to us, and working with us on a fix.

[1] http://guides.rubyonrails.org/routing.html#route-globbing-and-wildcard-segments

** This is an update from RubyHead post ***

I’ve seen many interesting ways to pass arguments to rake tasks. The fact of matter is, I really don’t like messing around with any constant or global variable. Here’s how I like to do it.

rake mytask:do_something 1 2 3

Arguments 1, 2, and 3 will be available in the task. Therefore, if you look at the arguments($*), you’ll see [“mytask:do_something”, “1”, “2”, “3”]. Just reject the first in the Array and you got yourself arguments

Here’s another example of passing in “Hash”. This is with quotes because there’s a bit of manipulation needed.

rake mytask:do_something setting:WHATEVER user:me

Using the argument facility built into Ruby, just create a hash inside of my task. I can even create a method to do this for all tasks. Below is my implementation.

desc "my task do something"
task :do_something => :environment do
  options = {}
  $*.each {|arg| options[arg.split(":")[0]] = arg.split(":")[1]}
  options.reject! {|k,v| v == "" || v.nil? }
  # I now have {"setting" => "WHATEVER", "user" => "me"}
  # for whatever I want to do.
  # ...

  exit
end

Make sure you have exit or it will try to run arguments as a series of tasks.

I think it’s cleaner and easier way to do it, but that’s just my opinion. By the way, $* has an alias, ARGV.

Here’s the link

Ruby 2.1 has many improvements including speedup without severe incompatibilities. You can use this on Rails and some applications, and get more comfortable experience.