8th Light Blog

Welcome to a Limelight production. I am going to go through a step by step introduction to limelight development using a tic tac toe game as an example. So, lets get started. I am going to create the directory structure and open it up in a text editor.

$ mkdir tictactoe
$ cd tictactoe
$ mate .

Now I need to set up Limelight. You can just download the gem.

$ jruby -S gem install limelight

We can start by creating the props.rb file in the tictactoe directory. The props.rb file defines the structure of your application. A prop is named after the theatre metaphor. We are going to use them to define what our scene’s physical structure look like. We can start with a simple screen with an empty board with the nine cells we need for a tic tac toe game. Lets create a spec directory to write a test for the props we are going to create.

$ mkdir spec
$ mkdir spec/props

Now for the spec. In the spec directory, we can name our spec props_spec.rb. We want to check that there is a cell on the scene. Here is the first test. NOTE: To be able to run the test, you will need the spec_helper.rb in your spec directory (not the props directory). You can copy it from the sample application.

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

describe "Props" do
  include PropSpecHelper
  before(:each) do 
    setup_prop_test
  end

  it "should have cell_0_0" do
    @scene.find("cell_0_0").should_not be(nil)
  end
end

and when we run it (You can copy the Rakefile from the sample application as well, if you want to have a specs task),

$ jruby -S rake spec

we get the failure

1)
Errno::ENOENT in 'Props should have cell_0_0'
No such file or directory - File not found - /Users/paulwpagel/Desktop/tictactoe/props.rb
/Users/paulwpagel/Desktop/tictactoe/spec/spec_helper.rb:18:in `initialize'
/Users/paulwpagel/Desktop/tictactoe/spec/spec_helper.rb:18:in `setup_prop_test'
/Users/paulwpagel/Desktop/tictactoe/./spec/props/props_spec.rb:6:

Finished in 0.063 seconds

1 example, 1 failure

So, lets create the props.rb file in the project root. Now we should get the error.

1)
'Props should have cell_0_0' FAILED
expected not nil, got nil
/Users/paulwpagel/Projects/tictac/./spec/props/prop_spec.rb:12:

Finished in 0.089 seconds

1 example, 1 failure

Each of the props accepts a block of code your can give options/structure to. We can open the props.rb file and add a cell with the id of “cell_0_0” to make this test pass.

main do
    board do
        cell :id => "cell00"
    end
end

And the test passes. Lets make sure we have the rest of the id’s while we are at it. Here is a more exhaustive spec.

it "should have cells" do
  @scene.find("cell00").should_not be(nil)
  @scene.find("cell01").should_not be(nil)
  @scene.find("cell02").should_not be(nil)
  @scene.find("cell10").should_not be(nil)
  @scene.find("cell11").should_not be(nil)
  @scene.find("cell12").should_not be(nil)
  @scene.find("cell20").should_not be(nil)
  @scene.find("cell21").should_not be(nil)
  @scene.find("cell22").should_not be(nil)
end

And it fails in a similar manner. Lets expand our props.rb file to make the test pass.

main do
  board do
    cell :id => "cell00"
    cell :id => "cell01"
    cell :id => "cell02"
    cell :id => "cell10"
    cell :id => "cell11"
    cell :id => "cell12"
    cell :id => "cell20"
    cell :id => "cell21"
    cell :id => "cell22"
  end
end

And it passes. However, it is all ruby code, so I can leverage ruby functions to help me out. Lets remove the duplication.

main do
    board do
        3.times do |row|
          3.times do |col|
            cell :id => "cell#{row}#{col}"
          end
        end
    end
end

Much better. Lets now move on to the styles. Nothing will show up without a few styles. I create a styles.rb file in the project root and filled it with some simple content. In Limelight, styles refer to how a prop is aesthetically displayed on the screen. Here is an example which defines the size and gives a border to the board and the cells.

board {
  width 152
  height 152
  border_width 1
  border_color "black"
}
cell {
  width 50
  height 50
  border_width 1
  border_color "black"
}

We should be able to start up Limelight and see the board. We start Limelight like: (From the tictacctoe directory)

$ jruby -S limelight open .

and there is your first Limelight screen. Pretty easy, and all ruby code. Lets make it more interesting. Let us make it such that if you click on one of the squares, the square shows the ‘X’ mark denoting the first move.

First we create a directory called players. Inside go the players, which contain the actions and behavior of the props for a Limelight scene (the controllers).

$ mkdir players

We want to now make a player for the cell prop. We create a file inside of the players directory called cell.rb. The file will start with a definition by looking like:

module Cell


end

We define all players in modules of the same name as the file and prop, by convention. This allows Limelight to include this behavior when it needs it. You can specify specific mappings between the props and its players, but we don’t need to do that here. So, let’s make the cell more interesting. When we click on the cell, we want it to make a large ‘X’ mark. Lets start by creating a spec for the behavior.

I created a new directory for the players spec

$ mkdir spec/players

We have to add the players directory to the ruby search path, so I added the following line to the spec_helper.

$: << File.expand_path(File.dirname(FILE) + "/../players")

My spec is going to find the prop that was clicked on and make that prop display an ‘X’, denoting the first move. Here is what my first spec looks like (I call it cell_spec.rb):

require File.expandpath(File.dirname(FILE) + "/../spechelper")
require 'cell'


describe Cell do
  include Cell
  attr_accessor :id

it "should make first move an X" do
    @id = "cell00"
    @cell_one = Limelight::Prop.new
    @scene = MockScene.new
    @scene.register("cell00", @cell_one)
    self.stub!(:scene).and_return(@scene)
    mouse_clicked(nil)
    @cell_one.text.should == "X"
  end
end

Which provides the feedback when run:

F

1)
NoMethodError in 'Cell should make first move an X'
undefined method `mouse_clicked' for #
/Users/paulwpagel/Projects/tictac/spec/players/cell_spec.rb:14:

Finished in 0.007423 seconds

1 example, 1 failure

If you have seen a rSpec specification before, this should look syntactically familiar. Before we move on to making the test pass, let us take closer look at a few aspects.

@id = “cell_1_1” - This line is setting the id of the imaginary prop that the players behavior will be executed against. @scene = MockScene.new - This creates a scene to mock out. The scene will be explained later, but for this test we are going to use the find method on scene to find our props. @cell_one = MockProp.new - Create a mock prop that will turn to ‘X’ when clicked @scene.register(“cell_1_1”, @cell_one) - We are giving the scene the mock prop, so the find method will find it by its id. mouse_clicked(nil) - Simulates a mouse_click on the cell. It takes an event, but we don’t care about that yet, so lets just pass in nil.

All right, time to make this test pass. Lets open up the cell.rb player and see what we need done to make the test pass.

module Cell
  def mouse_clicked(event)
    cell_prop = scene.find(id)
    cell_prop.text = "X"
  end
end

Run the test again, no failures. We needed to find the prop on the screen which we are concerned about. We do this by calling find on a method scene, which will give us any prop by its unique identifier. We are looking for the id of the element we clicked, and then we set the text of that element to ‘X’, which makes the test satisfied.

Now, we can run the application from the root directory.

$ jruby -S limelight open . 

If we click on the box that is displayed, a small ‘X’ should appear in the upper right corner.

Congratulations, that is your first piece of Limelight behavior. However, this is not very interesting yet. Lets take it the next step and make the tic tac toe game work. I am going to create a lib directory to hold the game model.

$ mkdir lib
$ mkdir spec/lib

And before I write my first spec, I am going to add the new lib directory to the ruby search path by adding the following line to the spec_helper (It is already in the example spec_helper.rb, you don’t need to add it).

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

So, here is what my first spec looks like:

require File.expandpath(File.dirname(FILE) + "/../spechelper")

require 'game'

describe Game do
  it "make a move in the middle square" do
    game = Game.new
    game.move(1, 1)
    game.mark_at(1, 1).should == "X"
  end
end

To make it pass, we need to create a game class in the lib directory and give it this code.

class Game
  def move(row, column)
  end


def mark_at(row, column)
    return "X"
  end
end

And we can follow the test driving of the model to make the game class. I have already done this, and you can download the models in the sample application. Lets move past that back to the players and hook up the game.

I am going to create a file init.rb in the root directory. The init.rb class gets loaded up by Limelight when you start the application. We want to create a new game and have a way to keep it in memory for the other classes to use. Here is what the spec looks like in a init_spec.rb in the spec directory:

require File.expandpath(File.dirname(FILE) + "/spechelper")
require "game"


describe "init" do
  it "should create new game on initialization" do
    game = mock('game')
    Game.shouldreceive(:new).andreturn(game)
    Game.should_receive(:current=).with(game)

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


end
end

The simplest way to start that is to have a current_game class variable. Here is the code for the init.rb.

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


require "game"
Game.current = Game.new

I add the lib directory to the ruby search path so the Limelight application would know what a game is when I require it.

Now we need to plug the game model into the cell player. Lets change the spec we made earlier to make the first move depending on the game model. Here is the new version.

it "should make first move in a game" do
  @id = "cell00"
  @cell_one = Limelight::Prop.new
  @scene = MockScene.new
  @scene.register("cell00", @cell_one)
  self.stub!(:scene).and_return(@scene)


game = mock('game')
  Game.shouldreceive(:current).andreturn(game)
  game.should_receive(:move).with(0, 0)
  game.shouldreceive(:mark).andreturn("X")

mouse_clicked(nil)

@cell_one.text.should == "X"
end

I am mocking out the game model and passing the values from the id into the game’s move method. Here is the code that makes this pass.

module Cell

  def mouse_clicked( event)


game = Game.current
x, y = get_coordinates
game.move(x, y)
cell_prop = scene.find(id)
cell_prop.text = game.mark


end

private ################################

def get_coordinates()
    x = id[(id.length - 1)..(id.length - 1)].to_i
    y = id[(id.length - 3)..(id.length - 3)].to_i
    return x, y
  end 

end

Minus the ugly string manipulation, it is a pretty straight forward approach. Now we should be able to start up the application and click on any of the squares and make some moves. There are 2 things left to do for this demo. We need to make sure that a player can not move on a square that is already occupied, and we need to display a winner. So for the first task, we need to write a spec to have some kind of feedback to the players that the move is invalid. Let’s add this spec to the props_spec file.

it "should have message center for feedback to the user" do
  @scene.find("messagecenter").shouldnot be(nil)
end

Nice and simple. Here is the new props.rb file.

main do
  board do
    3.times do |row|
      3.times do |col|
        cell :id => "cell#{row}#{col}"
      end
    end
  end

end


messagecenter :id => "messagecenter"

Now lets write a spec for the cell_spec to make sure that the move is valid, else we display a message in the message center to the user they must move somewhere else. Here is the spec.

it "should display in the message center if the space is occupied." do
  @id = "cell00"
  @cell_one = Limelight::Prop.new
  @message_center = Limelight::Prop.new
  @scene = MockScene.new
  @scene.register("cell00", @cell_one)
  @scene.register("messagecenter", @messagecenter)
  self.stub!(:scene).and_return(@scene)


game = mock('game')
  Game.shouldreceive(:occupied?).with(0, 0).andreturn(true)

mouse_clicked(nil)

@message_center.text.should == "This space is occupied, please move in an unoccupied square"
end

Same as before, with a new prop added. Here is the new cell.rb file.

module Cell


def mouse_clicked( event)
    game = Game.current
    x, y = get_coordinates
    if game.occupied?(x, y)
      messagecenter = scene.find("messagecenter")
      message_center.text = "This space is occupied, please move in an unoccupied square"
    else 
      game.move(x, y)
      cell_prop = scene.find(id)
      cell_prop.text = game.mark
    end
  end

private ################################

def get_coordinates()
    x = id[(id.length - 1)..(id.length - 1)].to_i
    y = id[(id.length - 3)..(id.length - 3)].to_i
    return x, y
  end 

end

Simple if, makes it all work. Lets remove the duplication in the specs. Here is the new spec file.

require File.expandpath(File.dirname(FILE) + "/../spechelper")
require 'cell'


describe Cell do
  include Cell
  attr_accessor :id

before(:each) do
    @id = "cell00"
    @cell_one = Limelight::Prop.new
    @scene = MockScene.new
    @message_center = Limelight::Prop.new
    @scene.register("messagecenter", @messagecenter)
    @scene.register("cell00", @cell_one)

self.stub!(:scene).and_return(@scene)
@game = mock('game', :occupied? => false) 
Game.should_receive(:current).and_return(@game)


end

it “should make first move in a game” do
    @game.should_receive(:move).with(0, 0)
    @game.shouldreceive(:mark).andreturn(“X”)

mouse_clicked(nil)

@cell_one.text.should == "X"


end

it “should display in the message center if the space is occupied.” do
    @game.shouldreceive(:occupied?).with(0, 0).andreturn(true)

mouse_clicked(nil)

@message_center.text.should == "This space is occupied, please move in an unoccupied square"


end

end

Much better. Now lets do the case of a winner. Here is the spec for the cell.

it "should display there was a winner in the message center" do
  @game.should_receive(:move).with(0, 0)
  @game.shouldreceive(:iswinner?).and_return(true)


mouse_clicked(nil)

@message_center.text.should == "Player X has won the game, congratulations"
end

And here is the new cell.rb

module Cell


def mouse_clicked( event)
    game = Game.current
    x, y = get_coordinates
    if game.occupied?(x, y)
      message_center.text = "This space is occupied, please move in an unoccupied square"
    else 
      game.move(x, y)
      cell_prop = scene.find(id)
      cell_prop.text = game.mark
      messagecenter.text = "Player #{game.mark} has won the game, congratulations" if game.iswinner?

end


end

private ################################

def get_coordinates()
    x = id[(id.length - 1)..(id.length - 1)].to_i
    y = id[(id.length - 3)..(id.length - 3)].to_i
    return x, y
  end 

def message_center
    return scene.find(“message_center”)
  end

end

Now we can finish off the application by adding new game functionality, or even a computer player that can not be beaten! However, before I let you go, we have to add some styles to the message center and pretty up the board to make it look better. To find a comprehensive list of the styles supported in Limelight, go here(http://limelightwiki.8thlight.com/index.php/Style_Attributes). Here is a new version of the styles.rb.

main {
  width "100%"
  horizontal_alignment "center"
}
board {


width 152
  height 152
  border_width 1
    border_color "black"
}
cell {
  width 50
  height 50
  border_width 1
    border_color "black"
}
messagecentercontainer{
  top_margin 100
  width "100%"
  horizontal_alignment "center"
}
message_center {
  width 300
  height 100
  roundedcornerradius "10"
  border_color "black"

  border_width 2
  padding 5

}

There was one change to the props.rb file, to wrap the message_center in a prop called message_center_container. Also, notice the pretty rounded corners. Easy to do.

Here is the props.rb

main do


board do
    3.times do |row|
      3.times do |col|
        cell :id => "cell#{row}#{col}"
      end
    end
  end
end

messagecentercontainer do
  messagecenter :id => "messagecenter"
end

Happy Limelight coding!

At 8th Light, they follow a practice of training people through an apprenticeship period. As it is nearing the end of my apprenticeship, my mentor has asked me to write a blog talking about one thing I have learned during the course of my apprenticeship. For me, the one skill that I learned the most about was the one skill that needed the most work in the first place. The main thing I learned was that I was writing software for others. Similar to that idea came the need for increased customer interaction and learning how to interact with people in general.

Prior to working at 8th Light, almost all the programming I had ever done was either for myself, or for school projects. In the first case, I was my own user, so there was never any issue in communication there. And for the second case, the requirements were almost always very clearly drawn out(and not likely to change). Again, not much room for error. Once I came to 8th Light, I was forced to write code both specified and to be used by someone that was not myself. This was something new to deal with. For at least the first month or so, my thought process was for myself. It wasn’t until I came to that realization that I was able to change my thought process. There was not one single event that made me learn this, but it was something learned over time. When starting a story, once the requirements have been approved, I don’t try to change the story. Even if I don’t agree with the desired functionality, it is what the customer wanted, and that’s all that matters. And now, when I finish a story, I take the time review the requirements and make sure it completes all the requirements that the customer specified.

In order to provide a high quality product for another person, you must maintain a high level of collaboration with them. Without talking to them, you will never be able to guess what they want. So, in going along with the first lesson, I also learned that a lot of customer interaction is important and any issues that arise should be addressed quickly. One event in particular occurred that helped me realize this was the week leading up to one of our releases. It was around this point that the customer decided to begin some testing of the system and uncovered a number of bugs. There was some concern as to whether or not all the bugs were being kept track of in some way, and this added stress to both the development team and the customer. It wasn’t the bugs that taught me anything, but the manner in which Micah handled them. After our iteration meeting, he called attention to the problem. He didn’t blame anybody, but just said that something needed to be done to fix the problem and even proposed some possible solutions. It was the high level of communication between the development team and the customers that was valuable to me. This made me realize that you have to address problems quickly, and it helps to offer multiple solutions to a problem. The customer also seemed to appreciate that we brought the issue up, and partly because of this week of bugs, we introduced a new bug tracking tool to our process.

I also began to learn that if you have a question about how something is supposed to work, sometimes the best solution is to just ask the customer. At one of our recent iteration meetings, the customer mentioned functionality that they expected to be in a completed story that had never been discussed. We realized that there was not enough feedback gained from the requirements, so we altered our process to account for that. Now, after determining the requirements, we bring them to the customer and discuss them in person. This is something we just began, but it already has shown signs of success. The customer has actually come to us to discuss the requirements for some of the stories. It is because our team values communication that we were able to improve our process.

Learning these things has already helped me work more productively. If I have a question, instead of trying to spend too much time reasoning it out my own, it can be much faster to either go to the requirements or directly to the customer. During the course of my apprenticeship, I also learned a lot about coding but nothing was as important as what I learned about human interaction. This is a lesson that has definitely changed my mentality towards coding and will hopefully improve my skills as a professional software craftsman.

Craftsman Clarification

There has been some discrepancy in the use of the term “software craftsman”. Rather than going into details about various uses of the term, I’ll just clarify what I believe it means.

software craftsman n. A man who practices the software craft.

There are a few points to make about this definition.

1. “software craft”

A craftsman believes that software is a craft. This is important because not everyone believes this. A craftsman takes pride in his work an strives to do the best job he can. He believes that writing good software requires skill and careful attention. That software is not something that can be manufactured nor can it be delivered faster by merely adding more bodies.

2. “practices”

A craftsman practices his craft, always striving to become more skillful, to produce better software.

There are traditionally 3 stages of craftsmanship:

1. Apprentice
2. Journeyman
3. Master

No matter which stage one may be in, as long as he practices software as a craft, he is a craftsman.

3. “A man”

Technically the term “craftsman” is gender specific. Women are just as capable of software craftsmanship. Indeed, I’d like to see more software craftswomen out there. In an effort not to alienate anyone we should use the term “software craftsperson” more liberally.

Update: There’s a movement afoot to make the term “software craftsman” gender neutral. Feel free to comment below.

I’ve checked with the book “Software Craftsmanship” by Pete McBreen to see if it conflicts with my definition. Although, he uses the term “software craftsman” ambiguously at times, he is careful to use the term “master craftsman” when referring to craftsmen at the height of his craft. This is in line with my definition.

I hope this serves as a reference for my use of the term. People should not think me presumptuous when I call myself or my colleagues craftsmen. I mean only what I describe above.