$(‘#2012’).on(‘success’, function(events) {..});

Personally, for me this year, my biggest technical advances were:

  • Learning bash scripting, provisioning servers, deployment scripts.
  • Developing on a Mac… yes I know i’m behind the curve here 🙂
  • Changing to IntelliJ from Eclipse… it’s worth the $$$.
  • Forcing myself to use Sinatra to build an app rather than Rails… and building it up to the point where it is becoming a Rails app.
  • I will migrate it across once Rails 4 goes standard. This helps me appreciate what Rails gives you, what it forces you into, and understand more about which modules it wraps up and the conventions it gives you.
  • Learning the in-s and out-s of underscore.js and backbone.js – you can read and read but to grok it you need to code in it.  Underscore.js in particular is like an ant… a small creature that can lift 100 times it’s weight. Kudos guys it’s invaluable and gives much cleaner / functional code in javascript.
  • Getting a nice 14″ Lenovo i5/SSD/8GB to use on the train… any larger is uncomfortable. The new Mac Pro 13″ looks like a good size too.
  • Spending time *away* from code to give my ideas time to settle / step away from the keyboard. As valuable as coding itself.
  • Getting a Telstra 4G phone to use the internet on the train… for better or worse, the Telstra mobile network is very fast and reliable.

error: 2013 is undefined


Tips to increase your dev-fu (java devs mainly):


  • switch to IntelliJ / RubyMine – fast searching (maybe notepad++ / grep / sublime is faster?) and if you are doing CSS / Javascript development I find it’s the most productive IDE for me.
  • spend 10 minutes every day asking yourself how to improve your IDE / environment… what do you spend the most time doing each day that is repetitive?
  • learn REGEX. It’s everywhere… if you have to replace/modify more than 2-3 LOC, use a find/replace. If that doesn’t fit, REGEX is your friend. Also learn SED once you’ve learned Linux 🙂
  • printout that keymap of your IDE… circle shortcuts you wanna learn then make a concious effort to learn them.  Test yourself the next day / week by trying to recall it with your muscle memory. Practising on different computers / keyboards reinforces it… especially mac vs. non-mac keyboards 🙂
  • Pair!!! I have learned the most shortcuts / configuration options from pairing or looking at others IDEs and asking questions.
  • Consider Chrome your browser of choice.  I was Firefox for a long time, but Chrome seems quicker and i’m more productive on it now.
  • if you are a frontend dev, research a bit on browser plugins for helpful tools like screen resizing, URL testing, JSON parsing, CSS reloading etc.
  • learn Linux, learn the shell and the command line…
  • learn Git (if you haven’t already), setup a few repos, patch some code on github.com – it’s good for the soul 🙂


Lately i’ve been doing alot of javascript development in my spare time. Spikes, little libraries, like HTML validation and logging.  When you’re righting event-driven code, TDD and logging help you quickly track down problems in your code.

The playing field has changed in Javascript and on the frontend over the last few years, and i’d like to share the tools and utilities I now use for my spare-time projects:

XDate : gives you nice decorators over a vanilla Date object (which is pretty basic and outdated) including parsing, formatting and manipulation without all the headaches.

Normalize.css : Best of the CSS resets.

Modernizr: Good for targetting many platforms (especially non-PC eg. mobile and IPad – helps with feature detection)

JQuery + Bootstrap 2: This one is a no-brainer.  Gives you responsive design (*-fluid), thoroughly tested and customisable and using Less or bootstrap-sass, can easily change styles globally.  Becoming a defacto standard.

Underscore.js:  I’ve found most people that have used Ruby like this library, it’s neat and powerful…

Backbone.js + Model.Binder – Backbone is useful even if you are grafting it to a legacy app, since it gives you basic object-oriented grouping of data and methods.  It encourages OO design in javascript, which also encourages a basic separation of DOM and data/functions.  There are some aspects I think are too basic, especially once you get into non-trivial models (toJSON() for example, is not recursive) but for alot of simple stuff it gives you cleaner, testable code and good separation of concerns.

Jasmine: If you are familiar with RSpec or keen to learn, start using Jasmine.  It’s probably the strongest testing suite for javascript and has good integration to both ruby/rails and java.  I use it even on vanilla javascript projects.

Working Together

Working on a new project is a great way to review what you think you know in a different application. I think as a veteran developer, the hardest part of doing our job is to avoid doing just the ‘cool’ stuff and being continuously objective about the work you are doing.

Devs will often spend more time on things they think are important which really aren’t in the scheme of things. A good dev will figure this out him/herself without help, and benefit the team and the product for doing so.

The other side of the coin is that the business isn’t always aware of things which would add efficiency to the product or process and can be hard to convince, even with several team members’ support.

Establishing trust in the environment is paramount to working together, and eroding that trust is so easy that it is a cautious game. The other issue is that building trust happens best when you achieve common goals, and many people will change jobs within a few years. It also seems like the less time you have been at a job, the more passionate you are about it, and the more energy you give the project.

Perhaps the solution is to only have short projects? =)

A good question is how engaged is the team? How often do you see people working together? You will normally see groups of people in the same process (streams) working together, and eating together. This is because you need a level of teamwork day to day to do your work. Examples are developers with developers, testers with testers, BAs and product owners.

A more important question is how often you see people from different streams working together, having whiteboard discussions, creating stories or eating lunch together or socialising. Forget metrics, KPIs, meetings, building a good relationship will pay off in orders of magnitude. Why?

If you build a relationship, you build respect and trust. Even if it’s not work related. You also build empathy.

By building empathy you tune your listening skills. You put yourself in the other person’s shoes and try to understand their points of view. Having two-way empathy and understanding is the ultimate level of communication.

Spring 3.1 not showing field errors using spring tags

After upgrading from Spring 3.1 we noted that many of our forms which have validation logic in the server side stopped displaying the error messages back to the original form submission.

Seems in certain circumstances when you create and return a new ModelAndView the BindingResult object is not appended to the Model automatically.

Adding the following lines is a quick work-around.  

Assuming method signature of:

public ModelAndView someMethod(@Valid User user, BindingResult result) {

if (result.hasErrors()) {

  ModelAndView modelAndView = new ModelAndView(PAGE);

  modelAndView.addAllObjects(result.getModel()); // added this line

  return modelAndView;



In our case we are not going to continue with this way of posting forms so we won’t invest more time in this.

I also noticed Spring has adopted the rails/grails ‘flash’ object which uses the session as a shared data store to pass messages or objects in between server side redirects, not a great pattern really.  Most Client MVC apps don’t need this complexity.

Learning new languages and their expressiveness

Syntax can be hard to learn. Although I have trouble reading lisp / clojure / haskell, I respect that for those who understand it is a simple pleasure to write code in.

The problem, as highlighted is not limited to computer languages. Often people who try to learn another language from English continually say “but why do they do it like that? English does it better.” Unfortunately, learning your first language (eg. mother tongue) is vastly different in approach from learning your second and third.

Many times learning the second is the hardest – why is this? You have to open up your cemented neural pathways to the idea that something can be expressed in a foreign way. Unlocking those pathways is hard, as it is like fighting an inertia you have had for a long time.

I learned Spanish, then French. After that I find my ability to learn languages is vastly easier. Why? Because I understand the concepts of tenses, gender, case, mood and respect the subtleties of each language.

I no longer learn concepts, I learn the implementations and the nuances of each language. The same now for most programming languages. In a language, I need to express conditionality. I need collections and looping, filtering
and transforming. I don’t need to learn these concepts again so I can pick up languages quicker and quicker as I learn more concepts.

I now see a trend towards less shared-state/synchronised realtime applications and a strengthening towards functional (map/reducible) programming and languages supporting shared-nothing and actor patterns. The interesting thing is that we used to think by sharing state an synchronising it was faster and more scalable than copying objects and using more memory. Now it is more scalable to do exactly that.

We now have the programming power, the memory and the disk space for almost anything – we are now stripping back our programming languages to make it ‘easier’ for us to write code. By easier I don’t mean we are writing simpler code. As Ola Bini points out in his blog programmers are wanting a higher level of expressiveness. To do this, we have to make some assumptions like we are not going to share and synchronise data/state everywhere in our application. Sure, it may happen on the database or in a 3rd party library like an aggregator, but we as expressive functional programmers don’t want the bother of covering all those horrid edge cases which are hard to debug and harder to reproduce. I’ve seen some shocking issues with ThreadLocal being used and abused. Which happens alot.

In my own code I have found issues where I have overridden variables or options to my own detriment. Each time thinking ‘if only I had put that into another (usually local) variable. I believe this is the biggest (current) pitfall in Java. It is too easy to modify the contents of objects from any library which has access to it. It almost sounds like a security flaw. It’s calling out saying “hey, you there. You want to use me somewhere else? Don’t clone me, oh no. Just change my state a bit. It’s alright. Surely.”. No.

I am finishing a book on Beginning Scala at the moment, which sounds interesting but mostly just copying the good things in Ruby and cramming it into Java-esque syntax. For these languages it is more important to learn the ‘idoms’ of the language, which is what should give you more expressiveness.

Ruby has alot of this. I am awed that this language was created over 15 years ago. It is a beautiful and expressive language. It reminds me of going from Windows background and learning Linux. You can do some really powerful stuff,
and you can really get yourself into trouble (metaclass?). Guard the gates of expressiveness and you will be treated with a powerful tool.

My next blog post will talk about JRuby in detail.

Agile… enough?

We’ve been doing a few inceptions in agile lately, and the question always comes up… how much work should be done for ‘this’ story? Well, you define your acceptance criteria, then you estimate your work based on that being completed and functional.

Honestly, there is so much more to it than that. There will always be acceptance criteria you miss out at the start, but perhaps you will cover the 80% of use cases. Perhaps you have to design a new pattern, so that other stories like the current one can be done quicker in the future, or perhaps you need to spike first because of the unknown estimate. Perhaps you need a 3rd party library to incorporate, so you need to wire that in and test it too.

Even in agile, I find myself asking, how much (or rather, how little) design is just enough? It really depends on the project. If the code is being rapidly developed, screens changing every day, database schema in flux, then perhaps you don’t want to do anything you don’t have to for that story, lest it be thrown away tomorrow and your efforts wasted.

Any developer hates the idea of their code being thrown away, it’s in our nature 🙂

Two areas I sometimes struggle with is a) only do enough to make the feature work and b) don’t think about things in the future. If you take b) as gospel, it means you will never refactor. I have seen developers go down this path. The code works, they iron out the bugs (with scant test cases) and it goes to production. They develop work quickly, but slowly but surely the code is polluted by duplication, wrong responsibilities in the wrong classes, or tight coupling due to bad design and/or lack of tests.

The begging question is how do you monitor this to stop it happening?