Angry Birds slung from WhyMCA to Vimeo

The video of our talk on Angry Birds is finally online!



All details can be found on the official site. Thanks again to Paolo for putting up with me and to the organizers of the event. Looking forward to WhyMCA 2012 :-)

Angry Birds at WhyMCA

Today Paolo and I have held our speech on the reasons beyond the huge success of Angry Birds.

First of all we would like to thank all our attendees, that decided to spend an hour of their time with us. Too often we only think of what we will say or do in a presentation, and we can easily forget that a lot of people would waste their time if we don't take this responsibility very seriously. We hope all the time we have spent preparing the speech has translated in even the smallest improvement for people who choose to listen to us. The hall was crowded, but then again maybe the other ones were too full and people were looking for a place where they could find a seat and sleep for a while after dinner :-)

The other thanks are for the organizers of the conference, whithout whom all this would not have been possible. They were even so nice as to give us a beautiful t-shirt for free... and I even won a mug :-)

Here are the slides of our speech:

Pattern per un gioco mobile di successo: il caso Angry Birds

View more presentations from andreamoz

I suppose they are not very easily comprehensible without the speakers, but at least I am told the pictures are nice :-)

All constructive comments, positive or negative as they might be, are highly welcome: help us to improve!

Angry Birds invade WhyMCA

On May 20 I'll be presenting with Paolo at WhyMCA Mobile Developer Conference in Milano. Our presentation will start from Angry Birds, the all famous blockbuster mobile game, to introduce the concept of patterns in games, loosely following the ideas presented by Raph Koster in A theory of Fun for Game Design.


The abstract: 12 million paid downloads, 100 million downloads, 50 million Euros under the belly. Why has everyone with a smartphone played Angry Birds? Why is it so addictive? How is it different from games not designed for mobiles, and how is it equal to them? What are the patterns beyond a successful game? Do they hold only for mobile? Is finding them an art, or are they reproducible? Let's find out why the answers are hard wired in our brains.

Read all about it here.

Duplication is evil, double duplication is worse

Think of an application with a domain model in which a person can have several emails, each of which has a different role (e.g. private, office, preferred, and so on). Persons can choose their preferred email for normal communications, but there are other communications that are normally sent to the email with a given role (e.g. communications about personal health will not be sent to an email which is also read by secretaries); only when an email with this role is missing the system reverts to a default email, which is chosen between the existing ones applying a chain of rules.

In an application like this you could (hypotetically speaking, of course) find a snippet of code that returns the email corresponding to a given role:

public String getEmailForRole(Role role) {
 String email = emails.get(role);
 return email != null && isValidEmail(email)
     ? email
     : getDefaultEmail();
}

public boolean isValidEmail(String pattern) {
 return (...stuff...);
}

The isValidEmail method checks the email against a simple regular expression. This snippet springs at least two different considerations.

Check for correctness

One might think that the check for validity is unnecessary, after all checks are done while inserting and updating, right? Partially. Let's just say all checks should be done there, and let's not forget that data greatly outlive applications, so you could easily have strings with completely different meaning stored where only emails should be. Sounds ugly? Welcome to reality. Sure, you could quite easily find all instances of strings that are not emails, but when the customers asks you to leave stuff as it is you have very little power. Other things I've seen include courses descriptions instead of teachers and documents instead of relatives. To cut a long story short, better safe than sorry.

Be clear on intents

Stick with them and hide mechanics. In particular, here we have a duplicated duplication (pun intended):

• the check for null values must be duplicated in every snippet that contains emails.get(role)
• the check duplicates the intent of the isValidEmail method. I think this duplication is worse than the previous one, first of all because the redundancy blatantly hits the eye, but most of all because there is a conceptual duplication: the responsibility for the check should lie in the idValidEmail method itself.

If there's an isValidEmail(String pattern) method I expect it to check for null values without having to bother myself:

public String getEmailForRole(Role role) {
 String email = emails.get(role);
 return isValidEmail(email)
     ? email
     : getDefaultEmail();
}

public boolean isValidEmail(String pattern) {
 return pattern != null && (...stuff...);
}

A more elegant solution could be the creation of an immutable Email value object and the use of the NullObject pattern, a special case of the more general Special Case pattern (another pun intended); in this case the emails object would return a NullEmail object that implements the same interface of the Email class:

public Email getEmailForRole(Role role) {
 Email email = emails.get(role);
 return email.isValid
     ? email
     : getDefaultEmail();
}

A simplistic implementation of the NullEmail object could be

class NullEmail {

 private Role role;

 public NullEmail(Role role) {this.role = role;}

 public String getValue() {return "";}

 public Role getRole() {return role;}

 public boolean isValid() {return false;}
}

If we wanted to explicitly return a String instead of an Email object we could slightly modify the getEmailForRole method:

public String getEmailForRole(Role role) {
 Email email = emails.get(role);
 return email.isValid
     ? email.getValue()
     : getDefaultEmail();
}

As you might have noticed, nothing changed in our NullEmail class - nor in the Email class, which is not shown here.

Of course in this particular case we still have to check for the validity of the email, but in many other places (e.g. print emails of a person for every possilbe role) we can safely operate on our NullObject just as we would on a valid one.

It could be overkill, but it surely gets rid of one of the worst plagues in software: duplication. But that's the subject for another post :-)

Hello, World!

<sarcastic>Ever came within an ace of understanding those damned patterns, but never really got them? Here's your solution: the classic and boring Hello World refactored to patterns - the ultimate experience!</sarcastic>

public interface MessageStrategy {
    public void sendMessage();
}

public abstract class AbstractStrategyFactory {
public abstract MessageStrategy createStrategy(MessageBody mb);
}

public class MessageBody {

    Object payload;

    public Object getPayload() {
        return payload;
    }

    public void configure(Object obj) {
        payload = obj;
    }

    public void send(MessageStrategy ms) {
        ms.sendMessage();
    }
}

public class DefaultFactory extends AbstractStrategyFactory {

    private DefaultFactory() {
        ;
       }

    static DefaultFactory instance;

    public static AbstractStrategyFactory getInstance() {
        if (instance == null) {
            instance = new DefaultFactory();
        }
        return instance;
    }

    public MessageStrategy createStrategy(final MessageBody mb) {
        return new MessageStrategy() {
            MessageBody body = mb;

            public void sendMessage() {
                Object obj = body.getPayload();
                System.out.println((String) obj);
            }
        };
    }
}

public class HelloWorld {

    public static void main(String[] args) {
        MessageBody mb = new MessageBody();
        mb.configure("Hello World!");
        AbstractStrategyFactory asf = DefaultFactory.getInstance();
        MessageStrategy strategy = asf.createStrategy(mb);
        mb.send(strategy);
    }
}

The original post is here. Let me add a disclaimer for the overexcited with their eyes rolling, thrilled about the whole thing and eager to refactor all their codebase: don't try this at home.