Vita Rara: A Life Uncommon

Quadran

2007: A Retrospective


Categories: | | | | |

Personal Life

Sylva and I got married on April 28. It's been a real whirl wind since then. We are expecting our first child on April 1, 2008. My time with Sylva is special and precious. I have a great partner, and look forward to raising a family together.

Overall business issues have dominated this year. I doubt that will be that case next year.

Business

It was a hard business year, but prospects for the future look good.

Quadran

Quadran has arrived. About 63,000 lines of Groovy, Java and JSP, with some XML files to wire it all together, and it's up and running. We turned on our first Quadran installation on December 5, 2007. This was the culmination of a process that began with an initial meeting in September of 2004, and the consummation of the development agreement in July of 2006.

Quadran: Shakedown Run


Categories: | |

Today is the first day we have our client's complete staff using Quadran. It's a good feeling. This is a day years in the making. We had our first meeting about this project in the fourth quarter of 2004. That's a long time ago. We started the actual project in July of 2006. Today we have everyone in the business running on Quadran, and using their old system in parallel. There are issues, but nothing fundamental, no burning houses, or staff jumping off the ship. Overall it has been a calm deliberate test.

We have created more automated test cases for this project that any other project I have ever worked on. In the early going I opted for Struts 2, POJO service beans, and JPA, because they were testable. I think this has paid off pretty well, because it's quiet here. I'm not hearing screaming and gnashing of teeth. We'll see what the rest of the day brings.

Replacement Systems are Really Hard


Categories: | |

Create a list of the hardest things to accomplish in software development and I'm sure near, if not at the top of the list, will be replacing an existing system. Especially a system that runs the lion's share of a business' operations. Especially when you can't look at the source of the system you're replacing.

For the past year I've been working on my Quadran project. Quadran is a drop in replacement for a system my client has been using for about five years. Completing Quadran has been just about the hardest things I've ever done. It has felt like an IT death march.

Quadran Update


Categories: | |

We're in the final push to getting our first release of Quadran out the door. We' implemented a lot of functionality over the past two weeks. The data model has grown and morphed as time has gone on. We look to have a running system up within two weeks.

As I mentioned in another post we're starting to use Scrum to manage our software projects. The transition with Quadran has been interesting. Quadran is a fork lift replacement of an existing system that runs our client's complete operation. About the only thing that isn't in Quadran is invoicing and receivables. This makes the conversion to Scrum a little hard, because we're so close to finishing the first release. And we can't deploy the new system until it does everything else the old system does. (The old system took five man years to develop in the bad old days of EJB 1.1.)

Groovy GPath: That WOW Moment


Categories: |

I'm writing a lot of integration tests for Quadran. I just wrote one where I needed to traverse a a complicated series of relationships, including collective relationships, through my domain model to test that a collection was initialized by Hibernate JPA. Here's the code:

Integration Testing Struts 2, Spring, and Hibernate JPA


Categories: | | | |

Last night with the help of loraxorg on the Spring Forums I got integration testing working under Maven 2 with Struts 2, Spring, and Hibernate JPA working. This was failing priorly due to a transient dependency in Maven 2 to an old version of Xerces. (See the Spring Forum thread for the solution.)

I have not done a lot of test driven development in the past, and personally I don't really get a lot of value out of isolated Unit tests. Integration testing on the other hand I like. Real data, real connections, real functionality, and at the moment for me real failures. I'd rather know now though.

Getting a Transactional EntityManager in a JpaDaoSupport Derived DAO


Categories: | |

In Quadran my Data Access Objects (DAO) are descendants of JpaDaoSupport. JpaDaoSupport provides nice one liner convenience methods for finding entities and such. Sometimes though I find I need to actually get a handle to a JPA EntityManager. If you do this, and you are using Spring's transaction support it is important that you get the EntityManager in the proper way. Otherwise you will get an EntityManager that is not bound to the transaction, and will not be closed when your transaction completes and commit its changes, or close the session.

When I first tried getting an EntityManager I used the following code:

Gettin' Groovy With It


Categories: | | |

Well, this week after hearing about Groovy and reading a bit about it I decided to take the plunge. I've grown tired of the get's and set's in Java code. It's all boiler plate repetitive, non-expressive junk. I've been listening to the Java Posse for quite some time, and all the talk about language level support of properties got to me. I checked out the Grooy Beans page and was sold.

As a proof of concept I started out writing some integration tests first. I used that as the test bed to get Groovy working with Maven. (I'll write more about that later.) Once I had that done I converted a Struts 2 Action that employed an Action class, a Model and a Query bean (to store the users input) into a single clear concise Groovy class. Three classes became one, rose in readability and it was quick. My Action, Model and Query class had a total of about 40 setters and getters. They're all gone now.

Web Page Data Models: Where do they go?


Categories: | |

You have a web page that has tabular data that doesn't represent simple rows from a database. It's a field from this table, one from that, one from four joins away. It's a little bit of data from all over your data model, but the client wants it on the screen. What do you do?

In the past I used to just a SQL result set and turn it into a Collection. Nice and neat. Iterate over the collection and put the stuff onto the screen. Simple enough, back then. Now I'd like to have better control over my models, and have them be full classes, with strong typing, setters and getters, etc.

The question is where should that class reside? Is it part of the data model? Is it a business object? It's really a presentation model. It only exists to make presentation of data easier. In essence it's like a report, or an element of a report. So, where should it live?

Maven Jetty Plugin Logging


Categories: | | |

I've gotten Maven, Jetty, Spring, and JPA playing well together! I've ecstatic. Bye, bye JBoss. I don't know that I'll never run JBoss for development again, but I don't think it will be common.

Anyway, upon getting the Jetty Maven Plugin working (mvn jetty:run) it was logging too much debug information. Hitting one page ran out a 10,000 line buffer on my terminal. There was a simple quick fix though. Add a few properties to the plugin configuration in your POM file and voila, reasonable logging.

Syndicate content