Waiting for the clashes

Next weekend the RBS Six Nations will begin with England hosting Italy in Twickenham, Ireland hosting France in Croke Park and the Grand Slam Winner Wales visiting Scotland in Murrayfield. Starting to feel the excitement...

Singletons?

...any global data is guilty until proven innocent

(Martin Fowler)

If you want to be a good software designer, don't optimize code prematurely. [...] If you use the Singleton pattern out of habit, because it "makes your code more efficient", you're prematurely optimizing. You suffer from Singletonitis

(Joshua Kerievsky)

I'm not afraid of a few globals. They provide the global context that everyone must understand. There shouldn't be many though. Too many would scare me.

(Ward Cunningham)

The real problem with Singletons is that they give you such a good excuse not to think carefully about the appropriate visibility of an object.

(Kent Beck)

I mean, it looks like we're not lacking literature on the subject, are we? I wonder why so many people are just too busy with their Singletonitis to consult it (Kent Beck gave a hint on this).

Tangled and circular dependencies

Back to the cyclical dependencies problem I wrote about one year ago, the other day I finally tackled it (15 years spent playing rugby must have taught me something), as it was left hanging in the air for too long. We started out like this:

Basically project B uses the domain model and persistence services from project A, which in turns uses transport services and a the domain model from project B (no, it is not the same as above, because the model B is just based on model A but it is managed from a different perspective). Let's not forget to say that presentation, model and services are all tangled.

A disclaimer: this is not what I'd call a refactor, just a different way of organizing projects thanks to NetBeans features (no Maven complexities, thank you).

I first extracted the core domain classes of project A used in project B and moved them to a new project, let's call it A Core, then had both project A and B depending on this one. Sounds easy, but it wasn't... it was quite long and tiring, and it required a little tweaking each now and then, just like the subsequent passages. That lead me here:


Now that could look good, but even if it is better it was not enough because of some legacy installations in which Project A must be compiled using JDK 1.4 and run on a Tomcat 4, but project B has a JDK 1.5 source level (Tiger, or whatever it is called now) and runs on a Tomcat 6. This forced me to extract from Project B all classes on which Project A depended to move them on a new project, let's call it B core. Nip and tuck, here and there, to land that prince with the perfect hair, and here we are:


Now all cyclical dependencies are gone. Packages with the very same name exist in different projects, leading to a namespace which "doesn't talk" to the developer; on the other hand this can bring a lot of confusion, even if the compiler understands everything perfectly. That's where fun begins... I just began scraping the surface, now we have to dig in deep. The first step will be choosing the right names for packages, so to convey the rationale behind their repositioning. The next one will be moving related classes left untouched by the dependencies game but logically belonging to one of the "core" projects. Other steps are still up in the air...

Moral: always clean up your mess. BTW, it does not matter if you just inherited it. Now it is yours, and it is you the one who has to deal with it. Leave spaghetti to gravy and keep them out of your code. There must be a reason if they say "clean code that works" and not just "code that works"...

Coaching your team

I stumbled upon this survey on Marsha's site and found it quite interesting as it was an occasion to stop and think how I'm doing.

The results tell me "You were meant to be a coach". That's nice, but it is just a start. The survey actually focuses on ideal characteristics of a good coach, but to really get to the point you have to ask yourself how you fit in. You have to walk the walk, not just talk the talk. So, do I always behave the way I should?

All I can say in all honesty is that I love coaching. But it is looking at how other people improve that you can say whether you're effective or not. So, if you want to improve, you have to help other people to improve themselves. Tricky, isn't it?

Motivating people

Peopleware is a great book. It says a fundamental thing: people are the cornerpiece of every company. That's good, as it is very important to recognize it, but it is always somehow bad, as dealing with people is one of the most difficult task we have to face. Yet, we face it each and every day.

Every now and then you have to clear the air a little, and this can be painful, but collaboration between people is one of the key factors to success.

As dealing with people is difficult, you have to motivate everyone, choosing the right stimulus for each of your collaborators. And, being your collaborators people, that is damn hard. It is always nice when your professionality is acknowledged, but that can be not enough. Someone wants to feel they are in charge. Someone wants more training. Someone wants a private office with plants. Someone wants a younger secretary. Someone wants an armchair lined with human flesh or a fish tank full with swimming accountants.

Most people think of money as the ultimate resource, but if you think it will suffice... well it won't. Besides, Choosing a job only on money is often a bad choice, as many other factors have a great influence.

That said, no one would be unhappy if they were given a raise.

I surely wouldn't.

The birthday greetings kata

On February the 14th the milano-xpug organized a kata whose subject was proposed by Matteo on his blog to introduce the exagonal architecture.

Unluckily I couldn't attend the meeting in the flesh, so I just decided to try the kata out here on my own. I first started from scratch, thinking it would prove more fun; then, as I was taking quite a different approach - you could also say that a whole different design was emerging - I decided to get back and start from the original code provided and refactor it to try and focus on the architectural issues which were the aim of the exercise.

Even if I think this exercise to be quite simple, I decided to post a trace anyway because someone might still find it useful. You can never say!

The heart of the application is the BirthdayService class, whose responsibilities consist in identifying employees whose birthday falls on a given date and sending them a greeting message.

This is the public method, called by the acceptance test:


I know it looks odd, but I've had enough of escaping characters and trying to format code to make it look nice, so I hope you will forgive me.

Anyway, the sendGreetings method parses an input file, creates employees, checks if they are eligible for a greeting message and delegate the actual sending of the message to a private method:


Seems a great bunch of things for a single class... let's try to sort it out. First I decoupled the service from the file with the employees' names introducing the interface EmployeeRepository, with the method getEmployees, then I wrote a FileSystemEmployeeRepository that implemented it. The repository was then injected into the BirthdayService via constructor by
the acceptance test. At this point the code looked like this:

...
List<Employee> employees = repository.getEmployees();
for (Employee employee : employees) {
 if (employee.isBirthday) {
    //compose message and call method that sends it
 }
}
...

Still I thought that the check on the date of birth could be done by the repository itself, so I changed the interface adding the new findEmployeesBornOn(OurDate) method and changed the code so that it looked like this:

...
List<Employee> employees = 
      repository.findEmployeesBornOn(ourDate);
for (Employee employee : employees) {
 //compose message and call method that sends it
}
...

Maybe not a very big change but I think it was worth it, as now the code is cleaner. Then there was the messaging part. First of all I decided to introduce a new BirthdayGreeting class, that produces a message body, a fixed subject and a recipient starting from an employee; at this point I extracted the interface SimpleMessage that exposes these three strings. The code had become

...
if (employee.isBirthday) {
  SimpleMessage greeting = new BirthdayGreeting(employee);
  sendMessage(smptHost, smptPort, "sender@here.com", greeting);
}
...

Still I had to resolve the dependency from the SMTP, so just like I did for the repository I introduced the MessagingService interface with the sendMessage(String sender, SimpleMessage message) method and injected it into the BirthdayService via constructor from the acceptance test. Some nip and tuck to move the body of the sendMessage method from BirthdayService into a new EmailService, implementer of MessagingService, and voila, the new BirthdayService code:

public void sendGreetings(int month, int day) {
  List<Employee> employees = 
      repository.findEmployeesBornOn(month, day);
  for (Employee employee : employees) {
     BirthdayGreeting greeting = new BirthdayGreeting(employee);
     messagingService.sendMessage("sender@here.com", greeting);
  }
}

I also changed the method parameter from OurDate to month, day. Now we have a simple and decoupled service that can focus on its true responsibilities: ask for all people who should receive a greeting, create a new message and delegate its sending.

One might wonder whether the sender belongs where I put it, or if the service should directly instantiate a BirthdayGreeting with a new rather than getting it in some other way. But maybe that's going too far.

BTW I also decided not to use the Employee.isBirthday() method and I created a value object called IsBirthday, created with two parameters representing month and day, with the boolean method forEmployee(Employee). The code in the repository now looks like this:

public List findEmployeesBornOn(int month, int day) {
   List<Employee> list = new ArrayList<Employee>();
   IsBirthday isBirthday = new IsBirthday(month, day);

   for (Employee employee : employees) {
      if (isBirthday.forEmployee(employee)) {
         list.add(employee);
      }
   }
   return Collections.unmodifiableList(list);
}

That's all folks... maybe I'll manage to post the complete code here, where you can find some other (and more accredited) solutions produced by people who actually were there.

Star Wars retold by someone who has not seen it

Continuing the Star Wars series, here's a simple animation that pictures the original trilogy as told by someone who has not actually seen it save for some pieces in open order.



One of the things that made me laugh the most was Amanda spelling "HanS solo" in a very German way... priceless!

The original post is to be found here: Star Wars: Retold (by someone who hasn't seen it) from Joe Nicolosi on Vimeo.