Monday, May 12, 2008

BarCampKC - 2008

A couple of friends from the Omaha Dynamic Language User Group and I went to Kansas City for our first BarCampKC experience. Not surprisingly, the conversations in the bar on Friday night and in the hallway on Saturday we at least as interesting as the presentations themselves. And that is high praise, as I really enjoyed the presentations on Radiant Content Management System, real world application of Google Maps, and Situated Web Applications.

A majority of the attendees were Rails users so it was good for me to be out of my normal programming ecosystem. Most of the people I know who use Ruby are language junkies so it was very interesting to broaden my horizons. I did get to present "Introduction to Groovy" and that was well received. Some of the attendees work with Java on a part time basis and I think they saw value in using Groovy on a Java project.

We also had a nice discussion about the value Groovy brings to business applications in using BigDecimal by default for float pointing values. Rexx is the only other language I've used that provides this feature. It may not help with performance in micro-benchmarks but if you have to work with business entities in domains such as banking, finance, insurance or anything that deals with money like shopping carts, its really nice to know the numbers will add up as expected when your language offers BigDecimal by default.

The folks in Kansas City were very gracious to us and I look forward to interacting with them in the future.

Monday, May 5, 2008

Preparing for my first BarCamp in Kansas City

I've heard about BarCamps but never have attended one. I'm really looking forward to going to Kansas City for BarCampKC .  One of the rules of BarCamp is that you blog about it :) 

 I will be offering to do two sessions, "Introduction to Groovy" and "Real World Groovy", which is a presentation that summarizes my experiences working on an insurance rate calculation engine that was part of large J2EE project. I always enjoy meeting other developers who are passionate about their craft and I'm sure this will be a memorable weekend.

Sunday, April 6, 2008

Update on the Omaha Java User Group Meeting Info

Today I had the pleasure of presenting on Groovy at the Omaha tour stop for No Fluff Just Stuff. It's always fun to attend these events. The hallway conversations with the attendees are always as interesting as the presentation topics.

During lunch on Sunday, I talked briefly about the Omaha Java User Group and the Omaha Dynamic Languages User Group. Someone pointed out that I was gave out conflicting information about my upcoming presentation at the next OJUG meeting. I apologize for this confusion.

The next OJUG will be on April 15th at Gallup. Food will be at 5:30pm and the presentations will start 6:30pm.  I will be talking about Eclipse Plugin development. In particular, I will show how I created a plugin to make my own life easier by adding some simple menu options and editors over Ant tasks and configuration files I frequently use.

Friday, March 28, 2008

My path to the Spring Framework "Aha" Moment

Many people see unit tests as a good way to get started with Groovy. Tests are quick and easy with Groovy. But for me, Groovy is just the beginning. Using Spring is what really makes it easy to keep driving down the test driven road.


There's been a lot written about dependency injection the past few years. I know many people look at dependency injection with confusion or frustration when they first hear people talk about it. They struggle to see what value it brings. Many people it just adds a layer of complexity without bringing any benefit to a project. I was in the same boat until I tried to write tests for all of my code.

I think a key architectural decision for writing testable code is using factories for object creation. I used to work on a web application where all database access was only allowed via SQL stored procedures. Not surprisingly, problems arose when the SQL stored procedure person would change the inputs or outputs and the Java programmers wouldn't find out about the change until someone trying running the application and something broke. This was the start of my journey to my Spring "aha" moment.

Step 0 - Testing from the App

At first, development and testing of Java services that invoked these stored procedures was done by writing the Java code, fire up the web app server, and navigate the screens until you hit the code under test.


Step 1 - Test with a Custom Servlet

Navigating those screens was painful. So someone created a test servlet that would allow developers to execute the code being developed without navigating all of the screens. This improved development but wasn't something was used for testing beyond initial development or bug fixing. Attempt were made to automate servlets using Cactus, but the setting up the test environment at the time was challenging.


Step 2 - Test with a Local Database Connection

The next improvement made was to add a method that could create a local database connection or get a pooled connection from the web container based on a property file setting. The default behavior was to use a container managed connection unless the "test" property was set. This really made difference in development speed. It completely removed the need to fire up the app server during development.


Step 3 - Move Connection Management to a Factory Class

Duplicating this database connection method across all of the Java database service classes wasn't attractive, so a database connection factory class was created that was responsible for the local or container-managed object creation logic. This was really valuable. There was one place to control all access to all database connections. When troubleshooting connection management problems, it was really easy to write a dynamic proxy for JDBC connection objects that logged when connections when connections were opened and closed.


Step 4 - Creating Other Factory Classes

Having experienced the value using a factory. I found myself in other areas of my application, such as security.


Step 5 - Spring "Aha"

After creating my third factory class with boilerplate code, I realized that it would really nice to have a consistent way to deal with creating and configuring all of my factories. "Aha" - Spring removes the burden of writing all of those factory classes. It provides a framework for creating different configurations for test and production. It also provides an easy way to inject code via Spring AOP across unrelated objects (cross-cutting concerns). I started using Spring and really liked the way it cleaned up my code. I liked removing the factory classes from my code base. I like removing all of the calls to the factory from the application code. Everything just felt cleaner.


Now, when I start writing a new application, the first thing I reach for is Spring. It provides the framework for writing testable code so that it will easily run outside of app container. This is important for easily running all of my unit tests from Ant - which for me is Step 0 in agile development.


Thursday, March 27, 2008

Using Groovy to Unleash Enterprise Resources

Over the last three years, I have been fortunate to use Groovy as part of a large J2EE application at a Fortune 500 insurance company. One of the interesting things I witnessed with regards to Groovy is that it really lowers the barrier for entry on Java projects - especially for people who have lots of experience programming in non-Java technologies such as FoxPro, VB, Cobol, and SQL stored procedures.

I have about 20 years of programming experience and have been using Java since 1998. The team I have been leading had a mix of the various skills listed above and the Java experience, if it exists at all, has been mostly classroom work. This team performed exceptionally well delivering a complex component with well over 90% code coverage with unit tests. We also built an extensive component regression test framework that took advantage of historical data. As new developers came on to the project, I spent the first week or so showing them Ant, JUnit and Groovy. Within 30 days, they began to contribute to the project and deliver non-trivial code. I have been in similiar situations before and have never seen programmers new to Java productively contribute to a project that quickly. It's usually more like six to 12 months before I've seen similiar productivity.

It is unfortunate that developers with 5, 10, sometimes 20 years experience in a business domain are often unable to particpate in projects that require expertise in newer programming technologies like Java. Technical expertise is very important and I know my long history with Java helped my team navigate the Groovy waters. However, large companies build custom software because they want systems that reflects their unique view of their business. I believe this kind of domain knowledge is invaluable to the success of an enterprise's projects. A corporation's experienced programmers are invaluable resources. They already have the experience using technology to build systems that reflects thier company's way of viewing their business.

Although no one person is indispensible on a project, developers are not interchangable like hammers or screwdrivers. Programmers make decisions, big and small, every day that impact a project's success. The quality of those decisions is affected by their understanding of both the technical and business context they are working in. Developers who have worked for a company for many years usually have a rich understanding their company's business. With Groovy in the corporate toolbox, I believe there is a wealth of expertise ready to be unleashed.