So, I have a bit of a confession here. I have recently purchased a new Mac Book Pro. It’s about 2 weeks old now and I can’t say the transition has been painless... It’s hard to migrate from working in a almost exclusive windows environment for the last 12 years (My first computer was a mac OS 7). I have to think a lot about how things work now keyboard shortcuts are different... Applications are different I sorely miss my editplus, I love that application. It is one of the few that I actually registered - and highly recommend it to anyone who does any type of file manipulation or scripting...

Anyway, I’ve been working on a super secret project that will eventually evolve into developing an application for the iPhone and to do that type of development then you have to have an Intel PC mac. It is kind of crappy - but I was in the market for a new PC anyway my previous laptop was over 4 years old (still running very well but showing a bit of age). I will say that GlassFish has never run better, and it is truly amazing how much development software it comes with out of the box. I’ve started playing with Objective-C and Cocoa just a bit and they are very cool I can totally understand why a developer would want to use the Cocoa Framework and XCode.

Anyway, I just wanted to get that off of my chest... I’m not a zealot yet - it is just a tool after all but it definitely a powerful system - and a 17“ wide screen is a beautiful thing indeed.



-Aaron

Code Nuggets

A friend just told me about a nifty little feature in commons-lang:

import org.apache.commons.lang.builder.ToStringBuilder;
import org.apache.commons.lang.builder.ToStringStyle;

public String toString(){
    return ToStringBuilder.reflectionToString(this, ToStringStyle.SIMPLE_STYLE);
}

 

What that does is spit out all the properties of your object when you call a toString on it.

 

Another little gem I have ended up using a lot is when I write test cases with spring.  When you extend the AbstractDependencyInjectionSpringContextTests object one of the methods you need to override is the protected String[] getConfigLocations() method.

Getting your spring context to load correctly is critical to getting your spring app to run and can cause a lot of head scratching and frustration here is a little trick to get it to load correctly - it is a bit hackish but in some scenarios it works well.

import java.io.File;

import org.springframework.test.AbstractDependencyInjectionSpringContextTests;

public class AbstractTestCase extends AbstractDependencyInjectionSpringContextTests {
    public final String RELATIVE_LOCATION = "src/test/resources";
    public final String FILE_NAME = "persistence_ioc.xml";
    @Override
    protected String[] getConfigLocations() {
        File aNewFile = new File("./");
        StringBuilder contextLocation =
            new StringBuilder(
                aNewFile.getAbsolutePath().substring(0,
                        (aNewFile.getAbsolutePath().length() -1)
                )
            );
        contextLocation.append(RELATIVE_LOCATION).append("/").append(FILE_NAME);
        File test = new File(contextLocation.toString());
        if (!test.exists()){
            System.out.println("!!! file doesn't exist at: " +
                    test.getAbsolutePath());
        }
        return new String[]{"File:" + contextLocation.toString()};
    }
}

Like I said a little bit hackish but effective nonetheless.

 

-Aaron

Ownership

In the enterprise Software Development Project Management thought process there is this concept that software developers are resources.  I suppose from the initial project development that is arguably true, more or less.  But what happens when the project is over; the deliverables have been delivered.  Who supports the project, who maintains the project and who enhances the project?  Basically who is the technical owner or steward?

This is an important part of the "Software Development Life Cycle" that is forgotten, at least where I work.  I recently came off of a fairly successful project where we delivered a fairly standard application - a web based front end that talked to an EJB service that depending on the request would call other "enterprise" services to perform the requested function.  Kind of like the diagram below:

 

So in the development of this project some of the extended services were already in existence, others were new development efforts.  I had the opportunity to design and implement one of the services.  My intent was for this service to be reused by another application I used to work with, not thinking I would really get the opportunity to see it get reused but I wanted the option to be there.  Well that other applications is getting re-done soon - and I would really like to see that project use the service I wrote for it.

Unfortunately the service I wrote does not really have an owner.  It is out there chugging along quietly behaving by itself so it is pretty much forgotten.  That seems to be pretty typical, when applications work well they are forgotten.  Somehow the concept of project ownership (or maybe stewardship) is a foreign concept in a lot of places.  If someone has developed a service/application they need to be responsible as the steward sure they can transition it to someone lese but applications should never be delivered and forgotten. 

So what does it mean to be a project steward? If you are a steward then you should be the most knowledgeable person on how the application should be evolved and reused.  The steward should be involved when changes are requested or if someone wants to use it.  They should also be responsible for documenting and troubleshooting it.  They don't necessarily have to have the final say in some decisions but their views should be taken seriously. 

When there isn't a steward the services don't get reused and they begin to stagnate, other people start to re-solve the problem the service was written for.  Knowledge is forgotten, documentation isn't written, basically the software dies and that is not good.  Our software creations can only live if we take care of them.  In the world of SOA this part of the equation is forgotten - for services to be maintainable and reusable they have to have someone that is looking out for them.

I think that is why so many open source projects are successful, they have people working on them that care about the project's success and have the sense of responsibility - the end result is owned by them.  Without that commitment software development is not much different from working at McDonald's - you crank out as many cheeseburgers as you can, as quickly as you can.  If some cheeseburgers get undercooked and make people sick - well it's not your fault really....  Someone else is responsible for making sure you do your job right.

We have to have ownership in everything we do - otherwise there is no reason to do anything.  When managers shuffler resources around because resource constraints - all it really does is make a lot of people sick from undercooked cheeseburgers software.

 

-Aaron