8th Light Blog

I gave a Chirb presentation last night on RubyCocoa, which went reasonably well. The slides, the working versions, are here. Unfortunately the images do not show in Safari, so you may want to use Firefox.

Jim Suchy recently laid down some basics of Rinda in his blog Rinda 101. I would like to build on that and talk a little about the rindlet architecture. A rindlet is some process that is listening to the tuplespace, waiting to read or take messages.

When a tuple is written to the tuplespace, the rindlet will look at the message and determine if this is a tuple of interest to it. If it is, then the engines warm up and the tuple gets processed by the logic in the rindlet. Otherwise, the rindlet will take a pass, and wait for another message to be written to the tuplespace.

These rindlets are autonomous and asynchronous pieces of business logic that are messaging across many systems, or across many modules of the same system. We deploy them as daemon processes.

As a proof of concept, Jim and I built a trivia game, with two different interfaces. One will be a rich client, developed using a ruby framework called limelight, and one will be a command line ruby client.

Lets look at the code in the rich client application which updates the question on a screen for all the trivia participants to answer.

require 'rinda_client'

module CurrentQuestion

  def start_update_question
    Thread.new(self) do |current_question|
      while true
        update_question(current_question)
        sleep 1
      end
    end
  end

  def question_update(current_question)
    client = Rinda::RindaClient.new
    tuple = client.read ["questioner", "response", "current question"], 1

    unless tuple.nil?
      current_question.text = tuple[3] 
      current_question.update
    end

  end

end

This code spawns a thread to sit and listen to the rinda server to see if there are any new questions. The questioner rindlet will post a tuple called “current question” every 30 seconds to change the question. After we create a rinda client, we set up the match criteria for the tuples we are interested in.

tuple = client.read ["questioner", "response", "current question"], 1

We want to read all tuples that match

 
["questioner", "response", "current question"]

current_question.text = tuple[3]

The fourth parameter, which is the question text to display on the screen.

This example shows you can integrate your application with rinda. Your application can listen to the tuplespace to get messages that are relevant only to it. If you are writing a rails application, then you would have to use the view helper periodically call remote, since rails is single threaded, it isn’t as easy as firing a thread and moving on.

Lets start with some rindlet code.

require "rindlet"

class QuestionerRindlet < Rinda::Rindlet

  def run
    with_standard_tuple("questioner", "next question") do |tuple|
      game = Game.active_game

      question_text = nil
      if game.nil?
        question_text = "No active game!"
      else
        question = game.next_question
        question_text = question.nil? ? "No more questions!" : question.text
      end

      @rinda_client.write(["questioner", "response", "current question", "#{question_text}"])
    end
  end

end

First, the withstandardtuple method is a standard wrapper to match elements and take the tuple if it matches and pass it into the block. Alternatively, you could do:

tuple = client.take [“questioner”, “request”, “next question”]

The rindlet itself then gets the next question from the game, and writes a tuple back to the tuplespace with a response, containing the question text. Notice the code in this rindlet feels a lot like controller code in the MVC pattern. Since rinda is a technology and notation of communication, it will just call the business logic in the models and respond to the actions performed if needed. Rindlets often behave as system level controllers, not specific to any one application.

I have had lots of fun getting rindlets to work, and they have been an interesting tool for decoupling business logic from any specific application. Happy coding!

Note: I will soon be releasing a rinda gem with the rinda server and the base rindlet class, amongst some of its functionality.

There is no perfect software. At least I have never seen it. Bugs and minor feature changes are indications people are using your software. Real users hit a system in ways that no control group can, and on non-critical applications, this is the best way to test your software. Let people use it and see what happens. This is goes in line with the agile philosophy of release early and often. Get your application out there as fast as you can, so you can mold the finishing touches around the real users experience rather than a faux-environment.

There is some conversation about what is and what is not a “bug” in the software world. That is not a conversation I would like to partake in here, so lets call both bugs, integration items, minor feature enhancements, and things that fall through the cracks of development tweaks. It doesn’t matter what the nature of origin is, these are all things that MUST get done.

After the release of one of our products, a load of tweaks came in from the customer. As proud craftsman, we decided tweaks were our responsibility, and we would take them on in addition to our normal iteration. So we started to do them, to the detriment of our iteration. We accomplished only about half of our iteration’s velocity.

The next iteration, much to our surprise, we were twice as busy with production support. This is about the time that a developer looses a little faith. What did we miss? Is this high quality software we are writing? So we lost even more velocity when it came to iteration 2 after the release. Also, the customers were now unable to accurately plan new features moving forward due to an unstable velocity.

It is so hard to predict or estimate production support and tweaks. However, we needed to be able to so that the production support didn’t leave such a footprint in the project. It felt and looked like we were not getting very much done, even though we were working harder than usual. It was the time being put into a vacuum and being unaccounted for that was troubling the project. It also had a negative effect on the morale of the team.

We came up with a card, we call the “Production Support Card.” The amount of the iteration’s velocity this card took up was calculated by the amount of time we spent on production support the previous iteration averaged with the amount of time allocated for that iteration(sound like a familiar formula?). It is added as a card to the next iteration. If the developers only spend 6 of the 10 points on production support, it is expected that they will complete 4 points worth of stories, which are automatically entered in the iteration. For the first iteration where it becomes apparent that we need a production support card, we set the point value of the card at 0 and track how much time we spend, bumping out of the iteration the least important stories if needed.

So, what does this tracking buy you, if you have to spend the same amount of time on tweaks? First, it allows transparency to the customer about what you are working on that week. When they see your normal velocity of 20 points turn into 5 points, they have a right to be worried. When you say, in a defeated voice “we were fixing bugs,” they also have a right to worry about the stability of the code you have been writing, even though this spike in minor changes to the application is a part of the normal process.

Second, it raises the moral of the team, because they are working towards a specific goal, to remove the production support cards from the iteration. Also, we get the satisfaction of maintaining a velocity in points, which is something we know so well it is hard to work without.

It takes a few iterations, and the team squeezes the life out of the production support card, putting you back on track. After those iterations, the footprint goes from sasquatch to mini-me.

It also helps the customer plan around production support. Their time lines and release dates are made from a projection of feature difficulty to development’s velocity. Over a long period of time, the velocity normalizes, and it hurts the projections to have hiccups. If you have production support data, you can predict about how much time around a release you will loose on the initial release of brand new development.