Thursday, February 28, 2013

StealJS Builds with Grunt

GRUNT!

I have seen the future of javascript builds, and it is Grunt.  Please, please, please disregard my earlier post on building with maven; it just doesn't make sense to use such a heavyweight Java-based tool for building javascript projects.

Grunt is rightfully taking the Javascript world by storm. It's got a great community around it, as shown by the wealth of plugins available. It runs on Node, allows for package management via npm, and lets you start working with Javascript in a way which makes us stodgy old enterprise Java guys breathe slightly easier ;-) (more posts on that soon!).

Steal Builds, with Grunt

So naturally I'd like to share how I've gotten steal builds to work with my gruntfile. There is a grunt-steal plugin, but it hasn't yet been updated for grunt 0.4, and steal builds don't run on node anyways. (but, excitingly enough, I've heard rumors that steal will run in node sooner rather than later!)

Here are the npm packages I'm using for my steal build:

    grunt.loadNpmTasks('grunt-contrib-copy');
    grunt.loadNpmTasks('grunt-shell');
    grunt.loadNpmTasks('grunt-exists');

My approach is to copy all of the source files into a target/ folder (ala maven!) so I can apply the package version where appropriate, and build the production.{css | js} files outside of the src dir.

Here's where I copy the source files. Note that I'm only including HTML in the phase where I am replacing the project.version and steal environment variables. As with maven, if you filter binary files it will corrupt them.

        copy: {
            build: {
                files: {
                    'target/': ['src/**/*.html']
                },
                options: {
                    processContent: function (content) {
                        return content.replace(/env\s*: 'development', \/\/ live/g, "env: 'production',").replace(/\$\{project\.version\}/g, grunt.template.process('<%= pkg.version %>'));
                    }
                }
            },
            build_other: {
                files: {
                    'target/': ['src/**/*', 'src/**/.*', '!src/**/*.html']
                }
            }
        },

Here's my corresponding HTML snippets which get replaced:

<head>
  <link href="app/production-${project.version}.css" rel="stylesheet">
</head>
<body>
   <script>
      (function() { 
        steal = { 
          env: 'development', // live 
          startFile: 'app', 
          executed: ['app/production.css'], 
          production: 'app/production-${project.version}.js' 
        }; 
      }());
    </script>
    <script src="steal/steal.js"></script>
</body>

Note also in the build_other phase, that I'm explicitly including src/**/* and src/**/.*, so that my .htaccess file comes along for the ride.

Next, I'm using the shell plugin to run the steal build, the same way as you would manually from the command line. First, I need to make the js script executable, then I run it using the target dir as the base working dir.

        shell: {
          chmodjs: {
            command: 'chmod 755 target/src/js'
          },

          steal_app: {
            command: './js app/scripts/build.js',
            options: {
                stdout: true,
                stderr: true,
                failOnError: true,
                execOptions: {
                    cwd: 'target/src'
                }
            }
          }

And voila! You now have a target/src dir with a deployable web application. My last step is to verify that our production files were built successfully.


        exists: {
            prod_files: [ 
              'target/src/app/production.js', 
              'target/src/app/production.css', 
            ]
         }

Also note that I haven't physically changed the name of the production.js file to production-{project.version}.js. I'm using a neat .htaccess trick from html5boilerplate to do my filename fingerprinting in apache. This works because I've set no-cache for *.html.

<IfModule mod_rewrite.c>
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.+)\-\d+\.\d+\.\d+\.(js|css|png|jpg|gif)$ $1.$2 [L]
</IfModule>

I'm going to go into more detail on integrating steal with jasmine tests, and exploring other grunt goodies, in (near!) future posts.

Wednesday, September 26, 2012

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.

Tuesday, September 4, 2012

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!

Sunday, July 22, 2012

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.

Friday, July 20, 2012

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!


Saturday, July 14, 2012

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!

Wednesday, July 11, 2012

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