• Refactoring legacy code

    I have recently refactored a piece of our product to improve its maintainability. It was a part responsible for (1) receiving messages from outside of the system, (2) calculating appropriate operation and optionally (3) adjusting the data in the database.

    Unfortunately, the code was a total mess:

    • a bunch of EJBs calling each other;
    • working directly on the message data and on JPA entities;
    • selecting and applying the appropriate operation was just a switch with a branch for each mode of operation.
    public class UglyService {
    	private EquallyUglyService otherService;
    	public void processMessage(Message msg) {
    		// ...
    	public boolean isOpen(Message msg) {
    		return msg.getStatus() == Status.OPEN;
    	public void doSomething() {
    	public void updateCase1(Entity ent, Message msg) {
    		if (/* conditions */) {
    	public void updateCase2(Entity ent, Message msg) {
    		if (/* other conditions */) {

    What I did was:

    1. Create a strategy class for each case of that switch statement and only use original enumeration to request a specific strategy from a factory. Each of them implemented an interface.
    2. Extract common parts of those strategies and introduce a composite that grouped strategies. (Factory was still hiding the fact that strategies were being composed as it always returned a reference to an implementation of an interface.)
    3. Wrap the original message object in an adapter and move all service methods retrieving data from the message to the adapter. At this point the code started looking like object-oriented just a bit. At least it is more coherent now.
    4. Implement a factory method in the above mentioned adapter to produce strategies based on its internal state.
    public class SlightlyBetterService {
    	public void processMessage(Message msg) {
    		MessageAdapter ma = MessageAdapter.wrap(msg);
    		Entity original = retrieveOriginal();
    		// Adjuster is usually a composite of several different
    		// strategies responsible for updates of different properties
    		// of the object
    		Adjuster adjuster = ma.produceAdjuster();

    With the above enhancements, it is easy to introduce new actions, each of them is easy to test and if the objects (messages) received by our system change, only the adapter needs to be adjusted.

    That was fun!

  • One hour rule

    There’s been some bad news today, mostly related to the EU Copyritght Reform (articles 11 - link tax, and 13 - upload filters). If that wasn’t enough, there’s more: the one hour rule.

    So we might get a new law that would enforce content removal too quick to be done with appropriate care and thought. Let’s take a look at the statement:

    […] the Commission is proposing a legally binding one-hour deadline for content to be removed following a removal order from national competent authorities

    One hour is expected to be enough to:

    • contact across several different organizations, regardless of time of the day,
    • take it off-line.

    A few questions, just the most obvious ones: who gets to decide whether content is terrorist or not? Who is responsible for classifying it? Is it done proactively by a group of internet detectives? How are power abuses going to be handled? Is the content always going to be removed selectively, or – to meet the deadline – the quick and dirty way, with anything around it?

    But then it gets even better:

    A clear definition of terrorist content

    I can’t even imagine how anybody could think that we can have a clear definition of something like that. There’ll always be some different perspectives and no definition is going to be 100% clear. None will save us from false positives.

    Strong safeguards: Content providers will be able to rely on effective complaint mechanisms that all service providers will have to put in place. Where content has been removed unjustifiably, the service provider will be required to reinstate it as soon as possible.

    This is of course unfair: the authorities have one hour to get our content off-line, but when it is decided that the content was classified as terrorist by mistake, there’s no clear deadline for them to bring it back.

    Increased transparency and accountability: Transparency and oversight will be guaranteed with annual transparency reports required from service providers and Member States

    Annual reports? Having a report once per year means they’re going to have only numbers, with no measures to fix errors in the processes behing them. This also means that improving anything in those processes will take years, because of the huge delay between action and its evaluation.

    All this makes me really worried about the future of the internet. And I hope we can still do something to avoid the tragedy that this one-hour-rule could lead to.

  • Single-handed watches

    Some time ago I’ve stumbled upon Slow Watches, a brand of single-handed watches from Switzerland. Initially I though: what a neat idea! Not much later it appeared that there are at least several companies that produce watches with only one hand.

    Up until now, I have found:

    At some point, I have also found some Belarussian watch with one hand, but I didn’t bookmark it and can’t find it right now.

    There’s something wonderful about a watch with only one hand. It might seem impractical today, when everything is happening so fast. These watches are simple yet elegant, eye-pleasing and still can be used to tell the time quite accurately.

    I think one day I will buy myself a one-handed watch.

  • Jekyll publishing

    I’ve started maintaining this website manually: versioning posts and pages by adding them to a Git repository and publishing the content by manually copying it to my hosting account. But that was the simplest thing I could start with, to make sure that it actually works. Now I’m considering options to automate it a bit.

    At the moment, I am investigating the possibility of using Git hooks to generate refreshed content of my website.

    In the meantime I’ve also added thumbnails to the items in the trips Jekyll collection.

  • Architecture of Open Source Applications

    I’ve recently come across the Architecture of Open Source Applications book and decided to give it a try as it had a reasonable explanation of why it was published:

    Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well–usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another’s mistakes rather than building on one another’s successes.

    Our goal is to change that.

    The list of contributors (co-authors) is quite impressive. The first chapter focuses on Asterisk, which I perhaps should have heard of but haven’t.

    I’ll post a review when I finish reading it.