Paul Grenyer

Thursday, 5 November 2009

Stranger in a Strange Land


by Robert A. Heinlein (978-0340938348).

This book lacks much real science fiction. At most it's a fantasy book. What it really is is a dig at society and religion and that, unfortunately, stifles a story that actually isn't there. Many science fiction books make these points as well, but that doesn't make this science fiction. If this was a relatively new book I'd say it's all been done before, but given its age, all I can say is that it's all been done again since and better. If I was reading it in the 1950s or when I was a teenage boy, I'm sure I would have loved it.

One ray of light in an otherwise dull read was one of the main characters, Jubal. The story is very much told through his, very sensible, view on the world. He understands everything perfectly, has seen it all before and is never fazed by anything. While everyone else is giving into their prejudices and preconceptions he is watching and making sense of it all.

The ending was probably the worst part. The main character is murdered for the good of the people, his followers rejoice and then he visits Jubal from beyond the grave. Time for some more Alistair Reynolds I think.

Sunday, 18 October 2009

Item 57 - Use Exceptions only for exceptional conditions

Using exceptions only for exceptional conditions is something we can all agree with. However, this item should have been named "Don't use exceptions for control flow and how to decided between state-testing method and distinguishing return value". Bloch gives an example of how exceptions can be used for ordinary control flow, two alternatives in state-testing method and distinguishing return value and how to choose between them. I was rather hoping for some discussion of what exception conditions are, not just a brief discussion of what they are not.

Thursday, 15 October 2009

Senior Java Developers – Norwich

I am looking for two senior Java developers to add to my team at Validus-IVC Ltd. (http://www.validus-ivc.co.uk/) in Norwich. Validus is a fast going growing company. It has only been incoporated for two years, currently employes around 60 people and is already in profit.

The only required skills are:

  • A firm understanding of Java
  • Robust Object Orientated software development.

Other skills include:

  • Automated Testing
  • Hibernate
  • Spring
  • Google Web Toolkit (GWT)
  • Tomcat

Please send CVs to p.grenyer@validus-ivc.co.uk.

Strictly no agencies.

Sunday, 11 October 2009

Java Dependency Management with Ivy Part I – The Basics

Along with the rich enterprise libraries that come as part of the language, one of the biggest advantages of Java is the vast number of third party libraries available. For example if you are writing an enterprise web application, GWT, Spring and Hibernate provide a framework with a huge amount of pre-existing functionality.

The size and number of dependencies grows as your application grows. GWT and Spring alone, without their dependencies, are more than 7MB. The ideal place to put dependencies is in a source control repository as part of your project so that when you or your continuous integration server check out the project for the first time all the dependencies are there. Then you don't have to go and get them and store them locally in a location that is agreed by the entire development team.

Storing the dependencies for a single project in a source control repository isn't too bad, provided there is plenty of room on the source control server.. However, if you have more than one project using the same or similar sets of dependencies the amount of space taken up in the source control repository starts to get a bit ridiculous. And then when a new version of a library comes out and you upgrade, even more space is wasted as the differences between binary jars cannot be detected, so the entire jar must be replaced.

Read more

Item 55: Optimize Judiciously

Bloch gets this item so right! He includes some famous quotes about optimisation and of course the most well known one:

We follow two rules in the matter of optimisation:
Rule 1: Don't do it.
Rule 2: (or experts only). Don't do it yet.

But Bloch doesn't leave it there. He goes on to summarise the rules with "measure performance before and after each optimization attempt." We all know this, but how many of us actually do it?

Actually I've seen these rules put to bad use and Bloch covers that too when he points out that you should still be thinking about performance issues when writing code. The example I've seen is someone retrieving a lookup table from a database for each iteration through a dataset, rather than reading it once and caching it. At least that optimisation was straight forward.

The new information that surprised me a little was that it appear to be accepted that Java does not have a strong performance model. We all know Java is traditionally slow, but i must admit I thought performance had been greatly improved in recent years. Of course the “semantic gap” between what the programmer writes and what the CPU executes is far greater than in traditional programming language.

I almost didn't need to write a summary as the final paragraph of the item summarises it so well.

Item 49: Prefer primitive types to boxed primitives

This is the first item, certainly that I have reviewed, where I feel Bloch has it spot on. There's no arguing with this one!

Bloch points out that Java has a number of primitive types such as int, double and boolean and each of these types has a corresponding reference type: Integer, Double and Boolean. These are the boxed primitives. Auto-boxing and auto-unboxing was introduced into the language in 1.5, so the Java programmer must now be more mindful of their use.

There are three main differences between primitive types and boxed primitives:

  • Primitives have only their values, whereas boxed primitives have identities distinct form their values

  • Primitive types cannot be null, but boxed primitives can

  • Primitive types are more space and time efficient than boxed-primitives

Care must be taken with using the == operator with boxed primitives as, with any other reference type, it compares identity and you almost certainly want to be comparing value. If a boxed primitive is compared to a primitive with the == operator, the primitive type is boxed and the identities compared, so care must also be taken here.

The process of boxing and unboxing, especially in a loop can serious impede performance.

Basically, boxes primitives should be avoided unless primitive types cannot be used, such as in collections or as parameterised types.

Saturday, 26 September 2009

ACCU Conference 2010 Proposal (2): Java Dependency Management with Ivy

Type: case study
Duration: 90 min
Speaker name: Paul Grenyer

Speaker Biography
Paul has been programming in one form or another for over 20 years. After several years using C++ and a brief period using C#, Paul is now happy somewhere he hoped he'd never be, programming in Java.

After time in industries such as marking machinery, direct mail, mobile phones, investment banking and Internet TV, Paul is currently working for an exciting new company based in Norwich where he heads up an ever growing team of senior and highly skilled people.

He has been an ACCU member since 2001, a regular publications contributor, including the now well established Desert Island Books column, creator of the mentored developers and a committee member for most of that time. When he's not programming and family life allows, Paul thoroughly enjoys science fiction, heavy metal and cycling.

Description
One of the biggest advantages of Java is the vast number of third party libraries available. As the size and number of third party libraries used grows your application's disk footprint also grows. The ideal place to put dependencies is in a source control system as part of your project. This means that when you or your continuous integration server check out the project for the first time all the dependencies are just there.

Although, storing the dependencies for a single project in a source control system isn't too bad, if you have more than one project using the same or similar sets of dependencies the amount of space taken up in the source control system starts to get a bit ridiculous. And then when a new version of a library comes out and you upgrade, even more space is wasted as the differences between binary jars cannot be detected, so the entire JAR must be replaced.

In this session I will demonstrate how easy it is to integrate Ivy with Ant and Eclipse and use a couple of XML files to manage dependencies without the need to check large numbers of JARs into source control. You will also see how to setup a local repository for any proprietary libraries or versions of libraries not in the publicly available repositories.