Senior Consultant, Object Partners, Inc.
A Senior Consultant with Object Partners, Inc., Scott Hickey, has been developing software for over 20 years and working with Java since 1998. He was the lead developer for the Groovy Eclipse Plugin and has authored several Groovy related articles.Presentations by Scott Hickey
Real World Groovy
Now that Groovy has arrived, you are considering Groovy for your next project. You search the web for more information only to get conflicting or incomplete information. It's hard to distinguish FUD from fact. In this session, we go beyond the theoretical and discuss everything you want to know about using Java in a real world corporate Java project. This presentation is based upon three years of actual experience using Groovy as part of a large J2EE project at a Fortune 500 Insurance company.Real World Groovy
Now that Groovy 1.0 has arrived, you are considering Groovy for your next project. You search the web for more information only to get conflicting or incomplete information. It's hard to distinguish FUD from fact. In this session, we go beyond the theoretical and discuss everything you want to know about using Java in a real world corporate Java project. This presentation is based upon three years of actual experience using Groovy as part of a large J2EE project at a Fortune 500 company.The Groovy Eclipse Plugin
In this presentation, we will look at how you can begin using Groovy inside of Eclipse. Project setup, mixing Groovy and Java, and debugging will be covered. The presentation will also feature tips and tricks from real-world project development using the Groovy Eclipse plugin.def groovy
Monday, April 7, 2008
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.
Tuesday, April 1, 2008
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.
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.
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.
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.
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
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.
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.
