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.

Someone stoled my session, "And now who can defend me?"

I know that it is not nice to keep talking about Sessions, there so nice subjects out there (modularity, agile, full stack systems, etc), but they seems so far away from me that I cannot really avoid talking about Sessions.

Yesterday I recorded the problem with memory leak, which somehow is related to the HttpSessions. I believe that using a tool like a Session (which is for sure important) make us lazy.

When the system is slow, just put things on the session and everybody will be happy, but is it true? Absolutely not! Some day someone will come to your desk with a nice chart saying saying that your wonderfull application is consuming so much memory that they need to restart the server every two days.

And then what are you going to do? Once everything is binded to the session, your live will get difficult doesn't it? Well, before getting into a new project or storing your nice new object into the session take a look at subjects like REST or some frameworks like Play that avoid the use of session.
For example the framework Restlet do not supply you with any access to the session, and the Play "session" is a simple Cookie, which for sure is small enough to avoid any massive storage there.

Today I am little bit lazy, so here is a list of sites discussing it across the web (there are no state of the art, but you are all grown and can extract the best from it!):

• http://www.peej.co.uk/articles/no-sessions.html
• Web Based Session Management: Best practices in managing HTTP-based client sessions
• Common REST Mistakes
• REST and Session State
• ...
  

I hope it could make we all think a little bit about it.

Oh my God, I don't understand why I cannot use static maps to store user information.

Sorry folks, it was a long time since the last post, but I promisse that I am going back to stay.

Today we will take about a issue that I have heard about in the office for the whole last week: memory leak.

I believe that some memory leak is ok to happen, mainly if you store things on the HttpSession. Let's be realistics, it is a easy solution and if the data keeps on the memory for 30 minutes who cares?

But actually the memory leak that we have found is not realted to the session, it was related to the 2 different issues: thread variables and static maps.

• Thread variables: a lot of things were being stored into the thread variable, and using as key some object. First, usually the web servers reuse the threads, so the information there was being keep for a looong time. Second object as key SHOULD-ALWAYS-NO EXCUSE TO NOT HAVE hash, otherwise baby, guess what? Every add is a new entry on the map. That's a bingo: memory leak.
• Static maps: this is just a more obvious leak than the thread variables, use a static map to store information, where the key also do not implement a proper comparation methods. So every entry lead to a forever-and-ever information into the memory. As as Murphy says: there is always something worst, those information stored into the map where GUI objects, which was reference even to God. And the leak could lead to a OutOfMemory after 5 screen hits.

Nice ins't it? I can understand the problems, what I cannot understand is people blaming the GUI obejcts to have the necessary references. Come on, they are GUI objects that are supposed to work for a single request.
But the real problem is that people still tries to solve problems that are not present yet. The performance problems are the classical example: you never run the application, so you don't know if there is performance problems or not. Why should you address them? Why to worry about it?
Most of the problems could be solve with a proper approach to the problem and not with cache (that usually leads to a whole bunch of other problems). And if the cache is need think about what are you doing: my key if unique? is it replacing the information? what is the live time of the data? should I need another cache than the HttpSession? ...

Make like the buddhists: breath 10 times before doing something, if after that time you still want to do it, go and think about it and then do it, otherwise just go home and relax.

Horror plot in software development!

There are few things in this world that is worth to do over and over again, but I am but that falling in the same stupid errors is not one of them. I have just left a meeting where, for my surprise, people are happy to do it again.
I will put it as example: let's imagine that you have a car factory, your car is not the best in the world, but some people like it. Then you realize that every time that your customer wants a new item into the car (like ABS, radio, etc) you should almost rebuild the car.
After years one of your engineers come up with the brilliant idea: let's build a car that the user can choose what we wants at fly, so if he wants a radio he just tell us and suddenly the radio is there. Uou marvelous isn't it?
Then some more years to develop it, and you finally have the car! But as car stuffs increase people start to say: "you know, let's not make it configurable, it gives us a lot of problem". Sooooo guess what: you end up with the same car as before.
As I told you: the same mistake.

It is like an horror history: doesn't matter how much times do you kill Jason, he will always come back, there will be a lot of blood, a lot of people will died in the way, eventually we could have a happy end (the guy get the girl and that is it); but still a lot of suffering.

The point is: doesn't matter the end, we are still writing horror histories, and there will be blood! We should before changing the players start to think about changing the kind of history, way not action? Or a comedy or a even romance? You know: light stuff!

Going back to our original example: the car was made in the same way, the same approach, way should the result should be different? No way, it will be the same!

About software (yeap it is a software blog): if we keep looking at your application in the same way, they will always look the same. And I am not talking about the technology that we use for that, but the way that we do that.
It should be configurable, let's make it in a way that I could be configurable, not just adding properties. It should be multi environment, let's do in a way that it could be deployed multi environment; and so on.

To finish: in the next article I will add my idea of how a specific kind of enterprise application should be done. Why this kind? In the last years I have faced this kind of application all around and no easy approach to it.

Now you ask me: what kind of application? Well I am writing this post in a thriller way, so you will see it in the next issue ;-)

Alice's Adventures in Procedureland!

When Lewis Carroll wrote his book there weren’t stored procedures, otherwise for sure it would appear in the book. Most of the time procedures seems to come from a dream land, result of a big nightmare.

Well sometimes we have good dreams, as sometimes we have good procedures, but most of the time it is just a dream or even worst: a nightmare.

Let’s put like this: even water could kill in a excessive amount, imagine procedures. That is what I am facing in the current project, a land with a lot of procedures: some of them are like the Cheshire Cat others like the Queen of Hearts, but for sure they are not from our world.

Why are they not from here? You my asked me: well can you version stored procedures? Can you unit test or debug stored procedures? Is there a coding pattern? Can you use common development concepts, fair simple ones like: functions, code split, reuse? Probably the answer to most of these question is: sorry you cannot do it!

Ok folks, before you start blaming me about performance issues: I agree, there is a right place to everyone, even to the stored procedures. But before the end let’s take a look to some code around my project, look how the dependency to the stored procedure recreates some filthy ORCS:

create procedure PP_TODAY
as
begin
select today=convert(char(10),getdate(),103)
end

create procedure PP_HOUR
as
begin
select hour=convert(varchar,getdate(),103) + " " + convert(varchar,getdate(),108)
end

How can we afford this? And do you know what: these procedures are used as part of other procedures in a batch mode. Yes that is true: batch! The files are read and stored in temporary tables and after that a procedure reads each line and them split it, put it into another table and them make a huge processing stack. Let’s face it: we are expending time and resource from the database machine to process something that could be done in another place, look it is even worst: we probably will be running against some production code, slowing down our user and requiring a more and more powerful machine (and at the end blaming the DBMS that we use).



Now I will ask you: is it right? Is it something that Alice would do in the wonderland?

I am back for some finger pointing

Hello all!!!

It was a long time since my last post, I know it. But I am back, and this time for some finger pointing.
Yes that it! No technical stuff here, just fun.

Why are you doing it? (a fair question): I have just jumped in a new project and currenctly I am looking the code around me.
Take a look at this pearl: a class called SwissArmyKnife. What would you expect from it? A class with a lot of util method that makes things that even McGuyver could never imagine, yes that is true... but the reality is a little bit different.

Take a look:

public class SwissArmyKnife {
  public static String getSimpleClassName( String strClazzName ){
    String strSimpleClassName = "";
    StringTokenizer st = new StringTokenizer(strClazzName, ".");
    while(st.hasMoreTokens()){
      strSimpleClassName = st.nextToken();
    }
    return strSimpleClassName;
  }
}