In late September 2007, Dan Sandler had started egging me on to develop a simple audio recorder. I was well within shipping mode for FuzzMeasure 3.0, and couldn’t do much more than talk about it at a high level.

In late November 2007—just before FuzzMeasure 3.0 shipped—Dan and I started talking more seriously about this simple audio recording application that just had to be written. Wrap up the Audio Queue Services API in Objective-C, add a great UI to aid in collecting the tapes, and it shouldn’t take very long at all, right? :)

By mid-December, Dan had some UI sketches which resemble what TapeDeck looks like today. There’s a ‘current’ tape in the player, some cassette recorder controls, and a list of tapes in a box. I had already built a prototype recorder by this point, complete with a tape, rotating spools, and an audio level meter. It looked nothing like the application we shipped. You could record audio straight to m4a files, and it worked fine. Effectively, at this stage, we were running Apple’s sample code with a UI on top.

Over the holidays, I spent a few days implementing the nuts and bolts of the early UI prototype. I wrote the UI a few times using Quartz, then Core Animation, then Quartz again. I probably wrote the bits that rendered the tape and its labels three times during this period.

In January, I had been busy with my job, and planning to leave (because FuzzMeasure was doing great, and I thought we had a real winner on our hands with TapeDeck). However, in every spare moment I could get, I would squeeze in fixes for FuzzMeasure, and code for TapeDeck. It was during this time that I decided I should get started on writing MP4 tags to the recorded files.

This was an extremely complicated undertaking, since Apple doesn’t provide an API to modify metadata on M4A files! So, I ended up writing an entire Objective-C library that is capable of parsing, and manipulating MP4 atoms (or boxes, depending on who you talk to), with the addition of the magic bits of metadata that work in iTunes. This was a very difficult piece of the TapeDeck puzzle, and it was fun to get working!

In early February, I left my job to work on SuperMegaUltraGroovy full-time. I spent some quality time with FuzzMeasure, cleaning up some bugs, and took a bit of a vacation from TapeDeck work.

By late February, Dan had sent me a mockup that looks very much like what we see today in the shipping version of TapeDeck. Initially, I wondered how on earth we would implement this–custom UI code, custom window drawing, etc. It seemed like a nightmare, but I put my head down and went for it.

Throughout March, Dan worked on our type logo for TapeDeck, and refined our plastic cassette rendering. I had the UI starting to look very much like the prototype at this point. Lots of work was done internally to support the box of tapes, and manage the collection with Core Animation–the UI that was written over the holidays was reworked again!

In early April, I had started playing with the speaker grilles. In order to really get the look of a cassette recorder right, there had to be speakers above the area where the tape sits. We had a few mockups with the speakers sitting somewhere between the tape and the controls, but once I drew up the grille pattern you see today, we had a winner. When the tape box was closed, TapeDeck really looked like a cassette recorder. Also, adding height meant the user could see more tapes at a glance, which was a nice end result.

By mid April, TapeDeck looked very much like TapeDeck 1.0 does. We were tweaking all sorts of the UI, and finishing off the functionality. The Design Awards deadline was announced, and I openly wondered if we could ship on time. I figured we might as well go for it, because external schedule pressure is always effective to maximize my use of time. :)

During this period, I got to the part where we wanted to implement seeking and FFWD/REW functionality. This is where my use of Audio Queue Services had to end. We wanted our tapes to play very quickly when seeking through the tape (in both directions!), which meant we had to do some trickier things within the audio stream. So, I took a week to rewrite the audio playback engine so that we could support full FFWD/REW functionality, as well as the accurate seeking of the audio stream.

I also decided that we really had to render an accurate image of the tape in the album art of each m4a file. This was an interesting thing to pull off using Core Animation, but the results were amazing when it was done.

In late April, TapeDeck began its beta. Tons of feedback came in, and we actually added the pause functionality in response to user feedback. I was coding at an amazing level of efficiency during this time.

Dan sent a mockup of a new HUD layout (recording and playback controls) to me on Friday, May 3rd, and I didn’t receive it until I woke up on Saturday, May 4. When I went to bed that same night, I had implemented the entire thing from the ground-up using Core Animation, borrowing bits of code from the old HUD. A great deal of this incredible implementation speed is due to Dan’s amazingly detailed mockups. He had effectively written a full specification with clear instructions about how each component would behave, alongside the detailed drawings.

In the last stages of the beta, tons of little bug fixes went in, and smaller aspects of the UI were cleaned up. Dan quickly put together our launch website, and threw a little easter egg into TapeDeck. We were smoking towards completion, and by May 8th I felt we’d done the impossible – we made it to 1.0!

I sent a copy to a few key folks in the media, and they all seemed to really like it! From there, the launch has just been incredible. We’re getting a lot of really positive feedback about TapeDeck, and we’re very proud of what we’ve done. You will find a tally of our media coverage in Dan’s blog post about TapeDeck 1.0.

Introduction

Improving FuzzMeasure to take advantage of Leopard under the hood was an exercise in patience and self-discipline. When I first learned about Objective-C 2.0, I wanted to just leap in and change every single accessor to use properties and turn for into for-each loops.

However, I didn’t have the time to do this, and I was smarter than that — mucking around in code that already works isn’t necessary. That said, there are benefits to ripping out code when you have the opportunity — less code means less bugs!. Also, converting to Objective-C 2.0 buys you other benefits behind the scenes, such as enhanced thread safety, proper memory management, faster enumeration, etc.

How does the one-man shop deal with balancing this lack of time with a mounting pile of important, but not time-sensitive, work? You page it in!

Read the rest of this entry »

I went to WWDC this year, and really enjoyed my time there. I got a lot of code written, a handful of questions answered, some new contacts at Apple, and a whole lot of motivation to keep innovating with FuzzMeasure. Sure, there were the keynotes, sessions, announcements, etc., but I found the real benefit was in the interactivity.

I met a lot of folks that I’ve been speaking to for years online, and some that I’ve never otherwise interacted with before, which added a whole other dimension of awesome to my trip. You can gain a whole lot just from attending the various parties and chatting with people in a laid-back setting over a beer (or a whole lot of fantastic tequila…).

On the more official front, you really do gain a lot from speaking directly with Apple’s engineers. Banging your head against a wall trying to figure out why an API isn’t quite doing what it’s supposed to can be very frustrating. Thus, having an engineer crack his laptop, check the source code, and tell you what’s going on under the hood is simply priceless. The labs are totally where it’s at.

If I could have done anything differently, I would have been far more prepared with questions and issues in advance. I found myself trying to create as many problems as I could while at the show so I had some more tricky issues to get sorted out as I hit them. That said, I think I got along just fine with the list of questions I encountered over the years, and I got a lot of names and email addresses to fire questions to in the future.

So, to those of you using FuzzMeasure, you have a lot to look forward to.

I was on the fence about attending the Leopard Tech Talk that came into Toronto on Friday. I signed up immediately to guarantee that I had a spot. As the event drew closer (and weather worsened), I couldn’t help but think that there would be not much added value over watching WWDC videos about similar leopard development topics.

The weather cleared up considerably during the week leading up to the event, and I heard that some key Apple personalities would be on-site, ripe for the brain-picking. My motivation had peaked, and I was all set.

Now that I’ve gone, I can’t say enough good things about the event. The food was excellent (and free!!), the people I spoke with were all very helpful, and I heard a lot of nice things about FuzzMeasure!

The only down side was that I couldn’t attend more of the talks! If I could have somehow split myself into two and attended simultaneous talks, I definitely would. Furthermore, it was nearly impossible to go to all the talks and speak with the tech support folks. I would also highly recommend that you go prepared with solid questions and examples beforehand, so you can get more done in less time.

I have a lot of work to do in FuzzMeasure to gain some of the extra functionality that Leopard will bring to the table. I also have to spend a lot of time learning some of the new developer tools and familiarizing myself with the new APIs available to me.

I don’t do FuzzMeasure Pro full-time. Most of you already know this. As a result, I need to ensure that I maintain agility so that I can keep FuzzMeasure moving forward on a shoestring time budget.

Because I have so little time, I need to reduce the time spent on routine tasks wherever I can. Also, I like to try and slip these operations into my regular routine, and make it something I could do just after having my morning coffee, for example.

So, with FuzzMeasure Pro 2 I tried to encapsulate as many updates as I could in a single operation. I chose appcasting as the technology of choice to accomplish this goal.

My appcast is centered around my release notes. Release notes come directly from FogBugz, which is a godsend for the one-man shop. As issues are resolved, they can be tagged for inclusion into the release’s notes by adding release notes to each individual issue. Once you gather up resolved issues for a release (I’ll have to write something up about my FogBugz workflow soon), you can pull down a release’s notes as a raw XML file.

Along with the release notes comes the distributable version of the application itself. I have a Python script (buildFM.py) that pulls down the head revision of FuzzMeasure’s trunk (maybe I’ll also describe my subversion workflow one day), and then produces a tbz file containing the application. This file is then auto-uploaded to my downloads directory after it is built.

Now I have the components I need to produce my appcast. Using another Python script I wrote (appcast.py), I toss my XML file (say, FuzzMeasure-2.0.4.xml) into my appcast working directory. Then, I add high-level details about the release into an index.txt file. The details simply state the marketing release number, the subversion revision for that release, and the date of the release. For FuzzMeasure 2.0.4, I added 2.0.4 1463 20060706 to the file. With this information, appcast.py builds appcast.xml.

My appcast.xml file is used as my central, “official” hub for distributing updates to users. FuzzMeasure uses Sparkle to read the appcast, and displays release notes to the user when an update is detected. My FuzzMeasure Pro download page also uses the appcast.xml to display its release notes and set the appropriate download link. Finally, end-users can subscribe to the appcast and view it in their favourite news reader.

So, by producing a single file and uploading it to a special location, I get three updates for the price of 1. Without fail, I would forget one of these three things when I updated in the past, so this new workflow enhancement sure is worth the time I spent on it.