NFJS COSS 2008 1st Day Wrap Up

It is the morning after the first day of the No Fluff Just Stuff Central Ohio Software Symposium 2008 and I am writing this blog at 6:05 am because I am still so mentally stimulated I could not sleep at all last night so I gave up trying. I hope it does not catch up with me during today's sessions.

I really enjoyed Jared Richardson's, author of Ship It! A Pratical Guide to Successful Software Projects, keynote called Career 2.0. He announced he was writing a book of the same name that he expects to finish in January. In his keynote, he encouraged us to take control of our careers by improving our visibility in the industry. Some of his suggestions for getting started were writing, speaking and contributing to open source. He recommended setting goals but starting with simple steps like writing a blog, giving lunch and learns in your office or contributing documentation to your favorite open source project or maybe one you want to learn more about.

I have to agree with Jared completely. During my exit interview from college with my advisor, I was asked what I wanted to do with my career. I told her I don't know. But I did know there were two things I did not want to do. I did not want to write and I did not want to teach. 12 years, 4 books, several articals, numerous technical classses, many conferences and COJUG presentations I can say that was a very narrow minded view. I have found those are two of my favorite things to do and doing them have opened so many doors including free trips to Europe. I also discovered that contributing and observing open sources has really improved my disipline as a developer. It has allowed me to be exposed to more projects and practices then I could even be exposed to in my consulting practice. It allows me to see more of what works and what doesn't.

I also attended Scott Davis's, author of Groovy Recipes, Blue Pill and Red Pill presentations I had heard so much about from Java One. I was not dissappointed. I think it was a great introduction to Groovy for Java developers.

Validate legacy databases with Grails

By default Grails assume you are creating a new database schema from scratch. But one of its strengths is it's ease of mapping to existing database tables. However when you map to existing tables you must be careful. By default the DataSource.groovy file, is configured to create-drop tables so it is easy to inadvertently wipe out data and tables. In addition switching to the less disruptive option of update may not be safe either. See GORM objects by default have an id and version attribute that are injected by GORM. When GORM gets initialized it will add id and version columns to your database which you may not want or expect. So the best option may be to use the validate option which is not documented in the Grails user guide. On start up it will validate the tables have the columns that your domain classes expect and if not fail to start.

By the way, to turn off the version column you will need to set version to false in the domain class mappings. To prevent the id column from being created, you will need to map id to the primary key column of your table.

Eclipse 3.4 (Ganymede) is more friendly to Maven Users

Last week I started using Eclipse 3.4 (Ganymede). There are a ton of new subtle enhancements along with the new major features. One of the subtle features I immediately appreciated was not even in the Workbench or Java Development User Guide’s What’s new documentation. It is a minor enhancement to the Classpath Variables which makes working with a local Maven repository so much easier.

Let me start of by explaining what Eclipse Classpath Variables are. As you probably already know, fully qualified paths in code or configurations are a sign of a code smell. It often leads to comments like “It works on my machine”. In Eclipse projects, this commonly happens in adding Libraries to the classpath. Many developers use the Project > Properties > Java Build Path > Libraries and press the Add External Jars button to add jars. This causes a fully qualified path to the jar to be put in the Eclipse .classpath file. If other developers on the team do not have the exact same path, sharing the .classpath file via version control does not work. So I have seen many teams choose to not version control the file to get around the problem. Unfortunately that is not the answer because it takes longer to set up new developers and also leads to “It compiles and runs on my machine” since everybody is using a different library configuration. Another problem that often happens is one developer adds a new library dependency and other team members start getting ClassNotFoundExceptions or code from version control no longer compiles because they didn’t know a new jar dependency was added.

Classpath Variables can solve this by configuring a variable starting point in the classpath and then using the Add Variable button on the Libraries tab of Java Build Properties rather than the Add External Library button, jars can be added in a much more flexible way. As a mater of fact, just two weeks ago when I presented my 10 Eclipse Productivity Tips at COJUG somebody said we had that problem on my last project so we stopped checking in that file because one person didn’t want to conform. After the presentation she realized Classpath Variables could have solved that.

For Maven users a Classpath Variable of M2_REPO is often used and configured to the top of their local Maven repository. Unfortunately, maven repositories can often get very deep and may contain multiple copies of the same or similar jars in different locations. So, navigating the directory structure to add many dependencies can be very time consuming. This is where the new Classpath Variable feature comes in. A new filename filter was added making it easier to see all the jars at once or farther narrowing can be done.

Free Groovy and Grails training and copy of Beginning Groovy and Grails

On March 10th, I made the offer to provide free 1 1/2 hours of Groovy and Grails training to any companies in the Central Ohio area. This offer has been very popular. With the recent publication of my book Beginning Groovy and Grails, I want re-offer this opportunity and sweeten the deal by providing one free copy of Beginning Groovy and Grails to any companies receiving the training. The training defines Groovy and Grails and demonstrates their capabilities with a live coding demo including some AJAX examples. If you are interested in learning more about taking advantage of this offer, please email me at groovy@juddsolutions.com.

Eclipse ${project_loc} errors during Grails development

In your Grails development with Eclipse, if you have ever used the Run Launch configuration provided by Grails or followed Add domain classes etc. instructions on the Grails Eclipse IDE Integration wiki page, you may have received the Eclipse error message “Variable references empty selection: ${project_loc}”.

This is caused by the fact that certain actions can cause Eclipse to loose focus of the current project. To resolve the issue, simply select your current project in the Package Explorer or Navigator and repeat task that caused the error. This can get annoying so another alternative is to replace ${project_loc} with ${workspace_loc}\project_name if your project in your workspace directory.