Saturday, May 26, 2012

Coda 2 + Diet Coda

Coda 2 + Diet Coda

I don’t link to stuff much any more unless I have something in particular to say about it–and I’m much better at critiquing than complimenting–but it didn’t seem right to break from tradition: previously, previously.

So, in just a few words: Awesome all over again.

Coda might just be my favourite app ever. At this point, I’ve been using it longer than most of my other apps - I’ve switched web browsers, email clients, and programming languages, but I’ve been making web apps with Coda, both at work and for fun, for years now. I don’t even remember what I used before. When you use any one thing for most of the day, five days a week, you get to know it pretty well, including all of its flaws and annoyances. I think the fact that I hold very little animosity towards Coda, the primary thing I use to do my job, is a testament to its design.1

Coda 2 does not feel ground-breakingly different, but it makes all the little things even better in ways that are constantly pleasing me throughout the day. I’m happy to give these guys money for the app again. I feel like I’m not giving them enough.

Diet Coda is fun, even if I don’t currently have a practical use for it. But then, I said the same thing at first about the iPad itself, and now it’s hard to imagine not having it.

Although, after all these years, I still don’t know why the icon is a leaf.


  1. Other tools I use on a daily basis, like Xcode and GitHub for Mac, I have more of a love/hate relationship with, where I admire their design but am continually frustrated with bugs and shortcomings. And then there are the apps that are just broken: Finder, iTunes, Skype, … ↩︎
Wednesday, May 9, 2012

GitHub redesigns its icons using a custom font

GitHub redesigns its icons using a custom font

It’s an interesting and novel technical approach, but I can’t help but ask: why?

The obvious answer, and the one GitHub gives in their blog post, is that with newer higher-resolution screens becoming popular (namely, iPhone and iPad), it’s necessary to have higher-resolution icons that look good on those screens.

But that still doesn’t answer: why a font, as opposed to some other way of accomplishing the same thing?

The approach Apple itself takes is to create two sets of images: a ‘normal’ size and an ’@2x’ Retina size. ‘But wait’, I can just imagine the engineers saying, ‘surely there will be more than just two different sizes in the future! We should be able to support any arbitrary size!’

Count the resolutions, count ‘em!

Any size? Well, actually, probably not, no. Device makers have been trying to support arbitrary-depth resolutions for ages. Have you ever tried to use Windows in something other than its default DPI? It’s a miserable experience. From what I hear, the variety of screen resolutions on Android, along with that OS’s handling of them, has created a similarly messy situation.

Mac OS X has had rudimentary support for arbitrary DPIs since near the beginning, but it was never enabled for or accessible by ordinary users for good reason; and now it looks like Apple is abandoning that approach entirely, not just on iOS (where shipping Retina devices already exist) but on the Mac as well, actually removing support for arbitrary DPIs in favour of having two modes only: ‘normal’ and HiDPI (pixel-doubled, same as Retina).

It’s pretty clear where Apple is going with this: pixel-doubling or nothing. But isn’t it possible that we might someday pixel-double the Retina screens, to get ’@4x’ versions? Well, probably not. Certainly the technology will advance to this point, but the human eye is unlikely to improve. It’s called Retina for a reason: it’s already (if you believe the marketing) at the limits of human perception. There’s no reason to increase the resolution further, because you wouldn’t be able to see it.

So, Apple is limiting themselves to multiples of two, while the rest of the industry fumbles and can’t seem to get anything to work right. We can safely assume that eventually ’@2x’ will become the normal ’@1x’ and we’ll be back only needing one size of icons for everything, and due to the human eye remaining constant, we’re unlikely to double the resolution again.1

Pros and cons

But, for the sake of argument, let’s throw out everything I wrote under the previous sub-heading and posit that for some reason, we really do need arbitrary-resolution images. Or maybe it’s not even that we need them, we just really want them, because engineers love the idea of vector images: vectors have a certain purity of essence, made from a mathematical formula that is capable of scaling to any size, just like your Rails app (cough).

Why not just use SVG?

Maybe browser support for SVG isn’t great; I haven’t looked recently. But I’m sure there are polyfills and fallbacks.

Maybe your designers complain that vector images look mushy at small sizes (a legitimate complaint that any engineer working with icons should be aware of!). I believe that font rendering may have a built-in advantage here, as font designers have had to deal with this issue for quite some time; but I’m also quite sure that you could cook up some not-too-complicated combination of JavaScript and CSS to swap in bitmap images at smaller sizes, while using the equivalent vector once it grows beyond a certain threshold, similar to the approach Apple uses for @2x images on apple.com, giving your designers total control.

In short, maybe it’s just easier to implement as a font. To an engineer, easier means less code, and less code means cleaner, and cleaner means more pure, and is very appealing. I can understand this.

But using fonts has one huge drawback:

You can’t use colours.2

Black and white

Maybe this started as a design decision: that the new icons would be completely monotone because the designers simply preferred it that way. But even if that was so, it’s incredibly limiting to your future design choices to allow your technical system to lock you into forever using monotone icons. As an engineer, you always have to be thinking of how the evolving needs of the product might require the system to behave differently in the future. And this leads me to wonder if the decision to use monotone icons at GitHub was driven by engineering desires rather than design considerations.

And so the only answer to my original question that I can think of would be: They used a font simply because it seemed like an interesting and novel technical approach.

And it makes me sad, because I look at the folder icons, and can’t help but think how flat and lifeless they look, and really the only thing they need is some shading to give them depth, and how they looked so much better just this morning, and how they will never be improved as long as they continue with this technical approach.

And so, while I love playing with fun new technology as much as the next engineer, I think products should be driven by design.


  1. Yes, it can be dangerous to make a prediction like that, but consider how long we were all using 72 DPI screens. The original Macintosh came out in 1984, and the iPhone 4 (the first widely-used web-capable Retina-class device; enough qualifiers for you?) was 2010, so we can conservatively say at least 26 years–in all likelihood, probably longer, depending on how much further back than the Macintosh you think it’s reasonable to look.

  2. Which is to say that, with a font, you can’t use multiple colours within the same icon. You can, of course, take a monotone font-rendered icon and set its colour to, for example, red or blue, but that changes the entire icon; you can’t have different parts of the icon use different colours, or use shading. This could almost be an advantage: being able to change the colour of an icon in CSS instead of having to go back and edit the source image. And yet, how often do you really need to do this? Not enough for it to be worth the trade-offs, I think. ↩︎

Sunday, April 29, 2012

Rentzsch on git subtree

Rentzsch on git subtree

I’ve long since switched from submodules to git subtree for all of my projects, but I’ve never really articulated why: just a general sense from having used submodules that they’re unnecessarily painful to use.

The best thing about git subtree is that, for many use cases, the other developers working with me never even need to know it exists.

One thing I discovered from Rentzsch’s post is that there’s an even better fork of git subtree that improves some of the command-line messiness. I had actually been considering writing some of those changes myself (you know, ‘when I get around to it’). Now it looks like I don’t have to; awesome. I haven’t tried the fork yet, but it sounds like it’s exactly what I need.

Monday, April 16, 2012

Under maintenance, edits tend to make Murphy an optimist.

Under maintenance, edits tend to make Murphy an optimist.

Brendan Eich

Saturday, March 17, 2012

Mike Daisey's Apple factory-themed This American Life episode and related performance in disgrace

Mike Daisey’s Apple factory-themed This American Life episode and related performance in disgrace

I remember listening to Mike Daisey describe tearing down his MacBook into individual components and then putting it together again, ostensibly for fun, and thinking: this is a description of what this guy imagines nerds do in their spare time, told by someone who is not himself a nerd.

It bothered me. It’s not that nerds don’t like to take things apart to see how they work. It was something about the way he said it: he was fetishising it. It didn’t sound as though he was treating the subject matter with respect. I can imagine myself or people I know describing how we take computers apart for fun, and I can even imagine telling the story in a self-depreciating way; but it would sound different, for an important reason: we do this because we enjoy it, and we have very specific reasons that we enjoy it, none of which outsiders are likely to understand. There is a method to our madness. None of that came across in his story. Activities like this are not random or arbitrary as they must seem to Daisey.

It was a tiny thing to pick apart from his story, but it just happened to be the one part of the entire episode that I happen to be somewhat knowledgeable about. I, like most of his listeners, have never been to China and know nothing first-hand about the factories there. So all I had to grasp with which to evaluate his trustworthiness was this one small, seemingly insignificant anecdote that rang false to me.

It was fortunate, I suppose, that this happened in the very beginning of the episode, as it made me sceptical throughout the rest of it. I assumed the encounters he described, and the specific quotes he gave from the people he talked to, were exaggerated or embellished. But it didn’t occur to me that he might be fabricating entire conversations–entire people who never existed.

I also remember thinking that it was surprising, after hearing all of the disclaimers and caveats that the crew of This American Life felt they needed to add after playing the guy’s monologue, that they had decided to air the episode at all, when–even before these new facts came out–they were aware of so many things that did not add up about the story.

Daisey’s response:

It uses a combination of fact, memoir, and dramatic license to tell its story, and I believe it does so with integrity.

In other words, he is one of those people who thinks it’s okay to tell a lie as long as you don’t get caught–that the ends justify the means.

As others have already pointed out, the truly disappointing part about this whole thing is that it also serves to discredit all of the very real and legitimate issues about present-day manufacturing in China.

Monday, February 20, 2012

Sorry you got Watson'd, bro

I’m showing my age at this point, but Apple has a history of integrating features into the OS that were once third-party utilities. Perhaps the most notable examples of this are Watson, which became Sherlock, and Konfabulator, which became Dashboard.1 And when I say ‘became’, I mean completely new, clean-room implementations of these features, with no knowledge, involvement, or compensation on the part of the original developers. I think it’s that last part–compensation–that really gets people, because there’s this persistent notion that ideas are currency.

On the other hand, there are also examples of Apple hiring or acquiring third-party developers to similar ends: a particularly relevant example would seem to be the hiring of this guy, who wrote a notification system for jailbroken iPhones before Apple’s own version existed, and then ended up (presumably) creating the official version at Apple’s invitation. There’s also the story of how Steve Jobs tried to acquire Dropbox when creating iCloud, even though it turned out that Apple’s plans for iCloud were very different from what Dropbox was doing.

So I can see why it would be frustrating for the Growl team to see Apple copy their product2, after it has been almost a de facto first-party system component for so many years, and after they’ve reportedly3 implored Apple for years to integrate Growl into the OS proper. But Apple never seemed to care how many people used Growl, or think it was a necessary UI feature, until after it showed up in iOS and they started the ‘back to Mac’ strategy. So I can see how a measure of flippancy might be in order. Yet still, I’m a bit surprised by the ‘full steam ahead’ tone in Chris Forsythe’s response to Apple’s announcement of Notification Center; it seems obvious to most people not invested in the situation that Growl is over.

Despite the fact that, only just recently, I spent many hours learning Mac Cocoa in order to write Launchpad Editor4, it’s my hope that Apple improves Launchpad enough to make my app unnecessary. Perhaps I would feel differently if I actually made any income from Launchpad Editor, but the way I see it, there are always new and more interesting things to work on.

Don’t let the man

There was some further drama about a rumour that Notification Center would only be available to apps on the App Store. I thought I remembered seeing this in Forsythe’s post, but either the post has been edited to remove this assertion, or I remembered incorrectly. Regardless, the rumour turned out to be wrong, as AnandTech explains:

There’s been a bit of confusion about the new notifications API (NSUserNotification) and whether or not it’s available to applications not in the Mac App Store. Local notifications using the new API are available to third party apps regardless of their distribution model (they don’t need to be in the Mac App Store). Push notifications on the other hand currently require that the application is distributed only through the Mac App Store.

This makes perfect sense to me, as a developer: the API is part of the OS, so why not let any developer use it? It doesn’t cost Apple anything to do so; it would actually be more work to limit use of the API to only certain types of apps.

But Push Notifications are something different. It’s not just a hook into the OS; all Push Notifications go through Apple servers before reaching their destination.5 These servers have a monetary cost associated with them for Apple to maintain. Now, Apple makes money on the App Store, so it’s reasonable that they have some left over to reinvest in the servers that make this work. Even if an app is given away for free or doesn’t make much profit, Apple still at least has the $100/year for the developer program. Over the entire App Store, it probably balances out.

But why should Apple provide this service, which makes apps more appealing to users, for free to developers who aren’t contributing anything at all? Keep in mind that these developers don’t have to go through app review, and don’t have the technical restrictions inherent in App Store apps either; it would be entirely feasible for such developers to make their own Push Notifications service that doesn’t go through Apple, and run a background daemon on the Mac which listens for messages and forwards them to Notification Center. (It’s up to the user to decide whether they like the idea of yet another background daemon.)

The same arguments could be made about iCloud, for that matter. As a user, I’m very sensitive about what’s happening to my ability to run any software I want on my Mac. But for the moment, the outrage about certain features only being available to App Store apps seems overblown to me.

Hey, listen! Hey! LISTEN!

Personally, I find there are very few things I actually need or want notifications for. I’ve developed a habit of saying ‘no’ at first to all notification dialogs on iOS, and then going back and turning them back on later if it turns out I need them–not least due to the increasing prevalence of their use for spam. And on the Mac, I’d have uninstalled Growl completely, if not for the fact that so many apps bundle Growl and continue to use it to display notifications internally even if it’s not installed, thus making installing Growl the only way for me to access UI controls for actually turning the notifications off.6

But I find I’m quite content with the fact that, on the Mac, Mail doesn’t pop up a summary of the email I just received, and iChat doesn’t constantly overlay last five messages from my friend on top of whatever else I was in the middle of. A single bounce of the dock icon and a number badge is enough to let me know that there’s something waiting for my attention. I can go and look at it when I’m good and ready. If I want to see new iChat messages as they come in, I can leave the window open on the side of the screen; or, if I want to focus on something else, I can hide that window. There’s no need for me to be constantly pulled away from what I’m doing for… well, just about anything.

The only apps I really find Growl useful for are the ones that lack any UI for telling me certain types of things: for which Growl is the only way I would know about certain information, because the developer did not build any alternative. But that seems more like a failing of the app developer, not a benefit of Growl. I think Growl (and similar systems) were always intended to be a secondary source of information presentation for an app, never the primary.

On iOS, the situation is a little different: I can’t keep my instant messages in a window off to the side, because there are no windows on iOS. And I have no complaints about that. But it does mean I’m a little more tolerant of notifications; just only in very limited cases.


  1. It’s somewhat amusing that of these two examples, Sherlock no longer really exists in any form resembling the original Watson–it sort of morphed into Spotlight, while losing most of its recognisable features–and Dashboard has long been on its way out. I somewhat suspect the only reason Dashboard still exists in current versions of the OS is because Apple printed a dedicated key for it on the keyboard for so long (newer keyboards omit this key in favour of one for Launchpad). The fact that there is no Dashboard Widgets category on the App Store seems enough to seal its doom. ↩︎

  2. Perhaps significantly, Growl was given away free of charge for most of its life, and only recently made a $1.99 purchase at the App Store. It remains open-source, so anyone who wants to can avoid paying for it by downloading the source code and compiling it with Xcode. ↩︎

  3. I should have a citation for this, but I don’t. So it might be rumours, or my faulty memory, or I might have just made it up. Take that for what you will. ↩︎

  4. Admittedly not even comparable to how many hours have been collectively put into Growl over the years. ↩︎

  5. The original reason for this was to save battery life on iOS devices, by only connecting to a single central notifications server rather than keeping many connections open at all times. It’s debatable whether or not that’s necessary on Macs, but it may well make more sense in terms of Apple’s development efforts to just reuse the existing service, rather than make something new just for Mac that works only slightly differently. ↩︎

  6. In the past, it was also common for apps to silently reinstall Growl on the system if it wasn’t present. I think this isn’t as common now, but the problem I described is almost worse: careless developers continuing to use their internal bundled version of Growl, while not presenting any UI for disabling it. ↩︎

Tuesday, January 10, 2012

Some rambling about eBooks, newspapers and the future

Marco Arment writes that Barnes & Noble will be offering discounts on the Nook to customers who commit to certain periodical subscriptions:

  • $119.88 for a year of People magazine gets a $50 discount off the $250 Tablet.
  • $239.88 for a year of The New York Times gets a $100 discount off the $100 Simple Touch or $200 Color.

To me, this mainly speaks to how disconnected from reality the pricing is of electronic versions of periodicals.1 I’m still waiting these publishers to wake up and listen to what Steve Jobs told them (according to Isaacson) about the price point for an electronic newspaper: $5/month. I like the New York Times and I would be happy to subscribe for that much, but no more. Instead, I’ll make do with what little the NYT iPad app doles out for free, or get my news elsewhere.

Subjectively, I feel like this discount scheme also makes the newspaper appear valuable while making the Nook look cheap. Doesn’t seem great for the latter’s brand image. I guess B&N is getting desperate?

It’s a shame. I like the Nook over the Kindle because it uses ePub, which seems at least a little more future-proof than Amazon’s pointlessly proprietary format2.

Sometimes there may be reasons a company wants to make a proprietary format instead of using an existing standard; mainly when the standard doesn’t do what the company’s product needs to do. As far as I’m aware, the Kindle formats do nothing that isn’t possible in ePub. Obviously, tech companies also love proprietary formats for the evil reason of customer lock-in. Even Steve Jobs was guilty of using customer lock-in as a direct justification (again, according to Isaacson).

Me, I mainly just want to be able to read my books a few years from now.

As a programmer, I can’t help but look at formats through the lens of how easy would this be to reverse-engineer if everyone else on the planet suddenly stopped supporting it and all existing software ceased to function? (Which, it turns out, isn’t really that far-fetched). ePub readers are relatively straightforward to implement, since ePub is mainly just based on HTML and CSS, and we can be reasonably assured that that will be around decades from now–although, perhaps not renderable in perfect, original fidelity.

On the other hand, almost all eBooks, in any format, are wrapped in some kind of DRM these days, which means in practice I mostly don’t end up buying them.3 I have no problem buying, for example, games from Steam, so I guess my expectations differ depending on the medium. But still, for lack of any really appealing options, I’m inclined to root for the companies that are doing the thing closest to what I want. But I also think we’ll somehow fare better if we are able to keep some good competition going, and don’t let any one company ‘win’. My hope is that this will eventually force the different vendors to sell stuff that’s compatible with each other, like what happened with music.


  1. Taking a page from our friends at the cable companies, The Boston Globe (a wholly-owned New York Times subsidiary) offers subscription prices where they charge you more for the web-only version, compared to the bundle that includes the same web access and a dead tree version. It’s like they live in some kind of alternative reality where logic doesn’t apply. ↩︎

  2. Apple’s iBooks also uses ePub, although the iBooks DRM is not compatible with the Nook DRM. If there was no DRM, it would be possible to buy an eBook from Barnes & Noble and read it in iBooks, or buy an eBook from Apple and read on the Nook. And wouldn’t that be interesting? ↩︎

  3. Tools exist to remove DRM from Nook ePubs and Kindle eBooks, but not from iBooks ePubs. Such tools are illegal under the DMCA, which is unfortunate. ↩︎

Monday, January 2, 2012

Things I listened to in 2011

I like music. Do you like music?

This is mostly (but not all) recent music, but what it all has in common is that I listened to and enjoyed it in 2011.

Here’s a list of the songs featured:

  1. Basement Jaxx - Raindrops (from Basement Jaxx vs Metropole Orkest; iTunes; Amazon)
  2. Bonobo - Animals (from Black Sands; iTunes; Amazon)
  3. Red Hot Chili Peppers - Ethiopia (from I’m With You; iTunes; Amazon)
  4. Electric President - Feathers (from The Violent Blue; iTunes; Amazon)
  5. Owl City - The Yacht Club (from All Things Bright and Beautiful; iTunes; Amazon)
  6. The National - Exile Vilify (from the game Portal 2; available as a single; iTunes; Amazon)
  7. Ico - You Were There (from the game Ico; soundtrack exists if you can find it)
  8. Way Out West - Survival (from We Love Machine; iTunes; Amazon)
  9. Big Giant Circles feat. Jeff Ball - Thunderstruck (from 25YEARLEGEND, a remix album based on the game series The Legend of Zelda; available for free)
  10. Radiohead - Separator (from The King of Limbs; iTunes; Amazon)

The final background picture in #5 is from here.

I arbitrarily limited myself to 10 songs; otherwise I might have never finished it. Here were some runners-up, which almost made the cut:

  • Caia - Remembrance (from The Magic Dragon;iTunes;Amazon)
  • Moby - After (from Destroyed;iTunes;Amazon)
  • Basement Jaxx - Samba Magic (from Atlantic Jaxx Recordings;Amazon)
  • Orbital - Don’t Stop Me (single;iTunes;Amazon)
  • Yasunori Mitsuda - The Beginning and the End (from Myth: The Xenogears Orchestral Album;Amazon)
  • GaMeBoX - Subsonic Sparkle (from Sonic the Hedgehog: The Sound of Speed, another remix album;available for free)

It was fun to make. I might do it again next year.

Tuesday, December 20, 2011

Launchpad Editor 1.0

Launchpad Editor 1.0

I created a Mac app - my first1.

I’ve been looking for an application launcher for a long time. When you have a lot of apps, like I do, the Dock just doesn’t cut it. Not that I didn’t try: I made various attempts to have a categorised, hierarchical list of applications in the Dock, which tended to get broken or more annoying in different ways with each major release of Mac OS X.

I’ve tried various third-party utilities, but they were all too complicated and customisable. Or, they expected me to type the name to launch it! There’s a reason I use a Mac instead of a UNIX terminal2.

What I was really looking for was something like the Classic Mac OS Launcher:

System 7 launcher screen shot

Simple. To the point.

So when I first heard about Launchpad, to come as part of Lion, it seemed to be just what I was looking for.

And indeed, it was–after I took the time to actually organise my apps. Which took a really long time. Click, drag, wait…wait….wait…drop. Repeat. Sigh.

But it was worth it. All my apps, easily accessible and meticulously organised. Yes, I tend to be a little more obsessive about this than most people, but it made me happy.

And then, one day, Launchpad randomly corrupted its database, resetting all of my apps into alphabetical order and losing all of my folder groups.3 I would have had to do it all over again–and maybe not for the last time, if Launchpad didn’t have its bugs worked out yet.

The idea

I was looking for an excuse to make a Mac app anyway.

I’ve always wanted to make native apps. Even having grown up in the ‘boom’, and being a self-taught web developer myself, I would tell people that what I really wanted to do was make ‘real’ software someday. And they would laugh. ‘Web apps are the future, silly kid!’ But while making web apps has been fun and useful, even the best web UIs have always felt to me like they lack the stability and consistency of a native app. So I’m glad to see the tide turn somewhat back towards native apps in recent years, which affords me an excuse to pursue making them. Anyway.

Once I found out that the Launchpad data is just a simple SQLite3 database, I decided to give a try at making a simple app to manipulate it, such that I could get the job done faster, and with less annoyance, than using Launchpad itself. All it would really need to be is a list view that synchronises to a database, so I thought it would be educational but not too daunting.

Building it

Reading the database was simple: I just used Gus Mueller’s excellent FMDB. I had to figure out the database schema, since it’s not documented anywhere (with a little help - thanks, Andreas!), but it was surprisingly straightfoward. Curiously, it doesn’t look like a database that was generated using Core Data (which was why I didn’t attempt to use Core Data for this either), which makes me wonder Apple is using: straight SQLite C calls? Shudder.

The main challenge was in learning how to do things in AppKit, after I had only just recently learned to use UIKit for making an iPhone app. But they both use similar patterns, the major example being the data source/delegate pattern, so I was pleased to find that I could use many of the concepts I already knew. And when I was having trouble finding documentation on certain subjects, the people in #macdev on Freenode were very helpful, for which I’m very grateful.

One thing I didn’t have to worry about (much) was… memory management! After having to learn retain/release the hard way for my last project, automatic reference counting was a breath of fresh air. It would be hard to overstate how pleased this made me: it allowed me to focus on my application logic, rather than getting constantly distracted by what seems like bookkeeping.

And now it’s done!4 Did I mention you can get it here? Since I couldn’t put it in the App Store (for obvious reasons), I made it open-source on GitHub.

Future

I expect that Apple will improve Launchpad in the future, hopefully by 10.8, making my app unnecessary. It’s typical of Apple to release a minimal-but-polished first version, then add more features later.

Or not. Maybe Launchpad is only for ‘halo effect’ former Windows users brought over to the Mac via their iPhones, who aren’t going to have many apps anyway, and thus maybe Apple doesn’t think anything needs to change. In that case, perhaps I’ll eventually attempt to reinvent the original Launcher myself. (Unless someone else does it first.)

In the meantime, I’m looking forward to making more apps.


  1. That reminds me: I never wrote a blog post about my first iPhone app. Perhaps I’ll come back to it. ↩︎

  2. Not that there’s anything wrong with that. I know a bunch of smart people who use Terminal as much as possible. It’s just a different way of thinking. ↩︎

  3. I think this happened on or around the time of the 10.7.2 update. ↩︎

  4. Well, shipped. Software is never really done, only acceptable enough to release. I still have more ideas than time, so if anyone wants to chip in, here are some places to start… ↩︎

Saturday, December 17, 2011

From around the age of six, I had the habit of sketching from life. I became an artist, and from fifty on began producing works that won some reputation, but nothing I did before the age of seventy was worthy of attention. At seventy-three, I began to grasp the structures of birds and beasts, insects and fish, and of the way plants grow. If I go on trying, I will surely understand them still better by the time I am eighty-six, so that by ninety I will have penetrated to their essential nature. At one hundred, I may well have a positively divine understanding of them, while at one hundred and thirty, forty, or more I will have reached the stage where every dot and every stroke I paint will be alive. May Heaven, that grants long life, give me the chance to prove that this is no lie.

From around the age of six, I had the habit of sketching from life. I became an artist, and from fifty on began producing works that won some reputation, but nothing I did before the age of seventy was worthy of attention. At seventy-three, I began to grasp the structures of birds and beasts, insects and fish, and of the way plants grow. If I go on trying, I will surely understand them still better by the time I am eighty-six, so that by ninety I will have penetrated to their essential nature. At one hundred, I may well have a positively divine understanding of them, while at one hundred and thirty, forty, or more I will have reached the stage where every dot and every stroke I paint will be alive. May Heaven, that grants long life, give me the chance to prove that this is no lie.

Katsushika Hokusai, Japanese painter (1760-1849)

9 of 47