Mojomonkey Coding

Most people use Unit Test to run automatically during the build phase of the project. They provide built in regression testing, allow developers to analyze the code while writing the test, etc. One over looked analysis is seeing what sort of set up is required just to get the test to run. If your Unit Test requires defining and initializing of a large number of external systems (especially those that on the surface don’t seem like they should have anything to do with the system you are testing), you have a design issue. Your application is not Orthogonal, and perhaps a redesign is in order. This is particularly true with static elements of a system (this include Singeltons). As a full suite of tests may rely on the state of an external system not changing, which can’t be guaranteed with static globals.

So, next time you are writing a unit test, take a hard look at your set-up phase and make sure it doesn’t seem overly complicated. If it is, your system is not orthogonal and you are going to have problems if you don’t take care of them.

I’ve universally moved all my editors; Eclipse, TextMate and Xcode to using 16 point font. I’ve had to defend a few “old man” accusations, but at the end of the day, eye strain is NO WHERE NEAR as bad as it was with the standard 12 point font. I can sit further back from the screen, more comfortably and read the text with out effort. Try it, you might like it.

In Predictably Irrational, Dan Ariely discusses Procrastination and a human beings tendency to under estimate their resolve and ability to stay ahead of the game. During an experiement he took three of his classes and gave them an assignment to write three papers over the course of the term.

“As they settled into their chairs that first morning, full of anticipation (and, no doubt, with resolutions to stay on top of their class assignments), the students listened to me review the syllabus for the course. There would be three main papers over the 12-week semester, I explained. Together, these papers would constitute much of their final grade.”

From the outset the students understood the importance of these papers, they would pretty much amount to their final grade. Each class was given a different schedule, the first was given three due dates (4th week, 8th and 12th), the second class was given a sheet (a tool) with which they were to set their own deadlines and turn that in. They would be held to these deadlines. The third class was told to turn all three in at the end of the semester, they could turn papers in early, but there would be no extra credit doing so. The class that had the equal due dates set for them did the best, those that set their own due dates were second and those that turned them in at the end of the semester did the worst, by far.

“What do these results suggest? First, that students do procrastinate (big news); and second, that tightly restricting their freedom (equally spaced deadlines, imposed from above) is the best cure for procrastination. But the biggest revelation is that simply offering the students a tool by which they could precommit to deadlines helped them achieve better grades.”

So, the best way to achieve your goals is to have some Draconian force from above giving you hard but reasonable deadlines. Failing that, give people the tools they need to combat the need to procrastinate.

Agile Development has had a huge surge in the last 5 years or so, to which I believe owes its success by helping people fight off the tendency to procrastinate. Scrum and other Agile methods give developers the tools to set the appropriate deadlines and meet them. Imagine if Agile is the second class in Ariely’s study with Waterfall being the third.

Waterfall development defines a rigid structure of Gather Requirements, Design, Implement, Test, Maintain. However, it doesn’t provide a good mechanism for applying appropriate deadlines (that is up to the higher level management, who typically just want to see the finished product by a certain date.) Therefore, the development team may have a couple months before they have to show anyone anything. Making it that much easier to put things off early in the development cycle.

While, Scrum instill shorter milestones (one month or less, typically three weeks) with something demonstrable at the end. There is the first tool to fighting procrastination, there is less time to do so. Secondly, every developer is given a larger task (Story) and breaks them up into smaller tasks, typically a day or less. With this, it has given each developer the tools they need to set their own deadlines with daily tasks, further reducing the time to procrastinate. Thirdly, daily meetings with peers are used to update the entire team, quickly exposing any potential procrastinators out there.

Agile has a multitude of benefits, helping people understand their work habits and tendency to procrastinate being only a small part.

One issue with JSON that has caused problems both here at work and with Celery is the fact that a list of elements is defined by the number of elements. That is, if there are no elements it will be a NIL entry in the Dictionary, one element will return a Dictionary and multiple entries will return an Array. So, programmatically, you don’t know what you are going to get at compile time.

Fortunately, the WebService you are using is will documented… right? Secondly, you are only ever going to get 3 possible results: NIL, NSDictionary or NSArray. As such, you know when something is a list, and can handle these special cases. This is how I am managing it in Celery. If there are better ways, please, let me know.

If the WebService Specification says something might be an Array, I will also treat it as an array. If it’s a single element, I create an array and put that element into it. That way, my business logic only ever has to deal with one type (array).

id object = [dictionary objectForKey:@"key"];

NSArray* myArray = nil;

if([object isKindOfClass:[NSDictionary class]]) {

    myArray = [[[NSArray alloc] initWithObjects: object,nil] autorelease];

} else {

    myArray = (NSArray*)object;

}

I banged my head against figuring out how to make use of third-party frameworks. Unfortunately, this seems like a task that most developers expect users to instinctively know how to do and never explain it otherwise. I was somewhat frustrated and having trouble getting my project to make use of the third party Framework for both compiling and running. After some banging my head on the wall, a post on StackOverflow and a few bruises later I got it working.

The first thing that I needed to do was build the framework. The particular Framework I am using is MPOAuthConnection which provides an SVN link and a project. I, therefore, needed to build the Framework in that project. Xcode is nice enough to put Products in the item list. I simply dragged the MPOAuth.framework product from the MPOAuthConnection Project to my Celery Project. Dropping it into the Linked Frameworks section and choosing to copy the files.

Using the proper imports, this admittedly tripped me up a bit, because I was working in the project and doing “file.h” imports rather than the proper <library/file.h> imports, my project would compile.

However, I was getting odd errors on running, where it couldn’t find the files needed (and some strange memory problems). Turns out, when you add a new Framework, you also have to have the build system copy the framework into the Application product. To do this, you need right click on the target for your application, Add -> New Build Phase -> New Copy Files Build Phase. The only setting that needs to be set is the Destination must be set to “Frameworks”.

Here is the key element that I could not figure out for about an hour. You must drag the Framework from the Linked Framework to the new Build Phase you just created.

Viola! You should be set.

The first task I gave myself when writing the Celery Application is to obtain nutritional information for various foods. I’ll need to provide a means to request a list of food that matches a search query and a way of getting more information about a particular food from that list. As I mentioned before, I found the FatSecret REST API, and decided to use this for these two requests. FatSecret supports “foods.search” and “food.get” methods that meet my needs. FatSecret also uses oauth for authentication.

My list of tasks were as follows:

1. Obtain the necessary keys to communicate with FatSecret.
2. Find a Cocoa Library to use oauth.
3. Establish a connection and call methods as needed.

1. Obtain the necessary keys to communicate with FatSecret. This was easy enough, simply went to this site and registered the application I was making. This provided me with a Public Consumer Key and the applications Private Key. These keys were emailed to me, and they were ready to be used.

2. Find a Cocoa Library to use oauth. As I mentioned in a previous post, I found MPOauthConnection for establishing an oauth connection and calling methods on a REST Library. I downloaded the source using Subversion and opened the library. After running the Build, Xcode proceeded to lock up completely. All I got was the Beachball of Death. I stared at it, tried a couple more times, but could not successfully build the project. After awhile, I noticed that it was failing to proceed past the Unit Tests. I figured, I’m not modifying the Library, and therefore, don’t really need to run the Unit Tests. So, I opened up the Unit Test target and deleted it. Kicked off the Build and it succeeded.

I was going to start up the Celery project, but decided to go ahead and modify the existing test application to communicate with FatSecret.

3. Establish a connection and call methods as needed. The first thing that I had to do was match up what MPOAuthConnection expects to what FatSecret API expects, including slightly different nomenclature. I started by plugging in the values for the Base Host URL, Shared Secret and Consumer Key and the method to call. The method to call stumped me a bit, as the FatSecret sets the actual method to a parameter (method=VALUE). Where the method for the API is server.api. That really took me awhile to figure out. Secondly, the provided example had no usage of method parameters (making it a very flawed example, in my opinion). I struggled then to figure out the API to pass parameters, finding a Unit Test in code, I was able to figure this out and successfully make calls to the API, searching for a food, and getting information for that food.

The next step will be to build my own Celery project and duplicate this functionality in what will become my own Application.

Noel Llopis has released his slides from AGDC. He discusses how to get every bit of performance out of this little “Pocket PC” (hey, Steve Jobs called it that, so can I). Noel is the creator of Flower Garden and a guru with OpenGL ES and pushing the iPhone to its limits. This is a great read, and one of the primary talks I wanted to attend, although timing of the conference didn’t allow me to see it.

MacRumor’s obtained more info on OpenCL . What is particularly interesting is that on high-end MacBook Pros (with the GeForce 9600M and 9400M, in which only one is used at a time for processing graphics), you can make use of both GPUs. That’s particularly interesting, because on the MBP one of those GPUs is sitting idle, doing nothing. An app can now harness that extra processor. I’m still waiting for the first development tutorial to come out, I’m too lazy to read the white papers.

I am quite guilty of allowing myself to fall into the mentality that there is a solution to software problems that can handle all situations and solve every problem. Unit testing is certainly one of those things that I felt makes all the difference in the world and is a major requirement. When we started development here, I required full unit testing, used code coverage tools to make sure. However, over time I became quite lax on making sure everyone wrote their tests. Part of it was laziness (writing Unit Test is perhaps the worst, most boring aspect of any development), part of it was it was feeling like a bit of a waste, and lastly, it wasn’t catching errors. That’s right, if our Unit Tests were passing, then why in the hell are we having bugs reported?

Wil Shipley summed it up quite nicely here. He is quite opposed to Unit testing, and some of his comments really hit home for me.

There’s only three major flaws with this: (1) Essentially, to write a program that fully tests your program, you need to encapsulate all of your functionality in the test program, which means you’re writing ALL THE CODE you wrote for the original program plus some more test stuff, (2) YOUR PROGRAM IS NOT GOING TO BE USED BY OTHER PROGRAMS, it’s going to be used by people, and (3) It’s actually provably impossible to test your program with every conceivable type of input programmatically, but if you test by hand you can change the input in ways that you, the programmer, know might be prone to error.

These sum up what I’ve been starting to feel, but he drives his point home with

Unit testing doesn’t give you information on how common a bug is, which is the single-most important piece of information about a bug, followed very closely by its severity.

Now, in his first quote he mentions the fact that “your program is not going to be used by other programs”. This, of course, is not always true.

Bill Bumgarner counters with a good argument of when this case occurs and how unit testing can solve a problem.

So, it seems the answer is: Writing an API? Unit Test. Writing an App? Don’t waste your time.

EDIT

bbum made a comment about this post (although, when he attempted to do so, comments were broken), so I’ll update the post here.

[Ed:] Unfortunately, the mojomonkeycoding.com weblog’s comment system is busted. The author of that post missed the point. If he had been paying attention, he would realize that unit testing is critical in a well designed app in that you will have a model/control layer that is a great UT target.

I am a bit confused as to which point I missed. From his post he speaks of the benefits unit testing Core Data to allow applications such as Delicious Library to trust that they can read/write data successfully. That’s to be expected, as the author of a core library unit testing make perfect sense.

And that is the answer. A software developer like Wil — a totally user focused, user experience driven, engineer — may not see the value of using unit testing directly in their development efforts. However, that Delicious Library could use something like Core Data and does use all of the other technologies in Tiger would not be possible without the huge investment in Unit Testing by the various teams at Apple.

Right, so because you so diligently tested the core API that it is using, he is able to focus on the user experience. Therefore, he doesn’t need to write those unit tests, instead relying on functional tests and focus testing.

Perhaps, my conclusion was a bit overly generalized:

So, it seems the answer is: Writing an API? Unit Test. Writing an App? Don’t waste your time.

I can see how this statement may seem obtuse, as it was a bit tongue-in-cheek, and “App” should have made it clear that I’m talking about the End User Application (the application may contain its own APIs). However, I still feel that if you are writing underlying code that client’s use, Unit Testing make complete sense. But when writing a user facing application, getting it in front of user’s (yourself included) is better use of your time.

Lastly, all that being said, I am starting to swing back to the other side, thinking more about TDD, etc. As the tools get better to make this stuff easier it makes it more inviting.

Wil Shipley has a great article on heuristics and human beings. Delicious Library is an amazingly well designed piece of software, and some of the lessons taught in this article should be taken to heart. Apple products have, honestly, raised the bar on what user’s expect when interacting with it. His point of sacrificing 100% accuracy for substantial more usability is a great one. This particularly applies to iPhone Apps, as the truly great ones are those that you immediately pick up and just inherently know how to use. The iPhone is a “quick use” device. Few people sit down and use their iPhone for more than just a couple minutes at a time. So, any moment you steal from them to force them to learn how to use your app (input data, etc) you have greatly reduced your target market.