Saturday, May 23, 2009

In Defense of Twitter

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.

Thursday, May 21, 2009

Mozilla Announces Jetpack, an API For Writing FireFox Adds-On with jQuery, HTML, and CSS

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:

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

Saturday, May 9, 2009

Bug In How Safari 3.2.1 Renders the Links For RSS Feeds

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, making 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.

Wednesday, May 6, 2009

New AIR Application: focusTimer

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