As Sai’s post states, jetlang (or if you’re in C#, retlang) makes for awesome message passing concurrency. I have become familiar with jetlang/retlang in my past few years of working at DRW Trading; many times writing code very similar to that within the examples provided by Sai but in C#. However, over the past few months my team has started using jruby more frequently so naturally we used jetlang as stated in Sai’s post. Shortly after adopting jruby as our JVM based language we started using jetlang via a gem written by Gareth Reeves, called jretlang, which provides the benefits of jetlang in jruby with less of the ceremony. To illustrate this, I’ve rewritten Sai’s first example using jretlang as opposed to jetlang. You’ll see that essentially all it does is clean up some of the setup of the file.

require "rubygems"
require "jretlang"

class Arnie
  def initialize
    @channel = JRL::Channel.new
    @consumer = JRL::Fiber.new
  end

  def start
    @consumer.start
    @channel.subscribe_on_fiber( @consumer ) do |message|
      case message
      when "The End"
        puts "I will be back..."
        @consumer.dispose
        @consumer.join
      when "Terminate"
       puts "Hastala vista baby!!!"
      else
       puts "You are terminated******"
      end
    end
  end

  def ^(message)
    @channel.publish(message)
  end
end

terminator = Arnie.new
terminator.start
terminator ^ "Terminate"
terminator ^ "Buy me ice cream"
terminator ^ "The End"
terminator ^ "Terminate" #Will not puts anything, as you've stopped the fiber

Now upon seeing this, it does not really seem to need the channel for the message passing. Typically we’ll use channels when the object publishing a message and the object(s) receiving the message are distinct and don’t know about each other. Notice I used “(s)” on object, this is because the publisher does not need to worry itself with he details of how many objects, if any, are subscribed on its channel. This is commonly referred to as a process calculi approach of concurrency. The Actor-model approach, which Sai speaks of, is more about an object having a reference to another object, their actor, which will act on the delivery of a message to its inbox. Jetlang/Retlang’s fibers support this concept without having the overhead of a channel. Fibers contain an execute method that can simply execute a lambda on that fiber. Using this concept, we can clean this example up even more and move to a truer actor-model based approach.

require "rubygems"
require "jretlang"

class Arnie
  def initialize
    @consumer = JRL::Fiber.new
  end

  def start
    @consumer.start
  end

  def ^(message)
    @consumer.execute do
      case message
      when "The End"
        puts "I will be back..."
        @consumer.dispose
        @consumer.join
      when "Terminate"
        puts "Hastala vista baby!!!"
      else
        puts "You are terminated******"
      end
    end
  end
end

terminator = Arnie.new
terminator.start
terminator ^ "Terminate"
terminator ^ "Buy me ice cream"
terminator ^ "The End"
terminator ^ "Terminate" #Will not puts, fiber has been disposed

Having used jetlang/retlang as my main source of concurrency for a while, I’ve seen myself writing very similar code to that above every time I introduce a new thread (fiber). But when I look at the class above I think, what really is the main job of the class? I find the answer in the body of the fiber’s execute. It is the only thing that differs from Arnie to any other class that has similar functionality, say JohnConner. After putting up with implementing this duplication for far too long, my co-worker Pat Farley and I decided that we were tired of wasting our “valuable” time and effort typing most of this over and over again. This lead us to create mailbox (see Pat’s blog post), a gem to help remove most of the structural redundancies involved in jruby concurrency models using jetlang. So, using mailbox our example code becomes:

require "rubygems"
require "mailbox"

class Arnie
  include Mailbox

  mailslot
  def ^(message)
    case message
    when "The End"
      puts "I will be back..."
      # cannot dispose from here
    when "Terminate"
      puts "Hastala vista baby!!!"
    else
      puts "You are terminated******"
    end
  end
end

terminator = Arnie.new
terminator ^ "Terminate"
terminator ^ "Buy me ice cream"
terminator ^ "The End"
terminator ^ "Terminate" # THIS STILL PRINTS

This separates the message handling logic from how the object achieves actor-model based concurrency. In addition to actor-model based concurrency, mailbox supports the use of channels, but this example is better shown without channels.

All the above code is available on github as a gist. I’ll try later this week to do the ping-pong example using mailbox and put it up either as a Gist or just an example in Mailbox; please look in the comments for another link to the ping-pong example.

Andy pointed me to a good site that had 49 different photoshop tutorials, after digging though there for a while I came across Tutorial9 and spent a few hours playing with one of the tutorials on there. Here’s what I’ve got to show for it:

Notepad image created from Tutorial9 tutorial on photoshop.

My thoughts on this tutorial: While what I produced it pretty sweet looking in my opinion, I really didn’t learn a whole lot, save how to use the Pen Tool when it’s set to you Bezier Paths. The tutorial was very laid out step-by-step and didn’t explain the reasoning behind a lot of it. That being said, I’m going to continue one with more Tutorial9 tutorials because I think after a few I’ll start to pick things up and should know enough to get my hands dirty with a simple logo or button image for my upcoming site.

Joshua spoke a lot on the agile process and what it takes to design software which is reliable, release frequently and most importantly constantly adds value to your “customer” with almost every release (I put “customer” in quotes because some people think that they may not have customers because their software isn’t being sold. However, that’s not what defines the customer, the end user of your software is your user). The way that they do this is decide after a release what customer requests they are going to release that week and when they’ll be able to release them that week. This can lead to release your software to production more than once some weeks and none some weeks. This can certainly have positive side effects, especially in your release process.

If your team releases using a manual or only semi-automated process, most likely frequent releases are not a luxury for you. My team at DRW has yet to master a fully automated release process, but it is a vision that we are working towards with every release. There are many tools that can be used to do this (and frankly I only know of the ones that we’ve used at some point in time). Which tool you use doesn’t matter, what matters is that you put the effort into an automated release.

The last major thing regarding frequent releases that Joshua mentioned during his tutorials was what their ultimate vision. The ultimate vision for Industrial Logic, and probably for many followers of agile, is a continuous release. Ideally they would like that have the setup that whenever someone committed to their repository, the continuous incremental build would run and then if successful a release would automatically occur. While this would involve many more infrastructure changes than just an automated release it may be a thing to consider. I have not yet given it much thought, since it was a concept I began thinking about roughly 24 hours ago, but I can see where there might be advantages to it.

All in all, I enjoyed my tutorials with Joshua and thank him for imparting his knowledge on me and the rest of us here at QCon – San Francisco 2009. I look forward to the rest of the week here and if anyone has good comments to add on this, please let me know what you think.

So I would currently classify myself closer to the n00b end of the spectrum of professional software engineers, especially when it comes to designing systems that are accurate, reliable, fail safe and fast (not just fast but get < 100 ms). This being said I look forward to the conversation with my colleagues, who fall more at the “I’m a badass” side of the spectrum, on pretty much any task or at least story that I am working on. Not because they “are always right” but because there is a high probability that whatever it is I’m working on, they’ve encountered a similar situation in one of their numerous previous projects. By using their previous experiences I can reach the best solution quicker and *hopefully* with less bugs. At the same time my ideas may just be the new “fresh” ideas that they may not have thought of before.

Anyways, getting back to the point. I’ve recently seen/heard that many companies, yes including mine at times, can hamper the under valued but essential flow of information between two members on the same team, two teams or even two non-competing companies. Most of the times this is not an intentional act that hinder the sharing of knowledge but rather an inadvertent one. At work we utilize many different technologies to open up the necessary channels for sharing within the company (paired programming, forums, chat rooms, brown bag lunches, etc) however this doesn’t seem to be the best solution. But what is a better solution? Why don’t these methods work?

Honestly, I wish I knew. The one thing I do know is that these require a willingness to participate by both the giver and receiver. As most of us are probably aware it is easy to say that you want to and are willing to do what is necessary to share information with your peers, but when it comes down to it the eagerness fades and things go back to the usual, only seeking out information from our friends and those we believe have the information we desire. Something needs to change!