Ruby Tuesdays

A lot of this problem is to do with implementing the algorithm that shares the gem. The only easy aspect is that the total value of the gems must be a divisible by the number of shares.

Danilo had used this problem while in South America so he already had a dojo solution that used recursion to effective check every possible combination. While that was clever there was also some discussion as to what causes the “greedy” method to fail. The method seems to work in such a large number of cases that the exact split has to be pathalogical.

At the last session we finally managed to get the datastore sorted out along with the basic application flow that it should have (not entirely implemented yet).

You can look at the code in GitHub so in terms of the report I’ll just mention some of the side conversation. There was a point as to whether passing parameters via a hash map was the preferred way of doing things. Points raised in favour of doing it include named parameters and the ability to consume options from the map and pass it along to other objects.

The application should call a redirect when dealing with the POST from the pizza form. The next page should be a list of people who are going to the next Ruby Tuesday. I think we should also have the personal confirmation message as well. Probably stashing the Confirmation in the Flash scope.

There was also a bit of discussion around testing the application. In its current state the application is a bit of hack and has not been driven by TDD (it has instead been driven by a need to order pizza). Coverage is therefore poor and while specifications were passing for most of the session the app was completely broken and needed post-session hacking to get it to run. TDD can lead to devs being a bit blinkered as to what is happening with the code in general. You need to actually run your application and see that it is still making sense at the user interaction level.

There was a discussion about the value of testing getters and setters in Ruby. Although this is still low-value testing there is actually nothing guaranteeing that any of the getters, setters or constructors work unless you have a runtime test for them. There doesn’t seem to be an alternative but to test them.

Just a quick write up. During the session we just installed Ruby and got irb and Scite running. Danilo then went through a few features of Ruby. This lead into a discussion of the language that I am going to try and sum up here.

Ruby is a dynamic language with strong typing and effectively open classes. In Ruby everything is an object. It treats methods and functions as first order citizens, these are objects of the Proc type. Ruby makes metaprogamming easy and there are several ways available to do it. All method calls are dispatched by lookup as reference the method represents may change between calls.

Programming in Ruby presents strong challenges for writing conventional enterprise software. Due to it’s dynamic nature testing is vital as little can be asserted about the operation of the code prior to actually running it. However some testing frameworks can actually interfere with the way the code runs so unit test behaviour may not translate to functional test or production environment behaviour.

Ruby inherits a lot of ideas from its ancestor Perl, importantly there are often several ways to do things and therefore it is often easy for people to convert to the language as they can use the ideas of other languages they are familiar with such as Java. However to get the most out of the language it is important to be familiar with what Ruby has borrowed from Smalltalk and functional languages.

Applications written in Ruby tend to be fast and easy to create, however TWUK does not have any real stories about how easy those applications are to maintain. Ruby’s small syntax and metaprogamming makes it a good choice for implementing DSLs and that might be a consideration in chosing Ruby for a project. Code could be very close to the domain language. That said we were not sure how much of that is good programming style by developers and how much is inherent in the language. There were comments about procedural style programming in web testing scripts and what kind of code someone unfamiliar with the language would create without guidance.

Actions stemming from the meeting were to start compiling a list of Gems that people have used in anger on projects and recording opinions on them. This has been started at the Ruby Tuesday wiki.