A good practice worth sticking to is minimizing the use of the global namespace. The value of this is especially evident in shared libraries. Here’s an example you may see in a page validating a form:

var MY_NS = window.MY_NS || {};
function init() {
  MY_NS.nameField = document.getElementById( "nameField" );
  MY_NS.phoneField = document.getElementById( "phoneField" );
  MY_NS.addressField = document.getElementById( "addressField" );
  …
  if ( null === MY_NS.nameField.value || "" === MY_NS.nameField.value ) {
    …
  }
  …
}
…

There are a few optimizations we can make that will help this script to compress well.

First off, the repeated calls to document.getElementById should be replaced with a local variable. The benefit of this is that the local variable will be reduced into a single letter during minification. I recommend replacing the “.” with a “_” character, since it leaves the source script fairly readable.

MY_NS.nameField = document.getElementById( "nameField" );
MY_NS.phoneField = document.getElementById( "phoneField" );
MY_NS.addressField = document.getElementById( "addressField" );

becomes

var document_getElementById = document.getElementById;
MY_NS.nameField = document_getElementById( "nameField" );
MY_NS.phoneField = document_getElementById( "phoneField" );
MY_NS.addressField = document_getElementById( "addressField" );

After minification you’ll get something like this (I’m leaving in the newlines though).

var A = document.getElementById;
MY_NS.nameField = A( "nameField" );
MY_NS.phoneField = A( "phoneField" );
MY_NS.addressField = A( "addressField" );

That tip saves 22 characters per use. Similarly, we can create local variables inside our init function to save us some characters when referring to the properly namespaced fields.

MY_NS.nameField = document.getElementById( "nameField" );

becomes

MY_NS.nameField = document.getElementById( "nameField" );
var MY_NS_nameField = MY_NS.nameField;
…
if ( null === MY_NS_nameField.value || "" === MY_NS_nameField.value ) {
  …
}

after minification:

MY_NS.nameField = document.getElementById( "nameField" );
var B = MY_NS.nameField;
…
if ( null === B.value || "" === B.value ) {
  …
}

If you find yourself referring to an object more than a few times, it makes a bit of sense to create locally scoped variables here. It’s also important to note that this is allowable with any Javascript object, even the document object. Yahoo! uses this technique all over the place in their great YUI library.

Perhaps a future release of YUI minifier (or one of the other minifiers) will add a two-pass optimizer in the future to save the developer the hassle of defining extra locally-scoped variables, but I’ll not hold my breath.

As an example consider the following code:

private static final int SPECIAL_CASE_1 = 1;
private static final int SPECIAL_CASE_2 = 2;
…
int someThing;
String param1;
String param2;
…
switch( someThing ) {
  case SPECIAL_CASE_1: {
    doSpecialCase1( param1 );
    break;
  }
  case SPECIAL_CASE_2: {
    doSpecialCase2( param2 );
  }
  default: doSomethingElse();
}

There are some issues with the above code. case statements are easily screwed up (is SPECIAL_CASE_2 supposed to also call doSomethingElse() or is that a bug? Also, adding new cases can lead to quite a lot of classes to update. For the times where a full-blown class hierarchy is overkill, an enum makes quite a lot of sense. Often, the methods doSpecialCase1, doSpecialCase2, doSomethingElse can be refactored into methods of the enumeration.

Here’s how we can accomplish this.

public enum SpecialCaseHandler {
  SPECIAL_CASE_1,
  SPECIAL_CASE_2,
  DEFAULT_CASE
}

This simple enum can be used to replace the type of the control variable someThing. Now the switch statement looks like this:

SpecialCaseHandler someThing;
String param1;
String param2;
…
switch( someThing ) {
  case SPECIAL_CASE_1: {
    doSpecialCase1( param1 );
    break;
  }
  case SPECIAL_CASE_2: {
    doSpecialCase2( param2 );
  }
  default: doSomethingElse();
}

On the surface, this doesn’t get us a whole lot. What would really be nice is if we could remove the switch statement altogether. To accomplish this will take a bit more magic.

We’ll begin our magic by defining an inner interface inside the enum itself. Since the above switch statement uses two separate String parameters, the interface will have to account for both parameters. In addition, our enum will need a field declared of that particular interface. It looks like this:

public enum SpecialCaseHandler {
  …
  private MyRunnable myRunnable;
  …
  private interface MyRunnable {
    public void execute( String param1, String param2 );
  }
}

Next, we’ll rework the enum members to use a non-default constructor that takes an instance of MyRunnable.

public enum SpecialCaseHandler {
  SPECIAL_CASE_1( new MyRunnable() {
    public void execute( String param1, String param2 ) {
      // body of doSpecialCase1() goes here.
    }
  } ),
  SPECIAL_CASE_2( new MyRunnable() {
    public void execute( String param1, String param2 ) {
      // body of doSpecialCase2() goes here.
    }
  } ),
  DEFAULT_CASE( new MyRunnable() {
    public void execute( String param1, String param2 ) {
      // body of doSomethingElse() goes here.
    }
  } );
  …
}

Now the original switch statement can be remove altogether, leaving this beautiful little call:

someThing.execute( param1, param2 );

But wait, you say, what if my caller class has some dependencies that prevent the methods doSpecialCase1, doSpecialCase2, and doSomethingElse from being refactored out of the caller class? The answer is simple, add additional input parameters to the MyRunnable execute method to take the dependencies as input.

That is, if doSomethingElse happens to use a database connection whereas doSpecialCase1 uses a file handle, you’ll have to come up with some way to pass that off to the method call. I’ll leave that as an exercise to the reader.

I’m pretty pleased with the result: I’ve removed the switch block from my code and can pretty easily add in new cases to the enum. I think using enums really is a nice alternative to more rigorous inheritance in a lot of cases. Anytime a specific identifier is called for but not necessarily a super-reusable class, consider using an enum instead.

The downside to this approach is that it becomes very difficult to compile those JSP files without walking through one’s application.

One of the nice things about GlassFish and WebLogic is that it allows you to compile your JSP files during deployment. Tomcat does not. Using Maven or Ant one can precompile the JSP files, but that approach hasn’t always worked for me (especially when a custom tag library is in use).

On Monday I’m launching an update to an application and we expect a bit of a rush on those first few minutes when the application goes live. Last time we had this, the first few sessions were incredibly bogged down by the JSP compilation.

Today I discovered the fix: move the JSP files to be in front of the WEB-INF wall and reconfigure my view resolver to look in the proper place. This allows me to then fetch those files individually via a simple curl call.

…

The downside to this approach is that I just CPU spiked my servers, as curl just fetched each JSP file individually causing a huge amount of compilation to occur. Sorry about that sysadmins Please ignore the huge spike in CPU usage this afternoon.

Back in 2001, Apple joined the fray of portable music device manufacturers with iPod. Of interest to some was a throwaway phrase mentioned about its engineering: “made with off-the-shelf parts.” That is to say, Apple used existing chips and hardware largely in creating its music player.

By designing iPod with pre-existing parts, Apple was offered a world of flexibility. If the device flopped, the company could recoup losses much quicker than if it had spent an extended amount of time putting its varying departments to work developing custom circuits, screens, etc. If the device proved successful, future revisions could include less off-the-shelf parts. Apple established a brand, getting their foot in the door. Over time, Apple switched from iPod components out gradually replacing them with their own, custom parts.

I am reminded of the software design principle of “Ya Ain’t Gonna Need It.” This principle basically says that one should not add functionality until it is required. In order to create a new product, Apple didn’t require all of the component design and maintenance headaches to start a project. Instead, YAGNI was in play, and Apple got their foot in the door.

When the time was right, the proper changes were made. By no longer using those same off-the-shelf parts, Apple could fine-tune and better control what it wanted, resulting in a more innovative player. The first iPod had a mechanical wheel, the next used a touch pad surface, the next a click-wheel, etc. However, without getting the brand started, Apple had no incentive to iterate its design. I think that is an important lesson.

In many ways, this has been the Apple m.o. for some time. The iMac and Mac mini have frequently been test beds for engineering smaller parts that would eventually end up in its notebook computer line. The MacBook Air paved the way for the Unibody Aluminum MacBook Pro. Across the internal lines within the company exist some powerful cross-cutting concerns. Apple is wise enough to keep its eyes open and to identify those cross-cutting concerns and embrace them.

This brings me to the iPad. Apple made a lot of news with this device. I found it interesting as it featured a processor designed by a recently acquired processor designer. If the pattern Apple has applied in the past continues, I wouldn’t be surprised if Apple believes the time is right to switch to a similar custom system on a chip for its next iPhone model.

By embracing the principle of YAGNI Apple has reaped the benefits of flexibility. As a software developer, I live in a wondrous age where I can lease a score of servers from Amazon’s EC2 system and try out an idea without purchasing a operations center full of computers. If the idea fails, very little harm was done. If the idea takes off, a future purchase of dedicated servers can be arranged. The beauty of it all is that one will already have proof that the idea is viable. The question I’m left with is this one: why haven’t I created something to prove the concepts I am talking about?

Here are my thoughts as I had (time to type) them.

• Does the public care how fast a computer boots up? There’s got to be an acceptable tolerance that has already been met by the Google Chrome OS efforts.
• The presenter has a Jeff Goldblum vibe going on.
• The demo was from code checked into trunk? Wonder if the demo will fall on its face at some point …
• I hope the UI changes for “application tabs”; favorite icons aren’t the best way to identify different properties. A plus will be that it becomes more useful for an app developer (I’m looking your way, Atlassian) to use separate favicons for its products.
• The favicons do have the benefit of being i18n-friendly.
• Panels remind me of the old Google Notebook Firefox add-on. I wonder if Gmail will use panels for its chat window.
• Note to self: games do not necessarily mean 3D.
• Multiple windows feels a lot like virtual desktops.
• I hope Google posts their use cases along with their source code. I doubt it will happen, but one can hope.
• Google has got to be working hard to keep Microsoft Office online from breaking in Chrome.
• The video sure ends abruptly.

I think Google has a hard sell in front of them; I’d love to know who Chrome OS is for. I know I would love a fast, little netbook that is really good at the few things it should do, but we have a 25 year history of PCs that continue to reinforce comparisons between things that have keyboards, pointing devices, and monitors. Perhaps Google doesn’t want many folks actually using Chrome OS but want to leverage it as an experiment to create more markets for web applications. Maybe they were really inspired by the One-Laptop-Per-Child project and want a cheap, useful PC to be able to be disseminated.

I’ve been working on a project lately that is a pretty simple management application that uses JPA in the data layer. One of the goals of this project is to provide a nightly process for parsing input files. I could have tackled this in a variety of ways. My first hope was to create an executable JAR file, but I quickly found that I couldn’t get very far due to a limitation/feature of JARs: one cannot modify the classpath via the command line interface. My project uses some platform-specific files, so I could not easily include them in the final package. My second attempt ended up working well: create a JAR file within my WAR and execute a class inside that particular JAR.

This project has quite a lot of dependencies: Spring MVC, Hibernate, JPA, Javamail, SQL Server, etc. If I were to create a command-line call to the java executable it would quickly fill up many, many lines in an editor. Fortunately, it’s easy to include the classpath inside the JAR manifest during the Maven package:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <archiveClasses>true</archiveClasses>
    <archive>
      <manifest>
        <addClasspath>true</addClasspath>
        <mainClass>…</mainClass>
      </manifest>
    </archive>
  </configuration>
</plugin>

The <addClassPath> bit tells Maven to include all of the other dependencies in the manifest file. This is a big deal, as it accomplishes two things: it takes care of me having to write a script to generate the classpath dynamically and it allows me to have a very reasonable length command line statement.

Thanks to letting Maven create a JAR file with its manifest managing the classpath, my resulting java command looks like this: java -cp MyProject.jar:… MyProjectRunner (where MyProjectRunner is a class that I want to execute).

Here’s how to replace JCL with SLF4J:

<dependency>
  <groupId>commons-logging</groupId>
  <artifactId>commons-logging</artifactId>
  <version>99.0-does-not-exist</version>
</dependency>
<dependency>
  <artifactId>jcl-over-slf4j</artifactId>
  <groupId>org.slf4j</groupId>
  <version>1.5.6</version>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
  <version>1.5.6</version>
  <scope>runtime</scope>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
  <version>1.5.6</version>
</dependency>

Here’s an explanation of what’s going on:

1. The first dependency tells Maven that commons logging will be using a non-existent version.  You’ll need to use an empty JAR file or find a repository that will serve you such an empty JAR.  The trick is that the version number is ridiculously high and trumps all other versions of JCL.
2. The second dependency tells Maven to use SLF4J to provide the API for JCL.  All Java commons logging calls will then use the SLF4J runtime implementation to provide logging.
3. The third dependency is the runtime implementation of SLF4J over log4j. In essence, the only calls to log4j are made through SLF4J.
4. Finally, we’ll bring in the SLF4J API so our code can use SLF4J instead of JCL or log4j.

Here’s an example of replacing log4j with SLF4J:

Old Version

private static final org.apache.log4j.Logger LOG = org.apache.log4j.Logger.getLogger( Taco.class );

New Version

private static final org.slf4j.Logger LOG = org.slf4j.LoggerFactory.getLogger( Taco.class );

This one line change allows you to change out your runtime logger at will

It’s no surprise that the biggest issue getting HTML 5 elements to work in a backwards compatible way is Internet Explorer. Fortunately, there’s a world full of folks out there working hard to determine workarounds and hacks until the IE team builds real support into its product.

Cue the HTML 5 shiv. This workaround is great; elements get full CSS access in Internet Explorer 7. This means that you can easily style the new elements without too much hassle. Combine with Internet Explorer’s excellent conditional comments and you can inject IE-specific javascript code into your page and expect it to work.

Here’s a problem with this method: the script elements must execute prior to when the style sheets are processed. This is a serious issue that prevents the good coding practice of having your script elements exist at the end of your HTML document, right before the termination of the body element.

What to do?

The big answer is to put the IE-specific code right after the meta-charset element in your HTML 5 document, but this only works for pages that you’ve got full control over w.r.t. the header. Not a good fix by most measures.

I’m still chewing on this one, but so far I’ve been unable to get IE to re-enable the appropriate style rules at the right time.

A technique I commonly use is to overload CSS classes and transform the elements via client-side Javascript. For example, if I have a control with a class of “required” I can, via Javascript, enforce requirements on the control. I would love it if I could also set the “aria-required” attribute in the same manner and have it work in screen readers.

Can anyone give me an idea of whether or not this works?

Why Maven?

I developed a similar system for building projects in Apache Ant.  Ant is a great tool that continues to be very useful, but I ran into two issues that prevented me from loving Ant (three if you count the fact that Ant is a piece of software, not a person).

1. Ant could not easily create a project.  My old build system involved creating a project copy via Subversion and then renaming several resources to correspond.  This kludge never really sit well with me.
2. Ant didn’t provide me much with regards to profiles and rolling out fixes.  A common occurrence I had was to check a project out from SVN, build it, deploy it locally, test it, roll it out to production again, and then check things back into SVN.  This involved a lot of tweaking, much of which I was able to streamline, but I never did get everything down so that I could really build in one step.

What Maven Got Me

Maven addressed both of these issues for me with the notion of a project archetype. With a Maven archetype, one can create a “proto-project” and instantly create a “real” project using it as a base.  During initial creation, you can specify the things in one place that I formerly had to follow a post-copy checklist in Subversion to accomplish.  This was a huge gain, as it removed a huge portion of the human error that could be introduced in a more manual process.

This in itself wasn’t enough to really make me like Maven though.  The real reason I wanted to use Maven was to solve #2 on the above list.  Until I could do that, I would continue to use the checklist-based Ant+Subversion method since it was more widely used already (and I was used to it).

Then I discovered Maven’s support for build profiles.  A profile is essentially a sub-environment for building (or whatever task you are accomplishing with Maven).  Using a profile that could allow me to define separate build environments for a single project.  Here’s what I came up with:

• development: working on a project that would then be rolled out to my local machine
• staging: once a project was sufficiently ready to show off to someone, I could build it using this profile and push it out to a staging server (originally I called this test but that term was way too overloaded already)
• production: once a project matured from staging I could build it with production settings and push it out to the production server.

I incorporated resource filtering in my Maven pom.xml file, so each build result would have its resources reflect the profile it was built under.  For instance, I have a central authentication service that my web applications use.  Maven will filter the resources so that, at build time, the location of the CAS endpoint changes with the build profile.  This is great, because I no longer have to nanny this setting.  Huge gain to me, as all of my settings become streamlined.  So long as I smartly set up my resources, each build gets the correct settings.

Caveats

Maven is still a moving target with regards to its plug-ins especially.  Maven’s archetype plugin changed a lot from version 1 to version 2, and neither version exited the alpha stage.  In order to correctly build on Windows, I had to upgrade to the bleeding edge 2.0-alpha-3 version, which I had to find via the JIRA site and then build and install myself.  This is a dependency that should be a non-issue over time, but YMMV.