This song can be referenced to “Child Soldiers” and the mindless youth in India, joining political groups like Shiv Sena for “freedom”. You can listen to the song at dhingana at http://www.dhingana.com/gulaal/movie/songs/hindi/latest/5001

यारा हूँ मौला,
यारा हूँ मौला ,
हाँ हे यादों में है अब भी ,
क्या सुरीला वो जहाँ था ,
हमारे हाथों में रंगीन गुबारे थे ,
और दिल में मेहेकता समां था ,
यारा हूँ मौला..

वोह तो ख्वाबो की थी दुनिया ,
वो किताबो की थी दुनिया ,
सास में थे मचलते हुए ज़ल्जले ,
आँख में वो सुहाना नशा था ,
यारा हूँ मौला ..

वोह ज़मीन थी , आसमान था ,
हम को लेकिन क्या पता था ,
हम खड़े थे जहाँ पर ,
उस्सी के किनारे पे गहरा सा अँधा कुआ था ,
होऊ …हूँ …

फिर वो आये भीड़ बन कर ,
हाथ में थे उनके खंझार ,
बोले फेंको यह किताबे ,
और संभालो यह सलाखें ,
जो गहरा सा कुआ है , हाँ हाँ अँधा तो नहीं है ,
इस कुए में है खजाना , कल की दुनिया तो यही है ,
कूद जाओ लेके खंझार , काट डालो जो हो अन्दर ,
तुम ही कल के हो शिवाजी, तुम ही कल के हो सिकंदर ,
हमने वो ही किया जो उहोने कहा ,
क्यूंकि उनकी तो खवाहिश यही थी ,
हम नहीं जानते यह भी क्यों यह किया ?
क्यूंकि उनकी फरमाइश यही थी ,
अब हमारे लगा जायका खून का ,
अब बताओ करे तो करे क्या ?
नहीं है कोई जो हमे कुछ बताये ,
बताओ करे तो करे क्या ?

Will try again

My only rant is the tags on blogspot were converted to categories on wordpress, weird!! so I went ahead and created fresh categories with some of the old articles tagged and some other pending.

The most interesting part of this migration was, I carried it waiting at Newport PATH station over my iPhone. Now when I think about it, it was insane, but amazing…

First the unix version; uname -a

After that I wanted to use some standard linux commands, but they were not available. When using Cydia, I saw some apt-get being executed; so tried it and installed ‘top’
I started MobileSafari to check if was realtime, or it popped up in ms on this screen.

I was bored over the weekend and decided to jailbreak it, and was wondering; “What kept me away from it!!”

As of now the access is restricted, but if you want access, just comment to this post and I shall be glad to add you as a proof reader to my book.

We did not want to use OpenSessionInViewFilter as it is evil (some day I’ll post all the consolidated rantings as one). You can google and find a lot of info around it.

As a quick fix we did what one would first think of, “It’s a demo, just eager load it!”. Well the demo was over and now was the time to investigate a better solution, and we did find it.

It was no rocket science, the solution was available in front of us all along, we just did not look hard enough. When using DWR, there are BeanConverters available which are responsible for this marshalling process. There was one for Hiberante, called “hibernate3″. http://directwebremoting.org/dwr/server/hibernate

The HibernateBeanConverter tries to avoid reading from un-initialized properties. (If you just want something that blindly reads everything then just use a plain BeanConverter).

Bingo, so when exporting a detached hibernate object to DWR, use type=”hibernate3″ and that should resolve the lazy load issues.

Other reasons I was waiting for was better 64-bit Ubuntu support. I still need to reformat my machine. Some of the issues resolved by 64-bit which I was waiting on;

• Flash browser support (had to use a 32-bit script)
• Video codecs (works like a charm, even apple trailers work)
• Open Office (the icons & menu was all messed up)
• Support for my wi-fi atheros chipset (8.10 cured the problem, no more ndiswrapper)

Hopefully this weekend, I should be able to make a transition. Only if I had 64-bit Windows, what the heck, will wait for Windows 7.

Can I go back to Photoshop & CSS again?? Been quite some time now…

Hmm let me think..

By Contract

For use cases, where a certain contracts needs to be followed, we should use interfaces, this allows easier testing and loose coupling of implementation, allowing us more flexibility to change the implementation at run time as asked for.

eg: UserService interface has a method fetchUser();

We can have two implementations for this service method, one using a DAO and other the WebService. Thus the implementation is loose and “the contract” is set to return a User.

By Convention

In certain cases, we cannot implement a contract, esp where the concerns span across multiple layers of the app. This is when we need to define convention over contract. AOP is the perfect use case where this needs to be strictly followed.

Let’s consider the service methods which fetch information for displaying info to the front end. They need to have a specific security restriction associated with it, or a use case where we need to assign “READ_ONLY” rights to certain users for an object. In order to keep the code as decoupled as possible we use AOP, which apply concerns on these methods, without having actual references in the code.

For these concerns to be properly applied, we need to follow conventions.

eg: All DAOs should persist an object using the create() method only, that ways we can add a concern to block access to all create() methods for a group of user. If someone plans to “be different” and follow their own convention, like calling the method persist(), this can open up a huge security hole in the application. The AOP concern will skip “persist()” as it does not follow convention. Such issues will not be caught unless there is a proper code review performed on the code base, or we have really really strong test case.

If your module needs to follow a convention, which cannot be controlled using a contract, please document it, so as the team can follow is correctly.

http://forum.springframework.org/archive/index.php/t-27716.html
http://forum.springframework.org/showthread.php?t=11338
http://forum.springframework.org/showthread.php?t=9810

http://www.hibernate.org/124.html

http://api.blogs.com/the_catch_blog/2005/05/protecting_the_.html
http://hookom.blogspot.com/2004/12/corporate-developer.html

Here is a small tutorial talking about how to develop using POJO’s. Makes you think the non-EJB2 way. (Reading this is strongly recommended)
Part 1 - http://www.developer.com/java/ejb/article.php/3590731
Part 2 – http://www.developer.com/java/ejb/article.php/3592341
Part 3 – http://www.developer.com/java/ejb/article.php/3594121

Since EJB3 is more revolutionary and uses POJO’s unlike remoting in EJB2, here is a link from the sun java forums
http://forums.sun.com/thread.jspa?threadID=5302559

I strongly recommend everyone to read these articles before choosing. My brains had been deep fried already reading these before trying to reach any conclusion. I wanted some other heads to think about these issues and post in their opinions.

Some points where I played the devil’s advocate and jotted my concerns with arguments before we said ‘I do’ to DTO or POJO.
ProDTO: DTO will shield the UI if there are any model changes
Argument: Either ways we’ll have to modify the DTO, the marshaller/unmarshaller to propagate these changes from the POJO to DTO. DTO does not eliminate the problem completely, but obfuscates or hides it.

ProDTO: Our service layer shall talk to various ‘services’ webUI or web Service or RMI or Star Trek, so we need DTOs to provide loose coupling and don’t want the service to expose the domain object directly.
Argument: We will use XML (WSDL or SOAP or RestFUL or ) for data transfer, which will involve marshalling/unmarshalling of the XML to DTO and then POJO & vice-versa, any changes will again have to propagated. through all the layers. We are just exposing the POJO to the XML transformer, not the DAO calls. The POJO by itself cannot persist if in a detached state. Unless we have a usecase of just exposing half the object to the webservice (do we have a usecase?)

ProPOJO: Less effort, lean and clean design, any changes will propagate at multiple places and will provide less points of transformation errors.
Argument: The inner implementation of the POJO with the Data model needs to be changed, but the view/web service does not have to change the implementation. We have to make the changes in these layers even if we don’t have to, there by adding more work and complexity.

ProPOJO: No over head of transforming POJO to DTO and vice-versa. Less memory consumption.
Argument: It’s a good practice to separate your business objects and data objects, provides better decoupling.

Anti-POJO: Handling Lazy Initialization of hierarchical objects, no openSessionInView Filter for ExtJS.
Anti-DTO: Locking of objects for optimistic locking. DTO’s are not aware of the revision.

Conclusion: Use POJOs as detached objects where basic CRUD calls are required and for fetching objects with minimum hierarchy, but if you need to fetch loads of info from different tables with a very small subset of columns from each, then use HQL + DTO

Select new com.vtech.model.dto.CompanyEmployee(bla bla bla);