Today I Learned

39 posts about #ruby

Finding a Rake Task Definition

Suppose you use a certain Rake task. Is there an easy way to find out where that task is defined?

There is. Use the --where option.

Example: rake --where packman:update

Hash keys must be symbols for keyword arguments

Recently our team worked on a ticket which required us to remove the tooltips for Edit, Delete button.

As an initial approach, we changed the signature by parameterizing the tooltip, and inserted into #link_to helper. To preserve the options parameter, we converted it into a keyword argument (**options).

def link_to_delete_remote(object, path, tooltip: _("Delete"), **options)
   link_to(options[:title], path, options.merge('data-bad-after': js, id: link_id, title: tooltip, remote: true))
 <%= link_to_delete_object(job, tooltip: nil) %>

However, bunch of specs started failing with the following message.

# ArgumentError: wrong number of arguments (given 3, expected 2)

Turns out, there were few callers of the method who were passing in an object that contains String keys, and they weren’t being used as keyword arguments…

<%= link_to_delete_object(
      "some-string-key" => _("some_string_value"),
      "another-string-key" => true
    ) %>

In the end, we reverted the signature, injected tooltip: nil to options object, and just inlined options.fetch(:tooltip, _(“Delete”))

  def link_to_delete_remote(object, path, options = {})
    link_to(options[:title], path, options.merge('data-bad-after': js, id: link_id, title: options.fetch(:tooltip, _("Delete")), remote: true))

Dig-ging into Data

Ruby 2.3 added a couple of dig methods to aid in accessing nested data.

Here's some Hash and Array examples:

hash = {
  animals: {
    furry: ["dog", "cat"],
    spikey: ["porcupine", "echidna"]

hash.dig(:animals, :furry)
# => ["dog", "cat"]

# safely returns `nil` for missing keys
hash.dig(:plants, :yellow)
# => nil

array = [1, [[2, 3], 4, 5], 6]

array.dig(1, 0, 1)
# => 3

# dig on arrays take indexes, and repeatly call dig on the result
# thus, you have to be careful if the return type is not an array!
# => 6

array.dig(2, 3)
# => TypeError: Fixnum does not have #dig method

# and duck typing means they can be combined!
hash.dig(:animals, :spikey, 1)
# => "echidna"

Finding Where Rake Tasks Are Defined in Rails

Rake has an option to print where a task was loaded from.

$ rake -W gettext:find
rake gettext:find   $HOME/.rvm/gems/ruby-2.3.3/gems/gettext_i18n_rails-1.8.0/lib/gettext_i18n_rails/tasks.rb:64:in `block in <top (required)>'

We can also get this data with code. This allows us to explore the tasks (e.g. filtering). In a Rails console:

# load up all the tasks Rails knows about
> Rails.application.load_tasks

# if you know the task you are looking for:
> Rake::Task["gettext:find"]
 => [["$HOME/.rvm/gems/ruby-2.3.3/gems/gettext_i18n_rails-1.8.0/lib/gettext_i18n_rails/tasks.rb", 64]]

 # if you want to explore known tasks
 > gettext_tasks = { |e| "gettext:" }
 => [<Rake::Task gettext:add_language => [environment]>, <Rake::Task gettext:base_without_table_attributes => [environment]>, <Rake::Task gettext:find => [setup]>, <Rake::Task gettext:pack => [setup]>, <Rake::Task gettext:setup => [environment]>, <Rake::Task gettext:store_model_attributes => [environment]>]
 > pp Hash[ { |t| [, t.locations] }]
  ["$HOME/.rvm/gems/ruby-2.3.3/gems/gettext_i18n_rails-1.8.0/lib/gettext_i18n_rails/tasks.rb:99:in `block in <top (required)>'"],
  ["$HOME/src/packmanager/master/lib/tasks/gettext.rake:27:in `block in <top (required)>'"],
  ["$HOME/.rvm/gems/ruby-2.3.3/gems/gettext_i18n_rails-1.8.0/lib/gettext_i18n_rails/tasks.rb:64:in `block in <top (required)>'"],
  ["$HOME/.rvm/gems/ruby-2.3.3/gems/gettext_i18n_rails-1.8.0/lib/gettext_i18n_rails/tasks.rb:59:in `block in <top (required)>'"],
  ["$HOME/.rvm/gems/ruby-2.3.3/gems/gettext_i18n_rails-1.8.0/lib/gettext_i18n_rails/tasks.rb:43:in `block in <top (required)>'"],
  ["$HOME/.rvm/gems/ruby-2.3.3/gems/gettext_i18n_rails-1.8.0/lib/gettext_i18n_rails/tasks.rb:82:in `block in <top (required)>'"]}

What does the zeus's read unix EOF error mean?


I'm running zeus, and it dies with the following error:

slavenode.go:226: [boot] read unix ->: EOF

What on Earth could be causing that? How do I fix it?


UPDATE (2018-06-13): I realized that this is one possible fix to this issue. Still useful info, so I'll leave it here.

Run bundle install


Def keyword can also be used as a begin statement

In Ruby, the begin keyword for exception handling (ie, begin...rescue...ensure, traditionally try...catch...finally in other languages) is optional. You can have a method that only declares a rescue or an ensure statement without begin. That's because the def statement in the method can serve the same purpose as begin. This means that this method:

def edit
    @user = find(params[:id])
  rescue ActiveRecord::RecordNotFound
    redirect_to :back

Can legally be shortened to:

def edit
  @user = find(params[:id])
rescue ActiveRecord::RecordNotFound
  redirect_to :back

Safe Navigation Operator

If you have worked in a Rails project, you have probably came across the try and try! methods. try saves us from checking conditions before drilling-down through a message chain. try! is more restrictive; it raises when the receiver does not respond to the method:

require "active_support"
require "active_support/core_ext/object/try"

User =

users = ["Jason")]

# "Jason"

# nil

# NoMethodError: undefined method `unknown_method' for #<struct User name="Jason">

Note these methods are provided by ActiveSupport. As of Ruby 2.3, this behaviour is now available in the language, called the safe navigation operator &.:

users = [ "Jason")]
# "Jason"

users = []
# nil


When an object does not respond to a method, &. behaves like try!; it raises an error. However, nil seems to break this pattern:

# behaviour like try!
# NoMethodError: undefined method `unknown_method' for #<struct User name="Jason">

# given that
# true

# this is confusing
# nil

The last example has a simple explanation: &. checks the receiver. Since the receiver is nil, &. immediately returns nil. It does not matter that nil responds to the message.

Block Kwargs

Ruby 2.0 introduced keyword arguments. Ruby 2.1 further added required keyword arguments. It is common to see methods using kwargs:

def some_method(keyword_arg: "Hello", required_arg:)
  puts "#{keyword_arg} #{required_arg}"

some_method(required_arg: "world")
# Hello world

However, these changes also apply to block arguments:

define_method :prints_block_arguments do |default_arg: "hello", required_arg:, **others|
  puts "default_arg: #{default_arg}"
  puts "required_arg: #{required_arg}"

  others.each_pair do |key, value|
    puts "other arg: #{key} => #{value}"

prints_block_arguments(required_arg: "world")
# default_arg: hello
# required_arg: world

prints_block_arguments(default_arg: "ciao", required_arg: "mondo", something: "else")
# default_arg: ciao
# required_arg: mondo
# other arg: something => else

# ArgumentError: missing keyword: required_arg

Using module_function instead of extend self

It's a common pattern to use extend self inside ruby module to make all methods available in a static context/declared as class methods.

Instead of this, you can use module_function instead which will do the same as extend self but also have the added benefit of making those method private instance methods when they are included in another file.

module UserNameFormatter

  def format_name(user)

class User
  include UserNameFormatter

  def something

Enumerable Predicate Methods Have a New Argument

Enumerable#grep accepts an argument that returns elements that are true using case equality (===). These elements can then be passed to its block for further proccessing:

fruits = %w(apples orange grapes)
fruits.grep(/s$/) # => ["apples", "grapes"]
fruits.grep(/s$/) { |e| e.start_with?("a") } # => [true, false]

In Ruby 2.5, this parameter argument was added to the Enumerable predicate methods all?, none?, one?, and any?.

fruits = %w(apples orange grapes)
fruit.any?(/s$/) # => true

# === works with more than Regexes!
[1, 3.14, 2ri].all?(Numeric) # => true
[0, 1, 2, 3].all?(1..10) # => false
[0, 5].one?(1..3) # => false
[0, 5].none?(1..3) # => true

More Expressive Regular Expressions with Ruby

I came across some parsing code that contained this regular expression:

# the first capture is the left quote
# the second capture is the string content
# the third capture is the right quote
METHOD_CAPTURE = /Module\.method\(\s*(['"])(.+?)(['"])\s*\)/

This regexp is matching the string contents of a particular method call. It captures three pieces of information, mentioned in the comments.

This code is not self-documenting. We have three comments explaining the captures, and a regexp we must parse in wetware.

Furthermore, numerical indexes are difficult to track and modify in complicated regexps. PCRE supports named captures; denoted in Ruby by (?<name>pattern).

To make the comments superfluous, let's refactor using the following:

  1. Use named capture groups
  2. Use interpolation to give descriptive names to common components
  3. Don't capture needlessly (in our case, the captured quote characters are not used)
  4. Prefer [] over escaping (personal preference)
quote_character = %q|['"]|
optional_whitespace = "\s*"

METHOD_CAPTURE = /Module[.]method[(]#{optional_whitespace}#{quote_character}(?<string_contents>.+?)#{quote_character}#{optional_whitespace}[)]/

# #match returns an object or nil
matches = 'Module.method("some string")'.match(METHOD_CAPTURE)

# if an object, access captures by name:
matches[:string_contents] # "some string"

You can tailor how many named expressions/variables to use based on the complexity of the regexp.

Finding Where a Method is Defined

One great thing about Ruby is how flexible it is. Although sometimes it can be hard to determine where a method definition comes from.

One useful technique to pull out in just this circumstance is the source_location method.

For example, suppose you see a call to the quantity method in a spec and you wonder where its definition comes from. Do some puts debugging by adding this line:

puts method(:quantity).source_location

Lambda argument passing shorthand

Suppose that I have a Ruby lambda like so:

greeting = -> name { "Hello #{name}" }

The conventional way of calling this lambda is like so:"Ned") # "Hello Ned"

However, for those of you dreading having to type in call (hello, JavaScript developers), you can use this syntactic sugar instead:




I am now a sad panda to learn that this shorthand syntax is not recommended in the ruby-style-guide:

It's still a cool learning for me to know that this syntax exists in the first place, though.

FactoryGirl identifiers as symbols not strings

Why is FactoryGirl.create(:my_object) better than FactoryGirl.create("my_object")?

Symbols are immutable objects that are stored by the Ruby interpreter as a numeric ID (an implementation detail, the design of Ruby is flexible for different storage mechanisms).

Strings, on the other hand, take up a memory footprint as large as the number of characters in the string. Using symbols will thus take up less memory and potentially be faster because the same address in memory will be used.

If you have n instances of the same string in your code, Ruby will use O(n) memory to store all those strings, however, if you have n instances of the same symbol in your code, Ruby will use O(1) memory to do the same lookup.

Further reading:

This TIL came courtesy of a discussion with Evan and later on Arturo about best practices in writing test code, but shared here because it's broadly applicable and the FactoryGirl example is just one use case.

Squish Those Strings

While reading some Rails code, I came across a deprecation warning:

  `redirect_to :back` is deprecated and will be removed from Rails 5.1.
  Please use `redirect_back(fallback_location: fallback_location)` where
  `fallback_location` represents the location to use if the request has
  no HTTP referer information.

What caught my eye was the squish method on the heredoc. It's common to see methods after heredocs to clean up formatting, but squish is a great method name.

squish removes all leading and trailing whitespace, then replaces all consecutive whitespace with a single space. One application has been cleaning up long string messages that use the line continuation operator. The community style guide says to only use line continuations for concatenating strings, but I think squish is cleaner:

long_string = "a long string " \
              "spanning " \
              "three lines"
# => "a long string spanning three lines"

better_long_string = "a long string
                      squished to a single line
                      without extra spaces or backslashes".squish
# => "a long string squished to a single line without extra spaces or backslashes"

An all-too-common caveat: squish is an extenstion method from active_support.

bundle update --conservative

Let's say you want to update the gem foo. After running bundle update foo you look at your gemfile.lock and find that not only was foo updated, but so were many of its dependencies. You also notice that many of these dependency updates weren't necessary, as the previously installed versions were compatible with the new version of foo.

The default bundle update foo behaviour will unlock and update all dependencies of foo.

If you don't want to update these dependencies unnecessarily, one solution is to add the current versions to your gemfile.lock.

However, an easier way to prevent the updating of shared dependencies is to use bundler's new --conservative flag.

Replacing with


I want to create an array containing objects created with an incrementing integer index parameter. For example, an array of hashes containing strings built off of the incrementing number.

Standard Solution

my_array = do |index|

BUT...rubocop didn't like this:

... C: Performance/TimesMap: Use with a block instead of

Improved Solution

The improved solution allows us to build the same array with less chained methods, thus improving readability:

my_array = do |index|

Comparing Version Strings in Ruby

While writing a Ruby script, I needed to check the the version of a binary dependancy. The --version switch gets me the data, but how to compare to the required version?

The binary follows semver, so a quick and dirty attempt might be:

"1.4.2".gsub(".", "") >= "1.3.1".gsub(".", "")
# => true

Unfortunately, this is misleading: we are lexicographically comparing the strings and these strings happen to have the same length. Thus, "142" comes after "131".

Testing that version "1.200.0" is newer than "1.9.0" will fail as "120" comes before "190".

It would be straight-forward to write a small class to parse the string and compare the major, minor, and patch values. But, Ruby has a quick solution provided by RubyGems. Since Ruby 1.9, RubyGems has been included in Ruby's standard library:"1.200.1") >="1.3.1")
# => true

Gem also provides a way handle pessimistic constraints:

dependency ="", "~> 1.3.1")
dependency.match?("", "1.3.9")
# => true
dependency.match?("", "1.4.1")
# => false

Decorator Pattern in Ruby with SimpleDelegator

The Decorator Pattern allows us to chain new behaviours to objects without modifying the underlying objects. It is an application of the Open/Closed Principle. This pattern is useful for example when we need to tack on logging, monitoring, and other non-functional requirements to objects.

In Java or C# this can be achieved using interfaces. In Ruby, we can use the SimpleDelegator class to achieve this:

require "delegate"

class FooDecorator < SimpleDelegator
  def bar
    "This is a decorated #{}"

class Foo
  def bar

  def fiz

decorated =
puts # outputs "This is a decorated bar"
puts decorated.fiz # outputs "Fiz"

double_decorated =
puts # outputs "This is a decorated This is a decorated bar"


Bundle Console

bundle console [GROUP]

runs Ruby console with bundled gems

Passing all env. variables to a shell command

Some of the methods in the Kernel module allows you to pass environment variables to a shell command. So rather than doing:

system("RAILS_ENV=test rake do_stuff")

You can do

system({ "RAILS_ENV" => "test" }, "rake do_stuff")  

This is particularly useful when we want to pass all environment variables on our current process.

system(ENV, "rake do_stuff")

Prefer sort_by to sort when providing a block

Prefer the sort_by method over the sort method whenever you provide a block to define the comparison.

Common form:

line_adds.sort { |x, y| x.elements["ItemRef/ListID"].text <=> 
  y.elements["ItemRef/ListID"].text }

Preferred form:

line_adds.sort_by { |x| x.elements["ItemRef/ListID"].text }

For small collections both techniques have similar performance profiles. When the sort key is something simple like an integer there is no performance benefit from sort_by.

The performance difference is especially noticeable if the sort key is expensive to compute and/or you have a large collection to sort.

The algorithm that yields the performance benefit is known as the Schwartzian Transform.

Ruby print to replace contents on same line

In Ruby, the print command can be used with the '\r' (carriage return) character to bring the cursor back to the beginning of the printed line, so that the next print call will replace the contents already outputted to that line. This is a very useful tool for printing status updates in a CLI script. For example:

print "#{index} done. Progress: %.2f%" % (index.to_f / items * 100).round(2) + "\r" if (index % 10) == 0

This will print and replace a line in STDOUT to report the status of a list of items being processed by a function, like so:

200 done. Progress: 15%

Typewriters still hold a lasting impact on modern-day computing!

Reading Text File with Byte Order Mark Using Ruby

Ruby's can natively read a text file containing a byte order mark and strip it out:

text_without_bom ="file.txt", encoding: "bom|utf-8")

A quick deep dive into 'rake gettext:find'


I am using Ruby Gettext to manage translations. But today, when I ran rake gettext:find to update my PO files, none of them got updated.


The Investigation

After some digging, I noticed that Ruby Gettext defines one FileTask (a specific type of Rake task) per PO file, which delegates the work to GNU gettext.

FileTask looks at the timestamps of dependent files, and only executes the supplied block if any of the dependent files have a timestamp later than the file to update.

For example:

dependent_files = ["translations_template_file.pot"]
file "file_to_update" => dependent_files do
  # update the file

Why gettext:find was not doing anything

It turned out that gettext uses two FileTasks.

One to update the template:

files_needing_translations = ["file1.js", "file2.rb"]
file "translations_template_file.pot" => files_needing_translations do
  # update the translations template file

and another to update the PO file:

file "en-US/translation_file.po" => ["translations_template_file.pot"] do
  # update "en-US/translations.po"

The reason gettext:find did not do anything was because none of the files needing translation were updated, thus no PO files were updated.


> touch one_of_the_files_that_gettext_looks_at.js
> rake gettext:find

Matching array subset in Ruby


How do you evaluate whether one array is a subset of another? For example, are the elements [a,c] included in [a,b,c]?

First attempt:

I was hoping to find something like Array.include?([...]), but this only checks if the array includes the argument as one of its values.

Second attempt:

Another approach is to pass a block into Array.any?

!arr1.any? { |e| !arr2.include?(e) }

But the double negation is rather indirect and doesn't easily reveal the intent.

I considered extracting a method to name the functionality:

def subset?(arr1, arr2)
  !arr1.any? { |e| !arr2.include?(e) }

But it's still difficult to read, as it's not clear whether arr1 is a subset of arr2, or vice versa.

Final Solution:

The Enumerable module includes a to_set method to convert the array to set, and Set includes a subset? method.


Technically, you need to require set.rb to get this method defined on Enumberable:

require "set"


But you get this require for free in Rails.

A little thing about .to_str

Playing with Ruby's === today and found some knowledge that's share-worthy. I noticed in ruby docs for string === a reference to .to_str and decided to investigate.

Nothing too exciting here, but its an important point of reference.

> hello = "hello"
> goodbye = "goodbye"

> hello === hello     #=> true
> hello === goodbye   #=> false

This is also what would usually be expected. Hang in there...

> string = "string"
> object =
> string + object     #=> TypeError no implicit conversion

Here's where things get funky.

class SomeObjectWithToStr
  def to_str
    "is now a string"

> string = "string"
> object =

> string + object     #=> "string is now a string"
> "string is now a string" === "string" + object      #=> true

Hunh? Why did that work?

TIL that .to_str is the default method call when operators force a conversion to a string. You'll likely have to define it yourself. Also note that the object type on the left is what the object type on the right will try to convert into.

Do you know of any Objects that come with pre-defined .to_str methods?

What's a "twiddle-wakka"?

I'm proud to say that I now know what a twiddle-wakka is. It is the notation ~> that we use in our Ruby-flavoured semver notation in Gemfile. Specifically, it means that the accepted version must be at the same level of the specified version. All sub-levels below the next increment of the current level are accepted. For example, ~> 2.0 means 2.0 <= VERSION < 2.1, while ~> 2.0.1 means 2.0.1 <= VERSION < 2.0.2.


But seriously, now I know what a twiddle-wakka is. :D

Enhancing rake tasks


I have a rake task, and I want to make it do something before and after it's done.

task :a_task do
  puts "task"

task :setup_task do
  puts "setup"

task :run_after do
  puts "after"

What are my options?


For pre-req tasks, this is what is often done:

task :a_task => [:setup_task] do
  puts "task"

task :setup_task do
  puts "setup"
> rake a_task

However, this requires modifying the existing task. This might not even be an option for rake tasks from 3rd party gems. We can do better: Enhance the task!

task :a_task do
  puts "task"

task :setup_task do
  puts "setup"

Rake::Task[:a_task].enhance [:setup_task]
> rake a_task

To run a task (or any code for that matter) after a rake task:

task :a_task do
  puts "task"

task :run_after do
  puts "after"

Rake::Task["a_task"].enhance do
> rake a_task


Expect to Receive and Call to Original

In integration specs, it is preferable to call the original method when setting up an expectation on an object to receive an invocation of that method. This way, the method isn't stubbed out but instead will still be invoked. Any downstream effects of calling that method won't be hidden.

class Calculator
  def self.add(x, y)
    x + y

Should be tested like this:

require 'calculator'

RSpec.describe "and_call_original" do
  it "responds as it normally would" do
    expect(Calculator).to receive(:add).and_call_original
    expect(Calculator.add(2, 3)).to eq(5)  # any bugs inside of #add won't be hidden

This code example is taken from: Relish - Calling the original implementation

Show definition of a method at runtime in Ruby

Many people know about method(:foo).source_location to find where a method is defined at runtime. I just found a better way by using pry.

From the pry console, run:

[8] pry(main)> show-source Bar.scoped.where
From: /Users/arturo/.rvm/gems/ruby-2.2.6/gems/activerecord- @ line 132:
Owner: ActiveRecord::QueryMethods
Visibility: public
Number of lines: 7

def where(opts, *rest)
  return self if opts.blank?

  relation = clone
  relation.where_values += build_where(opts, rest)

Happy Hacking!

Inheritance does not affect method visibility

Contrary to visibility conventions in other languages such as Java, Ruby methods defined under a private block in a class definition are still accessible by that class' children:

class Foo

  def private_method!
    p "Hello world!"

class Bar < Foo
  def uses_private_method

b =
b.uses_private_method # => "Hello world!"

This is because the private keyword in Ruby has nothing to do with inheritance; declaring a method as private only adds the restriction that it may not be invoked with an explicit receiver, as illustrated below:

class Quux < Foo
  def explicit_receiver

  def implicit_receiver

q =
q.explicit_receiver # => NoMethodError: private method `private_method!' called for #<Quux:0x007fee689e0ff8>
q.implicit_receiver # => "Hello world!"

Fetch: two approaches for setting a default value

When using #fetch to assign a default value, the default can be passed either as an argument or as a block.

What are the implications for choosing one approach over the other?

# Option 1: block
setting = settings.fetch('key') { default_setting }

#Option 2: argument
setting = settings.fetch('key', default_setting)

When the default value is passed as a block, it is only evaluated when needed (lazy evaluation).

The argument approach could lead to serious performance issues if the default is an expensive operation.

Consider using the #public_send method

Prefer the #public_send method to the #send method.

result_date = date.public_send(operation, delta)

In the example above the first parameter to the #public_send method is either + or -.

Loading Data into ELK


I want to load data in to Elasticsearch


Modify this script.

require "elasticsearch"
require "typhoeus"
require "typhoeus/adapters/faraday"

client = "localhost:9200")

scope = BackgroundTask
  .where("created_at > '2015-01-01'")
  .where("created_at < '2016-01-01'")

count_so_far = 0

puts "Processing #{scope.count} records"

  .find_in_batches do |tasks|

  puts "#{count_so_far} of #{scope.count}"
  count_so_far += tasks.count

  task_array = do |task|
      create: {
        _index: "background_tasks",
        _type: "task",
        data: {
          task_type: task.type,
          created_at: task.created_at,
          waiting_time: task.queued_at - task.created_at,
          queued_time: task.run_at - task.queued_at,
          processing_time: task.completed_at - task.run_at

  client.bulk(body: task_array)

Problems with Reusing Ruby Standard Class Names

You might want to think twice before making a class that reuses the same name of a Ruby Standard Library class. If undetected, you will get strange hard-to-debug behaviour in your app. Let's explore further with this Ruby file:

module Utils
  module String
    def self.some_useful_method
      # ...

module Utils
  module Foo
    def self.do_stuff(string)
      raise "Argument '#{string}' is not a string" unless string.is_a?(String)
      # ...

Utils::Foo.do_stuff("Hello World")

Okay, so Hello World is a String. And a String is a String, no questions asked. Right? Well...not quite.

RuntimeError: Argument 'Hello World' is not a string

Since Utils::String gets loaded by Ruby, all references to the String constant from code inside the Utils module will resolve to Utils::String. This example may seem simple and obvious, but imagine if these two classes were in separate files, even separate libraries. How would it feel like if you keep getting "string".is_a? String => false in your debugging sessions?

MORAL OF THE STORY: It probably isn't a good idea to reuse class names from the Ruby Standard Library. Naming the first module to Utils::StringUtils is likely a better idea.

UUID Generation in Ruby Standard Lib

No need for fancy gems in order to generate RFC4122 Version 4 compliant UUID strings.

>> require 'securerandom'
=> true
>> SecureRandom.uuid
=> "af04813c-6d80-4277-b4e7-7193f7413876"

Curly braces vs. do/end: Operation Precedence

Choosing whether you use { ... } or do ... end around your blocks is more than just a stylistic choice in Ruby. It also affects the way that an operation will be executed because your choice also specifies the Operation Precedence to use. In a nutshell, a block curly braces has higher precedence than a block with do/end.

Consider this example from a great Stackoverflow post:

f param { do_something() }

will execute differently than

f param do do_something() end

The former will bind the block to param, while the latter will bind the block to f. The more you know...

Reverse-search in IRB.

You can reverse-search through previously entered statements in IRB by pressing Ctrl-R:

2.1.6 :001  def something_complicated(x,y); x + y; end
 = :something_complicated
2.1.6 :002  quit

~ 10s
(reverse-i-search)`compli': def something_complicated(x,y); x + y; end

Happy hacking!