Anyone in the Ruby community probably knows about Why The Lucky Stiff and his numerous contributions to Ruby and the Ruby community[0].  They’ll also know that a while back _Why decided to disappear, removing his code, sites, and closing down his various accounts.  In celebration of what he brought to us Today, August 19th is Why Day, in which people are encouraged to:

• See how far you can push some weird corner of Ruby (or some other language).
• Try that wild idea you’ve been sitting on because it’s too crazy.
• or others….

One thing I know you can do is to use Skype to call “coderpath” and leave a message about what you think of _Why and Why Day.   Call coderpath’s skype (you of course need Skype installed and a Skype account…).

If you’re looking for a reminder of what _Why brought to the community, you can check out whymirror on github, where most of _Why’s various projects have been restored and preserved.  Most special though (in my opinion anyway) are:

• TryRuby – running ruby in the browser, like IRB
• Why’s Poignant Guide To Ruby – The man, the book, the legend.

This is probably old news to everyone who reads this, but today I had a bit of an epiphany.  I was watching Charles Max Wood’s excellent Teach Me To Code Screen-cast and realized (after watching two parts of his “building a blog” series) that he wasn’t ever actually looking at the output of his coding, at least in the traditional sense.

The way I’ve coded since, well, forever has been like this.  I open up my editor window, and an output window.  When I was writing C code back in the dot com days this was another terminal with a “make && ./app” in it, and in my newer web application days, a browser window with my mouse hand on the reload button. After a bit of code was written, I’d either hit “up-arrow enter” for C code or reload the browser, and see what’s happened.

Watching the screen-cast I realize that Charles was doing the following (as far as I can tell, as I’m pretty new to the whole TDD thing):

• Writing a scenario or feature (using cucumber)
• Using that to generate tests (with rspec, I think)
• Running the test, watching it fail
• Writing the code to make the test pass
• Running the test, watching it pass
• Repeat…

Now the last four steps I do know about, those are standard TDD methodology, broken down into Red (write a failing test), Green (make it pass), Refactor (make the code better), but I was blown away with the realization that he wasn’t looking at the output of the code he was writing, but instead was letting the testing framework do the work, so instead of having to verify with your own eyes that the [insert web page you're interested in here] is showing properly, you have it checked programmatically, no browser needed (in fact, at the point in part two when the browser is needed, there’s that uncomfortable pause while FireFox groans and raises itself into a running state).

Is that what TDD is really about?  I’ve always imagined it as an augmentation to the previously-described way I used to code in that before I coded and reloaded the browser window you’d write the test, then the code, then the browser reload, then the test again to make sure it passed.

This is a whole new world that’s frankly thrown me for a loop, and into a fervor of reading up on cucumber.  I’m not sure how this will affect my code writing, but this makes the whole world of TDD a lot more interesting!  Course, I’ll have to re-watch the two episodes to make sure I truly grok the tools that he’s using.

Further Reading / Links

• Part 1 and Part 2 of the screencast in question
• Teach Me To Code Screencasts (TMTC hold two coveted places on my list of programmer podcasts)
• @teachmetocode and @charlesmaxwood on Twitter
• The #teachmetocode IRC channel on Freenode, come by and hang out and chat

You may have noticed that my ‘blog 6 days a week’ has lately been kinda lax lately, but I finally, finally, started work on Ruby-idioms.com.  Nothing out there public yet, but I’ve finally found the time and energy, and quite frankly, got through that old friend of mine, fear of getting stuff done instead of watching TV and reading RSS feeds, and actually got some code down on… uhm… an editor.

I figure that it’d be a good idea to start blogging the experience of building a site from scratch with Rails by a newbie (not that there aren’t a hundred of those already).  Read My Code was done in 24 hours, I figure a week or so, or heck, a day or two per feature, ought to be enough.

I started by breaking things into some steps:

1. Create the Idiom scaffold, model validation, etc
2. User authentication and login
3. User integration (edit your own Idioms)
4. Site layout, look and feel
5. Commenting
6. Tagging
7. More site layout stuff (I’m thinking this might be the hardest part for me, as I am a programmer and not a designer for a very good reason

That’s of course a bit over simplified, and I’m probably missing out something huge, but that’s the current attack plan.  All things are flexible of course.  My grand plan is to code one day, blog the results and anything interesting or challenging that I find. I’ll make sure I push things up to the GitHub project page as well.

Well, it didn’t work out for me this year, but a few of my buddies from the FV.rb are over at RailsConf right now, having a good time I’m sure.  I’m sure that @milesforrest, @djbell, @krutten, and whomever else is there is having a blast right now.  You guys better bring back schwag, pictures, and good stories for next week’s meeting.  Also a thanks to the RubyMine guys over at JetBrains for throwing me a T-Shirt.  I’m not sure if they were giving them out to everyone, but they did say to send someone over, so I did.  Thanks guys!

When I came to ruby I knew that in Ruby Everything Is An Object, but until I started writing “real” code, I didn’t realize that the Ruby world works that much better if your code is object oriented as well.

Case in point my simple Twitter to HTML program.  When I first wrote it, it was pretty much written from the point of view of where I was at, a old and functional programming Perl coder.

So what is the difference between the styles of functional programming and object oriented programming?  For me, this meant that I was basically writing a program with no classes defined with a top to bottom program flow.  There was a “main()” (if you are familiar with C programming) which basically ran a set of functions and then ended.

Ruby itself discourages you from doing this.  There isn’t (as far as I can tell) the concept of pre-defining functions, so you have to write functions that you use before you use them.  So if you have a line that calls “foo(x,y)” you have to make sure that you have foo() defined above that in the program.  and if foo() calls bar() then bar has to be defined above foo(), and so on.  Not fun if you want to make your source code readable and nicely laid out.

Once I let Ruby’s object oriented nature take over a bit though, and defined the functionality in a class, and then just created an instance of the class to do foo() and bar() operations, it didn’t matter in what order code was assigned in the file, because the entire class is parsed by the interpreter before anything is done to it^*.

^* I’m sure this isn’t 100% true from a compiler / systems design point of view, but for the end user that’s basically what it looks like.

So what else does this give you, or more specifically, force you to do? Well, lots or Rubyist type things.  This encourages you to…

• create your programs in terms of data types (“this is a thing”)
• group functionality together (“this thing does these operations”)
• create objects that function together or off of each other (“this thing is a sub or superset of this other thing”)
• ensure your methods play nicely (ie: method chaining)

As many have said before, you can write bad C code in any language, but I had to come to the realization that just because I was writing in Ruby didn’t mean that I didn’t have to change how I was programming to take the most advantage of it.

Not that every program needs to be “objectified”, that 10 liner to parse out some some text and insert it into a database probably doesn’t need to be split into 2 modules and get 100% code coverage, but then again, maybe you’ll re-use it again next week, or maybe it’ll turn into the central convert-everything utility program for your job, and if so, wouldn’t it be nice if it was OO and tested from the start, instead of having those “extra” bits of safety tacked on after it becomes apparent that it’s more than just a quick and dirty little hack?  (For me it’s happened way too often that I don’t realize this until way too late….)

Browsing the twitters this morning I found a couple of high end posts from Peepcode that I thought deserved some attention (assuming everyone in my audience isn’t hitting their blog on a regular basis already that is):

• First is the Live Blogging a Rails 3 Upgrade.  I think I saw one of these somewhere before, maybe on RailsCasts, but the closer Rails 3 gets the more you’re going to want to see these so you’ll be that much more ready to do the upgrade yourself.  Now this is a post from February I realize, so it’s a couple of months old, but still looks great and is still very relevant.  Well worth the 25 minutes to watch TopFunky do his thing.
• Second on the list is an actual new post, entitled Am I The Only One To Use a Text Editor To Edit Files, listing out some requirements and what’s available for file navigation and searching in editors today.  In a twist ending that I’ll ruin for you here, the resulting list of features has morphed into a real application that works with a host of the favorite editors for the Mac.

Great stuff all around, both blog posts (as the Peepcode blog always are) look beautiful and are amazingly laid out with great graphics and typography.