The X Penny Game

The X Penny Game is a simulation game exploring the effects of WIP limits. It is a combination of Karen Greaves modified Scrum Penny game with Karl Scotland’s version of the Ball Flow Game.

This game is geared to show the importance of limiting the work in progress and to explore the following formula (implied by Little’s Law)

Flow Time = WIP/Throughput

  • Flow Time (Cycle Time, Lead Time) – average amount of time it takes to fully complete a unit of work
  • WIP (Work In Process) – is the average amount of units in the system
  • Throughput – average number of units being completed within a given time frame

The game is designed to work with 6 to 12 people – we had 8 players and 1 facilitator

The team divides into the following roles:

  • 1 – Customer
  • 5 – Workers
  • The rest are efficiency experts

We had a total of 8 players (6 workers, 2 efficiency experts).

The team organises themselves around a table. The image below shows how our team arranged themselves. Each worker has an empty area on the table directly in from of them referred to as a workspace.

Continue reading

Agile Practitioners

Mixing with other members from our industry. This keeps us up to date and stops us getting too caught up in a closed off world. If you would like to have face to face discussions with other professionals you may wish to join us at one of the  Agile Practitioners events. This London based group will be meeting at least once a month. We will be discussing a variety of topics. While we don’t plan to replace any of the existing Agile groups, we do intend to be intriguingly different.

Avatars and not acting like a manager

Recently we started using avatars on our Kanban board. We are certainly not the first to do this, however I was surprised by how excited and rejuvenated the team became. If you have never tried this I recommend you suggest it to your team and see if they go for it.

Not only is it fun, but it is also practical. With one look at our board we can see exactly who is working on what and who they are working with. Each person has one avatar on the board, therefore they can only work on one task at a time. Occasionally someone will start work without updating the board, but this is very seldom.

We went for the classic South Park characters, each team member got to draw themselves, here is the result:

You may have noticed that my character (Daryn) is a bit stressed out. This is a reminder to myself, that as the ScrumMaster I should not get overly concerned about everything. I need to trust in the team and leave them alone to get the job done. I need to remember that a ScrumMaster is a facilitator and not a manager. For me, not acting like a manager is the most difficult part about being a ScrumMaster.

Ajax Fundamentals – Part 4

Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5

5. Development and Debugging Tools

5.1. Documenting JavaScript

JSDoc is an open source tool used to add inline documentation to JavaScript source files.   JSDoc is based on the javadoc tool.   Many of the javadoc characteristics have been included in JSDoc.   An example of using JSDoc can be found here.

5.2. Firefox Tools & Extensions

DOM Inspector is included in the Mozilla Suite and Firefox browser.   This tool provides a graphical user interface that enables a user to brows the document object model of any site.   One can view, update and insert DOM attributes dynamically.   In order to assist JavaScript developers, DOM Inspector can be switched to JavaScript Object mode.   This shows all the properties and methods available to a JavaScript for a particular mode.   DOM Inspector provides a JavaScript evaluation window that allows the user to execute JavaScript against selected nodes.   There is the option to use CSS Style Rules and Computed Style information.   This allows a user to examine the CSS attributes associated with different page elements.

Firefox JavaScript Console is a tool that logs JavaScript errors found on a page when the page is rendered.   The Firefox JavaScript Console gives ‘compiler-type’ messages.   It describes the error that occurred and the gives the line number.

Firebug integrates with Firefox and provides many development tools.   Firebug has a version of a DOM inspector that enables a developer to find elements.   CSS support allows settings to be altered and viewed.   Firebug allows one to monitor the network activity in order to determine how long it takes for different sections of a page to download.      A JavaScript Debugger allows one to debug and step through the JavaScript at runtime.

Continue reading

Ajax Fundamentals – Part 3

Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5

3. Security Issues

The XMLHttpRequest object is restricted to run within the browser’s security sandbox. Any resources requested by the XMLHttpRequest object must reside within the same domain from which the calling script originated. Therefore the XMLHttpRequest object is constrained to requesting resources that reside within the same domain from which the script was originally served. The W3C states, that in the future The XMLHttpRequest Object specification will define a way of doing cross-site requests.

There is an overabundance of online documentation stating that Ajax introduces multiple security threats. These threats include fake requests, denial of service, cross-site scripting (XSS), reliance on client-side security, and more. Jeremiah Grossman’s article, Myth-Busting AJAX (In)security, maintains that these security issues existed before Ajax and the recommended security best practices remain unchanged. Part of internet security basics is to distrust the client. Ajax is a client side technology and requests need to be treaded with the same caution as all other calls.

4. Disadvantages

4.1. Usability Problems

Web users have become familiar with using classic web pages. Users have become accustomed to using browser features such as the back and next buttons. Ajax calls are not loaded onto the browsers navigation stack. Therefore the back button will not undo the last ‘Ajax operation’. Developers need to explicitly cater for undo operations.

Ajax enabled pages have a notion of state; this state is altered as the user navigates through the site. The browser is unaware of this state, and it is not reflected in the address bar. Therefore users are not always able to book mark a certain page state. Developers need to consider this when deciding on when to use Ajax.

The asynchronous nature may make page updates difficult for the user to notice. The developer needs a way of drawing the user’s attention to the modified section of the page. The ‘yellow-fade technique’ has become common practice. In this technique the changes are highlighted with a yellow background, and the yellow fades gradually. These and other techniques are becoming familiar to web users.

Continue reading

Short-listed!?!

About a week ago I noticed some incoming links from Computer Weekly.com. I assumed that someone had commented on one of my posts, so I browsed there wondering if it was a positive or negative comment. Once the page loaded, I was completely surprised. It turns out that this blog has been short-listed for the Computer Weekly.com IT Blog Awards! This came as a complete surprise to me.

This blog had really humble beginnings. In fact it was not even my idea to start a blog, it was my work that encouraged me to start one. Initially I felt that I did not have that much to contribute to the world at large. In fact I still don’t feel that my blog is as innovative as some others, although judging by the response to my ‘Routing In Rails Tutorial‘ it appears as if I do have a nice way of explaining things. I guess this is one of the main reasons I have been voted onto the shortlist.

The competition ends on the 31st of July 2008. If you would like to vote please go to this on-line voting page. This blog can be found under the ‘Programming and technical blogs’ drop-down list. It is a surprisingly painless exercise, it takes less then a minute and no registration is required.

Thank you to all of you who have voted for this blog.

Daryn

Beginners Tutorial: Routing in Rails 2.0 (with REST) – Part 6 of n

In part 5 we looked at RESTful routing. In this part we continue to explore RESTful routing, by examining nested resources.

I originally planned to cover nested routes and to cover two questions posted to me in previous comments and emails. One question was with regards to ‘one to many relationships’ e.g. an album has many songs. The second question was from Tom in part 3; this was about adding save as functionality.

In trying to answer these questions I created a new application – a text editor with a version history. This has turned out to be a fairly interesting piece of work. I then changed my mind and decided to include it in a follow up post. I am hoping to have that out later this week (before Friday the 11th of July).  As the ‘follow up’ post will have a practical example of nested resources, this post will not have the usual practical section with the experiments.

Part 6

Introduction to Nested Resources

The Nested URI

Returning to the familiar Music Store application, imagine we added songs to the application. Like Albums, Songs are resources and we could expect to access a song with this URI:

/songs/124

We could then perform the required CRUD operations on that URI based on the REST API as discussed in part 5.

An album has many songs. We can express this within the URI e.g.

/albums/10/songs/124

Once again we could make use of the HTTP verbs to perform CRUD in a RESTful way.

In this particular implementation, this URI does not mean that this is the 124th song of album 10 – it is possible for it to be the fist song of album 10.  The URI is pointing to the 124th song in the system.

If we wanted the URI to state the songtrack number of the specified album then we could alter the above implementation. Then we could expect to see URIs of:

/albums/10/songs/5
and
/albums/11/songs/5

This would not result in a URI conflict.

Continue reading

Programming While Stupid

Over engineering is a major problem within the software industry. This problem has led to the adoption of ‘lean software development’ – at least amongst the agile folk. Lean software development is writing code to support the current set of requirements and nothing more. This is not as easy to do as one might think.

As developers we naturally tend to make assumptions as to what the user, or system, will need. In truth, it is very difficult to accurately predict the future requirements of a system. Coding to meet our assumptions will inevitably lead to over engineering.

We should not let our intuition guide us into false requirements. As strange as it may sound, it takes a concious effort to stop ourselves from doing extra work. We need to adopt a ‘lean coding culture’. We need to constantly remind our selves to stick to lean software development. In agile teams it is common to hear developers reminding each other with certain acronyms and expressions e.g. ‘do the simplest thing that works’.

‘Do the simplest thing that works’ is in-line with lean software development, although it can be misleading. Some people interpret this as ‘do the first thing that comes to mind’ e.g. slap on another if statement – that is a simplistic solution and not a simple solution. If you take a quick and dirty simplistic approach you will end up with a big ball of mud. You need to do the simplest thing that works. The thing that works is something that can be tested, it is something that does not add unnecessary complexity. Therefore the simplest thing that works is not necessarily the quickest and easiest thing to do.

Continue reading

Beginners Tutorial: Routing in Rails 2.0 (with REST) – Part 5 of n

Part 6

In part 4 we explored named routes. In this session we move onto Rails’ REST.

Part 5

The Critics

Before we begin you should know that there are many critics of the Rails implementation of REST. There are many reasons for arguments against Rails’ REST e.g. Rails uses server side session state and client side cookies. Some people say that this is not REST compliant. Rails’ REST might not be 100% REST compliant, but you can still benefit from using REST in your Rails applications. In The Rails Way, Obie Fernandez explains that the benefits from using Rails’ REST fall into two categories:

  • Convenience and automatic best practices for you
  • A REST interface to your application for the rest of the world

Therefore it is worth learning and using Rails’ REST.

The Standard Introduction

Representational State Transfer (REST) is an architectural style. It was first introduced by Roy Fielding in his PhD thesis. Roy Fielding is one of the principal authors of HTTP.

The Mindset

When developing a Rails application in the RESTful way it helps to change your mindset. You should not think that you are developing a web site for users accessing the site via a browser. It is better to think of the application as being a service. The service performs actions for clients. These clients may be humans or other machines on the network.

This service will typically be placed on the internet. Therefore we could call it a web service. When I hear the term web service I immediately start thinking about SOAP and all the WS-* specifications. Let’s be clear, we are not talking about ‘those’ web services. We are talking about RESTful web services. These two technologies provide similar functionality, but RESTful web services are simple and sensible.

The Terminology

As previously stated, programming in REST requires a change in the way we think about the system. This naturally leads to a change in the way we talk about the system. The following provides a brief description of some of the key terms used in discussions about REST and HTTP.

A resource is one of the key concepts in REST. Many discussions on REST claim that a resource is anything and everything. This is neither true nor helpful. Let’s examine this concept with the aid of an example.

Let’s assume that the music store has started selling albums. The database may have the following schema:

orders erd

The data in the database is the raw data. There is data which, given in isolation, is of no real value to a client. For instance it is unlikely that a client will want only one row from the LineItems table. This means that a LineItem (on its own) is not a resource within the context of the music store service.

A client would want all the information pertaining to an order. This would include data from one or more tables. Some data would not be included e.g. database keys. Some information may be added e.g. the total cost of the order might be calculated and included in the ‘order information’. This ‘order information’ is an example of a resource. Order resource is the type, there will be one order resource instance for each order made.

Each resource must be given a globally unique identifier. This is done using a URI. This could look like this:

http://www.example.com/orders/65

A client, in an admin role, may want a list of all the orders. This collection of orders would be another resource. Following the REST architecture, the orders resource would be assigned the following URL:

http://www.example.com/orders

It is important to note that these resources are not HTML documents. Roy Fielding describes a resource as a conceptual mapping. As a resource is a conceptual entity it can not be used by a client. The service provides the client with a representation of the resource.

When the client is a browser, the service typically provides an HTML representation of the resource. If the client is another machine then the service may provide an XML representation of the resource. Other representations could include a PDF file, an image, csv etc. A representation is only supported by the service if it is applicable and required.

Resources are often referred to as nouns. This is often done when talking about HTTP to assist learning. The term ‘noun’ is more abstract. For our purposes, resources and ‘nouns’ are synonymous.

HTTP also has the notion of verbs. These are the HTTP operations. We are all familiar with the POST and GET operations. In addition to these two operations, HTTP also supports: DELETE and PUT.

There are a few more terms to cover, but we can do that later. The core terms have been explained.

Continue reading

Beginners Tutorial: Routing in Rails 2.0 (with REST) – Part 4 of n

Part 5

The routes we have discussed so far are known as simple routes. I have been referring to them as custom routes, but ‘simple routes’ is the correct term. The default route we discussed in part 3 is also a simple route. The aim is to move onto RESTful routes, sometimes called resource routes. RESTful routes are built on top of named routes. Therefore we must first cover named routes, and that is what part 4 is all about.

Part 4

Introduction

Referring back to part 1, the routing system has two main functions:
Interpreting a request URL
Generating a request URL

We had a detailed look at route generation and interpretation in part 2, but let’s have another quick look at it. Let’s assume, for some insane reason, that we defined the following route in the music_store routes.rb file:

map.connect ‘apples/bananas/:id’, :controller => “albums”, :action => “show”

link_to would use this rule to generate a URL, this can be seen in the following line extracted from index.html.erb:

link_to ‘Show’, :controller => “albums”, :action => “show”, :id => album.id

This could generate a URL of: http://localhost:3000/apples/bananas/7
And when given this request, Rails would handle it correctly e.g. the show action will be called on the albums controller and the show view will be sent as the response to the browser.

Coming back to the real world, we are more likely to define the routing rule like this:
map.connect ‘albums/show/:id’, :controller => “albums”, :action => “show”

link_to (and friends) would then generate a URL like this:
http://localhost:3000/albums/show/7.

To show the index (the listing of the albums) we could define a rule like this:
map.connect ‘albums/index’, :controller => “albums”, :action => “index”

The matching link_to in edit.html.erb is:
link_to ‘Back’, :controller => “albums”, :action => “index”

Looking at the last example, there is some repetition. Both lines contain:
:controller => “albums”, :action => “index”

The link_to method needs this (controller, action) information to obtain the URL. If we had the URL stored as some global variable, or method, then we could simply pass that into link_to. link_to could use this ‘literal’ URL without needing to generate one.
This could look something like: link_to ‘Back’, albums_index_url
This is one of the main ideas behind named routes.

Continue reading