Musings from The Software Underground

The 13th and hopefully final beta version of SQLGrinder 2, the completely-rewritten version of our database development tool, was posted today. Requested features not yet added have been moved to later releases.

Please see the release notes page for the full list of changes.

SQLGrinder is near release candidate status. Please make sure that you report any remaining issues, problems, crashes, etc. so that they can be fixed. This beta version is a non-debug build and carries the usual "use at your own risk" warnings.

SQLGrinder 2 is a Universal Binary, and will work on both PowerPC and the new Intel Macs.

SQLGrinder 2 Beta 13 can be downloaded here.

Pricing and availability for SQLGrinder 2

Pricing for the new version has been set at $59. During the beta period however, SQLGrinder 2 can be purchased for the current price of $49.95 with purchasers receiving a free upgrade to the final version once available. Owners of the current version can purchase an upgrade for only $19 by sending their current registration information to upgrades@sqlgrinder.com.

Shortly before the final version of SQLGrinder 2, those who submitted upgrade requests and who purchased their copies during the beta will be emailed upgrade coupons.

SQLGrinder 2 for Mac OS X is currently available for a limited time as an unlimited beta version, which anyone can use for free. Because of this, registration information does not need to be entered to use it.

The beta of SQLGrinder 2 can be downloaded from the Advenio web site.

Finally, you can subscribe to the release notes page, which now has an RSS feed, to stay up-to-date on what's changed and what known issues there might be.

I came across this via Guy Kawasaki's (most excellent) blog, and it rings so very true: Open letter to CEOs, COOs, CIOs and CFOs across the corporate world. The fact that so many CEOs/managers make all of these mistakes and don't care that they are making them was one of the driving forces behind my wanting to form my own company. An excellent read and a fine roadmap for future great companies.

(I couldn't help but think of the "mission statement" from Jerry Maguire as I read this one...)

Let me just say that I love some aspects of Japanese culture. I love Japanese pop music, I've always had a thing for anime, and I love a culture that could produce games where your object is to chop vegetables and prepare recipes. Wacky, but I love it! That said, I just came across a new game for the Nintendo DS to be published later this year by Majesco, called Cooking Mama. Cooking? Huh. This is the description courtesy of GameSpy:

Playing as a female chef, you have to prepare the food (slicing the vegetables, slicing the meat), then cook it on the stove. Use the stylus as their master kitchen tool to chop, slice, pan fry, knead, grate, mash, peel and more. With touchscreen play, you can do things such as shake the skillet for an omelet and dip tempura in the oil. Share recipes with up to 4 other people or transfer a saved game to a friend via the DS wireless link.

For a real treat, click on over to GameSpy and check out the movie for the game, it's totally wonky.

Ever wonder how application features evolve and change during development? Wonder what goes into these evolutions and changes? I thought I'd post an example of how this process can sometimes work using a feature from MacGourmet 2. This is by no means the only example of how things work for everyone, or even of how things always work when I develop or change a feature, but I thought it might be a good example of how sometimes a solution is far simpler in the end than at the beginning.

In the current version of MacGourmet there is a utility window that allows you to set up relationships between things say, two recipes, or a recipe and a wine. I've never really liked how this works. There were essentially two problems with the version found in MacGourmet 1: one is that the selected item could change when you didn't want it to, which could make the drag and drop method of setting up relationships difficult. The second was that there was no way to get from the listed items to the actual items in your recipe box.

For my first attempt at fixing things I had this bright idea to make the drag and drop shorter by adding a list of searchable items to the utility window. This, however, wasn't a great idea, because you would essentially be duplicating a lot of information, and using more memory, which would especially be a problem for people with very large lists. To get around this fact, I tried making the search field an actual search rather than a filter. This isn't the way any of the lists work in MacGourmet though. In MacGourmet, you start with the full list of items and trim that list down based on what is entered in the search field, so making this a search rather than a filter introduced inconsistencies. This change also didn't really solve what proved to be the REAL problem anyway, that being accidentally changing the selected item when you didn't want to. Allowing users to double-click on related items in the utility window actually made things worse, as doing this changed the item selected in the window. So at this point what I had was pretty much a solution looking for a problem.

Then it dawned on me that what was really needed was a way to "lock" the current selection, so that you could do whatever you wanted and the selection would be maintained until you were done with it. This worked much better, and in the end, made the search list absolutely pointless, as you already had a browse-able, searchable list in the main recipe box window. You could already find what you were looking for, and drag the recipes or notes to the relationship manager, so the extra search list was overkill. So in the end, the solution was much simpler than originally planned. So you see, sometimes things don't go the way you originally thought, or as designed, until something is implemented, which is why I like to do prototypes for certain things. You really should never be afraid to throw something out that doesn't work right and start over either. The worst excuse for not revising a feature that doesn't work correctly is that it's "done."