Wednesday, May 1, 2013

A Lazy Coder != A Good Coder

Recently, a co-worker recently shared a quote with the group:
working as a programmer is the 1st time in history where lazy people (w.o. connections or personal wealth) get payed well to be even more lazy
I take issue with this on a number of levels, but mainly that this seems to be a common theme in the programming world, that a lazy programmer is akin to a good programmer. This can't be further from the truth.

A lazy programmer:

  • takes harmful shortcuts and hacks his features into production code
  • doesn't take the time to think about how his module will behave in the context of the larger system
  • writes poor (or no) unit tests
  • doesn't care to understand how the API he is using works
  • cuts and pastes code
  • uses global variables
I definitely would not want to have a lazy programmer on my team, or contributing in any way to my codebase.

What I think people must mean (hopefully!) is that a good programmer automates when he can. A good programmer is conscientious, meticulous, and thorough. 

Saturday, March 9, 2013

The case of the mysterious failing date test

I had such an aha! moment this afternoon that I thought I'd share it.

This test case was failing for me, and I was positive that I hadn't made any changes which would affect that part of the system:

The trick here is when I was running the test: March 9, 2013, at 1:55pm EST. Turns out that tonight is daylight savings, when we "spring ahead" and lose an hour, and of course 23 hours does not a standard day make!

Friday, March 1, 2013

Using StealJS in Jasmine Tests with Grunt

Grunt Jasmine Configuration

In this post, I'll detail how to use StealJS to author Javascript unit tests in Jasmine, and run them from the command line using the headless grunt-contrib-jasmine runner.

If you look in the documentation for grunt-contrib-jasmine, you'll see a section on using a custom template to run tests which use RequireJS as a dependency manager. You'll end up doing the same bit for StealJS, but will use a different template plugin: grunt-template-jasmine-steal.

First, install the necessary plugins into your local grunt project workspace:

npm install grunt-contrib-jasmine --save-dev
npm install grunt-template-jasmine-steal --save-dev

Next, import the tasks into your Gruntfile.js:

grunt.registerTask('test', ['connect:test', 'jasmine']);

Finally, define the connect and jasmine plugin configs. Note that I'm setting up the connect plugin to start a local web server on port 8000, for phantomjs to connect to when running the jasmine suite:

var jsFiles = [

connect: {
    test : {
        port : 8000

jasmine: {
    tests: {
        src: jsFiles,
        options: {
            specs: 'src/**/*_spec.js',
            host: '',
            template: require('grunt-template-jasmine-steal'),
            templateOptions: {
                stealOptions: {
                    stealUrl: '/src/steal/steal.js',
                    baseUrl: ''

Take note of the jsFiles variable I defined; that concisely lists all of my javascript source files, excluding libraries.

Cleaning and Linting your Sources

Another important build step is to clean and lint (error check and validate) your code, and thankfully grunt makes this easy on us. I use the jsbeautifier and grunt-contrib-jshint plugins for this:


        jsbeautifier : {
          files : jsFiles

        jshint: {
            files: jsFiles,
            options: {
                jshintrc: '.jshintrc'

Note: look at the documentation for jsbeautifier to see the available configuration options (the defaults work fine for me out of the box).

Putting it All Together

Here is a complete Gruntfile.js and .jshintrc, detailing what I went through in detail above. I've set it so that the default grunt task performs the code formatting, checks using jshint, and then runs the full jasmine test suite.

A deferred loading cache in Javascript

I was playing around with jQuery deferreds the other day, and thought up a neat use for them, in a client-side ajax response cache. I created a simple expiring cache abstraction, and then wrote a 'loading' cache around it, which populates the cache with $.Deferred instances which are resolved with the result of a $.get.

Here's the simple expiring cache:

And here's the deferred loading cache:

Jasmine spec for the loading cache:

In my next post, I'll show how to use a jasmine spec runner for steal to run jasmine steal specs in grunt.

Thursday, February 28, 2013

StealJS Builds with 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:


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:

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

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: [ 

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]

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:


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


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, 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!