August 19, 2008

Skreeming with foxytunes

I was recently introduced to Skreemr (http://skreemr.com). An mp3 search engine that serves up mp3 from blogs. It's a neat way to sample music and check out stuff as you hear about it (among other nefarious things since you can download the songs as well.

I heard there was a player that would allow you to play a list of songs you retrieve in your search but I didn't want to download any new player. Then as I was checking out some Gorillaz tunes I saw that I had a little widget in my browser, when I started messing around with it I realized it was a part of one of my favorite Firefox plugins: foxytunes. It allows you to play all the songs in a web page as a single playlist. heres a screen shot:


until next time
Les

August 1, 2008

TDD: Prove what you know

Accepting the concept of TDD (and yes I mean test FIRST development) was a tough task for me. At first I didn't understand the complete benefit, honestly I can't admit that I do completely now. But I've come around none the less.

When working on a project it is pretty much impossible to deliver code without having a bit of an understanding of what it is the end result of that code execution should be. The user doesn't care about implementation. All the end user knows is that when they submit this data in that field then something specific had better happen as a result. I didn't really grasp how that was a reflection of what test first meant.

Now I like to think of the end user and my unit test as the same thing. Both are simply executors of my code. I can't know what the system is supposed to do unless the end user tells me so. At first that was all I saw. The user says so and then I code the implementation, then add some tests. Now I see that if the user tells me what the requirement should result in I replicate that in a test, and that proves without a doubt that I understand the requirement. If you don't understand it enough to write a test for it then you sure as heck don't know enough to write code to implement the requirement.

Not only does this help you better grasp the requirement before diving head first into coding, it also gives you an upfront contract that is based on vernacular communication. That adds a quality check. If you write the test first based on what you understand the requirement to demand then you write the code to satisfy that test and hopefully you don't write any code outside that (unless necessary, remember to use your head but remember to prove any code changes with tests for quality assurance).

So as long as it's sane I'd like to set a rule for myself for future coding:

If I don't understand enough of what is required in order to write a test
then I don't understand enough to code period.

Keep me accountable.
Until next time
Les