Monday, December 26, 2005

Another Great Piece on Living "The Life"

Gus Mueller writes on his ascension to living "The Life," i.e. doing Mac software development for a living. (Someday I'll get around to writing my own take on this topic, as writing Mac software is currently my own full time pursuit).

How to become an independent programmer in just 1068 days.

Monday, December 19, 2005

MacGourmet 1.1.8 Now Available

MacGourmet 1.1.8, a small maintenance release, is now available.

This free update is available from the MacGourmet download page.

As always, you can find a full list of the changes here.

This is just a small update that fixes database errors that were being displayed during file imports. The errors were benign, but shouldn't have been displayed.

Thursday, December 08, 2005

Way cool hack: Mac System 7.0.1 on your keychain

This is a really cool hack, you can now run the classic Mac OS on a "stick," essentially a USB drive. It emulates a Mac Plus, and will run any OS version that the Plus used to be able to run, up to System 7.0.1. You can also find a list of old applications that will run on this as well, including games, productivity apps and utilities.

I've been using portable Firefox with my keychain flash device for a little while now, and today reader Dimitri has pointed out the Mac-on-a-stick project. Basically, it allows you to put a completely functional version of the Macintosh operating system (in this case, system 7.0.1) onto a USB flash memory device.

It's a pretty easy install (other than all the "disk" swapping, wow did THAT bring back memories..), once you have all the pieces.

Check it out: Mac System 7.0.1 on your keychain (By way of

Tuesday, December 06, 2005

MacGourmet 1.1.7 Released

MacGourmet 1.1.7 is now available.

You can find a full list of the changes here.

This free update is available from the MacGourmet download page.

This release again benefits from the development of the next major version. It resolves a handful of usability issues and includes a couple of optimizations. As bugs are fixed in the next version, they will continue to be pushed out in maintenance releases, so that you won't have to wait for small improvements.

This Holiday, Give Your Favorite Mac User the Gift of MacGourmet!

Because last year people asked for it, MacGourmet is now available on CD for your unique holiday gift giving! For just $29.95 (plus shipping and handling*), only $5 more than the download version, you can now order MacGourmet on CD. The CD edition includes the latest version of MacGourmet and a serial number, the print-quality version of the documentation (in PDF format) and sample recipes, all packaged in a DVD case.

To order your copy, visit the Advenio online store, and just select the CD edition when you place your order. Happy Holidays from Advenio!

*Currently only shipping to addresses in the U.S.

Sunday, December 04, 2005

See New Stuff First: Join the MacGourmet Beta Team!

There are a lot of changes being worked on for future versions of MacGourmet, some of which could be significant. I'm looking for a bunch of people to join a team that can be available to test things first, and give feedback on prototypes for potential changes. There are only a couple of requirements. The first is that members download, sign, and fax (866-830-9080) a simple one page NDA and not discuss future changes or prototypes publicly in any way. Not to be paranoid, but the recipe app field is surprisingly competitive. When MacGourmet was released, there were maybe two non-Filemaker recipe organizers for the Mac. Now there are, at last count, at least 12. Matching of features to be competitive will always be the norm, and imitation is the sincerest form of flattery of course, but I'd rather see imitation of new features show up after a release, not before, hence the requirement.

The second requirement is that members must be completely comfortable backing up and restoring their databases. As with any test software, problems can happen.

If you are interested in becoming a member, first join the discussion boards if you haven't already, and then use the "Send Feedback" menu item in the MacGourmet Help menu to send me your user name, and a request to join the team. Members will be added to a private beta team discussion board where new features can be discussed. Space is limited, so don't wait too long.

Saturday, December 03, 2005

To Hack or not to Hack, that is the Question...

On Software DesignThere's a whole bru-ha-ha going on right now on various blogs regarding Unsanity's "Haxies" and whether or not developers of user applications should be responsible for problems that occur for people running the haxies.

It all started apparently on DrunkenBlog in a post entitled "Of unintended interactions." In it, he took BareBones, makers of BBEdit and TextWranger to task, mentioning that they go so far as to post a dialog essentially saying that if you are running APE and their app crashes, you're SOL. While the dialog that BareBones throws up is an interesting way to handle things, they do have a point. It's hard enough being responsible for your own code, considering the limited resources of most Mac developers, without having to worry about the system being hacked under you. Despite the cute name, "haxies" are hacks. They change the default way that the system works, in ways that can have unexpected results.

DB says at one point:
"Developers don't like debugging other's code, and are often going to be sensitive when it comes to dealing with other's software and how it may be interacting with their own"

I think that really oversimplifies the issue. It's not so much that we don't like it, it's that it's nie-impossible to debug other people's code, especially code of the nature of something that changes the base functionality of the system. Additionally, it can take a lot of time away from work on new features and real bugs, for the other probably 95% of users.

After a bit of back and forth between Rich Siegel of BareBones and DB, this followup was posted, "Of BareBones and bias (aka, "Ho, please.")."

Again, the statement he makes:
Users are going to install things, and they're going to change the parameters under which your app is running -- whether it's a kernel extension for something Apple ships or a mouse driver.

oversimplifies things I think. Haxies aren't a matter of simply installing a mouse driver or kernel extension necessarily. Haxies can effect the the basic and fundamental usage of the system, and can effect things in ways that are hard to diagnose. Installing a mouse driver will not usually effect how, say, system windows are drawn. Trying to write code that works around these potential issues can be frustrating at best.

On the other hand, I do know what he means when he refers to "edge cases." Not all code is the cleanest of code, and shortcuts are sometimes taken, or there can be a bit of laziness on the part of developers where the code isn't 100% correct to begin with. In these cases, APE can overwrite memory that probably SHOULD be available, but isn't. In this case the issue is probably with the application developer, but still, if the system hadn't been hacked in the first place... Regardless, users do the damnedest things sometimes, and as developers we try very hard to take that into account and work with them when they have problems. He says in the post that started this whole thing that "Software interactions are a bitch, and the improbable should be checked, because it's still possible" which is true. It's always worth investigating. Sometimes though, and I think this is why BareBones does what they do, all we can do is kind of drop back and punt. I guess I can see his frustration at the dialog though, cause he sees it as BareBones almost saying "it's not us man" immediately without entertaining the possibility of it being their bug.

On the THIRD hand, I'm also guessing that BareBones has seen enough issues with interactions involving APE that they immediately assume it's NOT their problem.

Finally, "Business on the Mac" offers a pretty good take on the whole controversy. I do like his analogy of chipping a car. If you do this, and the chip you install exceeds the built-in tolerances designed into the car, there is no WAY Audi, or BMW, etc. is going to claim responsibility for the damage done by your change. I think the same thing applies to system hacks. If an application relies on functionality as released by Apple in their APIs for something, and something else is installed that gets in the way, how can you accept responsibility for the problems?