Development, music and the 80s

Today is Friday! It is usually a day for going out drinking something, listening some music, having some fun.
It is difficult to find someone that doesn't like this kind of thing, isn't it? I usually develop listening to music, tying to have some fun too (all of this just to say that I listen to music).

Yesterday was thinking about what to write today in the blog, a lot of nice topics end up in my mind, but in the between a match and the other in the Winter Olympic Games I zapped to a channel with a 80's marathon. Everyone that remember the 80's movies knows that they have a lot of music, kind of ridiculous clothes and a lot of teenagers.
But listening to them I notice a lot of similarities with your developer day life, I don't know if it is because the personal computer are a boom from the 80's too or just a trick of the destiny, but it is unbelievable how those music says about your job.

Here I will add parts of some lyrics and you will see (ok not all of them are from the 80s, but come on everything has a beginning)

Customer asking for a new project

I need a hero
…
He’s gotta be strong
And he’s gotta be fresh from the fight
…
He’s gotta be sure
And it’s gotta be soon
And he’s gotta be larger than life

Somewhere after midnight
…

- I need a hero "Bonnie Tyler"

About that last minute change request

Who's gonna tell you when,
It's too late,
…
You can't go on, thinkin',
Nothings' wrong, but bye
…

- Driver "The cars"

A ever standing request in the list?

Its my own design
...
I can't stand this indecision
Married with a lack of vision

- Everybody Wants to Rule the World "Tears for fears"

A new incredible "never-ever-though" feature rises

What is it good for
Absolutely nothing
Say it again
...
What is it good for
Absolutely nothing

- War "Edwin Starr"

A good UI interface

More than just blind ambition
More than just simple greed
More than just a finish line
...
Like a streak of lightning
That flashes and fades
...
More than high performance
More than just a spark
More than just the bottom line
...

- Marathon "Rush"

Trying to avoid that 90 degrees change on the project

But it's gonna take money
A whole lotta spending money
Its gonne take plenty of money
To do it right child

Its gonna take time
A whole lot of precious time
Its gonna take patience and time, ummm
To do it, to do it, to do it, to do it, to do it,
To do it right child
...

- Got my mind set on you "George Harrison"

Fell free to send me any nice music that you think represents oour day life. I will try to make this post more often!

Enjoy the day! Enjoy the life!

Branch per feature

Last Friday I have read an article from Mr. Martin Fowler about VCS, focusing in Distributed Version Control System. Although it is an interesting topic, I guess it is a kind of technical discussion if it should distribute or not.
Before someone wants to shoot me, I know that there are advantages over a central system, but the point is that I don't want to highlight it here.

Actually it is much more interesting all the patterns that emerged with this kind of VCS, not because they didn't existed, just because the DVCS makes then simple. So ladies and gentlemen I would like to introduce you the amazing Spider-man!!! Ops… wrong introduction… I would like to introduce you the Feature Branch technique (a.k.a Branch-Per-Feature).

The main idea of this technique is: every new Feature of your software becomes a branch in the version control system, and as soon as this feature is implemented the branch is merged to the baseline. Simple isn't it? There are quite few advantages in this technique, the main one (in my point of view) is that you can release the software with the desired features as soon as they are available.
For example, if you have 3 features on the go, but one of them is important and should be released right now then, just merge it to the baseline and you are ready; the other features are no impacted and your delivery do not need to wait for that.

I don't need to say that to have it working like a charm, continuous integration is a must.

There are two really good articles about it, the first is an introduction about it by Martin Fowler and the second is a How-To about implementing this kind of technique.

• Feature Branch
  
• Branch-Per-Feature Source Control
  

I really got enthusiastic about this kind of source control technique, it is really usefull if you are interested in selling services and not software, so for you last minute services are almost a must.

Have a nice week.

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