July 18, 2008

You Can Use Native SQL With Hibernate

Recently, I read a piece at javaworld.com comparing object-relational mapping solutions. It says "Ibatis is powerfull because it allows usage of native SQL queries and Hibernate is a complete ORM solution but doesn't allow native SQL queries."

http://www.javaworld.com/javaworld/jw-07-2008/jw-07-orm-comparison.html?page=7

The link to the last page of the article is above. I met people who thinks that is true but when I saw this in a seven-page article I shocked. Hibernate clearly allows native SQL queries. Below, there is a link to the hibernate.org section of native SQL queries.

http://www.hibernate.org/hib_docs/reference/en/html/querysql.html

I don't know what make people think Hibernate doesn't allow native SQL. Hibernate is a very complex ORM tool and size of it may scare people and they may be don't dig it too much.

I used both Hibernate and Ibatis and both are sufficient ORM tools. I think the only advantege of Ibatis over Hibernate is its simplicity. Hibernate is a full ORM solution and it takes some time to learn the API but it does its job very good.

Comments [1]



July 10, 2008

Changing Position Of A Column In An Existing Table

For some reason, today I need to change position of a column in an existing table. Surprisingly, the only solution I ended up with is to use a temp table. I first execute following sql command;
 
CREATE TABLE temp AS SELECT column1, column3, column2 from table
 
By changing column order in select part the position of the column is changed. Then I executed following command and recreate table using temp.
 
CREATE TABLE table AS SELECT * from temp
 
I think there should be a more elegant solution to this. My table sizes small so I could do it this way but using this solution with big data will certainly couse some headaches. If somebody has a better solution please feel free to specify it in a comment.

Comments [1]



July 06, 2008

Performance Evaluations Does Not Add Value

Recently, I watched a presentation by Jeff Sutherland which is filmed during QCon 2007. In one part of the presantation he said that "A study show that performance evoluations actually disincent employers. 80% of the companies in the world have them and 90% of the companies have them failed to get  any value out of them." This suprised me a lot. I always think that companies should have them.

He said Google is almost unique on the planet that they figured this out and has no performance evoluations. Instead, they make a rule says that every developer must have a web page which includes what s/he is doing and objectives for next three months.

The presentation is about Scrum. It is a fairly good presentation especially If you want to learn about Scrum. The man is a Scrum guru and has a lot of experience in applying it. He also talks a lot about how things get done in Google. I give the link below for people who want to watch it.

http://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland

Comments [4]



July 05, 2008

Hello(with Strategy Pattern)

This is my first post and official opening of the blog. In this very first post I will talk about  a design pattern called "Strategy Pattern".

In Gang Of Four(GoF)'s design pattern book it is defined as "Define a family of algorithms, encapsulate each one, and make them interchangeable. [The] Strategy [pattern] lets the algorithm vary independently from clients that use it."

The Strategy Pattern makes the the desired behavior of an object changeable at run time. It does this by encapsulating the behavior(algorithm) in a seperate class and giving a reference to this behaviour class to the object. Three important design principle applied here. "Encapsulate What Varies" , "Favor Composition Over Inheritance" and "Program To An Interface, Not Implementation".

I want to show how The Strategy Pattern works with an example. Suppose you design a game. Each character may use a weapon at a time and can change his/her weapon any time. It is obvious that the changing part of the problem is weapon behavior. So I should apply the design principle "Encapsulate What Varies" . I will create a new set of classes and encapsulate weapon behaviour in these classes. This set of classes will implement an interface called WeaponBehaviour. So I make use of the "Program To An Interface, Not Implementation" design principle. By doing this, I get a flexible design. The classes which implement WeaponBehaviour interface will be interchangeable.

For a minute think that I don't know The Strategy Pattern and I used inheritance to implement the solution. What will happen? I locked the behaviour to concrete classes and the behavior can not be changed at run time. This show the importance of the  "Favor Composition Over Inheritance" design principle. Instead of inheriting behaviour, Character class should get weapon behavior by being composed(holding e reference) with the right WeaponBehavior object. Another disadvantage of using inheritance, a bigger ang obvious one, when a behaviour is wanted to be added, all character classes are needed to be changed. On the contrary , adding a behavior is a piece of cake if The Strategy Pattern is applied. Because, adding another class which implements WeaponBehavior interface will be enough.

The resulting class diagram is below; 

The example is from "Head-First Design Patterns" book. They ask it as as a design puzzle. I find it appreciate to use in this post. Below I give a link about a real-world use of The Strategy Pattern in Swing.

http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html

Comments [0]