We wanted to show how many hours were going through our application on a big flat screen at our office. So I whipped up a small javascript/html page that could show a neat animation. I borrowed the raw images from this blog. The end result can be downloaded from here.

Nedap Moves. Unfortunately for you it is all in dutch, but you can still look at the pretty pictures.

Moves has 45 controllers (4820 lines), 72 models (6457 lines), 121 test classes (4148 lines, still a work in progress...), 19 javascript classes (4560 lines), 176 migrations and only three developers :)

Building a large application always comes with a lot of problems. One of the most important issues is usually that the implementation doesn't match the way it is used anymore.

This can be solved in two ways: The short term simple way, which is to simply ignore it, or the always dreaded refactor. About 10 days ago (including weekend that is), we were at such a point.

A little background information on the problem might be insightful. At the heart of our application are the so-called events. These events are simple homecare related actions that have to be performed at some point in the future. This can for example be delivering and / or helping a client with his or her medication.

All the events are generated by more general rules that state when certain care has to be provided for, most of the time based on weekly or fortnight intervals. These generated events are what Moves uses to its scheduling.

Well, back to 10 days ago. We were still working with the first version that models all this behavior and it was showing its problems. Events could be generated at multiple points in the system and none of us had a clear view of the inner workings of the system anymore.

Because the major part of the work that was assigned to me involved trying to optimize and improve this model, I dared to ask the always dreaded "Why?" question. At a certain point I started wondering why a certain design choice was made as this choice was making the situation very complex and slow.

I asked Andre and Bart and together we thought about the problem and how it could be solved. On our way back home we were still discussing it in the car and decided to stop developing for the upcoming Moves 1.0 and discuss the entire model the next morning. That night at the new Harry Potter movie, both Andre and I couldn't get the ideas out of our heads (we did enjoy the movie though).

After a good night sleep, we were all ready to do some good thinking. After quite some discussion we came to the conclusion that we only had the two options already mentioned above. Either deal with the current situation and put a huge legacy burden on ourselves, or just refactor the most important and complex part of the system.

Just to make matters a bit more complicated, we had an upcoming deadline for the first completely working version of our product, which made the decision even harder. Because the choice was do it now or never, we had to go for now. Ignoring the situation was an even bigger no no, because of the huge amount of problems that would occur in the future.

So there we were... 10 days to go and ready to delete a couple of thousand lines of code... After branching our new version (so we could go back in case of disaster), we went for it. It took us only 6 days to get the new branch in a reasonable condition, so we merged it back to the trunk. No matter what happened, we were not going back to the old situation. We liked the new model way too much :).

And here we are, just delivered our first version :). That means we made it, and I can say that we are pretty confident that the system is working much better with the new event model in place.

What we've learned from this experience is that you should never wait too long with refactoring a piece of your system if it gets in your way. It will get even more in your way if you let it stay. Rails is pretty forgiving in ripping a part of the system out and ActiveRecord lets you stay pretty flexible. In our case it went much better than we could have hoped for.

So, after 1.0 its time to rip the next part out :). The actual drag & drop interface we use to couple all the events from the clients to the employees has some very nasty properties. It couldn't be done before 1.0, but luckily it didn't have to. It's only the interface and javascript side of the system and it simply has to work the same way, only nicer for the developer.

Well, the time has finally come! After almost a year of hard work, we are finally ready to release 1.0. Tomorrow the first group of customers starts using the product for real.

Below is a small screenshot to commemorate the moment.

Andre & Bart

P.S I'd like to take this occasion to thank Dirkjan from Sparks for his effort in making this possible :)

Just wanted to share we will be attending RailsConf 2007, so if anyone wants to say hello that's their chance!

Currently we are swamped with work, as our version 1.0 is coming up. But don't worry out multi-page plugin hasn't been forgotten, it'll get there!

The tutorials make it sound so easy. Plug and play even. Unfortunately reality (as always) bites hard.

SOAP integration is a piece of cake if you have one server and no authentication, but when you do the trouble starts. Although the problem is easy to solve once you know how, the lack of documentation on the subject is annoying.

Ruby's current SOAP implementation supports basic http authorisation during communication, however it does not support getting the WSDL file trough the same authorisation... (Argh! 1 ) So you have to pre-fetch the WSDL file and store it as a file, since Ruby does not support reading the WSDL file from a string (Argh! 2).

Since we have multiple servers running the same application on different ports the cached WSDL file is never correct...(Argh! 3) We solve this by overriding the WSDL's proxy setting.

The final code is short but it took me a while to find all this stuff out so I thought i'd post it here:

require 'soap/wsdlDriver'

# Connection settings
url   = "http://testingserver:3000/webservice"
usr  = "***"
pw  = "***"

wsdl_file = "wsdl/cached_file.wsdl"

factory = SOAP::WSDLDriverFactory.new(wsdl_file).create_rpc_driver
factory.options["protocol.http.basic_auth"] << [ url, usr, pw ]
factory.options["protocol.http.ssl_config.verify_mode"] = nil
factory.proxy.endpoint_url = url

Sorry for the fact that we haven't posted a lot. It's because we are quite busy with something. Can't tell you anything more that it is big.. and that it is ruby on rails. Keep an eye on the site for more info. What's comming up? The Act as Owned plugin is nearing it's 1.0RC release and will shortly be added to rubyforge. In the meantime: patience is a virtue!

Moves On Rails is finally up and running. But what is it for? Well, just wait until our Rubyforge projects are accepted, so that we have some content.