IntelliJ 4.5, OS X Panther and Subversion

I recently bought an Apple Powerbook to serve as my major development laptop and also to teach me a little about BSD. Installing IntelliJ 4.5 was a doddle, but having got used to Subversion integration I wanted that too.

After a lot of trial and error, I used the follow steps to get it all working.

1. Install Fink (http://fink.sourceforge.net/).
2. Use Fink to download and install the latest versions of the svn-client and svn-javahl packages from the devel section. If you are working in a secure environment you may need to also pull down the SSL versions of these packages from the crypto section.
3. Download the svnup and svn4idea45 jars from http://svnup.tigris.org/ (I used version 0.9.1 of both jars.)
4. Create a svn4idea subdirectory below the IntelliJ plugins directory (parent directory usually called IntelliJ IDEA.app) and in the svn4idea directory create a lib directory.
5. Place the 2 jars from tigris and the svn-javahl jar from the /sw/share/java/svn-javahl directory (if the Fink default install options were taken) and place them in the newly created lib directory.
6. Find in the directory that contains the plugins directory find a directory called Contents and below that directory find a directory called Resource.
7. In the Resource directory create a directory called Java (note the case).
8. From a Terminal window, copy the libsvnjavahl.jnilib alias from the /sw/share/java/svn-javahl directory into the newly created Java directory.
9. Restart IntelliJ and select the now available Subversion option as your version control and enter connection details for your Subversion server.

If you run into javahl library problems check that the alias has not been broken by the copy and also check that the Java directory that was created in step 7 is on IntelliJ's library path (the complete library path is listed in the error message from IntelliJ). If it is not present choose another directory from the library path for the copy destination in step 8.

Hopefully you will now have full refactoring/version control goodness.

An Erosion of our Humanity by the Justice System.

Something has been niggling me for some time about our approach to crime and punishment. Why is it that whenever a crime is committed, large or small, a whole raft of extenuating circumstances are brought out and the sentence reduced?

This worries me deeply, a criminal being able to say that he/she did something because of all these external factors and so should be mercied. I believe that one of the fundamentals of humanity is the ability to make a conscious decision, weigh all the pros and cons before acting. I wonder what the message is then when leniency is shown, the messages that I can see are:

• Either, if you make a conscious decision to break the law, having weighed all the factors, that's OK, it's not that bad really,
• Or, it's alright to break the law because you didn't really think about it, didn't think about the damage that you were doing and were only conscious of a small part of your decision making process.

The first message is bad enough. It takes the judgement of Solomon to determine whether there really were mitigating factors, and the mitigating factors have to really outweigh the negative consequences, not just outweight them in the mind of the offender.

The second message is far more dangerous, it goes to the heart of what makes us part of an human society. This means that it's alright to act as a criminal as long as you didn't think clearly about it, you didn't act as a thinking human being so we'll allow you back into human society sooner. That is a very bad thing. It attacks our humanity in general, it means that there is a general belief that we are unable to aspire to be rational beings and it's fine just to act without thought.

I take this very, very personally.

Simplify and Add More Lightness

My immediate family has a preponderance of engineers, not software engineers but the old fashioned kind that build physical objects. I always find it enlightening to observe the similarities and differences between classical engineering disciplines and software engineering.

One dictum that has come down to me that I always follow, 'Simplify and Add More Lightness'. My father applied it when designing racing cars, my sister a trained engineer applies it in her chosen engineering discipline - dressmaking (just think about it).

So what are the ramifications?

Primarily it means, as the XP programmers have it, that a piece of software should only be as complex as it needs to be to do the job and no more. I agree whole-heartedly that the avoidance of abstractions, neat tricks and anything that obscures the intent of code is to be avoided. The problem is that, despite whatever the sellers of methodologies tell you, there is no substitute for experience in determining how complex a piece of software needs to be.

I have a few questions that I use to make this judgement call:

• What are the invariants of a system? An often difficult question to ask, but rewarding. The invariants are the parts of the system that should have the fewest or even no abstractions. They can be certain key business objects and behaviours, certain work flows or even the fact that communication between components is to be asynchronous or synchronous. I tend to use these invariants to define the skeleton of systems that I am designing and they throw into stark relief the next question.


• How fluid are the variant elements of a system? An equally difficult question to ask. The degree of fluidity helps one to decide which level of abstraction to define. If something is unlikely to change during the lifetime of the system, then maybe just an interface should be defined. If an element is likely to be changed several times perhaps a factory should be written. If the element is likely to vary continuously, then some form of declarative configuration should be used, whether an XML file or even an end user defined set of rules in a rules engine.


• What is the likely skill level of the support staff? A question that is not asked as often as it should be. If there is likely to be a high turnover of the support team, giving them little or no chance to learn the system, or there is likely to be a preponderance of junior staff then this question is vital. A compromise will often need to be reached between the efficiency and simplicity of a system. An efficient system sometimes uses sophisticated techniques to be performant, however it often leads to complexity which then has to be supported. It is worth remembering that the more complex a codebase, the more prone it is to bit-rot.

A second important ramification of this dictum is that a piece of software should be as 'light' on the system it is using as possible. With certain exceptions (see above), overly complex systems are not performant, if messages are flying backwards and forwards, the code tends to be tangled and to make inefficient use of resources.

A good physical example of the application of this dictum is that of a bicycle, the most invariant elements are the carriage of a person, pedal power and two wheels leading to the relative simplicity and inflexibility of a frame. The more fluid elements are direction, speed and incline. Direction is handled by a simple steering abstraction. Speed and incline require a much more complex abstraction, that of gearing. It is interesting to note that there is still room for valid variation in the design of the 'skeleton'of the bike (prone bicycles) but the frame remains a static structure.

In the early days of bicycles, they were designed to be maintainable by non-specialists, either blacksmiths or the cyclist themselves, and were thus extremely simple and made of basic materials such as iron. With the rise of cycle technicians, more sophisticated materials were used such as steel, aluminium and now composites; the gearing solutions became increasingly complex and now there is even non-essential complexity, suspension systems.

I always try to design systems to be as simple as possible, but I am sophisticated in how I do this.

Naked Collections are a Design Smell.

I've been thinking some time about a malaise that seems to afflict the codebase of most applications that I work with:

Collections.

Don't get me wrong, Collections are an important part of the programming toolkit, but every time I see them exposed in a method signature I wince. Collections are used as a convenvient shortcut instead of actually thinking in an object oriented way. The Collection is as far as many people go in modelling the bulk properties of groups of objects.

We model individual objects very carefully. If we are properly object-oriented we provide methods to the object that we are creating and end up with a beautifully crafted object. Yet when we come to model a group of objects, most often they seem to just get chucked into a Collection. The only bulk behaviours that we get are those of the Collection and none of those of the group.

Properly clothed collections.

When a collection class is wrapped in a 'group class' we create better object models. We can make our code more robust and easy to understand.

• A wrapped collection can be strongly typed through the methods provided by the 'group class'.
• When one comes to write bulk and batch methods they have a more natural home than the proliferation of helper classes that one normally has to sort through.
• A group class can provide facets to the enclosed objects, for example when an instance of a 'Person' class is added to an instance of a 'Football Team' group class they become an instance of a 'Football Player' class. The addition of the 'Person' to the team should be accomplished through a method that has the necessary additional parameters for defining them as a football player, such as shirt number and position.

Using naked Collections is not object-oriented, when I see them used I know that someone has skimped on the modelling.

Groups of objects are objects too.

A little bit about me and my blog...

Well, this is my first venture into the world of Blogging and I am somewhat nervous. I know that there will be very few people viewing this blog initially and hopefully mainly my friends, but I'm still nervous as I know that I will be revealing more about myself here than I normally show to anyone.

Who am I?

That is the question that I have lived my whole life so far to answer, and it will never be completely answered until I have died. From your point of view however we'll start with basics and the rest of the blog will go some way to filling in the blanks.

The first and most obvious definition is my name. My full name is 'Robert Morris Maitland Boothby', a mouthful I know. My mother is about the only one who calls me 'Robert', the rest of the world knows me as 'Bob'. 'Bob' came about because at school there were too many Roberts, I was left with a choice of 'Bob' or 'Bert' and I really did not feel like I was a 'Bert'. That name was left to a gentleman called Peacock to whom, as a scion of a Yorkshire/New Zealand sheep farming family, it seemed eminently suited. To be honest I never fathomed whether he liked the name, but it's too late to swap now.

The second definition of me comes from what I do for a living. I am a Java programmer with design and architecture pretensions. I have my own small company though which I work primarily in the enterprise Java arena. I can't really claim a specialisation as I have worked in so many areas with a wide range of (not exclusively java) technologies. The companies I have worked for are equally eclectic with a bias towards the financial.

My work to date has been almost exclusively based in England. I did work for a short but happy period in Ireland, a small town called Castlebar in County Mayo but that will likely be a topic for another entry.

The third definition of me comes from what I do socially. I am not an instinctively social animal in many ways and it is often a conscious effort for me to get out there. I have started going regularly to gigs with good friends such as Dan and Ed, a particular favourite being the a pub called the Greys. Every year I go to the Cropredy Festival and every year I attend the South of England Show. I sporadically attend motor sports event (my father raced) and the rest of my socialising is in and around pubs and cafés. I have ambitions to get dining chairs and hold an honest to goodness dinner party, but I'm not hopeful.

What will this blog be about?

Anything and everything that takes my interest, this will include but not be limited to Java, OOAD, poetry, cars, politics, philosophy, poetry, music, movies and cooking.

I would say that that's enough for a first post so I'll stop.