Amigo 1.1 – Now in iTunes!

Amigo 1.1 – Now in iTunes!

The next revision of Amigo (1.1) is now in iTunes, here.

This version has been tested with OS 3.0 and can now upload photos to FriendFeed.

Check it out!

Everybody Has a Theory on Why X is Killing Y

Everybody Has a Theory on Why X is Killing Y

This morning, the running “theme” in my reading seems to be “x is killing y”; “free” online content is killing publishing, the “hacker” mentality is killing the American coder’s employability… you get the idea.

If there are common elements running throughout all of these articles in my stream this morning they are sustainability, or rather, the lack of sustainability – and the disappearance of value.

We have accustomed ourselves to the idea that we can get something for nothing.  Or for very little.

You want cheap development? Hire overseas or hire a student.  Better yet, have an intern do it, for free.

You don’t want to watch commercials? Set the DVR and fast forward to your hearts content.

Pretty soon we’re giving each other haircuts on IOUs and no one is paying for anything, because we have mistakenly placed our emphasis on what everything costs rather than upon the value returned.

My car’s battery died this weekend upon returning home from a long twelve hour drive.  I could have had AAA tow the car home and go out later and buy a $80-$90 car battery, or buy a $125 battery right off the AAA truck and be on my way.  From a cost perspective, the “better” alternative would have been to have someone take me to a parts store and pay a cheaper price; I opted to buy the more expensive battery off of the AAA service truck, because of the opportunity value of (a) getting out of the blistering heat sooner rather than later, (b) getting the ice cream I just bought home, and (c) having a new battery in 30 minutes rather than a couple of hours later.

By being shortsighted in our rush to minimize cost at the expense of value, we are wreaking havoc on the quality of the goods and services we receive.

I read in the local business journal where a prominent hotel has released an iPhone application.  The application was one that I was asked to quote upon last year, and I did so with an estimate of about 3-4 weeks of development and with a price commensurate with that effort level.  My pricing reflected getting the application to market in that 3-4 week period, production ready and in the App Store.

I was fairly roughly rebuffed for my estimate, despite my bona fides as a commercial iPhone app developer.

As it happens, the hotel had students create their commercial application.  For free, I’m assuming.

Of course, the opportunity value of taking six months to create the application versus having the application to market in four weeks is not zero.

The “cost” may have been infinitely cheaper, but the lost opportunity of having an app out six months earlier?  Ask the first iFart application dev how much money he made, versus the dozens of imitators who followed suit thereafter.  Is the business environment today better than it was six months ago?

There are times when I seriously question whether I’m in the right business.

But then I remember, we’re all really in the teaching business.  I need to obviously be a better teacher.

And remember: Those that can, Do.  Those that can’t, Teach.  And those that can’t Teach, Teach PE.

Cheap Gas! New Features

Cheap Gas! New Features

In addition to the “Tweet ‘Em!” button, I’ve totally revamped the SOAP client, so it should be faster getting data from (I had been using a proxy to assist with the SOAP calls, but bit the bullet and moved the SOAP client entirely on the handset – so, remove the intermediary proxy means a more responsive app).

I also optimized the scrolling so the UI experience should be a lot better… plus I prettied up some of the plain jane buttons.

I’m very hopeful this release gets approved quickly, because I really think people will dig the twitter option.  A lot.

Ageism in Professional Development

Ageism in Professional Development

I’ve been meaning to do a post on ageism and professional development for some time now.  Perhaps next week when I take a little off time with the family in Nashville.

Having been a professional developer (contractor, employee, manager, owner, entrepreneur) now for some twenty-five years, I have more than a few idle thoughts on the subject.

Part of my reticence on writing about the issue (which is very real) is not wanting to come across as just another bitter old guy crying about one thing or the other being better when I was a younger guy.  I’d rather write a heist novel – nobody’s ever done that, right?

Any way, trying to coalesce my thoughts into a semi-worthwhile take on the subject.  Meanwhile, if you have thoughts on the subject (or war stories), please feel free to leave them in the comments below.


Amigo Sorting Change

Some Upcoming Changes for Amigo

Some Upcoming Changes for Amigo

A few of the changes coming in the next revision of Amigo.

A Little More on NSDateFormatter

A Little More on NSDateFormatter

NSDateFormatter (as mentioned previously) is tremendously handy.

Unfortunately, it is rather sparsely documented.

I’ve had the opportunity to use it in a number of different projects; however, in each one, I’ve had to use a bit of trial and effort to actually get strings to decode into a valid NSDate object.  All the while wishing for better documentation.

Today, I ran across this blog post that does a good job of consolidating format strings for NSDateFormatter in one place.  I thought about adding my own comments to this post, but I believe the original does the topic enough justice.  Check it out, then see my version of a helper function which I use in the TweetPhoto iPhone App.

If you plan on writing an iPhone interface to any of the Social Media APIs (Twitter, FriendFeed, etc.), you’re gonna wind up (at some point) needing to implement some helper function for NSDateFormatter.

NSDateFormatter and Twitter

NSDateFormatter and Twitter

The NSDateFormatter class is super handy for scanning incoming text dates in order to create a NSDate object, so that you can then use for other date manipulation.

As handy as it is, it is not as well documented as one would hope.

As a bit of a teaser, I’ll list a version of a NSDateFormatter helper function that will take dates from the Twitter API and convert them into NSDate objects. I will flesh out the details behind the function in a post to come Thursday or Friday.

NSDateFormatter Helper:

-(NSDate*)dateFromTwitter:(NSString*)str {
static NSDateFormatter* sTwitter = nil;

if (str == nil) {
NSDate * today = [[[NSDate alloc] init] autorelease];
return today;

if (!sTwitter) {
sTwitter = [[NSDateFormatter alloc] init];
[sTwitter setTimeStyle:NSDateFormatterFullStyle];
[sTwitter setFormatterBehavior:NSDateFormatterBehavior10_4];
[sTwitter setDateFormat:@”EEE LLL dd HH:mm:ss Z yyyy”];
return [sTwitter dateFromString:str];

Amigo, an iPhone Client For FriendFeed… Now On iTunes!

Amigo, an iPhone Client For FriendFeed… Now On iTunes!


Amigo is now available on iTunes!

Home Screen
Home Screen
Geo-Tagging Pics on the iPhone: Easy AND Hard

Geo-Tagging Pics on the iPhone: Easy AND Hard

Well, over the weekend, I made some progress with my woes of getting geo-tagged info from pictures on the iPhone.

I wound up writing my own analog version of the camera roll picker, and it came out really nice – I was able to read pics from the phone’s DCIM directories for pictures and screen grabs.

But more importantly, I was able to read the EXIF information from the photos, which the API picker strips from view.

Happy, I soon found myself to be deluded – because any image I took with the image picker controller’s camera setting also stripped EXIF information when saved to disk.

After much pain (which I’ll detail in a future post) my solution was the following:

1) Write the picture taken with a camera to disk using the Apple API. This allows the API to find out what the next picture should be named (not as easy as just looking for the highest named file – for example, what if there are no pics on the phone? You would think that the number would be IMG_0001.JPG, but the iPhone “knows” – somehow – what the last picture taken actually was. By calling the API, you get the phone to always tell you what the next file name should be.

2) Now that you have written a JPEG using the API (and really, also a Thumbnail 75×75 JPEG as well), delete that image.

3) Write your version of that image, with the appropriate geo tags from the CoreLocation services.

That is the 10,000 foot version of things. In reality, this little feat of mimicking the built in camera controllers turned out to be a royal pain in the ass.

But at the end of the day, I can take pics, store geo tags, and read geo tags from the iPhone in a way that looks just like the documented uiimagepickercontroller interfaces do.