27 March 2009

Soft Skills

In our department there was a small team of three people, organising internal training, maintaining the library etc. One of them left and later in a departmental meeting a discussion took place about replacing the missing member. The remaining two guys said that they already have difficulties managing and synchronising themselves and a third person would not help and is therefore not needed. Well, it sounds reasonable so far.

Stop Some days later I was asked by my boss if I would like to join the team, which I denied, because as I had earlier understood, they did not want a third person, even if management thought they needed. (Well maybe it's from the management "idea" that having even two employees working on some topic is risky, because both might decide to leave the company - but three might as well...)

Afterwards I talked to the head of this "education" team. I had denied not of disrespect for their work but because I knew that they didn't want a third person. I was surprised to learn that they had already found a suitable replacement for the missing third member. They were so happy that someone they liked had volunteered. Huh?

Did I get something wrong in the first place, or did they talk unclear, on purpose, so they could choose their third member themselves? The whole story is just strange. Obviously I lack some soft skills in communication...

23 March 2009

Resources to Start Scala

The Scala Programming Language has been around some time and started getting popular in 2007. A good place to start are the tutorials included in the distribution, which are also available online: A Scala Tutorial (very short 15 pages), Scala By Example (already 145 pages) and The Scala Language Specification (full 180 pages).

Early multimedia resources that picked my interest were Martin Odersky's talk, The Scala Experience at JavaOne 2007 and the 62th episode from Software Engineering Radio. Further Martin Odersky gave another talk at JavaOne 2008 and JAX'08.

In January 2008 Ted Neward began his busy Java developer's guide to Scala, which started with stuff from the Scala Tutorial but went into greater detail later. Another blogger that is definitely worth mentioning is Daniel Spiewak, who wrote the nice Scala for Java Refugees as well as on some special topics like Integrating Scala into JRuby. Another piece worth recommending is Dean Wampler's blog titled the The Seductions of Scala. James Iry has to be mentioned for exploring more theoretical stuff in nice little chunks.

After spending some time with Scala, I went for the only book available, Programming in Scala, a comprehensive step-by-step guide with massive 754 pages. Unfortunately it did not ship for almost 9 (!) months and I do not like ebooks. (I know - I should have read the whole page when ordering; that it was not printed, not even finished back then.) However, now it's printed. Since January it's standing on my book shelf and torturing my conscience.

I have to pull myself together and finally start reading it!

21 March 2009

Slimming VMware Player Installation

Going Virtual @ Fiddler's Green Recently I had to play around with some VMware images. After installing the VMware Player (current version = 2.5.1) I had problems with connecting my image to the network. Finally I managed, but I learned it the hard way. IMHO the best way to run a virtual network is bridged using a static IP address for each image. (Just make sure the addresses are all in the same sub-net.) This description applies to Windows operation systems.

Network Connections
VMware Player installs two additional network adapters on the host computer.
  • Virtual switch VNNet1 is the default for Host Only networking. Using this network adapter virtual machines can't access the outside network. - Disable it, we don't need it!
  • Virtual switch VNNet8 is the NAT switch. Here virtual machines can access the outside network using the host’s IP address. - Disable it, we don't need it!
  • Just make sure the VMware Bridge Protocol is enabled for your main network adapter. So virtual machines can access the outside network using their own IP addresses.

VMware Bridge Protocol is enabled

Services
I noticed that VMware Player also installs several services which I don't like. Especially when the purpose of some VMware services is unclear.
  • vmnat.exe is the NAT service. It is needed for VNNet8. Deactivate it, we don't need it!
  • vmnetdhcp.exe is a virtual DHCP service. It's only needed if you use DHCP in your images and do not have a real DHCP server set up and running. Deactivate it, we don't need it for static IP addresses.
  • vmware-authd.exe is the authorisation service and controls authentication and authorisation for access to virtual machines for non admin users. Probably you don't need it, so deactivate it.
  • vmware-ufad.exe is the host process for Ufa Services. It's not active by default, so leave it deactivated.
  • vmware-tray.exe is probably the same as hqtray.exe, but it was not installed on my computer.
  • hqtray.exe is the host network access status tray. Unless you want to see network traffic in the taskbar, deactivate it. (This is not a regular service, it is started at system start-up. You have to delete it from the registry, it's key is below HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ Run.
If you have to use Host Only or NAT, leave the corresponding network and service settings alone.

WTF
And watch your back, you can't connect from the virtual image anywhere when your local firewall is dropping all unknown traffic ;-)

14 March 2009

Law of Code Quality: Consistency

Fall MixtureImagine you have some MDBs (Message Driven Beans). You want to get rid of them because they are still EJB2 and they suck. You want to use Spring's JMS capabilities instead. Sounds quite good. But after some time, due to some budget problem or pending dead-line, you stop converting the old stuff "because it does not add value" (and which is almost guaranteed to happen). So you end up having MDB plus Spring JMS mixed throughout the code and maintenance people have to know both of them. It's difficult enough to know one of them, but now you end up having both solutions messed up on the long run.

Copy & Paste
In brownfield development you always have some code before you start. The look, quality and design of this code is very important for further developments. Extending complex legacy stuff often involves a copy-and-paste style of coding. (If this is preferable is a story of its own right but will not be discussed here.) In the context of maintenance I consider copy and paste a good habit because this way the existing conventions and patterns are obeyed, even if they are not documented. Of course the positive effects of copy paste are only achieved if the "right" piece of the system is copied. Like reference solutions in generator development, aka templates (Link MDSD Generator), the copied piece has to be of highest quality, i.e. according to conventions and guidelines defined for the application.

Implicit Conventions and Uniformity
If the guidelines and conventions of some software are not written down properly, the only documentation is the code itself. Even if there is decent documentation, capturing all aspects of software development is at best very difficult or can't be done at all. There are always some implicit conventions that are only available in the code. The more an application is uniformly satisfying these conventions and designs, the more pieces of it serve as "safe" templates for further extensions and modifications. This helps new members on the project to find their way around. And good (maintenance) developers see these implicit conventions in surrounding style and patterns, adapt to them and work according to them. Uniform code makes it easier for them to adapt to the new code base and "get to speed".

Broken Window AboveBroken Windows
As the pragmatic programmers toughed us in rule 4, broken windows are causing problems in real as well as virtual life. If the conventions are visible and clear, who would dare to stand out in breaking them? On the other hand, if e.g. a piece of code is formatted in three different ways, there is no shame in introducing a new style. People tend to stick with the things they know, because it is faster and feels more secure. (And usually we think it to be superior to things we do not know.) This leads to patchworks in the code. This mixture gets maintained (read copied) from time and time and all the broken windows get spread throughout the code base, the differences live on and grow.

So I postulate the 1st Law of Code Quality - Code Consistency. This applies to source layout, naming and other coding conventions, typical code fragments (also called idioms, most of the time some boilerplate code), design concerns, layering, architecture, used libraries, technologies etc. Consistency in the code is the most important issue. Failing to have a consistent code base will cause all the troubles known from mixed designs, mixed technologies, making it difficult to maintain and get new people into the team.

Living with Changes
Of course we have to change things again and again. It's easy to have consistency in simple conventions, like formatting, just use Eclipse format on the whole source tree and put Checkstyle into your build. Short code idioms like getting a database connection are more difficult. These are rarely documented, but once you have them unified, a Ruby or Groovy script can do almost any syntactical change to your code using powerful regular expressions. More complex changes, e.g. replacing EJB 2 with something else, is more involved. However just don't make the mistake to leave the old stuff as it is. No excuses about small budget, needed retest, pending dead-lines and such! If you can't convert the old stuff, leave it as it is. If you are too "weak" to change it, you earned staying with it. Bringing in new technologies needs a strong plan, better a script, to convert everything existing to the new style. All remaining code has to be changed to use the new technologies as they are supposed to. Typical idioms and best practices of that technology should be obvious at the end. You don't want a Java program to be coded like old C, a few classes with lots of static, monolithic methods, static data etc. The same is true for any refactoring.

A Brighter Future?
In keeping your code base consistent you need help. Especially in the beginning we need someone who flags new inconsistencies, reminds us of conventions. Use static code analysis as soon as you have identified a consistency target. (That might be as simple as grep *.java.) The proper (consistent) way to do something should be enforced from day one. Unfortunately documenting it is not enough. For layout use tools like Checkstyle. Other conventions and boilerplate code can be checked with tools, that support custom rule definition, e.g. Findbugs or PMD. Nowadays many tools come with a large number of base rules that cover common stuff. Most likely some are of use. Modularity and layering is enforced with reference checking, e.g. Macker or SonarJ. With some fantasy (and enough computing power at your build machine) you can create quite sophisticated checks.