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 :)

The longawaited update for the Gettext Generator.

• First release as plugin
• Added svn:merge raketask
• Updated generated resource to mimmick scaffold_generator packaged with rails 1.2.3 tag

So go to RubyForge or take a look here.

I'm currently getting the plugin uploaded to rubyforge. As soon as I have that figured out how that works, I'll post the link here.

ruby script/plugin install svn://rubyforge.org/var/svn/gettextgnrtrs/tags\ /Gettext-Generators-1.2.3/

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 :)

The third movie of our presentation deserves a seperate blog entry: Multipage navigation.

Because we sell our webapplication on a 24" Mac, we have a problem. As you all know a webpage designed for 1024 x 768 does not look nice on 1920 x 1280. There is just too much whitespace on the left and right.

To solve this in Moves, we wrote a javascript library that makes our application function like a book. If you click employees , you'll get a list of employees. Clicking on a single employee will result in that employee being displayed on the right. Just watch the movie and you'll understand it right away:

3. Multi-page Navigation

There are still some major issues with this library. Because all the links on the application are parsed on the fly and rewritten to Ajax links, they break our nice URLs and the back button (NOOOO! WHAT DID I TELL YOU ABOUT USING AJAX FOR NAVIGATION!!!). This is something we have accepted for the time being (as it is a closed web application), but it is something we want to fix desperately. We can get away with this for the time being because you usually only want to go back one page, and with our multi-page navigation, this page is already visible. Also, users find the breadcrumb navigation very intiuative. The upside is that our library degrades gracefully: If you don't own a big screen, the application will fall back to the standard behavior. Isn't that cool?

We will be releasing this javascript library soon on Ruby Forge. Why? Because then the javascript will work out of the box (no Ruby code needs to be changed). You'll be able to get it to work in PHP or Java, but it you'll need to implement some restfullness in your application.

If you have any remarks or questions, please feel free to email Andre or me (Bart).

We were asked by Zorgmagazine.nl to express our visions about homecare scheduleing. This resulted in the attached article. At the moment it is only available in Dutch, but an english version will be coming soon.

Moves in Zorgmagazine (Dutch) Download

We were asked to do a quicky on the Holland On Rails rails conf :)!

We'll be talking about what we are doing, and we'll have a nice surprise for the rails comunity. We'll be posting that on our website around the same date. What it going to be? Just make sure you've got enough money for a big flatschreen....

Haven't you got a clue what i'm talking about? Pay them a visit: http://www.hollandonrails.nl/

Our initial relase of our Gettext Rails Generator is frontpage news on http://www.rubyforge.org. A good motivator for everything that is still to come!