8th Light Blog: Tag Micah

Tag! I'm it!

Micah — Wed, 02 Jul 2008 14:46:00 +0000

David Chelimsky tagged me with this “chain-blog”. I’ve enjoyed reading other peoples’ stories. Here’s mine.

How old were you when you started programming.

Hard to say. I suppose I was legitimately writing code at 9 years old

How did you get started programming.

You might say I was born into programming. At a very young age, maybe 4 years old, my dad (Unclebob) would put me on his shoulders and take on a robot’s personality. He would remain motionless until I ordered a command. For example, if I said “walk” he would start walking. If I said “turn” he would turn. And in a very computer-like-fashion, he would follow my orders to the “T”. After a “walk” command, my dad would not stop walking until I issued a “stop” command. Poor programming on my behalf often led my dad, with me on his shoulders, straight into a wall. I used to laugh with delight as he’d bounce off and walk into the wall again and again until I corrected my programming error.

What was your first language?

At 9 years old my dad taught me Logo. I was drawing circles, squares, spirals, and in general making that turtle dizzy.

What was the first real program you wrote?

In high school I programmed casino games on my TI-81 during physics class. You could play Black Jack, Roulette, Bet on the Horses, play the One Armed Bandit. My friend Jim Maggio even did some pixel art for the slot machine. It was pretty sweet. All the physics students were required to have TI-81’s so my games ended up getting copied over and over. My first open source experience I suppose.

What languages have you used since you started programming?

In chronological order…

Logo, Basic, Fortran, Pascal, Forth, C, C++, Scheme, Java, Python, Ruby, JavaScript, C#, Objective-C, Smalltalk, Assembly.

Whoa! I’m impressing myself with that list. But who am I kidding? I doubt I could remember how to write HelloWorld in half those languages now.

What was your first professional programming gig?

An internship at Object Mentor. I wrote some Java Servlets to automate parts of their website.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Software is not a spectator sport. ie. Just watching people code won’t make you a good coder. Code as much as possible if you want to master your craft. Code at work. Code at home. Code on vacation (WARNING Your spouse may throw your computer off the balcony). Code for fun. Code to kill time. Code while you’re sleeping (I mean in your dreams).

What’s the most fun you’ve ever had programming?

The project the David Chelimsky referred to was mighty fun. But I’d have to say the most fun I’ve had with my colleagues at 8th Light, Paul Pagel, Jim Suchy, Eric Smith, and Doug Bradbury. I have never worked with a stronger team. When it comes to software, I imagine we could prevail over any challenge. Outside of software, our strengths are less impressive….

We started a basketball league and had a perfect record: 0-10. That’s right, we lost 10 out of 10 games.
We went on a ski trip together an managed to loose some family members in the mountains, during a snowstorm, at night. They lived.
Doing push ups every hour of every working day surely made us stronger and earned us an infamous reputation in the office.

Up Next

Paul Pagel, Jim Suchy, Eric Smith, Doug Bradbury, Matt Segvich, Unclebob, Bob Koss, Michael Feathers, Dean Wampler, Tim Ottinger, Chad Fowler, Jake Scruggs, Mike Clark

Tag! You’re it!

Announcing Limelight

Micah — Mon, 02 Jun 2008 20:42:00 +0000

I’m pleased to announce the open source Limelight project: A thin client and application framework written in Ruby (JRuby).

http://limelight.8thlight.com

LimeLight at RailsConf 2008

Micah — Tue, 05 Feb 2008 04:32:00 +0000

Back at RubyConf 2007 I prepared a 1 minute presentation, well… more of a teaser, about an application framework called LimeLight.

What is it? LimeLight is a selfish dream of mine. In a nutshell it’s a light weight ruby framework for building rich client applications. To explain further, know this. I hate building web applications. Not because they’re hard to build or anything silly like that. It’s because they’re so perverted. Writing web apps makes me feel dirty; as though I’ve sunk into a pit of waste and decay where the foundation of my work is a pool of sludge. No matter how hard I may try, the very nature of modern web apps taints my code and leaves me a sour, grumpy developer.

Stop

To understand what I mean, consider the trivial little widget on the right here. Try clicking the button and watch the light blink. Simple huh? Can you count the number of languages/technologies used in implementing this widget? And don’t forget the code required on the server side…..

I count 5. That is, in most cases this widget would require about 5 or more different languages. Let’s count. HTML of course. CSS to make it look right. JavaScript. That’s 3, but in most cases you’ve got server-side code which, if you’re lucky, involves Ruby and ERB. Think about it. You need to know 5 difference languages to build that silly widget. Yikes!

I’ll include the code below. Know that I’ve made every effort to make this code as clean and simple as possible. Still, I would need to borrow your hands and feet to count all the things I find distasteful about it. Have a close look. Ask yourself, “Couldn’t there be an easier way to do this?” I say there is.

If you’d like to learn more, I’ll be presenting on the topic at RailsConf 2008. Or you can come back this this blog site later. I’ll be sure to post any exciting progress.

<div style="border: 1px solid blue; width: 100px; height: 100px; 
               text-align: center; background-color: white; 
               float: right;">
    <div id="light" 
            style="border: 1px solid black; width: 50px; 
            height: 35px; margin: 10px 24px 10px 24px; 
            background-color: red; text-align: center; 
            padding-top: 15px;">
        Stop
    </div>
    <input id="button" type="submit" 
              value="Start" onclick="stopOrGo();"/>
    <script type="text/javascript">
        function stopOrGo() {
            var button = document.getElementById('button');
            var light = document.getElementById('light');
            if(button.value == 'Start') {
                start(button, light);
            }
            else {
                stop(button, light);
            }
        }

        function stop(button, light) {
            light.style.backgroundColor = "red";
            light.innerHTML = "Stop";
            button.value = "Start";
        }

        function start(button, light) {
            light.innerHTML = "Go!";
            button.value = "Stop";
            blink();
        }

        function blink() {
            var light = document.getElementById('light');
            if(light.innerHTML == "Go!")
            {
                if(light.style.backgroundColor == "green") {
                    light.style.backgroundColor = "lightgrey";  
                }
                else {
                    light.style.backgroundColor = "green";
                }
                setTimeout("blink()", 500);
            }
        }
    </script>
</div>

Micah's General Guidelines on Ruby require

Micah — Mon, 08 Oct 2007 19:10:00 +0000

Ruby files have to require other files. There’s not avoiding it. Techniques to manage require statements are numerous and varied. Having tried most of them, I’ve found a system that works well for me. What follows are the guidelines I use to manage Ruby require statements.

1. Establish a Convenient Search Path

Although it’s possible to use absolute paths or complex relative paths such as below,

require "/Users/micahmartin/Projects/ttt/lib/game"
require File.dirname(__FILE__) + "../../../lib/ai/winner"

this should be avoided as much as possible. Otherwise you’ll be fixing dozens of require statements every time you move a file. It’s no fun. You’ll want your requires to look like this:

require "game"
require "ai/winner"

To achieve this, add your lib directory to the ruby search path.

$: << File.expand_path(File.dirname(FILE) + “/../lib”))

This will have to go in one of the first files that gets loaded. If you’ve got a standalone Ruby app, you could add this to the startup script. In a Rails app, it can go in environment.rb. If you’re using RSpec, you may want to add it to spec_helper.rb.

2. Independent Requiring over Require Farms

In some projects, you’ll find files that contain nothing but require statements. It’s common in gem projects. The advantage is that users of the library need only require one file which in turn requires everything else you’ll need. Convenient huh? Sure is. But there are 2 major consequences of this:

Maintenance Mayhem - Every time you add, delete, or rename a file you have to remember to update the require farm file. It’s easy to forget. And the order of requires can get very hard to manage especially if you end up with cyclic dependancies.
Drowning in Dependancies - Require Farms have a tendency to require more than you want. If there’s only a portion of the library you’d like to use, with the Require Farm you get the whole thing. The extra dependancies will consume more memory at run time and they may add undesired behavior to your system. In general, this is a violation of the Dependancy Inversion Principle.

Rather than build Require Farms, allow each file to be responsible for it’s own dependancies. Let each file require the files it needs to work. This approach can be a bit annoying as you’ll find your self using altogether more require statements, but it’ll pay off in the long run. With each file independently managing it’s dependancies, the system will be easier to maintain and it’s components more reusable.

3. Building Absolute Paths

Try as you may, you can’t always avoid using absolute file paths in your require statements. The following is reliable way to refer to other files.

File.join(File.expand_path(File.dirname(__FILE__)), "..", "spec_helper")

Let me break it down. First:

File.dirname(__FILE__)

This gives you the directory of the current file that is being executed. However, you never know what you’re gonna get since the form of the path is based on how the program was executed. This might give you an absolute path or it might give you a relative path from anywhere on the system. In some cases, Ruby won’t do what you expect with relative paths so it’s best to expand this into an absolute path.

File.expand_path(File.dirname(__FILE__)

Now you’ve got an absolute file path and you just have to add a relative path to the desired file. Normally I’d do this:

File.expand_path(File.dirname(__FILE__) + "../spec_helper")

However, this is not quite portable since I’m using forward slashes. To get this to work on any system independent of file separator, use File.join as shown above. Use this technique to require files when you don’t have your search path configured.

Happy Requiring!

Ruby DSL Blocks

Micah — Sun, 20 May 2007 08:45:00 +0000

There’s a common pattern I’ve seen for developing DSLs (Domain Specific Language) in Ruby. It’s used in RSpec, the Statemachine Gem, and Unclebob’s Clean Code talk at RailsConf 2007. I haven’t seen a name for this pattern so I’ll call it the DSL Block Pattern.

RSpec

describe "Bowling Game" do
    it "should score 0 on a gutter game" do
        game = Game.new
        20.times { game.roll(0) }
        game.score.should eql(0)
    end
end

Statemachine

sm = Statemachine.build do
    trans :locked, :coin, :unlocked
    trans :locked, :pass, :locked
    trans :unlocked, :pass, :locked
    trans :unlocked, :coin, :unlocked
end

Parser

parser = Args.expect do
    boolean "l"
    number "p"
    string "d"
end

Here’s the problem. You’ve got to write code for specific domain such as writing specifications (RSpec), defining a Statemachine, or defining command line arguments (Unclebob’s Clean Code talk). These domains have a contained and well defined terminology set. Often the cleanest, most elegant way to express this code is to create a DSL.

Before diving into the example, let me say that I like coffee as much as the next guy. But I feel lost when ever I go to a Starbucks. As you know, Starbucks has a it’s own language, DSL if you will, for ordering coffee. What follows is a DSL Block for ordering Starbucks coffee.

The general grammar for ordering coffee is: Size, Adjective (optional), Type of Coffee. This is by no means comprehensive but it’s sufficient for the example. So if you wanted to order a large coffee, for example, you would say, Grande Coffee. A small espresso: Short Americano. An extra large mixture of regular and decaffeinated coffee with some half and half: Venti Breve Half Caff.

Given the task to code these coffee orders, I’d like to be able to code it like this:

 Starbucks.order do
    grande.coffee
    short.americano
    venti.breve.half_caff
end

Ok that looks good, but as you look closely, you’ll start to wonder about those methods, grande, short, and venti “Do they have to be defined on the Kernel?” you may ask. Defining them on the Kernel is a scary prospect. And that may convince you to clutter the syntax by passing an object into the block like this:

Starbucks.order do |order|
    order.grande.coffee
    order.short.americano
    order.venti.breve.half_caff
end

This would allow you to define the grande, short, and venti methods on the object passed into the block. Although you do need an object where grande, short, and venti will be defined, you don’t need to add an argument to the block. You’ll find code out there, such as Migrations, that uses this less optimal route. It’s not necessary. The trick to get rid of the argument is below:

module Starbucks

  def self.order(&block)
    order = Order.new
    order.instance_eval(&block)
    return order.drinks
  end

  class Order

    attr_reader :drinks

    def initialize
      @drinks = []
    end

    def short
      @size = "small"
      return self
    end

    def grande
      @size = "large"
      return self
    end

    def venti
      @size = "extra large"
      return self
    end

    def coffee
      @drink = "coffee"
      build_drink
    end

    def half_caff
      @drink = "regular and decaffeinated coffee mixed together"
      build_drink
    end

    def americano
      @drink = "espresso"
      build_drink
    end

    def breve
      @adjective = "with half and half"
      return self
    end

    private

    def build_drink
      drink = "#{@size} cup of #{@drink}"
      drink << " #{@adjective}" if @adjective
      @drinks << drink

      @size = @drink = @adjective = nil
    end
  end

end

You can see that the Order object is doing all the work. It’s got the responsibility of interpreting the DSL, so let’s call it the Interpreter Object. The Module::order method simply creates an instance of Order and calls istance_eval on it. This causes the block to execute using the binding of the Order instance. All of the methods on Order will be accessible to the block.

The Interpreter Object can do any number of things as it interprets the DSL. In this case it simply generates a translation for Starbucks newbies. But, the sky’s the limit really.

Show all the source code.


    module Starbucks

      def self.order(&block)
        order = Order.new
        order.instance_eval(&block)
        return order.drinks
      end

      class Order

        attr_reader :drinks

        def initialize
          @drinks = []
        end

        def short
          @size = "small"
          return self
        end

        def tall
          @size = "medium"
          return self
        end

        def grande
          @size = "large"
          return self
        end

        def venti
          @size = "extra large"
          return self
        end

        def coffee
          @drink = "coffee"
          build_drink
        end

        def decaf
          @drink = "decaffeinated coffee"
          build_drink
        end

        def half_caff
          @drink = "regular and decaffeinated coffee mixed together"
          build_drink
        end

        def americano
          @drink = "espresso"
          build_drink
        end

        def mocha
          @drink = "espresso mixed with chocolate, milk, and topped with whipped cream"
          build_drink
        end

        def cappuchino
          @drink = "espresso mixed with milk and topped with steamed milk"
          build_drink
        end

        def no_whip
          @adjective = "without the whipped cream"
          return self
        end

        def non_fat
          @adjective = "with non-fat milk"
          return self
        end

        def breve
          @adjective = "with half and half"
          return self
        end

        def extra_shot
          @adjective = "with an extra shot of espresso"
          return self
        end

        def soy
          @adjective = "with soy milk"
          return self
        end

        def extra_hot
          @adjective = "with super heated milk"
          return self
        end


        private

        def build_drink
          drink = "#{@size} cup of #{@drink}"
          drink << " #{@adjective}" if @adjective
          @drinks << drink

          @size = @drink = @adjective = nil
        end
      end

    end

    require File.expand_path(File.dirname(__FILE__) + "/starbucks")

    #### Specs ####

    describe "Starbucks" do

      it "should handle empty orders" do
        Starbucks.order {}.should eql([])
      end

      it "should handle regular coffee with all the sizes" do
        Starbucks.order do
          short.coffee
          tall.coffee
          grande.coffee
          venti.coffee
        end.should eql(["small cup of coffee",
                        "medium cup of coffee",
                        "large cup of coffee",
                        "extra large cup of coffee"])
      end


      it "should deal with types of drinks" do
        Starbucks.order do
          short.decaf
          short.half_caff
          short.americano
          short.mocha
          short.cappuchino
        end.should eql(["small cup of decaffeinated coffee",
                        "small cup of regular and decaffeinated coffee mixed together",
                        "small cup of espresso",
                        "small cup of espresso mixed with chocolate, milk, and topped with whipped cream",
                        "small cup of espresso mixed with milk and topped with steamed milk"])
      end

      it "should handle the adjectives" do
        Starbucks.order do
          short.no_whip.coffee
          short.non_fat.coffee
          short.breve.coffee
          short.extra_shot.coffee
          short.soy.coffee
          short.extra_hot.coffee
        end.should eql(["small cup of coffee without the whipped cream",
                        "small cup of coffee with non-fat milk",
                        "small cup of coffee with half and half",
                        "small cup of coffee with an extra shot of espresso",
                        "small cup of coffee with soy milk",
                        "small cup of coffee with super heated milk",])
      end

    end

Chirb Statemachine Talk

Micah — Tue, 08 May 2007 07:28:00 +0000

Last night I presented the Ruby Statemachine Gem to the Chicago Ruby Users Group (Chirb) Below are links to download the slides and coding example used.

Finite State Machines and the Statemachine Ruby Gem (Slides):

statemachines_chirb0407.pdf

Statemachine Exercises:

Understanding Statemachines, Part 4: Superstates

Micah — Sat, 07 Apr 2007 21:19:00 +0000

Superstates

Often in statemachines, duplication can arise. For example, the vending machine in our examples may need periodic repairs. It’s not certain which state the vending machine will be in when the repair man arrives. So all states should have a transition into the Repair Mode state.

Diagram 1 - Without Superstates

In this diagram, both the Waiting and Paid states have a transition to the Repair Mode invoked by the repair event. Duplication! We can dry this up by using the Superstate construct. See below:

Diagram 2 - With Superstates

Here we introduce the Operational superstate. Both the Waiting and Paid states are contained within the superstate which implies that they inherit all of the superstate’s transitions. That means we only need one transition into the Repair Mode state from the Operational superstate to achieve the same behavior as the solution in diagram 1.

One statemachine may have multiple superstates. And every superstate may contain other superstates. ie. Superstates can be nested.

History State

The solution in diagram 2 has an advantage over diagram 1. In diagram 1, once the repair man is done he triggers the operate event and the vending machine transitions into the Waiting event. This is unfortunate. Even if the vending machine was in the Paid state before the repair man came along, it will be in the Waiting state after he leaves. Shouldn’t it go back into the Paid state?

Superstates come with the history state which solves this problem. Every superstate will remember which state it is in before the superstate is exited. This memory is stored in a pseudo state called the history state. Transitions that end in the history state will recall the last active state of the superstate and enter it.

You can see the history state being use in diagram 2. In this solution, the history state allows the vending machine to return from a repair session into the same state it was in before, as though nothing happened at all.

Code

The following code builds the statemachine in diagram 2. Watch out for the _H. This is how the history state is denoted. If you have a superstate named foo, then it’s history state will be named foo_H.

require 'rubygems'
require 'statemachine'

vending_machine = Statemachine.build do
  superstate :operational do
    trans :waiting, :dollar, :paid
    trans :paid, :selection, :waiting
    trans :waiting, :selection, :waiting
    trans :paid, :dollar, :paid

    event :repair, :repair_mode,  Proc.new { puts "Entering Repair Mode" }
  end

  trans :repair_mode, :operate, :operational_H, Proc.new { puts "Exiting Repair Mode" }

  on_entry_of :waiting, Proc.new { puts "Entering Waiting State" }
  on_entry_of :paid, Proc.new { puts "Entering Paid State" }
end

vending_machine.repair
vending_machine.operate
vending_machine.dollar
vending_machine.repair
vending_machine.operate

Output:

Entering Repair Mode
Exiting Repair Mode
Entering Waiting State
Entering Paid State
Entering Repair Mode
Exiting Repair Mode
Entering Paid State

Next we should cover pseudo states.

Storing Binary Data in Postgres? Beware!

Micah — Sun, 18 Feb 2007 06:05:00 +0000

If your situation matches the following conditions, beware!

You’re working in rails.
You’re using Postgresql.
You’re storing binary data in the database.

This was the situation on a project of mine. We were storing PDFs and PNG images in our Postgrs database. Everything was fine during development and testing where we used files that ranged up to a few dozen kilobytes in size. The situation went rapidly downhill when file sizes got up in the hundreds of kilobytes to megabytes. The worst part about it was that the errors we got were misleading and seemingly random. They included:

undefined method `<<' for nil:NilClass
invalid end of buffer
undefined class/module Packet (Packet being a model class which was definitely defined)

These errors sent us on a wile goose chase. The clue that finally pointed us toward the problem was the fact that it took 6 seconds to load a 4M PDF document from the database. That was far too long especially considering the same document could be loaded from a file instantaneously.

Apparently, binary data stored in Postgresql’s bytea data type has to be parsed on save and load to escape and unescape certain characters. Unfortunately the native C postgres gem doesn’t do the parsing. It’s done in the PostgreSQLAdapter.unescape_bytea and PostgreSQLAdapter.escape_bytea methods (Ruby code) of ActiveRecord and the parsing is a bit too intensive for Ruby. This is where the meltdown begins. It consumes too much memory, or too much processing power, or … well I don’t know exactly. But I know it breaks.

We refactored our model such that all the binary data gets stored in flat files on disk rather than in the database. After this, our Rails app came back to life. It was MUCH faster too!

Here’s hoping that if and when you encounter this problem, Google points you to this blog entry and you find it helpful.

Understanding Statemachines, Part 3: Conditional Logic

Micah — Tue, 13 Feb 2007 03:34:00 +0000

Conditions

If you’re doing any significant amount of work with statmachines, you will most certainly encounter some conditional logic in your statemachines. Take our vending machine. When ever a coin is inserted, the invoked event will depend on whether the total amount of money inserted is sufficient to buy something. If enough money has been tendered, the display should suggest that the customer make a selection. If insufficient money has been inserted, the customer should be prompted to insert more.

Conditional logic can be accomplished by using entry actions. See the diagram below.

State Diagram with Conditional Logic

Starting in the Accept Money state, when a coin is inserted, the coin event is fired and the statemachine transitions into the Coin Inserted state. This is where it gets fun. Upon entering of the Coin Inserted state its entry event is invoked: count_amount_tendered. This method will count the money and invoke the not_paid_yet or paid event accordingly. This will cause the statemachine to transition into the appropriate state.

The Coin Inserted state is unique. You wouldn’t expect to find the statemachine in the Coin Inserted state for any reason except to make this decision. Once the decision is made, the state changes. States like this are called Decision States.

Code

require 'rubygems'
require 'statemachine'

class VendingMachineContext

  attr_accessor :statemachine

  def initialize
    @amount_tendered = 0
  end

  def add_coin
    @amount_tendered = @amount_tendered + 25
  end

  def count_amount_tendered
    if @amount_tendered >= 100
      @statemachine.paid
    else
      @statemachine.not_paid_yet
    end
  end

  def prompt_money
    puts "$.#{@amount_tendered}: more money please"
  end

  def prompt_selection
    puts "please make a selection"
  end
end

vending_machine = Statemachine.build do
  trans :accept_money, :coin, :coin_inserted, :add_coin
  state :coin_inserted do
    event :not_paid_yet, :accept_money, :prompt_money
    event :paid, :await_selection, :prompt_selection
    on_entry :count_amount_tendered
  end
  context VendingMachineContext.new
end
vending_machine.context.statemachine = vending_machine

vending_machine.coin
vending_machine.coin
vending_machine.coin
vending_machine.coin

Output:

$.25: more money please
$.50: more money please
$.75: more money please
please make a selection

Next lesson: Superstates
Understanding Statemachines, Part 4: Superstates

Clean as You Code

Micah — Mon, 29 Jan 2007 13:43:00 +0000

In my younger days I was a Line Cook at the Olive Garden. In case you’ve never worked in the food industry, Line Cooks are the guys putting meals together as fast as customers order them. At times, it’s nearly impossible to keep up.

Among the most fundamental of the Line Cook’s principles was Clean as you go. I can remember clearly the manager walking regally down the line chanting, “Clean as you go Javier. Clean as you go Micah. Clean as you go Brian.” Cooks would remind each other from time to time too, “Clean as you go!”.

As you’re realizing, it’s import to keep your station clean when you’re a cook. Keeping things clean is not easy. Food gets EVERYWHERE when you’re putting together hundreds of meals an hour. Why is it important to keep it clean? Simple. When your station is dirty, the system breaks down and it slows you down. Utensils are dirty or missing, ingredients get mixed together, cooking surfaces are soiled… Combine this with all the fire, boiling water, and sharp knives, it’s dangerous too! Worse, other cooks are not able to help out. Uncleanliness on the line is a vicious cycle with positive feedback. Every experienced cook keeps their station spotless at all times and unexperienced cooks learn fast.

Dirtiness is a sign of trouble too. Let’s say that it’s the middle of a dinner rush. You look down the line and notice that Javier’s station is becoming cluttered. It’s near certainty that in five minutes Javier’s system will break down. Food will be burnt, orders will get lost, and servers will get vocal. Don’t get servers mad! Line Cooks work as a team though. So when you see that Javier’s station is getting cluttered, you jump over and give Javier a hand every moment you can spare.

This principle, “Clean as you go”, is well applied to software, “Clean as you code”. The analogy is fairly straight forward. Although I’ve applied the principle to software for years, it was only recently that I recalled the mantra “Clean as you go”. I’m sure my teammates will soon grow tired of hearing me chant… “Clean as you code!”