The end of free money?

When I started ReceiptWallet, I setup an Amazon Affiliates link to see if I could make some money on the scanners I recommended. Turns out, this was a smart move as I was making decent money for no work. After I sold ReceiptWallet, I get my links around on this blog and while I don't make enough money to quit my day job, I make enough to goto dinner a few times a year. I'd rather have the money in my pocket than someone else's, so I keep the links up.

Unfortunately, Amazon notified California based affiliates today that they're cutting us off if the state passes a law regarding online commerce. The law is a bit of duplicate regulation as California residents are already required to pay a use tax for goods purchased out of the tax; it appears that the law is putting the burden of collection on a company that doesn't even have offices in the state. The law argues that affiliates constitute a California presence for Amazon and thus it has to collect taxes.

So us little people get punished because the state can't enforce the current law on the books. Lovely.

A blast from the past (PDAs)

My wife and I have started watching 24 on Netflix and have become quite addicted to it. Since we're behind the times, we don't have to wait a week between each episode, instead we can blow through 2 or 3 episodes a night.

The technology in the show is kind of humorous as they've been using Palm OS based devices, at least in the early episodes. So far I've seen the Samsung SPH-I300 as well a Handspring Visor. I even caught a glimpse of SplashPhoto on the Visor!

This brings back memories of all the technology I thought was so cool way back when. Comparing it to today, it seems so primitive. If you look at the first Palm OS based smartphones, the way they handled data was quite primitive. Basically they "dialed" a special number (00 in many cases) to trigger the packet data connection. This, of course, prevented voice calls during the time. Then using the stylus seems so crude. Let's not forget the displays; today's devices have full color, awesome looking displays. The displays way back when were grayscale screens that were not pleasant on the eyes. The devices were not very robust and resetting the devices was a common occurrence; I got rid of my Treo on Sprint when the battery died because the device crashed and I hadn't noticed it.

I can't wait to keep watching to see what other tech memories come back!

Unit testing framework and Asynchronous calls

In my quest for information on writing test cases within the confines of unit testing framework, it became evident quite quickly that the tests are synchronous and asynchronous calls will never complete thereby rendering the test case useless. Since all networking code should be asynchronous (in my expert opinion), I had to find a way to handle this.

After a few quick searches, I found that my issue wasn't uncommon. The most straightforward answer to this question is some code called AssertEventually by a developer named Luke Redpath. Straightforward in that the calling method is not complex; however, there is a big chunk of code behind it that has me a little concerned.

The more I've read about this, the more it looks like I have to spin my own run loop during the test such as described on a mailing list like this:

while (!_isDone)
{
	[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1.0]];
}

While this should work, it isn't the most efficient way to do things, but at this point, I'm not sure there are other options.

Utility of Unit Tests in software development

Over the years, I've read a little about unit testing and heard it talked about at WWDC once or twice, but never thought much of it and didn't see much of a need for it. Recently I've started to look at it again and have done a little research on the concept. I found a reference that seems to sum up the flaws of unit tests.

A test is not a unit test if:

It talks to the database
It communicates across the network
It touches the file system
It can't run at the same time as any of your other unit tests
You have to do special things to your environment (such as editing config files) to run it.

Of all the projects I've worked on over the years, most, if not all, of them have had external dependencies such as network connections, handheld devices, or files on disk and therefore most of the unit tests I'd write adhering to the above rules, would barely exercise the app. If I wrote unit tests to simulate networks, I'd have to hard code in test data which lets us test one path in our app if we assume the data on the network never changes which is quite unlikely.

So, effectively unit tests are useless. I'm sure that someone will argue with me about this point, but if we assume I'm correct in the limited utility of unit tests, can tests be written that are useful?

Of course, we can write tests using the unit test framework (like OCUnit in Xcode 4). The test aren't unit tests, they're more like functional or integration tests that have external dependencies. This will let us test error conditions and see how different parts of the code will act in a real world environment.

It appears that Wil Shipley of Delicious Library fame seems to have similar views to me on this topic. However, I'm not opposed to functional or integration tests.

I don't discount the utility of writing "tests" and will be writing some to test chunks of my code, but for the projects I've been on and expect to be on, unit tests have very limited utility and are possibly a poor use of limited resources.