atomicbird

The next Iron Coder has been announced. This time it'll be a nine-day event instead of a weekend. The prize is an iPod Touch. And while the API hasn't been announced yet, it's going to be something new in Leopard.

If you read my previous post about expanding my product lineup, you know that MondoMouse was the ultimate result of the first Iron Coder. Since then I've participated whenever I've been able.

If you're a Mac developer, or want to be, this is a great event to take part in. The constraints of the event focus your attention on getting something done and ready to at least show to other people if not actually to release to the general public (and who knows, maybe it'll evolve into something you can release to the world). It's a good way to dive in and learn a new and unfamiliar API, a sort of friendly competition combined with a self-taught immersion course. Win or lose, I expect this Iron Coder will be most valuable to those with the least amount of time working on Leopard so far. If you're just now wanting to come up to speed with Leopard, participating would be a really good way to jump-start things.

It's also a good way to get to know other developers-- and not just any developers, but those who are actually motivated to try something like Iron Coder because it sounds like fun to them. The #macsb IRC channel (irc.freenode.net) serves as an unofficial discussion center for Iron Coder. It's normally a friendly competition, so you can feel free to ask for help along the way and usually get it.

So mark your calendars, and make sure you know your way around Xcode 3.

I previously covered Macaroni / Leopard compatibility. Basically, get version 2.1, which is a free upgrade, and read my previous message for more detail.

If you're using MondoMouse or Chimey though, you might well be wondering what's up. In short: the current versions of MondoMouse and Chimey work on Leopard as-is, so no upgrading is needed. As long as your Leopard install is one of the "upgrade" options (as opposed to "erase and install") you shouldn't need to do anything at all to keep using MondoMouse and Chimey.

Macaroni 2.1 is now available. This version differs from the last one mainly in that it works better with Mac OS X 10.5 "Leopard". The previous version seemed to work with Leopard, I didn't test the combination extensively. I strongly recommend that anyone who uses Macaroni upgrade to version 2.1 when they install Leopard.

System Requirements have changed. To use Macaroni 2.1 you must have Mac OS X 10.4 or 10.5, on an Intel or PowerPC Mac. Mac OS X 10.2 and 10.3 will not run Macaroni 2.1, although Macaroni 2.0.8 is still available from the Macaroni page if you need it for an older Mac.

This is a free upgrade for all registered users of Macaroni. Macaroni 2.1 can be downloaded from the Macaroni home page.

To Upgrade

There always seems to be a little confusion regarding how to upgrade Macaroni. Here's how you do it:

1. Install the new version.
2. There is no step 2.

People often assume that they need to go through a complex upgrade routing involving (at a minimum) removing the old version and (sometimes) mysterious rituals they expect are necessary to prepare their Mac. I try to make it as painless as possible but some people seem to expect the worst.

What may be necessary is to reinstall Macaroni after upgrading your Mac to Leopard. Depending on what options you choose when installing Leopard, some or all of Macaroni might disappear afterward. Just run the installer again.

A note on the release

I'm releasing this now rather than later because I've had a lot of people asking me about compatibility, which leads me to expect that many Macaroni users will be installing Leopard very soon. As I've discussed previously, Apple has not yet made the release version of Leopard available to developers, so I have not been able to test Macaroni on the version that will shortly be appearing in Apple retail outlets. However I've done everything I can to get Macaroni ready, and barring any major surprises in the release it should be fine.

I'd just like to thank everyone who took part in the Atomic Bird five year anniversary last week, including customers (both free and paid), blog readers, and those who contacted me directly by email.

Just a little snapshot to hint at how things went. This is how Mint shows recent traffic to this web site:

Wow!

I thought people might be interested in knowing how the whole one-out-of-five-free thing worked.

Step 1: Coupons

Free orders were managed with single-use coupon codes which would give a 100% discount on software in the order (CD-ROMs were not free). My orders are processed by eSellerate, and they have a system where it's possible to generate a long list of single-use coupon codes with the same effect and named with the same prefix. For example, "FIVEYEARS-0JL8JCVC" was one of the coupon codes. All of them started with "FIVEYEARS-" and the rest was random.

These coupon codes were set to be valid only for the week of the anniversary (and that one's been used anyway).

Step 2: Distributing Coupons

Giving out free orders to one out of five customers was handled by some custom PHP code on my web server, which would consult my order database to decide when it was time for a free order. I set this up as a web-store redirect script, and modified all of the "buy" links on the web site to point to it. The basic pseudo-code was:

1. See how many orders had been received since the start date
2. See how many free orders had been received in that time
3. If the number of free orders was less than 20% of the total, get a coupon code and give the person a free order.
4. Redirect the person to my web store, regardless of what happened in the previous step.

Because there's a delay from giving out a free order until it appears in the sales database, this meant that it was likely I'd end up giving out two or more free orders in a row. After one coupon code was given out, someone else might come along before the first person had a chance to use it, and there would be no new entries in the sales database. Free order (again)! Over the course of the week it averaged out, even though at any given moment the proportion of free orders might have been slightly higher or lower than 20%.

I could have just chosen random numbers from 0 to 1 and given free orders if the result was 0.2 or less, but I didn't want to make it too easy to game the system.

I also had to make sure not to give out the same coupon code more than once. Each code could only be used once, and I didn't want someone who should get their software free suddenly find themselves with a used, useless coupon code. For this I loaded all of the codes into a database. It was a pretty trivial database, having only one table with two fields (coupon code and a flag to indicate if it had been used). But it gave me a convenient way to ensure single-file access to the list of coupon codes. With MySQL I'd lock the table for writing, get a code, mark the code as used, and then unlock. If the table couldn't be immediately locked, MySQL would wait until it could.

If traffic through the redirect script got too high when it was free-order time, people might have to wait a moment while the code was retrieved, but I'd know that once they got the coupon that it'd work for them.

Step 3: Making it Make Sense

Despite my best efforts, not everyone knew about the anniversary and the promotion. I needed to make sure that if someone suddenly found themselves getting a free order, they'd know what was going on (they might not mind, but might also be confused). I set up an alternate version of my web store. It was actually the same store, but with a different appearance. This version added a message at the top explaining what was happening in bright, friendly letters that were hard to miss.

Putting it in action

I'm not a PHP guru by any means, but it all worked and that's what counts. I did have a hiccup in the system where it would sometimes fail to apply the coupon (resulting in an unexpectedly non-free order). But Daniel Jalkut and Paul Kim helped me discover them and get them fixed. Remember what I said a few days ago about getting to know other developers? This is where it really helps. It was more than a little disconcerting to have this kind of problem but having friends find it fast definitely helps.

Another error resulted in the first eight orders being free. Duh. But I got that fixed on the morning of the first day, and it still averaged out to 20% of orders being free over the week.

The End

Thanks again to everyone. Now to start planning the 10-year anniversary bash...

Coming on Friday the 26th is the next major release of Mac OS X-- version 10.5, a.k.a. "Leopard"

Those who have Apple ADC Select or Premier memberships have been working with pre-release versions of Leopard for some time now. Apple periodically seeds a new version to those who get these versions, both so that developers can be ready and so that they can provide Apple with feedback on bugs and performance issues and such.

But when it's release time, a curious thing happens. The pre-release seeds stop. When Leopard is released on Friday, developers will not have had any time to work with it. Those who have been getting seeds will have done their best, but ultimately will be playing the odds that their software actually works with the release version. Every seed differs from the last as the operating system evolves from alpha quality to beta and finally to release, and there's no telling yet how the release version might differ from the ones developers have right now.

A common question recently has been, how much advance time will developers have to work with the final version of Leopard? The answer, unfortunately, is negative time. Despite paying $500 or more for an ADC membership, the best a developer can hope for is to rush out on Friday for a retail copy of Leopard, install it, test, and hope that it works. In other words, they find out if their software's ready at the same time their customers do.

This is exactly what happened when Tiger was released and it didn't make any more sense then than it does now.

The reason, apparently, is that Apple's more interested in getting feedback on pre-release seeds than in helping developers prepare. Once the update goes "golden master" further feedback on it ceases to be useful, and so the seeds stop coming. Some have suggested that piracy concerns play into it, but that's BS, because anyone who would pirate it will only be briefly delayed in doing so.

I expect to have a busy week, but my software will be just as ready for Leopard as it's actually possible to be.