Capturing Output from PUTS in Ruby
When writing unit tests for my simplesem interpreter, one test in particular was problematic. In simplesem, the set write instruction prints output to the screen.
// 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.
A SIMPLESEM Interpreter
In my Programming Languages course, taught by Shannon Tauro we have been using a fake assembly language of sorts called SIMPLESEM to gain experience translating the semantics of a high level programming language, to a simple processor.
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.
Rails-doc.org is my new Rails Reference
When working with a framework as large as Ruby on Rails its necessary to have a reference close by for… well just about everything. Until recently I was a big fan of gotAPI.com because I really appreciated the Ruby and Rails reference tied together. However, the Javascript autocomplete on their search box is broken in Firefox 3 so I decided to try the new Rails reference site, Rails-doc.org.
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.
Ruby-Poker 0.3.0
Ruby Poker has been updated! This release is largely a result of bug reports filed by Jim W. He took ruby poker to areas I had not previously thought to explore and he ran into a couple nasty bugs. They have all been fixed in Ruby-Poker 0.3.0. In addition the following changes were made that users should be aware of.
Book Review: The Ruby Programming Language
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.
