I’m always looking for ways to improve my javascript development and after a few weeks of playing, Javascript MVC test looks like it might be one the best tools yet.

We all know the power of testing our code.  A proper suite of unit tests can be among a projects most valuable assets.  They can ensure against the regressions rampant in rapid application development cycles that may not have adequate opportunities for proper QA.  Most importantly, when coupled with continuous integration tools, a comprehensive test suite catches many bugs close to when they are written and when they are easiest to correct.

Historically, testing javascript hasn’t been the most useful or productive of tasks.  The type of data manipulation, object inheritance and communication most conducive to unit testing has been minimized in most javascript applications.  Instead, most javascript is highly event driven and is often loosely tied to any specific server side data model.  Test MVC stands to provide a powerful testing framework for just those tasks we normally use javascript for.

Key Features

• Cross browser¹ support for typical DOM events, like keypress, click, submit, blur, and focus
• Simulate writing text or dragging an element
• Easily simulate AJAX functionality with sample data in fixture files

Firebug and its kin are awesome for debugging javascript, but once our scripts are in the wild we really don’t have any feedback of any kind about the state of the browser.  DamnIT from JupiterIT attempts to alleviate this by providing an automated feedback system for javascript applications.

How it works:

1. A box appears prompting you to describe your most recent actions:
2. One of the following occurs:
   • you type something and click send
   • you click “close”
   • 10 seconds pass with you doing nothing
3. DamnIT emails you the following information:
   • Browser
   • Page
   • HTML Content
   • Description (if you entered one)
   • Error message
   • File name, line number, and stack (if the browser supports them)

On the surface this is an incredible system.  In practice there are a few key issues that I think need addressed before the product is an ideal fit for every situation.  Basically, I have severe reservations about the email only nature of the system and its dependence on central management.  Both of these are key issues when dealing with sensitive information or large volumes of error messages and I’m sure will be addressed with future versions.  I am going to integrate the system into the next release of BLT and will be providing feedback from those efforts in the near future.  In the short term, you can check out DamnIT here:

https://damnit.jupiterit.com 

ParseInt is one of the handiest universal functions in javascript. Even though javascript’s ability to cast most any primitive to any other primitive on the fly is handy to say the least, sometimes we need to explicitly parse a string to make sure we have a legitimate number to work with.

ParseInt does this for us. What most developers don’t realize is that parseInt is base agnostic. While it typically assumes base ten, any base between 2 and 36 can be used and is indicated by the optional second argument.

Why is this a problem you might ask? Because octal numbers can be represented by a leading zero. In practice this can cause some interesting effects in your code.

For example:

var x = "010";

console.log( x );

console.log( x - 0 );

console.log( parseInt( x ) );

console.log( parseInt( x , 10 ) );

Returns:

"010"

10

8

10

Note: “010″ is equivalent to 10 in  “x – 0″!

If you don’t already know about Namespaces, Here’s a quick primer.

A namespace is a unique identifier for a particular library or collection of objects.  Namespaces are used to prevent conflicts between various libraries and to simplify debugging.

Traditionally Namespaces are defined using the unique name of a given project or library followed by a subsequent functional grouping i.e. (Yahoo.Util).  There is also a tradition from the Java community of defining namespaces & packages using reverse URL notation i.e. (com.ajaxbestiary.libraryname)  I’ve found this notation to be too cumbersome for most Ajax projects.

Abbreviating Namespaces 

Some developers prefer to abbreviate namespaces using a shorthand variable notation ie (var yu = Yahoo.Util).  This technique should be used quite carefully as it can lead to conflicts and confusion in multi-library & multi-person development.  My recommendation is that any abbreviations be standardized upon across all development within an organization.

Over the next few days I will be exploring the use of namespaces in common Ajax toolkits.

Here’s a handy jQuery plugin to speedup development and greatly enhance debugging.

http://happygiraffe.net/blog/archives/2007/09/26/jquery-logging 

This lets you simply add a .log command to a jquery chain and have the result logged to the firebug console with all relevant contextual information.  Fast, easy and simple.

IBM Developer Works has released an excellent article on AJAX interface development with a focus on best practices and a recomended work flow.

Check it out here:

http://www.ibm.com/developerworks/web/library/wa-aj-frontend/index.html?ca=drs-tp4207

Organizational standards are wonderful things.  They enforce consistency, help insure institutional competence and can dramatically reduce the learning curve to get additional staff up to speed on a project.  At the same time, in the world of AJAX standards can be too slow to adapt to a constantly changing landscape.  How do you strike a balance between flexibility and consistency?

 Project Specific Framework Selection

This is one of the most common approaches and is definitely the most flexible.  Project specific standards basically let the needs of a given project describe the choice of frameworks.  A project needing lots of animation and color manipulation may be built using mootools, a complex RIA may be built using dojo & a simpler project may use prototype or jQuery.  The problem with this approach is the frequent need to learn new API’s & potential to develop overly superficial knowledge of toolkits that may lead to unnecessarily cumbersome solutions.

Selection of Approved Frameworks

A step beyond project specific framework selection is the adoption of 2 – 4 approved frameworks within an organization.  In this arrangement, you try to achieve a balance between project appropriateness and standardization.  Usually the frameworks are chosen to accommodate different scales of projects.  A natural breakdown is the use of prototype & scriptaculous where scriptaculous may not be used in every project.  Another breakdown may combine a simple framework like prototype with a RIA platform like Dojo & an intermediate toolkit like jQuery.  In any event, it’s usually a good idea to pick platforms with similar coding styles & api’s to maximize the transference of skills between projects.

Standardizing on a Single Framework

This is definitely a popular approach and prevents any problems with developers needing to relearn things to get up to speed on different projects. Unfortunately, it’s a very high risk approach as toolkits frequently aren’t optimal for every project (e.g. dojo for a brochureware site and prototype for a webmail client).  There’s also the unfortunate possibility of a framework transitioning to an inappropriate licensing model or being abandoned as well.

Standardized Coding Practices

This is a strategy that can be adopted independent of your framework strategy.  basically, since so many of the various frameworks share constructs and they are all based on javascript.   Adopting a set of coding standards can dramatically simplify collaborative development.  Some of the strategies to consider are:

• Standardized Naming Conventions (camelcase, underscore etc.)
• Standardized File Names
• Standardized Function Names
• Comment Formating
• Chaining limits

We’ll discus coding standards more in the future, but since I’ve had several recent discussions on adopting a standard for my organization.  I thought I’d share some of our thoughts with you.