RubyJudo - Home

Interview on the Ruby on Rails podcast.

2008-05-03T02:03:00Z

The interview I did with the incredibly gracious and awesome Geoffrey Grosenbach (of Peepcasts) on the official Ruby on Rails podcast just went up.

I talk a little bit about consulting at Norbauer Inc, a bit about RubyRags, and I spend a bit of time kicking social networks in the nuts.

Incidentally, I’m proud to announce that we’re now selling Peepcode shirts at RubyRags:

Alternative Ruby Implementations

2008-04-28T20:13:00Z

Sorry to just link drop on ya’ll, but if you haven’t seen it, Charles Nutter of the JRuby team has published a writeup titled Promise and Perils for Alternative Ruby Impls. It provides an excellent analysis of 1.8, 1.9, JRuby, Rubinius, and the other Ruby interpreter projects out there, if only slightly biased for JRuby (understandably). If you have an interest in the future of Ruby, it is a recommended read.

Rails 2.0 development finally meets Web 2.0

2008-04-19T04:13:00Z

I know I am late to the show, but I’d just like to say it is about time that Rails move off of Trac – with the move to Lighthouse and Github, Rails development itself is now hosted on awesome Rails-based services. I know such migrations are not easy for such a large project so I just want to say thanks to the Rails team, and nice choices!

Strange analogy

2008-04-17T15:15:00Z

Creating software is like eating a grapefruit (Randall Munroe’s favorite fruit). Sure, you can rush through it and you’ll get some enjoyment out of the grapefruit bits, but if you take your time and patience, you will get much more out of it. Like all things, you reap what you sow.

(Photo via Wikimedia)

Yet another Ruby framework and HTTP adapter

2008-04-12T10:05:00Z

It’s an exciting time to be Ruby or Rails developer as there are so many new and exciting things going on – in fact, it’s a lot to keep tabs on. Let’s look at two issues: Ruby web frameworks and HTTP adapters.

So, web frameworks, some of these you’ve probably heard of:

Ruby on Rails – You’ve probably heard of this one.
Camping has been around for a while, and aims to be tiny and simple – great when you’re only building a few pages. Developed by the infamous why.
Merb was created by Ezra, which now has many of the core Rails features, but less of the frills. It’s fast and, best of all, its thread-safe.

But, oh, there are so many more:

Nitro – Been around a while now, but development stalled for a year or two.
Ruby Waves, which claims to be highly flexible.
Wuby, a tiny server+framework, which serves RHTML files, in a manner similar to PHP.
Sinatra, a REST-centric framework which uses a DSL to make life simpler.
Ramaze, which is also very flexible, supporting a variety of ORMs, template engines, HTTP adapters, etc.
Mack is brand new, claiming to be highly modular and agile, as well as speedy. Their site is down but their documentation is up.
Maveric
Vintage
Cerise – Not recently maintained (2006).
IOWA – Not recently maintained (2004).

I’m sure I still missed some. Moving on the HTTP adapters – these are the likes of WEBrick and Mongrel. It’s good to keep up on these as they can often mean a boost in performance for your app, often regardless of your framework, thanks to the common interface provided by the Rack library.

Ebb is the newest to the show, touting fantastic performance as most of it is written in C. It can be a little tough to set up. It has support for Rails; for other frameworks, you’ll have to roll your own interface.
Thin is quickly becoming the defacto standard (at least until ebb is further along)
Swiftiply and Evented Mongrel was the first to improve Mongrel’s performance.
Mongrel started it all.
Fuzed allows your Rails app to run with Yaws.
Passenger is “mod_rails” for Apache, which could be a big news. They are also working on Ruby Enterprise Edition, which will be launched soon.

And you have already learned and adopted git, right? Can’t fall behind the times…

git: revert (reset) a single file

2008-04-08T07:33:00Z

This one is hard to find out there so here it is. If you have an uncommitted change (its only in your working copy) that you wish to revert (in SVN terms) to the copy in your latest commit, do the following:

git checkout filename

This will checkout the file from HEAD, overwriting your change. This command is also used to checkout branches, and you could happen to have a file with the same name as a branch. All is not lost, you will simply need to type:

git checkout -- filename

You can also do this with files from other branches, and such. man git-checkout has the details.

The rest of the Internet will tell you to use git reset --hard, but this resets all uncommitted changes you’ve made in your working copy. Type this with care.

Generating access keys

2008-04-06T09:09:00Z

This is a somewhat obscure but very efficient way to generate access keys. Look ma, no loops!

Array.new(16) { rand(256) }.pack('C*').unpack('H*').first

This will generate a 32-length key, like b3512f4972d314da94380e1a70e6814a.

This may look strange unless you’ve used Array.new, Array#pack, and String#unpack many times in the past. In the gaming world, I tended to deal with binary data on a regular basis, so pack and unpack became commonly-used weapons in my repertoire. They allow you to operate on binary data – pack creates binary data (stored in a regular string) from an array of Ruby objects, and unpack takes binary data and creates Ruby objects in an array. If you think about it, you are dealing with binary data here: you’re creating a random 128-bit (16-byte) key which you want in hex-format, so using pack and unpack do make sense. The parameters (C* and H*, in this case), are formats which indicate how to process the data.

Very cool cats may want to create more-compact Base64 keys. Be aware that Base64 is case sensitive:

[ Array.new(16) { rand(256) }.pack('C*') ].pack('m').chop

This generates keys like Gv5CJ68ptOZKVRvAFdzGpg==.

New RubyRags shirt

2008-04-03T14:24:00Z

I’m excited to announce a new fantastical RubyRags design: The Ruby City.

It’ll be in stock and shipping in mid- to late April.

You can join the waiting list or read more at the RubyRags site.

Ruby Meets Star Trek

2008-04-01T06:21:00Z

This isn’t funny.

But somehow I’m happy to know such a thing exists.

CabooseConf!

2008-02-01T22:50:00Z

One of my favorite Rails bloggers has just announced what is the only good news I’ve heard thus far about RailsConf 2008. I’ll let Courtenay put it in his own words:

In May, if you don’t want to cough up almost a thousand dollars to go learn things you already know, but want to come to Portland to network with skilled Rails coders from all over the world, instead of hanging out in the lobby at the Lloyd Center like I did last year, come to Caboose Conf.

I completely agree: the conference last year was way overpriced and the content utterly unenlightening. I actually enjoyed RailsConf 1, but I found the O’Reilly version much less fun. It turned into an enterprisey schmooze-fest, with all us small-time folks wandering around looking to make individual connections in the vestibule. I’m not opposed to a bit of business, but I certainly am when it comes at the expense of authenticity, aesthetics, and social experience—which it certainly did last year.

My Rails consultancy was already scheming a RubyRags gathering at the super-swank Jupiter Hotel, which we were planning to bill as a sort of unRailsconf Railsconf party. (Sign up on our announcement list to get an invite and details in the next few weeks.) I’m guessing the folks interested in Cabooseconf are going to be fairly like-minded to the RubyRags crowd, so hopefully we’ll find some way to dovetail our events.

I’ll keep you posted.

ActiveRecord performance vs self-executing statements

2008-01-23T14:18:00Z

One of the battles of Rails development is dealing with performance problems. If you have a database-intensive operation, using ActiveRecord can be an incredible slowdown to your system. You will know this because the CPU usage of your Rails app during the operation will be pegged at 100% (this means your server is busy running Ruby code), while your MySQL daemon will be coasting along at 5% or less.

What I have found is that, for an INSERT query, directly executing the query using ActiveRecord::Base.connection.execute (alternately, use the model name of the table you’re using, e.g., Post.connection.execute) will yield roughly a 10 times speedup in performance versus using create!. Consider the following steps that Rails will execute to run create!:

Initialize and build a new ActiveRecord model from the data you passed to create!
Validate the model using any validations you have placed on it
Before and after each step, check to see if there are any callbacks, and if so, execute them
Build the query using several levels of abstraction, passing through many functions, etc.
Hundreds of calls to #read_attribute to read the data out of the ActiveRecord model.

Compare this to what Ruby has to do if you create the query yourself:

One call to sprintf.
One call to ActiveRecord::Base.connection.execute, which then invokes the Mysql adapter.

Be wary, of course, that you get none of the benefits of ActiveRecord: no validations, no callbacks, no quoting, etc. I do not recommend doing this if the data is coming from the end-user unless it is carefully validated and escaped first. Note also that you will not get the resulting ActiveRecord objects.

To summarize, if you need to create 100 objects, change this:

1234	for d in data Something.create!(d)end

To this:


for d in data
  Something.connection.execute(sprintf(
    "INSERT INTO somethings (a, b, c, d) VALUES (%d, %d, %d, %d)", 
    d[:a], d[:b], d[:c], d[:d]))
end

Taking It Further: Multi-inserts

Pundits may realize that there is even a better way to do this: MySQL supports inserting multiple records at once, known as a multi-insert or extended insert. This can yield a 2x to 5x increase above executing the queries singly, depending on the speed of your database. Using the previous code as a base, you could change it to a multi-insert by doing the following:


values = data.collect do |d|
  sprintf("(%d, %d, %d, %d)", d[:a], d[:b], d[:c], d[:d])
end
Something.connection.execute(
  "INSERT INTO somethings (a, b, c, d) VALUES " + values.join(", "))

lighttpd 1.5.0 = vaporware?

2008-01-13T06:07:00Z

lighttpd has seen constant development and is currently at 1.4.18, so the project seems to be healthy.

lighttpd 1.4.0 was released in August 2005: about 2.5 years ago and according to lighttpd’s trac, 1.5.0 is still only 29% complete (who knows how accurate this is).

Is anyone still holding their breath for 1.5.0 and mod_proxy_core? Is anyone out there actually counting on deploying their Rails apps on lighttpd at any point?

Ruby 1.9 and Rails 2.0

2007-12-09T23:16:00Z

On the Ruby 2.0 announcement thread, Marcel filled us in on Ruby 1.9 compatibility work in Rails 2.0:

A lot of exploratory work and updates have already been made for 1.9 compatibility, mostly by Jeremy Kemper. So Rails 2.0 isn’t that far off from being 1.9 ready.

Hopefully this means that we will see a Ruby 1.9 compatible version of Rails a few weeks after its release.

script/console gives the best error messages

2007-12-04T00:31:00Z

I sometimes get bizarre startup error messages from script/server. The answer? Always check script/console if you’re getting something odd.

Here I am trying to use script/server:

rails-1.2.3/lib/commands/servers/mongrel.rb:18:
  undefined method `options' for []:Array (NoMethodError)

Huh? Let’s try script/server webrick:

vendor/plugins/loaded_plugins/lib/loaded_plugins.rb:21:
  in `<<': can't modify frozen array (TypeError)

Still no good… let’s try script/console:

ruby/vendor_ruby/1.8/rubygems.rb:251:
  in `report_activate_error': 
  Could not find RubyGem gettext (>= 0.0.0) (Gem::LoadError)

Oh, just install the gettext gem!

Ruby 1.9 for Christmas (we hope)

2007-11-30T06:38:00Z

This could possibly be one of the best Christmas’s ever, as Ruby 1.9 is slated to be released in the near future with a host of new features and performance improvements.

The performance improvements are extremely impressive and will be a huge boost to Rails applications – I am really looking forward to them. Not only will your Rails apps load faster, but they’ll take up less CPU resources on your system, which means less servers for large applications, meaning big cost savings and less headaches. For smaller apps, your server will be able to do more before you need to add a second, or can host more apps.

It won’t be an easy migration though: Ruby 1.9’s features include many things that will break the Rails framework and Rails apps. Here are just a few that caught my eye:

#send will no longer ignores visibility (i.e. private methods), you must use #send!. (Of course, you could re-define #send to call #send!.)
Class variables are no longer inherited.
Hash#to_s returns something more intelligible, but breaks anyone relying on the current behavior of mashing all the key-value pairs together.
Hash#each now passes a two-element array.
?c no longer returns the ASCII value for c, but instead the single-byte string "c" (you must use String#ord to get the ASCII value). Behavior for String#[] and String#[]= changed similarly, so "foo"[1] == ?o will still return true.
String is no longer an Enumerable, so String#each has been removed (use String#each_char instead).

But, there are many, many benefits. A lot of the improvements Rails made to Ruby through its “core extensions” library have landed in Ruby 1.9 (my favorite: the Symbol#to_proc implementation is in). Rails 1.9 has real character encoding support, more meta-programming methods, and plenty of other cool wizardry. Check out those new features for yourself.