Endorphins and Groovy
I just got done pushing myself on the treadmill and going through my max check list of stretching. My flexibility has just improved in three sessions, very impressive! Even though I pushed myself on the treadmill, I definitely feel that it was worth it. It feels so nice to have hot blood coursing through my muscles. Definitely a nice workout after a productive day at work.
I definitely feel like things are changing, and for the better. I feel like my feet are on rock solid ground so I can push off and fly, before I was definitely on solid ground, but there was the occasional pebble or piece of grit tripping me up. And I have to thank an old friend for contacting me out of the blue after about 7 years for giving me this new emotional foundation 
Today I was finally able to get maven to behave with eclipse and groovy, so I’ve started wor on a groovy project at work, sadly I’ve run into some issues:
- The groovy eclipse plugin (at least the latest stable release) has some bugs with auto completion of annotations and static imports. It also puts imports at the top of a file *before* the package line if the top lines are taken up by a comment.
- Both groovy code execution and the groovy console are slow to startup, even compared to maven. I’m probably going to try the development version to see if some of these things are fixed.
All and all, groovy seems to be a very nice language, especially with regards to java integration. Some of the features seem a bit dangerous (akin to ruby or perl) rather than the more constrained python philosophy. If you don’t already know, I’m an avid pythonista.
Ironically, or sadly, the issues I deal with from my tools are minor compared to some other issues. For instance looking through some of the code at work I notice strange mistakes, like variables that are arguments to methods that aren’t used anywhere, or methods that don’t do anything through-out a class hierarchy. Never mind the abysmal block comments or lack of test coverage 
I fixed maven by running it from the command line.
I also installed a coverage plugin for eclipse based on EMMA. I haven’t gotten it to work with groovy or groovy tests yet, but that should be relatively easy, since groovy files get compiled to bytecode and are executed as java applications in eclipse. One thing about the code coverage tool I dislike is that it wont tell me *which* unit tests cover specific pieces. I guess I expect that functionality after using figleaf.