Articles Feed

Something new, every day

by: eric | June 26th, 2007 | 0 comments »

Last December I went to to StarEast in Orlando because my fiancee is a tester and I well, I like sun. While there I picked up the book Practices of an Agile Developer and was particularly struck by the practice to keep a “Solutions Log.” The way a solutions log works is simple. Every time you find a solution to a problem you write it down, and later when you are confronted by a similar problem you have a reference. “Gee Whiz what a great idea!” I thought to myself, because I think to myself like Beaver Cleaver, “this way when Jim asks me about that bug I solved two weeks ago, I’ll know exactly what to tell him, instead of saying “uhhh, err, yeah I sorta kinda remember…” It really was an amazing revelation, seeing as how I hadn’t met Jim yet.

Then I got home and subscribed to Venkat’s blog where he recommended TiddlyWiki for keeping this list. If you’re unfamiliar with TiddlyWiki it’s an extremely cool browser-based personal note-taking tool that works entirely via JavaScript and CSS. You fire up your personal version of the html file, double click, and viola! there you have a note saved into the very document. Best of all it’s searchable even via regular expressions and plain text. With this tool I was gonna be a solution mastermind! People will ask me for that bug I fixed 14 years ago and I’ll be right there with my genius hat on and everything. You do have a genius hat don’t you?

How did it work out? Roughly 18 months later I have a whopping… 16 solutions, most of them written in the first week. You know what I learned from this? I suck at keeping a solutions list. The thing is I have no idea something is a solution to a recurring problem, until I come upon it a second time! What I need is a way to psychically determine what the solutions I’m going to need in the future are, and identify them. Um….

I’ve decided on a different option, which I think fits in well with the craftsmanship approach of perpetual learning. Since joining 8th Light I’ve been lucky enough to learn enormous amounts in a short amount of time, with more on the way, but of course none of this is in my solutions list. So instead of catching the realization that something is a solution, I’m going to write it all down. I’ve created a new list, and instead of calling it a Solutions List, it’s my LearnANewThingEveryDay list. Every day I’m obligated to write a new note with something I’d learned that day. If a day goes by and I haven’t learned something, I have to go learn something. I’ll read a book, find a great blog posting, try out a coding exercise, whatever. For example today I have written down some things I didn’t know about routing in rails. Mundane stuff that people more experienced with routing already new such as the :path_prefix parameter. What would be an otherwise fruitless day debugging now has a few little things I’ve learned from it. Will I ever search for that item? I don’t know - but the point is I can, so when Jim asks me how to get eric/is/the/coolest/blogger in front of all his links, I won’t stand there scratching my head.

Test Driving Module Methods - part two

by: eric | June 15th, 2007 | 0 comments »

Ever write an entire blog post, spend significant time on it, correct it, and eventually grow to love it - only to discover two months later you did things the hard way?

That’s what I’ve just discovered about my post Test Driving Module Methods. Turns out I’d been missing an important feature of RSpec, the and_yield command. Whereas previously I had written static methods and monkey patched the SFTP, I simply could have written:

    @mock_session.should_receive(:close_handle)
    Net::SFTP.start.should_receive(:start).with("test_server", "user", "password").and_yield(@mock_session)

That lets me test that the session I’m passing in is getting the right parameters like any normal code, and is far cleaner. Frankly I should have added the feature to RSpec for my original solution - if it didn’t already exist that is. Too bad about my lovely blog post - I guess I’ll stick to push-ups.

Pair Me Up

by: paul | June 14th, 2007 | 15 comments »

I am a better pair than solo developer. For me, software is a collaborative art from the start to the end. Starting from the beginning of a project, where the developers need to collaborate with the customer s and stakeholders of the project to learn about the business domain. Then working with the project manager for sorting priorities and deadlines to make the business goals realizable in the fastest amount of time. Also development is collaboration, via pair programming, to produce a dialog between the developers on their vision of the implementation of this code. The last part, pair programming, is what I would like to focus on.

Having a pair has the traditional advantages of keeping disciplined and sharing the knowledge base. That is a starting point, but pairing is quintessentially important to my process due to the diversity it provides. A diversity of approach and implementation provide me with enough to perform at a highly creative and expressive manner.

Since you are not driving the keyboard and control of the computer, there is more time for contemplating code you wrote and direction you are moving. Most of my good ideas come from the time when someone else is typing. Since I was just working on the practical, I have my head wrapped around the code, and since I am not responsible for typing, I can reflect in the abstract.

I have heard many places that a benefit of test driven development is that the tests force you to design the API of the objects you are using as someone would use them. Well, pair programming, in compliment with programming ping-pong, forces your code to be clean. When you write a test, it isn’t you that makes it pass, so you have to think with expression and intent in mind. So, you end up writing the test FOR your pair. It becomes a form of writing, not just coding.

Sometimes, the test needs to be explained. While explaining something to a pair, your test must hold up your own arguments. Often times when I come to explain something I just wrote, I think of a better way to do it. Explanation is the best form of validating you understand where you are going well.

Also, pairing is how I learned most of my developer personality. Taking bits and pieces of the traits of my pairs through years of pairing. My style is a composite of pairing with various mentors and peers of mine. It has shown me how people approach this craft.

No really, we do that?

by: eric | June 5th, 2007 | 3 comments »

I’m a bit overdue on blogging, so in lieu of the normally brilliant and insightful commentary on the state of…er something… I usually put here I thought I’d share something that we at 8th Light have started doing.

Push-ups.

Every hour. Yes I realize it’s nuts, but look at a typical day for me. Wake up too late. Rush to get ready. Get distracted by something on the computer (today it was RubyCocoa). Realize that I won’t make it to the gym in time to lift weights. Work too late. Come home, eat, maybe help my future step-children with their homework. Suddenly it’s 10, and I haven’t worked out.

Aha - but I did 150 push-ups today. I think - I don’t actually count. Here’s how the 8th Light Fitness Plan (published Spring 2008) works. Every hour, on the hour, do push-ups. We started at 10 every hour and that was pretty hard once upon a time, now we’re up to 25. Well most of us. Today I saw two of the guys in another part of the building doing them, and I figure that if it caught on amongst 8th Light it can catch on elsewhere. After all we’re not that weird. Are we?

####