that’s great…

Which OS are you?

Which OS are You?

The only thing it got right was about my cousin Wince…

I think Open Source is good, and technology helps makes life easier.

If your interested, no, I could not think of a better title.

Since the late summer of 2003, I’ve been working on a side project. It wasn’t much, simply an apartment rental application. The main features were:

• Allow a renter/seeker to search for apartments.
• Allow a manager of a complex to update apartment postings.
• Allow an administrator to update apartment postings, and update users of the system.

Well, it seemed simple enough, so I thought “why would this take more than couple of months?” Well, I was cocky, overconfident, shortsighted and most importantly, wrong.

I initially projected a demoable version of the application in six months. Yeah, that’s nice. So a year passes, and in comparison to what I had projected, I had actually only completed a fraction. Almost two years later, and I’m just finishing up. Oh yeah, and when I say finishing up, I mean finishing a drastically reduced in scope version. How reduced in scope? Very. For example, there’s no more renter/seeker version of the application. Yeah, and I also removed the manager section. I mean, who needs managers. In the end, I have a really robust Admin section.

Ok, now for something positive: I learned a ton. I started out using JBoss, and Jason C. suggests I try Resin. Not sure if it’s because of some bias, but Resin turned out to be much faster, and easier to deploy using Ant. For the persistence layer, I was using hand written JDBC DAOs to talk to my MySQL database. Jason suggested Hibernate; it was a great move. For the presentation layer, I was using Webwork/XWork, Sitemesh and DisplayTag. Since Jason is a leading member of WebWork, I didn’t hear much about “try this” or “try that” other web framework. Actually, I’ve been a WebWork user for a while, so I was pretty aware of what it could do. I was putting most of my business logic in the Actions, yeah I know: bad idea. So I decided to add a service layer, but I didn’t want to add EJBs to the mix; Jason suggests Spring. Being new to the concepts of AOP, IOC and dependency injection, the learning curve was much higher than expected. Either way, it worked out fine: I didn’t have to add EJBs, and it made deciding to add Acegi (to handle security) much easier.

In the end, the real reasons for me not completing the application include:

• Concentrating too hard on things like UI aesthetics. e.g., getting the color and size of table headers just right.
• Not having as much energy as I thought I’d have after a 40+ hr work week.
• Being one person and not being able to split my self like superman did in that one episode. This was the real killer; damn you reality!

But I’d like to ignore those, and instead blame the open-source community for making great software. Oh yeah, and Jason for suggesting I try these technologies. Damn you all to Hades. If you want see what I spent my free time on for the past 2 years, the code’s available here.

TREO 650’s and Pocket size

I was talking about the cost and size of TREO 650’s, and made the statement that these devices don’t fit in pocket’s well. TREO 650 dimensions: 4.4 x 2.3 x 0.9 inches (11.3 x 5.9 x 2.3 cm), and 6.3 oz. (178 grams).

I then went further to say that Pocket size is in direct relation to your height. I think this is a transitive property. For example, the pockets on a little person’s pants should be smaller than a person of 5′8″ in height. The 5′8″ individual’s pockets should be smaller than a 7′5″ person’s pockets.

Long story short, I was mocked for saying the stupidest thing ever. Is there anyone out there who thinks this might be true?

MIT Weblog Survey

Take the survey, it’s pretty interesting. It takes about 5 mins.

State Management with the Http Session

If you’re using a MVC web framework, such as WebWork or Struts, you might have had to store long-term state in your Http Session. At my job, since we do not use Stateful Session Beans, this is common. So, the solution in place was designed to do the following:

• Allow requests to transport state to subsequent requests without having to add each trivial (String) value as a hidden field on the view.
• In addition to the above, the non-trivial values do not work well as hidden fields.
• Discontinue the manipulation of multiple JavaBeans in the view. Depending on the complexity of the screen, and the number of beans involved this could become overly-complicated.

Moving away from the items listed above, and providing a cleaner and reusable way to transport long-term state between requests is fine. The issue I am most concerned with is the size of the Http Session. I understand that it’s mid-2005, and memory is not as large and expensive as it once was. However, this shouldn’t give developers license to just shove things into the session, and hope for the best. Here are some reasons why:

• Unused objects will sit in the Session until the session is invalidated.
• Garbage collection will never occur for the unused objects mentioned above.
• Based on the application’s complexity, this could lower performance.
• In general, you keep your session size as small as possible; Brown and Botzum say 2K is the suggested size, but I think that’s unrealistic.

IBM’s Brown and Botzum, suggest using transient for fields that will not be persisted, and having all items being added to the Http Session implement Serializable. This makes sense, but what if you are handling Hibernate objects? The transient keyword will not help much. Aside from reloading data each and every time you need it, the best option seems to use a StateBean of some sort. However, instead of just solving the basic problems of transporting long-term state, this StateBean should provide the following:

• The ability to decipher between event sensitive and insensitive state.
• The ability to set a space limit for event sensitive state.
• When new state is being bound and the space limit has been reached, remove old event sensitive state so that unnecessary heap use does not occur.

The limit of event sensitive state should be fairly small, allowing for just a handful of unrelated use-cases to occur before stale state is removed. If implemented properly, there should be at most one StateBean per Http Session. Keep in mind, if a developer wishes to place items that should be easily accessible during the entire Session, they still can.