groovy -e ‘def printout = { it.consumeProcessOutput(System.out, System.err); it.waitFor() }; new File(/./).eachDirMatch ({ new File(it, /pom.xml/).exists() }) { printout(“mvn -f $it/pom.xml clean”.execute()) }’

Which can be simplified from Groovy 1.5 to Groovy 1.6.5 speak:
groovy -e ‘new File(/./).eachDirMatch ({ new File(it, /pom.xml/).exists() }) {“mvn -f $it/pom.xml clean”.execute(). waitForProcessOutput(System.out,System.err)}’

which only fits in a tweet if you don’t care for errors when a directory isn’t a maven project:
groovy -e ‘new File(/./).eachDir {“mvn -f $it/pom.xml clean”.execute(). waitForProcessOutput(System.out,System.err)}’

For those of you looking puzzled, it’s a Groovy way to clean a bunch of Maven project subfolders you plan to add into Subversion. It’ll work for ant too just by changing “mvn” to “ant” and changing “pom.xml” to “build.xml” in case you have a bunch of Ant projects that need to be added into svn.

It’s been a rough day. I spent the majority of it chasing down random misbehavior on a staging server. My development machine is 32 bit. (Technically my development machine is 64 bit but I’m running a 32bit Kernel in my OS.) The staging server is 64bit. I write Java. Java sez, “you write once and run anywhere!” In reality, when I move compiled source code from my development machine to my staging machine things act radically different.

The big picture is that I’m trying to make the staging machine talk to me. I mean literally talk, using english words and all. It’s the extra 32 bits in this staging machine that have been getting in the way. They force me to scour the web and find native libraries that contain the same amount of extra chromosomes… err… bits. Then on top of that, Tomcat likes to do different things when you throw war files in it.

Today’s lesson begins from Tomcat. Pretend you’ve written a servlet. (Ok, you don’t have to pretend. Go on and write a servlet if it makes you feel better, I’ll wait here patiently.) In your servlet make like you have a lot of binary stuff that you want to share with connecting web people. These people might be sitting under a MacbookPro, or scrolling a Blackberry wheel, or flicking an iPhone or something. Whatever the case, they came to your servlet to get these wonderful binary thingies. These binary thingies are larger than your typical web page, spanning a few kilobytes. So now you have to use one of those stream classes. If you’re really smart, like I think I am, then you’ll do something clever [stupid] and try pipelining, or reading from an input stream and writing to an output stream. You’ll do this because you’re afraid of materializing too much binary goodness in your precious RAM sticks. You’ll say “1024 bytes is plenty enough! Let’s take these one thousand twenty four bytes and put them on the output stream for the people can get those!” Then if you’re really really smart, you’ll do this in a loop until you reach the bottom of your input stream.

Are you all done with your computer program? I think I’m done with mine! Goody! Lets mash the run button and see what happens? Is yourz doing like mine isn’t doing? Minez is supposed to be shuttling all of the binary stuff across teh internets, but its not because its borked. I only get part of what I thought I was gonna git. Now go scratch your head like the guys in the head and shoulders commercials and pour another cup of coffee. when you get back we’ll figure out wha happend…

Are you back yet? Cool! Lets look into your really really smart looping program. Do you see it? Right there in the middle of your loop. You keep writin’ stuff but only part of it is showing on the other end. Any idea why? My Mommy told me a long time ago, “never forget to flush! It’s just bad manners…” She was also famous for saying stuff like, “poop or get off the pot!” In the loop thing we never flush our output stream! Maybe that’s why we only see a part of the stuff on the other end. So then there’s a happy ending to the story after all isn’t there?

Your a Java developer and you’ve installed Linux. Maybe this is your first time converting from Windows. Maybe you’re a Linux veteran trying Java for the first time. Maybe you’re new to both Java and Linux and you’re running some crappy program some other Java guy wrote. Whatever your background is, you now find yourself staring at an unstatisfied link error. You don’t know what angered the link and you have no idea how to satisfy it. Hi, I’m Cliff and you’re here because you suck at satisfying links. But we already knew that, didn’t we? Does the error below look familiar?

java.lang.UnsatisfiedLinkError: Can’t load library: /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/motif21/libmawt.so
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1666)
at java.lang.Runtime.load0(Runtime.java:787)
at java.lang.System.load(System.java:1022)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1767)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1684)
at java.lang.Runtime.loadLibrary0(Runtime.java:840)
at java.lang.System.loadLibrary(System.java:1047)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Toolkit.java:1610)
at java.awt.Toolkit.(Toolkit.java:1632)

The long answer begins, “four score and seventeen (…seven? …several?) years ago…” and continues with babbling about openjdk and motif libs with a bunch of other nonsense you probably don’t particularly care about. The short story (which is also why you’re here listening to the most long-winded developer this side of the east coast that loves to insert rambling between parenthesis as if that makes any of his blog posts easier on the eyes…) is that you probably need to unset or set an environment variable. “export AWT_TOOLKIT=MToolkit” will cause the error while “export AWT_TOOLKIT=XToolkit” should make it go away. The environment variable controls which one of Linux’s windowing toolkits are used to draw the program on your screen. The MToolkit causes the Java program to look for the “libmawt.so” file which is a Motif Abstract Windowing Toolkit Shared Object, hence the “m-a-w-t.s-o” in the file name. Shared objects are the Linux way of sharing code. Other operating systems use other files. Windows uses “.dll” files, while Mac OSX uses “dylib” files. The Abstract Windowing Toolkit is the Java way of drawing programs on your screen which is abstract so that it can change the way the program looks and feels. Motif is one of the many looks of a java program, while others include “Native”, “Metal”, “Aqua” and others. Not all of these looks are available in each distribution of Java so chances are that you copied a program from a system (or developed a program for a system) that included the Motif look and feel and now you’re trying to run it on your fresh Linux install.

The good news is the problem is easy to fix once you know the how and why. The bad news is you’ll probably do something clever like putting “AWT_TOOLKIT=XToolkit” in your “~/.bash_profile” and forget this hack is in place which will likely cause other issues several months down the line when you want to toy with Compiz-Fusion but your IntelliJ editor is acting funny, locking up or going completely dark or something. That’s your good-news/bad-news for the day. Happy coding and clever hacking to you all.

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**