8th Light Blog

The other day, I was with my team at an interview for an internship. After we had asked the candidate some questions, he started to reciprocate, asking each one of us a little about our development past. Every one of the developers stories went something like, I was at the wrong job, and had to get out. The candidate listened carefully to each story, sat for a minute, then asked the obvious perfect question, “What makes the right job?”

I heard responses like “Waking up in the morning and being excited to work, rather than counting the days until the weekend.” The reason this struck me as interesting was only when I reflected back to why I loved computers and programming in the beginning. It was all about the problem. I went to college, so I could join the CIA or some think tank which wrote software which monitored and defeated the enemies entire world. About every developer I went to college with got into computer science with some similar grandiose notion. Most of them were gamers that wanted to work on the next big game. Yet today, I know no developer who works on games, and I don’t work for a think tank. I know lots of developers who are more than qualified to do it, but choose not to. So, how does this relate to the right job question?

The answers about the right job question had nothing to do with the problem set being solved either. Nothing to do with WHAT applications were being written, but the culture and with whom they are being written. I think this is because each problem set worth application development proposes unique and interesting problems for a developer to solve. I have never been on a project which didn’t constantly keep me on my toes as far as problems to be solved. Even if the business domain is a bit bland, the development domain isn’t. I have seen developers to do lists get bigger and bigger from day one on a project, and never shrink. This has nothing to do with laziness, quite the opposite, it has to do with an insatiable drive to make things better than they are.

As a developer, my problem set isn’t the business/science problems I am solving, even though that might be interesting in itself. My problem set is development itself, the different patterns/practices I use to solve the world’s [software] problems. It is like many art forms where the beauty and creativity exists in the process of creation rather than the results. I am sure you could have asked Pablo Picasso to paint something he didn’t have any interest in, and he would have been passionate about it and done a wonderful job. I suspect it is because the importance is in the painting process and the choices you make during each step. How he chooses to depict the subject is more interesting more than the nature of the subject itself. I find the same true in development. The thought that goes into the different development choices I make on a daily basis is the part that drives me to love development.

Having the right results is only part of the equation (an essential part though). When I started my path as a developer craftsman, I learned the WHAT in applications is not as important as all the other variables. I suspect some of the other members on my team would agree, based on their answers to the right job question. Being part of a company that values the software for its own ends and spends the time and attention to do it right is a privilege to me. To me, that is the definition of the right job. I enjoy knowing my software will be used. Everything I write is valuable to the company for its longevity and success. It takes people who are similar in values for it to work, but it makes the work fun. It makes me wake up before my alarm, rather than snoozing.

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.