fetching ember.js Handlebars templates with jsonp from Scala on Play!

As a setup I should mention that our ember.js javascript application is hosted on a third party page. Since we're using ember.js, the best templating solution is to use Handlebars. The trivial use case of handlebars is to embed the templates in the page itself via a script tag of type="text/x-handlebars". In our case, we're hosted so we can't really control the host page and even if we could, we shouldn't litter it with our templates. Moreover, there are many templates we would use in edge usecases, fetching them all on load will not be a good idea.
The solution we came up with is to fetch the templates on demand or pre-fetch if we see the need coming. Its best to keep the templates as stand alone files, its easier to revision and A/B test with variation of them. On top of that, we must handle the cross domain issue. In our case we decided to go with jsonp instead of CORS. On the javascript side: Note that in the response, the function gets the template html as a string and pass it onto the Ember.Handlebars.compile function to compile it to a handlebars template. Ember.js makes the template globally accessible from code or as an embedded view via the Ember.TEMPLATES map. When creating an ember.js view one should simple point to the template id as in:
On the server side we use Play Framework 2.0. Over there we have a rout in the routes file as in: It basically passes the name of the template from the path and name of the jquery's jsonp callback from the url args.

On the scala side things look pretty simple. Naturally you would like to check for security properties, string injections and A/B testing groups. [plug] QWallet is hiring!

Testing javascript with Play Framework 2.0 and JsTestDriver

At qwallet we're building an extensive javascript application backed up by a Scala on Play 2.0 backend. Since I'm using IntelliJ IDEA for the scala development, I'm using it for javascript as well. The nice bonus that comes with that is IntelliJ's integration with JsTestDriver.
While working on the javascript app I have it constantly tested on three captured browsers:

The test console shows the test results (super fast) and any console output that got fetched from the browser, e.g:

In the above test example you can see all tests are passing on firefox and chrome, but fail on safari. The sample has three test cases, the expanded one has two test methods. If there's an error, the stack trace is clickable and intellij will take you right to the line of the error. The tests are pretty fast, 6ms on chrome for this small subset means there's some room to grow.
The extra sweetness of Play2.0 is the auto compilation of javascript files. In dev mode the JsTestDriver is serving the library files and test cases to the browser and the application files are served through the Play2.0 application. Play will recompile the files as it detects change. It gives an extra coverage as in many cases the compiler catches things that I may have missed when writing the test.

On CI mode there is no need to pipe the javascript files through play as the files are compiled once. Not that its much faster this way, but it reduces the need of having play running in the background. As we're going to have qwallet operating in Continuous Deployment mode, testing all parts of the application is crucial. JsTestDriver bundled with the closure compiler provides a nice component in the testing strategy with its fast dev mode unit testing.

BTW, we're hiring. If you're interested, shoot us an email to jobs@qwallet.

Throw undeclared checked exception in Java, take II

Wrapping is in many times a necessity as you may not be able to throw a declared exception for contract restrictions or want to reduce boiler plate code. Wrapping an exception with a RuntimeException is sub optimal, takes more resources and clutter the logs with unnecessary stack traces, makes you look for the root cause.Loved Alexey's idea about throwing undeclared checked exception in Java. Here is a small twist on that AnyThrow class:Now I can do So the compiler and the reader knows I'm breaking the flow with an exception. The stack trace does not have the AnyThrow in it and the "return null" there is only to trick the compiler.

Testing Guice can init servlets

Sequel to the prev post, binding servlets is not enough. You must make sure that Guice can initiate them. For example, a common error is not binding servlets as singleton, there you get exceptions like

ServletException: Servlets must be bound as singletons. Key[type=my.servlet.FooServlet, annotation=[none]] was not bound in singleton scope.

Here's a way to test for all servlets in Guice context When calling init on the filter it would init all servlets in context.

Testing Guice Servlet bindings

Evan if you work with Servlet (for the record, I hate j2ee) and Jersey you can still enjoy Guice.
Unfortunately its not that evident how to test that the ServletBinder is binding your servlets to the right place. Here is a small Assert class that does that.