MelbJVM meetup #4

Last night I attended the 4th Melbourne Java & JVM Users Group meeting, and it was fantastic! Here are the highlights.

• Pizza, beer, over 30 40 developers all talking to each other.

• JBehave. The first speaker was Aaron Walker who gave a presentation and short demo on JBehave. JBehave is about Behaviour Driven Development - it's a way of writing tests in plain English and is perfect when you need to communicate tests to (or collaborate on tests with) other teams such as BAs or testers. A quick example is below.

  Scenario: User signs up with invalid data
  Given I am on the sign up page
  When I fill in "Email" with "invalid email"
  And I submit the sign up form
  Then I should see error messages

  The scenarios can easily be written by testers or BAs or devs. The Given, When, And and Then clauses get matched to actual Java test code through annotations, e.g.

  @When("I fill in $email with $data")
  public void enterEmailAddress(
        @Named("email) String email,
        @Named("data" String data) {
     // ...
  }

• Technology Radar by ThoughtWorks. The second speaker was Scott Shaw from ThoughtWorks who presented a register of technologies and techniques that ThoughtWorks maintain called Technology Radar: http://www.thoughtworks.com/radar. It is essentially a survey of a wide variety of tech options ThoughtWorks thinks you should Adopt, Trial, Assess or Hold (avoid)! Important Adopt items included REST, HTML 5, polyglot persistence (relational DBs are not the only option) and polyglot programming (Java is not the only language that runs on the JVM). Interesting Avoid items included Enterprise Service Bus, Java Portal Servers, GWT and Dart.

  I think one of the most important Adopt topics Scott discussed was Infrastructure as Code: there are so many tools now that automate the setting up of a server. You should be able to completely automate the initialisation of a server, it's configuration and deployment of all applications/DBs. These automation scripts etc are infrastructure that should be treated just like code: kept in source control and executed as needed. The consequence of this approach is that you shouldn't need admins to continually log into systems to configure them - human involvement means room for manual error: adjust a script, trash and re-create the server as needed.