March 2011

One reason I fell in love with computers — a long time ago, before the web, before the Macintosh — was that there were never any torn bits of paper to deal with.

No ink on my hands, no charcoal on my wrist. No tape measures to wind up. No eraser crumbs.

If you want two things to align perfectly, it’s easy. No need to eyeball it or get out a ruler.

I don’t mind real-world UI, textures, trompe-l’œil — as long as it doesn’t trigger the part of me that feels like it has to reach in and fix things.

I don’t want to have to go wash my hands, blow off the eraser crumbs, wind up the tape measure, tear off the bits of paper.

If this rumored new UI for iCal is real and not just a mockup by a misanthropic Photoshop sadist, then I’m going to be distracted forever by the bits of torn paper under the toolbar.

I say “forever” not for hyperbole’s sake but because I already have an example: the trash can. When there’s something in there, it’s not right, and I have to empty it right away.

Deleting a file or folder is a two-step process:

1. Move it to the trash can.

2. Empty the trash can.

(My fingers know the keystrokes, and I’ve turned off warnings, so this is pretty quick.)

The trash can has been around for decades and I’ve always treated it this way. I no longer torture myself by trying to change how I think about it — this particular battle is okay to lose. (Also: rm is my good friend.)

I’m well-adjusted

I don’t say all of the above because I think I have OCD or extraordinary psychological issues. I enjoy an interesting and reliable set of flaws like everybody else. But I’m not a special case.

It’s probably a minority of people who would be bugged by the torn bits of paper, but it’s probably not a super-small minority. And I’d bet that geeks — early adopters, software developers, designers, tech support folks — are more-prone than the general population to torn-paper derangement syndrome.

The thing is, geeks are the pushers. They’re the ones who get other people to buy Macs, who get people to upgrade their system, who get people to try apps.

It’s totally correct to design for people-in-general — but please don’t freak-out the geeks.

SCD

Cathy Shive</a> puts this way better than I do. She tweets:

Clearly, skeuomorphic compulsive disorder should be recognized as a medical condition.

staticDimension “is a static HTML blogging and publishing platform, written in PHP.” By @MalphasWats. Sounds cool.

I also heard on the latest Build and Analyze that Marco Arment might start one. I love the name: Second Crack.

Seth Godin: “It’s a cultural instinct to wait to get picked.”

That is what the web changed. It used to be pretty hard to pick yourself — you had to find a publisher of some kind, someone with power, to agree that your stuff will sell.

Now it’s easy. Do the thing.

Apple likes to talk about the intersection of liberal arts and technology — something I’ve always taken for granted. I didn’t think about it like that when I was growing up. It was just the water I swam in.

My Mom writes about her hospital stay, where a supervisor there had been a student of my Mom’s mom, my grandmother. Back in the ’70s, my grandmother, then in her 40s, went back to college and got a degree and then a master’s degree, and then went on to become a librarian at a small rural school in South Jersey.

She was and is a voracious reader. So were her parents. So’s my Mom. So am I. Words, books, stories — I remember those better than anything, and I remember the world around me best when I’m reading something good.

(I remember when I read the final pages of A Farewell to Arms — I was sneaking a read, as I often did, while my history teacher was lecturing. I had to re-read the final paragraphs a few times. I remember it was an unseasonably cool and windy summer in Newfield when I first read A Connecticut Yankee in King Arthur’s Court. I remember the bumpiness and torn seats of my middle-school bus because I remember reading 1984 on the way home. I remember thinking the bus would have fit into the book quite neatly. Doubleplusungood.)

My grandmom went on to introduce computers at her school. This was very early on. We had one at home, but hardly anyone else had one — they were still considered toys. (Macs didn’t even exist yet.) The question everybody always asked: “Cool — but is it actually useful for anything?” It was a hard question to answer.

My grandmom, on the other hand, knew the future when she saw it. I don’t know how she did it — it wasn’t a rich district — but she got the computers into the school, into the library (where they belong! Not in the math class). Way back when.

When I look at my upbringing, the nature and nurture, I’m completely unsurprised that I’ve written a newsreader, a weblog editor, and a publishing app. I just do what Grandmom always did, and what so many people do these days: I put words and technology in the same room.

The web itself is the beginning of the realization of the dreams of people like my Grandmom. And, without it, I don’t know what I would have done. (Mom has told me I would have been a criminal mastermind. Which could have been fun, I admit.)

(And I do it because, well, I need more to read. Which means you need to write more.)

One indicator — not the only one — that you’re doing threading right: you should be able to look at any method in your code and know immediately whether it’s main-thread only, single-thread-only, or multiple-threads. (Let’s set “immediately” to 10 seconds just to be reasonable.)

If you find yourself doing a lot of defensive stuff — like “Oh, this might get called by a background thread, maybe, possibly, not sure, so let’s check and do a performSelectorOnMainThread just in case” — then you still have issues.

The same goes for data structures: you should absolutely know which are main-thread-only, single-thread-only, and which need locking. And don’t rely on atomic properties to take care of threading issues — if you’re doing it that way, you’re working at the wrong level.

Some people are mean because they’re low-class, unimaginative sadists. Maybe that describes most mean people — but set them aside, because we don’t listen to them.

There’s another type, though, that is mean because they care deeply about something. They’re judgmental because they care about something important and good. They’re critical because the thing they’re criticizing needs criticizing, for the good of whatever-it-is. (“Whatever-it-is” is something you can’t argue with — in fact, you probably agree.)

The Church Lady is the way she is because evil is, in fact, running rampant in the world. Our young people are being harmed, and the future of civilization (and our immortal souls) is at stake.

Mean Mr. Mustard can’t believe all the waste in the world. He saw his best friends killed on the battlefield. He sees the destruction our dependence on energy causes; he sees the destruction of our climate; he sees the horror of war, of fighting over resources — now he shaves in the dark and tries to save paper. He knows loss.

The Church Lady and Mean Mr. Mustard are total jerks.

But can’t you sort-of identify with at least one of them? There are real, good, important things you care about too.

Tim explains how ongoing is baked. Nice solution. I love reading stuff like this.

My own solution is ridiculously heavy compared to his. It rebuilds the entire site (on my hard drive) on every publish. But it has the previously-built version of the site on disk, and writes only the files that have changed. Files that haven’t changed don’t have their timestamp modified.

Then it rsyncs the site to the server. If I’ve changed a template, that might mean every page has changed and so the whole site is sent up. But usually it’s just because I’ve added or edited an article, which means just four or five files get sent.

It’s totally brute-force — but surprisingly fast, even for an 11-year-old site like this one. (If I had a Flash drive I bet it would be even faster.)

I still get to write using MarsEdit, by the way. It talks to WEBrick running on my laptop.

Craig Hockenberry critiques Xcode 4’s documentation viewer.

He also links to Ingredients, an alternate documentation viewer (in beta, open source), that I didn’t know about.

Dave Winer says: “All baking done on premises.”

I’ve had people point me to some things I know about and some I don’t. Links:

Jekyll
Stacey
Laguna

A few people pointed out the problem with dynamic-authoring/static-publishing — the system spends too much time rebuilding after comments. I was going to mention Disqus and similar in my original piece, but didn’t want to over-complicate things. (Didn’t I read that Facebook rolled out a comments systems for weblogs? Sounds likely.)

Gus Mueller bakes his blog — it’s done in VoodooPad.

Mark Bernstein’s blog has been baked since 2002 — it uses Tinderbox.

Completely unrelated: 100% of Panic’s proceeds today go to help Japan. Buy Panic stuff!

Jim Dalrymple is a cheeky bastard. In the best possible sense.

Tim Bray’s Things on Blogging has a bunch of great advice. Enough that I can’t pick just one thing to quote.

You’ve noticed that processors aren’t getting faster as quickly as they used to. Instead, manufacturers are adding more cores. This means that app developers, in order to make their software faster and able to handle a bigger load, have been learning new techniques — they’ve been learning to take advantage of multiple cores. (They’ve been learning how to write multi-threaded apps.)

I think there’s a somewhat similar situation in the web-in-general. Servers aren’t getting faster, but traffic’s going up.

And so, even in the year 2011, if your weblog gets Fireballed, there’s a good chance it won’t be able to handle it. That seems crazy. It’s not 1997 — it’s 2011.

It freaks me out that this is still an issue. Or, worse — sometimes it pisses me off a little, when I want to read something and I can’t. (Imagine when it’s a post on your product’s weblog. I might never come back, or I might get a bad impression of your thing just because your site couldn’t handle a spike in traffic.)

Given that we can’t rely on servers getting faster, but we can rely on more and more traffic, weblog developers could learn new techniques to make their sites faster.

New technique is old

I think the new technique web developers — or weblog developers, at least — ought to learn is static rendering: writing files to disk rather than building from a database on every request.

It’s an old technique, actually, but too rarely practiced. (Lots of weblogs in the ’90s were rendered as files-on-disk. They were built from a database plus templates and scripts and uploaded to a server. We did a bunch of this when I worked with Dave Winer at UserLand Software.)

In 2002 Aaron Swartz wrote Bake, Don’t Fry, which is worth re-reading. (He also wrote that he doesn’t care about performance. If getting fireballed were a thing back in 2002, he might have cared about performance. If he had seen system X go down for a day, he might have cared about performance. It’s interesting that performance — or robustness — arguably wasn’t an issue in 2002, but it is now.)

Two main ways to do this

1. Desktop/laptop to web: in this scenario, your personal machine holds the source. An app or set of scripts generates the website based on templates, then uploads it to the server. (That’s what I do with this site.) It works great: I’m a huge fan of this style of publishing.

2. Dynamic authoring, static publishing: in this scenario, everything lives on the server. You have the advantage of being able to publish from anywhere you can get to a web browser. But then the server generates static pages when you make a change. It’s much like the first scenario, except that it’s accessible from everywhere. (It supports multiple authors better too, for people who need that. Which I myself do, for some sites.)

I’m aware of a few things

• Dave Winer is working on new software which I think implements the first scenario. (I think, that is: I need to investigate. I could be mis-characterizing the software.)

• WordPress has WP Super Cache, which should make your site Fireball-retardant. I use it on a couple sites. But this feels like a temporary band-aid. I keep wondering if we’ll need a WP Super Amazing Cache at some point.

• Movable Type can work like the second scenario, but I can’t help but feel that Movable Type is a much-heavier solution than the average blogger requires or wants. It feels like a pro thing, where the average blogger would like something closer to the Twitter end of the blogging spectrum.

• Blogger probably does static rendering. Maybe TypePad does too. But, to be clear, I’m talking about slightly-geekier-bloggers, the type who install a blogging system on their own server or on their shared space at DreamHost or wherever. Those are the weblogs I tend to read.

What I’d like to see

Given the above, I think the still-missing piece is the scenario #2 weblog system. It should be as easy-to-install and easy-to-use as WordPress — easier, actually, would be better. Not-requiring a database at all would be awesome. To be successful, like WordPress it would probably have to be done in PHP, since PHP remains the commonly-installed scripting system on shared webservers.

Maybe such a thing exists already? It’s entirely possible. (Then the next step is marketing it so that people like me hear about it.)

Anyway, I bring this up because I’m tired of slow sites or sites that go dark the very minute I hear about them. It looks to me as if there’s a big missing piece in the ecosystem, and now might be a great time to build that piece. Because, otherwise, it’s not going to get any better.

I’ve been enjoying Justin Williams’s weblog (carpeaqua) lately — he’s totally on a roll. Definitely worth subscribing to, if you haven’t already.

The App Store review process now has a resolution center. Apple writes, “The Resolution Center offers additional details, explanatory screenshots if applicable, and links to information on how to resolve any issues.”

I haven’t seen it yet, but it sounds like a good thing. Whenever this process can be streamlined — made easier and quicker for Apple and for developers — that ends up a good thing for users. (Better software, delivered more quickly.)

Peter Hosey has updated his Cocoa links card.

Gus Mueller shares a simple technique for automated testing of undo. Uses blocks.

Loop Insight notes a Business Insider report that the Zune is done.

I never did see one in real life.

It’s self-evident, I hope, that the best alternative to Twitter would be, like the web itself, not owned by a vendor.

It would be decentralized — there would be no single point of failure (no one big fail whale) and no single concentration of power. Again, like the web itself.

(This is not a critique of capitalism, by the way. I’m a big fan.)

This would remove the barriers to innovation and entrepeneurship. Nobody could stop anybody else from writing apps. There could be all kinds of companies, from the smallest one-person shops to the biggest companies, that work and compete in that ecosystem, but none of them could own it.

But how do you create a system as easy-to-use as Twitter? In a decentralized system, how do you find people to follow? How do you know how many followers you have? How does a message get to everybody? How do you even get started as a new user?

I don’t have all the answers — I don’t even know what all the questions are.

We know that decentralized systems are possible. Again, look at the web: there’s no one big webserver. Or email (as much as we don’t like email). RSS (near to my heart). Usenet. Decentralization is the rule, not the exception, on the internet.

Creating a decentralized system as compelling and ready-for-prime-time as Twitter would be quite a challenge.

Is it a good idea? Is it a necessary idea? I don’t know. But I do know that I like thinking about it.

The Twitter API announcement today has me stunned.

Instead of being pleased by third-party support and encouraging it, they talk about the need for a consistent user experience. They say that “the top five ways that people access Twitter are official Twitter apps” — but also that “consumers continue to be confused by the different ways that a fractured landscape of third-party Twitter clients display tweets and let users interact with core Twitter functions.”

The announcement says that “Twitter will provide the primary mainstream consumer client experience,” and that “Twitter has to revoke literally hundreds of API tokens / apps a week as part of our trust and safety efforts, in order to protect the user experience on our platform.”

Then it goes on to talk about about developer opportunities. There are a bunch, which is cool — but writing a Twitter client is not on that list.

Dave Winer summarizes: “If you make a Twitter client, you have a bit of time to get out of that business. If you were thinking about writing one, don’t.”

I’m seriously disappointed by this. Not as someone with a Twitter client, but as someone who likes the service and wants my fellow developers to do interesting things.

One of the cool things about Twitter is that the service sparked a bunch of UI innovation on the part of some very talented client-app developers. I want to see that continue. But it’s as if they said: no more. Stop. We’ll take over now.

Update: ReadWriteWeb, Twitter Tells Developers to Stop Building Twitter Clients:

Mainstream users are actively confused by different interfaces? And this is such a big problem that non-standard interfaces need to be stamped out? That just seems crazy, patronizing, arrogant, obnoxious and suspiciously arbitrary.

Another update: I’m just sad. So much of the fun of Twitter was seeing what developers did with it. That messy, buzzing “fractured landscape” was awesome, and I’ll miss it.

Another update: Craig Hockenberry answers the question of why third-party Twitter clients are important to the Twitter ecosystem by listing some of Twitterrific’s firsts.

Important stuff from Craig — I needed this myself.

When I see a kitten, I smile. I can’t help it. I don’t decide to smile, I just smile.

Same thing with hearing about the new book iOS Recipes by Matt Drance and Paul Warren. I didn’t decide to buy it, I just bought it. Couldn’t help it.

I keep running across people and companies I didn’t know about, and thinking, “Wow, they’re good.” I like it even more when I also get to think, “…and they’re generous too.”

I just ran across Bjango a few minutes ago. They have some cool-looking apps for iPhone, iPad, and Macs. They also have a weblog with articles on the App Store and on design.

I love this article about roundrects in Photoshop — it doesn’t present one or two methods, it presents a bunch of them. Here’s another about noise and textures. Good stuff. I’ll catch up on the rest when I have some reading time (hopefully later tonight).

Maybe I should have known about Bjango, but I didn’t. That’s kind of my point — there are so many folks in the community these days doing good work that it’s easy not to know about cool stuff. That’s a good problem to have, way better than the opposite!

(If I had one complaint, it’s that I can’t find the people’s names anywhere on the website. I like to know names. Names are important.)

Anatomy of a Crushing: “My Twitter client, normally a place where I might see ten or twenty daily mentions of Pinboard, had turned into a nonstop blur of updates. My inbox was making a kind of sustained pealing sound I had never heard before. It was going to be an interesting afternoon.”

(Via Bob Frank.)

I love how Mike Rundle brings design and code together.

Check out Design Then Code. There’s a free tutorial on Building iOS Apps From Scratch.

Further down the page is two linked tutorials taking you through a single project. I’m going to get the Design Rookie tutorial.

Mike has a bunch of great posts on his weblog. A few of my favorites:

Crafting Subtle & Realistic User Interfaces
Be Curious, Be Dangerous
Kill The Settings, Build Opinionated Software

Manton Reece: Where Apple went wrong with free apps:

Apple is trapped by their original decision to shoulder the cost of free apps. They encouraged free apps and now they’ve got one band-aid on top of another — advertisements, in-app purchase, subscriptions — all trying to make free apps work for the App Store bottom line.

A side note: I can’t think of any other profession where people give away for free so much of what they create. (Maybe I’m just not thinking hard enough.)

For the luvapete, don’t ever use this. (Via Dave Winer’s linkblog.)

I wonder what this is going to be. Flare for Mac.

(I can’t hear the word “flare” without thinking of Office Space, though I suppose the word in the movie was actually “flair.”)

Episode #32 of the Daily Edition, The Art of iOS, is up. Dan interviews me. Totally fun to do. If Dan ever asks if you want to go on the show, say yes.

Imagine starting your computer programming career way back in the ’70s, in those Watergate-hazy, Archie-bunker-ish days between A Space Odyssey and Star Wars.

Then imagine — in those dark ages, just 10 years after the era that Mad Men depicts — you’re a woman.

Borders are broken up and walls are cracked open person by person, achievement by achievement. My Mom is one of those people who did that.

And she taught me to program — she taught me about code elegance and about how the best programmers are lazy and never want to write the same thing twice. Software architecture was dinner-table talk when I was a boy.

Her heart valve replacement surgery — relatively minor, as heart surgeries go, but still, sheesh — went very well today.

Change comes when a bunch of people say, “Hey, I want to do x. And it doesn’t matter that I’m a y — they can’t stop me!”

I’ve never had to say that, but my Mom — like millions of Americans and people around the world, yesterday and today — did say that. And kept saying it, and did it.

In a day or so she’ll get out of ICU and get her iPhone back and she’ll read my weblog.

Cheers, Mom. You’re my hero. I wish for everybody to have a hero like you.

Peter Hosey on how to “get the docs, the right docs, and nothing but the docs.”

We were already dead before the chip even shrank: “…any code that will break under dual-core is already broken under single-core.”

I’ll be on the Daily Edition tomorrow morning.

Totally looking forward to it — I’m a huge fan of 5by5.tv. Dan’s doing such great work.

I want to say that 5by5 is the network of record for our industry in the way that the New York Times used to be the newspaper of record. I’m not sure that actually makes sense — but I want to say it anyway.

rentzsch.tumblr.com: “Software is streamlined by defining and supporting predetermined workflows. The tradeoff is that flexibility and composablity suffers.”

Wolf’s last line (which I didn’t quote) is spot on, I think. It describes exactly what we’re all doing, or should be doing.

The iPad 2 Rant: “Arguing that Apple would be doing better by doing what everybody else is doing isn’t usually very convincing to me.”

Mike Ash: A Tour of OSAtomic:

There are many rules to follow when writing threaded code, but the most important one is this: lock all access to shared data... Atomic operations allow you to sidestep this requirement and access shared data without using locks.

It’s articles like this that make me want to have Mike officially declared as a national landmark.

For a while during development of NetNewsWire Lite 4.0, the BBC was a default feed.

But I couldn’t stand the way the favicon looked — I figured there was no way I could ship it as a default feed, given how the favicon looked. It looked like this:

Yuck, right?

But something about that just didn’t seem right. There’s no way the BBC would have knowingly created such a rough-looking favicon. It’s the BBC, after all, not Bob’s Burger Cabana.

So I inspected the favicon, opened it in Preview. And it turns out it had two representations, one at 32 x 32 and one at 16 x 16. My code was naively just scaling down the 32 x 32 version, hence the blurries.

I’m not a graphics expert. I know some people who are. But I figured this one out on my own! (Hint: ImageIO.framework.)

So I ended up getting the non-blurry version, and it looked so much better.

Postscript

Then I deleted it as a default feed anyway.

But then I noticed that the favicon is blurry in Safari too.

The Safari team does fantastic work. I love the browser. (And WebKit.) And I mean absolutely no disparagement.

But still, I was a little happy at this little thing — that I got the BBC favicon right. :)

Update

Turns out this was an issue in Camino too. Fixed. (Via Chris Henderson.)

(This post is for fellow developers more than for users — it’s a look at a specific UI problem and how I solved it in NetNewsWire Lite 4.0. I don’t claim any special genius — in fact, I’m not totally happy with the solution and continue to look for something better.)

Favicons expect a white background

The source list is definitely not the standard source list — it’s not blue. The selection highlight is different. You can have an empty selection.

Here’s why: it’s because the app displays favicons downloaded from the web. In most apps with a source list, the developer is in complete control over what icons appear in the source list. They can be created to look good with the blue and disabled gray background color. They can be made — most importantly — with transparency.

Favicons (like most graphics on the web) are made with the expectation that the background will be white. They often don’t have any transparency.

So I made the source list background 95% white: close to white, but not stark white. (I considered stark white.)

Pictures

Here’s what a standard source list would look like, using normal blending:

Note how there are apparent white boxes around some of the favicons — those are the ones without transparency.

Here’s a standard source list, but this time the favicons are drawn using multiply blending:

In some ways this is better. But note how the interior of ReadWriteWeb’s icon is so much less bright. Same with TUAW’s icon.

When you have an entire source list like this, not just a small detail as above, it ends up looking like it’s having a bad day but doesn’t really want to talk about it. It’s just feeling kind of blue.

Here’s what the actual shipping version looks like:

It’s drawn using multiply blending, except when the item is selected — otherwise the interior of the ReadWriteWeb’s favicon would have been the color of the selection highlight.

This solves most of the problems — you don’t get weird white boxes, and the whites don’t get dulled-down to that blue background.

But it means the source list is non-standard, and it contrasts less-well with the articles list on the right. (And so I expect to get constant feedback that the source list is non-standard.) (At one point I even considered no icons at all. I like the look. But that’s a minority taste, I’m sure. I even considered doing something very different — here was a first cut.)

Which is just to say it’s tricky. Still working on a better answer.

Check out pttrns and Mobile UI Patterns. Very cool. (Via Josh Clark.)

Some of the particulars, in no particular order…

It requires 64-bit processors

This is because when Flash crashes on 32-bit machines, it takes down the app with it. When Flash crashes on a 64-bit machine, it’s just Flash that crashes.

It doesn’t have syncing, starred items, AppleScript support, searching...

This really is a Lite version, by design. Like NetNewsWire Lite used to be — just the basics.

I’ve been using it for a couple months as my everyday news reader. Beta testers have had it almost as long. And while I’d like to have syncing, searching, starred items and so on, I’ve been really happy with its speed. And I love the little thumbnails. That mark-all-as-read is finally undoable.

That you can set the refresh time to 10 minutes. That it supports gestures. That you can edit feed names inline. That it launches and quits very fast.

Folders

Though there are no folders by default, you can create one via File > New Folder.

Non-synced feed advantages

There are a couple advantages to non-synced feeds. The first is that it can read authenticated feeds, which Google Reader doesn’t support. Another is that the news comes in faster — you don’t have to wait for Google Reader to get it beforehand.

(But I know, yes, that syncing is important, and it’s totally planned for the full version of NetNewsWire 4.0.)

(And you can run this alongside an older version of NetNewsWire or any other reader — it’s a separate app.)

Customize toolbar has a bunch of commands

Everything that appears in the Share menu can also appear as single buttons in the toolbar. Choose View > Customize Toolbar.

Forum, bugs/feature requests, Help book

There’s a new forum (a Google Group) for the app, and a new UserVoice site for bug reports and feature requests. There’s a Help book too. All of this is in the Help menu (you don’t have to bookmark this page or any of those links).

Notes for developers

It uses Core Data — even though I’ve written previously about the drawbacks. (I’ll do a follow-up post.)

The article list is a custom NSScrollView — I wanted a table view with views, something like UITableView. It’s not hard to write. (But, on the other hand, I’m not actually suggesting you do that.)

NetNewsWire Lite 4.0 is up on the Mac App Store.

It’s free. If you already run an earlier version of NetNewsWire, you can run this at the same time — it’s a separate app, with its own preferences, data, and caches.

It’s been years since there was a separate Lite version — but for years there were always two versions of NetNewsWire: the full version with all the features, and a free Lite version with just the basics.

(In fact, NetNewsWire Lite was the first to ship, way back in 2002. The full version followed in March 2003.)

The Lite version was often my favorite version, since I personally prefer simple, lean, light apps to swiss-army-knife-apps. And, at the moment, NetNewsWire Lite is by far my favorite NetNewsWire.

It’s a complete rewrite of the code base, which had last been re-architected in 2004/2005. It was overdue, and it’s taken about a year to do. The iPhone and iPad versions will soon use this code base too — and there will be a full, for-pay version of NetNewsWire 4.0 for Macintosh too. (The full version will have more of the features you’re used to: syncing, searching, starred items, AppleScript support, and so on.)

I’ve been coding for speed, stability, flexibility, and ease-of-maintenance. It’s a solid base to move forward. I couldn’t be happier with it.

The UI is new too, not just the under-the-hood parts. (Click the thumbnail below for a bigger version. Of course there are more screenshots on its App Store page.)

For more about the UI, see my Flickr set with in-progress screen shots: The Making of NetNewsWire Lite 4.0.

(Also: the app has a Help book. I’ve put a copy on the web if you want to see it before trying the app. But, really, the app is free, so just go for it already, willya? :)

I love this question on Stack Overflow — it’s a few years old, but still interesting: “How many lines of debugged code do you produce in a day’s work?”

The answer for me, like many of the respondents, is that the good days are measured in negative numbers. And the great days are measured in very big negative numbers.

(Via Chris Pepper.)