There’s a big performance difference between for and foreach in JavaScript. My preferred method for iterating over things in JS is to use underscore.js’s _.each() function – I’ve just looked up the source code and it uses for which is the most efficient option.
I become quite attached to FactoryGirl during my first professional foray into Ruby on Rails earlier this year, so this week I was researching Java alternatives. I found a great explanation of the Data Builder pattern and its application for testing. Java being Java, it’s still a bit bloatier than FactoryGirl, but a big improvement on the massive copy and paste Object Mother style testing I’ve mostly been exposed to.
Java has its own weird quirks – new BigDecimal(600.9); is not equal to new BigDecimal("600.9"); is not equal to new BigDecimal("600.90");. Java, my love, how could you do this to me? I expect this nonsense from JavaScript, but not you.
As of Java 8, interfaces can have “default methods”, i.e. an actual implementation of the method. I got my head around PHP 7’s traits towards the end of my last PHP job, and I’m pleased to have access to some sort of multiple inheritance in Java now, although until we can define member variables on an interface they will be of relatively limited use.
ExpectedExceptions are the new kid (well, “new” if you’ve been away from Java for a few years) on the how-do-I-test-my-code-throws-the-right-exception block. Compared to my former goto approach (a try-catch which fail()s at the end of the try, they are a much more elegant way to check that the right Exception was thrown with the right message, but don’t offer the same flexibility to check that object state has been cleaned up before bailing.