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:


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:


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


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


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:



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.


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.


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.


Ruby vs. Java, Round 2

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


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


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


Print Name
Print your name ten times.


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


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.


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:


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.

Siri: a glimpse of the future

Open the pod bay doors, HAL.
Last week, I picked up an iPhone 4s and got a chance to try out its premiere feature, Siri. Siri is a digital assistant that lets you talk to your phone to get things done. You can turn the phone on, bring it up to your ear, and ask Siri for driving directions, to add reminders, find restaurants, play music, schedule meetings and more.

When I first heard about this, like many others, I wasn't impressed. Why would I want to talk to a phone? The UI on an iPhone is efficient and, as a techie, I'm pretty good at using it. Even though we've seen it predicted in all sorts of Sci-Fi movies, from Scotty in Star Trek to Dr. Bowman in 2001: A Space Odyssey, I was still not sure why talking would be preferable over other interfaces.

After using Siri for a week, I get it. Siri is a glimpse of the future.

In this post, I'll tell you why that's a very good thing.

It's not voice recognition

First, let's get something out of the way: Siri is not just voice recognition. Voice recognition by itself is nothing new and has been available for a while, even on phones. The important thing to understand is that voice recognition is merely the first step of what Siri does. It's what happens after your voice has been transcribed that's new and exciting.

Siri does a remarkably good job of natural language processing. In other words, it actually tries to understand human speech.

Before Siri, almost all voice recognition systems only worked if you used a very specific set of keywords and phrases - incantations, really. With Siri, you can speak more or less naturally and it (she?) does a remarkable job of understanding you. You don't need to read a manual or cheat sheet to use Siri: just start talking and you'd be amazed at how it seems to just work. It's certainly Clarke's third law at play, but at times, Siri seems truly magical.

Context

Not only does Siri understand normal human speech, it's also aware of the context around the conversation. For example, Siri is aware of both your location and where you live, so you can say:
"Remind me to water the plants when I get home"
As you pull into your driveway, the reminder will go off. Or, you can try:
"Do I need an umbrella this weekend?"
And Siri will check the forecast in your area, see that it's 70 and sunny, and say "no". Siri also remembers the previous things you've said, so you can have a whole conversation with your phone:
"What pizza places are around here?"
"I found a number of pizza restaurants fairly close to you." (a list comes up with Yelp reviews)
"What about burgers?"
"I found 20 burger restaurants fairly close to you." (another list from Yelp)
"What's the best one?"
"I found 20 burger restaurants fairly close to you. I've sorted them by rating."
Natural language processing + context + apps = some amazing possibilities that go far beyond the "voice recognition" you've seen before.

Efficiency

At first, I thought Siri would only be useful when my hands are busy, such as while driving and never expected to talk to my phone otherwise. As it turns out, talking to Siri can be a huge time saver in all situations. For example, imagine I want to set an alarm that will go off at 9am every weekday. Here are my two options:

Option 1: touchscreen UI
  1. Push the power button
  2. Slide to unlock
  3. Swipe through app screens to the clock app and tap to open it
  4. Tap the alarms tab
  5. Click the plus (+) to create a new alarm
  6. Use the spinners to set the time to 9am
  7. Tap the repeat menu
  8. Tap each of the weekdays individually 
  9. Tap save
  10. Done.
Option 2: Siri
  1. Push the power button
  2. Hold the phone up to my ear and say "wake me up at 9am every weekday"
  3. Done.
We're talking an order of magnitude faster. Similar time savings can be observed when getting directions ("how do I get home?"), scheduling meetings ("setup a meeting with Jon for 9am tomorrow about mobile strategy") and many other tasks. The ability to skip dozens of menus and huge amounts of text entry is a huge boost in efficiency.

And here's the kicker: the iPhone touchscreen UI is built incredibly well. It's arguably one of the most intuitive and efficient UI's available. Despite that, it's still orders of magnitude slower than Siri.

Accessibility

Speed and efficiency are great, but accessibility is why Siri is truly a glimpse of the future.  Although the iPhone touchscreen UI is intuitive and beautiful, it's still something that must be explored, experimented with, and learned. I'm a "power user", so I find it easy; the average person, even with a best-of-class interface, will find it harder.

The beauty of Siri is that it makes all of the functionality of a high tech smartphone available to everyone. Even the least tech savvy person knows how to talk, give commands, and ask questions. As Siri progresses, the bar for using the state-of-the-art will get lower and lower.

And after all, wasn't that always Steve Jobs' goal? Wasn't he always striving towards technology that was accessible to anyone, with no training and no confusion? Siri is a small step in that direction: pick up your phone and, in plain English, tell it what you want.

Personality

Finally, Siri has a personality. She can even be a bit cheeky.




There's an entire site dedicated to Siri's clever responses. But these are more than just easter eggs. They bring Siri - and your iPhone - to life. The iPhone has always done spectacularly well in terms of customer satisfaction; giving the phone a personality will make people love it. Siri will become assistant, friend, and even a part of you - we are cyborgs, after all. I suspect that after Siri, you'll never be able to go back to a phone without it.

Just the beginning

Now, let's not get ahead of ourselves. Siri is just the very first step. Actually, that's not entirely accurate: Siri is yet another step in a long continuum of making computers ever more accessible. From punch cards, to the command line, to the mouse & keyboard, to touch screens, and now, natural language processing. There is still a great deal of work to do, but give Siri a try now to see where things are headed.

In the near future, I expect Siri to be integrated with countless more apps. For example, I'd love to see Shazaam ("what song is this?"), New York Times ("what's happening in the world?"), shopping apps ("is this a good deal?"), and social networking apps ("who is this guy?"). I wouldn't be surprised to see some element of "learning" added as well, allowing Siri to become more personalized by using more info about you and your contacts (e.g. via Facebook, Twitter and LinkedIn integration), getting better with accents and mannerisms of speaking, remembering previous conversations you've had and... who knows what else.