Please do not publish this doc without checking with Anita. I’m in the process of reviewing and editing it. Thanks. AnitaWhat’s coveredIntroduction to the GPUGPU features in Photoshop and Adobe Bridge…

Here’s how it looked in NetNewsWire:

Those run-together words in the feed are a fair example of the lack of attention to detail in the design of the Adobe support site. There’s good stuff on there, but finding it is frustrating and anyway wouldn’t you rather download a demo of something with motherfucking Akamai download manager?

Meanwhile Anita must have said to go ahead because there’s no mention of her on that article’s page now.

Updated: I have re-written this post and the example to make it simpler following Marcel Hellkamp’s comments (Marcel is the primary author of Bottle). My original example was needlessly complicated.

It is possible to have a Django-style urlpatterns stanza with a Bottle app. Here’s how it can work:

from bottle import route

# Assuming your *_page view functions are defined above somewhere
urlpatterns = (
    # (path, func, name)
    ('/', home_page, 'home'),
    ('/about', about_page, 'about'),
    ('/contact', contact_page, 'contact'),
)

for path, func, name in urlpatterns:
    route(path, name=name)(func)

Here we run through a list where each item is a triple of URL path, view function and a name for the route. For each we simply call the route method and then invoke it with the function object. Not as flexible as using the decorator on a function (because the @route decorator can take additional keyword arguments) but at least you can have all the routes in one place at the end of the module.

Then again if you have so many routes that you need to keep them in a pretty list you probably aren’t writing the simple application that Bottle was intended for.

(This was tested with Bottle’s 0.8 and 0.9-dev branches.)

Best software ever

When this feature first appeared, one could trigger a stupid bug if one happened to have an application other than Preview.app set as the default application for files with the .pdf extension. If you had Adobe Acrobat set as your default PDF viewer, then hitting the preview button in print dialog boxes would open that preview in Acrobat.

It was a stupid bug, particularly because it was so obvious what was going wrong. The preview was being written to a temporary file with a .pdf extension and then being opened using whatever handler was defined in launch services. But you don’t want that, you want it to be handled by the operating system and not be subject to whether or not you have the patience to wait thirty seconds while Acrobat version 6 merrily paints its splash screen for your pleasure.

Later versions of Mac OS X fixed this so that the print preview is always displayed using Preview.app. This happens even if you set Acrobat as the default application for .pdf files, and it is a good thing it behaves like this. (In fairness, launch times for Acrobat since version 8 are no longer painful.)

I tested what happens if you delete Preview.app on a clean 10.5.8 install: the system falls back to opening QuickTime Player.app for displaying previews (which works fine). And if you delete QuickTime Player.app it falls back to using Safari.app (also works fine). And if you delete Safari.app it falls back to TextEdit.app (which works fine as long as you can render raw PDF data in your head).

It is as if going by the default association between file extension and application was not enough; that the system had a need to use a particular bit of software for these PDF preview files, regardless of what software was chosen as the handler for a different set of PDF files. Who’d have guessed?

All of this is an argument for providing a programmatic way to set the owning application for a file. You might call this a creator code, potentially any file could have one, but no biggie if it was not present because you could fall back to some regular stupid heuristic for determining the owner.

And then in Mac OS X 10.6 you might change the behaviour of the system so that this useful and important information about the file is ignored. Grumble.

Dammit, only just occurred to me to see whether the system would eventually fall back to using Acrobat itself for displaying previews. Grumble.

His first point is that Mail.app gives you a big warning before doing the dirty. I don’t think that excuses the bad behaviour. Warning someone that you behave badly does not excuse that bad behaviour (my ex says this rule applies in more cases than the implementation of mail clients).

His second point is that the user should have a backup; with a good backup she can recover from her mistake when all those old messages disappear. I agree that people should have backups, but I don’t think that argument has any weight because you can imagine that the answer for all bad design decisions is “you should have had a backup”, in which case there are no bad design decisions.

The problem is that Mail.app’s insistence on a POP account being a separate set of folders means a message cannot appear in the Inbox unless it belongs to an account. If you delete a POP account then you have to move the messages to the Inbox of another account just to keep them appearing in the Inbox. This does not make sense.

Suppose you have a large history of messages received via a POP account. Then you delete that account and switch to an IMAP service with a meagre storage limit. If you want to keep those old messages appearing in the Inbox you must move your the historic Inbox messages to the IMAP account’s Inbox even though that will take up space on the server (and there may not be sufficient space on the server for them anyway). The other option is to give up the idea that old messages belong in the Inbox and just move them to local folders “On My Mac”.

If Mail.app provided a local Inbox folder that appeared as part of the unified Inbox then my objections would go away. (There should also be a corresponding local Sent folder.)

IMAP and POP are different in that a POP account’s mailbox is really just a temporary queue for messages that have yet to be retrieved by the client. Mail.app should recognize that difference and stop pretending that the two types of account are equivalent.

Quite pleased that Hawk Wings even knows my blog exists. Hawk Wings is good.

I always liked that Outlook Express and Entourage defaulted to plain text for messages. I particularly liked the fact that OE / Entourage defaulted to bottom-posting when replying to a message – as any fule kno top-posting is a hideous convention foisted on us by miserable office mail systems back when there was still a chance that your e-mail would not be delivered via SMTP (Exchange version 5 and earlier is the primary culprit here).

I still get annoyed that when using Mail.app hitting the tab key in a plain-text e-mail inserts a tab character instead of expanding it to four spaces like Entourage.

Given enough time this post would devolve into arguments about top-posting versus bottom-posting, the width of the one true tab-stop and how HTML e-mail has turned our youths’ minds into mush.

The problem is related to how Mail.app stores messages for an account. For an IMAP account (or a Microsoft Exchange account) Mail.app creates a folder on the local disk and creates mailboxes within that folder corresponding to the mailboxes on the server. The contents of those mailboxes are synchronised with the contents of the mailboxes residing on the server. This makes perfect sense because with IMAP because the messages live on the server – keeping a local copy of those messages is effectively a performance optimisation.

What is weird is that Mail.app uses the same strategy for POP accounts, even though with POP there is only one mailbox on the server and it is effectively a temporary store for messages, which is to say that with a POP account a message does not live on the server but moves from one mailbox to another until it reaches its final resting place, that place being on the client.

The only copy of a message received via POP is on the client. (Having said that, Gmail’s POP support muddies the waters because issuing a DELE command does not actually delete the message from the server, but the principle is the same.)

Now when you go to remove an IMAP account Mail.app deletes all the local mailboxes for that IMAP account. This is not a problem, after all those local mailboxes are simple caches; the only reason the client keeps a copy is as a performance optimisation (as noted above).

Now when you remove a POP account Mail.app deletes all messages sent or received via that account, even though there will be no copy of those messages on the server (especially true for sent messages). This is not useful or intuitive – it is a bad design.

Why is this a bad design? It is a bad design because with an IMAP account you understand that the messages live on the server whereas with a POP account you understand that the messages live on your local hard drive. With an IMAP account you understand that removing the account removes your access to those mailboxes that exist on the server, whereas with a POP account it makes no sense that the act of stopping the retrieval of messages from the account implies that all the messages received via that account and now stored on your hard disk should be removed as well.

Earlier versions of Mail.app had an even more destructive behaviour when removing a POP mailbox. In the version of Mail.app that shipped as part of Mac OS X 10.4, if you removed a POP account then all messages associated with that account were removed without warning. Now imagine the not uncommon sequence of events for someone changing from POP account A to POP account B using earlier versions of Mail.app:

1. User accumulates years of e-mail using POP account A.
2. User adds new POP account B.
3. User removes POP account A.

At step 3 the user lost all her historic e-mail! Apple finally realised that this was no way to win friends and so introduced a confirmation specifically warning that messages would be lost before deleting a POP account (this change was introduced with Mac OS X 10.5).

Another unfortunate behaviour is how Mail.app handles a disabled POP account. Disabling an account stops Mail.app from using that account for sending and receiving but also removes all the associated messages from the Inbox.

It is possible to keep an old POP account enabled so that its messages are still displayed but then turn off the preference to “Include when automatically checking for new messages”. This leaves the old account available when composing a new message as a choice in the From field so one must also change the preference for “Send new messages from” to always use the new POP account in order to avoid inadvertently sending a message using the old From address (or edit the from address in the old account to match that in the new account).

Microsoft Entourage has a better approach to this situation: messages for POP accounts are delivered to the Inbox mail folder “On My Computer”, and they stay there when the POP account is deleted. The flaw in Entourage’s approach is that the local folders appear even when all your e-mail accounts are server-based (i.e. all IMAP and / or Exchange accounts). I think it would be better to create those local folders only when a POP account has been defined because if you have only server-based accounts then it is distracting to have a set of folders called “On My Computer” which have no purpose.

I tell them that a lot of things are the same, that their new computer will still go wrong in frustrating ways and that the Finder is the way it is for historical reasons. The most productive part of the conversation is suggesting bits of software that make your computing career on Macintosh less painful…

Growl! What a fantastic piece of software. Mac OS 9 introduced modeless notifications and it was immediately obvious why it was a good thing. Before then you could bring a Mac server to a halt just by holding down the mouse button for too long, and many Mac applications wanted to get your attention by throwing up a global dialog box to let you know when something had happened. Due to the classic Mac relying on co-operative multi-tasking a modal dialog box could not only interrupt the front-most application but also stop all background applications until the dialog box was dismissed. So Mac OS 9’s mode-less notifications were a great thing.

On Mac OS X there is no built-in API for posting global mode-less notifications. Growl fills that gap. Growl provides an API for Mac applications to post notifications and it presents those notifications in an unobtrusive manner, floating small windows on the top of your desktop that can be easily dismissed or ignored.

The truly great thing about Growl is how it has been adopted by developers. BBEdit uses Growl; Cyberduck uses Growl; pretty much every great Mac application supports Growl because it is such an excellent way to post notifications.

An example of Cyberduck's upload complete Growl notification

And so it seems to me that Mac OS X itself should support a Growl-like API for notifications. Either the operating system should take advantage of Growl when a user has installed it or Apple should just ship Growl as part of the system to provide its functionality as a standard API for any application to post notifications.

I believe there is a need for such an API. Witness the Google Notifier application which does not use Growl for notifications but instead chooses to post floating mode-less notification windows that look an awful lot like Growl’s notifications but which behave in a subtly different manner. Annoying.

When I am invited to appear on Desert Island Discs I will choose Station To Station as the one song I can take with me – it is flipping ten minutes long, and on a desert island I will want a song that takes a long time to understand and doesn’t repeat too often on my walkman.

Station To Station is great because it is at least two songs in one, if not three. The opening section has the discordant stop / start rhythm of a steam train getting up to speed and Bowie’s lyrics are intelligible while being sufficiently dense that I can’t sing along without a dictionary.

And then the song breaks into the second section with a solid disco rhythm interrupted by Bowie expressing the joy and uncertainty of a new love affair before we finally hit the chorus which takes the rest of the song to the end.

It’s not the side-effects of the cocaine, I’m thinking that it must be love.

Oh my gosh it is fantastic.

It is likely that if I can’t take Station To Station to my desert island I will take the prelude from Tristan Und Isolde, also about 10 minutes. Failing that maybe Something Against You by Pixies.

I am one happy prick.

Microsoft’s Mac installers are good, but unnecessarily complicated. And the design of the Mactopia website drives me up the wall – tiny little scrolling <div> blocks and javascript hyperlinks makes it difficult to read the information and difficult to link straight to an update.

syntax: glob
*.pyc
.DS_Store
._*
*.xcodeproj/*.pbxuser
*.xcodeproj/*.perspective*
*.xcodeproj/*.mode*

syntax: regexp
^build/

Ugh to .DS_Store files and gaaaaaah to resource forks wedged into dot-underscore files. Yay! to regular expressions.

But I disagree that the correct cursor to use for a blocking task that cannot be cancelled is the spinning beachball of death. That cursor after all is the cursor automatically provided by the operating system when an application is not responding to input events. As such when I see the beachball I associate it with a stuck application, one that may need to be forcibly quit.

Previous versions of Photoshop showed the watch cursor for actions which took a significant length of time. Showing the watch cursor is friendlier than showing the beachball of death because it indicates that the application is busy, too busy to handle your clicks but everything is hunky dory and the train will arrive at the station.

There is no watch cursor listed in Apple’s documentation on cursors. However the cursor is still present in the system and can be found in the headers for the carbon appearance manager:

kThemeWatchCursor             = 7,    /* Can Animate */

If you have Xcode 3.2.2 installed you can find this in /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/Appearance.h, line 634.

I don’t know enough about Macintosh programming to say whether it is possible to employ this cursor from a Cocoa-based application.

The newly-decorated function can then do things like checking the called arguments before invoking the original un-decorated function.

Django provides decorators for authentication so that you can wrap a view function with a check for client credentials before deciding whether to return the original response or a deny access.

In this manner Django’s authentication decorators encourage orthogonal code: the logic for displaying a view is separated from the logic for deciding whether you should be permitted to see the view’s output. By keeping them separate, it becomes simpler to re-use the authentication logic and apply it to other views.

Suppose you have a view that accepts a Django request object and checks whether the user is signed in:

def administration_page(request):
    if request.user.is_authenticated():
        return HttpResponse("Welcome, dear user.")
    else:
        return HttpResponseRedirect("/signin/")

With a decorator you can simplify and clarify things:

@login_required
def administration_page(request):
    return HttpResponse("Welcome, dear user.")

For older versions of Python (pre 2.4) which don’t understand the @ operator one must explicitly decorate the view function like so:

def administration_page(request):
    return HttpResponse("Welcome, dear administrator.")

administration_page = login_required(administration_page)

Note in the example that the original administration_page function is passed to the decorator. The @ syntax in the first example makes that implicit but the two are equivalent.

The implementation of a decorator is interesting. It takes the function itself as an argument and returns a new function which does the actual checking. Here is how the decorator used above might do its stuff:

def login_required(view_function):
    def decorated_function(request):
        if request.user.is_authenticated():
            return view_function(request)
        else:
            return HttpResponseRedirect("/signin/")

    return decorated_function

The actual implementation of Django’s login_required decorator is considerably less idiotic. Python’s functools module has helpers for writing well-behaved decorators.

Because functions in Python are themselves objects the decorator can accept a function reference, construct a new function that checks for authentication and then return a reference to that new function.

Simples!

(Simples gets less simples when you want to write a decorator that accepts configuration arguments because you then need either another layer of nested function definitions or a class whose instances can be called directly, but I’m going to ignore you for a bit and wow is that Concorde…?)

The virtual private server I installed this on (from John Companies) has a 256 megabyte slice, so I figured a regular Apache + mod_php setup might be in trouble seeing as one of the sites I am running gets several thousand visits a day. Up to now I have always used Apache with mod_php to run Wordpress, and anyway it is fun to learn how unfamiliar software works (Lotus Notes excepted).

On a side note, SysV run-levels and /etc/rcX.d directories are needlessly clever. sysv-rc-conf makes editing those easy.

server {
    listen   80;
    server_name  example.com;

    root   /home/david/example.com;
    index  index.php index.html index.htm;
    error_page   500 502 503 504  /50x.html;

    location / {

    }

    location = /50x.html {
        root   /var/www/nginx-default;
    }

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    location ~ /\.ht {
        deny  all;
    }

    location /b/ {
        if (!-e $request_filename) {
            rewrite ^(.+)$ /b/index.php?q=$1 last;
        }
    }

    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

# Rewrite www.example.com to example.com
server {
    listen 80;
    server_name www.example.com;
    rewrite ^ http://example.com$request_uri?;
}

This configuration is for Wordpress installed under http://example.com/b/ on my server.

My Python answer:

def readlines(filename, endings, chunksize=4096):
    """Returns a generator that splits on lines in a file with the given
    line-ending.
    """
    line = ''
    while True:        
        buf = filename.read(chunksize)
        if not buf:
            yield line
            break

        line = line + buf

        while endings in line:
            idx = line.index(endings) + len(endings)
            yield line[:idx]
            line = line[idx:]

if __name__ == "__main__":
    import sys, os

    FORMFEED = chr(12) # ASCII 12
    basename = os.path.basename(sys.argv[1])
    for num, data in enumerate(readlines(open(sys.argv[1]), endings=FORMFEED)):
        filename = basename + '-' + str(num)
        open(filename, 'wb').write(data)

This is also useful when reading data exported from some old-fashioned Mac application like Filemaker 5 where the line-endings are ASCII 13 not ASCII 10.

This post was inspired by Lotus Notes version 8.5, which is so advanced that to save a message in a file on disk you have to export it as structured text. And if you want to save a whole bunch of messages as individual files you must forget that drag-and-drop was introduced with System 7, that would be too obvious.

Django uses an instance of ModelAdmin (defined in django.contrib.admin.options) to handle the request for a model object add / change view in the admin site. ModelAdmin.add_view and ModelAdmin.change_view are responsible for populating the template context when rendering the add object and change object pages respectively.

Here are the keys common to add and change views:

• title, ‘Add ‘ or ‘Change ‘ + your model class’ _meta.verbose_name
• adminform is an instance of AdminForm
• is_popup, a boolean which is true when _popup is passed as a request parameter
• media is an instance of django.forms.Media
• inline_admin_formsets is a list of InlineAdminFormSet objects
• errors is an instance of AdminErrorList
• root_path is the root_path attribute of the AdminSite object
• app_label is your model class’ _meta.app_label attribute

The way that Django renders a form in the admin view is to iterate over the adminform instance and then iterate over each FieldSet which in turn yield AdminField instances. All I want to do is layout the form fields, ignoring the fieldset groupings which may or may not be defined in the model’s ModelAdmin.fieldset attribute.

This turns out to be easy once you know how. The regular form is an attribute of the adminform object. So if your model has a field named “king_of_pop” you can refer to the form field in your template like so:

{{ adminform.form.king_of_pop.label_tag }}: {{ adminform.form.king_of_pop }}

Or if you want to save your finger tips you can use the with template tag:

{% with adminform.form as f %}
{{ f.king_of_pop.label_tag }}: {{ f.king_of_pop }}
{% endwith %}

Delving through the Django source while I tried to understand all of this I was struck by how Python defines hook functions for iteration and accessing attributes. Half of Python’s attraction is in how easy it is from the program author’s point of view to treat objects as built-in types like lists, dicts, etc.; the other half is the responsibility of the author of a Python module to encourage that same ease of use by implementing the related iteration protocols. It is harder to write a good Python module than it is to write a good Python program that uses a good module.

The next problem was that MacPorts couldn’t update because rsync was blocked by the corporate access policy. Fortunately plain HTTP is permitted outbound. Here’s how to use a local ports tree.

Install MacPorts using the disk image for 10.5.

curl -O http://distfiles.macports.org/MacPorts/MacPorts-1.8.2-10.5-Leopard.dmg
hdiutil attach MacPorts-1.8.2-10.5-Leopard.dmg
sudo installer -pkg /Volumes/MacPorts-1.8.2/MacPorts-1.8.2.pkg -target /
hdiutil detach /Volumes/MacPorts-1.8.2

If the MacPorts install directories are not in your $PATH environment, you can add them to your .profile. This change will not take effect until you start a new terminal session.

cat >> ~/.profile <<EOF
PATH=/opt/local/bin:/opt/local/sbin:${PATH}
MANPATH=/opt/local/share/man:${MANPATH}
EOF

After you have installed MacPorts, create a directory for the ports tree and check it out using Subversion.

sudo mkdir -p /opt/local/var/macports/sources/svn.macports.org/trunk/dports
cd /opt/local/var/macports/sources/svn.macports.org/trunk/dports
sudo svn co http://svn.macports.org/repository/macports/trunk/dports/ .

N.B. In the last line beginning svn co ... the trailing directory separator is significant!

Now tell MacPorts to use the local checkout rather than rsync. Edit /opt/local/etc/macports/sources.conf and add a new line to the end with the path to the ports tree, then comment out the previous line that uses rsync. Here are the last lines from my configuration:

#rsync://rsync.macports.org/release/ports/ [default]
file:///opt/local/var/macports/sources/svn.macports.org/trunk/dports/ [default]

Finally you must create an index for the tree (otherwise you will see messages saying “Warning: No index(es) found!”).

cd /opt/local/var/macports/sources/svn.macports.org/trunk/dports
sudo portindex

Now go do great things.

In general the implementation of filesystem metadata on OS X has been two steps back with respect to the old Mac OS ways. (The one step forward has been the rich metadata provided by the Finder in terms of previews, performance on folders with hundreds of files, and the exposing of file content metadata with the interface for finding files.)

I feel that Mac OS X is shifting away from the concept of files existing on a filesystem without providing a suitable alternative.

Many thanks to Preston Holmes for releasing watchedinstall in the first place.

My goal is to replace the functionality of the fsevents helper application with a dtrace script that can list filesystem changes. A single python script would be simpler to install and use – you wouldn’t need to install it at all, just run it from the directory you downloaded it to. No effing about with setting PATH environment variables, no worry about compiling a C program for whatever architecture.

Hey Esther!

Apple does this for their search results. Netgear does this when searching their knowledge base. Microsoft does this for their Mactopia discussion forums. All three ostensibly good, clean designs fail to consider what the hell a visitor wants in the first place, which is to see the next damn page of results.

The first problem with using AJAX to load results is that the browser view does not change when the new results are loaded. Suppose you have read the first ten results, you scroll to the last result on the page and the first result scrolls up and out of view. Then you click the link for the next page of results. The fancy AJAX loader replaces the existing list of results with the next page’s list of results, but does not move the view, leaving you staring at the last result on the second page when what you want is to see the first result of the second page, so you have to scroll back to the top of the page.

The script to load the results should scroll the view so the first result of the subsequent page is visible – I have yet to see an example of this behaviour.

The second problem is the URL does not change between one page and the next, which means you cannot bookmark any page other than the first. URLs and hyperlinks are the very stuff of the Web, it is mad not to make use of them.

My guess is that the Web designer in each of these cases was so pleased by the effect of updating the visitor’s view of a page without changing the browser location that she figured it was an improvement over the established technique of passing query parameters in a URL.

It is not. Please go back to the old-fashioned use of a query parameter to indicate the offset into a list of results.