A quick review of debugging Struts applications

I had worked on a Struts web application a couple of years ago, and within our team I am still considered the "expert" on that application. So yesterday, when something wasn't working correctly, a teammate approached me and asked for help. As I walked her through what was going on, I made it a point NOT to rely on any knowledge of the application (after all, it has been two years and several maintenance programmers since I have worked on the application.) Here's what we did:

• Based on the URL, track down the action mapping
• Look in the struts-config.xml file and find the JSP that is rendered
• Examine the JSP and see where the data is coming from; identify the form object that holds the data
• Back in struts-config.xml, find the action that does the work
• In the action, look at how the form is populated

In finding and resolving the problem, I didn't have to use any tacit knowledge of application. Instead, we just ran the application, identified the problem, and tracked it back to the code that was causing the problem.

A quick and easy way to minimize java.lang.NullPointerExceptions

In Java, we often see code that compares a particular value to some know constant. Often this is written like this:

someObject.getSomeValue().equals("SomeConstant");

This works ok, assuming that someObject is not null, and as long as you are sure that getSomeValue() will never be null.

If you aren't so sure, or if you just want to develop a good habits that will minimize the number of NullPointerExceptions you run into, you may try to write the same comparison this way:

"SomeConstant".equals(someObject.getSomeValue());

You are ensuring that you will not run into the dreaded java.lang.NullPointerException, because your constant value will never be null. And you are improving your own productivity, because you and your teammates will spend less time tracking down and fixing NullPointerExceptions.

Glimmer to ECLIPSE RubyOnRails?

When I hear about Ruby, the first thought that comes to mind is Ruby on Rails and Web 2.0 applications. I would have never made the association from Ruby to desktop application. Until now. About a year ago, it was suggested that JRuby and SWT might be a viable combination for Ruby on the desktop. After all, SWT is the performant, native desktop library available from Eclipse, and Ruby gives you many productivity advantages. There was even a SWeeTgui project at the time, though it doesn't seem like there was much traction. Fast-forward one year, and we now have Glimmer: "a JRuby DSL that enables easy and efficient authoring of user-interfaces". What advantages are there with Glimmer? Here's what I see:

• A compact api that allows Ruby developers to write native destop applications
• A clean wrapper around the SWT libraries, that takes a minimalist approach by exposing the most important features and applying smart defaults everywhere
• An API that is based on Ruby's programming paradigms, not Java's.
• The ability to implement complex SWT desktop applications with only 25% of the code.

That last point is what brought me over. Being able to write the same functionality with just a quarter of the code (and time). I've been developing Java applications for nearly a decade now, and using SWT for two years, and I feel very comfortable. .

When I first saw Glimmer, I didn't believe that I needed it for my Java SWT applications, because I know Java, and I know SWT. But as we discussed the merits of this API, and I saw a demonstration of some complicated user interfaces, I got a "glimmer" in my eye. I could see alot of productivity benefits here.

Take a look for yourself, and consider it for your next desktop project.

A REAL Onsite Customer

I'm currently working on a project that is using an agile process to manage development. We use most of the XP practices, but are mising what I would consider the most important one: an onsite customer. Though our customer is a manager, and the final decision-maker, she doesn't participate directly in the daily development activities. Instead, she sends a proxy.

This works out great about 75% of the time, but doesn't work so well the other 25%, when we need a tough question answered quickly. And that often introduces some long waiting. Here are a couple of examples.

Last Friday, the manager had her proxy call a meeting with the developers to discuss a featuer we had just completed. She wanted to improve the flow of the feature, and make sure that it was as easy as possible for the users. We got together with the proxy, brainstormed, offered ideas and estimated the different steps. He then went back to her, she had some other ideas, and some questions. So he came back to us and .....

All this going back and forth was costing precious time. We are still answering questions and going over ideas, though we never really meet with our customer. There are several problems with this approach. Information is lost, intent is misunderstood with each link in the chain, and delays are introduced. And this happens both ways. The proxy is an intelligent guy, but all the intelligence in the world doesn't help here. Its the nature of communication, similar to the game we played in grade school, where we each whispered something to the next person, and what came out of the chain is not what went in. Extra energy is expended going back and forth. It would be much more convenient, and direct, to be talking directly to the decision-maker.

Contrast this to what happened yesterday. We were discussing a feature that the developers thought must be included, but the manager thought wasn't necessary. Of course, she sent the proxy to discuss this with us. However, we didn't feel she had a strong argument, and she didn't think we had a strong argument. By chance, one of our teammates saw her walking by, and we asked her to explain her point. Then we explained our. We were quickly able to come up with some options that would meet her requirements and our own. I walked out of this meeting energized and excited about our application. We were going to deliver a valuable feature that met the needs of our users, and our developers, and we were able to get to that point very quickly.

All modern books preach the need for an onsite customer. This experience of two extremes solidified the idea in my mind. Your team can definitely work more effectively with an onsite customer. Not a proxy, nor a proxy to the proxy, but the real decision-maker, in the trenches with your team, day in and day out.