My First Maven Release

As promised, I've gone and published my dropwizard-guice library jar to the central maven repository. This was a rewarding experience, being my first such release, and it feels good to be giving back to the community in such an "official" manner!

Here's the official maven dependency:

  com.fiestacabin.dropwizard.guice
  dropwizard-guice
  0.5.1

Many thanks to the official Sonatype docs, and Joel Orlina for helping me to get this set up properly. Also, this post helped as I needed to upload my PGP key to the mit keyserver, not the one listed on the sonatype docs.

Nostalgia

I've been coding for quite some time now. It just so happened that my freshman year of high school coincided with the release of an exciting new technology / language named Java. This was a language with its own runtime, which included the ability to run inside of a web browser (think Netscape). Seeing as how I already had some experience tinkering with C and C++, the prospect of creating visual applications made Java all that much more appealing to me. I borrowed my Dad's Teach Yourself Java in 21 Days book, read through a bunch of tutorials, and dove head first into the world of applets and AWT.

At this time, I was also very much into freestyle BMX, and with my best friend Eric Miller had created a moderately popular community site, JEBikes.com. In order to satisfy my urge to code, and also for us to put some interesting content on the site, we'd sit for hours in my room, Eric on Windows Paint, drawing the graphics and designing levels, and me in front of Notepad, typing away at my monolithic Java class file. We ended up creating a handful of these games, and it was a great experience.

A short while ago, an old friend of mine from high school contacted me about these games. Since the site had long since gone offline, and the domain had been surrendered, I got excited about the prospect of resurrecting them, just to see if and how they'd work today. It took some time, but I was able to locate the original source files on a portable hard drive tucked away in storage. The most annoying and difficult part about getting everything running was dealing with the old Windows 98 / DOS extended filenames; on the disk they were written out as eight characters with three character extensions, all in caps, and if there were any special characters or the length exceeded, then you'd have something like SCREE_~1.GIF, so I had to go through and carefully rename each file, even if it was simply to lowercase it.

For posterity and safe-keeping, I've decided to put these up on github. They are definitely not examples of my finest coding work, and might actually make interesting case studies in TDD refactoring in the future (if they weren't applet-based... ick!). It's always interesting to revisit code you've written 15 years ago, especially since most of the time I question what I was thinking with code I've written 6 months ago. Enjoy!

http://fiestacabin.com/jared/nostalgia/arcade

Simple Guice integration for Dropwizard

If you haven't come across it yet, Dropwizard is a nifty new framework designed to streamline and simplify development of lean web services which are inherently "ops-friendly". By "ops-friendly", I mean that it provides out of the box support for and gentle encouragement to use things like health checks and metrics monitoring. By "lean", I mean that these services are run from within their own JVM processes, with embedded Jetty as a server. This idea of multiple, self-contained, fail-fast processes is best described by the Twelve Factor App.

So with Dropwizard, you extend from the base Service class, and add things to the Environment on startup (e.g. Jersey Resources, Providers, etc). I've created a simple extension to the Service class which does some classpath scanning to automatically install your resources, providers, health checks and tasks for you, via Guice, allowing you to use Dependency Injection throughout your application for object dependencies. Check it out on github! (IMHO) It's quite simple to integrate into your project, and I've found it to be very useful so far, in that I can simply create a new resource class with a @Path annotation, create a constructor marked with @javax.inject.Inject, and it will automatically be wired up and installed into the REST container.

Let me know what you think! If I get enough interest (read: any) then I'll throw up the binaries on an accessible maven repo.

Update (26 Sep): I did end up getting interest, and have since made this available on the central maven repo.

ProTip: Debugging Minified JavaScript using Chrome DevTools

Here's yet another reason why I develop exclusively in Chrome: they've got a killer feature in the JavaScript DevTools which will format any script file, even if it's been minified, and allow you to place breakpoints on that formatted output!

If you're working on troubleshooting an issue in a production app, for example, you'll have something like this:

If you notice, there's a button on the bottom toolbar that looks like a pair of curly braces { }. If you click that:

Then voila! Pretty-printed!

And I can set breakpoints and troubleshoot!

Building CanJS with Maven (or Ant)

CanJS and other similar JavaScript frameworks are great for creating modular applications and keeping source files small and cohesive, but we all (should) know that when it comes to web site performance, it's important to keep the total number of downloads to a minimum. This becomes especially important when you start to factor in mobile devices, where the cost per connection is much higher than on desktop browsers.

Luckily, CanJS (and most of the others, I might add) includes the ability through StealJS of compressing and concatenating all of the source files for your application into a single production.js, as well as doing the same for your CSS files, into a single minified production.css.  When you use the generators which come with DoneJS / JavascriptMVC to create a new app, you'll notice in the folder structure a scripts folder, which contains a build.js and build.html. Steal uses Rhino to load the build HTML file, which includes a single call to load the main steal.js core and bootstrap your app (e.g. ../steal/steal.js?yourapp). It then tracks all of the imports, JS, CSS, and EJS, and bundles them into either the production.js or the production.css. Note: the folks over at Bitovi been busily cooking up a new "packages" feature which I haven't yet had the chance to play around with, which promises to shrink the size of the monolithic production.js into more on-demand modules.

The generated scripts folder of a DoneJS app. Also note that there are a few other fun features in that folder besides building, which I can go over in greater detail in a future post.

Building with Maven (err, Ant)

So now back to the subject of this article: how does one integrate this cool build feature into their existing build system? I've got it working in a Maven build (albeit via an Ant task), since the server-side component of my application is Java.

   
    org.apache.maven.plugins
    maven-antrun-plugin
    1.7
    
     
      org.apache.ant
      ant-nodeps
      1.8.1
     
       
    
     
      build-donejs
      prepare-package
      
       
        
        
        
         
         
        
        
         
         
        
        
         
         
        
        
        
                  
              
              
        
         
          
          
          
         
         
          
         
        
        
        
        
            
                
            
        
       
       UTF-8
      
      
       run
      
     
    
   

Things to note in this setup:

• I've split my web application into multiple distinct DoneJS apps; the line is drawn at the point where there's a distinct HTML page (in this case, login, app, and admin are separate pages).
• I'm hosting my static content out of /src/main/resources/assets, which is sort of a convention when writing DropWizard applications (more on that awesome framework in a future post!)
• I'm attaching this execution to the prepare-package build phase, since it takes a while (on the order of 5 minutes or more) and it's important to fail fast on the unit test phase. I've already moved all of the relevant resources into target during process-resources.
• The production build can fail for a number of reasons, including syntax errors in your JS files, so it's important to look for the production.js files in your output directory and fail the build when they are missing. If you don't, there's a chance you will deploy a broken build to production and your users will not be terribly thrilled!

Not quite done yet!

There are two more steps to do in order to fully take advantage of this awesome build stuff.

First, you need to reference the production.css stylesheet in your html files. Do so like this (in your document's head, of course):

This will give you 404's while in development mode, and your app will flicker a bit in that mode since you're using StealJS to import your CSS files, but in production mode the production.css file will be present and everything will be blazingly fast.

Next, you need to tell StealJS to load your production.js file. I've done so in my Ant task by using regexreplace to replace the references to steal.js with steal.production.js.

So there you have it. Add this plugin definition to the build / plugins section of your pom, and run mvn clean package to generate the production files!

Who's var is it, anyway?

Consider the following snippet of JavaScript code:

var cells = document.getElementsByTagName('td');

for(var i=0; i<cells.length; i++){
  var cell = cells[i];
  cell.addEventListener('click', function(){
    cell.style.backgroundColor = '#00F'; // which 'cell' ?
  }, false);
}

Does the click listener function do what it’s supposed to? Why or why not?

Closures and Scoping and Vars – Oh, my!

If you’ve gotten this far, it’s probably safe to say you’re aware of the fundamentals of the var keyword. It’s also likely that its use has been hammered into your consciousness as a “best practice” coding habit, and that’s a Good Thing™ (polluting the globe and the global namespace are equally heinous).

So, you follow this advice faithfully, and always declare your variables before you use them:

function foo(arg) {
  var a = 0;

  if( arg ) {
    var b = ‘arg: ‘ + arg;
    console.log( b );
  }
}

Here’s the caveat: unlike other C-style languages, JavaScript variables are NOT block-scoped; they are only global- or function-scoped. Those curly braces provide no protection for your poor vars.

What does this mean? I can update the previous code like this:

function foo(arg) {
  var a = 0;

  if( arg ) {
    var b = ‘arg: ‘ + arg;
    console.log( b );
  }

  console.log( ‘still b: ‘ + b );
}

One more thing…

In JavaScript, variables can be declared after they are first used. How is this possible, you (hopefully) ask? Because of a funny thing that the language parser does, called var hoisting.

foo = ‘bar’;
var foo;

// is implicitly understood as:

var foo;
foo = ‘bar’;

Because of this, it’s a good idea to declare variables at the top of functions. In our original example, the language understands it like this:

var i, cell;
var cells = document.getElementsByTagName('td');

for(i=0; i<cells.length; i++){
  cell = cells[i];
  cell.addEventListener('click', function(){
    cell.style.backgroundColor = '#00F';
  }, false);
}

Note that because the compiler moved the var to the top of the scope (and we don’t have block-scoping in JavaScript), our click handlers are all closing on the same cell instance, which will have the value of the last table cell element at the end of the for loop, so our click handlers will all only effect the last table cell in the document!


Reference: https://developer.mozilla.org/en/JavaScript/Reference/Statements/var

Simple(r) String Templates with Commons Lang

Whenever I have a need to use string templating in a project, I reflexively turn to Velocity, which works great, but it:

• is "heavy": can be difficult to get into a project and functional, has some quirks with classloaders and logger systems, etc
• is old: last updates were back in 2010

Velocity is also loaded with features like control constructs, loops, branches, etc, which seem like overkill when all I really need to do is format email notifications with some variables (I've already gone the route of client-side view templates for my UI stuff these days).

I know there are a million ways to solve this using homegrown regex's and other such things, but I found a convenient helper in Commons Lang3: StrSubstitutor. It allows you to replace variables in a string, denoted by:

${varName}

I've written a simple wrapper around it, which can pull a template string from a file on the classpath, caching it using a simple WeakHashMap.  This could be extended to use the nicer caching framework found in the fantastic Google Guava project, perhaps.

An example use of this class might be to stick a template text file into src/main/resources/templates/foo.template (for all of you fellow Maven'rs out there!), and invoke it like:

String output = Templates.template("templates/foo.template")
                         .value("foo", "bar")
                         .value("other", "val")
                         .render();

CanJS (or: How I Learned to Stop Worrying and Love the DOM)

Javascript?!? Ewww....

Let's face it: Javascript has gotten a bad rap over the years, and with good reason (mostly). Anyone with a less than favorable view of the language has likely formed that opinion after an encounter with some ugly messy spaghetti code, perhaps in a legacy enterprise web app, sprinkled throughout the HTML to add some basic form validation, or toggle visibility of a page section, or provide a rudimentary tabs control. When code grows organically, without an over-arching framework to guide its evolution, it tends to grow like a weed: out of control and in all the wrong places.

So we recognize that we need a framework, if we've got any shot of building a significant maintainable application. The problem then becomes, which one? There are a multitude of frameworks to choose from. The sheer volume of projects can make it quite intimidating to start on a greenfield javascript application.

This article will not be delving into the specifics of why to choose one framework over another; I don't have enough experience in all of them to make that an educated statement. It will, however, detail my experiences with CanJS, (and its sibling projects, StealJS, JQuery++, and FuncUnit, all of which now exist under the umbrella project DoneJS) and go into some depth on how I was able to utilize it successfully in a recent project. (also, I'm realizing that this will most likely end up a series of articles, as I'm finding that I've got a surprising amount to say on the topic)

CanJS: tl;dr

So what is CanJS, exactly? The website has a great explanation and description which I won't parrot here, but essentially it gives you some useful tools for building an application in Javascript conceptually as an aggregation of models, views, and controls (MVC, anyone?). There are a number of whiz-bang features they sprinkle in as well, like the concept of an 'observable' object, live binding with views, and URL hash 'routes'. It sits on top of a number of the "big" foundation javascript framework / libraries (e.g. mootools, dojo), but JQuery is the one I chose to base my app on (since, like, everyone is using it and stuff). You then use StealJS to "import" all of the dependency scripts for your app's components, with the added benefit of being able to compile complete, minified production js (and css) artifacts in a build process.

A big aspect of the DoneJS project is that it emphasizes and facilitates the creation of functional and unit tests for your code. Management-types will be giddy over the FuncUnit feature which can show you a line- and branch-coverage report for your test suite.

Why I think Can/DoneJS is cool

I like the way I'm able to logically structure my application into reusable components. I really like the EJS template library, which allows me to write my HTML in reusable fragments, "hookup" javascript objects and events to those fragments, and even "live-bind" to observable objects (where the view actually changes when you update an attribute on an observable). Can.Construct (and can.construct.super) give me class inheritance in Javascript with a nice syntax. Can.proxy allows me to write event handling and asynchronous code without devolving into nested nested callback functions. The Control concept is simple yet powerful.

Why I think Can/DoneJS is hard

My background is predominantly Java, with a heavy emphasis on server-side "enterprise" applications. It's possible that the doc sites are more grokkable by those native Javascripters, but I find them hard to decipher at times, and also often out of date or incomplete. That requires you to get familiar with the internals of the framework in order to troubleshoot when things don't work as advertised. That said, the guys at Bitovi do a good job of patrolling the forums and respond quickly to pull requests on github.

More to Come...

Now that I've (perhaps) whetted your appetite a bit, I will next go into deeper dives on some cool / interesting things I've done with CanJS, as well as illustrate some gotchas that I encountered which will hopefully help you in your coding.