The traveling hermit

AngularJS Missing Directives: Native Form Resets Part 2

2013-08-15T12:00:00.000-04:00

This is a followup to a previous post discussing a directive that supports native form resets. While that directive goes a long way for simplifying form resets with AngularJS, it does have a glaring shortcoming. What if a form utilizes multiple models? AngularJS makes no judgement about this and actually there can be various reasons for why that is beneficial.

The previous solution expected to have one and only one model. In fact it should throw an error if more than one model is passed. Here is the original code from the original reset directive.

To support multiple models in an updated directive lets first make a checklist for what would need to be updated.

A string format to pass in multiple models through the form attribute
Create getter/setters for each model
Create a master copy of each model
Set each model to its respective master copy when the reset event fires

The attribute string format is simple enough since there is an established format for specifying a list, namely comma separated. But since this list is also an HTML attribute, it should include the format supported by lists contained in HTML attributes, namely space separated (think CSS class attributes). This way either format will work if favored by a designer or a developer.

Since the attribute string will be a list, the directive will be dealing with an array of models to iterate over for creating both the getter/setters and the master copies of each model. Also it will iterate over the setters to set the corresponding models to their master copy during a reset event.

And low and behold the result. It works! It would have been a bit awkward if it hadn't.

In the end there was nothing very tricky about it but it can be extremely useful.

NOTE: I borrowed the map function from the AngularJS source since IE 8 does not support Array.prototype.map. Once again the source code proves it's a great place to pick up some tips and tricks.

AngularJS Missing Directives: Focus & Blur Part 2

2013-08-14T11:13:00.001-04:00

In the first part of this series about supporting focus and blur events I elected to follow the template in the AngularJS source code for event directives. This proved to be quite insightful as the AngularJS team just released 1.2.0rc1 which now supports these events natively in the same manner. This means you can just drop in the new version, remove the custom directives and any dependencies on these directives should still work! Check it out for yourself!

But to illustrate this point even further, lets continue with a previous discussion from the first part of this series. Namely the discussion about which adverb should be used for these event directives, "on" or "while". In the first part the directives used the "on" approach for each event. But this doesn't mean we still can't support "while". In fact, we already did in the original example by using both "on" events and storing the state in a scoped variable, focused.

We can extrapolate that concept and create a directive that will do this automatically. There are a few ways as always to skin this cat. We could simply just bind the events independently of the focus and blur directives, but that isn't much fun. Alternatively we can use those directives (no need to reinvent the wheel) and just build on top of them. The later approach will also lead us down a new path which will include learning about a couple of very cool tools. Plus, it's more fun.

NOTE: This approach does have one possible issue: without specifying different scope variables to use between various elements within the same scope, they will of course share the same state indicator which would be very confusing. So, basically dumb in equals dumb out.

Okay, on to the fun! First give it a try so you know I am not full of it.

Boom! Still works. Now lets dig in. The first difference is the new directive myng-focused has replaced both myng-focus and myng-blur on the element. Also, only the scope variable focused is passed now and not an AngularJS expression. Once last warning, remember to specify unique scope variables to track states for different elements unless you want to have a field day tracking down that bug.

Now for the juicy parts but if you need to review how the previous directives work, go take a look here.

The myngFocused directive is basically doing four things.

Getting the scope variable name from the attribute
Removing the attribute (this is important due to number 4)
Sets the attributes for the focus and blur directives
Recompiles the element

Steps 1-3 are fairly straightforward although steps 2 & 3 do introduce $set. The trick here is that if no value is specified, the attribute is removed. Useful for step 4.

Step 4 is the key. Without it, the HTML is updated but AngularJS takes no notice of the new attributes on the element. That is where $compile comes into play. It's a fairly powerful and useful service in the AngularJS world and used quite extensively in the source code. We use it here to force Angular to recompile the element which triggers it to recognize the new directives, myngFocus and myngBlur.

IMPORTANT! This is where removing the directive for myngFocused is crucial. If we omitted this step, when the element is recompiled AngularJS would see that directive and would attempt to initiate it. This would put it into a loop. Bad. It's why nearly all examples only use $compile on children of an element. Consider yourself warned.

And there you go. It should really be apparent now how directives are the building blocks of AngularJS.

Finally, as promised, here is the same directive using the new hotness of 1.2.0rc1. As you can see the directive is identical aside from using the new native focus and blur directives.

AngularJS 1.2.0rc1 Now Supports Focus & Blur Events

2013-08-14T09:26:00.001-04:00

A quick update on a previous post about focus and blur directives. The AngularJS team has released 1.2.0rc1, which among a host of great changes now supports focus and blur events natively.

The best thing is since I used the existing event code from the AngularJS source code as a template for these directives there is no need to change any code that utilized these methods! You will see another example of this in a post that I am editing that was scheduled to be posted later today.

Here is the updated example from my previous post with the only modification being the switch to use the native focus and blur directives in 1.2.0rc1.

Once again using the source code as a guide and a reference has proven to be both enlightening and also a savior since I won't have to make any extensive edits to switch to the native event support in the new release.

AngularJS Missing Directives: Focus & Blur

2013-08-12T10:03:00.000-04:00

After my last post discussing the missing native form reset directive, I was asked what other missing directives there might be. Which is a great question. AngularJS provides so many great directives out of the box, what could it possibly be missing?

Well, lets start with simple user input events. AngularJS 1.1.5 supports the following events as ng-directives:

click
dblclick
mousedown
mouseup
mouseover
mouseout * apparently this one is not documented yet
mousemove
mouseenter
mouseleave
keydown
keyup
keypress

* There is of course also ng-submit, which was mentioned in the last post.

While that list is pretty extensive there are two glaring omissions, namely blur and focus events. Luckily these can be easily added as you will see below.

Since there is nothing uniquely special about these two events compared to the list above, we can use the AngularJS source code as a template for adding two directives to support these events. The bonus for doing that is extrapolating and slightly modifying the code for our goals is quick and painless. Lesson to be learned: always look to the source for tips and guidance.

First, a note discussing this approach. I have read various development threads discussing how a focus and/or a blur directive should work. The main debate seems to boil down to a disagreement between essentially adverbs. Specifically 'on' and 'while'. The latter assigns a state indicator that can be monitored to determine if an element is currently blurred or focused. The former, which is the approach the following example will use, follows the native browser event listeners for firing when an event occurs.

Got it? Good. Lets jump in then. Click on the input element to give it focus and then click outside of it to blur it.

It works, but how? Focusing on the HTML tab we can see the directives are simply passing an AngularJS expression that sets the scope variable focused to either true or false if the input element is focused or blurred respectively.

Looking at the directive code on the JavaScript tab, the first thing you will notice is rather than repeating identical code for each directive I use an angular.forEach to loop through both events and dynamically create a directive for each one.

Again, there is nothing very special about the code in this directive. In fact anything of interest was discussed in the last post (review here if you need to). Basically the directive will evaluate whatever the AngularJS expression is when the event fires.

NOTE: If you want to do something only when an element has focus (or blurred) you would need to use both directives to monitor the element as this example does.

UPDATE (2013-08-13): AngularJS 1.2.0rc1 now includes blur and focus events! Wooohoooo! Check out the follow-up post to see how it compares.

UPDATE (2013-8-26): Part 2 - Supporting the 'while' adverb through a directive.

AngularJS Missing Directives: Native Form Resets

2013-08-09T15:20:00.000-04:00

If you haven't played around with AngularJS yet, I highly advise you give it a try. There are plenty of introductory articles and videos out there that will whet your appetite and get you up and running (here, here and here to name a few). Go ahead, go play. This post will still be here later when you need it. And you will need it.

Okay, for everyone else, after the excitement and wonderment of two-way binding begins to wane you will start to notice some of the peculiarities about AngularJS. And then after that you will start to wonder why it doesn't do some of the things you would expect to it to do (the simple answer is generally the great dev team working on AngularJS hasn't gotten around to it yet). I refer to these missing functionalities as missing directives. Which means we can write our own directives to add any desired functionality!

Lets jump in and take a look at form resets. If you have been developing for the web for any period of time you know that there is a native INPUT element type that will reset all form input elements (including selects, textareas, etc.) to their original values. The following fiddle has a simple form that includes a native reset button and an Angular controller to initialize the model ("myModel").

Try editing the fields and hitting reset.

Wait. What happened? The expected behavior is for the form to reset the values of the input fields ('foo' and 'bar') to their original values ('Boop' and 'Beep' respectively). But as you can see this does not happen. What gives?

First, two underlying points:

Since AngularJS forms do not use the value attribute to specify original values for forms, the native form elements therefore have no initial values outside of the AngularJS world.
AngularJS forms do not understand which model is being used to manage the two-way binding for the input fields (this example uses 'myModel').

Second, you might be wondering why this is how AngularJS behaves. I did and so at a recent AngularJS meetup I asked Igor Minar, a core Google Angular developer, why it hadn't been implemented and he responded that the team just hadn't done it yet.

So, that leads to the question of what would be needed to make it work. Interestingly enough it's not a difficult thing to do once you have a firm understanding of AngularJS and its concept of directives. If you don't know what a directive is, this should be a good example.

Based on the points mentioned above, the directive would need to be:

aware of which model is represented by the form
what the original input element values are (the original state of the model)
capturing the native form reset event and preventing it from reseting the inputs to no values
restoring the original values to the form input elements from the model on the form reset event

Since directives can be attributes of an element, the directive can be an attribute of the form element itself similar to the ngSubmit directive. We then can use the attribute value to pass in the model for the form. This placement will also allow the capture of the native form reset event.

Lets preview with the finished directive before we dissect it. Once again, edit the form and hit the reset button.

Whew! It works.

If you notice on the HTML tab, the directive is invoked by applying an attribute to the form element with the value set to the model. The directive is then called and executes the returned function.

From the JavaScript tab we can see how the directive accomplishes our goals.

But first, some background on some of the key pieces used in the directive:

$parse - since you can't pass the model object itself through the attribute (at least without creating an isolated scope), you can use this handy dandy service to get the model object from the attribute value string
angular.copy - creates a deep copy of an object or an array
scope.$apply - executes the model assignment in an AngularJS context
$setPristine - used for setting the form to a 'pristine' state indication

We can see the first thing the directive linking function does is to create a getter/setter for the passed model and then it creates a deep copy of this model. This deep copy will be the value that the model is reset to on any form reset events. Since $parse will only return an object with method assign if it is a model, we can use that to error check the input from the attribute.

The next step binds the custom reset handler to the native form reset event. When the native form reset event is fired, the custom reset handler prevents the default action (resetting the input elements to their non-existent value attributes), sets the model to the original copied state and finally updates the form state to indicate it is pristine.

That's it. That's all it takes. Nothing more. If you haven't realized it yet, while two-way binding is magical, directives are the building blocks of AngularJS.

The Lion Who Was An Insomniac

2012-04-26T15:07:00.000-04:00

Sometime over the last couple weeks my MacBook Pro running OS X Lion (10.7.3) decided it no longer needed to sleep. While peculiar, I didn't worry about it since I had just installed some software recently and figured that might be the reason for my laptop's new found bout of insomnia. Well, two weeks later and my poor little guy hadn't slept a wink.

Everyday I'd close the lid and go about my business only to find it still purring along waiting for my return. While I do love when my pets are excited to see me, this seemed to be a bit of a waste. So, like any good techie, I backtracked everything I had done over the last two weeks to see what could be the pea in my laptop's mattress. I checked the software I installed (nope), the updates I applied (nope), the accessories I had plugged in (nope), the second monitor (nope), on and on but nothing seemed to be the thorn in his side.

Now, I could have just restarted my computer to see if that resolved the issue. Two things prevented me from doing this:
1. I am not on Windows.
2. Where is the fun in that?

So, digging into my techie war chest it was time to hit the old Terminal and get under the hood. First things first, pmset is a godsend for this exact issue. If something is keeping your mac awake, BAM! you know what it is. Why I didn't just do this from the beginning I don't know aside from maybe I am a masochist.

$ pmset -g assertions
4/25/12 11:35:13 PM EDT 
Assertion status system-wide:
   ChargeInhibit                           0
   PreventUserIdleDisplaySleep             0
   PreventUserIdleSystemSleep              1
   NoRealPowerSources_debug                0
   CPUBoundAssertion                       0
   EnableIdleSleep                         1
   PreventSystemSleep                      1
   DisableInflow                           0
   DisableLowPowerBatteryWarnings          0
   ExternalMedia                           0

Listed by owning process:
  pid 50: [0x0000012c00000032] PreventSystemSleep named: "org.cups.cupsd"

The last line in the output is the smoking gun. A cupsd process was preventing my laptop from taking a much deserved nap.

Who, what and why? CUPS allows macs to act as print servers essentially allowing the computer to queue up print jobs. So, more than likely there was a stalled print job that was keeping the process open, waiting to complete, before allowing the system to go to sleep (which makes logical sense to prevent a print job from being interrupted).

I opened up my print queue from the preferences pane and voila, a stalled job was sitting there mocking me. After quickly killing this unruly guest and checking pmset again:

$ pmset -g assertions
4/25/12 11:37:05 PM EDT 
Assertion status system-wide:
   ChargeInhibit                           0
   PreventUserIdleDisplaySleep             0
   PreventUserIdleSystemSleep              0
   NoRealPowerSources_debug                0
   CPUBoundAssertion                       0
   EnableIdleSleep                         1
   PreventSystemSleep                      0
   DisableInflow                           0
   DisableLowPowerBatteryWarnings          0
   ExternalMedia                           0

No more processes or assertion statuses indicating the system was preventing itself from sleeping. So, with baited breath I closed the lid and waited a couple seconds...pure silence. No purring, no whirling, just silence. My laptop had finally been cured of it's insomnia.

The problem with document.cookie

2012-01-11T11:35:00.004-05:00

Accessing/modifying HTTP cookies with JavaScript is possible through the document.cookie interface which permits two operations: retrieving all of the cookies that are accessible from the current document domain and path; and setting/updating an individual cookie. This interface is limited and can cause unexpected behavior if used without a thorough understanding of the interface and the W3C spec for HTTP cookies.

Browser access/management of cookies is specified by the RFC 2109 spec which states:

Cookie uniqueness is controlled by the combination of the cookie's name, domain, and path.
When setting a cookie with a specified domain, it must begin with a dot (.jasoncust.com).
The domain will default to the host domain's location (www.jasoncust.com).
The path will default to host domain's path up to but not including the right most '/'.
Cookie access is restricted to the cookie path being a prefix of the document's full path (since paths were originally directory structures, cookies were accessible only from subdirectories).
Similarly, cookie access is restricted to the cookie domain being a suffix of the document's domain. Note this is only true for cookie domains starting with the required dot (.jasoncust.com). If a cookie domain was set by default to say 'jasoncust.com', the cookie would not be accessible from any subdomains.

That last two points could use a little more elaboration as people tend to gloss over them. Regarding just domains (assuming all cookie paths are set to '/'), if your document location is 'www.jasoncust.com', only cookies with domains set to either 'www.jasoncust.com' or '.jasoncust.com' are accessible. Any other subdomains including 'jasoncust.com' are not accessible. Combining paths with domains, if the document location is 'www.jasoncust.com/some/path/', only cookies with a domain of 'www.jasoncust.com' (or '.jasoncust.com') and paths of '/', '/some' or '/some/path' are accessible.

Retrieving cookie values is easy enough through the interface, simply go to www.nytimes.com, open a console and then enter document.cookie to see a string containing all of the cookies accessible from the current host domain and path. It will look something like:

> document.cookie
"RMID=0734175263b54f0d07f7801a; adxcs=s*2b53d=0:1; adxcl=t*2b53d=4f32014f:1326254071|ti=4f32014f:1326254071"

The format of the returned string is name=value with multiple cookies joined by a semicolon + space ('; '). So in order to get a particular cookie's value, a bit of parsing is required. One major caveat is only the cookie's value is returned. The cookie's path, domain, secure setting, and the expiration/max-age are not returned through the interface which can be problematic.

Why is this problematic? Lets walk through an example, albeit a trivial one, to illuminate this issue. Starting with two cookies:

name	value	domain	path
uuid	19691231	.nytimes.com	/
xid	42	.nytimes.com	/

If the document location is 'www.nytimes.com', then the returned cookies will be:

> document.cookie
"uuid=19691231; xid=42"

To set or update a cookie a string representing the cookie is assigned to document.cookie. For example, to update the 'xid' cookie to 'lorum', a first approach might look like:

> document.cookie = "xid=lorum";

Checking the cookie value returns:

> document.cookie
"uuid=19691231; xid=42; xid=lorum"

What happened? There are now two cookies with the name 'xid'. Looking at the table again we see why this happened:

name	value	domain	path
uuid	19691231	.nytimes.com	/
xid	42	.nytimes.com	/
xid	lorum	www.nytimes.com	/

The two cookies while sharing the same name have a different subdomain. Since the domain wasn't specified in the assignment, it defaulted to the host domain ('www.nytimes.com') in the example. So in order to update an existing cookie the same domain and path originally assigned to the cookie must be used. However no meta data is returned via document.cookie. This means any cookies that are to be manipulated by JavaScript need to have a set domain and path (probably the root domain and path) that both the server and the JavaScript code use when setting cookies. This also applies to any optional cookie settings such as the expiration and the secure flag.

Assuming for some reason it was desirable to have two cookies with the same name but a different subdomain and/or path, how do you know which cookie is what? Since document.cookies does not return the domain or path of the cookies, there is no way to tell. This may seem trivial, but what if an operation needed to clear or overwrite the 'xid' cookie with the value 'lorum'? How would it do so?

tl;dr

When using the document.cookie interface, the lack of any meta data about the cookies returned can cause issues if not properly designed around. Two key points to remember are:

Cookies with the same name but different subdomains and/or paths are allowed but this meta information is not returned by the interface. So there is no way to tell which cookie value is for what domain/path.
When updating a cookie, the original cookie is replaced if the name/domain/path match. If they don't match, a new cookie with the same name but different domain/path will be created. Also, when replacing a cookie, any other meta data is overwritten even if not explicitly stated.

Should there be an update to the interface for ECMA5? I'm not positive since cookies should only be used if the data needs to be included in every request to/from the server. Otherwise newer APIs such as the Storage APIs probably are a better design choice and don't have this issue. Still, it would be a nice addition to have access to the meta data for each cookie when you do need to work with them from both the client and the server.

IIFEs, Closures, Unit Testing and Privacy

2012-01-06T21:56:00.001-05:00

One of the toughest decisions within JavaScript code design is the choice between testability and privacy. It's definitely one of the most frustrating aspects of JavaScript for me personally (and that is definitely saying something). This choice can lead to a less than ideal design if unit testing is important to you... which it should be.

Lets start with an example to see how this choice can affect design. We are going to create an object that will represent a basic parallelogram that requires as input the measurements of two adjacent sides and an angle. Assuming the second measurement is the base, the object will internally compute the height and area of the parallelogram from the inputs on object creation exposing the original measurements and the two new computed values.

A typical design pattern for an object in JavaScript is to use an IIFE (Immediately Invoked Function Expression) to create a closure so we don't pollute the global namespace. A simple design (we aren't concerning ourselves with optimizations for this discussion) could look like:

(function( win, undef ) {
  // Global namespace object name
  var objName = 'myAwesomeParallelogram';

  // Compute the height of a parallelogram where length is the adjacent side
  // of the base and the angle is acute in radians length * sin(angle)
  function height( length, angle ) {
    return length * Math.sin( Math.min( angle, 180 - angle ) * Math.PI/180 );
  }

  // Compute the area of a parallelogram b * h
  function area( base, height ) {
    return base * height;
  }

  var obj = function( sideA, sideB, angle ) {
    if ( angle < 0 || angle > 180 ) {
      throw new SyntaxError('Angle is not between 0 and 180 degrees');
    }

    this.sideA = sideA;
    this.sideB = sideB;
    this.angle = angle;

    this.height = height( sideA, angle );
    this.area = area( sideB, this.height );
  };

  win[ objName ] = obj;
})(window);

Sample usage:

> var p = new myAwesomeParallelagram( 15, 12, 45);
undefined
> p.area
127.27922061357853
> p.height
10.606601717798211

Great! But aside from testing the object itself, how would we be able to test if height or area work correctly? How would we test the code flow? We could redesign our code to expose these functions and we could likewise include some logging calls to console to show the flow. But, is this what we want in production? Is it necessary?

There have been a few clever ways of handling this dilemma (I know I rolled a few of my own over the years) but Mr. Douglas Crockford (the author of JavaScript: The Good Parts and JSLint) has just released a new tool to help end the Sophie's choice between good design/security and testability. It's called JSDev and it allows you to include specially formated comments that can be transformed into development unit testing code and then removed through normal minification processes.

To use the new tool we first need to download the raw file (or use git) and compile it locally for a CLI.

$ curl 'https://raw.github.com/douglascrockford/JSDev/master/jsdev.c' -o jsdev.c && gcc jsdev.c -o jsdev

Now that we have a compiled version of jsdev we can edit our original object code to include development only code for unit testing.

(function( win, undef ) {
  // Global namespace object name
  var objName = 'myAwesomeParallelogram';

  // Compute the height of a parallelogram where length is the adjacent side
  // of the base and the angle is acute in radians length * sin(angle)
  function height( length, angle ) {
    return length * Math.sin( Math.min( angle, 180 - angle ) * Math.PI/180 );
  }

  // Compute the area of a parallelogram b * h
  function area( base, height ) {
    return base * height;
  }

  var obj = function( sideA, sideB, angle ) {
    if ( angle < 0 || angle > 180 ) {
      throw new SyntaxError('Angle is not between 0 and 180 degrees');
    }

    this.sideA = sideA;
    this.sideB = sideB;
    this.angle = angle;

    this.height = height( sideA, angle );
    this.area = area( sideB, this.height );
  };

  // JSDev code comments
  /*dev
    obj.height = height;
    obj.area = area;
  */
 
  win[ objName ] = obj;
})(window);

Now if we process it through or handy dandy new tool:

$ ./jsdev dev -comment "Development Version" < input.js > output-dev.js

The new file, output-dev.js looks like:

// Development Version
(function( win, undef ) {
  // Global namespace object name
  var objName = 'myAwesomeParallelogram';

  // Compute the height of a parallelogram where length is the adjacent side
  // of the base and the angle is acute in radians length * sin(angle)
  function height( length, angle ) {
    return length * Math.sin( Math.min( angle, 180 - angle ) * Math.PI/180 );
  }

  // Compute the area of a parallelogram b * h
  function area( base, height ) {
    return base * height;
  }

  var obj = function( sideA, sideB, angle ) {
    if ( angle < 0 || angle > 180 ) {
      throw new SyntaxError('Angle is not between 0 and 180 degrees');
    }

    this.sideA = sideA;
    this.sideB = sideB;
    this.angle = angle;

    this.height = height( sideA, angle );
    this.area = area( sideB, this.height );
  };

  // JSDev code comments
  {
    obj.height = height;
    obj.area = area;
  }
 
  win[ objName ] = obj;
})(window);

Before was continue there are a few things to notice between the input files, the command and the output file:

The comment from the CLI is now a header comment in the output file. This is handy to always include the type of output file in the file.
The other arguments for the CLI specify which multi line comments that match the format /*<argument> <code>*/ to include in the output file. This is handy if you have different testing levels or needs. Note that there cannot be a space between the opening comment notation and the argument.
Single line comment notations ("//") are unaffected by the jsdev tool as well as multi line comments that don't match the specified format above.

Now lets see if we can access our development code private functions using a console.

> myAwesomeParallelogram.area
  function area( base, height ) {
    return base * height;
  }
> myAwesomeParallelogram.height
  function height( length, angle ) {
    return length * Math.sin( Math.min( angle, 180 - angle ) * Math.PI/180 );
  }

And when we minify the original code we get this (using JSMin for this example):

(function(win,undef){var objName='myAwesomeParallelogram';function height(length,angle){return length*Math.sin(Math.min(angle,180-angle)*Math.PI/180);}
function area(base,height){return base*height;}
var obj=function(sideA,sideB,angle){if(angle<0||angle>180){throw new SyntaxError('Angle is not between 0 and 180 degrees');}
this.sideA=sideA;this.sideB=sideB;this.angle=angle;this.height=height(sideA,angle);this.area=area(sideB,this.height);};win[objName]=obj;})(window);

We no longer need to sacrifice our design and security for testability. Is it the most elegant solution? Maybe not, but it works well and can be easily added to a build process for testing and will not impact your current build process for production.

For more information and more usage info, please refer to the README file on github.

Chrome, Prerender and Site Stats

2012-01-05T20:24:00.003-05:00

As Chrome keeps inching towards market dominance, it is definitely helping to move the web forward and speeding it up along the way. One of the interesting ways they have helped speed up the web (as of Chrome 13) is through the use of "prerendering". Basically, prerendering will begin to download a page that is linked from the current page via link declarations on the current page like so:

<link rel="prerender" href="/someOtherAwesomeness.html">
<link rel="prerender" href="http://anotherAwesome.website.com">

These pages will now be downloaded in the background while the user is currently on the page theses are linked from. When/if the user follows a link to one of those pages, it will feel nearly instantaneous to the user since the page is already loaded.

Pretty interesting trick on Google's part to make Chrome feel faster. As one can imagine, to avoid unnecessary overhead to websites linked from one page, discretion should be practiced in selecting what if any pages should be prerendered from the current page being viewed. Easy candidates are next-type pages and other links that have a high click through rate.

How does this impact site stats? It depends on whether you can truly count a page view if a page was prerendered but then never seen? If you just care about inflated numbers, then this is probably a welcome exploit to increasing views across a larger number of pages even though a person truly only viewed one page. But, if you do care about them for being able to understand user interaction with your content, this could skew your numbers in a horrible way. These false views will increase the denominator in your analytics formulas without a chance of increase to the numerator, thus making your impact for user actions on those pages seem less effective.

The good news is that individual sites will have to enable this in their code for now and hence adoption will be slow. But with Google search results pages utilizing this feature already and the Chrome Beta released today enabling it from the omnibox, these false views will quickly start to accumulate.

So how do you prevent that from happening? Depends on how you determine page views.

If you use Google Analytics, you are already covered with the 2011-07 release (July 26, 2011) as it uses the Page Visibility API (but only with the webkit prefix, hopefully they keep up with other vendor releases as well).

If not, you can roll your own by using the Page Visibility API yourself. Continuing on form the example from my previous post, we can build a simple check for determining whether or not a page has been prerendered:

var visibilityAPI = ( typeof document.hidden != 'undefined' && { 'visibilitystate': 'visibilitystate', 'visibilitychange': 'visibilitychange' } ) || ( typeof document.webkitHidden != 'undefined' && { 'visibilitystate': 'webkitvisibilitystate', 'visibilitychange': 'webkitvisibilitychange' } ) || ( typeof document.mozHidden != 'undefined' && { 'visibilitystate': 'mozvisibilitystate', 'visibilitychange': 'mozvisibilitychange' } ) || ( typeof document.msHidden != 'undefined' && { 'hidden': 'msHidden', 'visibilitystate': 'msvisibilitystate', 'visibilitychange': 'msvisibilitychange' } );

(function pageVisibilityChanged() {
    if ( document[ visibilityAPI.visibilitystate ] === "prerender" ) {
        // Application has been prerendered
        // Add listener to fire when page is no longer in prerender state
        document.addEventListener( visibilityAPI.visibilitychange, pageVisibilityChanged, false );
    }
    else {
        // Page is no longer in presender state
        // A page view can be counted now
        document.removeEventListener( visibilityAPI.visibilitychange, pageVisibilityChanged, false );
    }
})();

There is still one problem with this example: the person could still never see your site though even after the follow one of the links. For example, they could open the page in a new tab behind their current one and then close it before they view it. Yes, this is probably an edge case, but you could easily expand the previous example to only count when the page is truly viewed.

var visibilityAPI = ( typeof document.hidden != 'undefined' && { 'hidden': 'hidden', 'visibilitystate': 'visibilitystate', 'visibilitychange': 'visibilitychange' } ) || ( typeof document.webkitHidden != 'undefined' && { 'hidden': 'webkitHidden', 'visibilitystate': 'webkitvisibilitystate', 'visibilitychange': 'webkitvisibilitychange' } ) || ( typeof document.mozHidden != 'undefined' && { 'hidden': 'mozHidden', 'visibilitystate': 'mozvisibilitystate', 'visibilitychange': 'mozvisibilitychange' } ) || ( typeof document.msHidden != 'undefined' && { 'hidden': 'msHidden', 'visibilitystate': 'msvisibilitystate', 'visibilitychange': 'msvisibilitychange' } );

(function pageVisibilityChanged() {
    if ( document[ visibilityAPI.visibilitystate ] === "prerender" ) {
        // Application has been prerendered
        // Add listener to fire when page is no longer in prerender state
        document.addEventListener( visibilityAPI.visibilitychange, pageVisibilityChanged, false );
    }
    else if ( !document[ visibilityAPI.hidden ] ) {
        // Page is no longer in presender state or hidden
        // A true page view can be counted now
        document.removeEventListener( visibilityAPI.visibilitychange, pageVisibilityChanged, false );
    }
})();

Now you are one small step closer to more accurate reporting!

Can you see me? Can you see me now?

2012-01-01T14:49:00.001-05:00

What is the Page Visibility API and what is it good for? It is a JavaScript API that allows developers to check if their page/application is visible and to attach an event listener for visibility state changes. What is that useful for? Well, lets discuss web applications in general for a moment to see how and why it is something developers should be concerned with.

Every window or tab a user opens for services like Google+, Facebook, Gmail, Twitter, and Reddit increases the resource requirement for each application to poll, update, animate and perform other intensive operations. The big question is do end-users really have to pay the resource costs for each of these web applications?

To answer this question, we can ask a few more questions about web applications in general:

Do they need to constantly run?
What operations need to be run and at what rate?
Can these operation rates be altered based on interaction types/levels?
What does user interaction entail?

First, let me state this is not a blanket solution nor an advocacy that all applications should be handled in this manner. That said, developers should think about not only how their applications are actively used but also what they need to do when not in active use.

Second, lets use a simple example to provide a context for pondering these questions. A basic news or message feed would work well enough. It is based around a data stream that is updated both asynchronously and irregularly so some form of polling and updating the stream with new items is required. Also, dynamic animation showing new items will be used to display these updates to an end-user.

Finally, the first three questions are in one way or another predicated on the answer for the fourth so we will begin there.

What does user interaction entail? The obvious cases are when a user is interacting with the application using an input device (mouse, keyboard, mic, camera, finger, stylus, etc.). But can someone use an application without interacting with it directly? What if it is open and updating with new items that the user reads as the show up on the screen? So, the commonality amongst all of these use cases for our application is that the user needs to see the application in order to use it.

Thinking about that a bit more generally, consider all of the tabs a user has open at any given moment. If only one is visible at a time, why do the rest need to do anything at all (aside from pending operations a user has queued up)? Shouldn't the visible tab be the sole active window?

So a more general question arises: if a user cannot see our application, does it need to run if at all?

For our application at least, this makes perfect sense. Why waste resources continuously polling and updating (especially with animations) if the user can't see it? Couldn't we fall back to less frequent polling with no special effects for updating the page? Seems reasonable with little to no user impact. In fact, since the user can't see the page, how would they know.

The only problem is how do we know if the user can see the page? Well, thanks to the Page Visibility API proposal, we can do this today (through browser prefixes at the moment). The API is available with a webkit prefix in Chrome 13+, a ms prefix in IE10+ and a moz prefix in FF10+.

For the example below, using the non-prefix version (which will be the standard) and only checking if the document is visible or not.

function pageVisibilityChanged() {
  if ( document.hidden ) {
    // Application is not visible to the user
    // Adjust polling rates and display update for inactive display mode
  }
  else {
    // Application is visible to the user
    // Adjust polling rates and display update for active display mode
  }
}

document.addEventListener( 'visibilitychange', pageVisibilityChanged, false );

That's it. Really. That's all you need to do to be a great application neighbor and also help reduce energy use by reducing unnecessary resource use by your application.

UPDATE: Here is a browser prefix version for those who want to play today with Chrome 13+, IE10+ and FF10+ and any browser that implements the standard.

var visibilityAPI = ( typeof document.hidden != 'undefined' && { 'hidden': 'hidden', 'visibilitychange': 'visibilitychange' } ) || ( typeof document.webkitHidden != 'undefined' && { 'hidden': 'webkitHidden', 'visibilitychange': 'webkitvisibilitychange' } ) || ( typeof document.mozHidden != 'undefined' && { 'hidden': 'mozHidden', 'visibilitychange': 'mozvisibilitychange' } ) || ( typeof document.msHidden != 'undefined' && { 'hidden': 'msHidden', 'visibilitychange': 'msvisibilitychange' } );

function pageVisibilityChanged() {
  if ( document[ visibilityAPI.hidden ] ) {
    // Application is not visible to the user
    // Adjust polling rates and display update for inactive display mode
  }
  else {
    // Application is visible to the user
    // Adjust polling rates and display update for active display mode
  }
}

document.addEventListener( visibilityAPI.visibilitychange, pageVisibilityChanged, false );

Bash sort... what the hell is up with tab separators?

2011-12-29T22:11:00.002-05:00

UPDATE: I have updated the sort Wiki page to include an example for tab separated sorting.

In the world of Unix shells there exists a very common one called Bash. And within the Bash shell there are a whole host of commands that can be used both on the command line and in a script file. These commands run the gamut for what they can do, but there is a small subset that most people find their daily lives centered around when it comes to programming or hacking out solutions such as sed, cut, and sort.

Fairly common inputs to these commands are delimited-separated values such as CSVs and TSVs. Thankfully almost every command that you would use for these formats allows you to specify the delimiter.

For instance, say we have a TSV file called phonebook that contains the name and number for each contact:

$ cat phonebook 
Smith, Brett 555-4321
Doe, John 555-1234
Doe, Jane 555-3214
Avery, Cory 555-4132
Fogarty, Suzie 555-2314

With cut you could get just the names if you wanted:

$ cut -f1 phonebook 
Smith, Brett
Doe, John
Doe, Jane
Avery, Cory
Fogarty, Suzie

How did it know what the delimiter was? Luckily with cut the default delimiter is the tab character. What if it's not though? Looking at the man page for cut gives us:

$ man cut
...
     -d delim
             Use delim as the field delimiter character instead of the tab character.
...

So, say you wanted just the last name for everyone. Well, you can pipe the output from the first command to a second command to do just that! The only difference is now we are going to specify the delimiter to be a comma for the second command.

$ cut -f1 phonebook | cut -f1 -d ','
Smith
Doe
Doe
Avery
Fogarty

Nice! Now, lets check out sort. First, lets sort our phonebook by last name:

$ sort -k1,1 phonebook 
Avery, Cory 555-4132
Doe, Jane 555-3214
Doe, John 555-1234
Fogarty, Suzie 555-2314
Smith, Brett 555-4321

That works well enough. Now lets sort by phone numbers:

$ sort -k2,2 phonebook 
Smith, Brett 555-4321
Avery, Cory 555-4132
Doe, Jane 555-3214
Doe, John 555-1234
Fogarty, Suzie 555-2314

Well... that's not right. It sorted by first name instead. Hmmmmm. Looking at the man page we see:

$ man sort
...
       -t, --field-separator=SEP
              use SEP instead of non-blank to blank transition
...

OK, lets add our trusty tab character:

$ sort -k2,2 -t '\t' phonebook 
sort: multi-character tab `\\t'

Uhhhhh... multi-character? Looks like sort doesn't interpret '\t' as a tab character, but instead a literal '\' and 't'. In another way:

$ echo -n '\t' | hexdump -c
0000000   \   t                                                        
0000002

So, how do we set the separator to be a tab character? The beginner's bash guide provides some guidance on that:

3.3.5. ANSI-C quoting

Words in the form "$'STRING'" are treated in a special way. The word expands to a string, with backslash-escaped characters replaced as specified by the ANSI-C standard. Backslash escape sequences can be found in the Bash documentation.

Using our echo example again:

$ echo -n $'\t' | hexdump -c
0000000  \t                                                            
0000001

Yup, one character. Trying out phone number sort again:

$ sort -k2,2 -t $'\t' phonebook 
Doe, John 555-1234
Fogarty, Suzie 555-2314
Doe, Jane 555-3214
Avery, Cory 555-4132
Smith, Brett 555-4321

BINGO! Now we are truly sorting on the second column.

tl;dr

Turns out sort is similar to echo in that by default escaped characters are interpreted as two character literals rather than the intended escaped character. While echo -e does provide a means to do so, sort does not. So we must use the ANSI-C quoting (or some other means).

Robot Chicken - Star Wars Episode III

2011-07-09T15:59:00.000-04:00

Here we go again. I really can not get enough of these guys. I won't break it down this time. Just sit back and enjoy as Palpatine looks back on his life: full video at adultswim.com.

Kindle for the web!

2010-09-29T16:23:00.000-04:00

Amazon has rolled out a new feature that allows people more easily preview a book online, but more importantly to anyone who has a blog, a very easy way to embed a preview of their favorite books into their blog. Pretty nifty if you ask me.

For instance, I just finished this book by Daniel Pink, 'Drive: The Surprising Truth About What Motivates Us'. And I have to say, it was an incredible read that provided an invaluable background firmly rooted in a variety of studies and academic research. I have already been working on various ways of employing intrinsic motivation at my work, but this has really helped to focus those plans and to create convincing arguments for why we should embrace this type of approach.

Now with this new Kindle preview, I can embed a preview on this blog for the book, so you can see how it works!

Robot Chicken - Star Wars Episode II

2010-05-11T09:41:00.001-04:00

Seth Green and Matt Senreich are back at it again with their take on the Star Wars Universe. They definitely take a similar angle on how I looked at the conclusion of the original trilogy: what about the rest of the Galactic Empire? How did blowing up the Death Star again finally defeat the whole Empire? Well, it's in the rules of course.

My absolute favorite skit is Palpatine's trip. I completely empathize with him in his traveling woes.

Lost bag: check
Wearing ridiculous clothing while waiting for your bag to be found: check
Spilling a drink in your lap because of a shoddy tray table: check

Once again, you can watch the full video at adultswim.com.

Robot Chicken - Star Wars

2010-05-02T15:39:00.003-04:00

Hopefully most of you have seen this many times over by now, but this treatment of the Star Wars movies still cracks me up no matter how often I watch it.

My absolute two favorite skits are the Emperor talking to Darth Vader on the phone and what really happened with Ponda Baba in the Cantina scene. "But, I'm ambidextrous. See?" Ahahhahahaha :-P

You can check out the full show on adultswim.com.

Passing bash arguments to an alias

2010-04-30T08:06:00.005-04:00

A buddy of mine was trying to figure out why he could only pass $@ to the end of an alias and not somewhere before. His failed attempt looked something like this:

$ alias psgrep='ps wwax | grep $@ | grep -v grep'
$ psgrep Terminal
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
grep: Terminal: No such file or directory

His successful attempt was swapping the two greps as such:

$ alias psgrep='ps wwax | grep -v grep | grep $@'
$ psgrep Terminal
98893   ??  R      0:00.48 /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal -psn_0_3666815

At first glance, this does seem odd, how could it properly interpret $@ in the second by not the first? Well, to answer that question, we first need to ask if it is really doing just that. Is $@ properly interpreted in the second attempt? Lets find out:

$ alias psgrep='echo "ps wwax | grep -v grep | grep [$@]"'
$ psgrep Terminal
ps wwax | grep -v grep | grep [] Terminal

Hmmmm, that definitely does not appear to be the case. So, what about the first attempt then:

$ alias psgrep='echo "ps wwax | grep [$@] | grep -v grep"'
$ psgrep Terminal
ps wwax | grep [] | grep -v grep Terminal

Now that is very enlightening. The error from the first attempt is not from the first grep as it appeared to be, but the second grep. Since grep can take a list of files, it assumed the now appended 'Terminal' argument was another file to search through.

That solves our question of whether or not it is interpreted at all, but not why it doesn't work. Well, it does, but only when it was first assigned to the alias. So, when the set alias command is executed, $@ is interpreted (correctly) as undefined, and therefore the alias is set as such. When the alias is then executed later, $@ has already been interpreted and any arguments are appended to the aliased command. That is why the second attempt appeared to work correctly.

So how would do something like this? One approach would be to use a bash function:

(first a little cleanup from the previous examples)

$ unalias psgrep

(now the actual example)

$ function psgrep() { ps wwax | grep $@ | grep -v grep ; }
$ psgrep Terminal
98893   ??  R      0:01.83 /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal -psn_0_3666815

(finally, to unset the function if you wish)

$ unset psgrep

Enjoy!

UPDATE: In yet another case of RTFM, I decided to read up on the man page for sh. It literally states "There is no mechanism for using arguments in the replacement text. If arguments are needed, a shell function should be used (see FUNCTIONS below)". So, there you go. At least my conclusion was in line with the documentation. :-P

10 steps to running multiple versions of Firefox simultaneously on OS X 10.6

2010-04-24T12:55:00.016-04:00

UPDATE: I have verified this works on OSX 10.4 and 10.5
UPDATE 2: I have verified this works with FF 4.0 as well
UPDATE 3: I have verified this works on OSX 10.7 as well as with FF 5.0+ (and the auto updating to new versions)

When I need to debug web apps in multiple versions of Firefox on a Mac, a major hurdle is not being able to concurrently run more than one version from the Applications folder. Simply adding the different versions under different names to the folder doesn't work. The main issue in doing so is the various versions will share the same profile directory which is a big no-no. The problems range from constant messages about upgrades to incompatible plugins and extensions, but most importantly, not actually being able to run them simultaneously.

So, off to the alter of the sage of search I went to figure out how to get around this. I quickly found a few ways to achieve this goal, all of which are great if they meet your individual needs. For mine, I tried both John Resig's method (of the jQuery fame) and Devon Govet's slightly more involved method. While they are essentially the same, I prefer Devon's approach since the corresponding profiles are auto loaded.

Why would you want to have the profiles auto loaded? Without autoloading, every time you launch a version of Firefox, it will prompt you to select the profile you want to use before launching the browser. Seems simple enough, but one caveat is a profile currently in use by one version cannot be used by another version (there are some other issues with sharing profiles across versions as well). So you would need to have as many profiles for as many versions that you wish to run simultaneously. For example, since I am running three versions of Firefox, I would need three profiles.

Again this seems simple enough. The main issue with selecting a profile every time a different version is launched (aside from being easily annoyed by popups) is installing add-ons like Firebug (an essential for debugging web apps). Firebug is version dependent upon the version of Firefox it is installed. When you install an add-on, Firefox installs (at least some) dependent files for the add-on in the profile directory. Essentially this means you must always use the same profile for the same version of Firefox or risk screwing it up.

Once more, seems simple enough. Name your profiles to match the versions of Firefox they are to be used with. Then when you launch a version and are prompted to select a profile, just select the corresponding profile. Up to this point, there is no significant difference between the methods suggested by John and Devon, however this is where John's approach ends and Devon continues a step further to automate the selection.

What is the advantage for John's approach? Either the profile prompt is not a big deal for you or you have a need to have multiple profiles per version of Firefox. However, if you only plan to have one profile per version, why waste the time (and add the risk of error) selecting a profile every time you launch the browser? For me this was the case, and is the main reason I prefer Devon's approach.

Now we finally get to the HOW do you do all of this.

HOW TO

Note 1: For most of the steps, you could do them from either a Finder window or from a Terminal screen. One particular step will require you to use Terminal to enter some commands. Therefore I will only include Terminal instructions since you will need to repeat some steps to get to the point where you would need to execute the commands if you used Finder.
Note 2: This tutorial assumes a fresh install of all versions of Firefox. If you are using an existing installation of one version of Firefox, ignore step two for the existing version installed only. Also, you can not simply rename the default profile as on of the version specific profiles. The underlying profile directory associated with the default profile will still be default and therefore initially be used automatically by all other versions when first loaded. I haven't tested this yet, but I believe you should be able to create the new version specific profile, copy the contents from the default directory to the new one and then remove the default profile in both the Profile Manager and the profiles folder.
Note 3: Proceed at your own discretion.

Say you wanted to run the latest versions of Firefox 3.0, 3.5 and 3.6. First download them from mozilla.org:

Part 1

Setting up Firefox to run multiple versions simultaneously

1. Open a Terminal screen (if you are stumped on this step, you might want to reconsider continuing on until you have familiarized yourself with terminal commands in general)

2. Install Firefox into the Applications folder as usual (or wherever you prefer to put it but I will use the Applications folder as the installed directory)

3. Go to the Applications folder within Terminal

$ cd /Applications

4. Rename Firefox to Firefox3.0 (or whatever you prefer)

$ mv Firefox.app Firefox3.0.app

5. IMPORTANT: Launch the renamed Firefox from the Applications folder and then quit once it is fully loaded

6. Go to the Firefox application contents folder in Terminal

$ cd Firefox3.0.app/Contents/MacOS

7. Add the profile for this version (save time and add them all now)

$ ./firefox-bin -Profilemanager

This command should launch the following dialog box:

- Click "Create Profile" and name your profile something unique per version (for example "Firefox3.0")
- Once you have added your profiles, click "Exit"

Part 2 (optional)

Setting up Firefox to auto select the correct profile on launch

8. Copy the existing firefox-bin to a new file (for example "firefox-bin_3_0")

$ cp firefox-bin firefox-bin_3_0

9. Edit firefox-bin to select the profile that was created for this version ("Firefox3.0")

$ echo -e '#!/bin/bash\n/Applications/Firefox3.0.app/Contents/MacOS/firefox-bin_3_0 -P Firefox3.0 &' > firefox-bin

10. You're done! Now launch Firefox3.0 from the Applications folder and save to dock if you wish.

Repeat these steps for each version (3.5 and 3.6 in this example) noting to change the names to something corresponding to the version you want to install in the appropriate steps.

Enjoy!