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

So head over and check out the workflow site and read not only my fine fine article, but also the other news and podcasts he’s got going on over there.

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

Anyway, a great interview and well worth the read.

• Memory leak tracing in Ruby…. A bit low end for most “normal” users, but good info to know how to get when you do need it
• Older article but still relevant: and vs && in Ruby
• Phusion has posted part 3 in their Road to Passenger 3 articles
• Everything you need to know about RESTful web services
• The Perils of Opinionated Software like Rails
• A nifty screencast where @garybernhardt moves from Python to Shell to Ruby

Well, back with some links from the last couple of weeks anyway

• RSpec syntax takes a bit to get used to
• RSpec philosphies take a bit to get used to…. understanding the :before block, lets, contexts, descriptions, and subjects are all great, but it’s even better to have an idea about the best practices associated with them
• The overall idea of TDD.  Do you want to test the actions that a user is taking?  IE: “Create an object”, “alter an object”.  Or do you test each individual function in the system?  IE: new() create() destroy(), etc.  If the latter, are you expected to test all the functions you don’t create, ie: the built in object methods that you get when you have any class?
• How far do you take TDD if you’re just trying to get a 3 function class off the ground?

Luckily the test-driven @dkubb was there to help me out a bit, and gave me this nice setup to start with.  This let me see the proper (or at least how Dan did it) setup for where a context/let/description/etc block goes.  All good stuff.

Now I have a model (so to speak) I can work from, so now I can finally get off my ass and get some code written.  Dan’s philosphy is that if you code for more than a few minutes at a time you’re doing something wrong, and you should be testing, coding, testing, coding and then doing some more testing before you do more coding.