Thought Delimited

I decided, mostly on a whim, that my blog needed a new look. It hadn't changed much since I first launched it back in October of '07, and it looked pretty stark compared to many of the current blogs out there now.

I was aware that a number of fellow ColdFusion bloggers were using a ColdFusion-powered blog engine called MangoBlog, but I didn't know much about it until I downloaded it and started poking around. Installing it on my local development machine was a breeze, and I was impressed by the skinning and plugin features, so I decided to give it a shot.

Installing it on my actual website proved to be more of a challenge due to my hosting environment (a shared server on HostMySite). For one thing, the 50-second execution time limit imposed on the server prevented the MangoBlog installation code that copies data over from BlogCFC from completing, but I was able to hack the code in order to break up the import process into several steps. I also ran into a weird issue that prevented the comment subscription functions from working (more on that in a separate blog post), but I got around that as well.

The "skin" I'm using is a personally-modified version of one of the skins that comes packaged with MangoBlog, called "Glossy Blue." I added a picture of Yosemite Valley my wife took in the summer of '06 as the page background, used some CSS hackery to widen the content area and give the side column a different background color, and expanded the size of the calendar icons so I could include the year as well as the month and day. I may make a few additional tweaks, but overall I'm pretty happy with it.

There's a lot going on in the ColdFusion community now that ColdFusion 9 and the new ColdFusion Builder IDE are now in public beta. I'm eager to delve into both products (but especially Builder because that will hopefully benefit me immediately), so I expect I'll have a few blog posts about those.

The whole reason I started blogging in the first place was so I could share some of the things I've come up with coding-wise, techniques and thoughts that might be of value to others, so I hope to continue blogging in that vein.

As I previously mentioned on my blog last week, Mozilla has launched a new means of creating add-ons for Firefox called Jetpack, which allows would-be plugin developers to build add-ons with HTML, CSS, and Javascript functions that include all of the jQuery functions.

As it happens, the first two functions listed in the Jetpack API were the clearInterval() and clearTimeout() functions, and that gave me a idea. My most recent AIR application, focusTimer, is a desktop widget inspired by time management techniques like Pomodoro, where you basically shut out/off all distractions and work on a task for a set amount of time. Once that time is up, the idea is to take a short break before starting another distraction-free period.

So my Jetpack add-on, browseTimer, is a timer built into the status bar of Firefox that lets you set how much time you want to spend browsing the web before getting back to work. Once the timer expires, the add-on uses the Jetpack API functions for the Firefox tabs to blank out the content of all of your open Firefox tabs and turn the body of the now-blank pages red (in other words, you KNOW when the timer has run out!).

It's certainly not the most useful add-on in the world, but it didn't take long and it helped me learn the basics of Jetpack.

If you're interested in checking it out, visit the following page...

http://www.swartzfager.org/blog/mozillaJetpack/browseTimer/installBrowseTimer.html

...for the link to the Jetpack add-on need to run all Jetpack-based add-ons, links to the Macintosh and Windows versions (there were slight differences in how the input elements were displayed in the status bar that warranted two separate versions), and instructions on how to uninstall it if you don't like it/need it.

Since I've already defended Twitter in two other people's blogs this past week, I figured I should write my own post on the matter. That way, if I feel inclined to comment on Twitter use again, I can just post the URL to this entry and leave it at that (save myself some typing).

I wasn't enamored with Twitter when I first checked it out. I wasn't interested in the mundane things people were doing at the moment, and I certainly didn't think anyone really cared what I was doing.

But at cfObjective() 2008, it quickly became clear that Twitter could help me connect with fellow conference-goers and clue me in on what was going on in particular sessions, where people were gathering to hang out or go out, etc. And I've used Twitter ever since: I'm not on it every waking moment and I don't feel like I'm disconnected when I'm not on it, but I do make use of it.

I really feel that the simple trick to getting value out of Twitter is to follow people whose Twitter posts ("tweets") provide some value to you: information, insight, humor, whatever. Most of the people I follow are ColdFusion/RIA/Web developers, and they'll post any interesting links about those topics that they encounter as they surf the web. It's almost like a people-powered RSS feed of tech articles, except that you're getting the information from people you know and respect rather than random people.

Sure, there are the occasional tweets about where people are or what they're having for lunch, the tidbits of daily life, but those can be easily ignored if you're not interested. And yes, it can be a distraction if you're getting live updates from Twitter via a desktop client like Twhirl or Tweetdeck, but there's a simple solution to that: turn it off while you're working, and turn it back on when you're taking a break.

I'm not trying to push Twitter on anyone--you can live without it--but I think folks should give it a serious try before deciding one way or the other.

I found out about this last night from a tweet sent out by the jQuery Twitter account (which is probably a good indication that they like the idea).

The subject line pretty much says it all: Jetpack is designed to let current web developers use their existing skills with HTML, CSS, JavaScript, and jQuery to build Firefox add-ons/plugins without the need to mess with Firefox's XUL mark-up language. While JavaScript has always been part of the add-on development process, the inclusion of jQuery should make performing certain actions a whole lot easier.

You can learn more about Jetpack via the following URLs:

• https://jetpack.mozillalabs.com/
• http://labs.mozilla.com/2009/05/introducing-jetpack-call-for-participation/
• https://jetpack.mozillalabs.com/tutorial.html

...the tutorials in the final link give you a good idea of the kinds of things Jetpack will allow you to do: the last example is a Jetpack add-on that will count and display the number of unread e-mails in your Gmail Inbox.

I want to give Jetpack a whirl, but I honestly can't think of any functionality I want to add to Firefox that I can't get from an existing plugin. Anyone have any suggestions for something to try with Jetpack?

It's interesting how web technologies keep being repurposed as a development option in other technologies (Adobe AIR, the upcoming Palm Pre's WebOS, and now Jetpack). Even though I'm not particularly interested in delving into all these different areas, I must say that I like the trend. :)

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.