Chariot Training Classes

Training Courses

I run Chariot's training and mentoring services. We provide training in AngularJS, HTML5, Spring, Hibernate, Maven, Scala, and more.

Chariot Education Services


Chariot Emerging Tech

Learn about upcoming technologies and trends from my colleagues at Chariot Solutions.


Chariot Conferences



Philly Emerging Tech April 2-3 2013 - Register today!

Remember that conference in the spring? Well, it's baaack! Yep, it's 2013, and so we are full-steam ahead, planning for the next Emerging Technologies for the Enterprise Conference, to be held at the Sheraton Olde City in beautiful Philadelphia on April 2-3.

We have quite the show lined up for you, with keynotes from Rich Hickey, the creator of the Clojure language, and Media Six Degrees' Chief Data Scientist, Claudia Perlich. Notable speakers include Ember.js creator (among other things) Yehuda Katz, Jessica McKellar of the Boston Python User Group, contributor to the Python Twisted async network library, the inimitable Aaron Patterson (if you want a laugh, listen to him rib us about our conference name in his Code Chacuterie talk of 2012)...

Also we have Cliff Click (0xdata), author of "Java Performance" Charlie Hunt, Go contributor and creator of Sinatra Blake Mizerany, author of "The Culture Game - Tools for the Agile Manager" Dan Mezick, Jurgen Appelo (author of Management 3.0), the creator of the Scrum process, Ken Schwaber, and more are being added every day.

We even have Angluar.js expert Lukas Ruebbelke (see Angular.js), a Google-sponsored "single page Javascript" client-side application framework that uses JSON/REST and has live two-way data binding. (I didn't even realize we booked him when I published this so ignore my earlier version where I said I am speaking on this topic). And as usual we'll be recording sessions and hopefully podcasting too.

More speakers are being booked each week.

So, don't delay. Last year we sold out with two months to go, and I think as we add additional awesome speakers the competition for a ticket will get intense. Register today at

If you want more incentives, the early bird registration is just $385, and ends on February 15th. After that prices go up to $450 (still a steal, but why not save and register now, will ya?)


The future of Web MVC testing

Ok, ok, I'm excited. Right now I just was able to hack my way through a test with Spring 3.2 and the new test web context.

The method I ended up writing looked like this:

public void tryStartQuiz() throws Exception {

How did I get here?

I upgraded to Spring 3.2, which has native support for loading Web contexts (well, not in a separate-but-parent/child way where you can mount the web context and business context separately, that's coming, but in one context).

Here is the top of my test class:

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;
import static org.springframework.test.web.servlet.setup.MockMvcBuilders.*;

@ContextConfiguration(locations = {
public class EngineControllerTest {

    WebApplicationContext context;

    MockMvc mvc;

    public void setUp() {
        mvc = webAppContextSetup(this.context).build();


Some analysis...

The MockMvc object, which I referred to as this.mvc in my test, allows me to mock up the web container request and record expectations. It is created in the @Before method, after Spring injects a test WebApplicationContext object, which is driven via the @WebAppConfiguration above.

The WebApplicationContext object is a web app engine in a test engine. It boots a Spring MVC platform, mocking the network engine so that you can submit requests with calls like mvc.perform(get(...) ... and chain assertions, using .andExpect statements to build conditions. It's like headless Spring MVC. This allows you to test by submitting URLs but without having to configure Jetty or Tomcat in a complex server bootstrapped integration test.

But where is it looking for my webapp?

As a nice touch, the default path for the web application is src/main/webapp. If you're not mavenized, or have a test version of your webapp you want to use, you can submit the path to it as the value of the annotation, like:


Assertions and matchers

There are several static imports that make life easier, as outlined in this great slide show from the MVC team (Rossen and friends):

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;
import static org.springframework.test.web.servlet.setup.MockMvcBuilders.*;

I had to hack a bit with the commands and don't have the DSL figured out much so far. But it is nice to test through the request dispatcher rather than inject a controller directly. It's more natural and lets you really test the way production will handle your requests/responses.

What about more sophisticated checks?

The expect syntax doesn't really allow dicing and slicing of the response as easily as grabbing it in a variable. You can tell the mock MVC object to return the result, which contains the MockHttpServletResponse. In this example, I'm using FlexJson (from Roo's dependencies) to deserialize the JSON request into a HashMap of string keys and values, and assert that the data exists in the proper format.

public void tryStartQuiz() throws Exception {
	JSONDeserializer<HashMap<String, String>> deserializer
			= new JSONDeserializer<HashMap<String, String>>();

	MvcResult result = this.mvc.perform(get("/engine/start/james"))

	Map<String, String> jsonPayload =

	assertThat(jsonPayload.containsKey("quiz_id"), is(true));
	assertThat(jsonPayload.get("nickname"), is("james"));



Roo and Spring 3.2

One more thing - I came from Roo 1.2.2, and as I upgraded the spring.version property to Spring 3.2 (yes, it works just fine) so I had to add one dependency in order for this to work, test scoped:


Roo was just upgraded to version 1.2.3 this week (check it out here). I am hoping it uses Spring 3.2 out of the box.

This test will be checked into the next update of Quizzo-Angular-Roo - my current obsession which is using Spring Roo on the backend, and Angular.JS on the front-end, for a single-page JS quiz engine.

Where to go to view the code?

Today I've pushed this code (somewhat modified) along with working Jasmine tests, AND a working Maven test suite that includes automatic Jasmine testing every time I run mvn test. Check it out at quizzo-angular-roo on GitHub. I warn you, it will be primitive and so far not really doing much, but it will shape up over time.


todo-txt - very cool GTD task management from anything

So, just I stumbled on Gina Tripani's todo-txt project when searching for a cross-device todo management system. I am switching from an iPhone to an Android device as I'm prepping to provide some Android training for Chariot in the early part of next year.

todo-txt is a very simple format. Described here and with a client for virtually anything (including the command-line, vim, Android, iOS, even WebOS) you can use it from anything, even a text editor. The clients are all savvy with Dropbox, so putting it on ~/Dropbox/todo is all you need to do.

Here is a groovy script I just wrote up to play with my todo list...

def todoFile = new File('./todo.txt')
def fileReader = new FileReader(todoFile)
def todos = fileReader.readLines()
def projects = [:], contexts = [:]
todos.each { it ->
  println it
  def tokenizer = new StringTokenizer(it)
  while (tokenizer.hasMoreTokens()) {
      def token = tokenizer.nextToken()
      if (token.startsWith("@")) {
          def size = contexts[token] ? contexts[token] : 0
          contexts[token] = size + 1
      if (token.startsWith("+")) {
          def size = projects[token] ? projects[token] : 0
          projects[token] = size + 1

projects.each { key, value -> 
  println "Project ${key} : ${value} tasks"

println ""
contexts.each { key, value -> 
  println "context ${key} : ${value} tasks"

Fun, eh? Now I can rid myself of the OS X reminders system - although I could really use the ability to store these in my Google calendar as timed events with due dates... Hmm...


STS 3.1.0.RELEASE - not loving Spock / Groovy for ADJT projects

At SpringOne/2GX I tried the updated Springsource Tool Suite, 3.1.0, running a pre-4.0 Eclipse (as the STS 3.1.0 version is a bit tricky on Eclipse 4 until the 3.x - 4.0 migration bugs settle down).

Turns out there is a new error that shows up if you try to run anything Groovy within a AJDT project (which is the AspectJ Developer Tools plug-in Roo requires to compile all *.aj files when you're using them in the IDE).

You'll get:

Error compiling Groovy project: Either the Groovy-JDT patch is not installed or JavaBuilder is not being used.

I realize from talking to one of the developers at SpringOne that there have been some issues with the way Groovy handles AspectJ compiled classes, and that using Groovy within a Spring Roo project as general code it won't work properly, but this puts a damper on Spock at least from within the STS IDE. I can still run my tests from IntelliJ, however.

I'm going to post a request in the forums that we can turn off this error, so that we can use Spock for testing. So far, at least with Roo add-ons, I have used it to great effect and productivity, so at least for that use case I'd like to have an option to turn it off.

More soon.



More Spock love - how I tested complex install scenarios

I'm in love. Officially. With Spock.

Ok, we've only been hanging out for a little bit, here and there. But one of the things I'm doing is prepping for an updated talk on Spring Roo add-ons at SpringOne/2GX. Rather than repeat the same things again, I wanted to show some practical help for people writing add-ons, things like how to write good tests.

Also, I wanted to point out a few things that need more work, bring up some issues for the JIRA queue, so that we can improve Roo further after SpringOne. We'll get to that later in this article.

Testing add-on availability

Testing whether an add-on setup command is available to expose to the Roo shell can be a bit tricky. For example, in the Spock Roo add-on, I expect that the user's shell is:

  • running in a project context
  • the project has to contain two maven dependencies for spock-core and spock-spring
  • the project has to contain one dependency for the gmaven-plugin to run Spock tests

So, there are several scenarios to test. I started down the road to testing them all individually. Bad developer. First off, there is a sort of truth table here:

depa, depbnonetrue
depa, depbpluginfalse
depabadversion, depbplugintrue


  • depa and depb = the correct two Maven dependencies,
  • baddep is a Maven dependency completely unrelated
  • depabadversion is the same dependency but a different version
  • plug-in is the gmaven-plugin from codehaus
  • expectedResult is whether or not we can go ahead and install the add-on (i.e. replace what is there)

As I started the third method I saw so much duplication I started to back off. First I removed whatever extra calls I was making to various methods (such as projectOperations.getDependencies()) which made it easier to test (and debug). Then, I pulled out the data table syntax.

Here is what I ended up with. Totally boss, BTW:

package org.sillyweasel.roo.addons.spock
import org.springframework.roo.project.Dependency
import org.springframework.roo.project.Plugin
import org.springframework.roo.project.ProjectOperations
import org.springframework.roo.project.maven.Pom
import spock.lang.Unroll

class SpockOperationsImplTest extends spock.lang.Specification {

  static def depa = 
    new Dependency("org.springframework", "spock-core", "0.6-groovy-1.8")
  static def depb = 
    new Dependency ("org.springframework", "spock-spring", "0.6-groovy-1.8")
  static def depabadversion =
    new Dependency("org.springframework", "spock-core", "0.6-groovy-1.0")
  static def baddep = 
    new Dependency ("org.springframework", "sbad", "0.6-groovy-1.8")
  static def plugin = 
    new Plugin("org.codehaus.gmaven", "gmaven-plugin", "1.4")

  def "install check - #situation"() {
      def pom = Mock(Pom.class)
      def operations = new SpockOperationsImpl()
      def projectOperations = Mock(ProjectOperations.class)
      operations.projectOperations = projectOperations

      def commandAvailable = operations.isSetupCommandAvailable()

      1 * projectOperations.isFocusedProjectAvailable() >> true
      1 * projectOperations.getFocusedModule() >> pom
      1 * pom.getDependencies() >> deps
      pom.getBuildPlugins() >> plugins
      assert commandAvailable == res

    deps          | plugins | res   | situation
    []            | []      | true  | "no installedDependencies or installedPlugin"
    [ depa, depb] | []      | true  | "all installedDependencies...
                                      but no installedPlugin"
    [ depa ]      | [plugin]| true  | "some installedDependencies...
                                       and installedPlugin"
    [ baddep ]    | []      | true  | "a different dependency and no plugins"
    [ depa, depb ]| [plugin]| false | "all installedDependencies and installedPlugin"
    [ depabadversion, depb ] 
                  | [plugin] | true | "bad version of a plugin"

What's even better...

See the method name at the top? It has an embedded hash mark, and uses the `situation` field, plus the `@Unroll` annotation, to turn the method into five separate test methods on the fly at test time. Niiiice!

Roo's challenges - addon testing

Why am I doing all of my testing in Groovy when Roo is a Java-based framework? Three reasons:

  • I want to get rolling on add-ons,
  • I need to understand the weaknesses of the add-on API so I can try to help improve it,
  • I need to make sure I test the most code for the least effort!

To the middle point: Roo is based on Maven and Spring. It manages a Maven `pom.xml` file, as well as Spring, Java and other artifacts.

Because the Maven files are managed by some Java wrapper classes, written for the purpose of generating Maven POMs, they are currently good enough - you can fill them via an Xml DOM, for example, but they aren't inherently testable.

For example, the Pom class can't be mocked, so I can't inject a fake set of dependencies or plugins. That is, unless I install two Maven test dependencies, both of which Spock told me to use as a helpful hint! They are: `cglib-nodep` for mocking interface-less classes, and `objenesis` for creating instances of classes as Mocks without no-arg constructors. To wit:



With that, I can use:

def pom = Mock(Pom.class)

See you at SpringOne/2GX

I'll be talking about this and other techniques at SpringOne/2GX in two weeks, and I'll post my presentation later as well. I hope to see some of you there.