This past year I’ve taken to keeping track of the books that I’ve read on goodreads and below is the complete list. A couple of things about the list:

1. You will notice that I liked, or at least tolerated all of the books on the list. So didn’t I pick up any books this year that I didn’t like? Sure. Did I finish them? Heck no! Life is too short to finish a bad – or perhaps simply misdirected book – out of some bizarre sense of duty.
2. The links below are all affiliate links. If this bothers you then google is your friend.

I do recommend keeping track of what you read (and thanks to my buddy Michael Fogus for suggesting just that). Keeping a list means that you can spot patterns — for example I realized that I’ve always had a bias against short books and classic fiction — and this year I’ve tried to remedy that.

Anyway, here’s my list, organized by topic.

Programming and Computers

Given what I do for a living, you would think that I read a lot of computer books. In most years that would be true, but not this one: In 2012 I went for quality over quantity. Perhaps the book that I proudest of actually finishing is Structure and Interpretation of Computer Programs (MIT Electrical Engineering and Computer Science) by Abelson, Sussman and Sussman. SIOCP is one of those much admired, frequently discussed, oft purchased but rarely read classics. Well having finally finished it, I’m here to tell you that it is well worth the effort. SIOCP takes what I think of as the 50 year view of programming; by the time you are done you will have looked at imperative programming, functional programming, meta programming, lazy data structures and everything in between. Like a lot of programmers, I’ve started this book any number of times, only to peter out somewhere in chapter three. Two things came together this year to get me on to the end: By the opening of 2012 I had gathered enough Lisp programming mileage to be comfortable with the code in the book right out of the gate. The other thing is that this time I bought a paper copy of the book — somehow having the physical thing there in my hand propelled me forward.

Another programming book that I read this year that I think quite a lot of is Let Over Lambda by Doug Hoyte. Where Abelson et. el. try to be even handed in that dry academic way about the controversies in our little world of programmers, Hoyte marches into battle with his keyboard drawn. Mostly it works and the book is full of all sorts of interesting Lisp ideas. My beef with LOL is that Hoyte violates the “show, don’t tell” rule: If I were editing this book I would have cut most of the “Lisp is indescribably wonderful” statements and leave the examples that tend to make the reader draw her own conclusion. Oh and one more thing: If LOL is only for the top 1% of the top 1% of programmers — as the book so helpfully explains — and there are something like 800,000 professional programmers in the U.S. then the target audience for this book is about 80 people. Did the publishers know?

A wonderful contrast to the somewhat preachy tone of LOL is another LOL book: Conrad Barski’s Land of Lisp: Learn to Program in Lisp, One Game at a Time!. Land of Lisp is one of those ‘full of cartoons and silly jokes’ programming books that don’t usually work for me. The thing is that Conrad is actually funny and he mixes the jokes with one of the best beginning explanations of Lisp programming that I have ever read. If you are just starting out in the Lisp world, this is definitely a book to check out.

I’ve also been delving into the history of programming languages this year, which explains why I read Smalltalk 80: Bits Of History, Words Of Advice by Glen Krasner as well as SmallTalk 80: The Language by Adele Goldberg. A fascinating look at a era where having an entire megabyte of RAM was something to brag about.

Science And Math

I spent much of my youth reading all of the science books that I could get my hands on, especially anything spewing out of the typewriter of Isaac Asimov. Asimov used to periodically publish collections of science oriented essays which I would consume just after the ink was dry. I thought I had read them all (Asimov died in 1992) until I happened onto Far As Human Eye Could See. If you care at all about the art of explaining, you should read Asimov. He was a brilliant explainer — and his essays are a great place to start.

One of the things that all of this list making has made me realized is how much my science reading has fallen off, so I spent a lot of this year catching up. For example, back in my heavy duty science reading days the question about extra-solar planets was Are they out there? Now the question is What time is it. Time is important here because we are are discovering new planets outside of our solar system at such a furious pace. As I write this the number, according to wikipedia, is about 850. When you read this the total will be higher. Wait a little while and it will be higher still. Strange New Worlds: The Search for Alien Planets and Life Beyond Our Solar System is Ray Jayawardhana’s tour through the people and technologies that are behind this torret of discoveries. It’s a fun book.

Newton’s Gift: How Sir Isaac Newton Unlocked the System of the World by David Berlinski is a pretty standard biography of everyone’s favorite physicist. Weaving in and out of Newton’s scientific life with what passed for his personal life, Berlinski tries – and mostly succeeds in pulling together a picture of the great scientist and very, very, ordinary man. My beef with Berlinski’s books, which also include Infinite Ascent: A Short History of Mathematics is that his prose is just a little too ornate. Here’s a sample:

Newton’s purely mathematical passions burst into flame during sixteen months; by the time that he left Cambridge for the countryside, the plague in place at the university, he had already immersed himself in the free-flowing currents of European mathematics and discovered, no doubt to his satisfaction that his powers were bounded only by his patience.

Sharp intake of air.

I wish there were more writers like Mary Roach out there (in fact I wish I was one of them). A typical Roach book is a light-hearted romp through some scientific or technical subject, with just enough fun to keep the science interesting. This year I read both Packing for Mars: The Curious Science of Life in the Void and the somewhat more cringe inducing Bonk: The Curious Coupling of Science and Sex. Both of these books are more about how people are reacting to our modern age than about the deep insights into how the physical world works, but both are fun and informative.

There were also no great revelations in Big Ideas: 100 Modern Inventions That Have Transformed Our World by Alex Hutchinson. It’s another one of those pictures plus a couple of pages of text for N things kinds of books but it did pass a pleasant hour or so on a Sunday afternoon. Much more serious was Einstein’s Cosmos: How Albert Einstein’s Vision Transformed Our Understanding of Space and Time by Michio Kaku. If you don’t know Michio Kaku, well you do. If you are a network news producer and someone discovers water on Mars or a misplaced boson, then the good Dr. Kaku is your goto guy. With good reason — Michio Kaku is a great explainer in the Asimov tradition and he can explain Relativity with the best of them.

My wife has a term for books like Patrick Moore’s Moore on Mercury: The Planet and the Missions. She calls them URBs, short for Ultimate Russ Books. You see my life partner is under the impression that I like very narrowly focused and detailed books, tomes that, in her words, will ‘tell you everything about nothing’. The trouble is that Moore’s book doesn’t really work as a URB. It’s kind of scattered, and worse there are a couple of really egregious errors. A much better candidate for URBdom is Alan Boyle’s The Case for Pluto: How a Little Planet Made a Big Difference. A fun book that runs through the history of Pluto all the way from discovery through planetary dethronement. Another interesting and surprisingly readable little book was Paul Strathern’s Hawking and Black Holes. I’ve always found Hawking’s writing completely incomprehensible. This book was only partially incomprehensible, which, when you are talking about black holes is a win.

Lee Smolin’s The Trouble with Physics: The Rise of String Theory, the Fall of a Science and What Comes Next is exactly what the title suggests: A long explanation of string theory and why it isn’t even science and how it came to dominate physics thinking and why that is a bad idea. I found the science in this book interesting and the politics of physics departments less so.

The best part of Richard Panek’s Seeing and Believing: A Short History of the Telescope and How we Look at the Universe is how the telescope changed astronomy not once but many times: Each new technical development led to a new vision of how the Universe is put together.

So who can resist a book from Jack Horner, who was technical advisor on the film Jurassic Park entitled How to Build a Dinosaur: Extinction Doesn’t Have to Be Forever? This books covers the usual territory of what the dinosaurs are, how we know about them, what we know about them and the prospects for creating a modern day (and I’m not making this up) chickenosaursus. Fun book.

I also spent some time learning more about math, starting with Ian Stewart’s Life’s Other Secret: The New Mathematics Of The Living World. Mr. Steward contends that DNA ain’t all there is to living things — that life is as much about the complex unfolding of dynamic systems as it is about the information encoded in your genes. Sounds plausible to me. Is Steward right? Dunno. But at least I know what the questions are, which is the first step.

I spent a lot of time studying calculus when I was in school and this year I turned back to that subject with a war and some diaries. The war came in the form of the historical dispute over who invented calculus: The Calculus Wars: Newton, Leibniz, and the Greatest Mathematical Clash of All Time by Jason Socrates Bardi. The diaries came curtesy of Jennifer Ouellette, who takes us along on her quest to figure out just what all those funny dx‘s are all about: The Calculus Diaries: How Math Can Help You Lose Weight, Win in Vegas, and Survive a Zombie Apocalypse. If I had to choose between the two I would definitely go for the Zombie Apocalypse flavored calculus over the stuffier historical variety.

If you have some time to kill in the bunker while waiting for the zombies to dissipate, take a look at Nate Silver’s The Signal and the Noise: Why So Many Predictions Fail. Silver is the guy who predicted the results of the recent U.S. presidential election down to the last state. Perhaps we should spend less time listening to the pundits and more time listening to people who tend to be right?

You might also want to spend some time with Michael Meyerson’s Political Numeracy: Mathematical Perspectives on Our Chaotic Constitution. This book is less about predictions and more about having a coherent debate about politics. I particularly like Meyerson’s idea that the arguments about things like the death penalty and abortion can be informed by modern mathematical ideas about infinity.

History

I like history a lot and since much of the US civil war was fought on my doorstep I do tend to spend a lot of time on that particular episode. This year’s crop of Civil War books included Secrets of a Civil War Submarine: Solving the Mysteries of the H.L. Hunley by Sally M. Walker, which is actually aimed at kids, but was interesting nevertheless. There was also To Appomattox: Nine April Days, 1865 by Burke Davis, a book about the last days of the war, an OK book that was just obsessive enough in the details to have that I spend every weekend reenacting the Battle of Whatever feel.

As I say, I like history a lot, and I do like some decades more than others. So this year I’ve tried to expand out a bit and fill in those dark spaces in my historical head, with mixed results. For example, a close reading of Tuchman’s The Proud Tower: A Portrait of the World Before the War 1890-1914 leads me to the conclusion that life from 1890 to 1914 was tedious. At least reading this book was; perhaps those years need a better biographer. Better was The Crazy Years: Paris in the Twenties by William Wiser, which is a tour through the artist and writer infested Paris immediately after the First World War.

Speaking of that late unpleasantness, we have John Keegan’s The First World War. Now this is what I look for in a history book: It’s deep, it’s detailed and it keeps moving.

Of course you can’t talk about World War I without mentioning it bigger and uglier brother. Finest Hour : The Battle of Britain by Phil Craig is a good book on the early ‘Britain stands alone’ part of the war.

Along with history I love me a good caper story. Put the two of them together and you have Paul Brickhill’s The Great Escape. This is the story of a a massive breakout from a German World War II POW camp, complete with tunnels, convincing disguises, cleverly faked identity papers, the works. Of course it’s all fun and games until you piss off the Nazis and they start executing people.

Alan Moorehead’s Eclipse is an interesting first hand account of the end of World War II. Written just months after the war ended, it is a good lesson in how different things can look when you are right up against them. Worth a read.

Rounding out my WWII collection is Eisenhower and Berlin, 1945: The Decision to Halt at the Elbe by Stephen E. Ambrose. This is as much a book about the Cold War Why didn’t the western powers rush into and take more of Germany before the Soviets got there? as about the Second World War. Also another URB. As is The Cold War: A New History by John Lewis Gaddis. I remember the day — I think I was 11 or 12 — when I realized that there was this other country out there, a country that was ready, and more disturbingly able, to kill me with 15 minutes notice. Gaddis’ book puts all that in perspective and along the way made me feel better about the world as it is today. Think about it: for all the horrible things that are going on right now, at least we are not 15 minutes away from extinction.

If you are, as I am, a fan of the HBO series Boardwalk Empire, you might be tempted to check out Boardwalk Empire: The Birth, High Times, and Corruption of Atlantic City by Nelson Johnson. Although the TV show is theoretically based on the book, be forewarned that the two have very little in common. Read the book and you will find that, as shown in the HBO series, AC was indeed a center of bootlegging during the 1920′s. But keep reading and you will also learn how Atlantic City came into being, how it rose and then declined and the (maybe) rose again with the coming of casino gambling. That is a lot of dry historical fact in return for a brief flash of mob glitter.

I’m also a fan of the TV show Mad Men. The book The Real Mad Men: The Wizards of Madison Avenue and the Memorable Ads that Shaped Our World by Andrew Cracknell? Meh.

I have strong political opinions and one of them is that people should mostly keep their politics to themselves. Having said that, I do think that Rachel Maddow’s Drift: The Unmooring of American Military Power is worth reading. Maddow makes the case that the US military has become detached from most of the US population and that this is bad for the military, for the rest of us and for the country as a whole.

In the same spirit, with all the talk in this past US election about voters needing picture ID, I’d like to suggest an alternative: Everyone who wants to vote should need an ID or proof that they have read Maureen Harrison’d Freedom of Speech Decisions of the United States Supreme Court. This simple book, where each chapter focuses on a single Supreme Court decision, complete with a summary of the case followed by the key bits of the decision itself, makes me proud of my country.

Blind Ambition by John Dean makes me a lot less proud. Dean was one of the key figures in the 1970s political firestorm known as Watergate. If you have ever wondered how decent people sometimes end up doing really awful things, have a look at this book.

Finally we have A Travellers History of Canada by Robert Bothwell. This was a book I read at least partially out of guilt. My friend and colleague Ryan Neufeld is from Canada and, well, I didn’t know a thing about that big country lurking up there at the top of the map. So I got hold of this book — admittedly a little dry and a little dated — and now I’m don’t feel quite as ill informed as I did. Just mostly.

Next year I’m going to make a concerted effort to read some non-North American, non Western Europe history.

Various

Reel Culture: 50 Movies You Should Know About (So You Can Impress Your Friends) by Mimi O’Connor is another one of those N Things kind of books. Should I feel guilty? Yes. Do I actually feel guilty? No.

I certainly don’t feel guilty about reading Steal Like an Artist: 10 Things Nobody Told You About Being Creative by Austin Kleon. Steal Like an Artist proves that books don’t have to be long and drab to be wonderful and valuable. Steal this book.

Another winning ‘N Things’ book is The Little Red Writing Book: 20 Powerful Principles of Structure, Style, and Readability by Brandon Royal. Being able to write well is the gift that gives in both directions: It makes you better at what you do and it enables you to make other people better. This little book is a great reminder of the basics.

Closely related are the next two books. I say they are related because being able to write is only part of the equation. The other bit is knowing something. What Does It All Mean? A Very Short Introduction to Philosophy by Thomas Nagel is a very short book about how we know what we know, while Michael Shermer’s Why People Believe Weird Things: Pseudoscience, Superstition, And Other Confusions Of Our Time is all about how we know what we do not in fact know. I know more for having read these two.

Finally, here’s another personal admission: I love the Ukulele. I love playing the things, I love other people playing them, I love buying them, and I even love reading about them. Despite the fact that, as someone once said, writing about music is like dancing about architecture, I like the way Alistair Wood writes about the ukulele in Ukulele for Dummies. If you want to learn to play the uke, a) buy one b) check out youtube and c) buy this book.

Fiction

This has been a fictional year of discoveries for me. The discoveries were real enough, it’s just that they involved fiction. I kicked off the year by discovering Jack McDevitt, in the form of his novel Deepsix (Engines of God, #2). Deepsix has everything that good science fiction should: Strong characters, including an actual female lead for a change, commentary on current society, and high, high tech all wrapped in an action filled plot. The only question that Deepsix leaves behind is why Hollywood insists on making crappy, story-free bits of fluff (yes Avatar, I’m talking about you) when Deepsix is lying around, just waiting to be made into a film? Best of all, Deepsix is part of a series (actually it’s the second volume of the series, but I’ve never been known for coloring within the lines) so once you finish it you can flow right into Chindi or Cauldron or Omega. If you aren’t in the mood for a long series, you can try the other McDevitt book that I read this year: Infinity Beach. Many of the same themes as Deepsix et. el. in a single tidy tome.

If you are looking for another good book with a strong female lead then try Stieg Larsson’s The Girl With the Dragon Tattoo (Millennium, #1). This story of violence, abuse and creepy old men is not for the weak of heart nor the upsetable of stomach, but it is nevertheless an enthralling read.

On the much lighter side is Stuart Jaffe’s Southern Bound (Max Porter Mysteries) and its sequel Southern Charm. So you got your modern day private eye, his feisty wife and their secret weapon, the ghost of a long dead Sam Spade knock-off. Yes, you read that right, ghost. I don’t usually recommend books based on price, but I’ve got to say that these inexpensive novels (available on Amazon and wherever fine bytes are sold) provide a lot of fun for not a lot of bucks.

Another way to waste a lazy Sunday afternoon is to read the little gems in 50 Short Science Fiction Tales. Edited by Isaac Asimov, this book is full of 4 and 5 page mini stories. In a world full of 600 page, Part 1 of the 11 book series with maps on the end pages it’s fun to read stories that come to the point.

Do comic books — sorry, graphic novels — count? They do if they are The League of Extraordinary Gentlemen, Vol. 1 and The League of Extraordinary Gentlemen, Vol. 2 both by Alan Moore. If you take all of the fun characters from 19th century speculative fiction, everyone from Captain Nemo to Mr Hyde and roll them into a James Bond sort of plot, well you had me at Captain Nemo.

Speaking of 19th century speculative fiction, I also read The Island of Dr. Moreau by H.G. Wells this year. Creepy and bloody in ways that usually keep me out of a book, this one was good enough to propel me on to the end. I’ll never look at the cat quite the same way again though.

I love John Mortimer’s Rumpole stories, and knowing this my lovely wife gave me A Rumpole Christmas: Stories for (what else) Christmas. If you don’t know Rumpole, he is an aging and opinionated British lawyer and sometimes writer, someone who is good at what he does and simply wants to get on with it. Substitute ‘engineer’ for ‘lawyer’ and you’ve pretty much nailed my career aspirations, but I wish I was half as witty as old Rumpole.

My final discovery this year was Jane Austen. Now Jane and her books have been around for a while, it’s just that I could never bring myself to finish one. This year I discovered it wasn’t Jane that I had a problem with, it was Emma. You know, the snotty rich girl from Austen’s novel called, well, Emma. I had tried to read Emma a few years ago and it just bugged me. So early this year I had another run at Austen with Pride and Prejudice and what do you know, the girl can write. In fact I liked P&P so much that I slid right into another Austen winner Sense and Sensibility. From there I went on to Persuasion and at that point my romance with Miss Austen hit another rough patch. So Jane and I are on something of a break, reading other people and seeing how things work out. I’ll let you know.

Onward to 2013!

Russ

Have you ever thought about how much of software engineering involves explaining things? We stick comments in our program to explain why we added X to Y, we type up README files to explain the program, we write proposals to explain why the program should be funded and we spend the afternoon explaining the whole thing to the new guy so that we can move on to something new. A decent explanation can be the difference between success and obscurity: Would there be any Ruby conferences if not for that original 15 minute build-a-blog screencast for Rails?

In this talk Russ Olsen will run through the things that you can do to craft explanations that are clear, engaging and perhaps even a bit funny. Russ will do his best to be clear, engaging and perhaps a bit funny.

This version is from last Summer at the Rocky Mountain Ruby conference in Boulder.

Russ

Russ: One thing that surprised me as I was preparing for this interview is that you have a Ph.D. in theoretical physics. How did you start in physics and end up in Ruby?

Michael: My work was mainly in computational physics, so I was writing programs all the time as part of my Ph.D. research. I also got interested in the idea of starting a company when I graduated. It was obvious in the late ’90s that software was moving online, so I decided to learn web development. I started with PHP, moved on to Python (in the pre-Django days), and then found Rails.

You can find the whole interview here: An Interview with Michael Hartl: Ruby on Rails, the ‘Magic’ Problem, and the Higgs Boson

Russ

The best programming advice I ever got came to me early in my career while I was working on a system that I simultaneously loved and hated. The cool part of that system was that we were doing computer aided design — think Adobe Illustrator, but for engineers. In those days CAD, with its interactive graphics, was the highest of high tech. The thing I hated was that the it was slow, painfully slow: You would sit there and watch the picture appear line by painful line. A simple drawing would take tens of seconds, while displaying something complicated was an opportunity to get coffee. The performance of that system was horrendous even by the standards of the primitive computers we had back then, which is saying something. What was a hacker to do? What would *you* do? …

Find out what I did over at InformIT.

In my professional life, I’m only afraid of a few things. John’s keyboard, which is coated with that fine patina of brown gunk. A call in the middle of the night saying the app server won’t start. And the dreaded request: “Russ, see if you can speed this code up.” It’s usually code I’ve never seen. It’s probably important, otherwise they wouldn’t be worried about how it is performing. And speed it up to what? Still, there are some basics you can fall back on when someone asks you to optimize some code. Here goes…

1) Start with working code and good tests or you are doomed

Before you can make something work fast, you need to make it work. And you can’t know that it is working if you don’t have good unit tests to tell you so. There is no point in making broken code run faster — a program that simply prints out “42” will run in no time flat but is unlikely to produce the output you are looking for. How are you going to know if your optimizations haven’t sped things up by breaking them horribly? You need a good set of tests.

2) Rest assured, you don’t know where the problem is

Back when I was still doing a lot of Java, I was assigned the task of speeding up some  code that managed query results. Very large query results. A quarter of a million rows, each with more than a hundred columns was not out of the question. The code that I inherited was actually the second or third generation of the thing. The original had kept all the results in memory, a strategy that worked fine as long as the number of users was approximately two. Any more and smoke started to billow up from the server room. The version that I started with at least stayed up, since it stored the results in a random access file and kept an index of the file in memory. The problem with the new version was that it was very slow.

I looked over the code and immediately found the performance problem: they were using Java serialization to turn the rows into bytes before writing them to disk. Ah, I thought, serialization is dead slow. It only took me the better part of the afternoon to come up with a way of turning those rows into bytes without the overhead of Java serialization. But removing the serialization didn’t really make much of a difference. A few percent when I was looking for something like 75%.

Although my change made only a tiny difference in the speed of the code, I did gain something. I was reminded that when optimizing, you need to profile first and code later. I was so darned sure it was the serialization that I didn’t bother to profile the code. Well OK, so I took my change out and profiled the code. Surprise! The culprit turned out to be in the way we were reading and writing the data to the file. Our IO was completely unbuffered — we were laboriously reading and writing all that data one byte at a time. Compared to huge IO overhead, the serialization was a drop in the bucket.

My experience is not unusual: Your best guess as to what is making this program a pig is usually wrong. The only way to know is to run your code with a profiler and see which bits are the slow ones.

3) There is always a long pole in the tent, but it is not always the same pole

As you optimize you code, you need to run your profiling after each change. You are looking to answer two questions. First, did my change actually help? If the change did speed things up, is there now a new bottleneck? Some part of our program is always going to be the limiting factor — otherwise your code would be infinitely fast. As you optimize things, it is quite likely that the part you sped up will fade into the background and some other section of the code will become the new bottleneck.

Going back to my results manager project, turns out that after I put in the buffered IO, which made a huge difference, the slowest part of the code was… Yes! The serialization. Remove the huge cost of unbuffered IO and the Java serialization was the problem. Back into the code went my original change.

4) If it doesn’t help, take it out

I said that you should reprofile your code after each change. The idea is to see if the change helped and if so to identify the new problem area. But what if the change didn’t help? Take It Out! I don’t care if your idea is so brilliantly efficient that it can’t possibly not speed things up. If Mother Nature doesn’t agree, Take It Out. Look at it this way: you are starting with code that works and your job is to make it faster. And oh yes, keep it working. Despite your unit tests, every change you make risks screwing things up. If your optimization isn’t an optimization, then Take It Out. How fast is broken?

5) You need to know when to stop

The trouble with optimization is there is no end to it. You can always think of something you can do to make the thing run a little faster, lighter, cheaper. The trouble is that making programs run faster frequently means making them uglier. There are exceptions: sometimes the original is slow because it is badly thought out, or it takes up too much space because it was hacked together from the start. But much of the time optimization is the process of taking nice code and making it longer, more complex, harder to read. In short, less nice. Really we should stop using the term optimization. We should call it what it really is: screwing up the code so that it performs better or maybe justifiable mutilation. You have to know when to stop, when the mutilation to performance ratio is just too high.

That’s really it: when optimizing you need to know what you are starting with, what you need to change, if your changes are working, and when to stop.

Russ

Books Read Thirty Two. Sad that Structure and Interpretation of Computer Programs is not on that list. Happy that it will be the first book that I finish in the 2nd half of the year since I’m just 100 pages from done.

Miles Hiked A couple of hundred but I should have kept better track.

Most Inane Discovery There are Ulysses S Grant $1 coins. My grandfather was named after the Civil War general and 18th US president. Imagine going thru life with Ulysses as your first name.

Blog Articles Written Twelve

New Programming Languages Wrestled With Two — Clojure and JavaScript. Three if you count CoffeeScript. (Ruby is no longer a struggle, finally. We do punch each other in the shoulder occasionally, just to show that we care).

JavaScript Projects Completed Just one, but a biggie because it was first.

Ukuleles Acquired Just one. I think the UAS is finally under control.

Most Popular Article Ruby reading list by a mile.

Best Conference Moment Hearing someone at RubyNation 2012 say that RubyNation 2008 changed his life (I’m a RubyNation organizer)

Best Work Moment Since I work at Relevance, too many to list. Having said that,  dialing into an early morning standup the other day to hear Michael Fogus say “More fish-sticks!” does come to mind.

Most Insane (in a good way) Coworker The golden straight jacket has to go to Chad Humphries, though there are many, many runners up.

Best Personal Moment Seeing my son graduate.

Saddest Personal Moment Seeing my son graduate.

New Book Projects <<REDACTED >> But stay tuned.

I love living in the future.

Russ

Zippo lighters and Russian novels

Back when I was still working for FGM, I spent a year running their lunchtime seminars. This was your typical volunteer driven get up and talk about anything kind of program that you find at a lot of tech companies. Since I was running the thing, I sat through just about every lunchtime seminar given that year, which with holidays and the occasional cancellation was something like 45 talks.

What I remember most were the pleasant surprises. Like the guy who wanted to talk about his Zippo lighter collection. I went into that session thinking I’d rather spend an hour watching paint dry. But then he started talking about the history of the lighters, about the different models, about how they were the prized possessions of some Viet Nam vets, and about the clever ways that he hunted down rare specimens. I came out thinking that the world of Zippo lighters was actually pretty interesting.

I also remember the talk about Russian novels. Now I don’t have a thing against Tolstoy and his equally verbose buddies, but they have simply never been my cup of vodka. But there was this woman who wanted to talk about her love of — you guessed it — Russian novels. Again, I entered the room thinking, Oh God, anything but Russian novels. Except that it was fascinating. And so it went: We had surprisingly good talks about guitar repair,  table top war gaming and Irish dancing.

The key factor

Now some of those 45 talks were really polished, done by people who do this sort of thing for a living. Others would have benefited from more planning, more practice and less PowerPoint. The funny thing is that some of the best talks — and here I’m thinking of Mr. Zippo and Ms Russian Novel — were not among the most polished. Some of the most interesting were delivered by people who mumbled through 200 busy slides while making excellent eye contact with their shoe laces. The thing that the best talks had in common was not presentation chops, it was passion.

It’s really not hard to understand: If you care about something it will come shining through when you talk about it. Not only that, but you are a lot more likely to do a good talk if you care about your subject. You can make your talk better by organizing your thoughts, by practicing and by taking command of the room, but in the end your passion for your subject is the energy source that makes your talk go.

Now passion can take a lot of forms. If you are an over the top arm waver, by all means wave your arms as you go over the top. If you are naturally more understated, then be understated, but make sure the thing that you understate is that what you are saying is important. Quiet enthusiasm is just as contagious as the louder kind.

So what do you do if you are stuck talking about some deadly dull subject, about something you don’t give a darn about? My advice is to find a reason to care. Dig into it. It’s probably, like the Zippo lighters and the Russian novels, important to somebody. Try to see the world from their point of view. If nothing else, you can care about your audience: I once got a round of applause from what started out as a room full of grim faced people resigned to sitting through a boring program review. The reason they all clapped at the end was that I admitted it all up front: This is going to be dull. But we have to do it, so let’s just get through it as quickly and painlessly as we can.

Wrapping up

So there it is: If you want to do a good technical talk, productively neglect the slides and instead focus on organizing what you are going to say. Then practice, practice, practice. When you get up there, take command of the room and above all, mix in some passion.

Russ

Help Us Accept You

I should start by saying that most of my experience with this sort of thing is from the other end: I help organize RubyNation, and a big part of that is picking the speakers every year. One surprising thing about the RubyNation organizers and, I suspect, the organizers of most other tech conferences is this: We want to accept every proposal that comes through the door. Think about it: Technical conferences are mainly volunteer affairs, put together by people who have a passion for the subject and for the community and who just want to give a little bit back. So here at the RubyNation world headquarters (generally an unused conference room in some nameless office park) we see every talk proposal as an offer of help, frequently from people we have never met. Yes, some talk proposals are better than others. Yes, some we take and some we turn down. But if we could hug everyone who ever sent in a proposal I suspect we would.

Having said that, we do take some talks and turn others down. How do you make sure that your talk is one of the ones that gets accepted?

The Bone Headed Stuff

One thing that you can do is to proof read your proposal. If you have been reading this blog for a while you know that I am not the king of spelling, the godfather of grammar nor the prince of punctuation. Neither are my RubyNation colleagues. Nevertheless we will tend to accept a proposal that is carefully written over one that is full of spelling and grammar mistakes. Look at it this way – a technical talk is all about communication and your proposal is the first bit of communication that we see from you.

You should also make sure that you take a look at the conference speaker guidelines. These will typically give you a hint as to what you should be talking about and how long your talk should be. Pay special attention to that how long thing. Every year we get a few proposals for talks that want to explain Life, The Universe and Everything – in 40 minutes.

Another thing is to make sure that you get your proposal in on time. Again there are no the rules must be followed people on the RubyNation organizing committee, but we do all have a sense of fairness and simple fairness says that proposals that come in on time will have a huge advantage over the late ones.

Tell Us What You Want to Say

So you’ve cranked up your spell checker, and you’ve read the speaker guidelines. Now what? Three things: Tell us what you want to say, a little about how you are going to say it and why you are the person to do the saying.

Of the three, what you want to say is the key. Keeping your eye firmly on the amount of time that you will have to talk, just tell us what you want to talk about. Not in general, like “CoffeeScript is the greatest thing” but specifically: “Why every web developer should use CoffeeScript” or even better “The three advantages of CoffeeScript”.  I can’t speak for everyone, but I’m a sucker for the three quarters fact, one quarter passion approach, so better still is: “CoffeeScript’s three advantages and why I love it so.”

Surprisingly we get a fair number of talk proposals every year that wax poetic on the perspective speaker’s love of some topic — perhaps CoffeeScript — without ever mentioning what they want to say about it. Yes, tell us why the subject is important, but don’t leave out what you are going to say about it.

Tell Us How You Are Going to Say It

We are also interested in how you are going to do your talk. Is it a straight lecture or a tutorial? Are you going to code live? Are you going to try to be a little or a lot funny or deadly serious? Is your talk a call to arms or an amusing look at whatever? Will there be audience participation? There’s no right answer here, we just want to know that you have thought it out a bit.

Within reason, it helps if your proposal is written in the same spirit as your talk. Funny proposals for funny talks have a much better chance than a serious proposal for a funny talk or (Lord help us) a funny proposal for a deadly serious topic.

Tell Us About You

It also helps to talk about yourself: What is your background in the topic? Why do you care? What is your public speaking experience? One of the best things about running RubyNation is that we like to give new speakers a chance. All you have to do is convince us that you can do a decent job.

One way that you can convince us is to direct us to other things that you have done. If we haven’t heard of you our first step is to do some creative google’ing. You can help us — and yourself — by directing us to internet places where you show up. Got an open source project or ten? Have you done some previous speaking? Or a podcast? Written an article? Do you have a blog? Point those things out in your proposal. Just be careful not to oversell yourself. If you are one of the industry’s leading lights then a) you don’t need my advice and b) we will figure it out.

So there it is: A talk proposal should say what you want to talk about, how you are going to talk about it and why you are the guy or girl to do the talking. As I say, we want to have you come speak. Help us.

Russ

How do you learn a new programming language? Attend a class? Buy the book? Just start writing code? All of those things will get you going – especially that last one – but if you really want to know how the experts do it, you gotta read some code. There is nothing like grabbing a well written application and trying to figure out how it all works to get you into the spirit of a new language.

If you are trying to learn Ruby by reading code, then I have some good news and some bad news. The good news is that Ruby is designed to be a language that is easy for humans to read. Ruby is so flexible that you can usually say a lot in very little code and this generally makes reading Ruby programs a pleasure. The bad news is that Ruby is so flexible that beginners sometimes find it a bit trying to spelunk their way through a serious application. In particular, Ruby’s flexible nature means that the code that gets executed when you sayobject.method does not always live where you think that it might.

So in the spirit of getting more people spun up on my favorite language, I’m going to take you through some of the ways that you might hook a method name on some object to a particular bit of Ruby code. We will start with some of the more pedestrian ways that a program can connect some Ruby code to a method name and then dive into the more exotic techniques.

Here we go…

The Usual Suspects: Classes and Superclasses

Let’s start with the most basic of basics: Every Ruby object has a class and a super class and a super-duper class and so on until you get to Object (or in Ruby 1.9, BasicObject), which stands alone at the top of the heap. And to no one’s surprise, when Ruby goes looking for a method it starts with the class and runs up the tree from class to super class until it finds the method or runs out of classes.

For example, I might be trying to model a car:

class Car
  def color
   "Boring blue"
  end

  def number_wheels
   4 
  end 
end 

class SportsCar < Car
  def color
    "Sizzling red"
  end
end

my_car = SportsCar.new

What we have in the code above is a SportsCar class which is a subclass of Car which is, by default, a subclass of Object.

Call a method on an instance of SportsCar and you get what you expect: my_car.color will return a very vivid shade of red. After all, thecolor method is defined right there in the SportsCar class. Similarly, if you call my_car.number_wheels, you will find out that no matter how snazzy your new toy, it puts its tires on four at a time. Thanks to the magic of inheritance, Ruby will discover the number_wheels method in the Car class after failing to find it in SportsCar.

You might also call to_s on your sports car instance and get something like this back:

"#<SportsCar:0xb7d073b8>"

The to_s method comes to you courtesy of the super-duper class, Object.

Finally, if you call some non-existent method, say my_car.foobar you will get an unpleasant message stating that there ain’t no such method: Ruby ran up the super class chain and complained when it fell off the top without finding a thing.

So if you are reading some code and you see my_car.number_wheels, start with the obvious: Look for the number_wheels method in SportsCarand then in Car and so on up the line.

The Module Behind the Curtain

Once you get past classes, things get a bit more interesting. Besides the standard class and super classes, Ruby also features modules. A module is a bit like a class, and in fact you define the two with nearly identical syntax:

module Convertible
  def top_down
    "Putting the top down"
  end

  def top_up
    "Putting the top up"
  end
end 

Modules may look like classes, but you can’t instantiate a module. What you can do with a module is include it in your class:

class SportsCar < Car

  include Convertible

  def color
    "Sizzling red"
  end
end

The effect of including a module in a class is to insert the module in the inheritance chain between the class and its super class. So if we called top_down on an instance of our new SportsCar class above, Ruby would look first go looking for the method in the SportsCar class (nope not there) and then in the Convertible module (got cha!). If we called the color method, then Ruby would look first in SportsCar (no luck), then in Convertible (nope) and then in Car (ah ha!).

The nice thing about modules is that while a class can only have one super class, it can include as many modules as it likes:

module NavigationSystem
  def location
    "39 53 N 75 15 W"
  end
end

class SportsCar < Car
  include Convertible
  include NavigationSystem

  def color
    "Sizzling red"
  end
end

The SportsCar class now includes both the Convertible and the NavigationSystem modules, so we will know exactly where we are when we put the top down. The fact that modules get inserted into the class hierarchy just above the including class has some interesting implications. First, since a module acts like a sort of super class, a module cannot override a method in the class that includes it. For example, imagine that we defined the location method directly in the SportsCar class and also included the NavigationSystem module:

class SportsCar < Car
  include Convertible
  include NavigationSystem

  # Stuff deleted ...

  def location
   "Right here"
  end
end 

With the code above, if your call location on an instance of SportsCar, you are always going to find yourself “Right here” – the method defined in the class always wins.

Second, it is not just your class that can have modules: your super class and its higher level relatives can also suck in modules by the basketful. But it all works the way you expect: When Ruby goes looking for a method, it first looks in the class, then in all of the modules included in the class, then in the super class and then in all of its modules and on up the tree.

Third, if you include several modules in a class, the modules get hooked into the class hierarchy such that the last module included is the first one to be searched. This means that when you call a method on your sports car object, Ruby will look first at SportsCar, than at NavigationSystem, and then at Convertible – in that order. Generally the order that you include modules doesn’t make much difference, but if two modules happen to define the same method it’s the method from the last module that you include that will win.

So if you are trying to figure out that automotive app and you just can’t find the location method in any of the classes, go looking in the modules included by the classes.

Singleton Methods: The Mysterious Stranger

But what if the method is nowhere to be found in the modules either? Well it might be completely alone. You see, Ruby allows you to define singleton methods (no relation to the design pattern of the same name). A singleton method is a method that you define on an object, independent of its class or modules.

I have taught Ruby to a fair number of experienced Java programmers and generally their initial reaction to singleton methods ranges from a good old Texas “That just ain’t right” to actual nausea. But once your ears stop ringing, it turns out that being able to customize a single object without having to worry about what the rest of the class is doing is incredibly useful. Think of all those cases that you have come across in your programming life, the ones that almost but don’t quite fit into some class, the programming equivalents of the three legged dog or the flying car. Singleton methods are made for this stuff.

It turns out that there are a couple of ways that you might hang a singleton method on an object. For example, if you wanted to install a custom, one of a kind, sound system in your car, you might use the class style notation:

my_car = SportsCar.new class << my_car
  def custom_sound_system
    "... BYYYYING A STAIIIIRWAY to heaVennnnnnn"
  end
end

Alternatively you might enhance your tunes by simply defining the method right on your object:

my_car = SportsCar.new

def my_car.custom_sound_system
  "... BYYYYING A STAIIIIRWAY to heaVennnnnnn"
end 

Either way you end up with a my_car object that is one method different from all of the other sport cars.

And just how does all of this work? Very simply: every object has a sort of stealth class that sits between the object and its regular class. When you define a singleton method on an object, the method goes straight into the singleton class. The singleton class is a real class, and like any other class it can include modules. So one way to customize your car would be to add a cool new exhaust system:

module CoolExhaust
  def rev_engine
    "VAROOOOOOOOOOOOM"
  end

  def monthly_disturbing_the_peace_fines
    279
  end
end

my_car = SportsCar.new

class << my_car
  include CoolExhaust
end

Your car, and only your car, now sports the new exhaust system: You can now rev your engine in the morning and spend all afternoon in court.

The singleton class is a bit like a module: While a module fits in between a class and its super class, the singleton class fits between an instance and its class. When Ruby goes hunting for a method, it is actually the singleton class that Ruby consults first, before the regular class, before any modules and certainly before any super classes.

method_missing: The Method With a Thousand Faces

Imagine that you are trying to follow some code that calls my_car.drive_to_washington, but you can’t find the drive_to_washington method anywhere. You have searched your classes and modules. You have kept an eye out for those pesky singleton methods. You have searched and grep’ed and grep’ed and searched and that stinking drive_to_washington method is just not there. Relax, you may have just come across a case of method_missing (cue scary music).

We have seen that when you call a method on an object, Ruby goes through this exhaustive search – it looks in the object’s singleton class and its modules, then in the regular class and its modules, and then in the super-class and so on. But what if there is no method to be found? You just get an exception right?

Not exactly: when Ruby fails to find a method on the first pass, it doesn’t just give up. Instead Ruby begins the method hunt all over again, starting with the singleton class and working its way up the tree, this time looking for a method called method_missing. Essentially, Ruby tries to inform your object that someone called a method on it and that that method was, well, missing. It does this by calling the method_missing method. What happens from there is really up to you. Do nothing and the method_missing from the Object class will eventually throw the exception that you expect. But you can also define your own method_missing method and catch those unexpected calls and do whatever you want with them.

To see how this works in practice, let’s define a method_missing to implement that mysterious my_car.drive_to_washington call:

class Car
  def method_missing(method_name, *arguments)
    if /^drive_to_/ =~ method_name.to_s
      place = method_name.to_s.sub(/^drive_to_/, '')
      puts "I'm driving to #{place}" 
    else
      super
    end
  end
end

There really is not a lot going on here. The method_missing method gets called with the name of the absent method along with all of the arguments that it was called with. What the Car class does is to look at the name of the method: If the method name begins with the string “drive_to_” then the code will clip off the last part of the method name and announce that that is where it’s going. Notice that if the method name does not look right, method_missing calls super which will eventually call method_missing from Object and we will experience an exception.

With our new version of Car we can drive where ever we want:

c = Car.new
c.drive_to_washington
c.drive_to_ny

The key thing to notice about the way we implemented the drive_to_washington and drive_to_ny methods is that the strings “drive_to_washington” and “drive_to_ny” never actually appear in the source code. That is something that you need to keep in mind as you are scouring some application for an enigmatic method: it may be hiding, nascent, in method_missing.

Methods Here and Methods There

Sometimes the explanation for those hard to find methods is a lot simpler than method_missing. For example, you might be looking for a method and you have looked at the class definition, you have looked at the modules and you have searched diligently for any method_missing’s and you still can’t find that method. What gives?

Wait… Did you say the class definition? You see, in Ruby there is no such thing as the class definition. Oh a lot of classes are just defined in one place, like this:

class Convertible < Car
  def color
    "Sizzling red" 
  end

  def top_down
    puts "Putting the top down" 
  end

  def top_up
    puts "Putting the top up" 
  end
end

But it is also perfectly possible to define a class in several chunks. You might, for example, find the first part of your convertible in one file:

class Convertible < Car
  def color
    "Sizzling red" 
  end
end

And then come across more of it in a second file:

class Convertible
  def top_down
    puts "Putting the top down" 
  end

  def top_up
    puts "Putting the top up" 
  end
end

Note that that second bit of code doesn’t create a new Convertible class; instead it reopens the existing Convertible class and adds a couple of methods to it.

The thing to keep in mind about Ruby is that when you define a class, you are not doing something all that special. What you are doing is creating a new object – an instance of Class. The object that you create, Convertible in our example, is special in some ways (you can create new instances with it, for instance) but in the end it is just an object. In Ruby you can modify existing classes as easily as you can create new ones. So if it is convenient to define one part of a class over here and another other there, people will. You just gotta keep your eye open for it.

Manufacturing Methods With Metaprogramming

The final twist in method making that we will look at is creating methods with metaprogramming. Metaprogramming is one of those very powerful techniques that can make writing an application so much easier but which can also make the code completely incomprehensible if you don’t get it. But read on, because get it you shall…

The idea of metaprogramming is that your program modifies itself as it goes. This is relevant for us, because a very popular way to modify a class via metaprogramming is to add a method to it. One way to do this is to simply evaluate the code to add the method:

class Car
  def self.add_destination(dest)
    code = %Q{
      def drive_to_#{dest}
        puts "Good bye!" 
        puts "I'm driving to #{dest}" 
      end
    }
    eval(code)
  end
end

The example above defines a class method called add_destination. The first thing that the add_destination method does is to conjure up a string (the %Q{...} syntax is just a convenient Ruby way of making a multi-line string) containing the Ruby code for the new method. It then evaluates that string as Ruby code. Instant method.

So if you call Car.add_destination('washington'), the string ends up being:

      def drive_to_washington
        puts "Good bye!" 
        puts "I'm driving to washington" 
      end

Evaluate this and you end up with a new method in the Car class called drive_to_washington.

You can also define methods a little more directly by using the (what else?) define_method method:

class Car
  def self.add_destination(dest)
    define_method "drive_to_#{dest}" do
      puts "Good bye!" 
      puts "I'm driving to #{dest}" 
    end
  end
end

There are some practical differences between the eval technique and define_method, mostly having to do with the visibility of variables, but at the very gross level they are the same: in both cases you end up with a new method without an explicit definition of that method in the source code.

Wrapping Up

So there you have it, a whole bunch of ways to connect that method call with some Ruby code. We saw that you that can do the traditional put all of your methods in the class or its superclasses thing, or you can define methods in a module and include the module in your class. Not only that, but you can also hang methods on individual objects. We also saw how you can catch calls to non-existent methods with method_missing or spread your method definitions in different files. Finally we took a quick look at metaprogramming, a way to cook up brand new methods on the fly.

If you are new to Ruby you may be thinking that the only possible reason that Ruby would support all of this variety is to drive the beginner nuts. I know that is how I felt at first. But every one of the more exotic Ruby method definition techniques has a purpose; Each one eases the burden of building programs in its own way. Want to know how? I think the best way to learn is to pick up your favorite Ruby book and start reading.

Russ Olsen

Fly the confident skies

Ever watch an airline pilot walk through the airport? They have a certain casual ‘I own the place’ attitude. The airline pilot attitude shows in the unhurried but purposeful way they stroll through the terminal, pulling their little wheelie suitcases. It shows in the confident way they settle into the cockpit and in the voice that they use when they ask the flight attendants to prepare for take off.  Pilots adopt that athoritative attitude because it is part of the job. When you place your bottom in seat 16A you are also putting it in the hands of the folks in the front of the plane, trusting that they know what they are doing. A serious part of being a pilot is to look and act like you are worthy of that trust.

As a speaker, you have something approaching that pilot-passenger relationship with your audience. They are putting the next 30 minutes or hour of their life in your hands and it is up to you to give them a smooth flight. And, as every pilot knows, the first step in a smooth flight is to inspire confidence. What this means is that you don’t slink to the podium: You  stride, like you own the place. If someone introduced you, take a second to thank them: You’ve got time, you are in control.  When you talk, talk five percent louder than is strictly necessary to be heard. You don’t just need to be heard, you need to fill the room. Don’t be afraid of silences either: If you want to make a point and think it will take a second to sink in, give it a silent moment before you continue. Above all, look people in the eye and keep on looking them in the eye. All of the practice (you did practice?) will help here: Since you know what you are going to say, there is no reason to keep looking at your slides to remind you where you are going next. You want to be locked onto to the audience for the entire talk.

And what if you don’t feel very confident? Well in the words of Leo McGarry, “Act as if ye have faith and faith shall be given to you. Put it another way, fake it till you make it.” Stage presence is a kind of bootstrap process: The more confident you act, the more your audience will respond, which will inspire actual confidence. Just keep reminding yourself that you are (literally) running the show.

What if an engine falls off?

If you do enough speaking, eventually something will go wrong. The PA system will produce feedback or a mistake in the schedule will direct people to the wrong room or the river will rise and wash away the projector. These are the times to take that airline pilot analogy to heart. If one of the engines on your plane falls off, you don’t want the pilot to panic, or sound rattled, or even to apologize constantly. You want him to come on the PA and say “Well folks, looks like we lost an engine and will have to set down on that tiny Pacific island back there. With a bit of luck you will all still make your connecting flights.”

If something goes wrong during your talk, mention it, and if need be apologize – once. Then move on. Your audience came to hear you talk about HTTP or the sex lives of Amazon beetles, not at how distraught you are over the bad lighting. Apologize once and just keep going. The good news is that the most likely source of trouble is the apparatus that you need to get your slides on the screen. But if you have practiced your talk enough, you should be able to get through it sans slides. In fact, one advantage of creating physical index cards (see part 1) is that you can drop the cards into your pocket on talk day. That way, if all Hell breaks loose on PowerPoint you can still deliver an old fashioned ‘peeking at the index cards occasionally’ style of talk.

The Secret Sauce

So there you have the things to keep in mind while you are doing your talk: No matter how intimidated you feel, act like you own the place. Focus your attention on your audience. If something goes wrong, admit it and just move on. Oh, and you will need to add just one more thing to your talk. Something we will look into next time…