defunkt · August 20, 2008 20:30 · minouye · Aug 25, 2013 · alexanderlperez · Oct 24, 2013
diff --git a/gistfile1.txt b/gistfile1.txt
 # Video: http://rubyhoedown2008.confreaks.com/08-chris-wanstrath-keynote.html

 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.