jamesladdcode.com

I like Assembly language. Assembly is clean and simple and fast, although verbose. I like Ruby’s interactive command line (IRB). Ruby’s interactive command line is quick to start and easy to use to test snippets of code. So what about having both of these, that is RASMATAZ, an Assembler written in Ruby that you can interact with via IRB or just execute from the command line. The biggest win is not having to re-start you machine when the instructions go off and give the operating system conniptions.

This is an example of the assembly you can execute with RASMATAZ:

mov rax, [rdx]
label :spin
push rax
pop rcx
dec rcx
jnz :spin

The assembly loosely follows the Intel syntax and you can see the full instructions and add your own in the file ‘machine.rb’.

You can interact with RASMATAZ using IRB by starting IRB and issuing a load to load your program, for example:

> load 'example.rasm', nil

For here you can interact with your program using one of the following commands:

• registers
  dumps the current values of the registers, for example
  >registers
  => {:rax=>0, :rbx=>0, :rcx=>0, :rdx=>0, :rsi=>0, :rdi=>0, :rbp=>0, :rip=>0, :rsp=>0}
• stack
  dumps the current value on the stack, for example
  => []
• memory
  dumps the current values in memory, for example
  => [#<RASMATAZ::Instruction:0×00000002924af8 @pointer=0, @mnemonic=:label, @arg1=:start>, …
• step
  steps forward by executing a single instruction. For example
  #<RASMATAZ::Instruction:0×00000001c97308 @pointer=0, @mnemonic=:label, @arg1=:start>
  => 1
• go
  executes from current instruction until the program ends.

RASMATAZ is written entirely in Ruby with the assembly instructions being a DSL, the machine, stack, memory and registers are all Ruby objects. The DSL is defined in the file rasmataz/dsl.rb and the instructions and the virtual machine they execute against are defined in the file rasmataz/machine.rb.

RASMATAZ is an experiment of mine to see how far I could go with an assembler with out of the box Ruby. It is at the proof of concept stage but available to anyone to fork and continue if they wanted to. I’ll be coming back to RASMATAZ at a future point to develop of prototype for a new type of virtual machine that is not based around executing instructions like traditional virtual machines.

The source for RASMATAZ is here on github.

When a Team starts on a piece of work they implicitly know the goal is to get the job done as efficiently as possible. There are probably other goals that are not verbalised and therefore not implicitly in the minds of the Team and this is a big problem, big enough to destroy the Team and significantly hamper getting the job done. A shared understanding of the goals of the Team helps focus decisions as each decision can be related to how it helps accomplish the goals. Without established goals decisions making can break down into a battle of wills which is extremely costly in multiple ways (this is covered in the book ‘Getting to Yes’ which I blogged about here. The goals of the Team are not just the Company goals they are also Team members personal goals like ‘I want to learn technology X’ or ‘I think the design should be Y’. These personal goals are rarely explicit bubbling along just below the surface with a building current that can derail a project.

Explicit and honest goals can help a Team focus and make decisions quickly and in a manner that feels more cohesive and transparent rather than driven by the loudest person, biggest personality or <insert sterotype here>. What follows is a proposed technique for making the goals of the Team explicit and prioritised to enable a Team to move forward efficiently with a transparent mechanism for making decisions quickly, reducing personal conflict and focusing the Team on getting the job done. After all, getting the job done is always the number one goal.

A Goal Pyramid is a hierarchy of ten (10) Goals starting with one at the top, two on the next row, three on the next and so on to form a Pyramid. It is suggested that the Goal Pyramid be kept to ten (10) goals. The first and highest priority goal is the core Business goal, “to get the job done as efficiently as possible”. If this isn’t the Goal at your Company then you should change the first and highest priority goal to that. This top goal is not a negotiable goal like the rest that make up the pyramid. To find and fill out the other goals you need the team to list all the goals they can think of and then prioritize them into the top nine (9). These top nine (9) goals will make up the rest of the pyramid from left to right, top to bottom starting on row two. The goals on row two have a higher importance than those on row three etc. A pyramid is used rather than a list or another shape as it allows the number one (1) goal to be clear while allowing the remaining goals to share in importance on each row, and have priority over those on lower rows.

The list of goals to prioritize should be succinct and clear to each team member so they know what they will be voting for to form their top nine (9). Each goal should have a title, a description and a “because when we don’t …” section which lists the impact/remifications of not focusing on the goal back to the number one (1) goal. For example, “Goal: Clean Code. Description: We should follow the principles set out in the book Clean Code. Because: When we don’t the code base becomes harder to work with slowing our ability to ‘<number 1 goal here>’”. In arranging your pyramid graphically I suggest putting the ‘Goal:’ in the Pyramid and having a legend under it to elaborate on the ‘Goal:’. However, nothing should stop you from having all this information in each pyramid segment if you wish.

A difficulty and thing to watch out for in forming the pyramid is getting the team members to be open, honest and transparent in why the goal matters. For example, a goal of “Keep Simple” looks fine until you dig deeper and draw out the fear behind this goal which might be a fear of meeting the deadline or a fear of a design that is not fully understood. ie: I want to keep the design simple because I don’t understand your proposed design. This particular example draws out a different issue, that of information sharing / knowledge transfer to understand a design more. This is an intended side effect of forming the Goal Pyramid. Encourage your team to think hard about the goals and to be as honest and fearless in presenting them to be voted upon. Wanting to use a particular tool or approach is a fine goal and it needs to be related back to the number one goal, made known and prioritised with the team. Letting the who team in on a goal means we can all work together towards multiple goals. A win-win situation.

• • Goal: Simple Goal statement
  • Description: A longer more informative description of the goal.
  • Because:  A set of reasons for the goal.

Once your Goal Pyramid is formed you can refer to it in situations where a decision is required, helping focus the discussions on the goals and to break deadlocks which can occur when Team members are in a battle of wills. A systematic analysis of how a path of action effects reaching the number one Team Goal will usually be resolved quicker than battle of wills and assist in preserving ego. For example, lets say a Team member wants to use a new and exciting piece of technology and a goal in the pyramid is “Goal: No risk. Description: Don’t take unnecessary risks. Because: When we take risks where a tried and proven path exists we jeopardize our ability to ‘<number 1 goal here>’, we can say no in a non-personal and professional manner by pointing out this ‘agreed’ team goal. Note, we don’t have to say no, we can say yes in a way that meets our goals. For example, in the same case above we might ask the team member for a plan or strategy for mitigating the risks, or offer our own like “why don’t you make a branch and work on this after hours or weekends to prove it out, taking the risk away from the team?”.

I have not yet tried a Goal Pyramid, and I plan to do so as soon as I can. I formulated it because I see a use for it in solving problems I have experienced in my career. One thing I have learnt in many years is that there are rarely if any technical problems that hamper a team delivering, rather people problems have been the root cause. I hope to use a Goal Pyramid as a tool to facilitate getting through some of these people challenges. Should you make or use a Goal Pyramid then please let me know as I would like to provide feedback here on success or failure of this approach. I will do the same.

Edit: This link was emailed to me and I think it is relevant to this post: http://blog.8thlight.com/brian-pratt/2011/10/25/simplicity-of-teamwork.html

Monday mornings at work there is a buzz about the weekend, especially the outcome of sporting events. Someone is usually strutting around on a high because their team won, or ribbing someone because their team lost. This social interaction is what PlayUp have captured in their flag ship application PlayUp Live, along with live scores, fixtures and more. You should click this link now and check it out.

The journey over the last six months to get the iOS version out (support for other mobile platforms is coming) has been quite a challenge and this post is about those challenges and key take-outs you wont want to miss if you are developing an iOS app that connects to a back end. PlayUp is really exciting and it will grow to be as big as a Twitter or a Facebook, so Im expecting a few more challenges and growing pains and it will be worth it. While this isn’t a job advertisement feel free to contact me if you think this sort of challenge is for you (james dot ladd at iplayup.com).

These are my personal top #5 take-outs from working on the project

#1 Small Team

The number one #1 learning from working on the project is to keep the team small, with two people on the UI and two people the backend integration with the server. The server side is not factored into this count as this is quite variable, however the typical code base size for an iPhone app suggests 4 - 6 developers maximum.

#2 Shared Vision

The team should share a consistent vision of the product they are building. Multiple competing visions or changes in the vision can derail the project significantly. There is a reasonably common held belief that a key person leaving a project can kill it, and this is even more so if that person is the vision holder. A vision holder who is strongly focused and driven to reach that vision with good communication skills is a must.

#3 One Application

The back end of an iPhone application is as important as the front-end, and involving both teams in understanding the requirements of the other is essential. Both parts are crucial to the overall success of the product and directly effect the schedule and outcomes. A shared design and understanding of the architecture is key.

#4 Fast Feedback

The cycle time on building a feature and showing the relevant stakeholders effects the schedule and this loop should be as small as humanly possible. Getting the app onto the stakeholders device is nice and in some cases essential but it takes longer. Getting the stakeholders to be ok with a ‘first-draft’ that isn’t pixel perfect is another way to reduce cycle time to get feedback quickly, so is not writing tests for this ‘first-draft’. However, there are some cases where writing tests in the ‘first-draft’ will allow you to make changes faster later on. You know your app and will have to decide on your own balance.

#5 Libraries

Depending on your application you may need to use off the shelf libraries, and these libraries need to be thoroughly evaluated. Take the time to do this because in the heat of battle is probably not the best time to find out it was not the most robust choice.

People still ask me about East Oriented code. I hope what follows helps shed some light on the topic of East and immutable objects and how they play nicely with each other. Attached are some files (I hope I can attach them) in Ruby which implements a contrived example.

In my example I have a Customer object which can be initialised with values and after which these values can not be changed = immutable. To print the Customer you send the printOn message passing in the ‘thing’ you want the customer printed on to.

Customer forms a customer writer ‘contract’ between itself and classes that implement the customer writer contract. This contract enables the customer to print onto any object that supports the ‘contract’ - essential any object that responds to the messages the Customer sends from printOn.

To help with the example I have two objects that implement the ‘contract’, CustomerConsoleWriter and CustomerJsonWriter.

The magic is that the Customer doesn’t need to change when you introduce new writers, be they a CustomerDatabaseWriter or  a CustomerHtmlWidgetWriter etc.

You can further extend this magic by having writers that know how to delegate to other writers - for example you could construct a CustomerFileWriter with a CustomerHtmlWidgetWriter to write a Html representation of the Customer to a file.

I have left this combinatory magic to you.

Here is a run using the interractive ruby shell (IRB) showing this magic in action (I have removed output that isnt relevant)

:001 > $:.unshift File.dirname(__FILE__)
:002 > require ‘customer’
:004 > require ‘customer_writer’
:005 > require ‘customer_console_writer’
:006 > require ‘customer_json_writer’
:007 > c = Customer.new(’Ronny’, ‘H’, 33)
 => #<Customer:0×2a7de90 @name=”Ronny”, @surname=”H”, @age=33>
:008 > w1 = CustomerConsoleWriter.new
 => #<CustomerConsoleWriter:0×2a74318>
:009 > w2 = CustomerJsonWriter.new
 => #<CustomerJsonWriter:0×2a33db8>
:010 > c.printOn(w1)
Name: Ronny
Surname: H
Age: 33
 => nil
:011 > c.printOn(w2)
{”Name”=>”Ronny”, “Surname”=>”H”, “Age”=>33}
 => nil

*end* I cut out some of the Ruby IRB text.

So now you see an immutable object go East and provide a mechanism that allows a loose coupling and unlimited possibilities for printing Customers - e: limited by whatever classes you supply.

The internals of the Customer object can change without effecting the contract. Other contracts could be created - like a translation contract or a storage contract (see below).

For testing you can use a Mock with expectations on it to test that a Customer is conforming to the Customer Writer contract and you don’t need any existing writers. Likewise you can test CustomerWriters without having any valid Customer objects.

What objects need the data from Customer - all those that implement the CustomerWriter contract.

What about storing ?  I suggest a storeOn method in Customer that send store message. eg: storeName
The difference would be what the Writers do with that message. Like writing the binary rather than string representation. Id probably separate classes that respond to storeOn from those that understood printOn.

With the dynamics of languages like Ruby or Smalltalk you can make the writers even more magic. Consider the Customers age being a class Age rather than a number - When passed to the writer with printAge() the writer could then send it as_date() and now both a Date and an Age object can be printed. This is more about making writers smarter than East and immutability.

Imagine if you took the approach of using a dynamic factory approach to the writers whereby the Customer could use a factory to lookup the writer given the thing you are writing to - for example:   customer.printOn({})    would take the type / class of the object supplied and dynamically create an instance of the writer to use - in this case the passed objects is a hash, so the factory would find a CustomerHashWriter to write to.    There are a lot of possibilities.

When I think about it the only things I typically do with an object can be categorised as one of the following:

1. print - human representation
2. store - non-human representation
3. read - from non-human representation
4. convert - from one representation to another.

I typically use the following methods corresponding to the categories above:

1. printOn
2. storeOn
3. readFrom
4. convertTo

Creation and destruction are needed too, but these are typically handled by the implementation language.

I have in the past written an entire system using this approach and it was simple to modify and understand.

Here is the Ruby code: East Ruby Example

Recently I was a special guest on ADDcasts back in episode 4: http://addcasts.com/2011/04/21/episode-4-special-guest-james-ladd-talks-to-us-about-running-smalltalk-on-the-jvm-immutability-and-how-to-write-good-oo-code/. After the episode aired I received some questions about East. What follows is part of my response which I am posting to continue the discussion on East in the hope that more people try the technique.

Im interested in learning new ways to write software and make what I am writing more readable to others, so Im ok with people disagreeing. I learn more if they do.

I think I led with a poor example and reasoning as I have limited time to think on weekends as I look after my twin boys who are 2.5

Lets forget the accessor and mutator side of things and just focus on the implications of asking an object for information and working on it, rather than asking that object with the information to do the work. This is the key principle - Tell Don’t Ask

When we allow callers to ask for data and we want to know what they do with that data we have to find all callers and look in detail at what they do with the data. Usually what they do with it will be spread over multiple statements, even if those statements just a ‘get’ of multiple attributes. When they can ask for each ‘field’ this task becomes larger and possibly harder. Why did they ‘get’ just 2 attributes here but in other code they ‘get’ 6?

In addition, when we allow callers to ask for the data I usually see multiple callers doing the same processing on the returned data. This might be as subtle as a conversion to uppercase, but I have seen much more repetition creep in. How often have you seen this in the caller:

returned_collection.each {}

This repetitive processing should be in one place - and highlites a missing concept/abstraction. For example, Why does the caller iterate over the returned_collection?

When you face the calls East and ask the object with the information to do the work then the use cases become more evident. For example, “customer.printOn envelope” provides more meaning than looking at multiple call sites. Note I’m not discussing the implementation of Envelope here - personally Id be using an object, even if in Ruby/Smalltalk.

When the use cases are encapsulated in an object like Envelope then the commonality of multiple “functional object” objects can be refactored and kept DRY.

Testing in the case where you can ask an object for attributes requires a lot of setup like when I call this accessor, then return that value”. In contrast when faced East the testing  changes. Usually there is a simpler expectation like “when I call this method, that object receives these calls.”

What I would like to see happen is for people to try this approach and see how it effects their design and their process of getting from A to B. Personally I have found the process to be more effective in time and the ability to understand the resulting code, which I also find there is less of.

Here is a concept for The Man Who Stole a Leopard by Duran Duran.

I contacted their manager Wendy (wendy@magusentertainment.com) and sent it through, and even after inquiring a bit later I still have not heard anything. Not even a thank you for the submission.

What do you think of it?

DuranDuranVideoConcept

Recently I spoke to some people about commercializing some software I was helping develop and the discussion was very short. After the discussion I remembered a lesson I learned in 2000 after I’d tried to ’sell’ an idea to get funding.

What I remembered is that it is all about numbers. You could be selling a ‘fart in a jar’ and as long as the numbers are good you probably have a chance. Focus on the numbers and don’t spend a great deal of time on describing the service or product - or at least leave that to last. The investors are looking for a ‘risk to reward’ that suits them. Give them this information first, and if asked, tell them what the product or service is. They will probably want to know, but after the numbers appeal to them.

What numbers will they want to know?

1. How many ‘farts in a jar’ do think you will sell over 1, 2 and 5 years?
2. How much will people pay for a ‘fart in a jar’?
3. What is the cost of putting a ‘fart in a jar’ and delivering it to the purchaser?
4. How much of the ‘profit’ will they get?
5. How much money do they have to risk to get that ‘profit’ and in what time frame?

There are some other things that investors will want to know like the competition and if there are other risks involved in getting a ‘fart into a jar’ etc etc. However, my experiences suggest this will be of secondary value to the numbers.

On another note, does anyone know a good way of finding out what someone would pay for a service (not a ‘fart in a jar’) ?

For some time now I have been working on a personal project: Redline Smalltalk and blogging about it here.

In March 2011 Ill be presenting the journey so far at Smalltalk Solutions 2011 in Las Vegas

If you get along to the conference please come and say g’day.

The web application I am developing allows the User to download various files in different formats. To test this works I’m using a combination of things, with Ruby WATIR-WEBDRIVER for the front end and Firefox for the browser and all automated with Hudson as the Continuous Integration (CI) Server.  The problem I face is that Firefox wants me to tell it what to do with the files each time I download them and this isn’t going to work for my CI needs.  So how can I prevent Firefox from asking me what to do with each file I download?

The functionality is there inside Firefox and WATIR-WEBDRIVER and you just need to turn it on. What follows are the steps to do this:

Create a Firefox Profile

Run the following command from your command prompt / terminal:

firefox -ProfileManager -no-remote

This will start an instance of the Firefox Profile Manager (see below) where you can create a new profile. I called mine “no-download-dialog”. You may also have an existing profile for running WebDriver but leave this alone. Click “Create Profile” and follow the wizard.  When back on the profile manager select “Don’t ask at Startup.”. Click “Start Firefox”.  NOTE that we are now using the Firefox Profile we just created.

Make a File Association

Firefox allows you to disable asking you what should happen to files being downloaded when there is a file association for that type of file.  So using this Firefox instance go to a Web site and download a file of the type you are going to download during your tests. In my case these were XML and Word documents. During the download Firefox will ask you where you want to save the file and allow you to select the option to “Do this automatically for files like this from now on” (See below). Select this option and save the file.

Now that file is downloaded Firefox should have an association between the file type and the action you want to perform. To make sure this is correct go to the Firefox Preferences (sometimes called Options) and select the Applications tab. I’m using Linux so this is Edit->Preferences->Applications (See below).  Scroll down the list of Content Types and Actions until you find the Content Type for your file. If you can’t find it then maybe your Web Server is sending something else as the Content Type when you download files.  When you find the Content Type check that the Action is set to “Save File”, if it isn’t you can change it now.

As a final test find another file of the required type and download it and you should not see a file dialog. However, you may see the Download Manager window, which can be disabled in the Preferences->General tab. De-select the “Show the downloads window when downloading a file”.

Test with Profile

Now that you have a profile that doesn’t ask what to do with downloaded files you need to tell your tests which profile to use. I’m using WATIR-WEBDRIVER but the same abilities are provided with other tools that sit atop Selenium. In your code where you obtain a browser instance add an argument to specify the Firefox profile to use. For me this looked liked this:

Watir::Browser.new(:firefox, :profile => 'no-download-dialog')

In some other tools or in Java you may need to specify the profile on the command line like this:

java -jar selenium-server.jar -firefoxProfileTemplate "<your no download dialog profile name>"

Set the Default Profile

So that Firefox is using the default profile when started outside of testing you need to tell it to use the “default” profile again. To do this Start Firefox Profile Manager and choose “default” and make sure “Don’t ask at startup” is selected and then exit.  Firefox should behave as normal when started outside of testing

Now when Firefox is run by by the Continuous Integration Server it will not stop the tests to ask you where to save files.

Said the Test Driven Tortoise one day to the Hackey Hare:
“I’ll run you a code race if you dare.
I’ll bet you cannot
Arrive at that production spot
As quickly as I can get there.”

Quoth the Hackey Hare: “You are surely insane.
Pray, what has affected your brain?
You seem pretty sick.
Call a doctor in–quick,
And let him prescribe for your pain.”

“Never mind,” said the Test Driven Tortoise. “Let’s run!
Will you bet me?” “Why, certainly.” “Done!”
While the Test Driven Tortoise creeps,
with Tests, Continuous Integration and
customer speaks, Hackey Hare makes four leaps,
And then tells all how soon he’ll be done.

It seemed such a one-sided race,
To win was almost a disgrace.
So he hackily coded about
until the bugs inevitably came out –
As the Tortoise was nearing the place.

Too late! Though he sped like a dart,
the bugs hard to start
The Tortoise was first. She was smart:
“You can surely code fast,”
She remarked. “Yet you’re last.
It is better to get a good start.”

Adapted from Jean de La Fontaine’s poem: Hare And The Tortoise

A corollary to this fable is another version http://www.jobcyclone.com/articles/haretortoise.php related more to business that sees the hare winning, however, the key to this version is “fast and consistent”. It is rare to find someone that is both fast and consistent without using techniques like Test Driven Development and Continuous Integration which support going as fast as you can as consistently as you can.

If you want to win the race you should start with TDD and CI.