“Groovy now ranks 31 on the list of top programming languages, according to Davis and data from the TIOBE Software BV. Groovy had cracked the top 100 six months ago, moving from 103 to 52, and jumped to its current position in a January poll.“

It is fantastic to see Groovy getting some real positive attention I can only hope that will spur people to more work on the Groovy Eclipse plugin.

Domain-Driven Design: Tackling Complexity in the Heart of Software

I love this book and return to it once a year at least. This book brought into focus for me the power and expressiveness that a healthy domain model can add to an application. I know a lot of people don’t buy into the idea of domain objects having both data and behavior and prefer an anemic domain model but those people are crazy. This books gives fantastic tactics and strategies for building a domain model including topics such as tips for those times when your project has to share a domain model with another project. The downside of this book is that is it written in a more academic style and is a bit hard to read in spots.

Integrating Agile Development in the Real World

I’d actually picked up this book on a pure whim but loved it. It gives a fantastic introduction to numerous agile methodologies and how to fit them into a project developing real applications. It is a guide to implementing the theories of agile development in a meaningful way. The book does a really good job of providing examples and explaining the “why” behind various agile behaviors. A big plus to this book is that it is a really easy read.

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

While this book has “Introduction” in the title it is a bit more advanced than that. The writing style wasn’t really my bag but the content is extremely useful. I’ve referenced this book when a more junior developer is looking to get a more solid grounding in OOP and a taste of Agile development.

The Pragmatic Programmer: From Journeyman to Master

This one being on the list is a bit of a no-brainer. It is a fantastically easy read since each of the chapters are pretty small and well-focused. The book as a whole isn’t that long either. This book wanders around a bit covering topics from learning to use an editor really well to software design issues.
Agile Software Development: The Cooperative Game

Okay, this book is a fantastic look at communication and software development methodologies but it isn’t an easy read. Alistair Cockburn really goes into detail about the data and theories he used when forming the Crystal methodologies but the same applies to general Agile development. If you have the time to work through this book you’ll have learned a great amount about the “whys” of Agile development.

Looking back I apparently like books with colons and sub-titles. I know these aren’t just one book but considering how many I read a year narrowing it down to five is pretty good.

On the plus side I’m looking forward to the new JBoss Seam, Second Edition. I won’t mention that a friend of mine, Jacob Orshalick is a co-author on the book too.

Now you may be wondering why I would so glibly throw out the U-bomb about both Fit and FitNess. Surely some value must have been found with either of the tools. Nope. Nothing but a huge sink of developer time looking into them. Before I start getting assaulted with comments and email about how Fit and/or FitNess worked great for you (or so help me the Fit and/or FitNess folks themselves) hear me out. I am sure that a lot of smart people put serious time into both projects and I really don’t want to take that away from them. Take this whole post as intended: constructive criticism. And ranting. So in no particular order….

Documentation
Documentation from the Fit project was laughable at best. It was so poor it made the Hibernate JavaDocs look like Shakespeare in comparison. The FitNess folks had their act together in this aspect. At least you could learn something from their website. But I think both groups suffer from the “we-got-a-book-to-sell” syndrome where they have no reason to provide good documentation because they want to you to shell out currency for their dead trees. In my book that’s shameful and unethical. Modern open-source projects should take a page out of Spring’s website and reference manual as an example of what they should be putting out.

Examples
So since the documentation wasn’t too much help surely the time and effort was spent on coming up with reasonable examples. Nope. The examples given were trivial and so far removed from what a real world project would need a tool like Fit and FitNess for. They were good for a laugh though. So I suppose that’s a plus. I mean of course I’d want to turn over test of a simple payroll calculations to users. I really think I could come up with an intent revealing test for multiplication without having to involve HTML tables or a wiki.

Examples with both projects should involve something that typical developers would understand and be “meaty” enough to address some serious development needs. Maybe a set of examples for a blog, forum, or wiki where multiple domain objects and services have to interact to get work done.

Source Code
Attempting to “Use the Source, Luke!” I downloaded Fit’s 1.1 source code bundle. I figured that having Ward Cunningham involved then surely I’d learn something by reading the source. And I did! I learned that you don’t have to comment anything. Anything at all. And that having classes with multiple, unrelated responsibilities is what all the cool kids are doing. Multiple overrides of the intent revealing names such as “at”, “mark”, and “check”. Lastly, we should simply throw away any of the visibility modifiers except public. Honestly it made me want to gouge out my eyes with red-hot branding irons. I didn’t have the heart to look at the FitNess source code. I can only hope it was better.

It doesn’t look like any serious work has been done on Fit since 2005 - early 2006 from what I can tell. To me that spells “dead project”. I don’t know for sure but the whole Fit project seems like something that someone once cared about but has since let go to seed. Sad really since I think a testing tool like it would be very helpful to a lot of developers and project teams.

On the plus side a friend of mine, Jacob Orshalick, sent me a link for Concordion which I’ll have to take a serious look at and report back on.

I often tell people that they (“they” is me too) don’t really know anything until they’ve had to work around the “asshole” of X. X can be a language, framework, library, application, etc. etc. “Asshole” is the nasty, ugly parts of X. Like real assholes no one wants to admit they have one but we all know that we all do. For example, you don’t know anything about Hibernate until you’ve had the “pleasure” of trying to map some seriously jacked up natural keys in a legacy schema. You can read all the Hibernate related books that you want but you are still a joke until you’ve worked around Hibernate’s ugly nasty parts.

In the interest of full disclosure I will admit that I read 2 to 3 development-related books a month. But unlike those people I’m ranting against here I see the information I get from a book as just a single starting point to help frame actual honest learning that will happen after I’m done with the book. For example, I have read 3 different books on Perl but do I know Perl? NO! I’m familiar with some of the concepts in the language and could probably understand a large amount of Perl scripts if I were to read them. Does Perl appear on my resume? No. Would I attempt to lead a Perl-based project? No. Why? Because I am still a Perl noob that only has a high level, weak understanding of the language. I haven’t seen Perl’s ugly bits.

So why do you read a book?

Each of these tools is a little bit different and I’m not trying to review them per se. This is more of an introduction for those that might not be familiar with some of the options out there. Now I know that some other nameless IDEs have had plugin management built in for a while (I’m looking at you IntelliJ IDEA) but Eclipse has not.

EasyEclipse

EasyEclipse is a distribution of Eclipse like Ubuntu is to Linux. They have different packages of open-source plugins targeted to specific development needs. For example, they have Desktop Java, Server Java, and Mobile Java distributions. I’ve used various EasyEclipse distributions in the past and I’ve found them easy to install and rock solid. I suppose the only thing I don’t care for is that lately they don’t seem to be keeping up with the latest versions of Eclipse or the bundled plugins. But if you’re don’t care about being on the latest greatest then that might not matter to you.

Pulse

Pulse is what I’ve been playing around with recently. It is a service that allows you to create profiles of Eclipse add-ons and have them downloaded automagically to your machine. When you have to move to another machine you simply install the Pulse software, login, choose a previously created profile and let it setup Eclipse with all your selected add-ons ready to go. I like that it is easy, very quick to get going, and has a fantastic interface (including a “Pulse Explorer” within Eclipse itself). The downside is that it is a new service in beta and there are a few annoying gotchas (i.e. currently you can’t switch workspaces without shutting down Eclipse and selecting another workspace). The repository is a bit on the small side but the developer Genuitec looks like they’re really working to expand the add-ons selection.

Yoxos

Yoxos is a Eclipse add-on distribution service that is a plugin to Eclipse. You really have to try their Yoxos On Demand to see an amazing web demo. Yoxos uses its web interface as the starting point (as opposed to Pulse’s executable) but after that you interact with the Yoxos interface within Eclipse itself. The plugin selection they have is easily the best and most wide ranging of the ones mentioned here.

I do wish that any of these services would allow me to upload my own Eclipse preferences files and attach them to my account so that they could follow me around too. (hint, hint, big money to be made here)

Over the long haul I think Pulse is going to have the biggest impact. I’m not saying the other guys don’t have their place but seeing how well Genuitec’s MyEclipse has been managed these folks know what they’re doing. I do wonder how they plan on making any money off of Pulse without charging people to use it.

My Dad’s dad was a blue-collar, regular joe who worked as a boilermaker for more years than I’ve been alive. He also grew up in a very large, very poor family in Louisiana during the 1920’s and 30’s. He was very much a no nonsense kind of guy. As I grew up he would often say comments or sayings that on the surface seemed pretty basic and simple but as you thought about them you started to see how complex and deep they really were. I also noticed that the sayings would be more clever the more cans of beer that were missing from his case. Anyway, one of my favorites was “Son, if you want to move a train, you back up the engine to it…and pull.” Yeah, no kidding. Thanks grandpa.

The heart (and the clever part) of that saying is what is missing from Martin Fowler’s entry. Go ahead and take into account all of the things he lists on the page but also add in the costs of overcoming the peopleware issues of trying to pull your organization in a new direction. There are a lot of developers out there that aren’t very skilled. These poor lost souls barely understand idiomatic Java after years of working on Java-related projects. You are not going to move an organization of these folks by throwing down the gauntlet and simply willing them to move. You are going to have to take the active roll of backing up your engine to pull their massive weight.

Groovy is a nice way to get Java developers - skilled or not - exposed to some of the ideas and idioms that scripting languages bring to the table without leaving the safety of Java (the language). It isn’t an all or nothing deal with Groovy like it is with Ruby/JRuby. You can take your time acclimating developers to the new world instead of simply throwing them into the deep end and hope they swim. It is just like you wouldn’t back up a train engine, attach the cars, and then try to floor it to get the whole thing moving.

JRuby on the other hand appears to be focused on getting Ruby developers a foothold into the JVM. I’m not saying JRuby doesn’t bring anything to the table for a entrenched team of Java developers I’m just saying the overhead of doing so is higher than Groovy since you can’t fall back to a more Java-like idiom if you need to. But if you have the development staff that can just jump in and go all out by all means do so.

So, take Mr. Fowler’s advice about Groovy and JRuby but don’t forget to think about how you’re going to back up to the train.

Neal uses an example I thought I’d expand on to make the point of Polyglot Programming. Think of Java as wood; you know, the stuff they get from trees. You happen to be a structural engineer that is involved in building buildings. Now imagine that no matter what type of building you were asked to build you used wood. For a large number of building types that would be just fine. But then you’d run into limitations of the material. Say someone says they want you to build the world’s tallest building. Breaking out the tried and trusted wood wouldn’t get the job done. You’d have to use a wide range of materials each targeting a specific need of getting the skyscraper built. The idea of using one material all the time for all problems seems almost insane, doesn’t it?

At first, I thought Neal had gone farther off his rocker because there would be no way that you’d be able to sell the Polyglot Programming idea to an organization that already had 500 Java programmers and 100 .NET developers that has been cranking out projects for years. Asking to toss into the technology stack another 200+ languages that run on the Java VM and who knows how many for the CLR is a bit much. On top of that, through my personal experience trying to staff development teams, I’ve found that finding developers that have a reasonable understanding of Java let alone knowing anything about Ruby, Groovy, or Jython is an incredible stretch. Add those together and while I thought the idea of Polyglot Programming was a good concept I didn’t think it would survive in the “real world”.

Thinking about it a bit more I realized that I’d already been doing a form of Polyglot Programming for years. Sure, I wasn’t throwing different languages at the JVM but I have piled JSF, Spring, and Hibernate on top of Java/JEE to produce web applications. Each of these frameworks adds a DSL-like layer to the application’s technology stack. Each is already adding to the cognitive load that a developer has to understand to be effective on a project. I am already asking developers to know something more than just Java/JEE or even the Java platform. I am already adding to the technology stack of the organizations I work for. Thinking about it in that light putting the idea of Polyglot Programming isn’t that much of a stretch.

Targeting a specific platform and relegating the programming language choice to what the language can do for you to solve your problems instead of just defaulting to some generalize programming language is an incredibly powerful idea. Being able to alter the tools you’re using over time while not having to go back to re-write legacy applications because you aren’t moving off of the target platform can save organizations lots in development costs.

So, I’m just left wondering where the hidden costs in Polyglot Programming are.