The Agile Practitioners group recently held a pecha-kucha event at Zuhlke Engineering. The talks were great! The content was intriguing and the Pecha Kucha format added an extra edge to the presentations.

We learned a few lessons that will help improve the next Agile20x20 event.

Here are the talks

Christian Heldstab does a great job of presenting Getting Things Done

Abid Quereshi exlapins the core values of Scrum

Daryn Holmes gives a talked inspired by the phrase “we want to be more agile”

Benjamin Nortier discusses efficiency at the cost of robustness

Sleepyfox warns about the dark side of metrics

Thanks to all the people who attended and thanks to the presenters for all the time and effort they put in to make it an interesting evening.

If you would like to be involved with these events in the future, please leave a comment below.

Railway buffer at the top of Pikes Peak, Colorado Springs CO

There is an informative slide deck on the FactoryPhysics website entitled A Fast Cycle Time Story. This slide deck was created by two Intel Products employees namely Tim Skowronski and Joan Tafoya.

The slides cover many aspects of lean manufacturing, one of the topics covered is The Buffering Law

Systems with variability must be buffered by some combination of:

• Inventory
• Capacity
• Time

Tafoya and Skowronski explain the implication of this law

If you cannot pay to reduce variability, you will pay in terms of high WIP, under-underutilized capacity, or reduced customer service i.e. lost sales, long lead times, and/or late deliveries.

The following variability buffering examples are provided:

• Ballpoint Pens:
• can’t buffer with time (who will backorder a cheap pen?)
• can’t buffer with capacity (too expensive, and slow)
• must buffer with inventory
• Ambulance Service:
• can’t buffer with inventory (an inventory of trips to hospitals?)
• can’t buffer with time (response time is the key measure)
• must buffer with capacity
• Organ Transplants:
• can’t buffer with WIP (perishable – very short usable life)
• can’t buffer with capacity (we cannot ethically increase capacity)
• must buffer with time

In software engineering we experience variability due to a number of reasons, including policies and practices we put in place.  The prominent cause of variability considered here is changing requirements and the varying levels of demand for features.

This variably is due to a number of reasons e.g. a customer gaining insights after using the software, a new opportunity in the market, a change in regulation etc. This variability is largely due to external events. Iterative and incremental development practices help reduce the impact of this variability but this does not illuminate variablility. Therefore, according to the Buffering Law, we need to buffer with some combination of inventory, capacity or time.

We cannot buffer with inventory because we don’t know what the future requirements will be. If we did we would not have variability in the first place.

A teams capacity is their ability to produce features as and when the business needs them. There are a number of options teams can use to improve their capacity e.g. process improvements (Scrum\Kanban), technological improvements (automated acceptance tests), increasing or decreasing team size (two pizza rule).

Due to the nature of software development most teams are continuously trying to catch up with a backlog of requirements. Many of these teams are continuously improving their velocity. With this in mind, it is naive to think that we can cause a huge increase capacity simply because we need to. That is like saying we only take the short cut when we are in a rush. The teams capacity is not like a tap that we can turn on and off. While all teams can (and should) incrementally improve, drastically increasing capacity in times of need it is not always feasible and it is not a trivial task.

In software development we need to buffer with time. Teams aim to deliver the requested features over a period of time. As Tafoya and Skowronski point out, when you buffer with time you pay with “reduced customer service i.e. lost sales, long lead times, and/or late deliveries”. Which reads like a readers digest version of the history of software development.

Photo attributed to: Tim Pearce

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.

The props
100 coins – I used 10 pence coins (GBP), all coins should be the same size
1 table – large enough to have 3 people stand side-by-side on each side of the table
A stopwatch for each efficiency expert – ones that can pause and resume
A spreadsheet to record stats – discussed later

The game
The customer takes a batch of coins (from 1 to 100) and passes them to a workspace. A worker turns over each coin one-by-one and then passes the batch to the next workspace where the process is repeated. A batch of coins are returned to the customer once they have been turned over once in each workspace. The facilitator records the time it took to process the coins. The team then decides how to improve the performance and tries again. It is recommended that you limit the game to 5 rounds to avoid fatigue.

The objective of the game: The team aims to turn over each coin once, in each workspace as fast as possible.

The objective should not be misinterpreted as “each worker turns over each coin once as fast as possible” . There is no 1 to 1 mapping between a worker and a workspace. This gives teams the opportunity to come up with a pairing or swarming strategy that may improve performance e.g. near the end of the round all workers who have nothing to do can join a work station where there is still work to be done.

The constraints
The game has soft constraints and hard constraints. The soft constraints are there for the team to change and to see the effect on performance. The hard constraints are there to make the game more challenging and to force certain behaviours. If you do change the hard constraints, change them after 4 or 5 rounds. The team can only make one change per round.

Soft Constraints
These constraints are enforced on the first round, after that the team can start changing or removing them.

• The customer and product owner may only use their left hands
• Batch sizes of 20 must be used

Hard Constraints

• Only the customer can add coins to the system and removed them from the system
• The complete batch must be processed before passing the batch on
• Each batch must be the same size
• The customer and workers may not pass batches to their neighbours sitting directly on the left or right, passing to the opposite neighbour is allowed. If you want to be cruel, don’t allow passing to opposite neighbours.
• A worker can only turn one coin over at a time

Defects
A dropped coin is a defect, you can choose to collect the defects in a round or enforce a different penalty. If you would like to focus on the impact of defects you may want to use a higher penalty for defects  e.g. the worker needs to redo that batch. Obviously this introduces a new dimension to the game.

Stats
The more stats you can collect the better. In our exercise each of the 2 efficiency experts chose a worker to monitor. They kept track of how much time the worker spent turning coins i.e. waiting time was not counted.

Karl Scotland was kind enough to provide a spreadsheet with the Ball Flow Game. I used a modified version of this spreadsheet in this X Penny Game. I needed to alter it as the ‘batches’ are different in this game. In the ball flow game the batch is the amount of balls in the system, in this game batches of coins are passed around. Thus 3 batches of 10 coins each could be in the system at once. This difference is reflected in the how the stats are collected. You can download the spreadsheet from the home page of this blog, near the top right.

Whenever the customer added a batch to the system she yelled “in!”, when she received a processed batch she shouted “out!”. This helped me, the facilitator, to record when a batch went into or out of the system. The spreadsheet displays some interesting data and graphs.

The game in progress…

The team gathered around the table, as per the image above. I explained the rules and gave them a few minutes to plan the routes for the batches of coins.

I had previously sketched out paths I thought the team would use to pass the coins and it looked similar to this:

I introduced the ‘neighbour constraint’ to create two troublesome intersections. The plan is for those intersections to cause delays and mishaps. The ‘X’ shape is the reason I called this the ‘X Penny Game’.

Interestingly the team did not come up with those paths, they opted for this strategy:

Later I found out that I did not explain the rules clearly, the team thought they could not pass to opposite neighbours. This misunderstanding did not do any damage, it made things more challenging. You can choose which versions of the game you would like to try.

Round 1
Batches of 20
Left hand only
All the hard rules in place

These are the initial set of constraints enforced in round 1.

The results:

The first batch came back to the customer at 2:00 minutes. The total time was 3:45min. The first two batches went through the system the fastest. The batches were delivered at an average rate of every 30 seconds.

1 coin had dropped off the table and we noted this as a defect.

The efficiency experts said that worker X worked for 1:33min and worker Y was active for 1:35min.

The team said that they experienced major delays waiting for the first batch to arrive.

Round 2
Left hand only
All the hard rules in place
Change: Batch size of 10

Round 3
Keep: Batch of 10
Left hand only
All the hard rules in place
Change: Don’t give coins to the next worker, unless they have an empty workspace

The first batch arrived at 0:56min, the total time was 2:45. This was 9 seconds faster than the previous round, interesting given the small change made in this round.

There were 2 defects in this round.

Worker X was busy for 1:45 minutes with worker Y working for 1:36 minutes.

The team felt that this round was more organised and that there was less waiting.

The following graph shows the WIP and the total time of the first 3 rounds:

The throughput between round 2 and round 3 are intriguingly similar:

Round 4
Left hand only
All the hard rules in place
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Change: Batch of 5

In this round, the first batch was delivered at 00:32min. The total time took ~2:50min. I don’t have the exact time, for some reason we only did 19 batches. None of us noticed this. The 19^th batch was delivered at 2:43min. The throughput was impressive. On five occasions we had 2 batches coming through within the 10 second time span.

We encountered 4 defects.

The efficiency experts said worker X worked for 1:55, worker Y for 1:51.

The following graph overlays the WIP from round 3 with round 4:

In this case, moving from a batch of 10 to 5 seems counterproductive. Had we done all 100 coins, it may have taken longer than using batches of 10. This may have been due to the cost of moving coins from one workstation to the next. The team said this round felt more exhausting. This shows us that we don’t always benefit from reducing the batch size.

Round 5
Left hand only
All the hard rules in place
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Change: Batch of 1

In this round the system ‘burst’. The first batch (coin) came in at 14 seconds. The throughput was about 4. By the time 8 coins had entered the system, we had recorded 7 defects. I could not keep up with the stats and called an end to this round.

The team noticed that while there was a high throughput, we also had a high defect rate and the pace was not sustainable. We could have made changes to make a batch of 1 more manageable e.g. limiting the number of batches\coins entering the system. Unfortunately we were not brave enough to try this batch size again.

Round 6
Batch of 5
Left hand only
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Change: You can now pass to your direct left or right neighbour

This change allowed the team to simplify the routes the coins were passed along:

This simplification reduced the time and disruption of passing a batch on. We remarked that this was similar to reducing the cost of moving work between stages. For example, when a development team passes work on to a separate testing team, the testing team would also need to learn about the requirements of these new features. If one team developed and tested the work we could avoid this duplication of effort.

The first batch was delivered at 27 seconds and the total time was 2:18 minutes. No defects were recorded.

Worker X worked for 1.40 minutes and worker Y worked for 1.35 minutes. The team mentioned that worker Y was extremely consistent, almost always having a time of 1.35 minutes.  While we had a ‘new and faster’ system in place, there was no significant change in the average time spent working.

In this round the team felt that there was less waste in the system. They noted that they did better, even though people worked for the same period of time. One of the team members felt that they worked better in the first half of the round, the stats confirmed this.

A comment was made about the synchronicity that was achieved in this round. The team seemed to be working like clockwork. The team developed a natural rhythm or cadence. This is reflected in the consistent cycle time:

Round 7
Batch of 5
Keep: Don’t give coins to the next worker, unless they have an empty workspace
Keep: You can now pass to your direct left or right neighbour
Change: Right hand only

The first batch came in at 28 seconds, the total time was 2:19 min.

1 defect was recorded.

Worker X worked for 1.36 and worker Y worked for 1.35 minutes (again!).

We discussed why the team had done better with their left hands. The team said this was because they had now trained their left hands.

Additional Discussions and Observations

We have noticed that when we try to think of ways to improve performance, our ideas tend to involve increasing WIP e.g. introducing queues. Returning to this formula:

Flow Time = WIP/Throughput

Increasing the WIP may be counterproductive. We noticed this in round 2 and round 3. The only difference between the two round was that we waited for the next worker to have an empty workspace before passing on the batch. In round 2 there were times when we had a WIP of 60 while in round 3 the WIP did not exceed 50. Round 3 was completed 10 seconds faster than round 2.

The following graph shows the amount of time worked by worker X and worker Y mapped against the time it took to process all 100 coins in the different rounds:

I have included this to show that performance was improved due to changes in the WIP and process. The individual workers did not perform their work any faster.

What we didn’t try

Some team members suggested a pairing strategy, another suggested converting the efficiency experts into workers to increase the size of the team.

We did not try a batch of 1, with fewer batches in the system.

There was a discussion about using queues, this would be interesting to try.

It may be possible to send batches around in opposite directions, it would take some organisation but it is possible.

Again. these ideas suggest increasing WIP therefore they may be counterproductive. 

Improvements

We had a number of misunderstandings as I did not have the rules written down. Sometimes fuzzy rules lead to interesting results, sometimes they frustrate participants.

I would have liked to have spent more time gathering feedback from the participants. Next time I may hold less rounds to give more time for discussions.

Your Turn

You are welcome to try this with your team, I am keen to hear what results you observed…

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.

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.

HTML Validator is a Mozilla extension that performs HTML validation within Firefox and Mozilla.   HTML Validator validates the HTML locally and does not use a remote third party.   The number of errors of a HTML page is seen on the form of an icon in the status bar when browsing.   HTML Validator offers a set of tools to assist in validating and correcting HTML tags.

Checky is Firefox extension tool for validating HTML.   In addition to HTML, Checky can validate XHTML, CSS, RDF, RSS, XML and many more formats.   Checky sends the source to third-party cites to be validated.   The third-party cites may be free or commercial services.

Pederick’s Firefox Web Developer extension offers a large set of tools for a website developer.      Web Developer provides an extensive set of tools, from highlighting table cells to converting ‘GET’ requests to ‘POST’ requests.   This toolbar contains more than 80 tools and is an essential commodity.

5.3. JavaScript Syntax Checking

JSLint is an online tool that evaluates JavaScript code.   JSLint scans the JavaScript code and identifies syntax errors, structural problems and questionable coding-style conventions.

5.4. Compression and Obfuscation

MemTronic’s FREEWARE HTML/JavaScript Cruncher-Compressor  is a freeware tool that can perform both compression and obfuscation.   The MemTronic’s website provides the following information.   The tool can Crunch, Compress and Obfuscate.   Crunching removes all comments and whitespace.   Crunching has a bandwidth saving between 20%-50%.   Compressing will compress the script with a real compression-scheme, with auto decompression added to the file.   This results in bandwidth savings between 40% – 90%.   The obfuscator has not been released at this stage.   Once complete this tool will encode the script into a format that humans can not easily read.   When using Compress, the file will undergo a level of obfuscation.

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.

4.2. JavaScript Disabled

If a user has disabled JavaScript no JavaScript will be executed and certainly no Ajax requests will be sent. A site that relies too heavily on JavaScript will be crippled if the user disables JavaScript, Gucci is an example of this. This site used to show a blank white page if a user browsed to it after disabling JavaScript. Now it explains that you need to have JavaScript enabled to use the site.

A site that relies on JavaScript for core functionality restricts its users to those who have JavaScript enabled. Having said that we should look at how many users are allowing JavaScript to run in there browsers. The following statistics from The Counter show JavaScript statistics.

Wed Mar 1 00:01:01 2000 – Fri Mar 17 23:59:01 2000
Javascript 1.2+: 260153365 (79%)
Javascript <1.2: 7790575 (2%)
Javascript false: 59884983 (18%)

Thu Mar 1 00:01:01 2007 – Thu Mar 22 13:58:01 2007
Javascript 1.2+: 56607094 (95%)
Javascript <1.2: 193622 (0%)
Javascript false: 2524217 (4%)

These stats show that most users are using JavaScript, therefore many stake holders would approve of the use of Ajax on their sites. Although there are cases where limiting access is unacceptable.

4.3. Search Engine Indexing

Web crawlers automatically navigate through the web by following link tags e.g. href, src etc. Current web crawlers do not examine client side scripts. Search engines skip the JavaScript code that executes the Ajax calls. Content loaded by Ajax calls will not be indexed by search engines.

Multiple solutions have been proposed to solve this problem. Most of these are workarounds and do not solve the underlying problem. In fact some approaches are considered as cloaking and can get the site black listed by Google. Google have stated that they will improve there searches, at present they do not follow Ajax calls. In order to make sure that specific content will be found by search engines, the site should have standard HTML links that web crawlers can follow.

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

]]> http://darynholmes.wordpress.com/2008/07/12/ajax-fundamentals-part-3/feed/ 5 Daryn http://darynholmes.wordpress.com/2008/07/08/short-listed/ http://darynholmes.wordpress.com/2008/07/08/short-listed/#comments Tue, 08 Jul 2008 21:17:25 +0000 darynholmes http://darynholmes.wordpress.com/?p=75 Continue reading →]]> 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

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 124^th song of album 10 - it is possible for it to be the fist song of album 10.  The URI is pointing to the 124^th song in the system.

If we wanted the URI to state the song\track 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.

Implementing Nested resources in Rails

If we decided to add songs to the Music Store application, we could start off by aiming for a URI of:

/songs/124

As you may recall, we can achieve this by declaring this resource in the routes.rb file:

map.resources :songs

This will give us access to helper methods such as songs_url, song_url (@song) etc. This was discussed in part 5 under ‘Experiment 5.2 Showing the Index Page’.

Next we could aim for a nested URI:

/albums/10/songs/124

To achieve this we use the following construct:

  map.resources :albums do |albums|
    albums.resources :songs
  end

Note that it is albums.resources :songs and not map.resources.

With this routing rule, Rails will generate slightly different helper methods. To view these routes we could use the method described in part one. There is also a more convenient rake task: rake routes.
This is one of the ‘things’ I have been meaning to mention. You may have read it in a previous comment.

If you use ‘rake routes’ you will notice that there are a quite a lot helper methods being generated, more than the 7 I pointed out in part 5. The ‘extra’ methods are there to create URIs for different formats.

Below is filtered output from ‘rake routes’

 album_songs 		GET    	/albums/:album_id/songs	            {:action=>"index", :controller=>"songs"}
 			POST 	/albums/:album_id/songs             {:action=>"create", :controller=>"songs"}
 new_album_song	 	GET   	/albums/:album_id/songs/new         {:action=>"new", :controller=>"songs"}
 edit_album_song	GET    	/albums/:album_id/songs/:id/edit    {:action=>"edit", :controller=>"songs"}
 album_song 		GET    	/albums/:album_id/songs/:id         {:action=>"show", :controller=>"songs"}
 			PUT    	/albums/:album_id/songs/:id         {:action=>"update", :controller=>"songs"}
 			DELETE 	/albums/:album_id/songs/:id         {:action=>"destroy", :controller=>"songs"}

As you can see, we now have helper methods which look like album_songs_url and album_song_url(@song). The path versions are also available.

Inside the view we could have:
link_to ‘Edit’, edit_album_song(@album, @song)

Looking at the rake routes output above, we can see that the songs controller can get access to the album ID via params[:album_id]. The song ID can be obtained using params[:id].

Now we have helper methods that generate URIs of the form:

/albums/10/songs/124

Our routing system also knows how to deal with incoming URIs of that form.
Now we would like an implementation that allows us to use URIs like:

/albums/10/songs/5

Where song 5 really is the 5th song in album 10. Therefore we could have:

/albums/10/songs/5
and
/albums/20/songs/5

As with most things, it is easy once you know how. To achieve this we simply need to override the ‘to_param’ method in the song model. I imagine that would look something like this:

def to_param
number # number is the track number of this song on the album
end

@song = Song.find_by_number(params[:id])
and not
@song = Song.find(params[:id])

There will be more on this in the follow up text editor post.

Deep Nesting

Jamis Buck recommends that resources should never be nested more than one level deep. You can find his original post about that here. The Rails community seems to be divided about this ‘rule of thumb’. I recommend that you follow this guideline – although remember it is just a guideline, you can use deeper nesting if the need arises.

End of Part 6

This was a quick and short introduction to nested resources. There is a bit more to them, but this enough to start writting Rails applications.

In the follow up, ‘plain text editor’, post we will see a nested route being used a slightly larger application. In that post we will look far more than just routing, that is why I took it out of this part. I will finish that up ASAP.  I hope you have enjoyed this post…

- Thank you, Daryn

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.

When talking about lean software development we often refer to KISS (Keep It Simple Stupid). I agree with keeping things simple but I don’t like to be called stupid, the truth hurts. I prefer to use: Keep It Simple and Sensible. This is more positive and the sensible part indicates that we should give some thought to our code. For example, instead of littering your code with conditional statements you could refactor the code to use an established design pattern. Having said that, design patterns are not always a good idea.

You should not implement a design pattern unless there are real signs indicating that you need a smarter solution. It can be detrimental to implement a design pattern for the sake of having one. You are likely to implement the wrong pattern and that code will be a hindrance. Only do what you really need to do. This is also referred to as YAGNI.

YAGNI (You Ain’t Gonna Need It) – This is a term used by Russ Olsen in Design Patterns in Ruby. In this book, Russ Olsen does a fantastic job of explaining design patterns. He also explains when not to use certain patterns and the problems that come with using each pattern – After all, software is about trade off’s.

Russ Olsen explains that we should not write code or implement patterns in anticipation of a requirement that might emerge. Firstly that requirement may never surface, and if it does it may have a stipulation which makes the pre-emptive solution void. It is safer to code to meet the current and real requirements of the system. To drive this point home, here is a delightful paragraph from Russ Olsens’ Design Patterns in Ruby:

“Look at it this way: Barring a sharp blow to the head, as you stand here today you are as dumb as you ever will be. We are all learning, getting smarter every day. This is especially true in software projects: You can be sure that you will have a better grasp of the requirements, technology, and design of any software that you work on at the end of the project then at the beginning. Whenever you put in a feature before you really need it, you are guilty of programming while stupid; if you wait until you really do need the thing, you are likely to have a better understanding of what you need to do and how you should go about doing it.”

The moral is: Don’t be guilty of programming while stupid