Seven Languages in Seven Weeks: Ruby, Day 3

This is my 3rd day of Ruby in the Seven Languages in Seven Weeks series of posts. You can find the previous day here.

Ruby, Day 3: Thoughts

The third day combines metaprogramming techniques (define_method, method_missing, and mixins) with what what we learned in the previous chapters (flexible syntax, blocks, yield) to work some magic. Whereas day 1 and 2 showed how Ruby could be more concise and expressive than other languages, this chapter shows some of the capabilities available in Ruby, such as beautiful DSLs and composable designs, that are nearly impossible in stricter languages.

I saw small of examples of this when I was working on the Resume Builder: the profile data I was fetching from the LinkedIn APIs came back as JSON. I wanted to have a nice Ruby class to wrap the JSON data and was able to do this cleanly and concisely using some very simple metaprogramming:

	class LinkedInProfile
	SIMPLE_PROFILE_FIELDS = %w[id summary headline honors interests specialties industry first_name last_name public_profile_url picture_url associations]
	SIMPLE_PROFILE_FIELDS.each do |field|
	define_method(field.to_sym) do
	@json[field]
	end
	end
	def initialize(json)
	@json = json
	end
	end

view raw LinkedInProfile.rb hosted with ❤ by GitHub

Instead of defining dozens of getters and setters as in the LinkedIn API Java Library, I just declared the fields in an array (SIMPLE_PROFILE_FIELDS), looped over them, and used define_method to create the appropriate methods. To be fair, this is kids stuff; if you really want to see metaprogramming shine, take a gander over at ActiveRecord.

Of course, with great power comes great big bullet wounds in the foot. Metaprogramming must be used with more a bit more caution than other programming techniques, as chasing down errors in dynamic methods and trying to discern "magic" can be painful.

Ruby, Day 3: Problems


CSV application

There was only one problem to solve on this day: modify the CSV application (see the original code here and the original output here) to return a CsvRow object. Use method_missing on that CsvRow to return the value for the column given a heading.

	module ActsAsCsv
	def self.included(base)
	base.extend ClassMethods
	end
	module ClassMethods
	def acts_as_csv
	include InstanceMethods
	include Enumerable
	end
	end
	module InstanceMethods
	attr_accessor :headers, :csv_contents
	def initialize
	read
	end
	def read
	@csv_contents = []
	filename = self.class.to_s.downcase + '.csv'
	file = File.new(filename)
	@headers = parse_row file.gets
	file.each do |row|
	@csv_contents << CsvRow.new(@headers, parse_row(row))
	end
	end
	def parse_row(row)
	row.chomp.split(', ')
	end
	def each
	@csv_contents.each { |row| yield row }
	end
	class CsvRow
	def initialize(headers, row)
	@headers = headers
	@row = row
	end
	def respond_to?(sym)
	@headers.index(name.to_s) || super(sym)
	end
	def method_missing name, *args, &block
	index = @headers.index(name.to_s)
	if index
	@row[index]
	else
	super
	end
	end
	end
	end
	end
	class RubyCsv
	include ActsAsCsv
	acts_as_csv
	end
	csv = RubyCsv.new
	puts csv.headers.inspect
	puts csv.csv_contents.inspect
	csv.each { |row| puts "#{row.name}, #{row.age}" }

view raw csv_new.rb hosted with ❤ by GitHub

Using this sample file:

	name	location	age
	Jim	Menlo Park	27
	Bob	Palo Alto	37
	Steve	NYC	28

view raw rubycsv.csv hosted with ❤ by GitHub

The code above will produce the following output:

	$ ruby csv_new.rb
	["name", "location", "age"]
	[#<ActsAsCsv::InstanceMethods::CsvRow:0x25814 @row=["Jim", "Menlo Park", "27"], @headers=["name", "location", "age"]>, #<ActsAsCsv::InstanceMethods::CsvRow:0x25738 @row=["Bob", "Palo Alto", "37"], @headers=["name", "location", "age"]>, #<ActsAsCsv::InstanceMethods::CsvRow:0x2565c @row=["Steve", "NYC", "28"], @headers=["name", "location", "age"]>]
	Jim, 27
	Bob, 37
	Steve, 28

view raw csv_new_output.txt hosted with ❤ by GitHub

Moving on

This was the final day in the Ruby chapter. Join me next time as I work my way through a totally new language: Io.

Sherlock, The Reichenbach Fall: What Really Happened?

The PBS/BBC Sherlock series is one of the most entertaining shows I've seen in years. It's a modern take on Conan Doyle's classic with strong writing, a superb cast, and plenty of mystery and deduction. If you're not watching it, you're really missing out.

Spoiler alert!

In fact, if you're not watching it, you should probably miss out on this blog post too. Seriously, stop reading.

What follows is an in-depth, full-of-spoilers discussion of what happens in the final episode of the show thus far, The Reichenbach Fall.

The final question

I'm sure you know exactly what I'm going to discuss: how did Sherlock fake his own death?

Using my amateur deductive reasoning and a healthy amount of rewind & pause, I have a pretty good guess at what happened. Let me walk you through the reasoning.

To start with, let's state the very obvious: either the body that fell off the roof was (a) Sherlock, or (b) it wasn't. I think we can fairly confidently eliminate option (b).

An impostor?

Could Sherlock have thrown Moriarty's body or the test dummy from earlier in the episode in his place? Not likely.

First, there was no way Sherlock could have bent over, hauled up a body or a dummy, brought it to the edge, and shoved it over, all without Watson noticing. There were some quick cuts and edits during the scenen, but we have no reason to believe that Watson looked away from Sherlock at any point during their conversation.

Other practicalities make this even more difficult: Moriarty was dressed noticeably differently than Sherlock (different coat, white shirt instead of dark, a tie instead of a scarf) and had shorter hair; seconds before Sherlock jumps, he looks back and Moriarty's body is lying there, still in the original outfit; the scene where Sherlock jumps is shot from behind and it's clear no one is just shoving a body/dummy off the roof.

Finally, the biggest evidence of all: the body falling through the air is clearly flailing its arms and legs. Neither a dummy nor a dead body would fall like that.

Verdict: it must have been Sherlock himself who jumped off the building.

How did he survive?

One key piece of evidence is that Sherlock is extremely specific in where he wants Watson to stand during their conversation. Here is the layout of the scene:

When Watson arrives, Sherlock is on the hospital roof, some 6-8 stories up, with a shorter, 2-3 story brick building between him and Watson. Watson tries to run around to the side of the brick building, but Sherlock yells at him to return to his previous spot. Sherlock is very vehement about this.

It's likely that Watson would be able to see Sherlock from either vantage point, which leaves only one other possibility for why Sherlock would care about where Watson stands:

(1) There was something between the brick building and the hospital that Sherlock didn't want Watson to see.

After Sherlock jumps, Watson again tries to run around the brick building and this time, is knocked down by someone on a bike. This is unlikely to be an accident and gives us our second hint:

(2) Sherlock needed to delay Watson until the something was no longer visible.

If you watch the scene closely, there is one item that fits both of these criteria: a truck filled with bags (garbage? recycling? laundry?) parked right next to the spot where Sherlock's body ends up. You get your first glimpse of this truck just as Watson is coming around the corner, just before he is knocked down:

You see the same truck drive away, out of the scene, a few seconds later as Watson finally gets to Holmes' body:

Think on that for a second: if a body comes crashing down a few feet from your truck, do you just casually drive away or jump out and see what the hell just happened? The fact that the truck drove away increases our confidence that it was part of the plot.

Verdict: the bags in the back of the truck served as padding to break Sherlocks' fall.

How did it go down?

Before meeting with Moriarty, Holmes seeks out Molly and tells her that he thinks he will die and that he needs her help. Holmes must've already realized that Moriarty's goal was to get him to commit suicide, so he enlisted Molly - who works at a morgue and could certainly fake autopsy reports and death certificates - to help him fake it. It's also worth remembering that it was Sherlock, not Moriarty, who arranged the meeting on, of all places, the rooftop of a hospital.

When Moriarty blew his brains out, Sherlock had no choice, and jumped. He landed in the truck, covered himself with some sort of blood (possibly provided by Molly), and dropped down onto the pavement to play dead. In fact, he did better than that. We saw Holmes with a bouncy ball much of the episode; it turns out there is a classic magic trick that involves squeezing a ball under your armpit to cut off circulation to your arm and make it seem like you have no heartbeat.

What about the bystanders?

Since all the bystanders could see the truck and Holmes fall into it, they must have been in on it. The crowd that gathers around Holmes' body and the biker that knocks over Watson were either part of Holmes' homeless network or government folks brought in by Mycroft.

Mycroft is an interesting possibility because his reaction to reading about Holmes' death is ambiguous: was he sad or relieved? Even more telling is the fact that Mycroft isn't with Watson and Mrs. Hudson at the cemetery to pay his respects to Holmes. My guess is that Mycroft knows Sherlock is alive, though it's possible that he merely deduced it after the fact.

No matter how improbable..

It'll be some time before the third season comes out and reveals the truth. In the meantime, feel free to join me in speculating by leaving your best theory in the comments.

Seven Languages in Seven Weeks: Ruby, Day 2

In my previous post, I went through the Day 1 Ruby problems from Seven Languages in Seven Weeks. Today, I'll share my solutions to the Day 2 problems and some more thoughts about Ruby.

Ruby, Day 2: Thoughts

I originally learned Ruby (and many other programming languages) the "hacker way": that is, I did a 10 minute syntax tutorial, browsed other peoples' code a bit, and then just started using the language, looking up missing pieces as I went. Although this is the most fun and productive way I've found to get started with a language, it can also lead to missing some of the finer points and subtleties.

For example, until the "Ruby, Day 2" chapter, I never had a full appreciation for Ruby code blocks and the yield keyword. For example, even though I frequently used "times" to do looping, I never thought deeply about how it worked:

10.times { puts "Jim" }

view raw print_name.rb hosted with ❤ by GitHub

It turns out that times is just a function (slightly obscured because Ruby doesn't require parentheses for function calls) on the Integer class that takes a code block as an argument. Times could be implemented as follows:

	class Integer
	def times
	1.upto(self) { yield }
	end
	end

view raw custom_times.rb hosted with ❤ by GitHub

This style of coding allows for some powerful possibilities. For example, it is surprisingly easy to introduce a "do in a transaction" function:

	def within_a_transaction
	start_transaction
	yield
	end_transaction
	end

view raw transaction_wrapper.rb hosted with ❤ by GitHub

Using this, I can now trivially wrap any number of statements in a transaction:

	within_a_transaction { do_something }
	within_a_transaction do
	do_something
	do_something_else
	do_a_third_thing
	end

view raw transaction.rb hosted with ❤ by GitHub

The equivalent in less expressive languages, such as Java, often involves vastly more code, implementing arbitrary interfaces, anonymous inner classes, and a lot of very hard-to-read code. For comparison, here is an example of how Java's Spring Framework recommends wrapping JDBC code in transactions:

	return _transactionManager.execute(new VoidDBExecCallback() {
	public void doExecute(DBExecContext dbExecContext) throws TransactionException {
	dbExecContext.getJdbcTemplate().execute(
	"Select name from tbl_foo where id = ?",
	new PreparedStatementSetter() {
	public void setValues(PreparedStatement ps) throws SQLException
	{
	ps.setInt(1, 12345);
	}
	},
	new RowCallbackHandler() {
	public void processRow(ResultSet rs) throws SQLException
	{
	String name = rs.getString(1);
	}
	}
	);
	}
	});

view raw SpringTransaction.java hosted with ❤ by GitHub

Ruby, Day 2: Problems

The Day 2 problems are only slightly tougher than Day 1. The most fun part was coming up with a way to keep the code as concise as possible.

Print 16
Print the contents of an Array of 16 numbers, 4 numbers at a time, using just "each". Now, do the same with "each_slice" in Enumerable.

	arr = (1..16).to_a
	arr.each { |i| print "#{i}#{i % 4 == 0 ? "\n" : ','}" }

view raw each_16.rb hosted with ❤ by GitHub

	arr = (1..16).to_a
	arr.each_slice(4) { |slice| puts slice.join(", ") }

view raw each_slice_16.rb hosted with ❤ by GitHub

Tree
Modify the Tree class initializer (original code here) so it can accept a nested structure of Hashes. Trickiest part here was that the "collect" function can call the passed in block with either one argument that's an Array or two arguments that represent the (key, value) pair.

	class Tree
	attr_accessor :children, :node_name
	def initialize(tree = {})
	@node_name = tree.keys[0]
	@children = tree[@node_name].collect{ |k, v| Tree.new({k => v}) }
	end
	def visit_all(&block)
	visit &block
	children.each { |c| c.visit_all &block }
	end
	def visit(&block)
	block.call self
	end
	end
	tree = Tree.new({"grandpa" => {"dad" => {"child1" => {}, "child2" => {}}, "uncle" => {"child3" => {}, "child4" => {}}}})
	tree.visit_all { |node| puts node.node_name }

view raw tree_new.rb hosted with ❤ by GitHub

Grep
Write a simple grep that will print the lines and line numbers of a file having any occurrence of a phrase anywhere in that line.

	# Usage: ruby grep.rb <regular_expression> <file_name>
	IO.readlines(ARGV[1]).each_with_index{ |line, index| puts "#{index + 1}: #{line}" if line =~ /#{ARGV[0]}/}

view raw grep.rb hosted with ❤ by GitHub

Ruby vs. Java, Round 2

I couldn't resist implementing the grep code in Java to see how it compares:

	import java.io.BufferedReader;
	import java.io.File;
	import java.io.FileReader;
	import java.io.IOException;
	import java.util.regex.Pattern;
	import java.util.regex.Matcher;
	/**
	* Usage: java Grep <regular_expression> <file_name>
	*/
	public class Grep {
	public static void main(String[] args) throws IOException {
	Pattern pattern = Pattern.compile(args[0]);
	BufferedReader br = null;
	String line = null;
	int lineNumber = 1;
	try {
	br = new BufferedReader(new FileReader(new File(args[1])));
	while((line = br.readLine()) != null) {
	Matcher matcher = pattern.matcher(line);
	if (matcher.find()) {
	System.out.println(lineNumber + ": " + line);
	}
	lineNumber++;
	}
	} finally {
	if (br != null) {
	br.close();
	}
	}
	}
	}

view raw Grep.java hosted with ❤ by GitHub

It's 33 lines long. The Ruby solution was a one-liner.

Ruby, Continued


Check out more Ruby goodness on Ruby, Day 3.

Seven Languages in Seven Weeks: Ruby, Day 1

I recently picked up a copy of Seven Languages in Seven Weeks by Bruce A Tate. The book is a survey of seven very different programming languages: Ruby, IO, Prolog, Scala, Erlang, Clojure, and Haskell. For each language, the goal is to give you just enough of a taste that you can see what makes it unique, what its strengths and weaknesses are, and the mindset and philosophy behind it.

Each section of the book focuses on a different language and includes coding problems for the reader to try at home. I've decided to record my my solutions to the problems and thoughts about each language in my blog. Today, we'll start with Ruby.

Ruby, Day 1: Thoughts

I've used Ruby fairly extensively the last few years, including several Ruby on Rails apps (Resume Builder, Veterans Hackday) and a number of utility scripts. There is a lot to like about Ruby - the concise & clean syntax, incredible flexibility, expressiveness, powerful DSLs - but my favorite part is the central tennet of the language, as expressed by its creator:

"Ruby is designed to make programmers happy." Yukihiro Matsumoto

The language isn't built for speed, concurrency, or any particular feature set. Its central "success metric" is programmer happiness and productivity, which are, arguably, the biggest bottlenecks in most projects.

Ruby, Day 1: Problems

The "Day 1" Ruby chapter focused on the very basics of the language, so I didn't learn anything new. The problems are extremely simple and basic, but for completeness, here are my solutions:

Hello, World
Print the string "Hello, world".

puts "Hello, world"

view raw hello_world.rb hosted with ❤ by GitHub

Hello, Ruby
For the String "Hello, Ruby", find the index of the word "Ruby".

"Hello, Ruby".index "Ruby"

view raw hello_ruby.rb hosted with ❤ by GitHub

Print Name
Print your name ten times.

10.times { puts "Jim" }

view raw print_name.rb hosted with ❤ by GitHub

Print Sentence
Print the string "This is sentence number 1" where the number 1 changes from 1 to 10.

1.upto(10) { |i| puts "This is sentence number #{i}" }

view raw print_sentence.rb hosted with ❤ by GitHub

Random Number
Write a program that picks a random number. Let a player guess the number, telling the player whether the guess is too high or too low.

	to_guess = rand(10) + 1
	puts "Try to guess a number between 1 and 10."
	begin
	print "Enter your guess: "
	guess = gets.to_i
	puts "Too low!" if guess < to_guess
	puts "Too high!" if guess > to_guess
	end while guess != to_guess
	puts "Correct!"

view raw guess_number.rb hosted with ❤ by GitHub

Ruby vs. Java

Coming from a Java background, every time I see Ruby, I'm amazed at how concise and readable it is. There is far less boilerplate: you don't have to wrap everything in classes and methods, no semi-colons, far fewer curly braces, and so on. Everything is an object and there are countless helper functions, all with intuitive names: even if you've never used Ruby, it's easy to guess the effects of 10.times or 1.upto(10). Whereas in the Java world, libraries seem to compete on having every bell, whistle, and tuning knob, in the Ruby world, libraries focus much more on having the simplest, easiest, one-line-and-you're-done API possible.

For comparison, I implemented the number guessing game in Java:

	import java.util.Random;
	import java.util.Scanner;
	public class GuessNumber {
	public static void main(String[] args) {
	Random generator = new Random();
	int toGuess = generator.nextInt(10) + 1;
	int guess;
	Scanner scanner = new Scanner(System.in);
	try {
	System.out.println("Try to guess a number between 1 and 10.");
	do {
	System.out.print("Enter your guess: ");
	guess = scanner.nextInt();
	if (guess < toGuess) {
	System.out.println("Too low!");
	} else if (guess > toGuess) {
	System.out.println("Too high!");
	}
	} while (guess != toGuess);
	System.out.println("Correct!");
	} finally {
	scanner.close();
	}
	}
	}

view raw GuessNumber.java hosted with ❤ by GitHub

It's has more than twice the number of lines of code as the Ruby version (and I kept opening curly braces on the same line!) and even though I've been doing Java for a very long time, it still took longer to write. Of course, there are many other trade-offs at play here, but they key thing to think about is the golden rule of programming:

"Programs must be written for people to read, and only incidentally for machines to execute." SICP

Ruby has its downsides, but it is one of the best languages I've seen for writing code that others can read, understand, and maintain for a long time after.

Ruby, Continued

The Ruby explorations continue on Ruby, Day 2.