RubyJudo

This isn’t a Ruby thing but many of us spend a lot of time in Terminal.app, and I suspect few of you have taken the time to both changing your LSCOLORS, the setting which affects what colors ls uses when in color mode.

Enable Colors in ls

In order for ls to use colors at all, you need to set up an alias to turn colors on. To do this, open (or create) .profile file in your home directory using your favorite text editor and add:

alias ls="ls -G"

Now open a new Terminal window and type ls. You will see colors, hurray!

Make Colors Linux-like

If you’re used to Linux-like colors, you will appreciate this setting. This is what I use and it works particularly well on dark Terminal backgrounds (I use the “Pro” theme). I also check off “Use bright colors for bold text” under Terminal > Preferences > Settings. Again, add this to your .profile:

export LSCOLORS="ExGxBxDxCxEgEdxbxgxcxd"

Customize Your Colors

If you’re interested in fully customizing your LSCOLORS variable, you’ll find more below the fold.

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:

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.

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!

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)

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…

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.

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==.

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.

This isn’t funny.

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

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.

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:

1
2
3
4

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

To this:

1
2
3
4
5
6

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:

1
2
3
4
5
6

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 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?

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.

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!