TODO: Cleanup blog

I'm not able to get any good templates, I think I need to search more on the web, or come up with a good design myself...

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

Hmm let me think..

By Contract or By Convention

Should we be using interfaces for everything and making everyone explicitly implement them or should we trust that everyone follows the same convention.

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.

2 DTO or not 2 DTO

Since the new project began I've been think about this over and over again reading as many posts and taking ideas from different posts and blogs. The more I read, the less I knew. Below is a collection of few links I've come across which have some conclusive and non-conclusive decisions/arguments, some of these post lean towards POJO's and some towards DTO. Frankly I was not been able to convince myself on what to use. (Leaning more towards POJO's as detached objects).

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);

You've got hacked :)

Yup since I opened up the ssh ports, once a day someone tries to get into the system. Here a small piece of log,
Oct 13 17:19:07 *******-server sshd[7250]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.117.255.223 user=nobody
Oct 13 17:19:09 *******-server sshd[7250]: Failed password for nobody from 58.117.255.223 port 35131 ssh2
Oct 13 17:19:17 *******-server sshd[7255]: Invalid user patrick from 58.117.255.223
Oct 13 17:19:17 *******-server sshd[7255]: pam_unix(sshd:auth): check pass; user unknown
Oct 13 17:19:17 *******-server sshd[7255]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.117.255.223
Oct 13 17:19:19 *******-server sshd[7255]: Failed password for invalid user patrick from 58.117.255.223 port 35703 ssh2
Oct 13 17:23:50 *******-server sshd[7325]: Invalid user jane from 58.117.255.223
Oct 13 17:23:50 *******-server sshd[7325]: pam_unix(sshd:auth): check pass; user unknown
Oct 13 17:23:50 *******-server sshd[7325]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.117.255.223
Oct 13 17:23:52 *******-server sshd[7325]: Failed password for invalid user jane from 58.117.255.223 port 52794 ssh2
Oct 13 17:23:59 *******-server sshd[7327]: Invalid user pamela from 58.117.255.223
Oct 13 17:23:59 *******-server sshd[7327]: pam_unix(sshd:auth): check pass; user unknown
Oct 13 17:23:59 *******-server sshd[7327]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.117.255.223
The address belongs to some kid in China (Beijing Education Information Network). The box has been safe so far.

Nobel Gases

Finally after successfully setting up OpenVPN with Linux server and XP/Ubuntu clients (Vista is evil), we decided to create the final network, but were stalled with the general problem of names (wonder what will I do when I have to name my kids!!). Looked around for tips and there is an RFC on it RFC 1178 which gives a few tips for names.

Without much ado the names helium, neon, argon, krypton clicked. Nobel Gases I say...

Book progress

I've finished the first chapter and have been able to rope in a few friends help me proof read and correct me along the way. I had never thought writing a book would be so much fun, but there is a lot of thought process also put in to make it as simple yet professional for anyone and everyone to understand.

There are many references from wikipedia for definitions of certain terms and terminologies. For those who don't trust wikipedia can search up their favourite reliable resources for further explanation and review.

Another interesting problem I'm facing as I go ahead is, how much detailed should the explanation be. What is the level of assumption I should consider while explaining a topic. Hopefully my friends will be able to point that out, if you are interested to participate in the proof reading, just drop me an email and I'll be glad to send you an invite.

My first E-Book: Kick Start a software start-up

Ok after all the configuration and working of the VM server with 4 virtual machines, I found it too much info to blog (lazy me..) with all the steps and configuration (I have some 3 posts still as draft yet to be published). There were some random thoughts on how this process and infrastructure can be used by others (start-ups or low budgets) for thier benefit.

Since most of the blog postings are enlightenments that occured to time once in a while, I've decided to consolidate all this information and jott them down like a step-by-step guide on how can we use the VM infrastructure for small shops or small projects in large shops. The table of contents for this book will look something like this.

Table of Contents

• Preface
• Who should read this book
• What are the technologies we'll cover
• Introduction
• Analyzing & Building the server
• Software selection.
• RAID & LVM
  
• Setup & Configure your first VM
• VPN Applicance
• Creating more Appliances I: Webserver, Database
• Creating more Applicanes II: Version Control, Continious Integration Servers
• Timed VNC sessions (iTalc or vncthumbnailviewer)
• Appendix A: Configure your Linksys router with DDNS

If you have anything else you would like to consider let me know if practically possible I'll try to include it into the book. I hope to get the book out in 2-3 months (provided I can give it one hour a day). People volunteering for proof-reading are most welcome.