Thought Delimited

One of my clients contacted me yesterday to tell me that there was a problem with reading their RSS feed in Safari (and only in Safari).

Over the next hour or so, I learned quite a bit about how the current version of Safari (3.2.1 as of this writing) handles RSS:

• By default, Safari is configured to open up your default e-mail client to handle/read RSS feeds, resulting in a lot of head-scratching by your truly when I tried to navigate to the feed and ended up with a "Compose New Message" window in Thunderbird. While a lot of people do prefer the RSS-reading capabilities of their mail client over what the browser does with feeds, make that decision for the user is a questionable call on Apple's part, and some sort of alert/notice that this was the deal would have been nice.

• A lot of browsers these days will apply a style to the RSS feed XML (probably using some sort of built-in XSL, I'm guessing) prior to display so that it's more human-readable and the hyperlinks for each news item are clickable. But you can still view the raw XML using the "View Source" option of the browser. Safari, on the other hand, transforms the feed into an HTML file with JavaScript, leaving no trace of the original XML. Again, another somewhat presumptuous decision by Apple to buck convention in order to enhance the user experience.

...Those two issues are annoyances rather than bugs. The problem affecting my client's RSS feed, however, is a bug in regards to how Safari is transforming the RSS data before displaying it to the user.

Each news item in an RSS feed can contain a number of elements/nodes, two of which are the <link> and <guid> elements. The <link> element is meant to contain the URL where the reader can access the full text of the item. The <guid> element contains a string that uniquely identifies that RSS feed item within the feed (like a primary key in a database).

If the <guid> element contains the "isPermaLink" attribute and that attribute value is set to "true", then that indicates that the <guid> element also contains a URL (a permanent one) to the full text of the item (one that might be different from the URL in the <link> element), and an RSS client could legitimately used the URL in the <guid> as the link to the story instead.

What I discovered, though, was that Safari was creating the hyperlink for each news item by combining the value of the <link> element in the <channel> node of the RSS feed with the value of the <guid> element of each item (which was simply a unique numeric value), even though the <guid> elements did NOT contain the "isPermaLink" parameter. So instead of using the value of the <link> element of each item as per the RSS specs, Safari ended up creating non-existent URLs.

The solution, of course, was simple: I just put the URL for each news item in the <guid> element as well as the <link> element. Point is, I shouldn't have had to.

Once I applied the solution, I did some searching to find out if this is a known problem that was being worked on. I found one mention of it in a generic tech support forum post published in 2008, so it looks like the problem has existed for awhile but hasn't gotten much attention (probably because most people read RSS feeds through actual RSS clients). I used Safari's built-in bug report mechanism to report it to Apple, but I don't hold out much hope for that having an impact.

Still, I thought it worth a post, on the off-chance this information might help someone else.

A few weeks ago, Peter Bell wrote a blog post about the Pomodoro Technique, a time management technique that advocates setting aside a set amount of time to turn off all distractions (e-mail, IM, Twitter) and focusing on a single task. I had just recently starting adopting the practice of shutting down my e-mail client once in awhile so as not to be distracted by incoming messages, so the idea made a lot of sense to me.

Not having a physical kitchen timer like the Pomodoro folks use and finding my stopwatch to be somewhat inadequate, I decided to try and write an AIR application to fit my needs. And so the focusTimer was born.

It's a very simple app: set the amount of time you want to focus (the 25 minutes advocated by the Pomodoro folks is the default), and click the "Start" button. I didn't want to get caught up in checking to see how much time was left, so I added a button so I could toggle between seeing the time left and just a status message.

I wanted to keep the window small so that it could be moved out of the way, but I also wanted a strong visual cue for when the time was up, so the color of the window changes to green when you start the countdown, switches to yellow for the "2-minute warning", and ends in red when the timer runs out. In the two days I've been using it at work, I've found that I can move the window to the far end of my secondary monitor and still catch the color change out of the corner of my eye.

Finally, even though the idea is to block out all distractions, there are some interruptions that cannot be ignored, so the "Start" button toggles between a "Pause" button and a "Resume" button once the countdown has started. If your focus session goes completely off the rails, you can use the "Cancel" button to break out of it and start all over again.

Even though I wrote this AIR app primarily for myself, I figured other folks might find it useful, so it's now available for download up on RIAforge: http://focustimer.riaforge.org

I just finished reading Issac Dealey's recent blog post (worth reading, by the way) where he shares some of the results from a survey he conducted regarding framework preferences back in September.

In the post, he mentioned how difficult it seems to be to get folks to participate in these kinds of surveys, and it reminded me that someone else in the community was recently pleading with folks to take their survey (unfortunately, I forget who, but I did take it). And I wonder what kind of a response Hal Helms is getting with his ColdFusion Web Developer Survey.

So it got me thinking: is surveying the community/getting feedback from the community a problem in need of a solution? Are these surveys being neglected because people don't see the point or don't have the time? Or is the low response rate more the result of a lack of publicity or poor technical implementation of the survey itself?

Any thoughts?

In my last blog post, I suggested that Adobe include a list of CFML community resources in the upcoming Bolt IDE in order to promote the community to isolated developers who might otherwise be unaware of all the resources out there.

After thinking about it a bit more, it occurred to me that maybe Bolt could take it one step further. Instead of simply using Bolt to point developers to the community, have Bolt bring the community to the developer. Build in an RSS viewer that displays the latest ColdFusion posts from Adobe Feeds. Put in a communicator tool so the developer can converse with other CFML programmers via IM or Twitter. Let the developer screen-share their code with other developers both inside and outside of their organization. Integrate geolocation into Bolt and show the developer a list of other Bolt users (and maybe Adobe user groups) that are nearby. Instead of using e-mail and message boards to communicate with CFML developers, Adobe could broadcast any news announcements to all of the Bolt installs, and Bolt users could submit questions to Adobe and other users via discussion forums displayed in a window of the IDE that gets refreshed automatically.

I'll admit, it's a pretty pie-in-the-sky idea. Given that Adobe only has a finite amount of time and resources, I would certainly not want Adobe to leave out any traditional IDE features, the things that allow developers to code quickly and efficiently, in order to take the time to add all of the things I just suggested.

But if they did have a little extra time, I think adding even one or two simple collaboration/informational features would certainly enhance the product, and perhaps set a trend for other IDEs to follow.

The MAX Day 2 keynote address is still in progress. So far, the biggest news so far regarding ColdFusion is the announcement of Bolt, a ColdFusion IDE based on Eclipse to be released at or around the same time as ColdFusion 9. Sounds promising.

You can sign up to participate in pre-release testing of Bolt on Adobe Labs at http://labs.adobe.com/wiki/index.php/Bolt

Not much else about ColdFusion so far: I'm trying to keep apprised by watching Twitter and the live blogging being done by two Adobe evangelists at http://www.webkitchen.be/2008/11/18/max-san-francisco-keynote-day-2-liveblog/

Unfortunately, I am at work, so I can't entirely devote my full attention to what's going on. :)