Archive for March, 2007

« Older Entries

Apple knows interface

Friday, March 30th, 2007

I added a second DVD drive to my MacPro today. Because I can't make my SuperDrive region free I just plumped for putting a second drive in. Now you may or may not know this but there is no CD eject button on the MacPro (or any apple machine). I have a single key on the keyboard.

Eject Key

So I wondered how I was going to eject the second drive. After installing the drive and rebooting this is what I discovered.

Eject Tool Appears

A new menubar tool has appaeared with a familiar eject logo on it. When it's clicked on you see this

Eject Drive?

So now I can eject the two drives either via the menu option or option-eject it. I'm not sure why it says F12 as I have an eject key on my keyboard. Maybe because it's not an apple keyboard something has gone wrong.

What I love about this is that the interface for all of this is hidden from me when I have one drive. I don't need to know how to eject a second drive when I have one.

This sounds obvious but if you use KDE/Gnome/XWindows/Windows machines you start to feel like there are options for EVERYTHING even if you don't know why they are there. Often they are there and they don't even do anything with no feedback to the user. This where apple excel. Vista, LDE and Gnome all look nice but their vendors don't go as far as Apple to hide meaningless interface options. More choice is not a good thing it's just noise. Sure you tune it out over time but it still takes hidden brain cycles to work with.

I'm not certain of why Apple succeeds where others fail but I can tell you what they do is hard. Any vendor can make a menu, decide on keyboard shortcuts, work with standards groups to decide on a code for eject. But it takes lateral thinking, time and space to be able to sit back and say "You know what: when the user has got one drive, let's hide all the work we've done". Maybe that's the key. If you've spent a few weeks making a menu. You, as an engineer, want the world to see it. You have after all slaved over the details. You have lovingly crafted a piece of code, submitted yourself to code reviews, checkin reviews, standards compliance tests and internationalization reviews. After all that 'they' want to HIDE the menu! Maybe Apple's design isn't driven by engineers. Maybe that's why it works. For once maybe it's not about you but about a greater good?

Posted in Apple, Hardware, Rant | No Comments »

Humorous Examples in documentation

Friday, March 23rd, 2007

I've been a fan of adding a little humor to dry documentation for as long as I've been reading dry documentation. It doesn't need to be a stand up routine Just a little bit of the character of the author will do. I just came across this in the Cocoa documentation for NSString:

Discussion
The substrings in the array appear in the order they did in the receiver. If the string begins or ends with the separator, the first or last substring, respectively, is empty. For example, this code fragment:

NSString *list = @"Norman, Stanley, Fletcher";
NSArray *listItems = [list componentsSeparatedByString:@", "];
produces an array { @"Norman", @"Stanley", @"Fletcher" }.

For those who didn't grow up in the eighties Norman Stanley Fletcher is a famous rogue from british television. Made me laugh for a moment :lol: Back to grindstone.

Posted in Code, Funny, Objective C, Software | No Comments »

XQuery is like a breath of fresh air!

Tuesday, March 20th, 2007

I've been processing a lot of XML in Cocoa recently and thought to myself there must be a better way to do this. Rather then loop through the elements pulling out the information I need. That's when I remembered about XPath. Looking in the Apple docs I stumbled upon XQuery which seems to allow a more fine grained control over how you process the XML

I'm processing XML from svn commands like:

svn --xml --verbose stat .which gets the status of all files below the

current directory and can return hundreds if not thousands of entries as you can imagine. Here is a snippet.

<status>
    <target path=".">
    <entry path="build">
        <wc-status props="none" item="unversioned">
        </wc-status>
    </entry>
    <entry path="stat.xml">
        <wc-status props="none" item="unversioned">
        </wc-status>
    </entry>

... blah blah

</status>

Now I want to get all the files that are unversioned or modified. This information is stored in each entry nodes wc-status node item parameter. So I run this XQuery over the XML which returns the nodes I care about:

for $p in .//entry

let $filter := "modified unversioned"

where contains($filter, $p/wc-status/@item)

return $p

line 1 filters the XML so I am only looking at entry nodes.
line 2 sets up a string containing the two strings I will be looking for
line 3 filters in nodes (entry nodes) where the item attribute value is contained in the $filter string.
line 4 returns all elements that made it past all the tests.

The Cocoa class NSXMLNode has a method:

-(NSArray *)objectsForXQuery:(NSString *)xquery
                   constants:(NSDictionary *)constants
                       error:(NSError **)error

which as you can see returns an array of all the elements that match the XQuery given. It's really cool! Here are the Cocoa docs for the XML Classes.

If you want to see what an XQuery returns with some sample XML then look in /Developer/Examples/Foundation/XMLBrowser. It's a piece of example code thats comes free with the Apple Developer Tools to show CoreData but it's a nice little tool for testing XQueries.

Posted in Code, Software | No Comments »

« Older Entries