I bring you tidings and cheer this year. All the way from Stonegate Drive where I spent many an hour in front of the T.V. I list my top five 80’s moments.

Transformers The Movie (One shall stand, one shall fall)

The Last Dragon (Busta Rhymes and Marlon Wayans need to do a remake!)

Bruce Lee Nunchucks (Nuff said)

Bruce Lee and Kareem (Now why would they use the Asian lengthening effect for a clip with Kareem?)

Breaking Electric Boogaloo (Sweeping the living room hadn’t been the same since!)

And number six (I can’t leave it out) Storm Shadow vs. Snake Eyes

Honestly I’m not sure if it was more cool to have the glow or the touch but either way I found myself in front of the mirror practicing mentally induced spontaneous combustion. (Don’t act like it was just me! A whole lot of you thought you could light up an empty dark room but instead found a way to accidentally crap your pants when showing your homies.)

If you try to fail and you succeed, which have you actually done? Are you a success? Or a failure? Is it good to be a failure? Is it better to be successful at failure? Let’s add detail to the question. By the way, I’m Cliff. You’re here because you tried to fail and you succeeded. Today’s topic is something I’ve visited before. It’s a new thing I’m trying with unit tests. Actually it’s an old thing to many but I’m trying it for the first time in both C++ and ObjC so it feels sorta new-ish.

How do you unit test?
Let’s start with how you unit test. What are your steps? What are the recommended steps? In order to be successful at TDD you must appreciate the entirety of the practice. It goes, “Red, Green, Refactor”. Red comes before Green, just like with traffic lights. What I’m saying is that you have to begin with a failing test. The first test is important. The first failure should describe what work you have to do. In my case, I’m swimming in un-ventured waters (C++/ObjC++ testing) so there’s some learning that needs to be re-enforced. Here’s how I’ve been starting my tests recently:

//
//  MyCoolNewObjectTest.m
//  Created by cliftoncraig07 on 12/1/09.
//  Copyright 2009 __MyCompanyName__. All rights reserved.
//
#import <SenTestingKit/SenTestingKit.h>
#include "MyCoolNewObject.h"

@interface MyCoolNewObjectTest : SenTestCase
{
  MyCoolNewObject *coolObject;
}
@end

@implementation MyCoolNewObjectTest

-(void) setUp
{}

@end

The test shell is completely empty except for references to the “thing” I’m about to create. I get my first failure which is a compile error stating that this thing does not exist. “No such file error…” around the include. Here I have an opportunity to review my design as minimalist as it is. I ask, “Does the error make sense? Is it expected? Do I like the name of this cool new thing I’m creating? Is it specific to the task I’m assigned to?” Always review each error with these question. After creating the files for the new “thing” I then follow up with:

//
//  MyCoolNewObjectTest.m
//  Created by cliftoncraig07 on 12/1/09.
//  Copyright 2009 __MyCompanyName__. All rights reserved.
//
#import <SenTestingKit/SenTestingKit.h>
#include "MyCoolNewObject.h"

@interface MyCoolNewObjectTest : SenTestCase
{
  MyCoolNewObject *coolObject;
}
@end

@implementation MyCoolNewObjectTest

-(void) setUp
{ STFail(@"You must fail before you can succeed!"); }

@end

Also important, while I train myself on the new testing framework, because I need to catch myself misnaming the “setup” method which should have a capital “U”. It also lets me know that my test is actually running as part of the suite. Far too often, in Xcode, I’ll have the wrong target active and begin writing the wrong code because I was getting false positives from tests that were never run. Here’s where it gets interesting. The STFail in the above example does not fail! Now we face our original question, if you try to fail, as we have above, and you succeed like our test suite will do here, which have you actually done? The first time I hit the unexpected success I got nervous and read all around the SenTesting framework and OCUnit. Eventually I settled on the conclusion that because there were no tests to run the setUp was being optimized away as unnecessary. What the above example is pointing out is that such a test case can never fail since there are no tests. That leads us to our final step…

//
//  MyCoolNewObjectTest.m
//  Created by cliftoncraig07 on 12/1/09.
//  Copyright 2009 __MyCompanyName__. All rights reserved.
//
#import <SenTestingKit/SenTestingKit.h>
#include "MyCoolNewObject.h"

@interface MyCoolNewObjectTest : SenTestCase
{
  MyCoolNewObject *coolObject;
}
@end

@implementation MyCoolNewObjectTest

-(void) setUp
{ STFail(@"You must fail before you can succeed!"); }

-(void) testSomething
{}

@end

…and here we get our familiar red bar! Our test case is complete and we now understand a little more about OCUnit. That’s it for today. Go on. Nothing else to see here. I know what you’re thinking. “We haven’t written or learned anything new!” Sure we have! We’ve written and validated our first test case in ObjC++. (I’m using OCUnit w/ C++ extensions to exercise or test drive C++ code.) The little amount we went over here is persistent through all the testing you will do from then on. It starts from the basic mechanics. Make sure every line of code is proceeded by some test (or compiler) failure. If you’ve done more than 2-3 things and haven’t run a build to generate a failure then you’re completely off track.

I rode the Wave then Twitter sucked me in! I don’t do Facebook anymore because too many people would know too much of my dirty laundry. (Not that I have anything to hide I’m just careful on what I share with whom.) It started over a year ago when those Facebook apps got to be fun. Before I knew it I was answering “would you rather…” questions and rating friends in a way that could be taken out of context. Nobody would believe that I was “just trying out this little app” if they were to come across some of the stoopidity I was putting in the checkboxes. Its dangerous. Not only do these social network apps link people in ways never thought of before, they have a way of weening information out of you that you wouldn’t typically share in a regular situation.

I’m a mostly open guy but I have a certain edge to my personality that, when not kept under control, can lead to random outbursts in awkward situations. Because 90% of my connections were work related and because Facebook has no qualms with broadcasting every minute move you make to your entire Friend list by default I found it’d be easier if I just left it alone, lest somebody thought I was experiencing a breakdown of some sort. I’m putting this out there as a warning to some of you who may be on Facebook and not realizing that the stuff you do there IS broadcasted and permanent. You won’t realize until someone in your office taps you and asks about your “wall” or inquires why you were up at 12am updating the movie preferences with Steel Magnolia topping your list.

More important is the distraction these things impose on your normal activity. Something as personal as spending the holiday with your family can now be interrupted by a series of dumb tweets on a nonsense topic. I don’t usually reveal too much of my personal life here because it’s supposed to be all about the sourcecode but that last statement is too true and speaks to my level of discipline. While I don’t believe I did anything too damaging with Twitter (following the Wayans Bros. trends) this weekend I do understand the potential for chaos.

Google Wave is another big nothing. On its own, its an IM/Email/Live-Twitter-Board that doesn’t give you anything you don’t already have. It just aggregates existing tools in an interesting new way and because it wears a “Google” badge you’ll use it regardless of its current usability issues. I burned an entire day trying to work around usability flaws my and lack of Wave connections and find some practical advantage of the new platform. I feel it does have potential and there is something big that could happen over the next few months but it is just taking too much of my time to follow along with everything else.

I always used to wonder about people who would pay for Cable, Pay-Per-View, NetFlix, Blockbuster, cell service, a land line, Satellite radio, and multiple-magazine subscriptions. Now I fear I’m becoming one if I don’t tone things down.

You’re working in Objective-C land trying to get a product out the door and into the Apple iTunes Store, right? (Don’t argue with me I’m just setting the stage.) You’re feeling the second cup of coffee seep into your bloodstream which creates a certain euphoric sensation as the last 3 times you mashed Cmd+B turned up no errors. Yes, that’s what’s happening in your copy of XCode right now. You then Cmd+Tilde to toggle the other XCode window active (Cmd+Tilde is a nifty Apple shortcut for switching active windows in the current app) and Cmd+B once again when a red flag on the play pops up in some code that had been just fine moments ago? What happened? Hi, I’m Cliff. You’re here because XCode got’cha and you’re not quite sure how/why/where. I’m here because I wanna list as many of these got’chas before I forget them.

Property accessor notation in Earlier SDKs
Here’s one weird gotcha that I just hit again for the first time. If you have a variable typed as a protocol and that protocol has a setter, which takes another protocol type defined then you may get an error when using dot notation in SDKs earlier than 3.0. That is a definition like this:

@protocol MyCoolAbstractType <NSObject>
-(void) setNetworkDataProvider:(id<MyNetworkDataProvider>)aNetworkDataProvider;
@end

…should be coded like this:

@protocol MyCoolAbstractType <NSObject>
@property (nonatomic, retain) id<MyNetworkDataProvider> networkDataProvider;
@end

…before you can do this:

id<MyCoolAbstractType> myObj = //create object from factory
myObj.networkDataProvider = [[MyConcreteNetworkDataProvider alloc] init];

Evidently the “Discover setter is a property” feature is something new Santa delivered with 3.0 and never told me about. Here I thought I had that toy from 2 years ago!

Unit Tests Can’t Be Signed
I added a unit test dependency to my “Application” target the other week in order to streamline my dev cycles. The idea was to ensure any changes I made to satisfy the integrated application bundle did not impact behaviors outlined in my test cases. (I use mini applications to perform my integration testing.) The problem here is that, even though this works well for simulator builds, an on-device build will fail as XCode attempts to sign your unit test target output. I haven’t discovered a work-around for this one yet so I’m gonna just punt and remove the test dependency from any targets meant to run on device.

I’ll trow up more as I find them…

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…