www.talios.com

For the past few months we've been recording the Illegal Argument java podcast and I thought I'd write down some quick thoughts on the tools/setup we're using.

The first ever recording (not publicly available) was recorded directly to internal mike of Richards Macbook Pro into Garage Band, unfortunately the internal microphone is located right next to the Mac's fan, so every so often you'd hear the fan kick in.

Following that first recording, we purchased a Blue Snowball USB microphone and recorded direct to Garage Band. Immediately we found the sound quality of the recordings improve, however we also quickly discovered Garage Bands 2gig file size limit after recording for 2-3 hours in one sitting. Unfortunately, given that we now had 3 people sitting around the mike talking, with the Macbook behind us on Richards desk meant no one noticed that recording had stopped.

Around episode 7 I purchased myself a Zoom h4n from Samsontech, whilst not cheap this external "field recorder" is probably the best gadget I'm purchased in a long while (the HTC Magic coming a close second).

The Zoom H4n is a portable, hardware based 4 track recording device that uses SD/SDHC memory cards for storage and can also operate as a USB hard drive. Our initial recordings just used the built in microphones, and the (now) four of us sat around the device talking as normal.

Following Antony's jaunt back to London and the Netherlands, we've now added Skype, the Belkin headphone-hub, and the Zoom's 4-track recording mode to the mix:

• A 3.5mm to 3.5mm (with 6mm adapter) 'headphone cable' from the Macbooks headphone jack plugs into the XLR channel input at the bottom of the Zoom.
• The belkin headphone hub is plugged into the Zoom's monitor port.
• Three headphones used by 3 podcasters locally plugged into the Belkin headphone hub.
• One 3.5mm to 3.5mm cable plugged into the Belkin headphone hub and the Macbooks line-in port.

This setup now gives us the ability to record any audio coming from the Macbook, and feeding our reactions back in, allowing us to record any skype conversations or audio played on the computer.

For audio editing we're using a combination of Garage Band from Apple, Fission from Rogue Amoeba depending on who is mixing/editing each episode.

For a while I've been an avid lover of the concordion testing framework, but one thing I always struggled with was the separation of state/data between the specification and the fixture. As a simple work around I added a simple "eval" command, which simply takes an elements content and turns it into a camel cased method name to call on the fixture.

When using a specification marked up as:

a specification with the following methods is exercised:

The result is a very lightweight specification that contains no state, data, or scripting in it, and by sticking to a single command, I open myself up to driving concordion from a simple wiki syntax without having to worry about how to encode all the various commands.

The eval command itself is fairly simple:

I have some ideas to improve further on this (stealing from Cucumber) to extract any numbers, or strings in quotes as parameters to the evaluated method which should add even more value to these extremely simple specifications, along with a similar "echoeval" command to insert content from the fixture into the rendered specification.

I'm sure a lot of people might cringe at this way of writing tests and specifications, but I'm finding I can very quickly jot down a sentence or two about something I want to test as it occurs to me in the form of a specification (rather than a TODO comment or JIRA task) and immediately have it fire up as a failing test.