So here is an interesting experiment.

Posted on by
Reply

I have a meeting in downtown Los Angeles, right off a subway stop at 7th street. So I thought I’d take the subway.

Why not; if I’m going to help pay the fourth billion dollar tax bill of the subway I may as well get some value out of it, right?

A few notes: first, it feels like any other subway I’ve taken in Europe or back east. Except for the turnstyles, which do not exist: the whole thing is run on the honor system. Well, there are cops, but they seem more interested in stopping me from taking pictures than they are in making sure I have a value day pass.

I take pictures anyway.

If I had taken my car to the office building at this time of day it would have taken me 20 minutes to get there. As it is it took me 10 minutes to get to the parking lot, another 10 minutes to park, and about a 10 minute wait for the subway car to run. I gave myself an hour. Let’s see how well this pans out.

A day pass is only $5, making this cost effective if I’m paying for parking. And so far the train seems to be running with efficiency: since my meeting ends at five my theory is that it may save time on the return trip, since downtown traffic is a nightmare at rush hour.

Later…

It took about 25 minutes, making me about five minutes late to my meeting. Not bad, not great.

Later…

Now the real test: leaving downtown Los Angeles. Right now trains are running every 10 minutes; if I can get back to my car in a timely fashion, then this will be–well, not a win, but at least a draw.

It’s clear to me that the real purpose of the subway is not transportation, though it serves that role. The real purpose is infill redevelopment in the Los Angeles area. I may just pop my head up at a couple of stops to see if I find what I did in Hollywood: massive development at each stop.

Huh. The train is late.

Addendum: I’m playing subway “wack-a-mole” and poking my head up every few subway stops to test my theory that the subway is about redevelopment. This may take a little longer, but it is more entertaining.

Later…

I think the LA subway is interesting. As a transportation method it is clearly a failure: for what we spent for it we could have improved the freeways a lot. But for incouraging infill development, it works very well.

I love Wikipedia.

Posted on by
Reply

The other day I had to hook up some code via JSON. Having no idea what JSON is, I looked on Wikipedia. Basic data types, examples, syntax, and a link to RFC 4627 later, and I was set. Cool!

I wanted to implement a hash map, but I wasn’t sure if I wanted to do what I’ve done in the past, which is to represent each hash bucket with a linked list, or if I wanted to use a list. Unsure of the pros and cons, I looked up Hash tables on Wikipedia and got a reasonable overview discussion.

I’m finding there is a lot on Wikipedia that provides a good cursory overview of different protocols and algorithms, and more importantly, points me to the relevant research, descriptions or RFCs which describe the thing in greater detail. And while I tend to take Wikipedia with a grain of salt (you never know if the guy who wrote the article knew what he was talking about, or if the page was vandalized), the cursory overview (even inaccurate) combined with pointers to scholarly research or published standards makes a great reference.

I know this is old news: however, in the past few days I’ve found myself using Wikipedia as a starting point for a lot of CS related searches.

Another gotcha to remember.

Posted on by
Reply

For some reason a development profile seems tied to the computer as well as the specified phone on the iPhone. What this means is that when you move the device from one computer to another to work on some software (say, a personal laptop to a personal desktop and back again), you need a way to clear out the development profile before things will work again.

I learned this the hard way yesterday when I blew away the contents of my iPhone, only to have things not work correctly (and deleting all my music at the same time).

Turns out the profile certificates are accessible and can be deleted from the iPhone itself: under “Settings” navigate to “General”, then scroll down to “Profiles”: this will show a list of profiles installed on the device which can then be deleted. Delete your development profile(s) from the device before plugging it into the new machine, and Xcode will load the profile for that platform onto the iPhone and things will just work again.

It’s why God created tool tips.

Posted on by
Reply

Don’t hide or disable menu items.

This is what separates the User Interface men from the User Interface boys: the suggestion “Instead, leave the menu item enabled. If there’s some reason you can’t complete the action, the menu item can display a message telling the user why” is the most Gawd-aweful suggestion I’ve heard in a long time.

The correct answer, of course, is to create a tool tip which pops up over the disabled item which indicates why the item is disabled. That way we have instant feedback on what a user can do, and if the user is puzzled, he can easily discover why a particular item isn’t currently selected.

In Java, you can do this by calling JMenuItem.setToolTipText(); set the value to an explanation why the menu item has been disabled, and the explanation will pop up when the user hovers over the disabled item.

On the Macintosh, with Cocoa you can do this by setting the ToolTip text field in the IB .xib file with the text describing the item; call NSMenuItem’s setToolTip: method in order to update the text for the disabled menu item.

And even Windows has the ability to create tool tips for disabled menu items, though it takes a hair more work: by watching for WM_MENUSELECT notifications you can then pop up a CToolTipCtrl, or update a status bar text line, showing the appropriate text if the item is disabled.

So as much as I appreciate Joel’s comments on the software development industry, on this particular item, ummmmm… No. I agree more with John Gruber: you’re much better assuming your users are clever. But if your menu command structure contains commands which are just odd or hard to puzzle out at first glance, tool tips are much better than an idiot modal dialog box. It’s just more elegant.

Self employment health care

Posted on by
Reply

The first thing I did as a 42-year-old with a wife when I left my job to go down the self-employment route was to get health care insurance. And boy is it complicated!

To summarize, I managed to get Aetna with a moderately high deductible ($5k/year) for both of us for around $300/month.

What made the decision making process complicated is not really understanding the various deductions and coverage exemptions. But it boils down to this: the various Aetna plans essentially have two rate structures. The first rate structure is when you see people who are part of the Aetna system; the second is for those who are not part of the Aetna system. And each rate structure includes a deductible (the maximum you will have to pay out of pocket for medical care per year), a “major medical” deductible (the maximum additional amount you’ll have to pay out of pocket if you get something like surgery), a visit co-pay (what you’ll have to pay when you see a doctor) and a prescription co-pay (what you’ll pay for a prescription). Each of these four numbers (deductible, major medical deductible, co-pay, prescription) is repeated twice: once for in-system and once for out-of-system. Once you’ve hit the deductible, of course, Aetna covers the rest up to $5 million–at which point, I presume you’re screwed. (A friend of mine died a few years ago; his medical bill exceeded $1 million for a 90 day stay in the hospital with a constant stream of tests and the attention of a whole bunch of specialists. That means that while a $5 million cap isn’t impossible to hit, it’d require a pretty nasty health care disaster on the scope of 15 months of hospitalization.)

Each of the different plans I saw from other companies looked roughly the same: about a dozen or so confusing numbers–but all of which boil down to your own responsibility before the health care package kicks in. (I only went with Aetna because I was covered by Aetna when I worked for Yahoo! and Symantec, so I wanted to keep things simple.) Ultimately, however, after wading through each of the numbers, health care insurance boiled down to how much I was willing to pay each month verses how much risk (how high a deductible) I was willing to live with. For someone who is self-employed with a huge pile of savings, it seemed a high deductible made the most sense: in the event of a disaster I can easily write a check for $8k (my max out of pocket if I’m hit by a bus, which is the deductible amount plus the “major medical” deductible on my policy), but in the starting stage of my startup, I’m not making any income.

Java sucks and Objective-C is great? Puuuhhhllleeeeaaassseee…

Posted on by
Reply

I still remember the brouhaha raised over Java on the Macintosh, and pronouncements by many of the Macintosh Technorati that Java sucks. (I believe Gruber’s words were Cross-platform crippity-crap Java apps.)

By all of the various posts I’ve seen, I’d think that Java was a complete wasteland while Cocoa was the rolling green hills of programmer nerdvana.

Okay, that’s fine. I set forth building a new custom application for the retail market, and faced with the various choices for building a cross-platform system I decided to build a simple data core in C++ with the Mac UI in Objective C++ and Cocoa, and the Windows UI in MFC/C++. (The common data core is to assure that data can be easily shared, but is a very small kernel: perhaps right now about 10% of the overall code base. So I’m not trying the YAAF-lite solution of building a UI framework on top of Objective C++ or MFC; rather, I’m building the UI twice, with a common set of data accessor routines at the bottom of the stack.)

Nerdvana? Hardly.

Today’s fun-filled afternoon was spent trying to figure out how to do an easy gradient fill for a custom control so it doesn’t have a flat, 2D appearance. With the sheer beauty of the Macintosh UI environment, you’d think would come convenience routines–but not really: the amount of work to build a gradient filled background was about what I’d expect using the Graphics2D class in Java.

And I’ve come to a couple of conclusions while engaging in this little exercise.

(1) The advantages outlined in Jens Alfke’s essay about making superior interfaces only gets you half-ways through the front door. To make it across the finish line requires a lot of nit-picky detail work that the Macintosh Cocoa libraries only sorta help you with. Sure, there is plenty of support for animation stuff which is really freakin’ cool. But to draw my simple gradient in a way which was portable back to MacOS 10.4 (and my business app needs to be supported by the current version and the previous version of MacOS X) required about 120 lines of code–which, while it took a couple of hours to toss together and test, wasn’t the easy exercise that many Cocoa advocates seem to suggest awaits all who come to the Cocoa big tent.

This isn’t to say that there aren’t advantages to Cocoa over Java Swing or MFC. However, there are many places where Java’s framework has a clear advantage: the JScrollPane class, for example, is a lot more flexible to work with than the NSScrollView class. And don’t even get me started on NSTreeController, though Rentzsch’s comments on enabling NSZombieEnabled was a god-send.

A corollary to this is:

(2) Macintosh applications look great because Macintosh programmers sweat the details, not because the Macintosh environment makes sweating the details any easier than in Java or Windows MFC. It could very well be the Macintosh market: people expect pretty applications, and so a lot of attention goes into making pretty applications on the Macintosh. This attention to detail, however, doesn’t really exist in the Windows market–and don’t even get me started on Enterprise Java applications. (I will agree with Gruber on this: a lot of Java Enterprise Swing applications do look like crap.)

However, this does not mean that the look and feel of Java applications are doomed, any more than it means Cocoa applications are uniformly great–nor does it mean to get the same level of greatness on a Java application you must spend two or three times more effort than on a corresponding Cocoa application. (And it’s not like Cocoa has inherently better support for creating icons like Panic’s beautiful icons, as opposed to the type of 1980’s icons you see in Java: nowadays they’re both PNG files.)

This attention to UI detail, by the way, predates Cocoa, and even predates NeXT, as anyone who ever read the original Apple Macintosh Human Interface Guidelines would attest. In fact, if anything, NeXT programmers and Cocoa programmers prior to the Apple merger weren’t exactly producing stellar examples of UI goodness: I’d say the biggest problem that I saw as an outsider when Apple and NeXT merged was having Apple’s attention to UI detail and usability drilled into the NeXT programmers–much to their shock. Even today I’d say that Apple’s attention to UI detail is only about 90% of what it used to be in the Mac OS System 7 days.

And that attention to UI detail wasn’t because Mac OS System 7 was a fantastic object-oriented development environment. (I should know; I was writing software for System 6 and earlier.) It was because you would sweat details like the fact that on System 6, an OK button was offset 14 pixels–not 15, not 13, not 8–from the lower right of the screen and was 58 pixels wide, not 57, not 59. (Now I will say that System 6 was superior in one aspect to Microsoft Windows–a superiority which existed for quite a few years: Macintosh QuickDraw’s CopyBits() routine was light-years ahead of any bit blitter available on Windows or on X windows: it would anti-alias, crop, stretch, extrapolate, and even fold your laundry and put it away for you, giving the Mac OS System 6 platform a clear advantage over Windows 3.1. But Windows and X windows caught up in that department long ago.)

So anyone from the Macintosh Technorati who suggests that Cocoa is inherently superior–I’m used to religious wars, even from people who should be intelligent enough to know better.

Oh, and for the curious, I’ve attached my GraidentFill class in Objective C using the CGShading routines to handle my custom control shading. It’s really not as flexible as the 10.5-only NSGradient class, but it does the trick.

Common edit design pattern.

Posted on by
Reply

Messaging is an important aspect of application development, especially in a UI-driven application.

While working on the undo architecture of an application I’m putting together, I ran into an interesting problem, and a general-purpose architecture which could handle this popped into my mind, that I thought I’d jot down for future reference. Feel free to borrow the idea if it seems useful, and pardon me if the idea is blindingly obvious.

A typical editing architecture essentially can be represented as a state S which represents the current state of the document, and a set of messages fi which transforms the state Si to a new state Si+1. Each message f represents an editing change to the document S.

Now a typical undo architecture handles undoing messages by storing the creation of messages f’ which is the inverse of f. When an edit operation f is generated and document S is transformed, an inverse operation f’ is created (in practice, as part of the code implementing the change message f) and added to a stack of undo operations, which can then be used to undo the operation on S. In theory as long as each operation has an inverse, we can maintain a perfect undo stack. In practice, of course, user considerations muck up this perfect world: for a text editor, for example, individual keystrokes f(key) may be coalesced into a single insert operation for purposes of an undo operation. (In that case, the easiest way to maintain this undo state is to allow the code creating the f’ function to peek at the top of the undo stack, to determine if the existing top of the undo stack can simply be extended.)

A second thing that one can do with messages f to a state S is that you can then use those messages to determine if S has changed, in order to update the user interface element displaying the document S. For example, if you have two text editors opened to the same document, each keystroke f(key) can trigger a message from S (call it ui) which triggers a user interface update.

Now I was working on an application which had multiple user interface elements editing the same object, and I was generating messages ui which was being used to update my user interface elements. The bug I had was that, when I would edit a state, the user interface would be updated–because my UI handling code would do:

    myDocument.sendEditRequest();
    updateMyUserInterface();

And of course on undo, the undo code would do the equivalent of:

    myDocument.sendEditRequest();

It strikes me that there are two solutions to this problem, though unfortunately most UI frameworks I’ve encountered makes the second solution a bit harder to implement in a natural way.

The first solution is to always use the state changed messages ui in order to drive the user interface refresh cycle. Sometimes this may not be the easiest thing to implement, however: some basic controls (such as check boxes and radio boxes) update their state automatically and really, updating their state again on receiving a state changed message is redundant.

The second solution is, on creation of an edit change request, to automatically note in that request the source of the change: thus, one of the parameters of a change request f is the originating object that sent the change. (For an undo change, the requester would be set to a value indicating that the message came from the undo manager.) The state changed messages would then pass the source of the change request on in the ui messages, so that a user interface element receiving the message can then choose to ignore the message if needed.

I personally like the second solution better than the first; the added flexibility allows my user interface control code to decide how to handle a state change. Unfortunately the undo manager in both the MacOS X Cocoa Framework and the Java Swing Undo manager would require a bit of extra bookkeeping in order to properly set the source of a state change. However, I think the extra work may be worth it on a future project.