I received a Google Wave invite this morning from a friend and I was all excited and ready to jump in. You know that feeling you get when you put on your favorite hat and your best shoes, grab a six pack and run into the party but nobody’s there? Yeah, thats the feeling. It’s like the Music is playing but there’s no DJ on the turn tables. You got a full tank of gas, you mash the pedal but the transmission is slipping. It’s when you pour the most gigantimous bowl of Lucky Charms, grab the shovel from next to the microwave oven, dig it into the bowl then open the refrigerator door to find an empty milk carton. I’m not out of hope, if I gotta wave to complete strangers then that’s what I’ll do for now. It’d be much better if Google found a way to make it work with existing communications like AIM, email, MyBook and FaceSpace. Then people would have some use for it other than a place holder in an otherwise empty conversation, “…say y’know I got one uh dose G Wiz Googly Wave thing-a-ma-jigs… it’s awesome…”

If you’re in the same boat as I am, look for clifton.craig somewhere in the wave system. By the way, how do you search and find new contacts with this crazy thing? Until then, I’m waving but nobody’s waving back… holler…

So I’d been thinking. Because I’m back into iPhone development and getting warmed up not only to ObjC issues and errors but also C++ oddities, I’m wondering how do you write tests for some of the more difficult things to capture? For instance, I’ve figured out how to capture some of the manual reference counting that’s required by CocoaTouch. (I assert that objects passed into other objects are properly retained and properly released when the object itself is released.) Still I can’t capture the more involved memory management problems. How do you assert an autorelease? What about dynamic memory allocation with pointers? I ended up with a single method that dynamically allocates for a pointer via malloc. I then changed it to use new with array notation.

void MySpecialObject::writeRequestToStream(CFStringRef aRequest, CFWriteStreamRef requestStream)
{
if(CFWriteStreamGetStatus(requestStream) == kCFStreamStatusNotOpen) CFWriteStreamOpen(requestStream);
UInt8* convertedString =(UInt8*)convertToCString(aRequest);
CFWriteStreamWrite(requestStream, convertedString, CFStringGetLength(aRequest));
free(convertedString);
}

It’s used in one spot so far and I’ve manually added the free without a prior failing test. I felt dirty. Assuming there were no call to free, how would you write a failing test for the code above? Is this just one of those things where you have to be extra careful? Maybe I should investigate the use of Velocity style code macros/templates that expand after keying special abbreviation similar to what we have in IntelliJ. I can imagine something like “cstr” expanding to:

char *myCStr = new char[size];
// use myCStr here
free(myCStr);

With the ability to tab through highlighting the variable name, declared size and commented insert code section. Any bright ideas?

My iPhone crapped out on me this weekend. I went to use it and the screen wouldn’t show at all. I loaded iTunes which was able to recognize it and offer to restore it to factory. Word of advice, iTunes is very sneaky! I didn’t realize that the factory restore it offered came with a complimentary upgrade to OS 3.1.2! It became apparent after I went to use the device and swiped right revealing the new spotlight search. Crap! I needed to keep it on 2.2 because I need to verify 2.2 compatibility. No worries, I’l just down grade when I get to the office. I then realized that I couldn’t build and run on device using XCode. I was getting “No Provisioned device connected” errors. I got concerned thinking I had to go through the whole re-provisioning my device hassle. Then I realized the “use for development” button in XCode. One thing lead to another then I finally realized all of the ugly truths about iPhone development.

1. OS 3.1.2 only accepts builds from XCode with iPhone SDK 3.1.2.
2. The iPhone SDK 3.1.2 only installs on OSX 10.6 (Snow Leopard)
3. Apple no longer offers any iPhone OS earlier than 3.1.2 on its website.
4. If you are lucky enough to find a lingering copy of iPhone OS 3.0 or earlier, you cannot roll back from 3.1.2 (…easily) due to baseband errors.
5. DFU mode is not easy to do or understand.
6. You will likely spend the good part of a couple of days trying to recover from an unintentional upgrade as your first 5-7 rollbacks will leave you with misc errors.

The simple answer is that you cannot downgrade the OS without using DFU mode. DFU stands for Device Firmware Upgrade and is a secret mode that Apple doesn’t want you to know about. You have to use something similar to the old Nintendo Contra cheat (you remember up, up, down, down, left, right, left, right, b, a…) to enable it. I’ve tried it a couple of times so far and realized that you probably should have a completely installed OS before trying it. My second attempt (after a fresh iTunes restore) left me with an error and I’m hoping the third time is a charm. Here goes nothing…

I’ve been having constant issues with Behavior Driven Design using xUnit tools. For those that don’t know what behavior driven design means check out Dan North’s introduction. When writing tests you can choose from a number of approaches. I feel I’ve followed an evolutionary chain through the most popular. Most people start with CWT, or Coding While Testing. This is an approach where the tests are written with the code, not necessarily before but along side. People take this “feel good” approach in order to cover their code with tests and to gain confidence that their code won’t break without them knowing why/where. Eventually tests become brittle and break all around and the tests become a burden to maintain. Some people evolve into TDD or Test Driven Design. This is where the test is written first in an attempt to achieve better design. When I evolved this far I was still struggling in the “implementation zone”. That’s where most developers get their mail delivered. The implementation zone is where the major concern is how things work. You can’t rest well unless you know exactly how things work beneath a method call. There are no surprises because everything is understood. Doing TDD while living here leads to “White Box” tests. These are tests that mirror the implementation of the system. These test scream immediately when the system change in the slightest. It’s no fun.

Later I learned about the Behavior Driven approach which lead to my understanding DSLs, or Domain Specific Languages. Actually I picked up my understanding of DSLs when I started using JMock, which is still one of my favorite tools. I started to remember why programming languages were invented. “Code is for Humans” became my mantra. I stopped caring about how code worked and started concerning myself with why code was written. With today’s systems rivaling NASA in their complexity it becomes impossible to obsess over every implementation detail. It’s more natural to trust that something works through an automatable specification that says it works. Its hard to put in English, but there’s a subtle difference in how I look at code compared to how I see most of my co-workers look at code. I rely on a system of trust which helps both in design and in debugging. I digress.

This morning I began reading Martin Fowler’s revised write up on Mocks vs. Stubs. If you do any automated testing of your system at all I demand you read this article. If you’ve read it in the past (as I had) I demand you read it again because it’s updated. If you read it last week then I demand you read it to your 5 year old tonight at bed time. The point is that Martin makes very good distinctions on what he calls classic TDD and Mockist TDD. He explains the difference between state verification and behavior verification. He explains it in a way that shocked me, because I’d classify myself as a mockist. The entire time I obsessed over implementation being secondary to design I see how and why the mockist frame of thought can easily shackle your design to your implementation details. I almost wanted to change ships, jump on the classical bandwagon. However the article very fairly points out several flaws in both approaches while not condemning either. In the end the choice is left to you. Well done Martin. Well done.

I titled this post, “Classic vs Mockist, TDD vs BDD” not to align BDD with the mockist approach though it fits better. The truth is that you can use Martin’s classic TDD style when doing BDD and vice versa. There really isn’t much of a difference between classic or mockist, TDD or BDD. It’s all really a matter of style as all these approaches aim in the same direction. Its similar to comparing Baptist to Methodist religions. There are differences but one is not more true than the other and its the faith or general direction that both point to that makes them equally as important. Here’s what’s really important.

Back to my problem. I posted on Stack overflow yesterday asking the question of how to avoid so many mocks. I have yet to receive a solution to the core problem I’m seeing. If you or someone you know has a mastery of TDD please chime in. I’d love to finally have a good discussion on how to solve a complex problem using the practice. I feel like I’m 80% there but I’m missing one piece of the pie.

This morning I spent 10 minutes answering “ok” to 65,536 dialogs in Finder. This is the direct result of used the latest thing. I don’t do like I used to. I used to install bleeding edge software and constantly run around with napkins as my nose dripped red goo. I’ve learned my lesson. I now know to install software only after its been battle tested and at least 1/2 of my coworkers are using it. So what has happened? What I used was the latest version of SVN support in Versions… 1.6 support. It’s not what I would call bleeding edge. Version 1.6 of svn has been around long enough. It’s battle tested and proven. Why then do I have exactly 65,536 ok dialogs scattered across my screen, each informing me that “my client is too old to work with…”? And how did I know that there were exactly 65,536 dialogs? (An exercise left to the reader… YOU! Not your RSS reader!) A long time ago I installed a Tortoise-like plugin for Finder. It gives you little folder decorations for things that are up to date in svn, checked out, conflicting or whatever. I forget the name of the app. It was so long ago that I’ve since forgotten and lost the installer. I don’t even know if there’s an uninstaller. (Which reminds me… why is it soo difficult to remove software from a Mac?) Still it helps me. It’s one of those nice to have things that help but doesn’t do the job entirely. So this tool has been hanging around assiting Finder for the past year or so and keeping me out of trouble when I attempt to delete old work that I’m not sure is under a VCS. After I switched Versions to use 1.6 format for its checkouts I started getting these dialogs. I didn’t know which tool they were coming from because I also use IntelliJ which includes its own svn support. Also I’ve since irreparably hacked XCode to work with svn 1.5. The dialog could have been coming from any of these three svn related tools. (I’d completely forgotten about the Finder plugin.) So I restarted versions a few times which seemed to remedy the problem. I was sure it was a Versions problem because I had other minor glitches since taking a recent Versions upgrade. By the time I figured out the Finder plugin was the problem I was already in knee deep. Unable to delete the 4-5 projects checked out in 1.6 format. Today I got a small break and decided to address the problem. It took me 5-10 minutes to fix because I had to first answer ok to each dialog. Then I had to delete and checkout the projects again. I also had to delete and checkout the projects again after realizing I forgot to change the Versions flag before the first delete/checkout cycle.

Because I have nothing better to do with the eight hours I spend in my company’s office building I felt it would be a great idea to sit down in from of a vi prompt and rewrite the Hudson build server all over again! From scratch! With no syntax highlighting! Without help from any of its core dev team! Ain’t I cool? Hi, I’m Cliff. You’re here because you too would like to waste hours of development time toiling over a build tool or IDE setting for years… just to make it do what it was doing three weeks ago before the system admins decided to switch all network traffic to route through a SOCKs server then through an authenticating HTTP proxy which is managed by a complicated key based 256bit encryption mechanism hosted on a Novell server that mandates each employee drive across the parking lot.. in the rain… and place their thumb on a high-tech print-scanner to acquire a key that is only valid for 2 1/2 hours after which the entire process must be repeated to continue accessing private company systems. Yeah, that’s why you’re here. That’s why I’m here too. After all, if you don’t get that one particular tool working the rest of your life will be a living nightmare of, “why am I not getting optimal results? Oh yeah, it’s because I forgot to do the manual 37 step process just before checking my changes into svn. Lets add step number 38 to prevent the disaster that just occurred last Wednesday when we tried to demo for our CEO.”

On to today’s topic. No I didn’t actually decide to rewrite Hudson. I just got tasked with figuring out why we don’t have CI in our project. That turned into the, “oh yeah it’s because this part of our project runs on a later version of Hudson.” That became, “why can’t we downgrade?” Which was answered with, “because we put so many man hours into getting to this point all of which would need repeating.” this ultimately turned into a hack that depends on Bazaar brilliance. The hack intermittently falls over so it became my job to revisit why we can no longer use normal subversion tools. When I got deep into this task I found myself staring into a vi prompt on a Linux machine looking at the Java source code which propels Hudson into action. Its bad enough that I made several failed attempts to build Hudson from source on my Mac each which consumed valuable CPU cycles and upwards of 10-20 minutes. It became really painful when I knew I had to point Linux through ssh at the several hundred megabyte (Gigabyte?) source package sitting on my Mac. Why not just checkout the source directly in Linux? Well the initial checkout took hours on my Mac and I wasn’t sure whether it was due to rainy conditions in the weather or client side bandwidth or slow server side response time and I wasn’t willing to do yet another bout of research just to get the answer to question which really isn’t critical. So here I am, looking at Java source and unable to rapidly navigate it as I could in IntelliJ Idea. Its a sea of text and I’m lost in the middle without a clue. I have Spotlight which pin-pointed the location that needs to be fixed. but I have no confidence that the build I execute is responsible for the war file that I ultimately collect because this war file is in a non-standard location. Also, the instructions for building this war file are comparable in complexity to the non-standard structure of the project. This structure is, in turn, comparable to the complexity of the source code. I’m lost, frustrated, and I just want it to work. On a good day (a Monday) I’d love to obsess over how the Hudson team has managed to tackle whatever problem that lead to the complexity that is their current build system. But on a bad day (a Friday) I only care that the end result of their build system can find the source code that is locked behind yet another ocean of complicated security constraints. I just want things to work. I don’t want to learn their interiors. I want them to do the thing I they were designed to to.

**Update**
I’ve updated my example below after realizing I left out some important pieces…
**Update**

How do you assert that something runs in a different thread? Or more generically, how do you assert that something runs asynchronously? I need to do this in ObjC but also in Java. The scenario is as follows. I have a WhatzItz object instance stored in myWhatzItz. I tell myWhatzItz to doDisThing. I need to specify that myWhatzItz will doDisThing asynchronously. Experience tells the story that multi-threaded unit tests are dumb, complicated and wrong. So asking myWhatzItz to doDisThing then waiting or polling for completion of doDisThing is not what we want to do here. (It may be what you want to do but it’s not what I want. Since we’re on the same team and since I’m doing the writing you have to want what I want not what you want. I want you to want my wants… forget your wants… your wants are dumb anyhow!)

So how do we design myWhatzItz to doDisThing and doDisThing right? I’m going to suggest an interface… err prototcol. That is an abstraction for what we want to design. In unit testing we stay focused on one thing. All distractions are tossed behind abstractions. So after asking myWhatzItz to doDisThing I need to assert that it uses asynchronous behavior. That brings us a step back. I have to design a dependency on asynchronous behavior first. Right now you’re probably wondering how asynchronous behavior works. Right now I’m ’bout to slap you like Bruce Lee slapped that boy in Enter the Dragon. (Or was that Return of the Dragon? Maybe it was the game of death? Bonus points to the 1st person that gets the movie correct with a link to the clip on YouTube!) “Don’t focus on the finger or you’ll miss the beauty in the sky above!”, says Bruce. We don’t care about how asynchronous behavior works, as its irrelevant to our design. We only care that our work is done asynchronously! So we’ll code this test in ObjectiveC:

#import
@protocol MyAsynchronousBehavior
-(void) performAsynchronously:(SEL) aSelctor onTarget:(id)aTarget withObject:(id)anObject;
@end

@interface MyWhatzItzTest : SenTestCase <MyAsynchronousBehavior>
{
  MyWhatzItz *myWhatzItz;
  SEL selectorPerformed;
  id targetForSelector;
  id parameterForSelector;
  int performAsynchronouslyInvocationCount;
}
@end

@implementation MyWhatzItzTest

-(void) setUp
{
   myWhatzItz = [[MyWhatzItz alloc] init];
   //The test uses the self-shunt pattern to listen for MyAsynchronousBehavior interaction.
   id theAsynchronousBehavior = self;
   myWhatzItz.asynchronousBehavior = theAsynchronousBehavior;
}

-(void) testMyWhatzItzWillAsynchronouslyDoDisThingWhenAskedToDoDatThing
{
  STAssertEquals(performAsynchronouslyInvocationCount, 0, @"Assuming that we haven't been asked to performAsynchronously");
  [myWhatzItz doDatThing];
  STAssertEquals(performAsynchronouslyInvocationCount, 1, @"We SHOULD HAVE been asked to performAsynchronously");
  STAssertEquals(selectorPerformed, @selector(doDisThing:), @"Should have asked to doDisThing using asynchronous behavior.");
  STAssertEquals(targetForSelector, myWhatzItz, @"Should use myWhatzItz for asynchronous execution.");
}
@end
#pragma mark MyAsynchronousBehavior protocol methods
-(void) performAsynchronously:(SEL) aSelctor onTarget:(id)aTarget withObject:(id)anObject
{
  performAsynchronouslyInvocationCount++; selectorPerformed = aSelctor; targetForSelector = aTarget; parameterForSelector = anObject;
}

Supplying the asynchronous behavior becomes a construction/intialization concern, which could be extracted into a wiring framework like Interface Builder (or if you do Java, Springframework). The nice thing is that we can alternate our asynchronous behavior without touching the rest of the project. We can do something quick/dirty like detachThread… and later get more elegant with RunLoops. Today’s tip comes to you (me) completely by accident. I’ve been trying to test drive things in Java and ObjC for several years now and I’ve never got this part quite right. Feel free to share your opinions/experiences with threads and tests.

**Update**
The above example demonstrates a few important unit testing concepts. first it uses the self-shunt pattern to allow the test to become a mock and listen for interactions between the tested object and its collaborator(s). Second, it demonstrates the importance of using tests to carve out the pieces that should NOT be under test. In this situation it’s multi-tasking, however in other scenarios it could be anything from a DBMS to a network call. I could have illustrated an example where I spin up a Thread pool of some sort from within the test started work, paused the main thread and waited for a response. That’s what I’ve done in the past and it becomes extremely complicated and brittle. In stead, I use the elegance of abstraction to make the test 100% predictable, 200% more simplistic, and 300% more maintainable. Where do I get those statistics? The short answer is they’re sequential. (The long story begins yesterday when my 5yr old spontaneously decided to count from 1 to infinity in the middle of our shopping trip. You see, she only recently learned her numbers up to 100 and after getting to 199 we all realized the child’s computational limits as she continued with one hundred one hundred then followed up with one hundred one hundred one, one hundred one hundred two…)
**Update**

A while ago I posted some promising info on how one might go about creating symbolic links in a tar using the Maven Assembly plugin. But as luck would have it there is no promise here… not yet. It’s such a shame because this can actually be programmed using some clever platform detection and command line trickery. It could also be done by enhancing the tar logic in whatever the open source project name is. However, I cannot do this today, nor do I have the time to investigate enhancing the tar objects in Java or anything else. The general idea is: given a directory with sym links, create a tar from the directory while maintaining the symbolic link structure within. I ran into the problem again this afternoon after revisiting the project. It’s funny how I thought I actually had a solution until I ran some of my old code searched Google and turned up my old blog post. If anyone has solved this problem speak up.

So I did this really spontaneous thing last week because the new lead VP of AOL Local and Maps came down from high. I love how that sounds… “came down from high”. It’s like these executives descend from their cloud cathedrals and bless us mere propeller heads with a visit. As it turns out, these guys are not heavenly at all. They get constipation just like I do when the diet doesn’t include an adequate supply of fiber and liquid. Hi, I’m Cliff. You’re here because you don’t think it’s possible to develop a mobile voice application using agile practices. I mean, you can’t honestly test drive something like text-to-speech or voice recognition… can you? Anyhow, like I was saying, I did a really “out-of-the-blue” thing. I’d been playing with Text-To-Speech ever since I started mobile development. I’d been fooling with it and trying to get a handle on voice recognition as well. So when I heard my director tell us that the execs were coming to town I thought, “This would be an ideal time to throw my work in front of their faces to see what kind of reaction I’d get.” At this point I had already taken voice in a double round trip from the iPhone to the server pinged back as text then ponged to the server which re-pings more voice. The example was simple and it demonstrated that we could not only do voice output from mobile, but that we could concatenate multiple audio streams in the client and perform recognition. I also had a good amount of confidence in my TTS engine, enough to spend the weekend prior roping in an ugly hack in one of our premier products. (We have two of them now… go grab the Navigator from the Apple store!)

I received favorable response from all who saw my prototype. So much favor that a subsequent demo was scheduled the next day on my behalf. (I missed my own subsequent demo.) That energized me even further as I decided two nights ago to begin officially bundling my idea. It’s one thing to hack something together but I needed a polished solution. I began to get back into my comfort zone with test driven design. My warm/fuzzy place. (Lately I’d been combing through miles of piles of other people’s non-tested non-reusable code regurgitating the bad practices I’d been swamped with.)

It began with a test. No. It began with a spec.
Given the text, “hello Miami!”
When I ask voiceOutput to speak the text
Then I should get an audio response in return.

I then started to chip away. Nothing was talking. No sounds or audio files were connected to my code. It was just how I remember it. The sweet smell of JUnit… err… OCUnit… or SenTest…somethin’ or other… I began to dream while I wrote test after test each followed by implementation logic. “What will the end picture look like?” Lower level details tried to sneak into my head but I fought them off… each time refocusing on the test before me. The task was only to accept text input and respond with an audio stream.

From the onset it seems difficult if not impractical. How does one validate that the voice engine is working? How do you verify the thing speaks… with sound your ears can pick up? How does it all work with unit tests? I tend to get tripped up on these details just as much as anyone who picks up TDD. When you look at the same problem, the same question with a slightly different view (in reverse even) it becomes obvious. Put the “D” in front of TDD. We aren’t testing, we’re designing! It’s Design Driven-by Tests or DDT. If you think test you think things like “how can I plug my ear drum into SenTestCase?”, or “how can I wire my optic nerve up to the JUnit Test runner?” When you think design you no longer care if it works right you care if you have the right works. So back to my original question, “How does one validate that the voice engine is working?” Let’s instead ask “How does one build the right voice engine?” The voice engine is right when it answers the question. The question become the point of focus. The question is the specification. So I don’t verify audio output. I verify the interface or logic in between. I didn’t write the voice engine code so verifying it is a wasted exercise. I only care about the code that sits between my phone and the voice engine.

On the outside I know that my phone code deals with english sentences. I also know that it is rather complicated so changing it to “fit into” a voice engine would be an exercise in complexity. So now that I’m not testing audio output or the engine that produces it I can totally forget about what the engine expects… for now. I continue design with specs and answers to specs. as long as my code returns an audio stream on the outside, I know I’m finished. The converter code is looking a lot more simple than one would imagine. I then know that I’l need to get the stream from somewhere. So I write the code to get the audio data from another thing. (Here’s where I make a subtle mis-step.) I start thinking about caching. Because I’m worried about cell network latency I want to include an on-device cache.

I continue adding a test that states (literally) that I’ll probably need a cache. The test asks for text to be converted to audio without using a cache then triggers a test failure if an exception isn’t thrown. The failure message states something like, “an exception should be thrown if a cache is not configured.” I satisfy this requirement and add more tests that anticipate cache inquiries prior to any conversion. I use the self-shunt pattern rather than OCMock objects because I don’t want to add a framework (layer of complexity) to my project just yet. I drive on with more tests that eventually shape the cache and also a network data provider that only exists as a protocol (analogous to a Java interface). I’m feeling good at this point. Not finished, not even close… but I have good progress with a relatively small amount of code. I’m also feeling slightly more comfortable with both XCode and Objective C. I feel best about the fact that I can actually test drive a feature that would likely seem impossible to most developers. That along with the fact that I managed to do an acceptable demo to our Senior VP team, one that got people giving the thumbs up. I think I can sleep well tonight.

These past few weeks have been chaotic. I’ve had more people asking for special favors than I’ve had seconds in each minute. If you are among those people who needed me to work on something, wanted me to research something, looked for a technical solution to something, or whatever then this post is for you. I apologize. I’ve had to ignore you, the others, and my family members in order to make progress on a few initiatives I’d started recently.

I currently work on Blackberry mobile stuff for touch screen devices. We’re trying to port our product to more platforms and the deadline is here. Also, I now have voice/speech working both ways in an iPhone app. (That’s recognition and synthesizing.) I’m working on getting the same idea going on the Blackberry Storm. I did a demo for the new executive that came to visit yesterday. I’m also killing myself over a podcast me and a buddy did last week trying to convert it to a form that can be viewed, heard, and appreciated around the company. Lump that on top of the forty-five other things that brothers, sisters, mothers, wives (no I only have one of those), and friends have asked me to look into. I put everyone on hold… silently. I really wanna help you, I do. I appreciate doing tech stuff and I wish I had more arms and heads to solve these problems simultaneously. Alas, I am but one being. One tired, worn out being who disparately needs a new hard drive in his Mac because this thing has slowed to a crawl. (At this point I know it’s the hard drive that’s slowing everything else because I’ve killed enough programs to free memory.) I also plan to be more active on my site. There’s a ton of things I want to talk about. If you’re a regular visitor do me a favor… help a brother out… Could somebody research and find a good tutorial on Cover Story for iPhone development? I really, really, really, wanna do something devilish… I mean innovative with it. I have big plans for Cover Story… big plans indeed!