I'm definitely in the "premature optimization is the root of all evil" camp, but the time has come for some performance work on Zesty News. I currently have well over 1,000 unread items, and it takes a few seconds to bring up the main view. Fixing this does make the code more complex, which is why I'm glad I didn't do it prematurely But, now is the time. So, I'll see the performance difference. Zesty's alpha testers won't even be aware that it used to take a few seconds. (And that's the way it should be.)

I don't buy the exceptions argument that Joel makes. When you're writing the code, if you're calling some outside function you need to know whether that function throws exceptions or if it returns an error code. Either way, when you're calling something that can fail, you need to decide how you're going to handle that failure. If you use error codes, you're forced to do bookkeeping all the way up the chain until the error hits a point where it can be properly dealt with (sometimes requiring action from the user). With exceptions, you can just say "this method is not in a position to do something about this problem, pass it along".

CompSci is all about tradeoffs: Joel's preference is for more explicit code that requires more bookkeeping. My preference is for something that requires a bit less bookkeeping, and saves a bit of time by leaning on the tools a bit more. People writing macros in LISP are all the way at the extreme of hiding much of the bookkeepnig behind the tools provided by the language.

There's no proveably correct answer to this, so pick your poision as they say.

Regardless of how you feel about exceptions, though, Joel's article is worth the read because of his Hungarian Notation explanation. If you've been turned off by Hungarian Notation in the past, it's worth taking a look at Joel's view on it.

So, I get to deal with the intracacies of cross-browser compatibility and the deployment aspects of a desktop application. Joy!

But, it goes beyond that. While I can imagine telling a geek friend, “yeah, you just point your browser at http://localhost:xxxx and there you go!”, I can’t imagine telling a normal person that. I certainly can’t imagine selling a product like that. That would just be irresponsible product management. My goal was to have just enough native GUI to give people easy access to Zesty News, and do everything else in the browser. I also decided early in the process that I am only targeting modern and mainstream systems, at least to start with. Here’s my supported platforms matrix:

¹ In all likelihood, Zesty News will run on any 32-bit Windows. That’s not part of my initial test plan, though, so I don’t want to guarantee that.

² OS 10.3 and 10.4

³ My testing will be with the latest version of Safari that comes via Software Update. This means 1.3 on Panther and 2.0 on Tiger.

⁴ My testing is with IE6. It is quite possible that IE5.5 will work as well.

Limiting things like this certainly reduces the cross-browser issues. There are some tricky bits, but Firefox, Safari and IE6 are close enough that I don’t spend all of my time just dealing with browser inconsistencies.

The question then becomes: what is “just enough native GUI”? It turns out that there’s not a lot of native GUI necessary, but that work does extend to providing something for every browser in addition to each platform.

Remember how I said that I couldn’t imagine telling all of the non-techies to go to http://localhost:xxxx? I have a couple of solutions for this. On both Windows and Mac, firing up Zesty News automatically opens the browser to Zesty News. But, that’s not a complete solution: people leave news aggregators running all the time. On Windows, as you’d expect, you get a taskbar icon that you can just double-click to get Zesty News to popup in your default browser. Whew! Something that “just works” with multiple browsers. The right-click menu also includes the ability to quit Zesty News (but why would you want to do that?):

As of this writing, the Mac interface isn’t quite as slick. That will change somewhere along the way. On the Mac, you can use cmd-Tab to hop over to Zesty News:

Once there, you can use the menu to launch your default browser to the right place:

Of course, you can also add a bookmark to Zesty News in your browser, given that the Zesty News software is just sitting at a URL you can point to.

Just opening Zesty News isn’t all that’s needed, though. The other key feature that’s needed when not looking at the Zesty News interface itself is the ability to subscribe to new feeds. Firefox 1.0 added a nifty feature to handle this, and the open source Feed Your Reader tool by Michael Koziarski made it easy to subscribe to feeds in Zesty News from Firefox.

That’s dandy for the 10-20% of web surfers who are using Firefox. But, what about the 80% who run IE? Zesty News includes an IE toolbar that scans for feeds and makes it as easy to subscribe as it is in Firefox:

With Mac OS 10.3.9, things aren’t so pleasant. Registering Zesty News as a reader for the “feed://” protocol is easy enough (just add it to the info.plist file). But, with 10.3.9 (and Safari 1.3), Apple took over so that Safari would display a message saying that you need to upgrade to Tiger/Safari 2.0 to do RSS. Ugh.

Zesty News has a “Browser Setup” screen that includes an option to make Zesty News your default feed reader. Unfortunately, there’s no documented way to do this under Mac OS 10.3! Under Windows, you just set a couple of registry entries and you’re done. Carl Lindberg, author of the excellent RCDefaultApp, gave me some tips on the undocumented, private APIs to do this. I haven’t had a chance to do it yet, though.

So, the net of all of this is that Safari 1.x doesn’t have a fancy way to detect and subscribe to feeds right now. However, Zesty News has a Feed Finder bookmarklet that should work in most modern browsers, and that makes it pretty easy to subscribe to feeds.

Of course, Mac OS X Tiger makes this all better. Safari 2.0 detects feeds along the way and provides an easy subscription mechanism that will work with Zesty News. (I haven’t installed Tiger yet, so I haven’t tested this. From what I’ve read, this should work fine, though.) Safari 2.0 also lets you change your default feed reader in much the same way that Safari 1.x lets you set your default web browser.

That seems a little backward to me, though. You really should be able to tell an application “I want you to be my default”, rather than having to run some other application which happens to do the same thing. Carl Lindberg reports that Tiger provides public APIs for setting defaults for file types, but not for URLs. And, of course, the private APIs have changed between Tiger and Panther.

Before Zesty News 1.0 final is released, I’m going to straighten out the Mac support to fix all of this. It’s ironic, because I use the Mac for all of my work except for Windows-specific development and testing.

Overall, making Zesty News cross-platform and cross-browser has not been too painful. There have been some days where I’ve been pulling my hair out over one little thing that works on one platform but not the other, or weird APIs or strange compilation problems. But, I feel much better about having a cross-platform Zesty News so that I can support the increasing number of folks running Mac OS X and the masses running Windows.

Late last year, I surveyed the scene and decided that I'd give it a go. None of the feed readers out there did what I wanted. Despite new RSS readers popping up all the time, they nearly all seemed to be clones of one another.

In short, and I'm sure that everyone will agree with me on this, there is plenty of room in the RSS reader space for new development and new ideas. Feed readers haven't entered the mainstream yet, but the increasing number of mainstream articles about blogs and RSS is changing that. Millions of people are using Firefox now, which raises the awareness of RSS through its little orange icon in the lower right hand corner. Safari 2.0, shipping today as part of Mac OS X Tiger, adds a blue RSS emblem. And IE7, going into beta this summer, will also reportedly have RSS support.

2005 is probably the year that news aggregation crosses the chasm. While I'm sure that there will be a small handful of dominant players, as with any business, the size of the ecosystem will be so much larger that even small players like Blazing Things can have a role.

People everywhere are discovering new ways to gather and use the information available on the internet. Zesty News will provide a new new way to gather up and read the information on the net.

The focus of Zesty News is simple: keep you informed about everything that matters to you, and use up as little of your time in the process as possible.

Zesty News runs on Windows PCs or Macs and works within the browser you're already familiar with: Internet Explorer on the PC, Firefox on the PC or Mac and Safari on the Mac. More details, screenshots and the like will be coming a little later on.

As of this writing, Zesty News has one minor feature and some cleanup and documentation to go before the initial alpha test release. That first release will not be a general public release. Only people with accounts on the blazingthings.com website will have access. Feel free to send me an email message if you're interested in being a tester for Zesty News.

The beta release of Zesty News will be open to the public, and this first release of Zesty News will be completely free. My plan is that there will always be a free version of Zesty News.

"Official" Zesty News information and tips will be posted at Blazing Things. As always, more technical discussion, and my general talk, will be here on my personal blog.

To me, that actually sounds like a bug. It's probably worth a couple microseconds (or less) to see if the data is significantly smaller than the allocated space and then do a copy if that's the case.

Ian’s perspective in this latest article is from short experimentation with Rails, but I agree with the things that he has said that he likes and dislikes. Ian has described Paste in terms that make it sound like a piece of middleware for web framework developers to use in sharing code. While that’s all fine and dandy, I do hope that we’ll start to see some fully-fleshed out packages that provide a good quick start for apps.

If nothing else, Rails has brought to light the fact that starting each new project with a completely blank slate is a real drag.

“Angels” read specs closely, write code, and then thoroughly test it against the accompanying test suite before shipping their product. Angels do not actually exist, but they are a useful fiction to make spec writers to feel better about themselves.

My guess is that many of the frameworks were created in the process of trying to get some job done. Especially given the nature of what’s easily testable with the browsers we have today, I can imagine how the frameworks we use came to be the way they are. It’s a non-trivial task to make a framework that encourages proper use of HTTP and exposes its full power while still being as easy as what we have today.

But, we do today have browsers that do a reasonable job of HTML/CSS/DOM, so it’s not inconceivable that we could have server side frameworks and browsers that let us really exploit all that HTTP can offer.

I just set up a new Drupal installation, and I'm reminded of Drupal's cron.php. cron.php runs whatever periodic maintenance tasks are needed. In other words, it changes data. But, you really want to use GET in that case, because it makes it trivial to add a wget crontab entry to ping it periodically.

My own app keeps does housekeeping as links are clicked, which is far easier via a GET than to rig up a POST via JavaScript. Maybe the difference here is whether or not one is making a claim of a RESTful interface. Or maybe the difference is how caught up in the semantics of it one is. Josh Alen has a good comment on this:

people chose between GET and POST based on other critera than suggested in the Fielding paper

This makes me think of the general notion that APIs are a user interface for developers. In Swing programming, to add a widget to a window you had to do this:

frame.getContentPane().add(somewidget)

This is the "correct" thing to do, because the JFrame object itself is not actually a container for UI widgets. But, it has a container: the content pane. Correct or not, it was annoying. Java 1.5 now allows you to do this:

frame.add(somewidget)

Though it is less "correct" for the architecture, I think this is more inline with what programmers expect and want to do with the API.

I don't know if this is the case with the Bloglines, Flickr and De.licio.us APIs, but my main point is that there are times when user experience is worth more than "following the spec".

Using F-Script Anywhere, you’ve got an object browser that you can use to poke around at the various objects in a running program, sending messages and getting responses back. Within a couple minutes of download F-Script Anywhere, I was able to send JavaScript commands to my running Safari window. Mac OS X has the coolest software architecture around.

Speaking of the Mac OS X software architecture, Apple has an open source package called Core Foundation Lite, which provides a number of the base classes used in Cocoa development. I knew that Mac OS X’s kernel was open source, but I didn’t realize that some of the framework code was also open source. CFLite is still quite low-level, but it is a way to move some code between platforms.