The software isn’t finished until the last user is dead.
Anonymous Support Group Member

The first 90 percent of the code accounts for the first 90 percent of the development time…The remaining 10 percent of the code accounts for the other 90 percent of the development time.
Tom Cargill

Why do we never have time to do it right, but always have time to do it over?
Anonymous Code Monkey

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
Brian W. Kernighan

So the iTunes App Store has been out for a little over a month now and we are starting to see some initial sales numbers. The remarkable thing is that some of these numbers are rather, well, remarkable. Let’s look at a couple examples:

1. Tap Tap Tap has posted their (Semi)Final Numbers for July with the juicy takeaway being that their two current iPhone applications brought in $75,177.38, leaving them with $52,815 after Apple’s cut. Simple math here shows that they would be on pace to make $633,780.00 during the next year for just these two applications provided they maintained this pace. Of course, they are already hard at work on their next two applications as detailed in their post here.
2. Mac Rumors has posted that a smaller developer named MintApps is currently making a more modest but still impressive $158 a day from their nutrition application. The significant datapoint here is that this particular application is currently only ranking in around as the 800th most popular application on the App store
3. NeoSeeker reports that overall App sales for Apple are currently raking in $1 million a day.

The really crazy thing is that we are only at the very beginning of the app store. As adoption grows, well you get the picture.

Why Python? Well Google, xkcd, and Mark Pilgrim seem to like it. For me, that’s actually good enough right there. And why Twitter? My good friends Shawn Smith and Mike Lambie think it’s a pretty cool service and will probably keep growing. So I figure it’s worth learning the Twitter APIs.

According to Wikipedia, an Internet Bot is a software application that

“performs tasks that are both simple and structurally repetitive, at a much higher rate than would be possible for a human alone”.

The bot we will create today will get a list of all the people a user is following (their “friends”) and then will compute the friends-to-followers ratio of each of those people. Why would you want to do this? Well some people (myself included) feel that a user’s ratio tells you a lot about them. Follow a lot more people than are following you, and you’ll be labeled a spammer. Really interesting people have at least as many people following them as they are following. And some of the best users on twitter maintain a close to 1:1 ratio of friends/followers. So ratio is important, and a bot that can tell us user ratios quickly might be good for other things {insert evil grin here}.

So now that we know what we want to do, we need to figure out how. If you are an experienced programmer you probably know several languages (and maybe you already know Python). You should be able to follow along fairly easily. If this describes you but you’re brand new to Python then I also recommend reading Mark Pilgrim’s book Dive Into Python. It’s available free online and full of Python-to-other-languages comparisons that make the process of learning Python very fast.

If you’re completely new to programming than have no fear, Python is a great first language. In fact, the creator of the language thought it would be useful in high schools as an introduction to programming. A great tutorial list for soon-to-be-programmers is available at the Python website.

In part 2 of this series we’ll get into the meat and potatoes of creating the bot

Firstly, frankly, hell yes. The apps that developers have already built are incredible and support from Apple will make them even better. As development becomes easier and the barrier to entry is lowered we will see more and more great extensions to an already great device. People will even plug some seemingly obvious “feature holes” and iPhone sales will increase, the platform will become more more ubiquitous, and the cycle will continue.

Still Apple is being very careful in how and when they do this. Citing concerns for the stability and security of the iPhone, it has taken a good 10 months since we were introduced to the iPhone to even get confirmation that native development would be possible and endorsed. Steve Jobs has stated that one strategy for protecting the iPhone would mimic a similar strategy used by one of Apple’s competitors.

Steve wrote:

Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer. While this makes such a phone less than “totally open,” we believe it is a step in the right direction.

While I understand where they are going here, Nokia is a terrible comparison. Nokia has never been in the position to create a device with this much potential to change how we use computers. Looking to them on how to manage this is like asking the safety guard who helps your kids walk to school to plan out the complete traffic flow timing scheme for your home town. They are good at what they do, but just because they also allow development on their devices, mobile computing is NOT what they do.

There are a whole hosts of complications with using digital signatures. On a major open source project, does the whole project (or at least the people who can commit) get access to the signature? If so, it’s easier to compromise a signature, negating all the supposed benefits. If the signature can only be used by a single developer, what happens if that person leaves the project? What happens on branches and forks? Is there now a new possibility for identity theft in order to gain access to an audience? New phishing schemes? And on and on…

There is a better solution. Treat the iPhone like what it is — a computer. Make it easy to reload, backup, etc. Rely on requests for privilege elevation like how OS X does now. Hey, here’s a crazy idea:

+ =

Give iPhone owners a reason to buy a Mac, just like you did with iPods.

Make the right choices here Steve. Be a leader, set some compelling precedents, and usher in a new age for computing.

So I think, ok this works like a charm, now lets extend this and add Facebook support! Oh wait, already been done here. Well, I remember hearing about a new Facebook API for supporting status updates that was released after that last script version which relied on a mobile hack. Ah yes this looks like it, I’ll build something using the official Facebook API and all will be good!

But it turns out that’s not going to work because first I find this TechCrunch article which points out a problem with my approach and the Facebook terms put the final nail in the coffin. The same policy that applied to this method would apply to Soeren’s method and any anything that I create because they all violate those ridiculous terms of use.

What kind of crap is that? I can build services that interact with Facebook, provided I only do it on Facebook’s site.

Oh yea that’s almost a win.