It’s been over a week since I’ve been able to go flying. Work and weather have conspired against me. As a poor substitute, I went through some pictures taken with my Treo 600. The first two were taken by my instructor, Rich Acuff in 374DM, the plane I eventually did my private pilot checkride in. I don’t remember exactly, but my guess is that we were flying out to the coast by Half Moon Bay when these were taken: This last one is of a Pitts Special S-2B. The careful viewer will note that the plane is taxiing on a public road, specifically Laurel St in downtown San Carlos, Ca. Back in November the city had a parade where several planes were allowed to taxi down the middle of downtown. Is that a pretty plane or what?

Sigh. Looks like the main Bloglines user database corrupted itself around 2:30am this morning. It did so in such a way so that the database still ‘ran’, for some definition of that. Which means that none of our automated monitoring picked up on this fact. We will change that. We take snapshots hourly, and we’re recovering to the most recent good snapshot. Unforuntately, that means that if you registered with Bloglines after around 2am Pacific time or so (and that’s a lot of people), you will need to register again. What caused the corruption? We’re not sure yet, although we’ve been having issues with the JFS filesystem that we’re using. So it may have been that. Update: The system is back on-line, based on the 2:05am userdb snapshot. We now need to go through the bad database files and find out what really went wrong. We are also bulking up our monitoring system to specifically detect this type of problem in the future. Update 2: We think we’ve pinpointed the problem. It only affected a small number of users and it had nothing to do with the filesystem, which is good. It was a bug in one of our programs, which is bad. In a few cases, a batch process would delete some site records from the database without removing any subscriptions that referenced those sites. This ended up looking like database corruption, but it wasn’t. The batch process in question runs nightly. The change we made was for it to delete some sites that were invalid (for a couple of definitions of invalid). This is part of our ongoing attempts to make sure our crawler only crawls valid RSS feeds. Yes, we did test the program before we pushed it to the site, but our testing didn’t uncover this particular behavior.

I apologize to anyone that has sent me email to my bloglines.com email address in the past week and a half. I just realized this evening that I hadn’t been receiving anything at that email address. It was a configuration issue with the new Bloglines machines, and has been in effect since we moved the service. All the email is stored up, so I have everything, I just need to go through it all. You’d think that I might just have a little bit of clue when it comes to email. But clearly that’s not the case. Update: Wouldn’t you know it, I’m not the only one with email problems.

We have rolled out two new Bloglines features, send subscriptions and a user directory. Send subscriptions makes it easy to transfer your Bloglines subscriptions to others. Simply enter the email address of the person, select which of your subscriptions you’d like to send, and add a short message. An email will be sent to the person which contains a link back to Bloglines. If the user is not already a Bloglines user, clicking the link will automatically create a new Bloglines account and pre-populate it with the subscriptions you’ve sent. It’s a very easy way to introduce your friends to aggregation. The other new feature announced is the user directory. When viewing a blog in Bloglines, or when looking through the blog directory, there is now a ‘Subscribers’ link to the user directory of that blog. The user directory lists all the Bloglines users with public profiles who are subscribed to that blog. It’s a great way to see who else is subscribed to a blog, and what other blogs they’re subscribed to. Both features were a direct result of user requests. As Bloglines gains in popularity, we are getting more and more great suggestions for how to improve the service. We’re doing what we can to keep up!

Warning, this is a nerdy post. Moreso than normal even. As I was visiting a site this morning that was having problems and spitting out random PHP error messages, I was reminded that I wanted to write up something about web programming. No I’m not going to name the site, but they should know better. And this is not a post bashing PHP, because like many things PHP can be used for good as well as evil. During one of our web redesigns at ONElist , a couple of our very smart engineers developed a new templating system, called CS/HDF, named after the two types of files that are involved. Later, Dave Jeske and Brandon Long wrote an open-source version of CS/HDF, called Clearsilver. It’s an excellent implementation, and it’s what we use for Bloglines. I won’t go into explaining how Clearsilver works; the web site’s got some pretty good docs in that regard. But I want to mention the design philosophy of the system. Basically, Clearsilver forces the developer to seperate application logic from the presentation layer. What does that mean? Before Clearsilver is given the chance to build a web page, all variables required for building that web page are populated. Once Clearsilver takes over, no additional data is input, no database calls are made, nothing. By the time that Clearsilver is processing the page, the application knows whether it was able to fetch all the data and whether there were any errors in processing it. How is this good? A couple of reasons. First, since the display layer is already extracted, it’s very easy to redesign the look of or internationalize the web site. No need to worry about messing up any application logic while editing templates. Also, there will never be any mysterious error messages showing up in the middle of the page whenever something fails. By the time the template is processed you know for certain whether you have all the information you need to display the page. That makes it easier to craft error dialogs. Ever been surfing a web site, and you see half the page come up, and then wait 30 seconds for the rest of the page to complete? That happens when the data required for the web page is fetched after the page has started to display. That makes it much more difficult to craft good error dialogs. If I want the look of the page to completely change if there’s an error, I can’t do that if I find out about the error after half the page has already been sent to the client web browser. Again, I’m not bashing PHP. I believe you can program in this style using PHP as well, but it’s not enforced. The language is not important (although Clearsilver is very good and deserves more recognition). The seperation of application logic from display is what matters.