The week in review - 2008-47

It is a good time for releases:

Looking around the train platform today I wondered when telecommuting is going to make a significant impact. Everyone needs to be somewhere else - and that puts a lot of strain on the public transport infrastructure. I've had few jobs I couldn't have done from home effectively with decent video, voice and remote control software. Being in an office *would* be far superior if teams were effective, but from my experience most of them are dysfunctional. I think part of the problem here is that managers measure productivity by the time spent at your desk, not by your actual achievements.

Know any companies that have effective management, well run teams, good career path and its fun to work? Let me know, because I'm always looking.

I was just listening to an episode of Agile Toolkit and it just makes agile seem like a whole different world. I'd love to spend some time at some of these companies that are *really* doing agile development. I've encountered companies that pretend/claim they do it by:

  1. having meetings in which you cannot sit down

  2. using junit

  3. use the jargon (iteration/pairing etc)

  4. pair when there is a problem

In this podcast, they mention some of the reasons why agile doesn't get implemented properly and as a result fails.

Here are some interesting tips for MS Windows users. Notice the recommedation to use FireFox and VLC media player - these get my thumbs up. MemoKeys is something I've been looking for recently - I've been looking for some software that lets me store text snippets (sql, command lines etc) and paste them with a key stroke. Thanks Ruchir! Unfortunately I can't install it at work because the PCs here are configured to stop any set.exe installers running - thanks security. Security sooo good its hard to get your work done.

I like to do small pieces of work and commit often. But when tests take a long time to run you get put off doing this quickly - running lengthy tests frequently means you take a nose dive in productivity. So you start taking risks and commiting more code less frequently - and end up with a mess. Whats the answer? Don't create long running tests. Do more UNIT testing, and separate your integration tests out into a separate test suite. Unit tests that don't hit the database are fast.

I used to think it was okay to put a continuous integration server on any old PC - but now I'm thinking I want pretty fast feedback after commits. So I'd rather have it on decent performing hardware so I can know when something goes wrong minutes after the commit. And, after commiting a fix, I want to trigger a build and have the answer NOW. Not in 10 minutes. So, CI on fast hardware = GOOD.

I haven't been doing much coding at home lately, so when I do, I need to be careful to leave my 'heavy lifting' JSF attitude at work and switch into a more 'spritely' Grails attitude. Point in case, I recently typed this into a grails controller:
[sourcecode language="java"]
def id = request.getParameter('id')
def book = Book.get(Integer.valueOf(id)) // but what if id is null?
It was then I thought I'd better do some null checking - and the little light bulb went on - this was getting too hard! So I replaced it with:
[sourcecode language="java"]
def book=Book.get(
And thats all I needed. No null checking, no type conversion. Sweet, I love the productivity of Groovy and Grails! I would have thought the 'Enterprise' would have been the first to adopt such productivity - after all they want to lower costs and produce more! What is stopping them? Why does 'Enterprise' = HEAVY LIFTING?

Popular posts from this blog

Using the Crystal Reports Java API to generate PDF

No Scope registered for scope request

Using Selenium WebDriver to select JSF/PrimeFaces selectOneMenu options