I’ve since recommended it several times to other people who were interested in building applications new applications. Most of the this feedback has been extremely positive so I’ve managed to get around to having another look at it recently. After @snaglepus suggested I check out Build twitter in Grails in 40 minutes (registration is required) I have to say I was very impressed. Since watching that I’ve gone from knowing absolutely nothing about Grails (three years it too long to keep information in memory) to building a sample application very quickly. After finding plugins for many of the tasks I wanted, I’ve implemented the logic I need and let the tool do the rest of the heavy lifting work which led to a very productive evening of coding.

I really love it when you find technology which just seems to work and does exactly what you expect it to do. There is still much I want to learn about Grails and I’m sure there are many other tips and tricks I can pick up along the way. At the minute I’m just looking through the many Grails books to find a winner and I think I have in The Definitive Guide to Grails, Second Edition. If you haven’t looked at Grails before, I really recommend you check it out and see what it can do for you. And if you aren’t following me on Twitter, I’m @pramatrdev and I’m sure there will be a few more tweets about Grails before the month is over .

I love a well documented API as much as the next developer. I also am fighting a constant battle to improve my JavaDoc skills, trying to write to the same quality that I see in many other projects. But is excellent documentation really enough? It can’t just be excellent when it’s written it needs to be constantly maintained to this same level over time.

It’s a pretty common occurrence that I can look at a section of code and find documentation that has nothing to do with the method it belongs to. The intention revealing name sounds nothing like the documentation which describes what it’s supposed to be doing. Somewhere in the mists of time, the intention of the method and the documentation parted company; it is documentation no more it is ex-documentation. The problem here however is that there’s nothing to catch this issue. If an extra argument is added, Eclipse might display a warning telling me it’s missing from the documentation, but the actual context of the documentation can be completely wrong and I am none the wiser.

Although this incorrect documentation may seem fairly harmless to some, the reason it was supposed to be there in the first place is to the give the user of the API information on the method contract and the expected outcomes. If this information is completely wrong however it introduces confusion and also potential misuse of the API. After much wasted time and several grey hairs later I recently filed a couple of JIRA reports about popular open source frameworks which did exactly this. After my code just didn’t work and the unit tests failed, it took me a number of minutes to realise that the JavaDoc description of expected events just didn’t reflect what was actually going on in the code.

One approach to solving this problem is to include the documentation in the frequent code reviews. Code that doesn’t have documentation or has incorrect documentation can’t be considered complete, thus doesn’t pass the review. Developers need to make sure however, that they treat the documentation with the same respect that they give to their code and their tests. When dealing with documentation I’d much sooner see a method with no documentation than something that is completely wrong. I do want a good level of documentation in the code I work on but there is a very simple rule; update it or lose it.

For those people who have never played the blame game before, we need to set out the rules. The rules are actually quite simple, if in doubt seek the advice of a seasoned player. The first rule of the blame game is, it’s never your fault. The second rule of the blame game is, it’s never your fault. The third rule of the blame game is, it’s always some one else’s fault. So now we’ve established the rules, we need to work out some tactics to work out whose fault it actually is.

The first candidate for blame always has to be the last person to leave the company. Anything that’s wrong can easily be blamed on them, after all they can’t defend themselves so they make an ideal target. The next candidate can be chosen from any of the temporary staff you currently employ, the shorter the contract the better. If you aren’t going to have to see these people for much longer, this should work out quite nicely. The next candidate is anyone that’s working for the company in another location (if it’s another country this works even better). You might have to work with these people again, but you’re probably not going to see them on a daily basis, it shouldn’t be too awkward. Now this is where your choices start to become a little tricky, you’re down to the people that you work with everyday.

You have to keep this simple and align yourselves with the strongest members of the team, after all this is survival of the fittest. Fit yourself nicely into the crowd and look for anyone that doesn’t quite fit, this is real back to basics school ground behaviour. Pick off the weak and vulnerable first as these shouldn’t put up much of a resistance, then work your way up the power hierarchy until you find your patsy. So there you have it, those are the basic tactics for the blame game you might have to tweak as appropriate within your organisation but the general approach should apply.

The most important decision you face when presented with the blame game is do you really want to play? If you decide that it’s really not for you, the best way to deal with it is to simply throw out all of the rules, rip the board in half, stamp your feet as hard as you can and shout out loud, “I refuse to play”. It is often said that; “we work in a blame free culture, until something goes wrong”. Are you really interested in finding someone to blame when something goes wrong? Will it really help the customer solve their problem any sooner if you’ve found the person to carry the can for the failure? In the time it takes to sit there and rack your brains for potential candidates to take the blame, you could already be investigating the cause of the problems and attempting to fix them. In his recent post Sean Landis said;

Successful Agile development presupposes that team members will all act like adults. That’s a euphemism for being competent and professional. Agile teams are expected to accept a high level of responsibility and accountability. When they don’t, things can fall apart really fast.

Regardless of how bullet proof a process claims to be, there are always going to be issues that weren’t found prior to the release. If issues are always going to occur, should teams really be allowed to turn on each other in response to them, will this really lead to a better working relationship? The most important thing is that problems are dealt with promptly and professionally when they arise. Instead of trying to assign blame, people should be responsible for their own actions, they need to learn from the experience and measures should be put in place (if possible) to prevent this happening again. Next time your team is out celebrating your latest release and your mobile phone starts to ring, do you really want to start playing the blame game?

Currently the roads are covered in snow, buses, trains and planes are cancelled and I’m stuck at home, and I’m costing my employer money. Some employers might expect you to turn up regardless of the weather. Some employers might take the “snow day” out of of next months wages. Some employers provide the means to let their employees work from home. It is obviously not logistically possible for every business to allow working from home, but what about the ones that can? In a quote from the BBC report, Keith Tilley said;

“Employers need to do everything they can to allow staff to work from home and ensure that those that do manage to travel to work are well looked after, with overnight accommodation if necessary.”

Many businesses are turning to technology to allow their employees to not only work from home during periods of bad weather but also during peak demand. These virtual call centres are proving extremely popular with more businesses turning to this technology to provide a more permanent solution. Many businesses could benefit from this approach but lack the technology to actually make it possible. Is this technology too expensive, too complicated or is there simply a lack of knowledge about it’s usage?

A quick search in Google yields a range of solutions that can make working from home very possible, one of the best is a VPN. At one end of the spectrum is OpenVPN which retails at £0 (or $0). It’s open source; download it, install it, configure it and you’re ready to go. There is obviously an associated learning curve, but for most people with a technological persuasion it should be quite straight forward. If you don’t want to have to install and maintain software, another top result is Barracuda SSL VPN which starts to retail at £1250 (or $1800). It’s an appliance; turn it on, configure it and you’re ready to go. Both solutions provide the means to be virtually on the network without having to be physically in the office. Access can be provided to email, file servers, internal Web sites and office workstations. As a developer I can access CVS, SVN, our Maven repository, Hudson build system and any other resource I use during my normal working day. I can be just as productive (often more so) as if I’m really in the office.

There are a whole range of products that allow employees to work from home, but there really should be something to suit every businesses budget. Some businesses worry about letting employees work from home, but even if the technology is only used for extreme or emergency purposes, at least a business can suffer near zero downtime. Even if the technology is only used once or twice a year, it can still provide a return on investment for the smallest of companies. We currently have six team members connected to our SSL VPN, our business is counting the cost of the bad weather, but fortunately for us it should be somewhere near £0 ($0).

I read a thorough discussion of the malware behaviour many months ago, but I don’t think this is quite what google were looking for when they implemented the feature. I’m sure there are a great many retailers who are cursing at potentially lost revenue and users who are now unsure if a website is harmful or not. False positives are never helpful to users who are unsure about their actions at the best of times. Thankfully, the problem seems to be sorting itself out and only seemed to last for twenty minutes. It’s not yet apparent whether the issue has been rectified or simply that the feature has been disabled altogether. It will be very interesting to see how this one is explained!

Update: It seems the problem was bigger than I thought.