SAP on Rails

The following news shouldn't be a surprise to anyone who's got their groove on with Ruby on Rails. In a new article on SAP Developer Network, german Ruby on Rails developer Piers Harding describes how to easy it is to integrate Ruby on Rails applications to SAP business-related functions via BAPI.

SAP on Rails focuses on providing an alternative type of Model template to the default - ActiveRecord. This is done via SAP::Rfc which allows RFC calls to SAP from Ruby, with automatic handling of data types, and discovery of interface definitions for RFCs. Some of this has been covered in a previous article, and on SDN. The model templating class is SAP4Rails. It's job is to automatically build up connections to R/3, look up the interface definitions for the collection of associated RFCs, and to hold the attribute definitions for the given model. This, coincidentally, corresponds to the SAP Business Objects view of the world in BAPIs.

Where's My Radar Detector

I swear someone should write a toolkit called Radar Detector that integrates your code and runs tests on a low-priority background thread while you're coding. Kind of like Eclipse does the continual compiling thing. I thought of this while reading James Shore's third great entry about continuous integration, where he says in part:

1. I often see teams using CruiseControl that don't have the shared agreement and feeling of responsibility for "we will never check in code that won't build" that underlies true continuous integration. Instead, one or two people feel that way and are using CruiseControl to force the "bozos" to step into line. You can imagine how well this works.

   If you're on an agile team and using a tool to solve a people problem, you're missing the point. "People and interactions over processes and tools," as the agile manifesto says. Get everybody to agree to take responsibility for the build, then install CruiseControl.

2. A second problem I see is teams using CruiseControl to catch their mistakes, not act as a rarely-needed safety net. This is a real and common problem--the team lets their build times get out of control, they stop running all of the tests themselves, and of course they start running into escalating build problems.

Having been on teams that displayed one or both of these anti-patterns, I understand exactly where James is coming from: Continuous integration is an attitude, not a tool and CruiseControl is a traffic cop: it doesn't help you follow the rules; it just tells you when you've broken them.

On the other hand, I've lost a lot of my idealism for being able to put together teams that maintain the right attitude and follow the rules all the time. Human nature is to follow the path of least resistance, and on a team with a continuous build server, that path is usually to check-in without thorough integration testing. Again quoting the agile manifesto, "People and interactions over processes and tools," I wonder if it isn't better to accept that people will tend to break the build and work on improving tools that prevent that from happening.

Connecting to ActiveMQ with Ruby

Oh man this rocked my socks tonight: Communicating transparently between Ruby and Java using JMS !!!

I spent the day using the web services libraries that come with Ruby to do some SOAP calls on my current project. I had some issues with getting the parameters of my SOAP envelope sorted out with the other team providing the service, but being able to code it in Ruby made it a little less stressful. I was glad to read the link above and realize I'm not the only Java guy that does this sort of thing in Ruby.