I enjoyed reading his post, because I like rules of thumb for simple design, and one of my favorites is “why not just use files?” - there are often reasons to do something else, but the filesystem is faster, more reliable, and more open than anything you’re likely to come up with on the first try. So you’d better be sure you’re not just poorly reimplementing it.

Buzz Andersen has a thorough response, centering on the fact that VoodooPad is a very useful app. Certainly I agree - I use it all the time, and its hyperlinking sets it apart from other notes apps (and the filesystem). So yes, VoodooPad is a Good Idea.

But is VoodooPad really an “Everything Bucket”? I’m not sold - you can use it to store PDFs and images and other files, but it really focuses on pages, and those files are just attachments to your pages. I see it as a notes app. I think if your problem is keeping notes - with images if necessary, linking between them, and searching those notes, then VoodooPad is clearly better than the filesystem. But you don’t have to put everything else in there too.

I agree with Alex that I don’t want one program to keep everything in a proprietary database. I like apps that keep my files as files. (like EagleFiler.) But I do want layers on top of the filesystem - you wouldn’t want to use just files for email, for example.

The only solution that’s always bad is the solution to someone else’s problem.

The most recent version of iCal decided that events are write-once-read-many as well. You now have to use cmd-E to get into edit mode, while cmd-I just gives you a small display mode.

I’m mostly OK with that, although I find I edit events about as often as I look at their info windows - after editing I usually just deal with alarms, not the events themselves. The casual glance at the time and title is always enough - I think either you’re looking at the time and title or you’re editing. I don’t see the appeal in the new ‘info-only’ mode (if it’s actually new - it seems new.)

However, the change does highlight the jumble of editable text fields and text-like fields in the edit window:

The “Add Attendees” link and the “None” placeholder for url act the same - you click on them, and enter text. One’s a link and one’s mute gray text. Why? For my part, I think the gray text is too understated, and the link is too garish.

There are other differences: you can tab to the “url” field, but you can’t tab to “attendees”… until you add one, then you can. Once you click on either of them, the url field pops up a plain white raised NSTextField, but the attendees field is sunken and translucent, apparently an NSTokenField?

Both of the blue links could also be buttons. I’m still not completely sold on replacing buttons with links, but I can understand the trend. I think a small plus-sign button would be fine for “Add File”, though, and “Attendees” ought to be a text field. Why force the user to use the mouse when adding data to an event?

All in all, I think the “Add Attendees” link/field is pretty strange. I’m curious if I missing a precedent somewhere.

Because I always have more than one project going, I don’t actually wait much. I just switch workspaces and try to make progress on the next thing. If I can’t make progress on anything immediate, I’ll end up checking email or looking up something for a side project.

This kind of multitasking is inefficient, but inevitable when I might have to wait for 20 minutes or more for a compute job or a compile to finish.

The problem with this approach is that the things I’m waiting for often finish while I’m off doing something else, and if I get too involved, the low-priority research or emails will eat up my day while the high-priority work sits waiting for me.

I’ve attacked this problem in the past when using OS X with growl, but I can’t call growlnotify from remote systems. However, I just found dzen for X Windows, a lightweight notification display utility that compiles easily on every system I’ve tried, and works remotely with ssh X forwarding.

I wrote a simple script called go, which just executes its arguments and runs dzen when it’s done. Now I type (for example) go make and I can switch over to something else, confident that I’ll see a big popup window letting me know when I can get back to working on my highest priority project.

Here’s basically the entire go script:

#!/bin/ksh
echo $@
$@
echo $@ completed on `hostname` \
 | dzen2 -p -h 64 -bg darkblue 

It’s simple but it’s working great for me. I’ve tried some improvements like randomizing window placement to avoid overlapping notifications, but the simple version above really does all I need.

Finally, a couple of details. zsh always seems to want to spell-check ‘go’, so I really named it ‘~/bin/executeAndNotify.sh’ and just aliased ‘go’ to that. Also, I’ve found it can mess with shell quoting as is, so sometimes I have to do 'somecommand ; go echo done'. If someone has a tip on getting the quoting right in the script, I’d love to hear it. The problem crops up when you try something like ‘go make CC=”cc -g”‘ - the quotes don’t make it through.

This bothered me, so I downloaded Pukka and gave it a try. I was curious to see if it was indeed trivial.

While it definitely doesn’t seem like the most feature-rich program up front, there’s a lot of stuff in there - it works with more than one bookmarking site, it integrates with RSS readers, uses the OS X keychain, includes Bonjour discovery of nearby users, and has AppleScript support.

Further, it shows attention to detail. Although I may not agree with some of Justin’s UI design choices, it’s clear that he spent time thinking about bookmarking workflow. I know in some of my projects, just pondering design choices takes hours - drawing mockups, and trying things out.

End-user app development isn’t just programming, and programming isn’t just typing.

I think it’s fair to say that that although you might be able to retype the code by hand in a few hours, Pukka represents a good chunk of serious work. I’m sure the mac developers in the audience will agree - Applescript support alone is almost guaranteed to be more than two hours of work.

I’m glad that there’s a market for small apps and small developers, and I hope downwards price pressure from large subsidized or bundled apps doesn’t kill that off.

It’s a solid update, including welcome image-editor integration and more. I thought I’d point out my favorite feature in the release notes:

“You can now edit pages and sort the results in the search window (woo!).”

I like this because it matches a kind of manual refactoring habit I picked up with Project Builder / XCode’s excellent “Find in Project…” window - I search for a keyword that marks places I need to look at and edit the files right in the search window. (Note: ‘occur-mode’ and kin are a powerful way to do the same in Emacs…)

It’s a powerful habit if you plan for it, by using comments in code to keep track of what you’ve touched when making a lot of cross-cutting changes, like # @addsearch Then when you think you’re done with a change, you can run a quick search to see if you forgot to fix anything.

Sometimes in VoodooPad notes, I’ll write in placeholders like that comment when I don’t have a bit of information yet, and now I can follow my trails the same way I do in code.

Thanks, Gus!

The latest version of PyObjC is 2.0, it’s installed by default on OS X 10.5, and XCode now includes templates for starting a PyObjC project. There’s even code autocomplete in XCode for PyObjC and IB integration, so aside from some smart-indenting issues, writing PyObjC in XCode is almost as natural as writing in ObjC.

I thought I’d post a few nice shortcuts and tips here.

You can use tuples for NSRect/Range/Point, for instance, this -

r = NSInsetRect(((0, 0) ,
                 (100, 100)), 
                10, 10)

creates this NSRect -

NSRect origin=<NSPoint x=10.0 
                       y=10.0> 
       size=<NSSize width=80.0 
                   height=80.0>>

Passing python arrays as NSArray instances (and dictionaries as NSDictionaries) works great, but sometimes you need to pass a C array. The Python ‘array’ module handles that nicely:

import array
g = NSGradient.alloc().
   initWithColors_locations_colorSpace_(
    [NSColor.whiteColor(), 
     NSColor.blackColor()], <br/>
    array.array('f', [0.0, 1.0]), 
    NSColorSpace.deviceRGBColorSpace())

ObjC selectors are just python strings in PyObjC.

defNC.addObserver_selector_name_object_(self,
  'windowDidResize:',
  NSWindowDidResizeNotification,
  self)
# or
self.performSelectorOnMainThread_withObject_waitUntilDone_('doIt:', None, False)
# or 
if o.respondsToSelector_("fun:"): return o.fun_(a)

Finally, something that comes in handy when working with KVC, the ‘_’ method now defined on NSObjects in PyObjC:

o = <Some ObjC object>
print o._.myKey
o._.myKey = 44
# is equivalent to:
print o.valueForKey_('myKey')
o.setValue_forKey_(44, 'myKey')

That last example is straight from the NEWS page, where lots of other useful info can be found.

I’ve collected some links to public info about the job.

The Google channel has a promotional video from one engineer about the role - he tells a quick story about being on call to monitor and address problems with Google talk.

A set of slides from a talk by James Youngman at the UK Unix & Open Systems User’s Group gives a good description of the general task, and dives deeper into two specific examples - powering down failed disks, and protecting data with checksums, exploring how straightforward ideas can explode at scale. (These slides also have potentially the best proprietary-information disclaimer I’ve ever seen: “This has been written entirely in ASCII. No EBCDIC or animal fat.”)

Here is another set of slides with a quick overview, from a ‘lightning talk’.

A sampling of what Google SRE engineers put in their public resumes about their job includes quite a span - from troubleshooting mission critical services to writing automation software (in Python).

And finally, an interesting post from 2006 about the theory behind Google’s hiring strategy, summarized as “only hire candidates who are above the mean of your current employees”.

His script generates a list of numbers and included a Numbers template to paste them into. Since I don’t have Numbers, I’ve modified his script to write a file that can be read by gnuplot, and wrote a basic gnuplot script to output an SVG file version of the stats.

While I was at it, I changed it so it no longer counts “@someone” separately from “@someone:”.

Both scripts are right here – gnuplot_twitterstats.tgz

It uses gnuplot 4.2, which you can get on OS X with macports using port install gnuplot +no_x11'. (Or it’s a pretty easy build on its own, see the gnuplot download page )

Here are my stats: Click here for a full-screen version.

I’ve used both kgtd and iGTD, and played around with a few others. I came closest to sticking with a system using kgtd, but switched to iGTD because manually syncing kgtd got old.

All the extra stuff in iGTD was appealing, but I left tasks in the inbox for weeks, and never reviewed much of my vast forest of projects. I eventually fell back into tending short lists in Stickies, with titles like “NOW:” and “BY TUESDAY!:”.

When I moved those Stickies lists into TaskPaper, all I had to do was copy and paste - it uses the same format I do when I get lazy, and that has to be a good sign. I haven’t found a reason to jot a note somewhere else yet.

Moving tasks from iGTD was more sobering. Half those “next actions” had been done for weeks, and the other half were clearly scheduled for next Neversday. As Merlin Mann pointed out, switching apps is a good excuse for a real review.

TaskPaper adds automatic formatting, tabs, search, and a bit of hyperlinking to plain text. Tasks are lines that start with a dash, and can be tagged by starting any word with an at-sign. Clicking a tag starts a search for that tag. I use them in a couple of ways - as contexts, and for scheduling. They can really be anything that makes sense as a visible search keyword.

I have been keeping a few tabs open - one to edit tasks, and a couple others with live searches to look at what’s on my plate. When I want to schedule something, I’ll tag it as @now or @tomorrow - I have those two as open tabs, and as I work I keep the @now tab open. Other tabs come and go to look at contexts, like @email or @errand.

I like that the tags can be part of the sentence, so I don’t have to tab through a bunch of controls to set tags - I just write something like ‘@email Bob @home’… easy.

I also set up an inbox project (by typing “Inbox:”, naturally) to collect notes quickly, and that’s worked pretty well so far.

As with any 1.0, there’s some room for improvement. It’s not very scriptable, but it is plain text, so it could be worked around. Quicksilver integration was important with both kGTD and iGTD, and I’m not sure yet if I’ll really miss that here. It can clean up tasks marked as done into an “Archive” project, but doesn’t yet note when they were finished, if that kind of thing matters to you. Finally, I’m not sure what the best way to sync with other devices would be, but there is a web interface in development - maybe that would be a good iPhone option.

TaskPaper is a solid, clear, and nicely minimalist app. Over the week I’ve been using it, it has made keeping to-dos in one place too easy to avoid, and added just enough functionality to sort through them without being distracting.

Note: When I downloaded the 1.0 release, I found a conflict with TextExtras and wrote a bug report. In reply, Jesse sent me a complimentary license. Nice guy. I was going to write about it anyway, but I thought I should mention that I got it for free, as a surprise.

I give paper sections and important emails a while to sit after I write them, and they always benefit from another look with fresh eyes. I think that doing this with code is worth thinking about.

Once you get a piece of code to the point where you believe it works - it’s passing its tests - go back over it and edit it. That is, go back and edit it for clarity, flow, and style. Just as if it were an essay.

This is particularly important for tests. If a test fails, it should tell a clear story that explains exactly what failed, and what it was expecting.

Things to consider editing out are vague variable or function names, and non-idiomatic shortcuts. Control flow can get tangled when working out a solution. Make it obvious. One-liners often don’t tell the full story. When you come back to a piece of code, you know the chase. It’s the first loose thread of a bug, a failed test, or an occurrence of a symbol you need to refactor. What you need is the story around it, and solid code will fill that in.

You can learn this by sharing your code or by waiting a while and reading it over again. It’s easier said than done - I don’t always do it, but I do know: an editing pass can do you good.

Something to think about: would a professional code editor help or hurt in the long run?