Friday, 23 May 2008

New Baby on Board : GraniteDS

I have just come cross a remoting alternative to BlazeDS which is called GraniteDS. Even thought it uses the same core classes it is much more simple and Google is behind that project.
Just as they say now it is so hard to determine if the future of Flex Data Services will be in GraniteDS of BlazeDS. I tried it and it works fine.
I am so happy to see that Google is supporting a commercial product like Flex. It is extremely easy to integrate this open source solution with spring framework. And it is nice to develop POJOs to communicate with remote interfaces. I suggest everyone to try this one, and Google guys... Well done and I hope you can also add data synchronization soon..

Thursday, 22 May 2008

Antipatterns; Building unextensible software

For some time I have been writing some posts about design patterns. To show why they are important and how they help let me also introduce you The Anti-Patterns.

Recently a friend asked help for some professional advice for their company's running software, so i went as a consultant and examine their software and needs. First let me give you some brief imformation (without mentioning the companys name). They are a small-mid size company in health business, who have very basic network and computer setup. The have a professional financial software which works fine, but what they fail is their custom built software. They started coding the project 2-3 years ago. Since they didn't have an IT team (and they still don't have a real one) they asked a software company to guide them and hired some professionals(?). The developer on their side has changed up to 4 times and the software company who guides them had only one developer who know about their project and he already left the company. So now nobody can help about the new software needs and bugs.

When I first entered the server room instead of checking the interfaces, I wanted to see the database (as a Domain Driven developer). They had 160 tables coupled with 140 stored procedures and about 20 views. Heavy use of stored procedures caused the business buried into database but the software also still has some of the business logic which make the business flow divided into two (Layered architecture failed). When they showed me the functionality of the interfaces I was so suprised that I have seen so many tables for so simple functionality (over complicated db structure). Meanwhile when I checked the tables i saw that they are not normalised and some have more than 30-40 columns (db normalisation failed). I wanted to check the classes but the first thing i figure out was some classes has over 15000 lines of code (keep your classes short). Then they mentioned about their reporting needs. They have some reports which can not be sorted, new parameters or columns can not be added. I was so suprised when the marketing department said we cant get the patients ordered by city so we just count them one by one over the report. That report which their IT stuff cannot get ordered, is a report querying just one table and the city information does not rely on any other table, it is just an embedded column in that table. Come on even a fresh graduates would order by that query in few minutes.
Their software has all major anti-design patterns including spaghetti, dead end, golden hammer, lava flow, the blob... and just like most IT projects the software does not have any documentation, and the back office part is not completed (ex. they can't add new doctors to db).
One of the thing they complain about was funny. The software closes all instances of internet explorer when the user session is expired and they are not happy with that. Without checking the code, I told them to use firefox to browse the internet but continue using ie for their software. Well simple solution but works ok for them. Rest of the problems, i suggested not modifying the current software since nobody knows the structure so it will take too much time and would be so fragile. Instead we can make a new one which has only the features the current one lacks. So they would need to run both same time.
Well the other option I suggested was if they have enough budget and time to built a new one from strach with new and modern technologies like Java and Flex.

DZone publishes RefCards

A colleague just send me a link Spring Configuration Reference Card. There is also other versions such as GWT, Ajax and Eclipse. The best thing about these articles is they are all written by authors of related "in action" book from Manning. Personally I really like In Action series, so I will regularly check for new ones. You want to check? Click this link

Tuesday, 20 May 2008

JavaFX on JavaOne

JavaFX was the most interesting topic on last year's JavaOne. Well for one year we have been waiting and this year it looks more stable and more complete but still i am not happy with tool support and maturity.
If you still haven't you should watch this years JavaOne presentation of JavaFX. Better to see with your eyes pros and cons to decide better at choosing the tecnology.



Well looks nice, hope JavaFX can go on...

Design Patterns Revisited (2)- Decorator Pattern, Decorating your software

The decorator pattern is the second most used pattern for me after singletons. I really recommend you to read chapter 3 on Head First Design Patterns which I think has the best example for the topic.
Here is a real life story; Several years ago one of my colleague and I developed a software for Order and Payment management of Restaurants. That time we had concrete product objects with price property. In time some restaurants started asking for products which can have extras like pizza but with extra cheese or kebap but with yoghurt. We asked them to create new products from back office for that extras which changes price of the product. What we failed was we thought if the price changes there is no harm to create that as a new product but imagine a pizza with combination of 20 different ingredients.
Long years after it is so easy to see what we had failed. We needed to decorate the products instead of just adding a detail text which can't update the price (just like we did).
Decorator pattern is very easy to understand, use and implement. Lets imagine we have a car factory and we offer a variety of options to our customers like, sunroof, airconditioner, airbags etc.
First of all we need create our car object, to make it simple I will be demonstrating a concrete car object but the best use should be creating a car interface and built your car objects implementing this interface.

public class FamilyCar{
private String description="This is family version 5 door";
private double price=10;
public String getDescription(){
return description;
}
public double getPrice(){
return price;
}
}


So far so good, but as our car hits the stores, customers would like options like sunroofs, extra airbags, child seat, a/c and we can't give those for free. So lets create a decorator, again for ease of understanding i am creating a concrete decorator class, but in real life we should do that via interfaces for extensibility.

public class Sunroof{
private FamilyCar familyCar;
public Sunroof(FamilyCar familyCar){
this.familyCar=familyCar;
}
public String getDescription(){
return familyCar.getDescription()+" with sunroof";
}
public double getPrice(){
return familyCar.getPrice()+(familyCar.getPrice()*0.1);
}
}


So simple, you want to sell a family car with sunroof, create a family car object and decorate it with sunroff, thats it. You may have notice right now we cant handle to sell a car with sunroff and airbag (imagine we also have an airbag decorator) which is not good. So lets change our implementation...

public class FamilyCar implements Car{
...

public class Sunroof implements Car{
private Car car;
...

public class Airbag implements Car{
private Car car;
...

Now you can create a family car decorated with sunroof and airbag and the price would be calculated automatically.

new Airbag(new Sunroof(new FamilyCar())).getPrice();


You may have different interfaces for your Car and Option decorators and let your decorator interface to extend your car interface so you would seperate implementations. Either way you choose, you will have vast variety of options to decorate your car and you will be the most extensible car dealer who can offer any price for any options wanted by their customers.
Not bad? lets burn some rubber and do not hesitate to use the decorators whenever you think they might work...

Friday, 9 May 2008

Design Patterns Revisited (1); Singletons, how single they are..

Well enough about giving thoughts or chatting about flex, lets get back into important stuff. I decided to give write several posts about design patterns. Either you use or not they are important and make your life easier (and probably increase your salary). Even you really not interested in design patterns, you will face questions about some in interviews or architectural design meetings. So better open up your brain and learn some, nothing wrong to impress few colleagues.
The first pattern I will post is the Singleton Pattern. The mighty gof explains this pattern as; "Ensure a class only has one instance, and provide a global point of access to it.". Simple isn't it, if you need only one instance of a resource mostly because it would be expensive to create and hold new instances, you make sure there is only one unique living instance of that object. Singleton objects are god and if you don't want chaos, conspiracy and fight like Olympian Gods than you must make sure you have only one!
Back to basics how do we construct and instantiate an object.. yes just by using the constructor. Even we don't type the compiler creates a default one for us. So to take control from the compiler we just create a default non-argument constructor and mark it as private. So we ensure no one would ever has access to it, to create a new instance(A). Next we type a public static method so whoever wants to use our object must use that entry point to access(B).
public class SingletonObj {

private final static Singleton instance = new Singleton(); // our unique instance

private Singleton() {} //A

public static Singleton getInstance() { //B

return instance;

}

}

This is the most simplest way to show a singleton. You may also want to use a static initializer so our "instance" will be initialized only when it is first accessed.
public class SingletonObj {

private final static Singleton instance = null;

static {

instance = new Singleton(); // our unique instance

}

private Singleton() {} //A

...

Or you might check if it is initialized in getInstance method.
public class SingletonObj {

private final static Singleton instance = null;

private Singleton() {} //A

public static Singleton getInstance() { //B

if (instance == null){

instance = new Singleton(); // our unique instance

}

return instance;

}

}
All of the examples above works quite same and ensures the current running JVM has only one instance. Most experienced ones are now quite ready to leave a comment on how to hack this design. Ok, you can't just really ensure, but it is a hack and you must be expecting your colleagues not trying to break your design and mess up with resources :)
Since JVM lets us to access even the private methods by reflection and once we get the methods it is possible to change the access rules and create new instances. Here is how to create more instances from a singleton;
public class SingletonHack {

public static void main(String [] args);

Class clazz = Class.forName("SingletonObj"); //we load the class

Constructor[] cons = clazz.getDeclaredConstructors(); //get the constructors

cons[0].setAccessible(true); //change access rights

SingletonObj noMoreSingleton = (SingletonObj) cons[0].newInstance();

//we have brand new instance

}

Actually this is not something new and I'm quite sure most of you already new it. Java is just like having jedi powers. "The dark side of the force is a pathway to many abilities some considered to be unnatural". When you really need, it offers a dark side to make things work but you shouldn't be using that powers and staying on the light side. If you feel you need such a hack you must look back and try to find what did you do wrong and put yourself in Anakin's shoes :)

Sunday, 4 May 2008

IBM on Java EE 5

As a former Websphere specialist I must confess lately I had been really far away from websphere platform. After our Eclipsist presentation we had some questions about Websphere 6 & 7 aplication server compability with ejb 3. First of all IBM has released Websphere 7 which runs on Java EE5 so any one using WAS7 can use our EclipsistEE project.
The second and interesting news is IBM also released a SOA feature pack equipped with EJB3 for WAS 6 (which will be called 6.1). I remember every new feature or fix pack of IBM really made me nervous since they come up with new problems but this time the change is worth to try so I encourage all EE developers to try new featues. At least how bad could it be than EJB 2...

Friday, 2 May 2008

Eclipsist Presentation Available...


At last just as we promised on our workshop full source codes with jar files are available as eclipse project on our cvs server. You can check out the projects by these settings;

Connection type: pserver
User : eclipsist
Password: eclipsist
Host: yenerm.homeip.net
Repository path: \sys\okyanus

If you face any problems while checking out please feel free to contact us. You may face connectivity problems and slow transfer rated since this is an home server.


We have so many positive feedbacks and want to thank you all. We also have your negative comments and concerns. I am sure most of java and eclipse guys dont trust flash runtime just as they trust jvm but hey youtube runs on flash streaming, microsoft makes vista and silverlight presentations with flash and Flex is so much mature than JavaFX so why dont you give flash a chance. Also dont forget Flex SDK is open source and comes with it is own jre so actually it is not really leaving Java environment.
Also some people might think we could built the project so fast and easily since we are experienced on those tecnologies. Well no you are wrong, we migt be experienced in some but we are not using EJB3 or BlazeDS in production but we could manage to code them just as Spring and WebServices. Please do not afraid and just try to code on your own.. and if you still have trouble let us know. May be next time it will be better to guide a volunteer who is not interested and let him/her to code, to show you how easy it is.
Finally thanls to all our collegues and so many thanks to Naci Dai and his team who let us have this chance..

P.s. we are planning to publish a screencast to show how easy to code to people who didn't have chance to attend the workshop...