Crisis Averted!

The folks over at iPhone Web Dev, a great resource for iPhone web application development, have forked Lace with a few little tweaks and made it play nice with the iPhone.

They've set up a live demo to play with (it works damn well), and have released the modified source to boot.

According to this Microsoft KB article, memory leaks caused by circular references or closures in JavaScript have been eradicated from IE6 on Windows XP.

After all these years dealing with this problem, it sounds almost too good to be true. via

Keith Grennan recently described how he used Jabber::Bot to create an e-mail notifier, complete with code examples. Through a wicked combination of procmail, Perl, Jabber::Bot and Growl, he receives a sweet little notification when he's got new mail. Nice!

Jabber::Bot 1.1.1 is now available. This release includes a minor change to the listener thread that should improve CPU usage in some cases.

Some folks have directly or indirectly reported that Jabber::Bot tends to peg CPU usage at 100%. This is due to how the underlying Jabber::Simple framework handles incoming messages. Jabber::Bot 1.1.1 should alleviate these CPU usage pains in most cases.

Download:
jabber-bot-1.1.1.gem
jabber-bot-1.1.1.tar.gz

Coda, the new all-in-one web development tool from Panic is truly a great app. It has tons of useful web development features within reach: text editor (complete with optional fancy CSS editor, syntax highlighting and code completion, and more), FTP client, live preview, terminal and code references (books) all wrapped up into one very slick, very Mac UI.

Despite all these good things, I feel that version control is sorely lacking. Users of TextMate, or other tools with version control integration (Eclipse, etc.), will find Coda's lack of version control a slight setback. Of course, command line access to version control is still possible, and power users won't mind. But, if Coda were to have support for this built right in, I think there are a lot of folks that wouldn't mind that, either.

Jabber::Bot 1.1.0 is now available. New in this release is support for Jabber presence, including presence (available, away, do not disturb, etc.), status messages, and priority. There are several other additions, changes and fixes in the full release history.

Despite my best efforts for a bug-free initial release of Jabber::Bot, a few choice issues found their way in, including one line of debug code. Oops.

With that, Jabber::Bot 1.0.1 is now available. Fixes include the removal of said degug statement, and two regex fixes. The release history has all the details.

Jabber::Bot makes it simple to create a Jabber bot with little fuss. It is a perfect starting point for creating and customizing a powerful Jabber bot, public or private. A Jabber::Bot's command repertoire is a combination of regular expressions and pure Ruby code. With a little creativity, there's really nothing a Jabber::Bot can't do.

For example, I recently created a Jabber::Bot that interfaces with a custom Lace chat room I extended with a RESTful API, and it's been working great.

Installing Jabber::Bot is a snap with RubyGems: gem install jabber-bot.

You'll find some brief documentation with examples on the Jabber::Bot home page. Also, the RubyGem contains full RDoc, and the gzipped tarball includes a sample Jabber::Bot implementation.

Recently while working on a few Swing applications at work, I realized that one of the most frustrating aspects of developing Swing apps (and perhaps GUI software in general) is also one of the most mundane: user preferences. Building out the main application is tremendously rewarding, but providing users with preferences can be a huge pain.

Most GUI applications provide some way for a user of the application to modify how the application behaves at run time. In fact, users expect some level of control over the application's behavior. As a user, I like having options, even options I know I won't need right away but might like at a some point in the future. But users — myself included until recently — don't realize that, as a developer, providing users with options is often a huge pain.

First, the preferences need a place to live. As developer, I need a way to retrieve preferences from somewhere and store them back again. This storage system could be a text file of key-value pairs, more complex XML data, an OS-provided data store (e.g. Windows registry), a relational database, or umpteen other possibilities. Choosing the proper way to handle the storage of user preferences depends on the size of the project, but is by no means a simple matter. Simple applications with many options can quickly outgrow a simple storage system.

Once I've decided on a storage system and implemented an API for manipulating it, it's time to give the user a way to see and modify the current configuration - a user interface. As luck would have it, there are no standard conventions for creating preferences UIs. Because the preferences for a unique application are, well, unique, there is no one generalized UI that will work in most situations.

It was at this point in the development of one Swing app that I had an epiphany.

A user preferences UI and storage system is a complete project in and of itself, with a purpose entirely separate from that of the application to which it provides configuration abilities.

It was also at this point in the development of one Swing app that I began to gently rock back and forth in my chair, mumbling incoherently as I realized exactly what I was up against.

The preferences UI has to make sense. The user has to be able to quickly find where a setting can be changed. If the preferences UI is too convoluted the application becomes difficult to configure, and the overall experience using the application can be adversely affected. Sometimes this is a task best left to designers or so-called information architects. I would advise against letting a strictly developer-type build your preferences UI. This is something that a user will see from time to time. It needn't be pretty, it need be easy to use.

Once I've sufficiently sketched the UI (or reviewed a designer's sketches) and feel I'm confident I understand how it will work, the biggest pain begins. I must now translate thoughts and drawings into code. This is perhaps the most time consuming step in the process. The preferences system I create must present a simple UI to the user and also be easily maintained when preferences are added, removed or modified.

Creating the UI itself isn't terribly difficult, but because preferences often use a myriad of UI controls such as text fields, select lists, drop downs and check boxes, the logic behind each control must be fleshed out and properly bound to the storage system. In some cases, controls will also have unique validation requirements such as a minimum character length or specific punctuation to avoid configuration errors. It's the 'controller' logic that is the real killer of moods. Creating this layer of the user preferences system is the most tedious and time consuming and can also be the least rewarding. It's just fluff, but it's important fluff. Therein lies the rub.

Finally, after I've designed and created the UI, bound the controls to the storage system, validated certain new values, after I click 'Save' and the the modified values are written out to the storage system, after the application responds to me changing preferences, my job is complete. I've just spent a few hours, likely days, and potentially weeks allowing Joe User to change his text color from Medium Quasar Blue to Metallic Pearl Shine. And because my application is not a Medium Quasar Blue to Metallic Pearl Shine font color changerator, I've just spent many hours on code that does not help accomplish my applications main goals.

At this point, my user is happy, and if I happen to work on another application that needs a Medium Quasar Blue to Metallic Pearl Shine font color changerator, I've already got some code to work with. However, I'll still need to decide upon the proper preference storage system, create a unique UI and write the tedious controller logic fluff. There's got to be a better way.

On the heels of the release of Basecamp's latest time tracking addition, I've modified the initial release of Basecamp Time Reporter to take advantage of the new feature.

The changes improve performance greatly. Now, instead of exporting and parsing each project's time report individually, Basecamp Time Reporter needs only a single pass over a single export, making it about 75% faster.

Download

Basecamp Time Reporter 0.2 (8KB)