Press "Enter" to skip to content

Category: Programming

I have a bad feeling about this

Published May 19, 2008

Sometime when I wasn’t looking Apple posted the WWDC session schedule. I hope I’m wrong, but already I see the potential for some serious problems.

WWDC does not seem to have a big reputation for being well-run. I can’t speak to this personally with any great authority; I’ve only attended one previous conference, in 2006. I didn’t really know what to expect, and I was excited just to be there, but even still there were a few issues I noticed. That year the sessions on the newly-announced Objective-C 2.0 and garbage collection were scheduled in a room that clearly was too small for the amount of interest. I saw there was a problem and decided to bypass the sessions, even though I was interested, figuring I could read up on the material later.

Meanwhile, the session on application code signing had been put in Presidio, the largest room — which I interpreted as a sign of the importance of the topic to Apple — but there were well fewer than a hundred people there. So Apple’s track record on predicting attendance is suspect at best.

Now this year they’ve sold out the conference, so we know it’s going to be crowded, and we know many if not most of those people are there for the iPhone. Apple seems to have booked Presidio exclusively with the key iPhone sessions, which is wise, but I fear it won’t be enough. I imagine four or five hundred people lining up early Tuesday morning, parking themselves in Presidio, and staying there for three and a half days. People who try to come for a later session are going to be annoyed if they can’t get in — but if Apple tries to clear the room after each session, people will get really angry.

[In 2006 they apparently ended up “repeating” a few of the overcrowded sessions by replaying them on a video projector one evening. I didn’t go; if I remember correctly, that was Wednesday, the night of the Apple Design Awards and Stump the Experts, and I didn’t want to miss those. This time around I’d probably pass them up, though. For one thing, the former DTS engineer with whom I saw Stump the Experts, and who made it twice as much fun by filling in the back story for me, is probably not attending this year.]

As a would-be independent developer with interests in both desktop and iPhone software, I’m anxious about the scheduling. On the one hand, if the iPhone session fill up I can usually find other sessions of interest to me. On the other hand, the trip out to San Francisco from the East Coast is a big deal in both time and money, and it’s not clear when I’ll be able to do it again, so I’d like to take advantage of the iPhone sessions as much as possible, since they’re clearly of more immediate value. (After all, I’ve got my Hillegas third edition right here already.)

At least if I keep myself on Eastern Time I can show up early every morning and get in line. I’ll miss the evening socializing, but I’m pretty introverted and don’t know anyone in SF, so that’s not much of a loss for me.

I sure hope this works out…

Comments closed

Micro-huh?

Published April 3, 2008

As reported by Macworld: “Exec touts developing iPhone apps without SDK”:

There are more ways to develop applications for the Apple iPhone device than using the company’s beta iPhone SDK. Through a combination of Microsoft and other technologies, developers can build a Web application for the iPhone, according to a speaker at the VSLive conference in San Francisco on Wednesday.

How would you use Microsoft technologies to make an iPhone application? Oh, right: VSLive = Visual Studio Live. Got it. Know your audience.

“Don’t worry about rubber-tired vehicles,” said a speaker at this week’s blacksmith convention. “They can’t take you anywhere a well-shod horse can go.

“And besides, they won’t let you make your own tires, which I find kind of offensive.”

Comments closed

Little details mean a lot

Published March 4, 2008

I’ve just filed my 2007 taxes using the much-maligned TurboTax. (I filed my 2005 taxes this past January, so I’m doing much better this year.)

TurboTax for the Mac appears to have been completely rewritten with an eye towards satisfying the Mac customer, which is a refreshing change for Intuit. (It will be interesting to see how their Financial Life product looks this fall.)

As a good example of leveraging the foundations of Mac OS X to provide specific functionality for the customer: I was pleasantly surprised to be given these choices for saving my return after filing:

  1. “Print returns” (I routinely “print” to PDF, but Mac OS X already makes this easy);
  2. “Backup to .Mac”: this puts a copy of my TurboTax data file, as well as a PDF with my return and all supporting worksheets, into a folder (Documents/TurboTax/2007) on my .Mac disk;
  3. “Burn to CD”: this uses the standard disc burning interface to put a copy of my data file as well as the TurboTax application (fully updated, as far as I can tell) onto a CD. Brilliant. (I can’t tell you how much time I wasted looking for the 2005 software. The fact that it wouldn’t run under Leopard once I found it is another issue entirely…)

These are the little details that Mac users expect in their software (otherwise they wouldn’t have bought a Mac), and companies that pay attention to things like this should be able thrive in the Mac marketplace. Granted, Intuit’s reputation on the Mac is in tatters (and deservedly so), but I’m much more inclined to check out Financial Life now than I was before.

Comments closed

Dancing with the elephant (revised)

Published November 3, 2007

While gathering information about application compatibility with Leopard, I notice one developer, Snerdware, is struggling to keep up with the situation. They report two major problems that affect their current applications, and, with some evident frustration, blame both of them on Apple. [Note: I’ve substantially rewritten my commentary on the first issue, since I’ve learned additional information and since my main point applies to the second issue.]

The first issue affects both their products; the report here is for AddressX:

AddressX won’t startup on 10.5.0/Leopard running on an Intel-powered Mac (a log indicates “… Reason: no suitable image found. Did find: /usr/lib/libcrypto.0.9.dylib: mach-o, but wrong architecture. …”).

When we looked at the 10.5 pre-release, we encountered an OS X library issue — it installs a non-universal/PPC-only version of a library that’s critical to our applications (and, of course, all our developer systems are Intel-powered). ‘Though we filed a bug report early in October (original Problem ID: 5520955 and have now re-filed it), believe it or not, it’s still a problem with the released/commercial version of 10.5.0 (even without the bug report, you’d think that a check to ensure all binaries are universal would actually be a basic QA step — it’s one that’s easily automated!).

After corresponding with someone named Bryan D. at Snerdware and doing a little more research, I’ve learned the following things which make me more sympathetic to their problem than I originally was:

  • Apple includes two versions of libcrypto: one called libcrypto.0.9.dylib, and one called libcrypto.0.9.7.dylib, and a symbolic link libcrypto.dylib that points to the newer library.
  • In Leopard, the newer library is indeed a four-way universal binary, but the older library is PowerPC only. I originally assumed this was because only pre-Intel applications would require it, since libcrypto.0.9.7.dylib has been available in Mac OS X at least as far back as 10.3.9; and so Snerdware was making a mistake by linking to the older library and then complaining that it wasn’t universal.
  • But it turns out that Snerdware relies on features that are present in the older library (which corresponds to libcrypto version 0.9.6l), but have been removed for some reason from the newer library.
  • More strangely, Apple did include a universal binary of libcrypto.0.9.dylib in the Intel versions of Tiger, but strangely left it PowerPC-only in Leopard. Huh?
  • Snerdware originally considered compiling the older library into their program, but since it’s crypto there are all kind of export regulations that come into play (and believe me, I know about this; I had to research exactly this topic at a previous job).

Hopefully this was indeed an oversight that can be fixed in a future update; otherwise, Snerdware has a problem with no easy solution, and some portion of the blame lies with Apple.

The second issue is a more fundamental problem, and one that affects nearly all Mac developers — Apple has a history of making significant changes to core system services between OS versions. I presume that Apple doesn’t do this maliciously, but there are plenty of developers who will tell you they’ve been burned by Apple changing or dropping technologies. Apparently Snerdware is once burned and twice shy:

Since we’ve previously been seriously “bitten” by Apple’s last-minute major changes to developer pre-releases, we can’t afford to take pre-releases seriously until they are near release. […]

With the imminent release of 10.5.0, we […] discovered that, even ‘though OS X’s Sync Services has the same interfaces and we’ve seen no documentation/release notes that document subtle but significant changes in behavior, we see that the behavior has changed in a way that will cause us to make very major changes to Groupcal … Given that Groupcal was working very well with 10.4, this is more than annoying for us, as well. Be angry with Apple, not with us.

[…] It’s things like this that make it much more difficult for an OS X product to be a viable business proposition.

Here I have a harder time finding sympathy. By their own admission they waited until the last minute to check whether the behavior of Sync Services had changed, and now they report to their users that their flagship product won’t be compatible until the first quarter of 2008, and point the finger at Apple?

(Luckily their target market appears to be corporate workgroups running Exchange servers, and those folks are less likely to be rushing out and upgrading to Leopard, so Snerdware may have some time there.)

If my livelihood depended on my product operating correctly with Sync Services, I wouldn’t rely on Apple keeping its behavior unchanged from release to release; I’d be booting up each Leopard seed on a non-critical system and checking things out. Perhaps I’d muster up the resources to send a developer to WWDC, where Apple encourages you to bring your code, try it out on the current seed, and discuss problems with the Apple engineers who have come up from Cupertino for the week for just this reason.

(To be fair, I don’t know that Snerdware didn’t do this; but with the “can’t afford to take pre-releases seriously” comment above, I somehow doubt it.)

And then — well, maybe Sync Services does change in the September seed and I still have a lot of work to do — but wouldn’t I’d be five weeks further along?

If you choose to dance with an elephant, you can approach it one of two ways — you can wait for the dust to settle, and then see what the lay of the land is; or you can try to be more nimble and maneuver around the elephant. We independent developers are supposed to be more nimble… aren’t we?

[But sometimes, even if you’re nimble, you can get still stepped on…]

Comments closed

Ruby vs. Python (take 147)

Published July 25, 2006

Tim Bray, a new student of Ruby, admires it for its readability, and compares it to Python:

In theory, Python ought to do better, lacking all those silly end statements cluttering up the screen. But in practice, when I look at Python code I find my eyes distracted by a barrage of underscores and double-quote marks. Typography is an important component of human communication, and Ruby’s, on balance, is cleaner.

John Gruber concurs:

Now that I think about, those underscores and extra quotes are exactly why Python does not appeal to me. I find Python’s indentation-as-block rule to be quite elegant, but its use of punctuation feels clumsy.

As a Python programmer (but not a Ruby programmer), I have to say:

Huh?

I respect both Bray and Gruber, but I don’t see their point. At all.

When I look at my Python code, I see underscores in two contexts. The first is in the names of “special” methods and attributes. In practice for me, this is largely limited to __init__, since I rarely need to overload operators. (And this syntax makes such identifiers stand out as “special”. Who’s to say that this is less attractive than Ruby’s use of $ to mark global variables? Are underscores uglier than dollar signs?)

The second, more common use of underscores in my code is in long Cocoa method names, because by convention in PyObjC they replace the colons in the Objective-C selectors. Those underscores are generally acknowledged as ugly by the PyObjC community, but accepted as a necessary evil. I suspect Tim Bray is not writing PyObjC code. (Maybe he’s writing more special operators than I am.)

As for quote marks (single or double), the only “barrages” I can think of are in multi-line string literals, which are frequently used as documentation strings (or comments, effectively). I suppose this criticism might come from the common use of string literals as symbols — e.g., as keys in dictionaries (hash tables) — where Ruby has an actual symbol type, whose syntax is borrowed from Lisp keywords (a prefixed colon).

Whereas if one wanted to criticize a language for “clumsy” punctuation, one might point to any of the fourteen-odd uses of non-alphanumeric symbols in Ruby found here: marking different kinds of variables with $, @, @@, and &; four kinds of “quoting mechanisms” with %X{..}; etc. (Is that Perl I hear calling?)

Perhaps that’s why neither Bray nor Gruber commented on the controversial use of @ in Python to mark the user of a decorator function.

So I have to say I just don’t get it. To each his own, I guess. I see that Ruby is getting a lot of buzz these days, in large part because of the success of Rails, and that’s fine; if I had to throw together a quick web application I might investigate Rails too. Perhaps it’s just that I came to Python first and don’t really know Ruby very well.

Still, to me, saying Ruby’s use of punctuation is “cleaner” than Python’s is (to paraphrase Gruber) like criticizing the iPod because it doesn’t come in white…

Comments closed

PyWikit

Published June 22, 2006

In response to a challenge in the Mac forum at Ars Technica, I’ve banged out a quick service that adds “Search With Wikipedia” to your Services menu (right below “Search With Google”). It’s called PyWikit because (a) somebody suggested “Wikit” for the name and (b) I wrote it in Python, using PyObjC. To use it, download it and move it to your ~/Library/Services folder. At the moment you will probably have to log out and log in again to update your Services menu. If I get motivated I’ll build an installer, someday. (Unlikely since I’ve only spent about an hour on this, most of which was taken up building a universal binary for PyObjC. While it is true that PyObjC rocks, its universalness is still a little, uh, rocky.)

3 Comments

SubEthaEdit for $0 is a great deal

Published April 25, 2006

SubEthaEdit from CodingMonkeys is an excellent collaborative editor that I’ve used to help create session notes at past PyCons. Many people also use it as a programming editor, although to date I’m still in the BBEdit camp.

Now, as part of BLOGZOT 2.0 on MacZOT.com, MacZOT and TheCodingMonkeys will award $105,000 in Mac software — specifically, free SubEthaEdit licenses (if enough bloggers link back to the web site to reduce the license price to $0).

Obviously, the intention is to drive a lot of visits to the MacZOT site, but SubEthaEdit for $0 is a great deal no matter how you slice it. (And MacZOT is an interesting idea itself; I’ve used it once or twice to spring for software I might not have otherwise bought, when the discount pushed the price down to impulse buying levels.)

(Thanks to Matt Deatherage for the heads-up.)

Update: Yes, enough bloggers fell for the offer to drive the cost down to $0, and I got my free license code over the weekend — thanks, MacZOT and Coding Monkeys!

Comments closed

Exclusive: New Tiger window style deciphered

Published April 15, 2005

Paul Thurrott accidentally wrote a pretty favorable review of Mac OS X 10.4 (“Tiger”). Towards the end, he apparently realized he was losing all his street cred in the Windows world, so he threw in some gratuitously negative comments — “Tiger is in fact a minor upgrade with few major new features, more akin to what we’d call a service pack in the Windows world” — which, apart from being patently ridiculous, supports the not-very-original premise that Apple fans are “suckers” who will immediately cough up the cash for mere glitz.

  • Pretty tough stance for a self-described “Mac fan [his] entire life”; so much so, we learn, that in 1987 he replaced his Commodore 64 with … an Apple IIgs. This was followed by an Amiga; then, when Commodore went belly up, a PC running OS/2 — this is one industry analyst who really knows how to pick winners — and finally, in 2001, an iBook. Pity the poor “Mac fan”, pressing his nose against the glass for fourteen years.

I mention all this as an excuse to use another of Thurrott’s comments as a jumping-off point for an observation I have not seen elsewhere as yet. (Not that anyone’s going to see it here, but at least I’ll be on the record.) By now many people have commented on the new window style seen in Mail, where the title bar and toolbar blend together in a single gradient. Thurrott remarks upon “yet another user interface style”, which he calls “plastic”; others have called this change “arbitrary” or “gratuitous” or “confusing”.

Well, I think I’ve figured out the logic. Here are some applications using the new window style: Mail, Help Viewer, System Preferences, Xcode 2, and the Spotlight window itself. What do these all have in common? The Spotlight search field. The new window style, to me, is a visual cue that the application supports Spotlight as a primary navigation mechanism.

Unfortunately this analysis fails in two important respects:

  1. I haven’t found anything in the Apple documentation that suggests this usage is intentional. (Of course, the Tiger developer documentation hasn’t been publicly released yet.)

  2. A huge exception to the rule is the Finder, whose windows still (inexplicably) use the “brushed metal” style. You’d expect that if a Spotlight cue were present anywhere, it’d be in the new Finder.

Still, this is the best theory I know to explain the new style, and I haven’t seen anyone else mention it, so I hereby take credit for it.

  • On the other hand, Mail’s toolbar icons… I understand why they’re in “capsules” (to allow for toolbar button “groups” — though it makes the non-grouped icons needlessly cramped), and I even know why they’re “centered” (they’re not; they’re left-justified over the message list, skipping over the mailbox source list — a bit of a hack, but having Delete and Junk over the source list is potentially confusing). But I won’t make apologies for them, either.

[2005-04-16: Added Help Viewer to the sample applications.]

[2005-04-22: Well, I could be wrong… see first comment.]

[2005-05-05: Yes, I’m wrong… see second comment.]

2 Comments

EA Spouse speaks out

Published November 19, 2004

I’m only just hearing about the [EA spouse][] who spoke out about the increasingly extreme conditions under which the SO was working. At last count this single weblog entry had 2780 comments.

[EA spouse]: http://www.livejournal.com/users/ea_spouse/274.html

Reading the description of the EA development process from the point of view of a longtime software engineer, my mind boggles at the idea of a “pre-crunch” to ramp up for the “real” crunch, followed by a “super-crunch” — all apparently planned for in the schedule. Folks, apart from being disgraceful and probably illegal, this plain just doesn’t work; engineers get fatigued and you end up with crappy software. And no compensatory considerations for the staff? No money, no comp time? It’s not like EA is a startup company; they’re making money, and they’ve been making games for years. They should know better.

I’ve worked at three different companies, including one in the gaming subindustry. All of these companies were startups or startup-sized, and so the success or failure of any one project might mean the success or failure of the company as a whole. We knew this and reacted accordingly — when the time came, we put in the level of effort needed to accomplish the job, up to twelve- to fourteen-hour days, six or seven days a week. (I tried very hard to keep one day to myself, to protect my own sanity.)

In my experience, we were *always* compensated for our extra effort in some way, usually comp time or cash. In one case we had a specific deadline with promised bonuses for meeting it, including an extra bonus for the “team MVP.” We were given every opportunity to meet the goal (including moving the deadline back ten days after the server failed in the last month), and everyone got the MVP bonus. (We ended up not shipping for another fifteen months, but that’s another story.)

More meaningful were the “personal” rewards. Once our company president got us tickets to a Celtics playoff game (in ’85 — Bird/McHale/Parrish). At the gaming company I was given the opportunity to do a personally meaningful project and given a brand-new Mac II and hi-res color monitor to do it with. It’s a cliché to say this can mean more than the money does, but it’s also true.

So why would someone put up with the conditions described by the EA spouse? Sometimes (as in this case, seemingly) they needed a job in a weak market; sometimes they just didn’t know to expect any better.

One more story from early in my career: one Friday the boss asked me to demo my current project at the company-wide meeting on Monday. Unfortunately it wasn’t working yet, but I was young and the boss was new, and I was too intimidated to say anything. So I worked throughout the weekend, giving up going to New York on Saturday to attend a good friend’s wedding — to my lasting shame and regret. (And on Monday? No demo; something else came up at the meeting, and I didn’t speak up.)

[I wrote the above before skimming the comments. Apparently (a) EA’s record in this area is widely known, and (b) they’re not alone in this. It was nowhere near that at the gaming company I worked at in the mid-to-late ’80’s. I won’t name it here; it’s no longer around as an independent concern. If you Google my name you can probably figure it out on your own.]

Comments closed