Category Archives: News

Episode #521 – January 13th, 2015

This episode covers Ruby methods you should be using, code metrics that matter, using ES6 on the Rails asset pipeline, tampering with network connections, automatically prefixing email subject lines and phone verification using SMS.

Listen to this episode on Ruby5

Useful Methods

Ben Lewis wrote an article about Five Ruby Methods you should be using. He covers Object#tap, Array#bsearch, Enumerable#flat_map, Array.new with a block, and the sort operator (a.k.a. spaceship).

Metrics That Matter

Chris Kottom published an article covering a few of the code metrics that he feels don’t necessarily matter, like 100% code coverage. He focuses on a few that do, including performance, complexity, and security.

sprockets-traceur

The sprockets-traceur gem by Adam Pohorecki allows us to use the new features from ECMAScript 6 in Rails apps today, before the next version of JavaScript is officially released. Since a lot of Rails apps tend to make heavy use of JavaScript, it’s good to be able to try out some of these features sooner than later.

Toxiproxy

The team at Shopify recently released a new library for tampering with network connections called Toxiproxy. It provides a TCP proxy system which can be used to simulate network and system conditions.

email_prefixer

The email_prefixer gem by Ryan Sonnek automatically adds a prefix to the subject line of all delivered emails in development and staging. Great use of ActionMailer::Interceptor, a feature added in Rails 3.1.

Phone verification using SMS via Twilio

Santosh Wadghule published a guide on how to perform phone number verification in your Ruby application using the Twilio API. Who needs CAPTCHA? I’m just gonna TEXTYA!

Episode #520 – January 9th, 2015

Rails Misconceptions, performance and minecraft

Listen to this episode on Ruby5

Sponsored by NewRelic
most popular posts for 2014

Why Do They Say Rails Doesn’t Scale?
Why Do They Say Rails Doesn’t Scale?Noah Gibbs posted 4 reasons
…

Read more at the source

Episode #519 – January 6th, 2015

The holidays brought us Ruby 2.2.0 and Rails 4.2.0, Finishing Moves, the end/beginning of RubySpec, a nifty way to bind data from JavaScript to Rails, tips on testing controllers, and the tragic news of James Golick’s death.

Listen to this episode on Ruby5

Ruby 2.2.0 Released

Ruby 2.2.0 was released on Christmas day, containing a bunch of new features and improvements. The new garbage collector is now able to collect Symbol type objects, reducing memory usage of Symbols. This new version has reduced pause time for garbage collection thanks to the Incremental Garbage Collector. Rails 5.0 will take full advantage of both of these features, when it eventually comes out sometime in the Fall of 2015, requiring Ruby 2.2 or greater.

Rails 4.2.0

Rails 4.2.0 was also released over the holidays. There’s AdequateRecord, the painstaking multi-year rewrite of ActiveRecord led by Aaron Patterson to improve the performance of ActiveRecord beyond what it was in Rails 2.3 days, which means a lot.There’s also ActiveJob, which was originally planned for Rails 4. It brings a centralized interface for queuing jobs for any queueing systems like Resque, Sidekiq or Delayed Job. There’s also Web Console which gives you the ability to run queries you would usually run in the rails console, but right inside the browser when an exception occurs, which is similar to the better_errors gem. And now, adding and removing foreign keys is properly supported in Rails migrations.

Finishing Moves

Every now and then you find yourself in a situation where Ruby doesn’t have that one method you need. For example, a nil_chain method, which allows you to write method chains without fear of tripping over a NoMethodError and NameError exception when something throws out a nil value. Sometimes you just want to call something if it exists, and not if it’s nil. The folks over at Forge Software wrapped up a bunch of these useful methods into a gem called “Finishing Moves”.

RubySpec

On new year’s eve Ruby Hero Brian Shirai wrote a blog post explaining why he is ending the RubySpec project. RubySpec is a set of specifications, or tests, on how Ruby is supposed to run that was taken out of the Rubinius project. The objective was to have a common set of tests, not written in C, that could be run against any Ruby implementation to see if it had all the right behavior for Ruby. The reason why RubySpec is no longer is quite contentious but it seems like collaboration on the project wasn’t optimal between Ruby implementation. There was already a fork from people working on the MRI implementation that tackles some of the issues with RubySpec itself. At the very least we can, we can all agree that knowing how Ruby should behave matters.

Broader discussion available at: https://gist.github.com/nateberkopec/11dbcf0ee7f2c08450ea

Databound

Domas Bitvinskas dropped us a line yesterday to let us know about Databound, a Ruby gem that provides JavaScript a simple API to the Ruby on Rails CRUD. Basically it provides you a simple way to write ActiveRecord like functions directly from your JavaScript. So you can do things like User.find(1) from your JavaScript methods, and Databound will take care of calling into your Rails app to find the user with an ID of 1. You don’t even need a controller for the models you want to be able to query for, if you don’t already have one. All you need to do is write a line in your routes file specifying the model you want to be able to query for, and the columns you’re permitted to set from your JavaScript calls. This could be really useful if you want to write more code on the front-end, and less on the back-end.

How to test controllers in Rails

Occasionally it’s nice to cover a beginner tutorial, and we’d like to mention Cezar Halmagean’s tutorial on testing controllers in Rails. Controllers can be pretty easy to test assuming you know how to stub out calls and set expectations properly. Otherwise they can mimic your integration tests, which is not very useful.

Remembering James Golick

Thanks for everything you did James.

Episode #518 – December 19, 2014

Eastward Ho, Git ours/theirs and where does your code go?

Listen to this episode on Ruby5

Read more at the source

Episode #517 – December 16, 2014

This week we have Streem, Rails 4.2.rc3, Papercrop, and RubyMotion 3.0.

Listen to this episode on Ruby5

Streem

Ruby’s creator is working on a new stream based language. It’s in its early days but is clearly influenced by Ruby.
It is a concurrent scripting language based on a programming model similar to shell, with influences from Ruby and other functional programming languages. Currently, it’s still in the design stages.

Rails 4.2.0 Release Candidate

The Rails team has just released the third Release Candidate of Rails 4.2 today. Major changes include – Active Jobs, Asychnonous mails, Adequate record, web console, and foreign key support. So far, there haven’t been any major regressions for this release, meaning that we are still on track for our target to release the final version of 4.2.0 before Christmas time.

Papercrop

Papercrop is a gem from rsantamaria. It’s an easy extension for Paperclip to crop your image uploads using jCrop. It’s quite simple to use – there are 2 form helpers (cropbox and crop_preview). Cropbox places an adjustable crop area over the image being cropped and crop_preview renders a small preview of your finished image. Just a note – make sure you allow for additional params when using strong parameters

RubyMotion 3.0

Last Friday, RubyMotion announced the official release of version 3.0. Since the release of the beta, they’ve been hard at work adding some updates. Most notably, they now support all versions of Android. There’s a bunch of new features too. A debugger interface and a spec framework have been added but it doesn’t stop there. 3.0 let’s you write Apple Watch apps with Watchkit, create iOS 8 integrations, iOS 64-bit support, and an overall application size reduction.

Episode #516 – December 9, 2014

This week we have a jRuby security release, a new Command API for ROM, Traveling Ruby, early validations, easy rewrites with Ruby and Science!, and a Rails Camp not too far from Hobbiton.

Read more at the source

Episode #515 – December 5th, 2014

RubyConf 2014 on Confreaks, browser geolocation with Spyme, referential integrity with foreign keys, forwarding messages with tell, and free SecCasts all in this episode of the Ruby5.

Read more at the source

Episode #514 – December 2, 2014

In this episode we yap about Rails 4.2 RC1, Opal, Deployment, Interpol, Sportdb, Service Objects, and Emails.

Read more at the source

Episode #513 – November 25th, 2014

This episode covers the future of Ruby 3.0, the flip flop operator, a gem to ferry your data away, speeding up your Capybara specs, and a new place to find Ruby meet up resources.

Read more at the source

Episode #512 – November 21st, 2014

RubyConf 2014 wrap-up, accelerating your Rails app, RubyGems.org gets redesigned, Heroku wants you to try HTTP Git, and new versions of Rails were released

Read more at the source

Dynamic Method Definitions

March 4, 2013

TL;DR: depending on your app, using define_method is faster on boot, consumes less memory, and probably doesn’t significantly impact performance.

Throughout the Rails code base, I typically see dynamic methods defined using class_eval. What I mean by “dynamic methods” is methods with names or bodies that are calculated at runtime, then defined.

For example, something like this:

class Foo
  class_eval <<EORUBY, __FILE__, __LINE__ + 1
    def wow_#{Time.now.to_i}
      # ...
    end
  EORUBY
end

I’m not sure why they are define this way versus using define_method. Why don’t we compare and contrast defining methods using class_eval and define_method?

The tests I’ll do here use MRI, Ruby 2.0.0.

Definition Performance

When defining a method, is it faster to use class_eval or define_method? Here is a trivial benchmark where we simulate defining 100,000 methods:

require 'benchmark'

GC.disable

N = 100000
Benchmark.bm(13) do |x|
  x.report("define_method") {
    class Foo
      N.times { |i| define_method("foo_#{i}") { } }
    end
  }

  x.report("class_eval") {
    class Bar
      N.times { |i|
        class_eval <<-eoruby, __FILE__, __LINE__ + 1
          def bar_#{i}
          end
        eoruby
      }
    end
  }
end

Results on my machine:

$ ruby test.rb
                    user     system      total        real
define_method   0.290000   0.030000   0.320000 (  0.318222)
class_eval      1.300000   0.120000   1.420000 (  1.518075)

The class_eval version seems to be much slower than the define_method version.

Why is definition performance different?

The reason performance is different is that on each call to class_eval, MRI creates a new parser and parses the string. In the define_method case, the parser is only run once.

We can see when the parser executes using DTrace. We will compare two programs, one with class_eval:

class Foo
  5.times do |i|
    class_eval "def f_#{i}; end", __FILE__, __LINE__
  end
end

and one with define_method:

class Foo
  5.times do |i|
    define_method("f_#{i}") { }
  end
end

Using DTrace, we can monitor the parse-begin probe which fires before MRI runs it’s parser and compiles instruction sequences:

ruby$target:::parse-begin
/copyinstr(arg0) == "test.rb"/
{
  printf("%s:%d\n", copyinstr(arg0), arg1);
}

Run DTrace using the define_method program:

$ sudo dtrace -q -s x.d -c"$(rbenv which ruby) test.rb"
test.rb:1

Now run again with the class_eval version:

$ sudo dtrace -q -s x.d -c"$(rbenv which ruby) test.rb"
test.rb:1
test.rb:3
test.rb:3
test.rb:3
test.rb:3
test.rb:3

In the class_eval version, the parser runs and compiles instruction sequences 6 times, where the define_method case only runs once.

Call speed

It seems it’s faster to define methods via define_method, but which method is faster to call? Let’s try with a trivial example:

require 'benchmark/ips'

GC.disable

class Foo
  define_method("foo") { }
  class_eval 'def bar; end'
end

Benchmark.ips do |x|
  foo = Foo.new
  x.report("class_eval") { foo.bar }
  x.report("define_method") { foo.foo }
end

Here are the results on my machine:

$ ruby test.rb
Calculating -------------------------------------
          class_eval    115154 i/100ms
       define_method    106872 i/100ms
-------------------------------------------------
          class_eval  7454955.2 (±5.0%) i/s -   37194742 in   5.004418s
       define_method  5061216.4 (±5.2%) i/s -   25221792 in   5.000041s

Clearly methods defined with class_eval are faster. But does it matter? Let’s try a test where we add a little work to each method:

require 'benchmark/ips'

GC.disable

class Foo
  define_method("foo") { 10.times.map { "foo".length } }
  class_eval 'def bar; 10.times.map { "foo".length }; end'
end

Benchmark.ips do |x|
  foo = Foo.new
  x.report("define_method") { foo.foo }
  x.report("class_eval") { foo.bar }
end

Running these on my machine, I get:

$ ruby test.rb
Calculating -------------------------------------
       define_method     23949 i/100ms
          class_eval     23015 i/100ms
-------------------------------------------------
       define_method   261039.7 (±6.3%) i/s -    1317195 in   5.066215s
          class_eval   228819.7 (±12.2%) i/s -    1150750 in   5.286635s

A small amount of work is enough to overcome the performance difference between them.

How about memory consumption?

Let’s compare class_eval and define_method on memory. We’ll use this program to compare maximum RSS for N methods:

N = (ENV['N'] || 100_000).to_i

class Foo
  N.times do |i|
    if ENV['EVAL']
      class_eval "def bar_#{i}; end"
    else
      define_method("bar_#{i}") { }
    end
  end
end

Here are the results (I’ve trimmed them a little for clarity):

$ EVAL=1 time -l ruby test.rb
        3.77 real         3.68 user         0.08 sys
 127389696  maximum resident set size
         0  average shared memory size
         0  average unshared data size
         0  average unshared stack size
     38716  page reclaims
$ DEFN=1 time -l ruby test.rb
        0.69 real         0.63 user         0.05 sys
  69103616  maximum resident set size
         0  average shared memory size
         0  average unshared data size
         0  average unshared stack size
     24487  page reclaims
$

The maximum RSS for the class_eval version is much higher than the define_method version. Why?

I mentioned earlier that the class_eval version instantiates a new parser and compiles the source. Each method definition in the class_eval version does not share instruction sequences, where the define_method version does.

Let’s verify this claim by using ObjectSpace.memsize_of_all!

Measuring Instructions

MRI will let us measure the total memory usage of the instruction sequences. Here we’ll modify the previous program to measure the instruction sequence size (in bytes) after defining many methods:

require 'objspace'

N = (ENV['N'] || 100_000).to_i

class Foo
  N.times do |i|
    if ENV['EVAL']
      class_eval "def bar_#{i}; end"
    else
      define_method("bar_#{i}") { }
    end
  end
end

GC.start

p ObjectSpace.memsize_of_all(RubyVM::InstructionSequence)

Let’s see the difference:

$ EVAL=1 ruby test.rb
44718112
$ DEFN=1 ruby test.rb
718112

Growth Rate

Now let’s see the growth rate between the two. Here is the growth rate for the class_eval case:

$ N=100 EVAL=1 ruby test.rb
762112
$ N=1000 EVAL=1 ruby test.rb
1158112
$ N=10000 EVAL=1 ruby test.rb
5118112
$ N=100000 EVAL=1 ruby test.rb
44718112

Now let’s compare to the define_method case:

$ N=100 DEFN=1 ruby test.rb
718112
$ N=1000 DEFN=1 ruby test.rb
718112
$ N=10000 DEFN=1 ruby test.rb
718112
$ N=100000 DEFN=1 ruby test.rb
718112

The memory consumed by instruction sequences in the class_eval case continually grows, where in the define_method case it does not. MRI reuses the instruction sequences in the case of define_method, so we see no growth.

Caution

Defining methods with define_method is faster, consumes less memory, and depending on your application isn’t significantly slower than using a class_eval defined method. So what is the down side?

Closures

The main down side is that define_method creates a closure. The closure could hold references to large objects, and those large objects will never be garbage collected. For example:

class Foo
  x = "X" * 1024000 # Not GC'd
  define_method("foo") { }
end

class Bar
  x = "X" * 1024000 # Is GC'd
  class_eval("def foo; end")
end

The closure could access the local variable x in the Foo class, so that variable cannot be garbage collected.

When using define_method be careful not to hold references to objects you don’t care about.

THE END

I hope you enjoyed this! <3<3<3<3

[…]

The Ruby Rails Aggregator

Category Archives: News

Episode #521 – January 13th, 2015

Sponsored by Top Ruby Jobs

Useful Methods

Metrics That Matter

sprockets-traceur

Toxiproxy

email_prefixer

Phone verification using SMS via Twilio

Sponsored by Ruby5

Episode #520 – January 9th, 2015

Episode #519 – January 6th, 2015

Sponsored by Top Ruby Jobs

Ruby 2.2.0 Released

Rails 4.2.0

Finishing Moves

RubySpec

Databound

How to test controllers in Rails

Remembering James Golick

Sponsored by Ruby5

Episode #518 – December 19, 2014

Episode #517 – December 16, 2014

Sponsored by Top ruby Jobs

Streem

Rails 4.2.0 Release Candidate

Papercrop

RubyMotion 3.0

Sponsored by Gift of Code

Episode #516 – December 9, 2014

Episode #515 – December 5th, 2014

Episode #514 – December 2, 2014

Episode #513 – November 25th, 2014

Episode #512 – November 21st, 2014