Continuations

Yesterday I spent quite few time trying to solve some problem related to old data stored in the webapp session. It made me remember a similar situation few years ago, when I had hard time with the same problem (not that it just happened twice, but those two times were quite remarkable).
But there is a small difference between those two situations, a small difference that makes all the difference.

In the early days I was dealing with a kind of application similar with those online selling: a lot of pages that you must commit the information only at the end. So the use of the session, although not mandatory is almost 100% of the choice. But the application of yesterday is the opposite: it should commit the changes all the time, almost at every breath of the user; but again we are using the session.

I remember myself thinking how it would be nice and simple to get free of the session, all those synchronization problems, back button problems and so on. And now I have an application that could act like saving all the time, but still we are stick with the session. Why?

Well I don't have the answer but I guess it is just a question of old habits, justified by the performance of using the session. And that is my point: is the session the best high performance solution?

Well, I would like to have numbers about it (maybe in a future post), but it is well spread the idea that session is an enemy to scalability. It makes all the sense, but a non-session world looks like to be impossible outside of the books.

I do not advocate about killing the session, no!, but a better management of it is crucial for: a better performance application (memory leak can kill an application more easily than a slow response time) and a smooth programming (spend hours trying to find out why things do not match is not nice).

As I said in the beginning, it is just a way home though, but it deserves some kind of investigation, what the world thing about this subject. Despite of the REST way of doing things (which we can discuss later) I have found a nice third wave, something that they claim to be Statefull programming model for a stateless world: Continuations.

I would explain it here, but there is nice article at IBM which can do this job much better Crossing borders: Continuations, Web development, and Java programming.

I hope you enjoy the reading; maybe it could make you less angry next time (knowing that there is a brighter life out there).

Patterns of Deployment

Today I was looking at a Javalobby post, that highlight some deployment tools. Between those tools there is a interesting one called SmartFrog (java based and developt by HP, yes it is true, these guys still have some projects).

SmartFrog is a powerful and flexible Java-based software framework for configuring, deploying and managing distributed software systems.

Take a look if you want, but the main idea of this post is to invite you to see one of the SmartFrog wikipage: Patterns of Deployment.

In that page you will find nice patterns to deploy application, some address by SmartFrog, some not. But the main idea of this page is to show you the possible patterns and tools for that.

I am sure that you need to deploy your application and maybe creating the .WAR is not enough or that easy ;-)

It is in the corner, just waiting to spook you!!!

Today is friday, carnaval is close (although I am not going to have holidays, but it is ok, I hope someone will enjoy it for me), so I will not talk about boring stuffs like datastores, performance, why the world is not green enough, why my house does not have a auto-clean button and so on.

The post of today is just to invite you all to take a look in another post, from Joel Spolsky, "The Law of Leaky Abstractions".

I am sure that it is something that you already know, feel it in your heart, but it is nice to see someone writing about it. The example about actors travel is quite good :-)

I hope you all enjoy and have a nice Carnival/Fastnacht (hope it is right guys :-)

Key-Value stores

To finish the posts about different kind of storage mechanisms I would like to introduce you to the Key-Value datastore.
A key-value datastore is nothing more than a BIG hash table that is able to persist the data in the disk. So why is it interesting? Why would it count as a remarkable datastore?

For sure it is not a new technology or even a new concept, but your Google friends brought it to light doing map reduced processing over key-value datastores. This kind of store is easy to persist, easy to distribute over many nodes (ok there is a lot of technology behind it, but still easier and faster than a relational Database).

I know that it looks like a geek subject, but if you think about the kind of applications that you have, you will find something that will fit in this concept, and maybe you are using relational databases and a lot of tricks for that.

For the moment I would just like to make a note about this subject, but for sure I will return to comment about it (maybe with some examples).

For the time, if you are interested in it, please refer to these projects:
- Keyspace : the whitepapers of this projects give you good idea how it works and where you can apply it;
- Voldemort : a promising datastore (used by linkedin).
- Richard Jones had made a nice post with comments about key-value datastores, much deeper than this one. Please pay a visit really good reference about the subject: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/.


Hope it could trigger some lights for you as it had for me :-)

Document-oriented databases

In the last post I have talked about Graph Databases, and today I will keep in the same direction and talk about another kind of database: Document-Oriented database.
A document-oriented database is not a Content Manager system, although some similarities. Usually this kind of database could be view as a KEY-VALUE database, where the key is a unique id (handled by the database) and the value is your document.
The way that the document is described can vary from database implementation but currently the most accepted format is JSON; also the databases offers good query and indexing features to make this data workable in real applications.

This kind of database can be really handful for applications with documentations that evolves among the time and they all can exist at the same type. As the Graph Databases it is not a replace for relational databases, it is another way to store and structure your data; and a way that can be really good for common data store applications.

I would like to end the post with three links, it is a good start to understand how document-oriented database works:

• http://www.mongodb.org: MongoDB (from "humongous") is a scalable, high-performance, open source, schema-free, document-oriented database (thanks Tiago for the tip for this database).
• http://couchdb.apache.org/: Apache CouchDB is a document-oriented database that can be queried and indexed in a MapReduce fashion using JavaScript. CouchDB also offers incremental replication with bi-directional conflict detection and resolution.
• http://books.couchdb.org/relax/: CouchDB: The Definitive Guide (to understand a little bit more about this kind of the database, read the Introduction).
  

See you in the next post!

Graph Database

Graph database are not about images or graphs and things like that :-). They are simply a database organized as a Graph, you don't have tables, you just have nodes and relations.
Interesting concept that can be applied in some kind of structure that we could need to have work with.

Too conceptual? Well I suggest you to take a look at the project Neo4j project. It is a java project that implements a graph database.
Take a look, investigate the examples, I am sure that you will find where to apply it easily (at least you will know that there is another option to your good friend Relational Database).

• Neo4j project page: http://neo4j.org/
• Neo4j introduction pdf: http://dist.neo4j.org/neo-technology-introduction.pdf

Guidelines!?!

This month at the working place we could manage to promote some Design Pattern training. The really basic about the patterns, a quick and dirty overview of Gof's patterns.
I am not here to discuss the importance of the training, how basic it could be, if people should go to learn it by them self or whatever. I am here to discuss the results of the training.

We have managed to make 2 days in 2 followed weeks, and with 2 different groups. Most of the people thought that it was interesting and valid, and at the end of the sessions we come up with the discussion if we should continue with that or not, and of course what could be the next steps. A reasonable amount of ideas come up from, nice ones, other I think not that nice, but still ideas for next steps.

During the last session one of your colleagues talked with the Big Boss, about the ideas, with the purpose to give a feedback and collect the sponsoring need for the next sessions; but guesses what: an answer more less like this – "I believe that we can come up with some guidelines, publish it on the wiki page and people go there read and learn". Simple as that, why have we never thought about that? Unbelievable how stupid we are!

Or may be not? I fact I believe that not! Guidelines as the name (which in English is straightforward) are for guiding, are not for learning, usually in a guideline you have small sentences that gives hints for the people. Let's take an example: imagine a guideline like this "Prefer Abstract Factories over the Factory method and make them always return interfaces", what could happens if the reader does not know what is a Abstract Factory of a Factory Method or even an interface? From two one: or he will ignore it completely or it will take this guide line as a God message and follow is an immutable rule, something that if not done will make him end up in Hell!

None of these situations are beneficial; by far they are really bad. Guidelines are guidelines, rules are rules and knowledge is knowledge, both should exist but one cannot be exchanged by the other. Another point about guidelines, I don't believe in guidelines coming from a group of people (which in most of the places are a split department creating them as God writing the 10 Commandments) and releasing it. It should come from a common sense, and I am not only talking about programming, here you can include, analysis, requirements and so on.

I have already worked and participated of a projected that we have created immutable guidelines (or rules if you prefer a proper name) and it end up with a complex unnecessary structure – believe me a waste of time creating Action->that calls->Façade->that call->Business Objects->that calls->Dao->that converts to->VHO->is stored in the database, most of the time to be used for a internal web application that could have being solved with some Action->Dao thing.

So Guidelines are useless? Sure not, they are really useful for someone that can interpret them; otherwise people will lost faith on the guidelines and in the process and they will start to believe that it is a bunch of stupid rules for nothing. And at the end you will end up with zumbi-developers and a bizarre-code.