Evolutionary Goo

Being from St. Louis, I am obviously partial to our local baseball Cardinals. It was amazing to see them go through their ups and downs throughout this year’s season, to finally pull everything together and win the 2006 World Series. I got a good chuckle out the national media and it couldn’t understand how a team with only 83 victories during the regular season could beat “better” team like the Mets and the Tigers. The more that reporters made excuses, devised clever explanations or just plain whined, the more I laughed.

Watching “the band of misfits”, as some have labeled them, made me think about how baseball is sort of like making it in business. Sometimes the best laid out plan financed with millions of dollars falls flat on its back, while another other crazy idea created by some startup working out of a garage becomes the next big thing. It’s all about execution, a little luck, a lot of skill and a whole bunch of hard work. The Cardinals were fortunate enough to have all of these this year.

“Getting Real” is a great short read from the 37Signals Web software company. Yes, they are the guys that bring us Ruby on Rails and Web apps like Basecamp and Backpack. The book is pretty much a collection of short essays on how to run a small software company and develop Web software. You may not agree will everything in the book, but IMO, there’s a bunch of good stuff in here that can be used for Web development or applied to many other situations. This book is now available for free in HTML form.
Getting Real

I recently reported that I thought RollYo was a cool Web site for creating custom searches. I guess Google thougt so also, as they are now allowing the same thing. Not very good news for RollYo.

Google Co-op

I am working on a Java Web project where we use the Quartz scheduling system to schedule and run a variety of miscellaneous jobs. Using Spring’s Quartz integration this is very easy to do. We configure the jobs and schedule them using Spring XML configuration files. There is no Java code to write, except for the code in the job itself. Nice.

We did run into one problem during redeployments of our Web applications while running on a Tomcat 5.5 server. We want the ability to make scheduling changes to Quartz jobs belonging to a single Web application, redeploy that Web application and see those changes take place once the application is up and running again. What we found was that the changes did not take place until the Tomcat server was restarted. This obviously was not acceptable. Using the Java Monitoring and Management Console that ships with Java 5, we were able to see that the Quartz scheduler thread was still alive after we stopped our Web application.

We tried a number of combinations of configuration changes to the Spring Quartz schedule factory bean, including the “destroy-method” attribute and “waitForJobsToCompleteOnShutdown” property, with no success. What did work for us was to add code to our Web application servlet’s “destroy” method. This code retrieved the Quartz scheduler from the Spring context and then called the “shutdown” method on the scheduler. It worked like a charm. The downside to this fix was that we had to write some servlet code. However, it was minimal. Not much of a price to pay in order to not have to write our own scheduling system.

Ever wonder what was the name and artist of a great song playing on the radio. Of course you have. Well, wonder no more. Yes.com has all the answers for you. Besides having a great URL that really doesn’t describe what their site is about, Yes.com is able to tell you every song that has payed on a particular radio station for the past seven days. You can search by song name, artist or radio call letters. Once you find what you are looking for, there are links into Amazom and iTunes. Very cool indeed.

It is Blog About 5 Things Week at the Instigator Blog. A previous list posted on this site last month has been included on the blog - Five Way To Indentify Increasing Software Complexity.

Martin Fowler has good blog post this week on the imposition of agile methods on a development team. I know of large companies doing this, so I find this post particularly interesting.

From Martin’s post… “An important consequence of these values and principles is that a team should choose its own process - one that suits the people and context in which they work. Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.”

I understand where he is coming from and tend to agree. However, large companies have always been about choosing standards and then imposing the standards once they have been determined. Can or will the adoption of agile processes inside large enterprises be done in any other way? I doubt it. Any opinions out there?

Scheduled to do a Java code review for one of your teammates? Grab a copy of FindBugs and analyze her/his code beforehand. You will be the hit of the code review, however, your teammate will definitely not be buying you a beer after work.

Actually, FindBugs is very useful and finds all sorts of things that could cause you problems that you may not have even known were issues. You may not care about all of the bugs it finds, but every now and then you will find one and say “oooh, that is bad”. Best of all, FindBugs is easy to setup and to run.

What are you waiting for? That code review is scheduled to start in 15 minutes.