The book covers all of the standard programming language basics: strings, classes, arrays, loops, etc. Additionally there are three chapters on more advanced subjects in Ruby: Marshal, Threads, and Dynamic Programming. Ruby on Rails is also quickly introduced in a chapter at the end of the book.

Each chapter includes a Digging Deeper section at the end that goes into more detail, warns about corner cases, or introduces an advanced usage. As someone who already knows Ruby these were the most interesting to read. They are placed inside of their own section to let someone who is just trying to learn Ruby know that they can safely be skipped.

No Starch Press is the publisher behind several fun programming books like Land of Lisp, Learn You a Haskell for Great Good, and the iconic Manga guides. When I picked up The Book of Ruby I wasn’t expecting to encounter the second coming of Why’s (Poignant) Guide to Ruby, but that’s what I was hoping for. Unfortunately, The Book of Ruby does not share any characteristics with that fun intro to programming Ruby and instead reads like an average technical book… dryly. On the positive side, I did find the author’s writing to be clear and easy to follow.

The book contains many examples but they are as contrived as possible. I understand that examples should be as simple as possible so that the reader can easily follow along but there is also a need to make the examples do interesting things to make the book more engaging.

Further, Collingbourne does not make an attempt to explain how Ruby is actually used “in the wild”. This is something that another Ruby author, Russ Olsen, does really well. Ruby has a lot of features so it is important to understand how Ruby programmers actually use Ruby. For instance, even though class variables are available, Ruby programmers try to never use them. This is something I would have liked to know when learning Ruby. However, instead of sharing these tidbits of information from his many years of Ruby experience, Collingbourne stays neutral and presents all of the information without including his opinions.

The one opinion that Collingbourne did share, is that he does not believe code style conventions are very important. This is something I can respect, and actually envy. In my own programming, I consider the time I spend to reformat my code to make it “look pretty” to be a waste. However, I still do it because it drives me crazy not to. If I could flip a switch inside my brain that would cause me to not care about code style anymore I absolutely would.

Overall, I feel like if this had been the first Ruby book I had picked up I would not have fallen in love with Ruby like I did. I am disappointed with No Starch Press for not upholding their unique style. The Book of Ruby does not differentiate itself enough to recommend over the other Ruby titles that are out there.

// place Hello World! on the 'write' buffer
set write, "Hello World!"

Internally, the interpreter is just passing the second parameter, “Hello World!”, to the puts method in Ruby. This makes it difficult to use traditional test/unit assertions to check that the simplesem instruction is working.

I eventually found two solutions for this. The first, suggested by David Stevenson at Pivotal Labs, is to use mocha to check that puts was called on the object.

require 'test/unit'
require 'rubygems'
require 'mocha'
 
class SimpleSemParserTest < Test::Unit::TestCase
 
  def test_set_stmt_write
    parser = SimpleSemParser.new
    parser.expects(:puts).with("Hello World!")
    parser.parse('set write, "Hello World!"').execute
  end
 
end

This solution is fine for most situations; Mocha will throw an exception if puts is not called. However in my case, it was unsuitable because puts was not being called on the SimpleSemParser object but instead on a Treetop syntax node that I did not easily have access to within the unit test.

I knew that if I could capture the output from the puts method into a variable I would be able write the test using a standard assert_equal. After some googling I discovered that this functionality is built into the ZenTest gem. After rewriting the test looked like this.

require 'test/zentest_assertions'
 
class SimpleSemParserTest < Test::Unit::TestCase
 
  def test_set_stmt_write
    out, err = util_capture do 
      parser = SimpleSemParser.new
      parser.parse('set write, "Hello World!"').execute
    end
 
    assert_equal "Hello World!\n", out.string
  end
 
end

This works great. However, should we decided that we do not want to use an external gem, with a little effort we can bypass ZenTest and implement util_capture ourselves.

require 'stringio'
 
module Kernel
 
  def capture_stdout
    out = StringIO.new
    $stdout = out
    yield
    return out
  ensure
    $stdout = STDOUT
  end
 
end

Done! We extended the Kernel module with a method called capture_stdout¹. capture_stdout works by redirecting $stdout to an instance of StringIO. StringIO has all of the IO methods, but acts on a string instead of a file. After changing $stdout we yield to let the caller generate output. Once the yield is finished, we return the StringIO instance and add an ensure to guarantee that $stdout is reset to its default value. Adding capture_stdout to the Kernel module has the effect of giving capture_stdout a global scope so that it can be used anywhere.

With the exception that we that we renamed the method to capture_stdout, and are not returning $stderr, the unit test has not changed from the ZenTest version.

class SimpleSemParserTest < Test::Unit::TestCase
 
  def test_set_stmt_write
    out = capture_stdout do 
      parser = SimpleSemParser.new
      parser.parse('set write, "Hello World!"').execute
    end
 
    assert_equal "Hello World!\n", out.string
  end
 
end

We end with a clean, very readable way to test Ruby methods that generate output without using any libraries.

Since SIMPLESEM is a made up language that was created just for our textbook, there was no way for me to execute the SIMPLESEM programs that I was writing for the homework assignments. This was annoying because SIMPLESEM is a low level language which makes it hard to notice mistakes. Of course, it is very easy to make a mistake any time you are programming but it is even harder to catch those mistakes if you are working at close to assembly level.

As a fun exercise I implemented an interpreter for SIMPLESEM using Ruby and published it as a RubyGem. Fortunately, I choose to use Nathan Sobo’s Treetop gem to aide in the development. Using Treetop, I wrote a parsing expression grammar to parse SIMPLESEM commands. This resulted in my SIMPLESEM interpreter being a lot more flexible than I had originally anticipated. After I familiarized myself with the basics of writing Treetop grammars I found it very easy to make changes to my grammar definitions to add language features one by one.

Installing the SIMPLESEM interpreter should be easy if you are on Linux or OS X, and possible if you are on Windows. The program is packaged as a rubygem. *nix folks should have rubygems packaged with their system. Windows users should visit the RubyGems page to get running. Once you are setup with RubyGems, install the simplesem gem from Gemcutter:

$ sudo gem install simplesem --source http://gemcutter.org

The gem installs a command called simplesem. To test it out download this sample SIMPLESEM program that prints “hello world!” five times. Run it by passing the name of the file as an argument to the command.

$ simplesem hello-world.txt
hello world!
hello world!
hello world!
hello world!
hello world!

You can view other sample SIMPLESEM programs here. To learn more about SIMPLESEM or the interpreter check out the README.

About four years after the education system made the switch to Java from C++, the whole software industry started complaining about the degrading quality of the Computer Science graduates in the US; which is a topic I explored recently. Ultimately, schools have made the switch away from C++, and they are unlikely to go back, nor do I think they should. Instead, what I want to discuss is why did we have to replace C++ with Java? I can see that at the time, it may have seemed the obvious choice, but looking around the language landscape now there are several choices that I think are better suited for the task. Namely, Python.

Java > Python How???

First, I want to really think about what advantage does learning programming with Java have over using a modern scripting language like Python? Python equally hides the things that make programming in C++ laborious and has many of the nice features that the JVM provides like garbage collection, unicode strings, and threads. The difference is Java is miserable for web programming (Java EE) and equally overly complex for building GUIs (Swing). As a scripting language, Python is far easier to pick and learn.

What CS students would lose from switching from Java to Python

• Static Typing – The difference between an Integer and a Float is harder to understand when you do not have to declare variable types.
• Compilation – In my opinion this is not a big deal. They are still going to learn how to debug runtime errors which is where the substance is. Advanced IDEs like Eclipse are making dealing with compiler errors almost a thing of the past in Java. Additionally, the upper division compilers class will still be there to teach them the ins and outs of compilers.
• Performance – This is a moot point. I only put it down because it is what most people think of first but very rarely do the projects assigned in a classroom require serious computation. I would also wager that even the ones that do can be solved in a satisfactory manor with Python. If anything it will force students to be more creative about their solutions instead of just relying on brute force.

What CS students will gain from switching from Java to Python

• Dynamic Typing – There are tradeoffs to both approaches but as nearly everyone who programs dynamically typed language for a while finds out that the type safety provided by static typing is unnecessary and more often gets in your way than it helps you (ex. Casting).
• Interpretation – Becoming familiar with interpretation is just as important as compilation. Interpretation opens several doors for you when programming and is becoming more common. In addition it gives you helpful tools like an interactive console.

Overall, there is no big loss in Computer Science concepts when moving from Java to Python like there was when we moved away from C++. You trade static typing for dynamic typing and compilation for interpretation but everything else is just about the same and you gain Python’s simplicity.

One of the real problems with Java is that many students do not like to use it when programming for fun. Since the majority of students only become competent in Java, they only code they write is for their homework assignments. These are type A CS students. There is a second, type B, group of CS students. Type B students pick up another language like PHP, Python, Ruby, Clojure, etc. and are ones who spend time coding and creating cool things outside of their schoolwork. These students find programming on the side to be the most enriching and also the most educational. Employers often cite type B students, the self starters, as the ones they are most interested in hiring. If the only programming a student does while attending school is for their class projects, it is more than likely that they will continue this practice once leaving school, only writing code for their job. By making the switch away from Java in education, more type B CS students would emerge from American universities; enormously benefiting the software industry.

Fast forward to the present. Last week, I borrowed Joel’s new book “More Joel on Software” from Michael Arrington which contains the “Perils of JavaSchools” essay. Reading the essay again I was blown away. What a difference a few years of CS education makes! This time instead of just feeling that Joel is right, I know he is right. Learning Computer Science completely in Java instead of C with a healthy dose of functional languages like Scheme is two different worlds.¹

All CS degrees are not created equal

Is the value of my CS education less than that of the traditional CS education Joel reminisced about? All other things being equal, I would say absolutely say “Yes”. I can not help but agree with Joel when he says that an all Java education can never be of the same caliber as the CS programs that preceded the Java “revolution”. People like Guido van Rossum, Paul Graham, Steve Yegge, Linus Torvalds and many other great hackers all received their degrees before the notion of a Java school existed. And as Joel puts it, they all went “stark, raving mad trying to pack things into bits”. The bit level is considered foreign territory for students at Java schools; a place we dare to venture only once or twice and will quickly return to the safety of the Java virtual machine.

Joel’s essay is best summarized by this paragraph:

You used to start out in college with a course in data structures, with linked lists and hash tables and whatnot, with extensive use of pointers. These courses were often used as weedout courses: they were so hard that anyone that couldn’t handle the mental challenge of a CS degree would give up, which was a good thing, because if you thought pointers are hard, wait until you try and prove things about fixed point theory.

I have never even heard of fixed point theory!

Finally we come to my dilemma. I have one year left at my Java school and I desperately want to avoid mediocrity. Since adopting Ruby as my primary programming language last summer, I have experienced several small victories. Ruby is a very powerful language which is gradually breaking me away from the ridged programming practices I picked up from programming in Java for 3 years. Ruby has introduced me to things like metaprogramming, reflection, DSL’s, anonymous methods, and several aspects of functional programming. All are things that I never would have been able to fathom had I stayed inside my Java bubble. I will say that CS students at Irvine take a Programming Languages class which introduces unfamiliar languages like Haskell. Unfortunately, the class doesn’t make up much ground. Like all classes it is only 10 weeks long and students only get a brief look at the various languages they are introduced to. To top it off most of the projects are still done with Java.

Ruby is not the Answer to Life, the Universe, and Everything

Ruby is great but its not going to teach me any of the low level knowledge I am lacking. I can program in Ruby for another decade and still not achieve a full understanding pointers. The only thing I can do to understand why while (*s++ = *t++); copies a string, is to actually program in C.

Why I am not learning C now

Learning C is something that you generally need to be forced into. In today’s world you are not going to able to write very much software if you are coding the entire thing in C from top to bottom. It is a very anti “Get Things Done” programming language. In addition, there are very few things that actually need to be written in C. Operating systems and compilers are the two big areas where use of C is nearly always required. Both are territory that I am not interested in venturing into at this point. The most common use for C among software developers is to optimize slow chunks of code by rewriting them in C. However, everything I write does not need to “scale” so while I always do my best to not write inefficient code, I can not be bothered to rewrite any of it in C when it is “fast enough” already.

What I am going to do about it

This is a problem that I have not thought of a solution for. I can not bring myself to sacrifice productivity in order to use C. At first I thought I would learn Objective-C which is based on C in order to create Cocoa applications for Mac OS X. That solution is flawed however. Just like Joel says learning C++ is not a substitute for learning C, the same is true for Objective-C. My best chance is if something in my school work for next year comes up that requires the use of C. If it does happen it will be an elective; the chance of a required course using C at Irvine is very slim. I am just one person, what I am experiencing is true for Computer Science students across the county at Java schools. We are collectively being handed a disadvantageous education and in the long run it will have a direct impact on the level of software engineering that is being done in the United States. For instance, I would guess that a graduate from a Java school is far less likely to ever contribute to the Linux kernel, GCC, or a similar project. This is of great consequence because we need innovation at the lowest level of software in order to continue innovating at the top.

Obviously, if American Universities are going to keep up, they need to switch back to the “middle ages” of Computer Science and resume using C in the classroom. For those of us that are already in the system, or recently graduated, individual crusades are required to attain the level of understanding that is obligatory for Computer Science graduates. For myself, this will likely include working through the exercises in Structure and Interpretation of Computer Programs and the accompanying lectures. I am still looking for a good, practical way to learn C. Just reading Kernighan and Ritchie is not going to be sufficient. There is a big distinction between learning to program and learning a language. I need to learn to program—for real this time.

Rails-doc.org is an fairly ambitious project to create a community driven Rails documentation site. Basically they let users sign up and contribute notes to the existing Rails documentation. This certainly has the potential to be very useful, especially for new Rails hackers because sometimes the people who have been around the framework for a while just take things for granted.

Take the documentation for strftime in the Date class for example. There is no documentation listed for that method. Despite the fact that you clearly need documentation of the strftime options in order to use that method. Instead you have to know to look under strftime in the Time class for the documentation. While this is an example specific to Ruby documentation, these are the kinds of obvious problems that a community documentation website can help solve.

Right now Rails-doc.org has only been live for a month the so amount of community documentation feels very low. In the mean time I’ll be using the site for the official documentation that is already in place. Plus its the best looking rendering of the Rails documentation site out there. The Nodeta guys did a good job with the design. They also have a nice looking blog.

It will be interested to see how many of the notes contributed to Rails-doc get ported to the official Rails documentation. This certainly feels like the easiest and most straightforward way to contribute to Rails documentation and I can see it becoming a testing ground for future contributions to the official docs.

Comparing cards has changed

Before 0.3.0 two cards objects were regarded as equal if they had the same face value. Resulting in a 6 of Spades being equal to a 6 of Clubs. After some thinking I decided that I did not like that and changed it so cards must have the same face value and same suit to be considered equal. This should not affect anyone unless they are creating and comparing Card objects directly.

PokerHand#arranged_hand has been replaced by PokerHand#sort_using_rank

To sort a PokerHand there are a couple options. PokerHand#by_face will sort a PokerHand in order from least to highest. But what if you have a pair and want to sort the cards based on the hand’s poker rank. For that there is PokerHand#sort_using_rank which was previously available as PokerHand#arranged_hand but it wasn’t documented.

Handling of duplicate cards

Before 0.3.0 Ruby-Poker would not complain if you added four 8′s of Clubs to a PokerHand. I’ve added a configuration option so that you can tell Ruby-Poker to throw a tantrum if you try and add the same card to a PokerHand twice.

require 'ruby-poker'  
PokerHand.allow_duplicates = false  
PokerHand.new("8c") << "8c"   # this throws a RuntimeError

allow_duplicates is set to true by default so you will not notice anything different unless you choose to opt-in to the exceptions.

That’s everything

As always you can install ruby-poker with the gem command.

gem install ruby-poker

Or gem update ruby-poker if you already have it installed to upgrade from an old version.

For a long time now Dave Thomas Programming Ruby (aka. The Pickaxe) has been the standard in the Ruby community as the book to learn Ruby from. Unfortunately the Pickaxe is not the best programming book ever written. In fact, its bulk and slowness almost killed my inspiration to learn Ruby. I respect Dave Thomas a lot for what he does for the Ruby community but the Pickaxe and I just did not click.

Since I didn’t find the Pickaxe to be excellent reading material, I had been eagerly anticipating David Flanagan’s The Ruby Programming Language to come out and unseat The Pickaxe as the de facto book to recommend to newcomers to Ruby.

I am happy to say that The Ruby Programming Language did not disappoint. I picked up this book solely expecting to just review it since I already comfortable programming in Ruby. However, once I started reading the book I found myself frequently learning things about Ruby that I didn’t know before. Not like little things either like, “oh that’s interesting”. I’m talking significant things like “holy crap that’s sweet”.

This book covers both Ruby 1.8 and Ruby 1.9. Initially this concerned me because as impressive as it is, it must have been quite a headache for the authors and was not sure how they were going to pull it off. It turns out to be pretty much a non-issue. The authors make a note of what is 1.8 or 1.9 only and it does not disturb the flow of the book since it doesn’t come up too frequently. I do hope though that after Ruby 1.9 stable is released they upgrade the book and tear out all the 1.8 specific material. Since I currently use 1.8 on a daily basis I don’t mind having 1.8 material in there but after everything has shifted to 1.9 it would be rather irksome.

The style of the book is fairly straightforward. It starts with an introduction to how Ruby programs work and then goes into an explanation of Ruby datatypes and objects. The later chapters cover advanced topics like reflection and metaprogramming. The authors opted not to go the tutorial route, which I think, was a good approach since the book is not designed to be an “intro to programming” text.

In the preface of the book, the authors state:

[The Ruby Programming Language] is loosely modeled after the classic The C Programming Language by Kernighan and Ritchie and aims to document the Ruby language comprehensively but without the formality of a language specification. It is written for experienced programmers who are new to Ruby, and for current Ruby programmers who want to take their understanding and mastery of the language to the next level.

O’Reilly is hoping that The Ruby Programming Language becomes the equivalent of K&R’s The C Programming Language for Ruby and I hope it succeeds. I think that every language needs their own K&R book for people to turn to as the definitive authority. That’s something that I feel like the Java programming language never had and it creates something of a hurdle when browsing for a Java book.

The third edition of the Pickaxe is in beta and will be coming out soon. I really hope it makes a strong showing when it hits the press because after the bang-up job Flanagan and Matz did with The Ruby Programming Language, there is no reason to look at the Pickaxe till then.

Initially I had thought that I would not need to change anything for 1.9 because ruby-poker-0.2.2 installed and ran through some quick examples without any trouble. However, I was saved by my test suite when it quickly exposed a problem where I was calling each on a String object. The each method was removed from String in 1.9 so I made a quick change to work around it and once again I’m seeing nothing but dots.

I am actually going to show two ways to do this. The first is the way that Evan Weaver, the creator of Ultrasphinx, recommends and the second way is the create a simple plugin that extends the Ultrasphinx plugin. The second way is my favorite because it provides the cleanest integration in my opinion but I’m going to demonstrate both methods so you can choose for yourself.

Method 1

To begin we need to make a class method that performs the eager loading in the model. Something like this:

## app/models/course.rb
class Course
  ...
 
  def self.find_with_includes(id)
    find(id, :include => [:professors])
  end
end

Notice how I’m using the familiar ActiveRecord include option to perform the eager loading like we would normally. The next and last step is to add the method to client_options[:finder_methods] in your environment.rb.

## config/environment.rb  
Ultrasphinx::Search.client_options[:finder_methods].unshift(:find_with_includes)

That’s it. Now to the second method.

Method 2

As I mentioned before, in this method we are going to create a simple plugin that will add functionality to Ultrasphinx. The code for this plugin was written by Henrik N.

Create a new folder in vendor/plugins/ called ultrasphinx_customizations. The name can be anything you like as long as it starts with “ultrasphinx”. This is so our customizations are loaded after the actual Ultrasphinx plugin. Inside the folder create init.rb and place this line in it.

## vendor/plugins/ultrasphinx_customizations/init.rb
Dir[File.dirname(__FILE__) + '/lib/*.rb'].each {|file| require file }

Now for the part of the plugin that actually does the work. Create a lib folder in ultrasphinx_customizations and create a new file in it called eager_loading.rb with the following contents.

## vendor/plugins/ultrasphinx_customizations/lib/eager_loading.rb
 
# Allows specifying eager loading options as e.g.
# Ultrasphinx::Search.client_options[:include]['MyKlass'] => [:user]
# or directly in is_indexed like
# is_indexed ..., :eagerly_load => [:user]
 
Ultrasphinx::Search.client_options.merge!(HashWithIndifferentAccess.new({
  :finder_methods => ['find_all_by_id_with_eager_loading'],
  :include => {}
}))
 
 
class ActiveRecord::Base
 
  def self.find_all_by_id_with_eager_loading(*ids)
    includes = Ultrasphinx::Search.client_options['include'][self.name]
    args = ids + [:include => includes]
    find_all_by_id(*args)
  end
 
  def self.is_indexed_with_include_option(options)
    Ultrasphinx::Search.client_options['include'][self.name] = options.delete(:eagerly_load)
    is_indexed_without_include_option(options)
  end
  class << self; alias_method_chain :is_indexed, :include_option; end
 
end

Sweet we’re done with the plugin. Now for the fun part. Remember in the model where we have our Ultrasphinx is_indexed :fields => [...] declaration? Thanks to our new customization we can add an :eagerly_loaded key and it will behave like an ActiveRecord find(:include => …). Here is what mine looks like.

## app/models/course.rb
 
is_indexed  :fields => ['course_number', 'title', 'term'],
            :eagerly_load => [:professors]

That’s all you have to do! I really enjoy the second method because it provides a seamless integration with the is_indexed call which seems to help me sleep at night.

Huge thanks to Henrik N for writing the ultrasphinx_customization code and Evan Weaver for writing Ultrasphinx.

Updated 04/17/2008: Fixed incorrect statement about plugin names.