Thought Delimited

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. :)

Yesterday I ran into an old colleague at the gym (we'll call him Glen). Glen conducts training sessions on technical topics.

Glen asked me if I knew if anyone at the university was using Ruby on Rails. I told him that I didn't think so. He then told me that he was giving Ruby on Rails training at John Hopkins University because they were looking to reduce their use of Java. I responded by saying that I thought Hopkins also used ColdFusion for certain things.

I expected him to either simply agree with my observation, or perhaps offer an explanation about why Hopkins was looking at RoR verses expanding their use of ColdFusion. I was not expecting him to respond with the standard FUD about ColdFusion: it's dying, people are moving away from it, etc. He even went so far as to refer to it as the "COBOL of web programming languages."

I countered with the numbers announced at cfObjective(), that the number of ColdFusion developers had increased dramatically over the past year. That elicited a "well..." and then another assertion that ColdFusion use was decreasing in the federal government as well (there are a lot of government-oriented CF jobs here in the D.C. area).

There wasn't much else to say or do at that point. I couldn't hold him up from where he was going and I had somewhere else to be as well. So I shook my head, laughed at his prediction of ColdFusion's demise, and basically said "Yeah, we'll see about that."

My immediate feeling after the conversation was more amusement that annoyance. Year after year, we hear the annual proclamation that "ColdFusion is dead," yet the proclaimers never seem to realize that if they keep saying it year after year, ColdFusion obviously must be still around. And more often than not, they have no hard numbers to support the idea that CF use is waning, just statistic-free assertions.

Now that I'm several hours removed from the conversation, I find myself more curious about why Glen even had an opinion on ColdFusion in the first place. I don't know him all that well, but he's always struck me as a fairly rational person and not someone who's looking to make and win an argument, yet he immediately began disparaging ColdFusion the moment I mentioned it. What or who lead him to having this opinion about CF? I may have to ask him that the next time I run into him.

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.