#yakshaving

i did a step or two of troubleshooting for most of these problems: we replaced the vacuum with a cordless one, we moved the baking dishes from the nitemare cabinet to an open shelf, i switched from harpoon needles to subcutaneous. 

but i still rarely did the things i was supposed to do, so i thought it must be that i’m just lazy.

we moved two months ago, so it’s unclear how much is me being on my best behavior still, but i’m vacuuming at least once a week, taking out the garbage at all, the bathroom sink is pretty clean, my injection is never more than a day late, the baking dishes are neatly stacked, our room is much cleaner.

it’s weird: i’ve confirmed with cohumans that it seems we’re spending less time cleaning, but the space is baseline-neater than it used to be.

I gained a lot of experience back in 2010 by helping my buddy Caike launch the OrlandoDojo. We kept the fun going for almost a year and a half before having to call it quits on our regular-like-clockwork, every-other-Saturday dojo sessions.

Nonetheless, one of the pain points we discovered early on was in setting up the boilerplate for each of the dojos. For those who aren’t familiar, the rules of the dojo are pretty simple:

Pick a Problem: Project Euler, Daily Programmer, and CodeKatas are a good start. Despite what Uncle Bob might say, avoid bowling.

Pick a Language: It’s always fun to try a tried-and-true problem in a new language but make sure there are some people on hand that understand the language you pick; i.e. know it well enough to solve the problem already.

Pick an Implementation: This is where things get interesting. In the aforementioned attempts at bowling, all we managed to uncover in two hours is that no one knows how to actually score bowling. That information has apparently been lost to the droids. However, discussing the problem and its implementation led to some interesting places.

There are some additional rules to help control the fun, as my A-type friends like to say: red-green-refactor (there’s a hat for that), pair programming (pilot-copilot), just to name a few. However, we found that after all the discussion, we ended up killing a reasonable chunk of time just setting up the environment for us to start writing tests! Total buzz kill!

I’ll have my yak pre-shaved, please.

Eventually, I started capturing our setup routine and pushing it into a Github repo... Mostly because I’m lazy. Don’t get me wrong, there was a lot of value in demonstrating the testing setup and that ran the tests auto-magically for us while we happily coded away. That 30 minute interruption, though, really choked the momentum, and we found ourselves asking more than once, "So, uh, what were we gonna build?"

That, as I said, was 2011, and we haven’t had a regular dojo since. I still run occasional dojos at the OrlandoPHP user group when I don’t have a speaker lined up, and I hope to get some Coding Dojo groups started up at the local colleges one day. The state of the dojo union is not strong in Orlando at the moment, and my old environment setup was looking a little dated.

Now with more Future!

Being a (somewhat) proactive sort, I decided to update my toolchain a bit. I don’t currently use watchr anymore, as it was deprecated a while ago. Most of the Rails folks are using the heavily-integrated-with-Rails guard gem, and the gazr gem replaced my old friend for Ruby >= 1.9.3, it seems.

As I’ve made a transition to more JavaScript tools, I’ve taken up the use of ~~Grunt and grunt-contrib-watch plugin~~ (EDIT: I'm all about the gulp these days, which has file-watching built right in) to "just do things" when a file changes. Y’know, like when I want to re-run all my tests… Or just the one for the corresponding file… Wait, this sounds familiar.

So I picked up my old xUnit Environments repo on Github again and refactored mercilessly! The result is a simple, one command method of running tests for four different languages — PHP, Python, Ruby, and Javascript — whenever a file change event occurs and some decently modern boilerplate for running tests with the built-in testing facilities, where possible (PHP is still a notable exception), e.g. unittest in Python and Test::Unit in Ruby. (EDIT: Yes, I know simpletest now... Time for more updates!)

You’re welcome.

I know, I know. Those are probably NOT the tools you’re used to using: “Where’s RSpec?” you cry, “Ever heard of Jasmine? What, no BDD?” Yes, yes, I’ve heard of all of those things, and if you want to use them in your dojos, you probably know how to fork repos and install gems and customize the ever-loving snot out of this tiny kernel of an idea that I pieced together so that I didn’t have to do so much yak shaving every other week when I gave up my Saturday to teach people how to write test-driven code.