Thoughts about Document Oriented Databases - part 2

In the first post I presented some issues that I would like to investigate concerning the Document-Oriented Databases. Now I am going to introduce you with the User Story that I will use as basis for that, so "Sit! Here comes the story!".

Let's imagine a group of geek-nerd-friends, every week day they do something during the night. They have the Halo night, the comic store night, the movie night and so on, a full life. Because of that one of those guys wants to manage the nights, they want to know for each night: the participants, the activities of each one, time of those activites, how much people are involved in each activity and which nice widgets they have to use for those activities.

So let's write our first use story (I will give to the user stories some short name to simplify further references):

PYTHAGORAS: As a nerd, I want to organize the night and distribute the activities of that night across all my nerd friends.

• All the nights have a name, like Halo night or Comic store night.
• It always happens in a specific day of the week, like Halo night is always on wednesday.
• To have a nice night we should execute a group of activities (buy food, bring the game, etc).
• Each activity has one responsible.
• Each activity could need the help of 1 or more people.
• Each activity could require one or more widget to be executed (using the iPhone to find the pizza store, the teleport machine to arrive in time, etc).
• Each activity should be done to have a nice night.
• A night is ready to start when all the activities are done.
  

Based on this user story we can create this base class diagram:


These classes will be improved over the time, but with the current information is what we can create.

To understand the class model, here is the test case of the Night::isNightReady() method, it will help to understand what a Night and an Activity is:

@Test
public void testIsNightReady() {
    Night saturdayNightFever = new Night();
    saturdayNightFever.setDayOfWeek(DayOfWeek.SATURDAY);
    saturdayNightFever.setName("Saturday Night Fever revival night!");

    //No activities means that the night is read to start
    assertTrue(saturdayNightFever.isNightReady());

    //Let's add a list of activities in the night
    List<Activity> activitiesOfTheNight = new ArrayList<Activity>();
    saturdayNightFever.setActivityList(activitiesOfTheNight);
    assertTrue(saturdayNightFever.isNightReady());

    //For a saturday night fever we need to practive dance listening the BeeGees K7
    Activity practiceDance = new Activity();
    practiceDance.setWhatShouldBeDone("Dance listening BeeGees K7");
    practiceDance.setResponsible("me");
    saturdayNightFever.getActivityList().add(practiceDance);

    //And also get the nice white suite
    Activity takeTheSuite = new Activity();
    takeTheSuite.setWhatShouldBeDone("Take the white suite at mother's house");
    takeTheSuite.setResponsible("me");
    saturdayNightFever.getActivityList().add(takeTheSuite);

    //And finally meet the girl
    Activity meetTheGirl = new Activity();
    meetTheGirl.setWhatShouldBeDone("Meet the girl at his house");
    meetTheGirl.setResponsible("me");
    saturdayNightFever.getActivityList().add(meetTheGirl);

    //I have done none activity, so the night is not ready to start
    assertFalse(saturdayNightFever.isNightReady());

    //I've found the K7 and danced a lot, but still not ready.
    practiceDance.setDone(true);
    assertFalse(saturdayNightFever.isNightReady());

    //Got the old father's white suite at moms house
    takeTheSuite.setDone(true);
    assertFalse(saturdayNightFever.isNightReady());

    //Meet the girl
    meetTheGirl.setDone(true);

    //Now it is time to ROCK
    assertTrue(saturdayNightFever.isNightReady());
}

And finally I have set a project at GitHub: TADOD, so I will keep publishing the code there.
It is a maven project, so it should be easy for everyone to download it and run. All the entries in the blog will be present in the project site (just need to execute mvn site).

In the next post I will define the interfaces of the services, so we will be able to create the test cases and later start your analysis.

See you soon, and have a nice 1st of May (beware of the Punks around).

New pattern - The Match Marker Design Pattern

Yes that is true, the GOF Design Pattern book is not the bible of the OO design patterns; it is just The Book of Genesis, the beginning but it is far away of the end. In fact new problems, causes new common ways to solve them and at a final stage new patterns.

In a recent article Michael Bar-Sinai presents a new pattern The Match Marker Design Pattern, which has the intention to solve similar problems to the Visitor pattern. The main idea of this pattern is to solve the situation where you want to extend the action applied to your business objects in a better and clear way than just extending objects.

Let's suppose this problem (well it is the same one presented by Michael, I guess it is easier to show the same): you have an Employee and needs to calculate the salary of it, as type of Employee we have Manager and Engineer. How to solve this problem? Create a salary calculator that has a method that checks the instance of the class to calculate? Does allow the Employee to return the salary and overwrite it for each class?

Well take a look at this pattern: it is a interesting way to solve the problem: The Match Marker Design Pattern.
For those that want to remember the Visitor pattern, here it goes an article explaining it: Design Patterns Uncovered: The Visitor Pattern.

Enjoy it!

Java in the factory field

Back to the middle of 2003 I have spent sometime reading and investigating how to use Java in the factory field, based on some standards like Fieldbus, Profibus, Supervisory Systems and so on. It was an early time, a time that I was walking in green fields but without money or contacts to transform the research in something more concrete.

Not that nowadays I have contacts or money, in fact I am not even in the green fields anymore, but looking at my old papers and pdfs I have found those documents. And it brought me some curiosity where was the state of things in this area; back to that time we had a lot of papers, researches but no real implementation in the factory fields itself; it was still the realm of C programmers.

For my disappointment a brief search and inspection proved that Java hadn't stepped forward in most of these areas, but a work demonstration at JavaOne 2007 looked really promising. It is an industry robot automation using merely JAVA, for sure it is using the Real-Time Specification for Java 2.0, as we need a more strict control over what is happening in the machine.
It is used on top of a bus standard called EtherCAT, which is a kind of bus that communicates over Ethernet and not some serial protocol.

The main point here is to see that it is possible to have Java running in a critical environment that needs time based response in a preemptive mode. By the way if you want to see the robot in action just go for this video World's First Java-Controlled Industrial Robot



For those that want to remember about industrial bus here is collection of wiki pages that could helpful:
- Fieldbus (http://en.wikipedia.org/wiki/Fieldbus)
- EtherCat (http://en.wikipedia.org/wiki/EtherCAT)
- Profibus (http://en.wikipedia.org/wiki/PROFIBUS)

And finally the paper Using Real-time Java for Industrial Robot Control that has an overview about the robot implementation with java.

I hope you enjoy it as a new curiosity area or make you remember old hard working days!

Where is your coin?

Some time ago people used to believe that you should bury a person with a coin in his mouth in order to pay the ship (or at least to guarantee a good place in the ship) to the land of the death.
If even in the land of the death, in the other world, there isn't free entrance, imagine here, imagine in the software's land. In a nutshell: there isn't free lunch. But why all this death, lunch talks; are you hungry? Are you afraid of dying?

No, absolutely not! The question is that people still think as new technologies as a free lunch, something like, an all around solution. If you need speedy them you should let it go the versatility, if you want all around solution them forget the speedy and welcome to the complexity nightmare; the blanket is not big enough for everyone.

I guess that all of you already heard about those Agile things like XP, Scrum and others, they are not really the same thing but all of them propagate the idea of: postpone as much as you can the decisions, most of the time you will realize that they are not needed or you will have the enough knowledge to do it right; I completely agree with that (by the way it doesn't means that the decision should not be made or it should be a no meaning decision, like a lot that we see around).

And them you come to NoSQL alternatives, quite flexible and it seems to fit so smoothly that it is like a temptation. No schema, you are so free to change it that you can even have different versions of data in a productive environment, really nice. Do you remember that we need to give the coin to the punter? Well, the NoSQL is a really light because of the simplicity of its schema, no rules, but it has a cost, the queries.
Once you go for this kind of solutions you need to pay in the queries, you don't have the power of the relational databases here. If in one end you don't need to think about the schema in the early beginning at the other end you DO need to think about how you are going to look for that information in the future.

Most of those solutions requires you to duplicate data if you want two different queries at the same time, or you need to create a view that will be your query, or simply no query at all, just a sequential access to the data (in a predefined order). The benefits? Fast, light, easy to distribute, but you need to pay a price for that.

So are they not really going to work in the real world? Absolutely not! Do not misunderstand me, they have a place, and I guess a big one. But we need really to understand what kind of application we are going develop, in the early beginning to know if it fits or not, and to address the needs of the technology.

The point here is: you need to know with whom you are dealing; do not take only the nice words of Agile and NoSQL; otherwise you will fall in the sing of the sirens and your ship will crash the rocks of reality.

As usual I will let a link here, I guess it will help you all to clarify what I am talking about the drawn backs of the NoSQL technology (in this case Cassandra): WTF is a Super Column