Month: February 2005

On the Move, Part I

I’m copying a bunch of applications over to a new machine. Replicating the settings for those applications is more application-specific than I was expecting. Here are the two I’ve tried so far.

MarsEdit:
I love MarsEdit primarily for its preview template. I could use my weblogging software’s posting mechanism instead of MarsEdit, but that software’s preview doesn’t actually make the previewed post look like it will look in my weblog. MarsEdit can do this.

But after I copied the preferences file (com.ranchero.MarsEdit.plist) from my user-level Library/Preferences directory on old machine to my new machine, MarsEdit still used its default preview template. I had to also copy over everything from my user-level Library/Application Support directory in order to get those settings.

Now, Apple’s guidelines say that the Application Support directory is for files like “document templates and sample files.” I am interpreting that to mean unchanging template files that ship with the software, such as e.g. Microsoft Word’s various letter document templates. I don’t think that means things the user can configure, which I think should go under Preferences.

However, other applications also dump files with user info in the Application Support directory. Firefox seems to put your entire profile there, for instance.

I’d rather not have to look in two places for files with user configuration info, but the guidelines don’t seem to provide crystal-clear guidance on the issue.

DragThing:
For DragThing, as for MarsEdit, the first thing I tried was just copying over the preferences file. This failed for DragThing as well, but not because there were missing Application Support files. Instead, in order to make the preferences file work in the second DragThing, I had to explicitly import the preferences file.

How did I know to do this? Because DragThing’s import window specifically says, “Select a folder, XML dock file, or “DragThing Preferences” file to import.”

Not sure what I think about this. On the one hand, the UI is clear and intuitive. On the other hand, why do I need to go through an import? Why doesn’t just copying the files work, like it used to work for almost every application?

Does it work anymore for any application? Stay tuned.

An Exercise for the Reader

A while back, I bought Test Driven Development: by Example by by noted banjoist Kent Beck.

On p. 5, after presenting me with the first code of the book, he writes, “I’ll explain where and how we type it in later, when we talk more about the testing framework, JUnit.” He then proceeds to go on for pages, describing more and more code changes and additions, without ever coming back to JUnit.

Odd.

Still, I decided to keep going. I spent some time getting JUnit set up on my own – Java CLASSPATHs are evil evil evil – and got back to the book a couple of days ago.

It didn’t take me long to realize that even with JUnit in front of me, I wouldn’t be able to follow along with the book. It’s just not written that way. There isn’t anywhere near enough detail provided: what his classes inherit from, how they should be arranged for the sake of later steps, etc.

Now, one of the benefits of TDD as he describes it is its immediacy – you can get to work right away knowing that any mistakes you make will be corrected as you go along. But his book doesn’t allow you to experience this benefit. It just lets you peek in through the window as he experiences it.

Now, JUnit appears to include the example he describes, but it’s the finished example. You’d have to reverse engineer it to get it to the point where he starts his work on it. Basically, you’d have to learn it on your own before you learn it from him. So what do I need the book for?

I’ve heard very good things about TDD from various people, so I will still be giving it a try, but this was a frustrating first experience from a recommended resource.

Don’t Use the Brown Project File

I have an old project that I dusted off today that uses the Omni frameworks. It’s old enough that I remember a time when the frameworks built without a hitch.

Then they stopped building. I searched on the Omni Mailing Lists page and found a variety of build problems people were having.

But the message I needed to read was this one, which says “Even if you’re building with Xcode, you may want to stick to the .pbproj projects….” Turns out the *.xcode files are outdated, despite the fact that it’s a newer project file suffix. With the *.pbproj files, everything builds fine.

Should it have occurred to me to try the older files? Sure. But a Readme note, or removal of the outdated project files, or some update in the six months since this was last released, beyond an obscure mailing list message….would’ve saved me some trouble.

The Unix Carapace

In a previous post, I said (or at least implied) that Mac OS X should not be considered “Unix with a pretty GUI on top.”

But why not, you ask? What’s the big deal? After all, in some ways it’s a pretty accurate technical description.

It’s all about perceptions, and priorities.

Another way of phrasing it would be to say “Unix with a pretty GUI shell.”

In my estimate, a shell is an add-on used for convenience. Shells are interchangeable: the important thing is the underlying functionality. Shells just modify how end users access it.

Software becomes less shell-like the more people use it and develop for it based on the added functionality, or for a combination of the new and base functionality. Windows 95 is (shudder) a good example of this. The real money was and is on Windows apps, not DOS apps.

Software becomes more shell-like when you can discard it at will.

GNOME and KDE are large, complex…shells. Sure, there are some apps that are built on top of GNOME or KDE, but they can be exchanged for others. Linux, and the ability to run Unix applications, is what matters.

When people talk about how wonderful it is that you can run Unix applications, mostly unchanged, on Mac OS X, what they’re saying is that Mac OS X is a really nice Unix shell.

If Apple’s biggest achievement with OS X is attracting lots of Unix developers who think that, then it has failed. Because those developers can, and will, discard OS X at will. And their Unix apps, which will run just as well on cheaper Intel boxes, won’t sell Macs.

In my opinion (and all of this is just my opinion), Apple’s priority should be the applications that will.

I Love Trash

Tonight, I’m on page 126 of my Learning Python book. (It’s not exactly a page-turner.)

So far, no mention of mandatory source code indentation, except as the briefest aside. It’s a bit amusing how it’s the first thing everyone thinks of, yet my tutorial is playing coy. Well, be that way, you tease!

One thing it does mention is circular, or “cyclical” references. Object A refers to object B, which refers to object A.

>>> A = ['tiger']
>>> A.append(A)
>>> A
['tiger', [...]]

In the above case, an entry in list A refers to list A itself. So if you tried to print A, you’d get an infinitely long list.

But Python detects this case, and substitutes [...] instead. I’m going to assume this is list-specific, but that Python does this even just for standard types is heartening.

Does Python apply the same kind of logic when implementing automatic garbage collection? Will it recognize that a list, whose only remaining reference is from an unreferenced object within that list, can be gc’ed?

Per this page, the answer would appear to be yes: “Fortunately, Python’s cyclic-garbage collector will eventually figure out that the list is garbage and free it.”

The rest of that page, however, seems to imply that for more complicated custom classes, sometimes you need to take care of cyclical references yourself.

Is that a rare case? Or an inevitable gotcha as you start writing more complex Python programs?

My book is mum on the subject.

Now For Something Completely Different

I bought Learning Python a couple days ago and have read maybe 100 pages in.

It’s no wonder people who like Objective-C like Python!

You get…

– Typeless variables, like Objective-C’s id.

– Garbage collection without Java.

– String addition using overloaded + without C++.

– Automatic upgrading of numeric variables, something you can’t do with C types like int, float, etc.

– Mutable and immutable collection types like in Foundation.

What’s not to like?