Favicon Alerts with Tinycon

I came across a cool favicon hack recently called Tinycon, which provides a Javascript function to add a small alert bubble to a favicon image. You can see a demo of it in action at http://tommoor.github.com/tinycon/.

Basic usage is super simple:

Tinycon.setBubble( 6 );

sets a favicon alert bubble with the number six in it.

After looking at this I was surprised that Gmail hadn’t done this already. For that matter, perhaps the Google Chrome browser could provide some native functions to make it perform even better.

Code for Tinycon is available at https://github.com/tommoor/tinycon under the MIT open source license.

Automatically Loading a Gravatar Image Based on Form Field Input

I’ve seen several examples of automatically loading a Gravatar image on the fly based on an input form field. After coming across another one recently and not finding a Javascript library that would do this for me, I sat down to play with this process a bit. I knew the process wasn’t complex, but at the same time it seemed like something that should have an easy to use drop in module to make it work. The result is a simple jQuery plugin I’m calling form2gravatar.

The source code is available at https://github.com/josephscott/form2gravatar, along with a simple demo at http://josephscott.org/code/javascript/form2gravatar/. To get started you need a form field, and a target image element:

	Email <input type="text" name="email" id="email">
	<img src="http:////www.gravatar.com/avatar/00000000000000000000000000000000?d=mm&s=64" id="gravatar" alt="Gravatar" height="64" width="64">

Assuming you’ve loaded jQuery and form2gravatar.js you can then trigger a Gravatar image lookup with:

$( '#email' ).form2gravatar( { target: '#gravatar' } );

This tells form2gravatar to watch the keystrokes in the #email element and update the #gravatar image. By default it will check the form value several times a second, which makes it easy to update the image rapidly, but might be a waste in some cases. So there is an option to only do an image update when the form field loses focus (use_blue).

For pages with several form fields setting use_blur to true will still provide a good experience and have almost no performance impact on the page. If you only have a few form fields (like on a log in page) I’d stick with the default behavior. You can adjust how frequently the form field is checked with the timer_interval option.

Here is a list of all the options in form2gravatar:

	var opt = {
		'default_img'	: 'mm',
		'size'		    : 64,
		'ssl'		    : false,
		'target'	    : false,
		'timer_interval': 100,
		'use_blur'	    : false

The only one that is required is target. The other option many folks will want look at is default_img, which by default uses the mystery man from Gravatar. You can use any of the other Gravatar default options (404, mm, identicon, monsterid, wavatar, retro, and blank) along with a URL to some other image.

The Github repo includes a demo.html file that shows this in use for sign in page. From there you can copy and tweak it into what ever shape you’d like.

Difference Between A Human Click And A Trigger Click With jQuery

I was recently working on a page that had some existing transitions that happened when a user clicked on an item. My thought was to periodically trigger a click event that would automate the process some what, allowing me to take advantage of the existing transition code.

jQuery has a nifty method called .trigger that takes care of firing the click event for me. Very handy, but then I quickly realized that I needed to be able to tell the difference between a human click event and a .trigger‘d click event.

Fortunately I wasn’t the only one to have run into this issue and there is a solution described at http://stackoverflow.com/questions/6692031/check-if-event-is-triggered-by-a-human/6692173#6692173. The key is event.originalEvent, here is an example from the StackOverflow post:

$( "#click-me" ).click( function( event ) {
    if ( event.originalEvent === undefined ) {
        alert( 'not human' )
    } else {
        alert( 'human' );
} );

You can also try it out on jsFiddle – http://jsfiddle.net/Uf8Wv/

This appears to be specific to jQuery, which in this case wasn’t a big deal since all of the other code on the page was using jQuery as well. The Event object documentation mentions event.originalEvent, but doesn’t indicate that it can be used in this way.

Is Meteor The Future Of Node.JS Development?

What does the next step in the evolution of Node.js look like? One answer to that question is Meteor. I found their screencast very interesting:

The idea of having a built-in framework that takes care of updates for you, on the fly, is compelling. I also liked the example of being able to work with the MongoDB data right from the client (that also scares me).

I’m not ready to abandon all other web development platforms and move strictly to Meteor, but I’ll definitely be watching it. I’d like to dig deeper into the details of what makes Meteor tick.

Microjs, Long List of Libraries

I don’t recall the last time I’d looked at microjs.com, but I’m quite sure the list of libraries was much smaller back then.

Some of the libraries listed, like Mustache, I’ve seen and played with before. Skimming through the list this morning, most of them are new to me. The number of libraries listed is impressive.

I’m still not sure that I’ll have a use for many of these, I suspect for most sites being able to rely on jQuery (and jQuery plugins) consistently will out weigh trying to save a few bytes here and there. I’m willing to be proven wrong though, which is why one of the reasons I find the microjs list so fascinating.

Do you have a favorite microjs library, or one that you can’t live without?

Javascript Timeline

It seems that having Facebook offer a timeline UI has reignited interest in that format. I’ve seen several Javascript libraries pop up that make generating a timeline UI fairly simple. One that caught my eye is Timeline.

Has anyone whipped up scripts to automatically populate data for Timeline from Subversion or Git repos?

Live Updating a Node.js Web Server

Each time I look at Node.JS the issue of live updating comes up. For PHP it is easy to take live updating for granted. You update your .php files and *poof* your site is running the new code. With the merged web server model of Node.JS that doesn’t happen.

I’m happy to see some folks thinking along these same lines. From Staying up with Node.JS:

To many beginner Node.JS users, a fundamental and immediate apparent disadvantage of writing their web applications with Node.JS lies in the inability to save a file, refresh the browser and see their changes live.

This isn’t just a beginner issue though, it make deploying to production much more complex as well:

The need for seamless code reloads extends into the realm of production deployment as well: one needs to be able to serve new requests with fresh code immediately, without breaking existing ones (such as file uploads or content transfer).

To deal with these issues LearnBoost has developed two projects: distribute and up.

Another option that has been brought up is hotnode, which looks like a fairly simple approach. In general the fewer moving parts the better.

If you are using Node.JS for production services, what approach do you use for deploying updates? Are you doing a load balancer and worker dance (spin up new worker, add it to load balancer pool, drop out an older worker, update it, add it back to the pool) or have you come up with a live update method?