One thing that amazes me is the amount of code required for some simple O/R mapping, or I am missing something? I hope to be wrong about this, but it seems like an EJB3 "entity bean" requires, for each column in a database, the following items written and maintained:

• a private member variable
• a getter method
• a setter method

As I have some Ruby on Rails experience, where inheriting from ActiveRecord gives you those things out-of-the-box, I am amazed of the sheer amount of boilerplate code needed in Java for the same thing! I asked a friend wih ZendFramework knowledge about how it worked there, and it seems like Zend_Db_Table_Abstract works just like ActiveRecord.

I can’t be the first one perplexed by this, especially not when the development guide for the ASM 3.0 Java bytecode engineering library contains exactly the above parts as an example of generating bytecode! (See section 3.1.3.)

• Agile Software Development With Scrum by Mike A. Beedle and Ken Schwaber
• Agile Web Development With Rails (2nd ed.) by Dave Thomas, David Heinemeier and Leon Breedt
• Everyday Scripting With Ruby by Brian Marick
• Programming Ruby (2nd ed.) by Dave Thomas, Chad Fowler and Andy Hunt
• User Stories Applied by Mike Cohn

Unfortunately two of them are already old. A version of Programming Ruby updated for Ruby 1.9 now exists in PDF format and Agile Web Development With Rails will most likely be updated due to the recent 2.0 release of Ruby on Rails. Maybe Everyday Scripting With Ruby will be updated too soon, but I hope that all of them will still be of use to me. I only use Ruby and Ruby on Rails for my personal projects anyway, but I think that both of them — the language and the framework — make too much impact to be ignored.

Speaking of Ruby on Rails: I read that Hemnet, the major Swedish site for real estate ads, is using Ruby on Rails. Cool!

I bought Agile Software Development With Scrum in order to read one of the major works about Scrum. I really ought to have read it before by Scrum Master certification but I can admit I didn’t. Now it’s time to make up for that.

The reason for buying User Stories Applied is that I want to improve my skills in handling customer requirements. My current client is very fond of use cases but I don’t think that diminishes the value of the book in any way.

Mysteriously missing from today’s world wide web, but fortunately captured by the Wayback Machine, the blog entry Ant and XML is worth reading. The entry is concluded like this:

If I knew then what I knew now, I would have tried using a real scripting language, such as JavaScript via the Rhino component or Python via JPython, with bindings to Java objects which implemented the functionality expressed in todays tasks. Then, there would be a first class way to express logic and we wouldn’t be stuck with XML as a format that is too bulky for the way that people really want to use the tool.

Or maybe I should have just written a simple tree based text format that captured just what was needed to express a project and no more and which would avoid the temptation for people to want to build a Turing complete scripting environment out of Ant build files.

Both of these approaches would have meant more work for me at the time, but the result might have been better for the tens of thousands of people who use and edit Ant build files every day.

Hindsight is always 20/20.

The “real scripting language” part sounds just like Ruby’s build program Rake and “a simple tree based text format” sounds very much like YAML, a format well worth considering for hierarchical data structures.