It was so very cool to get a behind the scenes peek at what was going on with a group of people making a top notch game. Other developers began doing this also, and soon there was a nice little ecosystem of plan updates flying around. This was all pre-RSS.

Over time the .plan file fad kinda fizzled out and died. But now with the rise of twitter, it seems like it could see a come back. True, 140 characters is not a lot of room to explain certain technical issues, but John Carmack’s tweets are a step in the right direction. I’m glad he’s back.

This reminded me of something I heard about back when the iPhone was just getting started: The German Tank Problem.

Its basically a way of statistically estimating the maximum number of “items” that have been produced based on the serial numbers of the item. This method works when the serial numbers are in sequential order, and basically allows you to produce a somewhat realistic estimation (as opposed to a wild-ass guess).

Estimation is one of those skills that most people (myself included) could stand to improve a little bit. In the wikipedia link above, this is shown by the intelligence estimates the Allies had for the number of tanks the Germans were producing in the middle of WWII. The initial estimates were really high (1,000 per month), but using statistics based on the serial numbers of crankcases from captured or destroyed German tanks showed that the number might be lower (around 200 per month, or 1/5th of the original. After the war when the factory records were looked at, the true number was a lot closer to 200 than 1,000.

Math FTW

The formula is pretty easy:

N=m + (m/k) -1

Where m is the largest serial number observed, and k is the number of serial numbers seen. The variance is roughly equal to:

(N^2)/(k^2)

Which means that the standard deviation is roughly:

N/k

So, how does this apply to the iPad’s initial orders? Based on the data points of 2 known orders spaced 50,000 numbers apart (keeping in mind these order numbers also probably included orders for items other than iPads). So plugging those two numbers into the equation we get N=

>>> m=50000
>>> k=2
>>> N = m + (m/k)-1
>>> N
74999
>>>

Wow, almost 75,000… That seems like a really big number. The question we should then ask ourselves is “How realistic is this number?” Using the standard deviation and variance we could find out how spread out our numbers are:

>>> (N**2)/(k**2)
1406212500L
>>> N/k
37499
>>>

Wow. Those numbers huge. And that is a very bad thing. The bigger the standard deviation and variance, the more less accurate the estimation. Another way to approach this analysis is to look at the confidence interval and see how big it is. The wikipedia article has a handy formula for finding the confidence interval which leads us to the estimation that there are (based on k=2 and m=50,000) between 50,000 and 225,000 iPads ordered!

Those numbers are lying

Why? There’s two reasons: The main one is that our sample size (of 2 orders) is waaaaaaaay too small. Its like trying to guess how big your grocery bill is by averaging the price of two items, and then multiplying it times the number of things you bought. That estimation will be way off.

As an example, if there were 20 orders to work with (k=20), the high end of the confidence interval would shrink to 58,000. But that leads to the second reason why we can’t trust these numbers:

We don’t know the lower bound.

In other words, yes, there could have been 50,000 orders between the first and last data points. But what if only half of them were for iPads? That would mean that m is actually 25,000 which would drastically skew the numbers down. Remember that N that was almost 75,000? With m at 25,000 (and keeping k = 2) N drops to 37,499 which is half the original estimate!

So how many were sold?

That’s a really good question. Knowing Apple and how people love their products, I bet they sold a TON of iPads. But based off these rough numbers we see in the news, we can’t really draw a good conclusion. We can get a couple of estimates which are better than nothing, but they are so numerically shaky (huge standard deviation and enormously questionable confidence interval) that they strain believability. More data points will help establish a upper bound (i.e. the estimated maximum number sold), but without a lower bound to keep us grounded the numbers will still look really huge.

If you are seeing weird errors in the console when you run the application (specifically “Could not connect the action <your_action> to target of class <your_AppDelgate_class>”), here’s what it probably is: In the AppDelegate python file that XCode creates it uses spaces to do the indentation of the methods.

I hail from a land where tabs are used for such tasks, and the use of spaces is look down upon in much the same way that pick ones nose in public is.

At any rate, what’s happening is when the code is compiled/run the python interpreter is not recognizing the new methods that I put in (using tabs to indent) and instead of giving me a warning about inconsistent indention, it fails somewhat silently in that it groans it can’t hook the action up to the class and that’s it. It wasn’t until I turned on the invisible characters that this occurred to me that it might be the root cause of my problems.

Once setting all of the indentions to be the same, I chose tabs, everything worked like a champ.

By the way, if you are looking for some tutorials for PyObjC in XCode 3 (there are a ton of XCode 2 tutorials out there, but things have changed ever so slightly in 3), be sure to check out these links:

• PyObjC Hello world for XCode 3
• PyObjC Resources

For starters I created a new XCode project, ran it to make sure it could build, and then decided to check it in to svn so that I would have a “clean” starting point in case I ran into problems. This is how I normally work in other IDE’s, and I’ve never had a problem. Until today.

After setting up the repository in XCode I couldn’t find how to set the project so that XCode would “know” it was under version control (or SCM as XCode refers to it). If you look at the project’s properties, there is a drop down list the lists the available repositories (or it offers to let you set up a new one, which is a nice shortcut). However, the repository I just added is grayed out. After a half hour of trying various “obvious” things I gave up and googled around.

It turns out that XCode can’t create and then check in. The project has to be put into the repository, then checked out before XCode will recognize that it is under source control. Very unusual, but what ever, I decided to play along.  I used XCode’s svn browser (which isn’t half bad) to upload the code, then deleted the project and checked it out.

And right about then is when it became obvious that I was traveling the wrong way on a one way street. Here’s an executive summary of what I found so very, very, very wrong with XCode’s SCM integration:

1. I had to create the project, check it in, then check it out for XCode to realize that it was under version control.
2. Although XCode has an svn repository browser that allows me check in and out the code, it doesn’t seem to know anything about XCode projects as it checked in the build directory without asking. For me (and a lot of developers I know) the last thing I want in version control are files that are going to change constantly (i.e. object files). Checking in a finished version, fine. Checking in a ba-jillion intermediate files: fail.
3. After checking out the project, XCode began complaining about there not being a lock on a file in the build directory. The error message actually said “This might be a bug, please report it.” Sorry Apple, I’m a nice guy, but I’ve got limits. This seems like something that shouldn’t happen on a fresh project (i.e. all boilerplate code, I haven’t done a thing to the project yet).
4. Deciding that I might be slightly smarter than the computer, I decided to delete the build directory in the repository. I tried to refresh the project to let it know there was a change it might need to be aware of. Instead I was made aware of the fact that there doesn’t seem to be one central view of what’s changed for the project. The near-useless SCM menu item in the project reported that one file had change, and I could not seem to get it to even look at the project as a whole. Maybe I’m spoiled by the way Eclipse handles this situation (which provides a bunch of clues in different areas, but all of which lead to a pretty straightforward GUI for dealing with changes). Even TextMate handles this decently (just not as good looking as Eclipse).

By this time I just gave up. I removed the repository connection from the project settings, and decided to just go Command-line for doing my updates/commits. Life’s too short to be chasing my tail on stuff like this.

I was using Pixen which is highly regarded and does just what I need it too. Buuuuuut… I can’t get the program to run more than a few minutes without a crash. And that just really bums me out because it seems like the perfect program. Sadly, I’m not the only one having this problem, posting around the net seem to indicate that this is a common issue.

And unlike Windows, the Mac doesn’t seem to come with any simple programs a-la Paintbrush. What’s up with that? I realize Apple is all about minimal cruft and what-not, but this really takes it to an extreme.

For the moment I’m trying out tileeditor which is a pretty minimal editor, but at the same time seems to work pretty well. (Although as a side note I would like to point out that you need to start the editor in the same directory as your artwork, otherwise it seems to try and save to the wrong directory. Every time I did this is put _tmp and the front of the path, which of course doesn’t exist. I’m not sure if this is a Mac specific thing, but just starting the program in the art directory seemed to get around this issue.)

Last week at an Apple ADC Tech Talk I saw an example of Quartz Composer.  I had only vaguely heard of Quartz Composer before and hadn’t really looked into it. It turns out that it is a very useful tool for building a neat GUI quickly, and is available as part of the Xcode tools. After getting home from the talk I played around with it and was able to build lots of cool demo-type apps very quickly.

And then… I discovered that it can be integrated into Cocoa apps very easily. I mean, I found this great tutorial on the Apple Dev site, and within 5 minutes I had a Quartz Composer (QC) window running in my test app along side my OpenGL test window. And not a line of code was written. The absolute bets news is that you can expose the internals of the QC window to the Cocoa framework and then manipulate the QC object from your program!

That just rocks so hard. Now I can focus on the mechanics of my program instead of worrying about the mechanics of OpenGL. Of course, the QC isn’t 100% efficient as hand tuned code, but for most of what I want to do with it, its perfect! Thank you Apple!

As a side note, if you are interested in doing Mac development and you aren’t a member of the ADC (Apple Developer Connection), you really owe it to yourself to go sign up for one of their free accounts and check it out. Its a great resource for all things Mac and OS X.

I don’t really know what I was expecting, probably a hard time as that’s what I usually get at stores when I try to get something fixed, but this visit was as smooth as silk. I had to wait a little bit past my appointment time, there was a ton of people in there and a couple of the problems looked bad, but once I was called up I was done in less than 10 minutes!

I explained to the “genius” (sorry, I didn’t catch his name) what was going on, and what I had tried to fix it. He booted up the Mac, confirmed the problem and then brought out a new battery. He plugged it in, booted the Mac and then it showed there was a battery and it was charging. I was so happy (I was afraid it was the logic board) and when I asked what was the problem with the battery, I was told that the chip in the battery was probably dead.

The best part about the whole experience was that the battery was covered under the warranty, so there was no money out of my pocket! Woo-Hoo!

As a side note, after the iPhone announcement the other day I heard that Apple would be providing the customer support for the phone, not Cingular. Customer support is a major undertaking, and I was really wondering how Apple would handle this. Granted, phone support is different from one-on-one support, but everyone I saw at the Apple store today was really nice. Granted most of the customers were nice also, but a few seemed on edge (since their equipment was going to have to go into the shop to get fixed). But no one was steamed or looking unhappy with how they were being treated. Contrast that with most cell phone stores, and you’ll see a big difference. Hopefully Apple will be able to maintain that level of customer satisfaction and service when the iPhone rolls out…

When I added the file(s), I did so by clicking on “New” and selecting a C++ file under “BSD” because it was the first option that I saw. It turns out when you do this, the Cocoa project settings will attempt to compile the files as Objective-C files (which they are not). This results in cryptic messages about a “parse error before” in you .h file.

The solution is to right click on the .cpp file, select info, then change the file type to “sourcecode.cpp.objcpp”. This tells XCode to use the Objective-C++ compiler to build the files, and from then on everything *seemed* to work ok. I’ve never worked with Objective-C (or Obj-C++), so I’m figuring this out as I go. If something bad seems to happen, I’ll post a follow up to let everyone know.

A while ago I wrote a small GUI app in python using Tk (Tkinter to be specific). It worked pretty good on Windows machines, which is where I was running it at the time. About a year later I tried to run it on a Mac, and the results were a little surprising. It did not look good. It seems that there are some differences between the Tk stuff on different platforms.

Every since then I’ve been wondering if there was a more platform independent way of making Python GUI apps. I’d heard a lot about wxPython, so I decided to give it a shot. The documentation is pretty good and the demos that come with it helped me get up to speed pretty quickly. (Plus the API reminded me of some work I did in the Win32 world a few years ago, and surprisingly, that helped me get things “working” faster than I think I would have otherwise.)

Anyways, I built a little app to visualize an idea I’ve been having for a few weeks ago. Again, on Windows machines it looks great. Today I remembered that I hadn’t run it on a Mac yet. With a little bit of trepidation, I grabbed the code and hit run. Lo-and-behold it runs great on the Mac. A little bit slow on the re-draw, which probably has more to do with how I wrote the event handlers, but it ran and looked just like it does on the Windows machines.

Thus I have concluded: wxPython rocks.

In case anyone out there is wondering about the pro’s and con’s of getting an ICBM (Intel Chip Based Mac), I thought I would toss out my thoughts on the topic:

• Speed- It is sooooo much faster than the old PPC machines. Don’t get me wrong, the PPC machines are fast, but the duo core aspect of the MacBook makes everything that much faster.
• Ease of Upgrade- I bought 2GB of RAM and dropped it in the machine after I got it all set up. That has made all the difference in the world. The Mini only had 512MB, and I think that really holds it back. Being able to get 2GB for less than $200 was a no brainer, and the performance is phenomenal.
• Heat – The MacBook gets hot. Real hot in some spots. The Mini is one of the best combinations of speed and coolness that I have ever seen. Most of the time I don’t have the MacBook on my lap, but I’m still concerned about heat.
• Compatibility – The Intel based machines are supposed to support the old PPC binaries, and for the most part I have found this to be good. However, I did find two glaring problems right off the bat: Eclipse and NeoOffice. Both of these programs would not start up. It turns out that Universal Binaries are right around the corner for both. I thought it was odd though that both apps (which are Java based) wouldn’t run. It turns out there is some JNI in the background and that’s where the problems were. Once the Universal builds are released (I think Eclipse is already out with its 3.2 release) that should solve those problems. Also, I’ve found that PyGame isn’t 100% functional on the MacBook, but I’m thinking I might have done something to cause that. (More on that later)
• Form Factor – Both the Mini and the MacBook are just slick looking machines. Thin, compact, yet packed with power. Its great! I recently took the MacBook on a trip and it was a breeze to bust it out and knock out some code. The built in Wi-Fi is great, though sometimes I wish I could get a little more detail out of it (Windows machines have a really good interface for its WiFi stuff, its great for users who want more advanced information).

Overall I’ve got to say the MacBook just rocks.