Location: Groenlo, The Netherlands

URL: http://www.nedaphealthcare.com

Nedap Healthcare, market leader in the dutch home healthcare sector, is looking for a skilled and motivated web developer with a knack for interaction design. We provide an inspiring work environment with a mixture of coding and direct contact with our customers.

Even though Nedap is a fairly large company we work in small teams. Should you choose to accept, you will become the fourth member of our Moves team. Moves is a two year old web application that is sold to home healthcare organizations in combination with a 24" iMac. It allows planners to create routes that make the client, nurse and managers happy. If you want some more info about what we build and how we think, check our blog (listed below).

As a developer you should be proficient in HTML/CSS/Javascript and Ruby on Rails. Flash is a bonus, just like photoshop skills. Working in the healthcare business, we aim to develop most of our code using a BDD methodology.

We are based in Groenlo, a small dutch town near the german border. Though we are not necessarily looking for an on site developer we do prefer someone who is able to drop by from time to time regularly. Freelance is an option if you prefer.

We are offering a great job and unique company culture. It is important to us to build an excellent product by cherry-picking great people, not by bloating our team.

To apply If you are interested send your resume to andre.foeken@nedap.com

This afternoon we held our first Ruby on Rails Workshop at Twente University. We got 20 Apple MacBooks together and allowed 25 people to bask in the glory of Rails!

We want to thank everyone who attended for their enthousiasm and energy. We had a great time! Also great thanks to Pragmatic Programmer for giving us a good deal on their latest Rails book and Inter-Actief (Michel) for their organisational skills.

Below are the sheets we used, courtesy of SlideShare.

Recently I've been implementing a simple web-service protocol that used Net::Http instead of ActiveResource magic. Although it was easy to mock ActiveResource objects, I found it hard to find any intel on how to mock actual Net::Http calls.

Below is a very basic example (which you can easily expand to fit your needs) of how to mock your calls. The example below shows a simple snippet that results in all 'posts' to be result in a Net::HttpSuccess object with a given XML body (which you can define)

Now define the XML data as follows:

Net::HTTP::xml_data = nil

You've probably all been there: your application is running slow, but why? What views or actions are clogging up the mongrels? Or are the mongrels just waiting for the database?

Request log analyzer is a simple but very powerful command-line analysis tool to quickly determine what is taking time, on all kinds of different levels. At the moment it can tell you the following statistics:

• Top 10 most requested actions
• Top 10 actions by time - cumulative
• Top 10 actions by time - per request mean
• Top 10 worst DB offenders - cumulative time
• Top 10 worst DB offenders - mean time
• Mongrel process blockers (> 1.0 seconds) - frequency
• Requests graph - requests per hour

For an example run, or the analyzer take a look at the github. http://github.com/wvanbergen/request-log-analyzer/

To install, run:

sudo gem install wvanbergen-request-log-analyzer --source http://gems.github.com

As you might have guessed from Bart's previous article we've been looking at ways to speed up our Rails app. We've been profiling and query optimizing but at some point we reached a dead end.

Our app needs to calculate a lot of distances between geo locations. Until now we've been happy using a home-grown Ruby method to calculate these distances but our profiling showed that it was (as one may suspect) horribly slow.

We now have several options:

• We could try to built a faster Ruby method (but that would be hard since it's pure math and not really a lot can be done here)

• We could use the database (mysql in our case) to calculate our distances (A lot more db connections in our case, since we need distances between lots of points. Not the standard stuff that gems like acts_as_mappable can handle)

• Use RubyInline to create a faster C based method

We decided to look at RubyInline. A gem that enabled C code to be used right inside a Ruby script. We rewrote the method in C. A simple benchmark proved that our inline C method was 2.3 times faster!

require 'inline'
inline do |builder|
    builder.include '<math.h>'
    builder.c "double calc_distance_between(...) { ... }"
end

Although this result is very good, it does complicate your app and makes it less readable. These inline methods have to be used with care. But in our simple (and very localized) case we decided to keep the C method in favor of the pure Ruby call.

What a marvelous feature, but be wary! It can cause some unexpected behavior if you don't know what you are doing.

This morning we found a rather suspicious bug that lead to unexpected things. Here is an example:

class Person ; attr_accessor_with_default :things, {} ; end
john = Person.new
john.things[:table] = true
...
jim = Person.new
jim.things => {:table => true} # huh??


As it would seem attr_accessor_with_default has some problems with collections. Since we are sharing the instance over the entire class. Peter Williams noted this problem several month ago in his article (which we didn't read until it was too late), however the solution he provided still left us with some very undesireable behaviour.

class Person ; attr_accessor_with_default :things, {{}} ; end # note the extra brackets!


john = Person.new
john.things[:table] = true

...

jim = Person.new
jim.things => {} # okay!
john.things => {} # uhm... not okay!

The variable would only stick if we actually assigned it.

john.things = {:table => true}
john.things => {:table => true} # yay!

But doing this every time is not only a pain but also introduces very hard to debug errors, since the assignment does not fail...it just doesn't work!

We solved it by going old-school. Back to the normal accessor for collections.

class Person
attr_accessor :things

 def initialize attributes=nil
  super
  self.things = {}
 end

end

Now the code works as expected and we can use all operators (like >>, []) from the get go.

Update: It seems this had no effect on ActiveRecord objects that were created using finders so here is the fix for any those:

class Person < ActiveRecord::Base
attr_accessor :things

 def after_initialize
  self.things = {}
 end

end

A few months ago I got the assignment to set up and build javascripts-tests for the scheduling view of moves. At first I had to select a testing-framework where the test would be written in. The framework had to be able to run both unit and integrations tests. Also it would be very nice if we can run these test automatically through the command-line instead of clicking around in the browser (autotest).

After reviewing some frameworks, I chose the Crosscheck framework (http://www.thefrontside.net/crosscheck). Crosscheck is a javascript-testing-framework written in java. It is crossplatform and you can control it from the command-line. It is even able to emulate the behavior of multiple popular browsers like ie6, Firefox 1.0 and Firefox 1.5. Sounds like the ultimate testing framework!

So after my decision I started playing around and implementing tests. However, when the tests became more complex I ran into trouble. Some basic browser features like document.write() (ie6) and the Option object where missing. I was able to work around these problems, but the real trouble began with the integration tests. As our application relies heavily on ajax through the prototype framework, testing this functionality is crucial. However, I was not able to do this. Performing one hack after another, I finally gave up.

The crosscheck framework was clearly not mature enough to satisfy my needs. My conclusion is: Using crosscheck for unit-testing is doable, but the framework is not mature enough for the use of integration tests. So what are the problems with crosscheck? As mentioned earlier, it is written in Java, so it tries to emulate the browser behavior based on it's specifications. The advantages of this approach is that you can emulate more than one browser, the disadvantages are that the emulation is an approach, so you will never really get the real behavior of the browser.

If a browser changes its implementation, the framework is always outdated. You don't get the browsers quirks, so if it your tests pass in the test framework, there is no guarantee it will work in the real-browser world. Another problem with crosscheck is that is seems to be abandoned. The last changes are from end-2007 and as far as I can see none of the reported bugs have been fixed yet. Firefox 3.x and ie7 are becoming standard, but these browsers are not available as a test-browser in crosscheck (and there are no clues they will be soon).

What can we expect from the continuity of crosscheck? If you, like us, want to be able to test a long-term project, then it is important that your test-framework is long-term too. So what does my ideal javascript-test-framework look like?

It should:

• Run from the command line
• Represent the browser realistically
• Emulate ajax responses
• Mock objects
• Run implementation tests

As far as I know, no such framework exists. However, in my view, it shouldn't be too hard to realize. We could embed the mozilla tree in an application. That way we always have the latest version of the mozilla engine and an exact copy of the behavior including it's quirks. Through the Mozilla API we can access the DOM and other functions. The framework should be able to easily load tests and run them (for this part it's important to take a good look at the x-unit patterns).

At this moment I don't have a clue how easy it is to emulate the ajax responses through mozilla API calls. Furthermore the framework should be give a rich toolkit for testing including abilities to mock objects. You start the framework via the command-line for easy integration with test-runners like autotest. Of course this application should be released under the GPL-licence. Now we only need someone to implement this for us!

Steven van der Vegt (s.vandervegt TA student.utwente.nl)

Ps we are offering an internship for the development of the described plugin at Nedap healthcare. Interrested? bart.tenbrinke@movesonrails.com International students welcome!

Autotest is great, but when it is waiting for test, my MacBook turns into a whirlwind as autotest takes 100% CPU. After looking at autotest.rb, we easily find the waiting function:

def wait_for_changes
  hook :waiting
  Kernel.sleep self.sleep until find_files_to_test
end

As self.sleep is defaulted to 1 it means that my laptop does not sleep at all. Changing this is quite easy, as you can just add this to your .autotest file in your home directory:

Autotest.add_hook :initialize do |at|
  at.sleep = 5
end

Experiment with the amount to determine what works for you. Offcourse autotest will now react slower to you changes, but hey: you can't have everything. Enjoy the silence!

Original by XKCD.

Like lots of you I bought the incredible MacHeist app bundle last week. One of the appz was Cha-Ching, a finance program to keep track of your money.

One of the most useful features is the import. You can simply import all of your bank's records and be done with it. Unfortunately the dutch banks (or at least the Rabobank and Postbank) don't support the same formats Cha-Ching supports (like OFX/QIF).

I wrote a small ruby script to convert the banks CSV files to OFX files. There are two separate files below (one for each bank):

CSV convertor - Postbank (Ruby)

CSV convertor - Rabobank (Ruby)

Before you can run the files you need two additional gems (if you haven't got them already).

sudo gem install extensions
sudo gem install builder

After this you can use the scripts like this:

ruby csv_convert.rb [CSV FILE] > export.ofx
ruby csv_rabo_convert.rb [CSV FILE] > export.ofx

Update: Now supports Tiger using PHP version of script and (optional) automator

For the next files you don't need anything else than a vanilla Tiger install of OSX.

CSV convertor - Postbank (PHP)

CSV convertor - Rabobank (PHP)

You can use them like this:

php csv_convert.php [CSV FILE] > export.ofx
php csv_rabo_convert.php [CSV FILE] > export.ofx

For the simple version, use the automator zip file! Read the README to get it to work.

CSV convertor - Postbank/Rabobank (PHP/Automator)