The technology behind The Lab - Part 1

Before starting, I want to share my happiness with you: The Lab was selected as a Notable Entry and featured on the GameOn blog!

You can see the post here.

It is a great success to have reached a place among the first 15, given the fact that there were 161 total entries.

---

This is the first of a series of posts about various technical aspects of The Lab, my hackable HTML5 game.

Here I will talk about the Javascript libraries that I integrated and that helped me through the development.

jQuery + jQuery UI - I've been reluctant for some time to use jQuery, as in my opinion it over-simplifies the job. However, given the short time available for the competition, I felt it was time to leverage its ease of use. And in fact it's very helpful for this kind of situations! I didn't require any fancy graphics but only dialogs, accordions and resizable divs, and it's all provided. Thumbs up for jQuery.

jQuery Terminal Emulator - Since The Lab is a game about coding in Javascript (1), a terminal is mandatory unless you force the user to open the browser's developer tools. When you need a specific feature in your web-app, there is a huge chance that "there is a jQuery plugin for that" is a valid answer, and this is the case! There is an interesting topic for one of the next posts: how to eval the user's Javascript?

CodeMirror - Since The Lab is a game about coding in Javascript (2), for some tasks you'd probably prefer using a handy code editor with syntax highlighting rather that writing each instruction on the command line. This is a pretty powerful one, and it runs entirely inside your browser. By the way, its creator Marijn Haverbeke is also working on Tern, a Javascript analysis engine to add autocompletion and other nifty features to your favorite editor.

Buzz - Music and sounds add personality to a game, and they matter a lot to describe entities and situations. I used Buzz for everything that concerns audio.

-prefix-free - Thanks to this small library by Lea Verou you can write your CSS without caring about vendor prefixes. Quite a lot of time saved.

Mutation Summary - This library allows you to play with the DOM and solve some particular puzzles without writing a single line of Javascript. It wraps the Mutation Observer DOM APIs, of which I will probably talk in one of the next posts.


That's all for now, in the meantime you can play The Lab here.

Deploying a Yeoman webapp to Heroku+Node.js

I am currently developing a prototypal game for Mozilla GameOn competition, based on my past JS Bugs Lab project. Well, that was already a prototype, but at least this time I'm trying to make it somehow playable by a human.

To build the app, I'm using Yeoman, a very nice set of tools that is helping me speeding up the entire process.

As of now, the deployment step has not yet been introduced into Yeoman's toolchain, so this is what I'm doing to let it happen without requiring to create other build scripts or move files across the build system.

I'm using a very simple Node.js server hosted on Heroku.

The first thing to consider is the fact that both Heroku and I use git for versioning, so I need a solution to handle both repos, as they cannot overlap in the same directory.

To solve this problem, I change the final build output dir defined into Grunt.js from dist to heroku/dist. This way I have a subdirectory of freedom between raw code and built code. The heroku directory is where I'm creating the Heroku repository. The heroku dir needs to be added to the .gitignore file of my app's repo, so that it doesn't track build files.

To create the Heroku app I move to the heroku dir and I follow the instructions provided on their help page from Local workstation setup to Deploy your application to Heroku.

I also need the package.json file in the heroku dir, so I'm creating a hard link from the main app directory instead of copying it, to avoid duplication of data.

I also modified the web.js file, in order to serve gzipped files, using gzippo:

var gzippo = require('gzippo');
var express = require('express');

var app = express.createServer(express.logger());
app.use(gzippo.staticGzip(__dirname + '/dist'));
app.listen(process.env.PORT || 5000);

And here is the package.json. Highlighted in yellow is what should be included in order to work:

{
    "author": "My name",
    "name": "my-project",
    "version": "1.0.0",
    "dependencies": {
        "gzippo" : "0.2.0",
        "express" : "2.x"
    },
    "engines": {
        "node": ">= 0.6.0 < 0.7.0"
    }
}

To summarize, the heroku folder now contains:

• the original Yeoman's dist folder, that contains the app ready to be deployed
• Procfile, which has the instructions for Heroku
• package.json, that lists the project properties and dependencies
• web.js, used to instantiate the node.js server

Doing so, I can build my app with the yeoman build command, and have my files ready to deploy on Heroku without adding any other build scripts!

Moreover the site gets 91/100 points with PageSpeed, I'd say... not bad!

Let me know if you have any questions or suggestions to improve this solution!

If you're interested, here is my app:
http://gfc-thelab.herokuapp.com/

I'll be covering the details when it's done :)

UriBuilder - a Closure Tools example

Lately I've been playing around with Closure Tools, a set of web development tools open sourced by Google.

It consists of different packages that can be used either on their own, or together for even better optimizations.

Here is a quick summary of the features:

• Closure Library - a collection of optimized and cross-browser JavaScript reference types
• Closure Compiler - minifies and optimizes Javascript code
• Closure Templates - generates JavaScript or Java files from a template
• Closure Linter - checks the style of JavaScript code, including the correctness of documentation
• Closure Stylesheets - adds functionalities to CSS stylesheets

I made this simple web application that combines all of them!

You can also enable source maps if you are using an updated version of Chrome.

The code is available on GitHub. The app itself is still a work in progress (suggestions for additions and optimizations are very welcome), but the interoperability between the Closure Tools is already up and running.