Matt's Spring Live book convinced me to give SiteMesh a try and move away from Tiles. So I have been using SiteMesh for a couple of weeks now, but I haven't really had to change the configuration until today. Today I wanted to use a different decorator than the default decorator and I had a rough time. I had a couple of different pages to help me out: Will Iverson's Intro Tutorial to SiteMesh, Rick Reumann's Strut'in SiteMesh Tutorial and of course the SiteMesh home page.
One of the points that got me confused was Will Iverson's tutorial talking about the default order that decorators will be applied. It is only the default if you have it setup that way in the sitemesh.xml file (IE you are using the sitemesh.xml that comes with sitemesh-blank.war). Once I figured out that the sitemesh.xml had to be altered, I still didn't know that order mattered. I feel like a dunce because it took me over two hours to figure out how to get a new decorator to work.
My team had a lengthy discussion about how we (as individuals) design applications. The smartest guy on the team likes to build applications from the middle/business layer and then move out in both directions (to the view and persistence layers). I personally like to start at the view get enough of it done (this sometimes involves just a flow diagram, but can often lead to actual screen mockups as well) to understand what needs to happen in the business layer, skip back to the persistence layer and then start working my way to the middle. The humorous part is that I think we all do it the same way, the difference is in how we figure out what the middle is supposed to do.
We have all had our bouts with Space Shuttle Projects and from time to time I think our little application is teetering on the edge of becoming one, but our team is smart and our deadline is near so that keeps us away from overdoing it.
Cris' has great description of Continuous Intergration and the tools you need to do it right. CI seems to always be the forgotten peice of the CM puzzle.
I worked for Booz Allen Hamilton a couple of years ago. They are truely one of the greatest companies to work for. One of the things that really attracted me to the company was that they were known to be thought leaders. They hired the best and provided the best advice to their customers. Unfortunately they got caught by the tech bubble and couldn't figure out how to stay in the same position.
They couldn't figure out how to find the "great brains" of technology. In the past it was easy, go to the top Ivy League schools and you hire the top in the class. That works well in the business world where much of the product is based on relationships and advice. In this new technology world, there are real deliveries that don't depend on a certain education or knowing certain people. It depends on imagination, logic, ingenuity, hardwork, courage and building a good team. I bet if you look at B-school documentation, you will find 4 of those in there, but they lack the emphasis on imagination. This job takes 35% imagination, 35% logic, 20% skill, 10% hardwork. Humorously, logic and imagination are rarely found together in one person, which is what makes developers so valuable.
Today, to find the good developers that are also good consultants, you have to find out if they have the ability to communicate effectively, if they have the ability to write code, are they crafty enough to do it in an effective (meaning repeatable and maintainable) manner and if they have the ability to learn new things rapidly. Companies are no longer able to go to one source to find the talent that they need. They actually have to search long and hard to find what they need.
Why does insomnia always come the night before a big meeting? I am dead tired, but I can't get to sleep. Ugh, time for another hour of toss, turn, repeat.
I would like to take credit for the new Contacts feature in Gmail, but I doubt I was the only one to ask for it. My favorite fat email client, Opera, has the ability to easily see the emails that were sent to you by people in your contact list, it also shows what you sent to them. Gmail now has that capability. I am very excited about this as it is one of the things that I like most about Opera.
Gmail just gets better and better!!
As I have said many times before, Hibernate is not my favorite persistence framework. But we decided to use Hibernate at work because my opinion was pretty biased and there were books available for Hibernate.
So, I have been using Hibernate for the last two weeks and I have decided that I still don't like it. There are tools that allow you to generate your POJO's, but they don't create your DAO's. There are tools that will create your tables for you, but how often do you need to do that? This is actually one of the areas where Jaxor is lacking. The problem isn't that Jaxor can not create your tables for you, because it currently creates tables in HSQLDB for unit testing, the problem is that Jaxor doesn't do this in a production like way.
Jaxor also doesn't have a default way of setting the primary key. There is a suggested way that is covered in the questions, but Jaxor doesn't come with that built in.
Even though Jaxor doesn't have all of these things, Hibernate does not have DAO's. Granted, the DAO's are made up of one or two line methods (if you are using Spring) but I still have to write them and the service layer. After I generate my domain layer with Jaxor, all I have to provide is the service layer. For a while I thought that I was doing this incorrectly because I didn't have as many layers as the properly architected applications, but I am actually doing it right. Jaxor just provides so much more functionality that I only have to focus on what parts need to be glued together to make the business work. I am pretty sure that means Jaxor is a better product.
Because I thought I wasn't architecting the system properly, I was reluctant to push Jaxor as hard as I could. I gave in pretty easy and now I am starting to think that was a mistake. My team is not going to like me all that much on Monday if I decide we should switch, but I am starting to think we should. I want to do some testing to find out how Jaxor and Spring interact, but I have a feeling that after this weekend, we will be using Jaxor instead of Hibernate.