halostatue

halostatue

software development with ruby in Toronto

• Home
• About
• flow

Mac Recipe Management Programs
Sunday, 23 November 2008

Posted by austin in: Apple, Personal, Recipes, comments closed

Updated 30 November 2008: I sent links of this review to the publishers involved (except for SousChef, because Ben Lachman the developer found this post on his own and reminded me that I hadn’t done this even though I meant to). I received a note from the developer of MacGourmet and have added some additional notes.

It’s time to declutter the house. One of the things I want to get rid of are all the recipe magazines and loose recipes that I have. To do this, I need to keep the recipes that I like or want to try. I need a recipe management program. I currently use Yum 2.7.4, which is good, but not great. I decided to seriously evaluate the various recipe management programs available for the Mac. There’s a number of them out there, each with different strengths. I’m going to be evaluating these programs on the following criteria:

• Browsing: How easy is it to find a recipe without searching?
• Reading: How easy is it to read the recipes, once entered? A “kitchen mode” is nice, but absolutely unnecessary in my kitchen—my iMac is in the office. So, I’ll either be reading the recipe to get a sense of the way to make it (and often just a reminder), or I’ll be printing the recipe.
• Printing: How good does the output look? How much fiddling do I have to do to get multiple recipes on a single page, if they’re small enough? How much fiddling do I have to do to get a longer recipe on a single page? Sure, I can use the n-up feature on my printer, but that shrinks the whole page down really small.
• Searching: How good is the recipe search?
• Adding/Editing: While I will be reading, searching and printing recipes most often, I’m going to be most annoyed at a program while adding a recipe by hand.
• Import: I’ve been using Yum (see below) for a while, and while I’m not unhappy with it, it has some major annoyances on recipe entry that keep me looking. Whatever I switch to is going to have to handle importing my Yum database one way or another, without screwing it up. Additionally, since I’ll be looking at the latest version of Yum, I want to see the external import techniques (from text or the Web).
• Extras: What extras exist for the program? Can I easily transfer a recipe to my iPhone or iPod Touch? Does it have an extensive ingredient list with nutrition data to give a rough approximation of the caloric content? These things aren’t going to be deal breakers, but if everything else works, they could be deal makers.

There are more programs available than I am reviewing here. A number of these programs presented problems early enough in the review process that I didn’t think it was worth spending any more time on them.

One that I wish had been better was Measuring Cup. It has some really interesting ideas including sub-recipes and not distinguishing view and edit modes. Unfortunately, it doesn’t have any import facility to speak of, and the controls on the lists are non-standard and finicky. It’s worth looking at if you’re just starting your recipe collection. I’m not.

Connoisseur 1.2

Only Connoisseur 1.2 is available for direct download; there is a beta version referred to, but you must contact the developer for this information.

• Browsing: A Connoisseur has fairly good browsing. It’s laid out much like iTunes with a “sources” list on the left and three filtering criteria on the main panel under the toolbar: Cuisine, Course, and Ingredient. This will make it easy to find recipes based on the ingredients you have at hand and the meal you’re serving.
  You can great new “groups” (recipe collections/folders) and smart groups (groups with search criteria) pretty easily.
• Reading: C+ After browsing to the recipe, or searching for it, you double click on the recipe in the main list to display it¹ in a smaller (but resizable) display window. The window isn’t bad, but it’s too loose: the recipe metadata (such as cook time, yield, etc.) takes up far too much space; blank fields are shown; ingredient lines are 1¼ linespacing, which is too much.
  On the up-side, there’s a nice “Cooking View” that fills the screen with the recipe. The directions are too widely spaced, but this is a much better “view” than the default windowed view. As a nice touch, Connoisseur will also read the recipe steps to you.
• Printing: F Everything that’s wrong with the display window is wrong with the print function, and it has additional sins of commission. The linespacing per field appears to be about 1½ and the ingredients are still 1¼. The empty fields don’t show here, but the amount of space taken up by the metadata eats up half of the first page. Worse, the metadata is incomplete: it’s cropped if it goes over a certain (small) width. The directions for a “2-Minute Fudge” included with Connoisseur don’t begin until page two—and the heading “Directions” is on page one. The directions are cropped if they’re over a certain (small) width.
• Searching: F ⌘F and ⌘⌥F don’t work for search. As far as I can tell, aside from the filtering mechanisms mentioned in browse, there’s no way to search for a recipe.
• Adding/Editing: F I’m not sure where to begin with the problems presented by Connoisseur’s add/edit recipe sheet. When adding or editing a recipe, you are presented with a modal sheet on the main program window. If you’re copying information from another recipe, you have to first have displayed that recipe in a separate window before you start editing the current one. The recipe sheet is tabbed and has far too many controls on it (at the bottom of the sheet is a help question mark, previous, next, a “cooked” checkbox, cancel, and save. The recipe scaling feature looks impressive, but I’m not sure why it’s part of the recipe editing—this is something that Connoisseur should be able to figure out automatically, on the fly.
  The ingredients and directions are on separate tabs, requiring flipping tabs to make sure you’re correctly using all of the ingredients as you’re writing the recipe down (as someone who creates recipes from time to time, this matters). Ingredient and direction entry is more complex than it should be, relying on +/- buttons on each and every ingredient and step.
• Import: B Will not import directly from the Yum database format, but recognized the Yum XML format reasonably well. The import itself was fairly pedestrian, although my imported recipes had stupid errors, such as: “2. 1. In a small bowl…” There’s some level of intelligence that should be applied here. There’s no import from a webpage, and the import from text is a little hit-and-miss (in my test of a copied recipe from the New York Times, the instructions were inserted as ingredients, possibly because they were numbered).
• Extras: There’s a nice set of default recipes included. You can add a recipe to a shopping list and export it to an iPod as a list, or to the Palm program “HandyShopper” and “SplashShopper” (which would be useful if I used a Palm device anymore). There’s an online component for shared recipes and you can download others’ shared recipes, too. It looks like there’s a moderation process to the recipes, though.

This is not a program that I would recommend to anyone at this point. It looks pretty, and the filtering mechanism is superb, but I don’t think that this is a usable program.

Cookware Deluxe 3.2

• Browsing: B- Cookware Deluxe starts in a recipe view, requiring explicit switching to a browser. The browse interface is a filtering interface that’s rather busy and confusing. The display has three panels. The recipes are in the main panel on the right, and there is a switch (”First/Any”, defaulting to “First”), followed by the alphabet, “All”, and a heart symbol. Clicking on a letter will filter the display of recipes based on the presence of that letter at the beginning of a word in the recipe name; if the switch is set to “first”, only the first word is considered. Clicking on “All” clears the filters and clicking on the heart selects “collected” recipes (those that carry from version to version).
  The upper panel on the left has five tabs that act as filters: Cookbook, Ingredient, Region, Course, Bev (the alcoholic beverage one would have with the recipe, generally limited to wines and some beers). These filters are not co-operative filters; they work independently (one cannot select an ingredient of “Asparagus” and a beverage of “Pinot Grigio” to filter for recipes that call for both). The lower panel are for saved search templates (loading a saved search goes to the Find window) and menu sets (collecting several recipes that are intended to go together as a meal). Clicking on “All” above the menu list removes any of the filters applied from the left panel, too.
  Cookware Deluxe also has a planner view where meals and menus can be planned in advance. There’s both a monthly calendar and a weekly calendar view (called “Planner” and “Details”, confusingly). There is no option to make Monday the beginning of the week.
• Reading: The recipe display panel is fairly decent, divided into two panels (a large upper panel shaped like a recipe card and a lower tabbed panel). The recipe card is divided into three columns. The first column is a quarter of the entire card and contains the name of the recipe, a tabbed box for photographs of the recipe, and other important metadata (cooking time, oven pre-heat temperature, difficulty).
  The second column is the ingredient column and also takes up a quarter of the recipe card. The third column has a small toolbar (about ¹/₁₀ of the vertical space), a description area (about ²/₁₀ of the vertical space), and the directions. The toolbar over the directions provide a checkbox (”Multi-Print”), four buttons (Tools, Custom Print Layout, User Prefs, and Large Print Display), another checkbox (”Collected Recipe”, see above), and a bronze badge with a check mark inside for checking spelling.
  The font in all of these sections is small, but there are two icons of interest for this: in the lower left hand of the card is an icon that looks like a two item bar graph. Clicking on the taller bar zooms the interface larger; the shorter bar zooms it smaller (and it will go smaller than the default). In the toolbar over the directions column the last button will display the current recipe in a window with a much larger font for viewing from a distance. It’s not as good as Connoisseur’s full screen display, but it works (it also only shows the ingredients and directions.
  The bottom tabbed panel allows for category information (cookbooks, course, main ingredient, region, beverage, source, recipes it requires, and recipes that work well with it); additional source information, Weight Watchers™ points, and nutritional data (unformatted and not calculated on purpose); and notes and substitutions.
• Printing: A- Very strong. Includes the ability to customize where each section of a recipe, although the sections themselves include very weak formatting. The “Multi-print” selection (in recipes and the browse list) allows you to print multiple recipes on a single page (if they fit).
• Searching: Has relatively strong search capabilities, but the layout is pretty confusing.
• Adding/Editing: B- Recipes can only be created from the “Recipe” view; not from the “Browser” view. The strengths of the recipe view are present, but each of the fields is unformatted, leaving it to the user to know the appropriate abbreviations and names of each ingredient. This makes for easy cut and paste, but explains why the “main ingredient” must be entered separately; the ingredients are not stored individually, but in aggregate. Note that I did not attempt drag and drop adding, but I would expect it to work well given the lack of formatting in the fields.
• Import: C- Only supports importing past CookWare recipes, recipe sets, and MasterCook recipes. This is found under the application menu, not a “File” menu.
• Extras: Supports an iPod cookbook or recipe (presumably just a text note). Supports QuickTime movies for each recipe. Has a Windows version.

This is another program that I can’t recommend. There are some nice features, but this program is written on top of FileMaker and it feels like it. The layout is crowded and hard to read; if there’s been thought given to making this program easier to use, it seems to have been hampered by FileMaker forms options.

MacGourmet 2.3

MacGourmet and MacGourmet Deluxe are essentially the same program. MacGourmet Deluxe includes all of the available MacGourmet plug-ins (”Cookbook”, “Mealplan”, and “Nutrition”) and is a better value than buying the plug-ins individually. Because the plug-ins are extra for MacGourmet, I will only cover them in the Extras section of the review.

• Browsing: B+ The interface for MacGourmet looks like the Apple Mail or NetNewsWire interface with sources and folders on the left, a recipe index on the top right and recipe details on the bottom right. There are two views for the recipe index: a standard tabular view and a simplified image, name, source, and rating view. By default, the simplified view only shows two recipes at a time; the standard view shows seven.
• Reading: A The recipe layout is beautiful. The ingredients are in a formatted box with the source, yield, pictures, and other metadata on the right side of the recipe². The directions are below the ingredients. There’s a very readable chef view; as a nice touch, if multiple recipes are selected, the chef view is a tabbed interface, one tab per recipe. In the standard view, only one recipe can be displayed at a time; multiple recipes can be displayed in separate chef view windows as well.
• Printing: A Standard printing facilities are superb and support printing on Avery 3×5 and 4×6 cards as well as several other templates.
• Searching: A Simple but effective rule-based “cupboard” searching (like Spotlight) with ⌘F. ⌘⌥F provides access to the quick search box, which is very effective. Explicit note, recipe, and wine note searches are also available.
• Adding/Editing: B- Some of the problems seen in Connoisseur’s add/edit screen are here to a lesser degree. By default the recipe add/edit screen isn’t a modal sheet (but it can be configured as such), but it is a modal dialog that blocks the main view. Otherwise, it takes an iTunes approach to editing: multiple tabs for Info, Ingredients, Directions, Preparation, Notes, Picture, and Nutrition data (which can be calculated from the ingredient list). The ingredients list is pretty easy to use, but there are two columns of checkboxes (”D” and “M”) which aren’t explained in the help documents. “D” marks the ingredient line as a descriptive title separating distinct portions of the ingredient list; I haven’t figured out what “M” does. The other sections are unformatted text entry.
• Import: A Importing is strengthened by the clippings section to turn clipboard results into recipes relatively quickly. Featured recipes from MacGourmet.com and Amazon.com are also automatically importable through the “Featured” section. It supports importing from Yum, but only imported 70 of the 116 recipes that I have in Yum; I’m not sure if this is a demo limitation or not.
• Extras: There’s a shopping list, a generic note list, and wine notes. Easily supports publishing to standalone sites or weblogs (the ability to use a weblog publisher like MarsEdit would be nice).
  The Cookbook Builder plug-in is a fairly nice idea and works reasonably well (drag and drop recipes into the appropriate places), although I don’t think it’s something that I would use often, if at all. The meal planner works similarly but is a little finicky as to where things should be dragged (if I drag the “breakfast” meal into the day area, even if it’s not on the day row, the “breakfast” meal should land in the right spot; don’t make me care about your hierarchies when adding—you just need to do the right thing). It’s nice that the meal planner can easily become a shopping list. The nutritional plug-in is a little confusing as to how it works at first (you need to edit the recipe to calculate the nutritional value for it based on ingredients), but it does a very nice job of calculating once it’s clear.
• Update: Michael Dupuis, the developer of MacGourmet, indicated that the Yum import failure with MacGourmet is related to an XML format change in the Yum format, not a limitation in the demo. This will be fixed in the next update of MacGourmet. I discovered that I had forgotten to put a grade on the Import feature. He also mentioned that the “D” and “M” checkboxes in recipes are explained on pages 23–24 of the user guide as “Divider” (descriptive title, as I surmised) and “Main Ingredient”. Finally, the post editor allows you to choose an extern blog posting tool such as MarsEdit by choosing it under the “Post using” menu.

This is a great program. There’s enough here that I can possibly see replacing Yum with MacGourmet. I suspect that although I don’t see myself using the cookbook builder, I would consider using the meal planner and the nutrition calculator, so I might go with MacGourmet Deluxe.

SousChef 1.0.1

• Browsing: A- The app is divided into three panels: a source list, a recipe list, and a recipe display. It looks very much like the Address Book application provided with Mac OS X. The source list contains a master recipe library, a search results entry, recent imports, and then user-added folders and collections. Folders can only contain collections; collections contain recipes. Collections are associative; recipes can belong to more than one collection at a time. Deleting a recipe from a collection only deletes it from the collection; it does not appear that there is a way to delete a recipe from the recipe library permanently except using the recipe library view.
• Reading: A The reading pane is clear, well laid out, and easy to read. This is not as flexible as the display in MacGourmet, but I am pleased to say that it’s easily readable. The full-screen “Cook” view is the best I’ve seen in any of these programs: it will not only speak your recipe (which Connoisseur also does), but you can also turn on voice recognition so that you can tell it you want the next instruction to be read. Drop down menus in the ingredients list let you search for other recipes with this ingredient with ease.
• Printing: B- The print layout is functional and well laid out, but you can’t print more than one recipe at a time.
• Searching: A+ Excellent search on ingredients, name, category, or cuisine. Simultaneously searches local and “cloud” recipes.
• Adding/Editing: A- Heavy reminders of Address Book here; ingredients and directions are added and removed with the red “-” and green “+” circles. Can’t drag and drop ingredients, and the green “+” isn’t always visible on entry. Sub-recipes (the crust for a cheesecake) are handled manually (possibly poorly). Directions are automatically numbered. Notes are automatically bulleted.
• Import: B Can only import one recipe at a time essentially from the clipboard or a single text file. Does not handle heavily formatted recipes well. No support for Yum importing.
• Extras: Blogging, although how it works is not clear without a licence. “Cloud” recipe sharing of recipes in yours and others cookbooks.

This is another program that I really like. I’m not happy about the state of import for multiple recipes—I have an extensive collection that I want to import already. Conversion utilities would be very useful here. I’d also like to see print improved some, or at least some sort of iPhone integration.

Yum 3.0

Yum was recently acquired by “Dare to be Creative” and has been turned into a shareware program as of Yum 3.0. I’m currently using Yum 2.7.4 which is no longer supported. I’m reasonably happy with Yum 2.7.4. This review is based on the trial version of Yum 3.0.

• Browsing: A- Like several other recipe programs, Yum uses a 3 column layout. In this case, it’s category, recipe list, and then the recipe itself. Categories are associative (and in Yum 2.7.4, able to be managed in the “categories drawer”; this appears to be read-only in Yum 3). A nice touch carried over from Yum 2.7 is that when you select a recipe, all of the categories to which it belongs are highlighted (similar to Address Book).
• Reading: A- Simple, well-laid out. Ingredients are always on the left; the method (directions) are always on the right. There’s a full-screen mode, but the default configuration misses the point (it doesn’t increase the font size at all)—you need to go into the Format|Manage Layouts and change the “step-by-step” layout to “Step-by-Step” to be meaningful.
• Printing: A- Layouts can be edited (it’s not completely clear how they work) and multiple recipes can be printed on a single page if they fit. Layout is completely customizable (but I have never done so).
• Searching: B+ It works well enough, but there’s no keyboard shortcut.
• Adding/Editing: B+ Fairly good adding and editing. It’s been improved from 2.7 (which allowed the method to be formatted rich text). Automatically converts fractions to their proper display form. Has a “paste ingredients” for quick addition from a copied list. Scaling is done in here and not elsewhere.
• Import: Imports from Yum, MasterCook, and XML only. Doesn’t have a single recipe import mode (although “paste ingredients” helps with that).
• Extras: Now comes with a shopping list mode.

This is a fair update to a good recipe manager. I’m not sure that it’s worth the shareware cost, when others that offer more features are just a few dollars more. However, I am excited to see that Yum has been acquired and is under active development again; I would not be surprised to see Yum become a viable competitor to YummySoup!, MacGourmet, and SousChef moving forward.

YummySoup! 1.6.9.5

I’ve tried YummySoup! a few times and never been quite convinced by it.

• Browsing: A Like MacGourmet, this is somewhat reminiscent of Mail or NetNewsWire; there’s a source list on the left and recipes on the right. There’s both the “My Library” and the “Online Library” view for viewing and sharing recipes online. The default recipe index (top right panel) is the image browser. This isn’t quite Recipe CoverFlow, but it’s pretty damned close. This view alone argues in favour of taking pictures of your masterpieces. There’s also a standard tabular view which is clear and readable. There are both groups (folders) and smart groups (live search folders); groups are associative (recipes can exist in more than one group at a time). Recipes can be removed from a group or from the library.
• Reading: B+ Functional and pleasant, but it still puts metadata at the top and too prominent. The first thing I care about when looking at a recipe is the ingredients. I don’t care about the source, difficulty, ethnicity or anything else. The full screen view is well done, but not as nice as SousChef (and, to be honest, I don’t care about the recipe picture in full screen mode).
• Printing: C+ Only one recipe can be printed at a time. Standard print format.
• Searching: B No keyboard shortcut. It works well from the search box, and the smart groups really are smart.
• Adding/Editing: A- A modal sheet for editing, but everything is on one pane (no tabs!). Easily make new ingredient groups; good auto-fill values. Bullet (●), ℃ and ℉ buttons. It gets nearly everything right (modal?).
• Import: B+ Doesn’t support importing from Yum; I could import Connoisseur or MacGourmet recipes if I wanted to. Importing from a web site could not be easier (and works very similarly to SousChef; YummySoup! had it first, though).
• Extras: An easy to use grocery list; a liquor cabinet tracker. Online publishing (via email to HungrySeacow) and downloading.

I’m still undecided about what to think about YummySoup!. I like what it has, but it has some weaknesses that I’m not fond of. I don’t think that it’s as good as MacGourmet or SousChef.

The Verdict

Tonight, the verdict is to change nothing—I’m not convinced that the alternatives are worth the price today (including the new Yum 3.0), and the stronger contenders (MacGourmet, SousChef, YummySoup!, Yum 3.0) have serious flaws with how I need to use a recipe management program. If I were forced to make a choice, I think that MacGourmet Deluxe would be the winner, but I’m not sure that the expense is worth the time and effort it would take me to switch. I really want to like SousChef, but it’s not quite there yet for me.

Vacationing with the iPhone
Tuesday, 2 September 2008

Posted by austin in: Apple, iPhone, comments closed

This past August, my wife and I went out to Nova Scotia with my parents in their RV¹. I’ll be uploading some of the better pictures I took to my Flickr stream in the near future².

My parents tell me that they have wireless access in a campground more often than they don’t. Of the campgrounds we went to this summer, exactly three had any Internet access at all, and only one was reachable from where we were parked.

Intrepid road warriors, we kept up with our email and other web browsing most days through the iPhone. Even in Cape Breton on the Cabot Trail, we had decent EDGE data signal through the Rogers network³. For eighteen of our twenty-two days away from Toronto, the iPhone was our only meaningful Internet access. It performed like a champ. We even got tickets to see Neil Young at the Air Canada Centre in December while rolling down the road.

My parents also use Microsoft Streets & Trips with an attached GPS for navigation. More than once, the iPhone with its GPS and Internet connection (and Google Maps) gave us better directions than Streets & Trips. There was one notable incident where Streets & Trips put us in the Atlantic, but Google Maps on the iPhone gave us the right directions⁴

The iPhone is too small to be practical for extended use as your sole access to the Internet. It is an excellent adjunct to a standard laptop or other computer and I don’t regret the purchase or contract at all. I have some ideas on how a good web tablet might work, based on my use of the iPhone and a Tablet PC, but I’m going to let them percolate a bit before I publish them.

GNU GPLed Software and the iPhone
Tuesday, 26 August 2008

Posted by austin in: Apple, Technology, iPhone, comments closed

Last month, Aristotle Pagaltzis claimed that “John Gruber doesn’t understand freedom“. This is in response to Gruber’s post about the release of the WordPress iPhone application source code.

Unsurprisingly, Aristotle is probably wrong, as is the FSF. Their own history with respect to running applications on non-GNU GPLed operating systems suggests this. I’m going to briefly address Aristotle’s comments in regards to the FSF’s definition of “free software”¹.

The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.

Study? Yes. Adapt? Technically, with the source code, yes, except, without a developer key from Apple the most useful thing I can do with the changed source code is print it out and use that as… toilet paper.

On many Unixes, compilers were an added cost. This still remains true on some platforms (and gcc isn’t an acceptable replacement on some platforms). Without access to a compiler, the most useful thing you can do with the changed source code is, as Aristotle says, toilet paper. Note as well that there’s still the “Operating System exception” in the use of the GNU GPL. Specifically, I can use any services or libraries provided by the operating system without infecting the operating system or the GNU GPLed software that I’m compiling.

You may as well complain that the development toolchain requires that you purchase a Macintosh computer to write an iPhone application, since there’s no version for Windows or Linux. (Nor is there likely to ever be.) I see the requirement for a developer key as analogous to the requirement of a compiler and easily falling under the “Operating System exception” for execution purposes.

The freedom to redistribute copies so you can help your neighbor (freedom 2).

As long as my neighbour is the App Store, I suppose.

You can still do this, either through ad hoc distribution or through Apple’s own system. You can also redistribute the changed source without limitation. The GNU GPL says nothing about requiring that distributions be binary distributions.

Being free to do these things means (among other things) that you do not have to ask or pay for permission [emphasis mine].
You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist. If you do publish your changes, you should not be required to notify anyone in particular, or in any particular way [ditto].

Uhm, except Apple, right? Right?

This is where Aristotle has gone completely off the rails with respect to iPhone software development.

As a license agreement, the GNU GPL does not impose—nay, cannot impose—requirements on third parties. This is partially the source of the “Operating System exception”; you cannot force IBM to release the source of AIX just because you build, run, and/or distribute a GNU GPLed piece of software on it. (If you want to write well-accepted software for AIX, you’re not going to use gcc; you’re going to use IBM’s xlC, which is really expensive.)

I can, without limitation, make modifications to the WordPress iPhone application and use it privately with my developer key. I don’t have to tell anyone that I’m doing this, at all. (My iPod Touch still has some demo programs on it.) I can also, without limitation, post my modified source (which, again, is all the GNU GPL gives a damn about) anywhere I want without telling anyone else anything about it.

What I can’t do, without going through the App Store, is publish a compiled binary for other people to use without having to effectively buy the compiler.

But none² of my rights under the GNU GPL have been violated. Period. Because the GNU GPL just cares about the software in the abstract, not in a specific compiled form.

I guess those silly hippies at the Free Software Foundation were right.

I guess those silly hippies forgot to read their own licence and recognise their own history when it comes to their licence. You and I might prefer a more open App Store with fewer restrictions on what software can run and how it could be distributed, but nothing about iPhone software development violates the GNU GPL, as much as people would love to pretend that it does.

Revisiting the iPhone on Rogers/Fido
Sunday, 13 July 2008

Posted by austin in: Apple, Toronto, comments closed

A few days ago, I wrote that I wasn’t planning on getting the iPhone under the data plans that Rogers/Fido offered offered.

I didn’t.

When they offered the $30/6 GB data plan, I started looking at my options and on Friday, I ordered an iPhone (16 GB, Black) with the $30/6 GB data plan, combined with my existing 300 minute plan totalling out at $75. I don’t have Visual Voicemail or text messages with this, but I can add Visual Voicemail and a few other features for $15 per month, so for $90 a month I’m getting a pretty good plan—and I don’t have to give up my long distance option.

I may shift my voice plan around a bit since the plan that I’m on has been grandfathered in and includes voicemail already (which I won’t need with Visual Voicemail) and I’m pretty sure that I can save some money doing that.

Even better, since I ordered my iPhone on-line, it’ll arrive sometime next week (without having to stand in line) and it’s going to be $48 dollars cheaper than it would have been because I had 48 “Fido Dollars” in rewards.

Go me.

Rogers/Fido, the iPhone, and Me
Saturday, 28 June 2008

Posted by austin in: Apple, Technology, Toronto, comments closed

I’m a happy customer of Fido. Even after Rogers bought them, they didn’t ruin them.

Now, Rogers has the iPhone. And the best data rates that they’ve come up with are absolutely insane — with no unlimited data and that we should feel that their plans are “High Value”.

Colour me not interested. Here’s the text of my feedback to Fido:

Thank you for showing that Rogers is both stupid and greedy. I had planned on getting an iPhone in two weeks. Now I will NOT get an iPhone because of your absolutely insane data pricing. You call it “High Value” pricing; I call it “highway robbery” pricing. When AT&T has a better price plan than you, it strongly suggests that you’re out of touch. Let me know when your prices return to Earth with an unlimited 3G plan and I’ll happily upgrade to the iPhone.

I should have pointed out, but did not, that I have no problem with the idea that I have to spend $75 or more per month—I’m already spending a lot of money. But I want value for that money, and Rogers plans are anything but value to the consumer. They’re a pure rip-off.

That said, there’s a petition on-line that I refuse to sign, mostly because I refuse to have my name associated with some of the disgusting things (including wishing Ted Rogers bodily harm). I may think that Ted Rogers is a greedy pinhead, but we should act civilized, people. Grow up.

I Paid for Twitterrific
Thursday, 27 December 2007

Posted by austin in: Apple, Technology, Twitter, comments closed

When Craig Hockenberry released Twitterrific 3 as either ad-supported or a $15 licence, I paid it immediately. According to one “Captain Marc” over at Odelbee, there’s a “hack” to disable the ads from Twitterrific, who apparently thinks that I’m a bit of an idiot for paying for Twitterrific. (Interestingly, between comment #9 and #21, Marc went from thinking that Twitterrific was a “POS” and a pretty good app.) “Captain Marc” is wrong: the switch from free to free+ads or paid wasn’t without warning; this was stated up front on the download page of Twitterrific.

He’s further wrong: Eudora was simply a tool for receiving and delivering … content, yet it sold for quite a long time. Very few of the applications that I’ve bought for the Mac since I switched eighteen months ago have I had any qualms about buying after buying them, and Twitterrific is one of the apps that I use every day, multiple times a day. There are features I’d like to see, certainly, but it’s a damned good product and I’m proud to have paid for it.There’s plenty of software that I wouldn’t buy at full price; sometimes I’ve waited for bundles (and my unwillingness to pay full price has generally been justified by the lack of use the product ends up seeing). More often, though, I just stop using the product. If I use it, though, I pay for it. No ifs, ands, or buts about it. And so should you, “Captain Marc.” You certainly shouldn’t be posting hacks or alleged hacks.

More on this from Seth Dillingham and Justin Miller.

The Twitterrific icon in this post is copied from the IconFactory web site. It belongs to IconFactory and has been used with permission. 

Optimize What?
Sunday, 25 November 2007

Posted by austin in: Apple, Ruby, Technology, comments closed

There’s been a furore recently over an article by Ankur Kothari where he optimized CTGradient. As an exercise in optimizing code, it was fairly aggressive but otherwise pedestrian. As an article, it was inflammatory and insulting from the beginning:

CTGradient contains an incredible diversity of built-in gradients, gradient styles… For demonstration purposes, all these features are excellent. For production, this is a nightmare.

It gets no better at the end:

…The documentation already shows you how to draw gradients, yet the number of applications using CTGradient – the whole 1300 lines of it – is astonishing.Please: When you use other people’s code, don’t put it in without a thought. Go through it, understand it, and optimize it for your specific need. For the better performance and reduced RAM usage, computers will thank you.

Quite legitimately, some Mac developers spoke out about this. Hoare’s famous dictum Premature optimization is the root of all evil was pulled out early. It’s completely applicable here by any measure. This story would have ended here, and I wouldn’t be writing now, had it not been for a series of bile-filled nonsensical articles posted at Rixstep, starting with one calling Mac developers (such as Daniel Jalkut) objecting to this inflammatory article as the Landed Gentry of Mac Development™.

Which Optimization?

I’ve been developing software for a long time. While I haven’t done any Objective C programming yet, there’s nothing in Ankur’s article which is unique to Objective C. When developing software, you make it work, make it right, make it fast. In that order. The goal is to ship your software, not have it languishing in interminable development. Mac developers aren’t the only ones who will use third-party source without looking for optimizations (or further optimizations, as the case may be); Unix and Windows developers do this, too. Any developer worth their salt does this, because the first goal is to make it work. At work, when we see performance and memory issues, we don’t start digging through third-party code. We don’t even start looking at our own code. We start looking at profiled performance data. Then, and only then, do we start to make something fast.So, if the first goal of software development is make it work, what’s the first optimization you should do? You should optimize your developers’ time toward shipping the softare. Window background gradients aren’t the type of thing that will sell more copies of an application, but their absence may prevent some sales because the application doesn’t look “tasty” enough. So, you start looking at how to provide gradients. You see that Core Graphics supports it, and you start digging in the documentation and you see that it’s going to cost you lots of extra time to learn the CG gradient support. And then you have to debug what you’ve written. No sensible unit testing here; this is visual inspection. If you can add a single file that reduces your time to implement a background gradient—which you don’t really care about yourself but you know it’ll cost you sales not to have it—then you’re going to be better off entirely. Scott Stevenson of Theocacao stated it much better in 2006:

Ah. Now doesn’t that feel better? It’s not that the class does anything that is otherwise impossible, it’s just a lot cleaner because all of the goofy callbacks and whatnot are moved into their own code space. In other words, you have more free time to work on the actual application.

CTGradient is (almost) all about developer optimization. It also helps you deal with the second optimization: optimizing for correctness. It’s code that someone else has written and debugged. You know that other people who develop Mac apps are using it, and no one is screaming loudly about bugs in the code, so you feel pretty comfortable with it. So, you know that by using this drop-in library, you are not only getting this negative feature done, you’re getting it done right. At this point, you can forget about the getting it done fast, because no one has complained about gradient performance at this point, because you’re not yet done shipping.Make it work; make it right; make it fast. Optimize for developer time first (and this includes good design), and then worry about the rest when you need to.

More Code Optimization = Better Developer?

Things really went off the rails with this discussion when Rixstep posted the “Landed Gentry” article. He’s posted further bilious articles attacking some of the developers involved in the discussion over CTGradient optimization, but I’m not considering those articles for this discussion, since they’re pure bile and add nothing meaningful to the discussion (that is, they’re still based on false optimizations that I’ll address in a moment). In the “Landed Genry” article, Rixstep asks:

Who would you rather have engineer your software? Someone who’s as conscientious as Ankur Kothari? Or someone who squirms and attacks and insinuates and does the absolute utmost to avoid the actual question? You the user/paying customer can decide. Wander over to Ankur Kothari’s article on CTGradient and see who’s objecting. At least you’ll now know what the Landed Gentry of Mac Development™ think of you.

Rixstep presents a false dichotomy here. Ankur isn’t particularly conscientious in his article; there are specializations presented as optimizations, and some optimizations aren’t geared toward the most important parts of development anyway. Daniel Jalkut, on the other hand, is very conscientious toward his most important target: his customers’ time in using the program. I’d be very surprised if anyone was saying that MarsEdit is too slow because of gradient display.Optimizing on parts of code that don’t matter doesn’t make you a better developer. Optimizing the right parts of code at the right time do. If I were hiring Ankur and Daniel, I’d have to watch over Ankur more to ensure that he wasn’t working on stuff that doesn’t matter to the customer. Like optimizing gradient code without actually knowing that it was a performance bottleneck. Ankur does a decent job of making sure that the resulting code meets the minimum required needs of the job (which, if you’re developing from scratch is a good thing, after all, YAGNI). He outright says that one should spend time going through third-party code that (probably) isn’t relevant to the primary mission of your softwasre, and therefore doesn’t help toward “make it work.”In reality? They’d probably both work out as great developers. But Ankur cares no more about a user’s software experience than Daniel does, despite the insinuations of Rixstep. I do question Ankur’s judgement on the optimizations made and how they were reached, or at least how they were explained.

The Axis of Optimization

Let’s play along for a moment, though. Assume we have already determined that there’s a measurable performance problem and we don’t have any currently outstanding feature requests or other problems that are higher priority than this performance problem. Assume further that we’ve profiled our program and we’ve determined that yes, our source of program slowdowns is CTGradient.There’s a legitimate question about whether Ankur’s effort was really optimization or specialization. When he says Firstly, let’s remove the methods we know for sure we won’t need…, the discerning reader should be asking why we don’t need those methods. Ankur doesn’t explain how he reached this conclusion. This means that the developer who is doing their job right won’t immediately think of eviscerating the entire CTGradient library, but rather measuring the performance characteristics of the library.Ankur made a mistake in his approach. Yes, simpler code is usually easier to maintain, debug, and will usually perform better. But simpler code does not necessarily mean better or more performant code. A bubble sort is simpler than quicksort; there’s no way that it’s faster. One may as well look at binary size for comparison. This isn’t to say that one shouldn’t strive for smaller binaries; the larger your binary, the more likely it is that you’ll cause something else the user uses to swap out to disk, which would be bad. Can CTGradient actively contribute to this? It’s not distributed as a Framework, so most projects compile it directly into their code.CTGradient’s 1,172 lines of code in six source files (as determined by Sloccount) doesn’t even come close to adding meaningful binary code bloat. I compiled CTGradient from the latest available SVN checkout and Ankur’s “Lean Gradient” project. I compiled both as Universal using the default settings and compared the final binary size (from Contents/MacOS/) and the intermediate object file sizes. Since the projects are structured differently, it’s not a completely fair comparison. Ankur’s binary does one gradient and results in a binary size of 42,992 bytes; CTGradient does a lot of different types of gradients and results in a binary size of 78,776 bytes, a difference of a mere 35,784 more bytes of Universal code. A lot of the binary size differences is overhead, though. CTGradient creates three object files per architecture: CTGradient.o (55,964 bytes), CTGradientView.o (14,160 bytes), and main.o (976 bytes), leaving an overhead slack of 7,676 bytes. optGrad just has main.o (10,912 bytes), leaving an overhead slack of 32,080 bytes. So, CTGradient.o isn’t going to add to your binary size overhead in any meaningful way.What about memory use? Ankur posted two follow-up comments that suggested that CTGradient adds between three and ten megabyes of memory use to a program over and above his approach. That suggests that there might be room for a CTGradientLite, but making that would require extensive profiling to determine the parts that could be excised prior to doing so. And, of course, if all you need is a single gradient like Ankur did, and have the time and mathematical knowledge to do what Ankur did, by means do so. Ankur’s five minutes, though, might be five hours for you—so make sure that you don’t have something more important you should be working on.

The Unwashed Messes

Ankur can perhaps be forgiven for the mistakes he made, as other posts by Rixstep suggest that he’s quite young. He hasn’t yet had to learn the personal interaction lessons that most of us have to learn, and that most of us do learn. There’s a few who don’t, and Rixstep appears to be one of these developers who resisted learning about how to behave toward other people throughout his career. He stepped into this discussion “defending” Ankur from the “Landed Gentry”, who were simply asking the same questions that any good software developer would. He’s gone further recently into personal attacks against two of the more vocal questioners. Reading further on Rixstep’s site, anything that is selling better than his software seems to result in that anything being called the “Landed Gentry” of something. He thinks that he’s defeating dragons, but in reality he’s tilting at windmills just as usefully as Don Quixote did.Rixstep is supposedly in the business of selling software. The content and tone of his posts have managed to do the opposite. I had recently considered purchasing some of his software; I know now that to do so would have been a mistake, because he doesn’t treat his peers well. It’s impossible for him to treat his customers well with that sort of attitude. It doesn’t take much to be generous in spirit to people, at least in starting. It doesn’t take much to realize that there are better ways to deal with conflict than has been done.There is a difference between taking a hard-line, hard-nosed approach to something and defending it on technical grounds and actively attacking someone without basis. Rixstep’s attacks, starting with the “Landed Gentry” article, are entirely without merit. Ankur didn’t optimize CTGradient; he made a specialization. This is valid sometimes, but in reality something like window gradients isn’t central to your application’s purpose, and to spend more than an hour or two dealing with them would be wholly inappropriate. The good developer knows that it’s better to ship than to spend all your time optimizing someone else’s code or rewriting it yourself.

Where does Ruby Fit into This?

The astute reader would have noticed that I filed this as a Ruby article as well. While I haven’t mentioned Ruby until this point in the article, the parallels here are obvious. Rixstep and Ankur both say that the dozens of applications that use CTGradient are abusing their users because it uses too much code, too much space, too much memory, and it’s too slow. Aside from the memory use, the claims have either been exposed as false already or haven’t been supported with data. As Scott Stevenson’s quote suggests, CTGradient optimizes for developer time.So does Ruby. I can get more written with Ruby than any other language that I use. It won’t be the fastest software, it might be a little more memory intensive, but I will get it written—and written correctly—faster. And that, given that shipping is the goal, is important. When Rixstep rejects CTGradient without providing a more optimized yet equivalent functionality alternative, he rejects any developer-side optimizations in favour of hand coding everything, including using more expressive languages.I reject that notion. And so should you.

Not Going Back
Wednesday, 24 October 2007

Posted by austin in: Apple, Technology, comments closed

John Gruber has it exactly right:

Windows lost a huge chunk of the nerd market. Nerd switchers, in and of themselves, don’t constitute a significant enough number of people to account for anything other than a tiny blip in Apple’s Mac sales. But nerds are the people who recommend computers to friends and families; it seems inarguable that there are an awful lot of nerds recommending Macs today who weren’t five years ago.

I bought my first Mac (15″ MBP) in August 2006. In some ways, I bought it two months too early; in others, I bought just at the right time (I needed a new home laptop). In that time, I have convinced my parents to ditch their two Windows computers for a Mac—my MBP, when I upgrade early next year; I have told my wife that her next computer when this one dies will be a Mac and I have recommended Macs to three other people. There’s very little that one can do on Windows that one can’t do on the Mac; the only compelling reason for most people is games.

If you’re a big player of FPS games, you want a Windows PC. If you must always have the latest and greatest video card, you want a Windows PC.

Anyone else? You want a Mac. No, Apple doesn’t offer a $400 Mac. If that’s your budgetary limit, you *still* want a Mac, but you can’t afford one. Look at one of the Linux vendors. Because you’re not going to run a decent version of Vista on that $400 PC. And you’ll need to replace it sooner than you would an equivalent Mac. My rule of thumb for non-Mac hardware has been that you’ll get about 12 – 14 months of meaningful use per $500 you spend. I suspect that it’s 18 – 24 months of meaningful use per $500 you spend on a Mac. By meaningful use I mean before you start noticing memory and graphics limitations requiring significant hardware upgrades to keep up to date.

I’m not going back. I don’t know that I’ll stay with the Mac “forever”, but at this point, it’s the best computer investment that I’ve made so far. Aside from that first computer (and it was my dad’s investment then), that started me on the road I’m on.

More on the Wrong Question
Saturday, 20 October 2007

Posted by austin in: Apple, Technology, comments closed

In the comments of my previous question, John asked “what was the wrong question that he asked?” To which I replied:

The wrong question is the comparison between Vanilla Ice and Soulja Boy. Vanilla Ice was low rent back in the day — his second album was a live version of the first album, and his “superstardom” lasted about a year. Soulja Boy’s rap may be better than Vanilla Ice’s rap, but it’d be better to compare Coldplay or Oasis (people with more than one album to their name) to The Beatles or Pink Floyd when asking whether the singles price on iTunes is good, or whether they should be variably priced.

Radiohead may have hit on the right way to handle variable pricing, but that only works when you know you’re sending the majority of your money directly to the band. Most people don’t want to make the soul-suckers at the labels any richer than they need to be.

John replied last night with:

interesting — i read that differently. soulja boy is currently listed as one of the top 10 downloaded songs on itunes, which gave me the impression that his point was about demand. (right now, lots of people want that new hit single, and far fewer people want the old single that now sounds like crap.)

so i thought it wasn’t about which musician was “better” — i don’t especially like either of those songs, personally — but about which musician’s product was currently more “in demand.”

The record execs want you to think that it’s about demand, but it’s not. Demand pricing makes sense when there’s scarcity and you have a lock on the market. Newer music is anything but scarce. You can hardly go anywhere without hearing it as a ringtone, an advertising jingle, or just on the radio. I listen to a “classic rock” format station, yet they’re playing new music from Neil Young and Kim Mitchell, and they consider U2 (up until All That You Can’t Leave Behind, at least) classic rock. So music has the opposite problem of scarcity; there’s a glut.

The radio brings up another important point—as much as record execs would love to pretend otherwise, they’re not competing like you do in other markets. They’re competing against free. There’s plenty of songs out there that I like, but that I don’t like enough to even consider buying even at 99¢—not when I can hear them periodically on the radio. And if I wanted them, but they were more expensive than my lowest willing price, I can usually find them somewhere online. (I don’t; but I have used AllofMP3 before. I already pay the CRIA something every time I buy blank media, so I have the right to get songs that others share that way.)

There is one other theory the record execs could be using here, which is the concept that one values something one has to pay for. Therefore, one values something more that one has to pay more for. If this had been possible when Vanilla Ice was in his (short-lived) heyday, people may have been willing to pay $3.00 for “Ice Ice Baby”, but how many people would have regretted it later and deemed themselves fools? (The song has not aged well.) So the value of a song isn’t really derived from how hot it is, but its longevity. And even then, you’re still competing against a model that treats songs as essentially valueless (radio or satellite radio).

So, demand pricing doesn’t work well if there’s no scarcity (or artificial scarcity). We also know that subscription pricing for portable devices doesn’t work. (More accurately, it doesn’t work for portable devices where you control the content. Satellite radios are portable, but you don’t control the content.) Subscription pricing works when it gives you a menu of things to choose from (cable television, satellite radios) but the value is provided by the menu, not the individual pieces that make up the menu. (The subscription price is too low per person for the individual songs or television shows to be worth much at all. In aggregate, they can make money, but individually they’re fractional pennies value.)

What does work? That’s where we get back to the Radiohead experiment. They asked people how much they value their music. Some folks bought it for the absolute minimum; others paid much more. Most paid about the same price that they’d pay on iTunes. But you have to have an environment where that will work, and I don’t think that the Radiohead experiment is generally applicable for the entire catalogue of some bands’ music. (That is to say that I think that it’s a decent short-term strategy when the music is new, but I don’t think it’s sustainable for more than a few months.)

I don’t agree completely with Apple’s iTMS policy (you can have some songs album-only, but you can’t have an album-only album), as I’d love to see album-oriented rock make a return. (But I’d also love to see sound-bite politics go away.) I think, however, that the simplified pricing models make a lot more sense than pretending that something is more valuable because more people want it, when there’s no scarcity involved.

Souljaboy may be hot. Will he be next year? Or will he be dropped like Vanilla Ice?

When you ask the wrong question, you will get the wrong answer
Thursday, 18 October 2007

Posted by austin in: Apple, Technology, comments closed

In Slate’s What’s the future of iTunes? by Ivan Askwith, the wrong question is asked. Not surprisingly, the wrong answer is reached. Specifically:

…Whomever you believe, the fact remains that content providers have been pushing Apple to loosen up its pricing restrictions, and Apple has refused.

Regardless of demand, each song on iTunes costs 99 cents, each television program $1.99, and each feature-length movie $9.99. Most consumers are likely to agree that iTunes’ pricing seems illogical; there’s no obvious reason that Vanilla Ice’s ‘Ninja Rap 2′ should cost the same as the newest tracks from Soulja Boy. For content owners, this is more than illogical: It’s bad for business.

The question isn’t about Vanilla Ice. The question is about Led Zeppelin, Pink Floyd, The Rolling Stones, The Who, and the Beatles. There’s no reason whatsoever that newer, “hotter”, music should be more expensive than legendary music by these bands. Is the latest Justin Timberlake even remotely as good as “Behind Blue Eyes” or “Paint It Black” or even “Yellow Submarine”?

The usual standard presented by the recording industry morons is variable pricing based on the freshness and popularity of the music, where the more popular and fresh the music is, the more expensive it is. This works in a scarcity model, but music isn’t scarce. Music’s value increases the more that it’s heard and the more people internalize it. But if you’re going to price Soulja Boy’s latest tracks more than Harrison’s masterpiece “While My Guitar Gently Weeps”, you’re implying that Soulja Boy’s music has more value than the older, and better, music.

Why does Apple stick with fixed pricing? Market analysts generally say that this is because iTunes sales are a means to an end, where the end is selling iPods. As such, Apple’s interest is ensuring that desirable content for the iPod costs as little as possible.

John Gruber addressed this quite nicely in September. I’m not trying to say that Apple is perfect (far from it!), but I would assume the obvious: multiple price points confuse people unnecessarily. Those market analysts, of course, are wrong. Ivan Askwith gets this one right:

The more likely explanation, however, lies with the company’s obsession with simplicity. ITunes has been a huge success because it’s easy to use, and (at least for now) has the most digital content of any online store. Apple’s refusal to budge on pricing indicates it’s prepared to defend simplicity at the expense of selection.

That target of simplicity is important: the harder it is for people to play the media they want on the devices they want, the less they’ll buy the one they need less. (And, so far, the iPod is the device people overwhelmingly want. People will forgo on-line purchases if the rest of the device is easy enough to use. I’ve bought a total of four things from iTMS, and two of those were audiobooks.)

Simplicity matters. Amazon works, despite the pricing differences, precisely because it makes the shopping and shipping simple. Amazon’s music store works well because it integrates with iTunes, too.

search

• Categories

  • Apple
    • iPhone
  • HaloStatue
  • Humor
  • Personal
    • Recipes
  • Politics
  • Ruby
    • Archive
    • Ruby PDF
    • RubyConf
    • Ruwiki
    • TRUG
  • Technology
  • Toronto
  • Twitter

• Archives

  Select Month April 2009  (2) March 2009  (2) January 2009  (1) November 2008  (1) September 2008  (2) August 2008  (1) July 2008  (1) June 2008  (1) March 2008  (3) December 2007  (2) November 2007  (7) October 2007  (11) September 2007  (4) August 2007  (2) April 2007  (2) March 2007  (1) February 2007  (2) November 2006  (1) October 2006  (7) September 2006  (5) August 2006  (3) July 2006  (3) June 2006  (2) May 2006  (3) April 2006  (1) January 2006  (1) October 2004  (2) September 2004  (3) May 2003  (1) February 2003  (1) November 2002  (2)

• 

• Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

• Feeds

• Full
• Comments