Hi everyone, I'm Chris Wanstrath.
When Jeremy asked me to come talk, I said yes. Hell yes. Immediately. But then I took a few moments and thought, Wait, why? Why me? What am I supposed to say that's interesting? Something about Ruby, perhaps. Maybe the future of it. The future of something, at least. That sounds keynote-y.
So why don't I just get that part out of the way. The future of Ruby.
In the future, Ruby will become... more popular. There will be more implementations. There will be more programmers using it. More machines with it installed by default. There will be more people writing blogs about it, and more people reading blogs about it.
I know this may sound kind of crazy, but you have to trust me. I'm keynoting.
There will be more RubyGems, and there will be more RubyGems servers. At least one, possibly as many as two, and it's conceivable that more than three new books will be written about it. Current books will be released in new editions, with more pages and more in depth information on new features.
New Rubyists will be younger, and current Rubyists will get older. Some Rubyists will get dogs, others cats. A few will remain dogless and catless, perhaps opting for children instead. (This is a common mistake, as, in my experience, children are much more expensive than either dogs or cats.)
Websites will be created in Ruby, using futuristic versions of Ruby on Rails and Merb. Versions like 3.0 and 1.0, respectively. New web frameworks will be created with strange names and stranger maintainers. We will come to know _why the lucky stiff as a less violent version of the Joker, matz guys as a more controlled version of Two Face, Dr Nic as the Penguin (he really loves fish), and DHH as our Batman. As for me... I am Iron Man.
New languages will come along, and they will become popular. People will continue to scorn Ruby, calling it names like "Python's Perl," or "Java for nerds," or even, God forbid, "Visual Basic for the web." (Technically, however, I think that role was already filled by ASP versions 1 through 3.)
Ruby will be taught in college, to young nubys eager to learn the ways of the master craftsmen. Most of the students will be drunk during these classes, others hungover, all hungry for knowledge.
Behavior will drive us and macros will help define us. Well, some of us.
Proc. Lambda.
There will be more conferences. People will speak at these conferences, sometimes about Ruby, sometimes not about Ruby. Speakers will wax philosophically about the glory days of Smalltalk... without actually having written any Smalltalk. Others will show benchmarks for their new, superfast Ruby VM. No, it's not open source and no, you can't try it out yet.
Someone will bring up a 2.0 version number, then quickly be hushed. Suit people will surround us. Tests will be mocked, and mocks will be tested. Or is that stubs?
Ruby will be fast and it will be slow, patches will be released that break backwards compatibility, and security vulnerabilities will be handled in a less than satisfying manner. Big websites will attract billions of visitors while little blogs will appear, amaze, then vanish.
Most importantly, Ruby will stay beautiful. At least, we hope so.
And that's the future of Ruby.
Did that feel keynotey? Let's talk about the past now.
John von Neumann was one of the great mathematicians of the 20th century. He made contributions to cellular automata, set theory, functional analysis, quantum mechanics, ergodic theory, continuous geometry, economics and game theory, computer science, numerical analysis, explosive hydrodynamics, and statistics. (I know about 60% of those words.)
He also helped invent the modern computer. The ones we're all using, right now.
In the 1940s, von Neumann and a group of, basically, geniuses got together to build a computer. It wasn't the first computer, mind you. In fact, 'computer' is a term once used to describe individuals who computed numbers.
Charles Babbage was such a computer frustrated by the fallibility of the human brain - when dealing with massive amounts of numbers, mistakes were common. For example, William Shanks spent 15 years calculating 707 digits of Pi.
Tragically, he made a mistake at year 11. His next four years were spent computing in vain and only the first 527 digits were correct.
Anyway, Babbage envisioned a machine that could carry out precise instructions and deliver accurate information. If machines could do physical labor, why not mental labor?
Guys like Alan Turing got in on the action and came up with ideas which would eventually produce machines such as ENIAC, the first programmable digital computer. While ENIAC was a breakthrough, von Neumann's architecture was different in an important way: it stored both program instructions and user data in RAM. Prior to von Neumann's ideas, program instructions, while modifiable, were stored separately from data.
Like I said, this idea (called the von Neumann or stored-program architecture) is what we use today. When you're writing your Rubys in your TextMates, both the Rubys and TextMates are stored together in RAM.
Having both instructions and data in memory together could be used to implement, as a primitive example, loops - branch instructions are modified as the loop iterates. In the ENIAC and others, these sort of transformations were done by hand, by programmers. (Oh, and the first programmers? All women.)
Anyway, in the second half of the '40s von Neumann and a small team got together at the Institute of Advanced Study (IAS) and started working on a machine based on his stored-program architecture. To be fair, it wasn't entirely his idea. Standing on the shoulders of giants, and all that. Also, Wikipedia claims that some British team actually beat his team at implementing a stored-program architecture computer.
But who cares about Wikipedia?
The IAS, where von Neumann's machine was built, was basically a dorm near Princeton, but not officially affiliated with Princeton, started by some philanthropists who wanted scientists to stay there, have their lodging and food paid for, and get their science on. Big time. Einstein was one of the first residents, as were von Neumann, Kurt Gödel, and J. "mother fin'" Robert "atomic bomb" Oppenheimer.
So this place held historians, scientists, and engineers. The engineers working with von Neumann on the IAS machine worked in the basement. Sound familiar? To this day, the basement is the IAS server room.
These guys working on the IAS machine that summer were both programmers and
engineers. They would solder the parts themselves, program the
programs, and fix bugs in both hardware and software. Actually, they
often had a hard time distinguishing between hardware and software bugs.
Is the code wrong or is the machine wrong? What a nightmare.
They used about 2300 Radio Shack-caliber vacuum tubes for switches and memory. Stuff would break constantly. They'd stay up until 4, 5am drinking tons of tea with tons of sugar. In fact, since this was during the war, sugar was rationed and they were using more than their fair share. The historians and other nerds in the IAS building were pretty pissed. (Sounds like me and my brother over Mountain Dew in high school.)
All the engineers kept notebooks, of course. Blogs. They'd write frustrated entries, only to have massive elated breakthroughs the following day. Their notes were being sent out to institutes all over the country so others could reproduce their work and create new machines with the von Neumann architecture.
And then they finished. On June 10, 1952 the IAS machine was fully operational. Others built similar machines (though none of the machines had compatible instruction sets - you couldn't yet write a portable program) at similar institutions, and the IAS machine then carried out its intended purpose:
Help design hydrogen bombs.
The first hydrogen bomb was detonated on November 1, 1952. It was called "Ivy Mike," detonated on an island in the Enewetak atoll in the Pacific Ocean, and was 450 times more powerful than the bomb dropped on Nagasaki.
So, mathematicians built the first modern computer to aid them in applied mathematics and hydrodynamics. These guys were true hackers working on what was a massive side project, and, in a way, the ultimate yak shave.
(Interestingly, this may also explain why everyone thinks you need to be great at math to be a programmer, but I digress.)
Today, that is, in the present, there are a number of high profile Ruby projects which began as side projects. Some of them might also be called... the bomb.
Rubinius now has five people working full time on it, but began humbly in 2006 as Evan Phoenix's side project. He wanted to build his own Ruby.
Ruby on Rails itself was extracted from Basecamp, which was a website the 37signals guys were doing on the side. At the time, they were a design firm and David Hansson was a contractor.
No one really knows what _why does with his time, but Shoes is certainly moving full steam ahead with no mention of monetary gain. Just for hack's sake, to make things better for people wanting to put together GUIs in their favorite langauge, for fun.
Merb started as a pastie, a thin layer on top of Mongrel to allow for fast, concurrent file uploads. Developers at Engine Yard now actively work on the framework. (Though I'm not so sure it can fit in a single pastie (or gist) anymore.)
You should always have a side project, too. Side projects give you an outlet, provide a useful distraction, let you explore new ideas, learn new concepts, and generally give you the freedom to be unaccountable. You don't have to worry about your boss, or your coworkers, or the damn commentators on Reddit. Just have some fun. Treat yourself.
After I dropped out of college, I worked at a PHP shop doing trucking logistics applications. We were a broker between independent truckers and big companies like KMart. Truckers would register on our website, say they're going to be in Delaware on the 3rd of May and that they're heading to Denver, then get information on shipments along their chosen route. They could then bid on shipments or accept them, all through us.
It was a fairly complex application and two things were missing: version control and constants. There was no version control, so you'd have things like main2.php and compute_radius_of_from_shipment7.php laying around. Along with versions 0 through 6 of that same file, in the same directory. Truly painful.
There were no constants and no configuration, so the source code was filled with magic numbers. If you wanted to tweak any of our algorithms, you had to find the code which did the computation and change some numbers by hand. Hopefully the correct numbers.
Naturally, the first thing I did was institutionalize Subversion. (I've apparently always been a champion of source control, though I didn't realize it until setting this story to paper.)
The second thing I did was start extracting the magic numbers into configuration files. At the time, it was a pretty common PHP idiom to use .ini files for configuration. Most of what you'd need was supported, and I'm pretty sure PHP came with a library (aka a shotgun blast of functions in the global namespace) that could understand .ini files.
This worked okay, but once I started tinkering with Rails I was blown away by YAML. So clean, so powerful. There was Syck, the C extension written by _why, but it was just that: a C extension. I didn't know much about loading C code in PHP, and even less about doing it on our production servers.
So I set out to write a YAML parser in PHP, on my own time. As a nod to Syck, I called it Spyc - S P Y C - a simple php yaml class. It was my first parser, was stateful, and I think did two passes for the reference / pointer stuff YAML supports. It didn't support all of YAML, but it supported most of it - both dumping and loading. The good parts.
I snuck it in and before long we were using YAML with great success at my company. Naturally, I put the code up on SourceForge. King of all online source code repositories. My designer friend made a page and in the first month Spyc was a huge hit. I swear it had at least 70 downloads. SEVENTY!
That was a big deal.
Fast forward about nine months: I realized the trucking logistics business isn't the beacon of progress or congregation of forward thinking individuals I had envisioned. After all, they hired me.
I quit and begun re-enrolling in school. This time I would major in Computer Science instead of English. My path was set.
But then, near the end of that summer, a friend IM'd me. A close friend I grew up with. He was into Digg and video games, but was far from a programmer. "Hey," he said. "Do you know MySQL?"
"Shit," I thought. I figured this conversation would be the modern day equivalent of said friend asking why Ruby sites are always down. Real time trolling.
"Yeah, I know MySQL."
"And you know PHP too, right?"
"Yes." I was dubious about the direction this conversation was headed.
"GameSpot is hiring. You should apply."
Ah, GameSpot. He and I were both into video games. During high school I worked at a local GameStop, and in college I worked at EBGames in the mall. I had all the modern systems and grew up with Atari, NES, Genesis, all that.
Gamespot.com was a site I had visited quite often while in high school and college. By the way, notice how different the names GameSpot and GameStop are - this would later cause my family endless amounts of confusion, thinking I had moved to California to work retail. The American dream.
So, when you Googled video games, GameSpot was usually #1 or #2 in the results. I knew it well. GameFAQs.com (that's game F A Qs) was owned by the same company, and probably the site I used most. It's basically walkthroughs, how-tos, guides... and cheats. Lots of cheats.
Anyway, I had no idea where San Francisco was or what the guys at GameSpot were looking for, but I applied. I created a brand new resume and stayed up all night working on the cover letter. By the time I was finished, it was a page long and pretty convincing.
In it I promised to move to California the next day, bringing nothing but my guitar and Xbox with me. My family would miss me but I was ready to leave, and I was hungry to show the world what I could do. Ready to learn from the masters.
The phone interviews went well, they liked that I was into Macs and Ruby, and I obviously got the job. My first time ever stepping foot in California was when I flew out to find an apartment with my dad.
My work experience wasn't what got me the job. I'm sure my cover letter had something to do with it, but my short lived career in trucking logistics was less than glamorous. I really only had one thing to show GameSpot - Spyc. My code was freely available, had been used in production, and worked. They could download it and play with it, or check it out online. Regardless of whether or not they thought it was good, they could tell it was clean and well thought out. Well, maybe not, but I had a website and 70 downloads.
So I got the job at GameSpot, in my mind the first big step in the path that brought me right here, thanks to my open source side project.
Something I learned from that experience is that you don't need to make money from code to make money thanks to code. I didn't make money off Spyc, but I made money thanks to Spyc. (Also, it got my name in a book. But that's a different story.)
So that was pretty cool, and I thought unique, until it happened again. While I was working on GameSpot, I was doing more and more Ruby on the side. I had an open source Rails tumblelog called Ozimodo, a crappy FTP server called ftpd.rb (which I used as a way to learn about threading), and a command line option parser DSL called Choice. For Choice, I had a full test suite (I wrote the thing to learn TDD) and an RDoc generated homepage on Rubyforge.
When CNET, GameSpot's parent company, acquired Chowhound, they decided to rewrite the site in Rails. Classic. They brought on two Rails programmers from Wayfaring.com and were looking for another. They found me.
I later found out my RDoc site, Ruby gem, and test suite proved to the Wayfaring guys I was a "real" Ruby programmer. They wanted someone excited about this stuff, and I certainly was.
So they threw a bunch of money in my face and convinced me to work on Chowhound. Thanks, again, to open source side projects.
This happened to me twice, so it's not uncommon. Open source can make wonderful things happen for you, and not just financially but socially too. At Chowhound I met PJ Hyett, a GitHub cofounder and coauthor of Err the Blog.
So, start a side project. Who knows where it will take you.
Do you have one now? If not, why not? Not enough time? No ideas? I think I can help with both of those.
First off, the time issue. I don't know how many of you read RSS, but I challenge you (that's a keynote term) to give it up for a month. Just turn it off. Stop using Google Reader or NetNewsWire or whatever the kids are using these days. It's not worth your time.
What should you do instead? If you use Twitter, try following the authors of your favorite blogs. Read their tweets on the bus. Or in the bathroom. Check Ruby Inside once a week and skim over the posts. Visit an aggregator like planetrubyonrails.com once a month. But mainly, let other people do the filtering for you. Use your time for other things.
You will not miss out on anything big. Stuff like the Google App Engine, or Rubinius running Rails, or the killer speaker line up at this year's Ruby Hoedown will find its way to you. How can it not? I'm willing to bet a lot of the stuff in your RSS reader is stuff you already knew, or heard about somewhere else.
Personally, I used to check RSS multiple times per day. Now I don't use any reader, and haven't since January 2008.
Another big time sink among programmers, I've found, are books on process and theory. Books like Smalltalk Best Practice Patterns, Practices of an Agile Developer, and even, I dare say, the Pragmatic Programmer, are not worth your time. Instead, listen to Rein's talk. Talk to your friends or coworkers. Let other people filter the information for you, then decide what you like.
The best way to learn about patterns, idioms, and best practices is to read open source code. See how other people are doing it. It's a great way to stay current, and it's free.
(I really wish someone had told me this before I bought and read Head Start Design Patterns. The whole thing.)
Next implement the Jerry Seinfield GTD method. Every time you work on your side project, mark a big X through that day on calendar. Eventually you'll have a nice line of Xs. Missing an X will be torture - it'll mess up your beautiful streak. The goal is to maintain the streak, even if you don't think you have any ideas for the day. The best way to overcome writer's block is to write, after all.
Okay, so the time excuse is gone. Now you have time to work on a side project and the motivation to do it consistently - the beautiful line of Xs. You can devote at least one Sunday a month to it, at least. But what's the idea?
This is actually the easy part, because you don't need a good idea. Just start doing something interesting. Play with a new framework in Ruby - I hear Sinatra is pretty hot these days. Learn how to do GUI stuff, with Shoes.
Learn JavaScript. Like, for real. If you don't know what the var, with, or delete keywords are, get a book and start working on some flashy effects. Or download Rhino or Johnson and write some server side JS. It's a really beautiful and misunderstood language.
Take some time to master your editor. Pick up the TextMate book and dive in. Write a bundle. If you're already got massive Vim-fu, try out Emacs. Learn why people love it, then use that information in your holy wars against them.
Write a web service. Something like Cheat, Subtlety, Disqus, or TwitPic - tools someone can use to help make running a blog, site, or coding simpler. Simple sites that do one thing very well, and surface their information with digestible APIs.
If you've been meaning to learn a new language, start learning it. But don't just read a book. Start writing a program.
Learn Objective-C and Cocoa. Write a little Mac app to do something useful, then give it away for free. Post the code on GitHub. Put up a Pledgie badge and accept donations. Profit.
Write Rake in a Lisp. It's a good way to learn about metaprogramming and how command line scripts work in your new language. Write an RSS parser and explore native data types in Erlang. Write a simple blog and learn about the web frameworks in Haskell. Write Scrabble in Io, picking up some OpenGL along the way. It doesn't matter if people have done it before.
In fact, stop worrying so much about other people. Every time I've worked on a project I thought other people would really love, it was a massive flop. Every time I've worked on a project I loved, it worked. If you're sitting in this room, your taste is not as far off from those around you as you'd think. Build something you love and others will love it, too. (Not everyone, of course.)
Alternatively, do something hard, the hardest thing you can think of, in your language of choice. Stretch the boundries. Make Ruby cry out in pain. Install ImageMagick. Rewrite all of the standard library. Write an Objective-C bridge. You know, something just devilish. Flex your brain.
Work on your small project for a few Sundays, declare it complete then move on. Learn another language, or write something else in your new language. Pick up a new web framework or work on flashy effect number two. Add concurrent task execution to your Rake. The more acclimated you get to this process, the more creative your ideas will be. It's the whole 10% inspiration 90% perspiration thing, and it worked for me.
This, after all, is how GitHub was started. Tom and I had full time gigs, but we'd get together on Saturday, have lunch, then work on GitHub. We wanted a pretty and simple way to share Git repositories. Something we'd use. Something that would make it easier for us to share and work on open source.
Now we have three people working on the site full time, thousands of paying users, and tens of thousands of repositories.
But it wasn't an overnight eureka, and it wasn't intentional. I didn't just walk out of high school, pick up a Ruby book, meet Tom and PJ, then launch the site GitHub. Before GitHub came, in chronological order, Spyc, Ozimodo, my ozmm.org tumblelog, ftpd.rb, Choice, Err the Blog, acts_as_textiled, Cheat!, acts_as_cached, Mofo, Subtlety, cache_fu, Sexy Migrations, Gibberish, nginx_config_generator, fixture scenarios builder, Sake, Ambition, and Facebox. And that's just the stuff I released.
The more side projects I had, the more I felt the pain of maintaining open source code.
If you already have a job you love, this doesn't exclude you. You probably use, day to day, many side projects from others. You can also use your own side projects at your job. From Emacs configs to simple web services, there are a ton of things you can do to stretch your brain.
I had no intention of leaving Chowhound when I wrote Cheat - I just wanted to make it easier to look up commands I rarely used. Things like TwitPic or Twictures have nothing to do with anyone's job, they're just fun and make life on the Internet a little bit more enjoyable. Ruby on Rails may have a financial angle, but if there's money to be made in Shoes I'm not sure I see it.
My plea to you today is to start a side project. Scratch your own itch. Be creative. Share something with the world, or keep it to yourself.
Side projects are less masturbatory than reading RSS, often more useful than MobileMe, more educational than the comments on Reddit, and usually more fun than listening to keynotes.
Thank you.