Cheat Sheet: Ubuntu / Debian package mangement

Debian package management is a powerful feature that is well integrated into modern debian-based Linux desktops like Ubuntu. One does rarely need to know more about it than that its mere existence. It handles all the ugly update- and dependency stuff in a user-friendly way.

Sometimes it comes in handy to dig a little deeper. For example: As a developer, I want to use multiple installations of the Eclipse development environment (sounds like the title of a user story, doesn’t it?). It would be useful to see how the default Eclipse installation in Ubuntu is installed. Because which eclipse only yields the /usr/lib/bin directory we need to figure out the actual locations of the package artifacts. The command-line tool of debian package management is called dpkg. To list all installed packages containing eclipse use:

$ dpkg -l | grep eclipse
ii  eclipse-platform                      3.5.2-2ubuntu4.3                                Eclipse platform without plug-ins to develop
ii  eclipse-platform-data                 3.5.2-2ubuntu4.3                                Eclipse platform without plug-ins to develop
ii  eclipse-rcp                           3.5.2-2ubuntu4.3                                Eclipse Rich Client Platform (RCP)

Now we can query for the locations of the package contents:

$ dpkg -L eclipse-platform | less

There are some locations that I did not think of in the first place, for example

[...]
/etc/eclipse.ini
[...]
/usr/share/applications/eclipse.desktop

This knowledge helps to conclude a well-founded strategy for managing multiple installations of Eclipse, based on how far one wants to go. Larger teams or departments, maybe distributed among several countries could very well benefit from the both the simplicity and flexibility of .deb packaging.

Advertisements

Methods with flags: Why they hurt maintainability

Some time ago I was assigned a bug in the UI part of a system. Some component would not be displayed. I digged deep into the mostly procedural code and found a method invocation that read like this (simplified):

public void createActionHandler(Action action, Window window) {
   ...
   window.create(context.getTextValue(), true);
   ...
}

At that point I thought everything was fine and continued the investigation. Like most of the times there were of course no unit tests in place because the controllers and action handlers were intertwined with the UI framework. After half an our of testing and adding debugging output I realized that there must have been a mistake before. I opened the Window.create method – looked OK, although the second parameter was named arg1 and was not used (the warning was disabled though). I opened the inheritance tree and chose the Subclass I knew was used in this case. It looked like this:

public void create(String value, boolean update) {
     super.create(value, update);
     if(update) {
          // only do update
          ...
      } else {
          ... // initialize component
      }
}

It wasn’t that obvious because the method had well over hundred lines. Setting the boolean flag to false fixed the bug. I refactored the code and simply created an update method and replaced every call with create(.., true) by update.

Then I pressed undo several times and I asked some fellow developers to come over. I showed them the first method and asked them if there was something wrong. From the context they couldn’t tell. They looked further down the control-flow like I did. Then I hit redo several times until the update(..) call showed. Immediately it was clear to them that calling update from a method named create looked odd – the basic flow and idioms used in the system were known to everyone.

Obviously naming things wrong or not unique is a major bummer. In my opinion it is not necessary to discuss software-architecture styles when simple principles on the lowest level get violated on a regular basis. Start at the bottom. Having a good class design is half the way of creating a good architecture. Methods with control-flags are a no no. If you are using a source code validation tool like PMD add a check for syntactic overloading and maybe a check to catch a boolean parameter that is used inside an if-statement – this may well be a sign of broken encapsulation.

Always remember Meyer’s No-Overloading principle

“Different things should have different names.”

Do not share objects in the first place, copy!

As an informed developer or architect you will probably know what makes functional languages like Scheme, F# or Erlang so powerful: They share the inherent effort of their creators to make the creation of complex behavior easy (by combining simple elements) and the introduction of undesired side-effects hard. But achieving the same in OO languages like Java it is just as easy if you follow some simple principles (or guidelines, if you do not like principles). In this post I will scratch the problem of unintended side-effects because in my experience it receives not enough attention in practice. After all there are always serious integration and distribution issues to solve, so why care about making simple applications sound? Just kidding.

Here is the key idea to solve the issue of unrecognized side-effects: Instead of creating aliases to the same mutable storage cell, all one needs to do instead is create new or copying existing objects, leaving existing ones unmodified. This principle is inherent to the functional programming style. Like the number two denotes the same concept, regardless of who thinks about it or writes it down on a piece of paper, the same is true of numbers or even larger structures in the functional paradigm. If you add an element to a list, you are creating a new one (using cells, cons, car and cdr in LISP), leaving the existing one intact. Because you cannot modify the lists’ elements the old list will exist until it goes out of scope and eventually gets garbage collected.

We can and should use this method in Java often and happily. The usage of final fields and correctly overloaded equals(..) and hashCode() form the basis of any sound, object-oriented domain-model in Java. The ValueObject design pattern was created and is perfect for creating the basic elements of the domain-model. A ValueObject is immutable, thus only publishing methods that create or return another immutable instance but never modify an existing on. It is small and its equality is usually based on the comparison of each of its parts. Date, Money, Distance or (musical) Pitch are common examples of ValueObjects. Developers can safely use and share ValueObjects and focus on desired side effects of the commands of reference objects aka entities. As a bonus we get multi-threading safety (see Java Memory Model).

Let’s take this idea a step further. Think of a typical anaemic object (an entity this time) having a list of addresses as part of its inner state. Using Java Beans style getters and setters will almost certainly get you into problems with undesired side-effects. There will always be someone in the team (often even a programming pair) who unwillingly does not copy a list before modification. Maybe just in a special case. In my career this was once the case in a net of Controller-like classes responsible for both redrawing the screen and creating print output. A user complained, after printing a page there would be a runtime exception when the next screen update happened. Guess how efficient I was tracking down that bug – without any unit tests of course (UI code is rarely well tested in practice). Well, you probably guessed this problem was created by a list, that was not copied but referenced from the print logic, modified before printing and so created inconsistent control data. I thanked the Eclipse debugger developers twice this day.

What does this indicate for designing domain-model classes? My advice: Add getters and setters only if required by some framework, else use an intention-revealing interface style like proposed by NakedObjects / Apache Isis. It is really easy to make an interface intention-revealing:

     customer.getAdresses().add(address);
     customer.getAdresses().remove(address);
     return customer.getAddresses();

becomes

      customer.addAddress(address);
      customer.removeAddress(address);
     // Should do a deep copy if addresses are mutable. 
     return customer.createDeepCopyOfAddresses();

Expose the methods you need – you do not need to conform the Java Bean convention (which was designed for tools of the 1990s anyway). Note how using domain-related, readable method names makes the code abide to the Law-of-Demeter and adhere to the OO principle “Tell, don’t ask” [Sharp1997]. If you are modeling a bidirectional 1:n association you may easily apply the Mutual Registration Pattern to attach and detach elements to and from their parent.

What I find quite interesting is how creating intention-revealing interfaces using terms from a domains Ubiquitous Language relates to the rename / redefine language constructs of the EIFFEL language. EIFFEL has a well designed approach to multiple inheritance, that is conceptually much more sound than in C++ for example. While C++ uses non-satisfying precedence rules in case of name clashes, EIFFEL allows the creator of a subclass to decide which features of the base classes are exposed by which name. In this example, the add method of java.util.(Array)List could be renamed to addAddress and in a second step redefined to a void method. java.util.List.add(..) returns a boolean which does not conform to the Command-Query Separation principle. Note that redefinition of a method in Java means creating a trivial delegate method.

I must say that Meyer’s use of inheritance is one of the few positions that I do not share. In a forthcoming post I will discuss how inheritance relates to composition and delegation. In my current understanding and from the point of view of the designer of an object-model inheritance seems to be best explained as a special form of delegation. Anyway, EIFFELs approach on multiple inheritance is much more useful for designing domain-models than that of C++ and fits very well within the language, so it is very worth to mention.

After talking so much about side-effects let me clarify, that because we are in the imperative programming paradigm there are also wanted side-effects. Call them mutators, setters or commands, what you want to achieve in object-oriented programming is come close the real world with  a clever set of classes that have as much in common with the application domain as possible. If there is mutable state in an object of the application domain, it should be modeled as mutable state in our little (or not so little) computer world. If the the state of an object should not be mutable, think of which demand once made Xerox so successful: Creating copies!

[Meyer2001]

Meyer, Bertrand: “Overloading vs.Objectechnology”, Journal of Object-Oriented Programming, October/November 2001, p. 3-7.

[Meyer1992]

Meyer, Bertrand: “Eiffel: The Language, Prentice Hall, Englewood Cliffs”, NY., 1992.

[Sharp1997]

Sharp, Alan: “Smalltalk By Example”, McGraw-Hill, 1997.

How to make systems production ready

When meeting with a fellow developer the talk is usually about implementation technologies, planned features and the like. And of course we will try to avoid errors and failures. A failing (software) system is something no one really likes to talk about. Until “it” happens and unplanned expenses reach displeasing heights.

Most textbooks exclude the problem “failing”, except for some exception handling examples not worth imitating. A quite unique publication discussing production problems is Release It! by Michael Nygard. One of my favorite statements is:

[But] painful experience has shown that “feature complete” is not even close to “production ready.”

This is so true. Mr. Nygard proposes a failure-oriented mindset and presents stability patterns and of course anti-patterns and much more. I can only recommend this book to anyone, beginning programmer or seasoned software architect, software tester or project manager.

One of the few other non-academic publications I know about covering error handling in a systematic way is a German book, “Moderne Software-Architektur” by Johannes Siedersleben. Part of a very interesting approach of programming in the large this book contains a complete chapter on errors and exceptions as well as methods too design and handle “abnormal results”.

So how do you make a system production ready before something goes terribly wrong? I think awareness is the key. Both books should be on every stakeholders bookshelf, just to remind everybody of how dangerous “happy-path” development and not-testing can be.

If you know of other important publications please leave a comment or drop a mail.

Michael T. Nygard: “Release It!: Design and Deploy Production-Ready Software”, Pragmatic Programming Bookshelf, 2007.

Johannes Siedersleben: “Moderne Software-Architektur“, d.punkt-Verlag, 2004.

Open, extensible object-models

If you ever wondered how simple an object-model implementation, the “runtime” of an object-oriented language can be have a look on this paper of Ian Piumarta and Allessandro Warth:

Piumarta, Warth: „Open, extensible object models“, 2007

http://piumarta.com/software/cola/objmodel2.pdf

It took me a while to understand all (or maybe just some) consequences of this proposal and how to relate them to common, more familiar object-models like those of Java, SmallTalk, Objective-C or C++. The C-Code at the end is easily compiled with gcc and fun to study (“How to bootstrap a world.”) and play with.

My Personal “Software Development Guru” Hall of Fame

This list is in no particular order but everyone on this list had a big influence on me and my work. These guys have important things to say, so don’t miss ’em!

  • Bertrand Meyer – naming the blog after his ground-breaking manual to object-oriented thinking makes him an obvious member of the hall of fame.
  • Martin Fowler – probably one of the most influential people of the late 1990s and 2000s until today. Reading any of his books or posts is always a pleasure. I am always surprisedtoy  how clever and hard-working a single man can be.
  • Alan Kay – one of the guys who started it all. SmallTalk is just so powerful and yet simple. Try out Squeak and toy around with the UI – its just amazing.
  • Erich Gamma – you already know him and his famous gang of four and their classic book “Design Patterns. Elements of Reusable Object-Oriented Software”. Why not re-read it today? Besides giving us Eclipse and its vast amount of plugins his work on object-oriented frameworks and user interfaces at UBILAB is very notable.
  • Kent Beck – there are few publications with that few pages (for a computer textbook)  that may have such a big impact on your development practice like his “Test Driven Development: By Example” published in 2002.
  • Eric Evans – “Domain-Driven Design: Tackling Complexity in the Heart of Software” is a wonderful book with wonderful advice that stands both as a publication and as a method in one line with our beloved “Design Patterns”. Being a non-native speaker I just love translating his rich descriptions into German, although I have to use the dictionary now and then.
  • Rod Johnson – his sharp-minded alternative to the clumsy first J2EE approaches laid  out in “Expert One-on-One J2EE Development without EJB” became the popular Spring framework, whose appearance influenced Java EE 5 strongly and is a prime example of how good competition is for business.
  • Niklaus Wirth – creator of PASCAL, the MODULAs and OBERONs is an excellent example of how a philosophy of simplicity yields outstanding results. He and his department at ETH Zürich have developed a huge amount of software including the Oberon OS.
To be continued…

Hitchhikers guide to Java class loading issues

Java Exceptions and Errors like ClassCastException, MethodNotFoundError and NoClassDefFoundError can be a real annoyance, especially when everything looks allright on the first sight. My advice: Stay calm and follow this simple checklist:

 

  1. Check if the class is really on the classpath. In a Java EE project you might have misconfigured the build tool and the JAR you expect to be included is not.
  2. Check if the class is more than once included in your project. This may also happen if a JAR file is already provided by your application server.
  3. If you are really sure there is a class or interface with the exact fully qualified classname (compare package names with a tool, they can get really long in some organizations) there is almost always more than one ClassLoader involved. You need to understand how class loading works in your environment. There is a hint for the popular JBoss application servers below.

JBoss application servers do not by default isolate application artifacts from each other. Because you usually want isolation you have to define a scoped classloader in jboss-app.xml, for example

<jboss-app>
      <loader-repository>
           myusefulapp_version_1_0:archive=myusefulapp_version_1_0.ear
      </loader-repository>
</jboss-app>

Be careful when copy-pasting code from old projects: If you don’t change the name (or even better filter it with the maven-resources-plugin) you will almost certainly get into problems. Here is the complete documentation from JBoss.