Kanban - A small practice project

A few months ago I completed my first Kanban project. The team was small and the introduction informal but it went well.



Background

The team comprised 5 people. A technical manager, 3 web developers and me. They managed many projects simultaneously which resulted in a great deal of task switching for the developers.

There were no detailed plans and few team planning sessions. The technical manager was able to keep track of the teams goals on the fly. As tasks and priorities changed, the team would be notified.

Three of the team members had experienced a full agile project in the past which resulted in the team continuing daily stand-up meetings. They stated that they wanted to continue using TDD but that hadn't persisted as strongly. While one of the developers had used TDD in the past, they did not use it consistently, and the rest of the team did not have any training on the technique.

Project

The project was estimated at 2 weeks and involved a UI replacement of an existing web application. A couple of minor business flows were going to change but essentially it was just large segments of the site getting new HTML/CSS. All HTML/CSS was developed by a 3rd Party design company so the in-house work was limited to verifying what was delivered and implementing the designs.

Process

We started with a little presentation on what Kanban is. Ran through some examples of how a project might be run with a focus on software projects. The whole team was in attendance along with a couple from other teams and a Director.

Feedback seemed good with statements like "We need something like this" and "I wish we could get all teams to do this".

From there we got the team together to chunk up the tasks and played Planning Poker to come up with some high level estimates on how long it would take. Each task was written on a post-it note and stuck on a white board in the left hand column ready to be pulled forward into the work in progress.

The columns we started with were:

o Backlog
o Work in progress
o QA
o Complete

Even though "everything had to be done" it was agreed that some were more important than others so a loose prioritization scheme was devised that ensured that the correct post-its were pulled forward first. The manager took on the role of adding priorities to post-its in the Backlog column when needed.

Results

Team members initially needed some encouragement to move the post-its on their own. This soon past as they were offered the opportunity to take control of the work they were going to do.

By the end of the first day we had blocked tasks. We started adding red stickies to the post-its but eventually moved them to a new blocked column between the Backlog and Work in Progress columns.

When asked, the team said they liked the process because it helped them see what was needed and completed.

A great indicator of the teams investment was the exclaimation "Wow, look how much we have got done" as they looked at the completed column full of post-its.

Since the team was switched to and from other projects the estimated two weeks was not an elapsed time but the project was released before the business needed it.

Comparison with Agile

We did take the time to estimate the stories which wouldn't necessarily be part of a Kanban project. However, there was concern about the completion time which needed some up front guestimates to allow the team size to be predicted.

Beyond release estimating, no time was spent planning what tasks should be worked in the first iteration. While it was only a two week project, in a Scrum or XP project we might have tried for 2 one week iterations. Not doing this did save us a little time and since the Kanban board continued to show tasks getting completed there was always a clear understanding that things that were getting completed.

Additionally, without iterations we didn't ever ask ourselves about what to do if we had not finished the estimated work in the iteration. Instead we maintained the column constraints and monitored how long items stayed there.

If this team ran all their projects using Kanban, the lack of planned iterations might allow some projects too fall through the net. This can be handled with simple organizational changes so shouldn't be a risk.

Grand Rapids Give Camp - Cincinnati Satelite - Retrospective

What an excellent time, hanging with friends, meeting new people and the opportunity to help out some charities at the same time.



I first heard about Give Camp when Mike Wood published his involvement at one of last years events. When Mike mentioned Grand Rapids I knew it was something I wanted to be involved with. Only a 5 hour drive from Cincinnati but it turned out that the drive was not going to be possible. Fortunately, with some great support and nagging from friends I decided we needed to organize a Cincinnati based satellite to see if we could help out.

Now that it is over, everyone is talking about doing our own in Cincinnati next year so here are some memories to remind us.

Over the coarse of the of the weekend twelve local developers volunteered their time and were able to contribute to 5 different projects with their Rails, PHP (Joomla/Drupal) and .Net (dotNetNuke) experience. A great diversity of skills allowed this group to really make a difference.

Thanks everyone, you rock, Rob Biedenharn, Brad Leydorf, Phil Japikse, Mark Haskamp, Frank Glandorf, Kevin Longshore, Bill Barnett, Gerard Sychay, Sunil Kommirshetty, Brian Harwell, Andy Douglas.

It was great working with the Grand Rapids team, Chris Woodruff, Ryan Montgomery, Carl Furrow, Luke Rumley, Emily Stoddard and an apparent endless list of others that I never got to talk to.

However, as with all experience, it wasn't just buttercups and blue bells. As a remote team we experienced the usual problems that distributed developers face. We had a hard time connecting with the teams in Grand Rapids. To make Give Camp Satellites more effective they really need full Voice/IM connections with the teams they work with.

On the first night Luke took on the the role of runner and was great at matching the experiences we had in Cincinnati with the work opportunities up there.

The second day involved us bugging people we learned about on the first day to see if we could help. We heard that they were mostly involved with design work and we were not UI people so the pickings were lean to start with. As the day rolled on we started getting more hits and ended up being able to make some real connections and contributing some positive changes.

The last day left us with one, particularly difficult, bug to address which ended up taking input from 5 developers, over 7 hours, to find the eventual 2 character fix. Oh Safari, the pain you put us through.

As the closing ceremony started in Grand Rapids, we had our own celebration with the most popular food of the weekend, a giant bag of M&M's and promises to work on a Cincinnati Give Camp next year.


Thanks to EdgeCase for donating their Cincinnati office space, and for those that work there, letting us use their desks and plug-in to their monitors.

Thanks to Finagilous for supplying food.

Some pictures:

EdgeCase Office
All Volunteers waiting for work
Bill, Frank and Mark
Rob and Bill
Kevin, Ed and Andy
Bill and Rob

Security and Quality through Testing or Process?

As an Agile software developer I talk alot about testing. I promote and teach Test Driven Development and push to change the habits of developers to encourage quality traits that make the software we produce just work.

I want to draw a distinction between the understanding that I am "testing" and the fact that I am following a "process". This may be moot in the grand scheme of things but it strikes me as important because of a sentence I was about to make to a security professional.

Consider this:

As a software developer, my primary goal is to make software work.

A QA developer is focused on making software NOT work.

This is why I am not capable of testing.

Similar logic demands that
I am not capable of producing secure code.

The problem with this logic is that is contradicts everything I teach. Test, test, test but, oh by the way, you are not capable of succeeding.

So, perhaps I should describe TDD as a development process that improves quality instead of a process that tests code. While the eventual result is a set of tests that verify features of code, the developer gets there by following the TDD process, not by trying to make things break.

This is not a statement of whether TDD is a design process or not. Different discussion. I am addressing developer intent, not defining the outcome of the TDD process.

In TDD we first follow a simple mantra:

Run the Test,
Change the Test,
Change the Code,
Repeat every 60 seconds.

Step two of this process could be argued to be an attempt to break code. However, this is not true since all we are doing is writing tests that will break because the functionality is not implemented yet.

TDD offers us a process to ensure that we end up with a suite of testing code that matches our running code. So TDD is not a testing process, just a development process that encourages a higher quality of working code than other processes.

From a higher level, the software development process we use already "values" a Quality Assurance team that double checks the work that we do. These people focus on breaking our code and do a really good job at it. They are a critical step to producing reliable software.

Another important role that software developers are unable to be good at is producing secure code. While we can learn the best practices and gain an understanding of the OWASP Top 10 attacks we are still trying to make software work for the business, we are not trying to prevent customers from attacking it.

Even with this problem, the software development process doesn't "value" a security organization reviewing the product that is produced.

Our industry is just starting to learn how to integrate security intelligence into the software build process and, to date, we software developers do not have a Security Driven Development process to improve our odd for success.

Scott Ambler's 2003 article predicted its creation in 2004 but his predicted internet shutdown wasn't as impressive a game changer as he thought. Unfortunately, that remains a learning curve in our future.

Dynamic vs Static Typing: An Observation

This is a dynamically typed language


pron. This v. is prep. a adj. statically n. typed n. language

Careful, Java Programmers going to Ruby

Good evening everyone, I am a Java programmer.
It happened quickly, I didn't even notice.
One day I was merrily strncpy'ing and the next it was immutable.

We joke about languages of old while new shinny languages are paraded in front of us, but in the end they all teach us something and make us forget other things.

Today I came across the first serious change that the Java world thrust upon my weak mind. I am working a Ruby project, a great new shinny language which is lots of fun to learn and work with.

When working in Java I use the usual Agile development process; write your test, write some code and repeat. As I progress, my code, and indeed the API design, evolve into a nice usable, stable set of libraries.

Working in Java, with Eclipse, the simplest technique is to start by writing your test, reference a public method, press a key to create it and flush out the implementation. As you go, you will naturally refactor pieces of code into new methods to keep it simple.

Well, this is where things get a little too easy for Java developers in Eclipse. To refactor a block of code into a new method just select it, press a couple of keys and Eclipse creates the new method for you. A new private method in the same class.

Sounds good right? Well it is, except, that you have now learned to not thing about the scoping your your methods when you create them. Your first is always public or protected because your test is driving it and subsequent methods are private by default as created by the IDE. It's a beautiful system.

Now you switch to Ruby.

You write your test and implement your public method, you refactor with the cut/paste/rename/suffle and low and behold, because you have learned not to think about it, you have loads of public methods in your class.

The project I am working on takes it one step further and has tests for every method, examining all its nuances, mocking all its dependencies and going to town making the implementation as couple to the test as possible. It's easy to do, they are all public, what else is a programmer to do?

Unit testing philosophy does vary depending on who you talk to but my basic goal is to:

• Test all public methods,


• Test all protected methods,


• If a private method is particularly complex make it protected and test it,


• If I have loads of "untested" private methods I need to move some to new classes and make them public. I leave it to you to quantify "loads".


• Trust your coverage tool to tell you the private code you never use and delete it.

So, starting tomorrow, I change my Ruby development process and consider all new methods private unless part of a test driven process. This will do lots of things to improve the final product:

1. Simplify the test/code dependencies making the tests less brittle.


2. Prevent call sequence bugs where you have to call one method before another or it all falls over. Too many publics will do that you know.


3. Make the calling conventions exposed by the class easier to grok by new programmers reading the code.


4. Improve Class API design which is one of the primary benefits of TDD, lost to the lazy public manic people like me.

Oh, yes, an stop putting java semicolons in Ruby code. That really upsets the Ruby people.

Tests and Blank Lines

Add blank lines please.

This might sound stupid and, indeed, alternate DSL's for unit testing are making this less of an issue but there are still a lot of the old XUnit frameworks that prevent isolation of the 3 areas of your tests.

Every test you have needs to be setup, executed and validated. Let's start with a Java example.

public static void testSomething()
{
Address address = new Address();
address.setName("The House");
address.setLine1("1234 Street Ave");
address.setCity("Cityville");
address.setCountry("US");
address = dao.geocode(address);
assert_equals(-86.234, address.getLatitude());
assert_equals(46.234, address.getLongitude());
}


What does this test do? Which lines of code are being tested? Ok, lets try again with blank lines.

public static void testSomething()
{
Address address = new Address();
address.setName("The House");
address.setLine1("1234 Street Ave");
address.setCity("Cityville");
address.setCountry("US");

address = dao.geocode(address);

assert_equals(-86.234, address.getLatitude());
assert_equals(46.234, address.getLongitude());
}


Doesn't that help? A simple change and you can clearly see the three areas of your code.

I hear you shout "setup method", I know but junit sucks in that the only way to write enough tests with enough setup's is to have lots of separate test classes. Certainly go that way if you have a complex class to test but simpler stuff can be done in one class with a little setup and tests with blank lines.

OK, what is the future of these blank lines? Well, Ruby has unit test libraries like Shoulda that make these concepts easy to express.

context "an address" do

setup do
@address = Address.new(
:name => "The House",
:line1 => "1234 Street Ave",
:city => "Cityville",
:country => "US"
)
end

should "be geocoded to a specific lat and long" do

@address = @address.geocode

assert -86.234, @address.latitude
assert 46.234, @address.longitude
end
end


This allows us to separate and describe the areas of our tests, however, common usage has taken this API to the next level which, I think speaks to the need for the original idea behind the blank lines.

context "an address" do

setup do
@address = Address.new(
:name => "The House",
:line1 => "1234 Street Ave",
:city => "Cityville",
:country => "US"
)
end

context "when geocoded" do

setup do
@address = @address.geocode
end

should "have a specific latitude" do
assert -86.234, @address.latitude
end

should "have a specific longitude" do
assert 46.234, @address.longitude
end
end
end


As you can see, the use of the sub-context for each "test" and the use of the setup method to actually run the test, allows us to isolate the specifics of what the test is all about and describe each area.

Extreme Arguments and the Slippery Slope

So often we hear doubters ripping into ideas for their "potential" for destroying the world we know. Why the crazy extreme?

Most recently it was argued that code refactoring was bad because a programmer will spend so much time "perfecting" the code that they will never finish the project.

Another, states that we spend so much time unit testing that we don't write production code.

Another that you have to "corrupt" your beautiful domain design so much to make it testable that it makes OO irrelevant.

The Republicans are doing with the whole stimulus thing. A few billion spent means that we are on the slippery slope that results in the government owning every house in the country.

The "Slipper Slope" argument is the favorite argument of the person that doesn't have an argument for the proposal on the table.

Perhaps we should attempt assess the benefits of a proposal based on the proposal.

If you don't understand why something is bad you should not announce your opinion about your fears of what it might lead to. If it ends up leading there, announce away, until then, lets improve our world one step at a time.

Sticking to the facts is the single hardest thing we do. Especially, since facts can be a little slippery themselves.

Garmin nuvi 760

I had a Gadget Frenzy this morning that worked out quite well. This years birthday produced a Garmin nuvi 760 which will prevent me from getting lost unless I am too busy playing with its features to notice the turns it is telling me about.

Oh, by the way, don't play with your Garmin while driving. This is the first and largest warning the device gives you, even ahead of the one about how the device may, or may not, get you where you want to go.

This device also includes an SD Card slot and mp3 player, plus Bluetooth phone headset connectivity, an FM transmitter and an audio jack. Oh, and a picture viewer, but what on early is the point if that.

Unfortunately the FM transmitter is no use in Cincinnati because all the radio stations are too close and powerful, however, the audio jack and an audio cassette adapter work wonderfully.

So, imagine the scene. Car stereo blaring but with no sound, just yet, a fresh set of podcasts loaded onto the SD Card and a willingness to connect as many pieces simultaneously as possible.

Select the media player on the Garmin, create a play list and hit play for the latest episode of Furled Sails sailing podcast.

Hit Back and select "Where To" enter my work address and press Go. The mp3 pauses and a nice lady with British accent says, "Please drive to the beginning of the route" and back to the sailing adventures. She even says route like the Brits say it, root, I had forgotten, how sweet.

My Treo 650 Bluetooth has already synced with the Garmin so if someone would call me, please, we can have all three audio streams passing through this device, hopefully, appropriately paused.

So my problem now is, do I continue listening to the Sailing podcast or switch over to my His Excellency: George Washington audio CD. Either way, I should arrive at my destination, precisely at 8:29am.

Wordle - like a tag cloud but wordier

A Wordle creates a word cloud of your blog

or capture the state of the world at a single instant.

Prototype Ajax Responders - Disabling

The Prototype Ajax API allows us to make requests to our web servers very easily. It also supports Responders that allow you to declare standard behaviors to occur before and after your Ajax calls, like show the spinning ball and dim the page and fun things like that.

The nice thing about this approach is that you don't have to worry about setting up these behaviors around your send and receive methods for each call. Instead, they just work, until you don't want them to.

I have a session timeout popup that needs to submit an Ajax request to tickle the server session stopping it from timing out. I do not want my standard behaviors occurring since this is not a modal interaction like all my other Ajax calls.

What I need to do is let my "responders" know that this is not a call that I want handled. This is my standard Ajax API that wraps the prototype call. As you can see, I am enforcing a json interface to the callback supplied by my application.

var Url = Class.create(
{
get: function(a_url, a_callback)
{
new Ajax.Request(a_url,
{
method :'get',
onSuccess : function(a_transport)
{
var json = eval(a_transport.responseText);
a_callback(a_transport, json);
}
});
}
});

The behaviors I am using are simple dimming of the background and the usual spinner image.

Ajax.Responders.register(
{
onCreate : function(a_request)
{
if (Ajax.activeRequestCount >= 1)
{
document.body.addClassName('ajax-processing');
new Popup('spinning_wait',null,
{
position: 'screen',
modal:true,
effect: 'blink'
}).show();
}
},
onComplete : function(a_request)
{
if (Ajax.activeRequestCount == 0)
{
$('spinning_wait').popup.hide();
document.body.removeClassName('ajax-processing');
}
}
});

So the problem is how do I specify, at call time, whether a specific Ajax call should be modal or not. Fortunately, the Prototype library passes the options to your Responders so that you can push in variables as you like.

To do this add your own options to your Prototype Ajax call.

new Ajax.Request(a_url,
{
my_custom_modal_option: true,
...
});

And in your handlers you can access this custom option.

onCreate : function(a_request)
{
if (a_request.options.my_custom_modal_option)
{
...
}
}

You can of coarse pass in any property name to drive any kind of behavior you like.

2D, 3D and 4D Languages

If you are looking for something about graphics, then go away. Nothing of interest here.

I want to coin some terms that allow us to describe the languages we use. Nothing fancy but we might find it useful to limit the pro/con discussions and abstract them to something simpler.

We have talked bout 3rd Generation and 4th Generation languages to allow us to conceptualize the abstractions at the language level as opposed the class level. 4G languages are still being sold by those after some money but continue to be generally despised by programmers that can't make them do what they need.

OK, so why add the concept of a dimension here? Well, it probably has something to do with how my mind works and is not necessarily anything anyone else might share but when you say "refactor these lines into another method" I see that as a vertical or horizontal shift in behavior. Perhaps they are being generalized into a base class, vertical obviously, or moved into a delegate class that would be a right shift. These are 2D movements performed in all languages but C, for example, is limited to these kinds of adjustments.

Some languages are able to move along the Z axis. Object Oriented languages add to the 2D shifts the ability to distribute behaviors across instances, while not being able to vary behavior along this axis they are varying state and therefore execution paths vary by vertical plane. Each layer represents a keenly scoped set of behaviors driven by the state passed in. These are cones of execution, from a single method entry point at the tip of the cone, the state is distributed out across a set of associated instances to apply the appropriate behavior.

These 3D models become more complicated when you consider how some line of code inside a cone might throw an exception that provides a pipe to some layer of your application, in-front-of and left-of the throw point. It produces a hole in the side of the cone where flow can pass to another location.

Cones are contained within other cones of coarse, the applications main method being the pointy end of the outer cone. The API design rules we apply like no globals, no leaky abstractions, scope actions on state within their own class, all go to explain why no cone sides should ever intersect.

If you are still with me, then on we move to the 4th Dimension. I don't know how you conceive this in real space but I tend to look at the time dimension as a set of invisibility cloaks. As you move forward throw the cloaks, the last set of 3D stuff you were looking at disappears and another set appears. Presumably, we could move backwards to start seeing back in time.

Well Ruby, and other dynamic languages, have started playing with this dimension. Each instance, executing it's methods in it's cone, can be changed at runtime. A call to File.new here is different from the same call there. This allows us to evolve what is being executed based on state, time or idle whim. Code is data, data is code.

Now these concepts have some evolution ahead of them since these changes are made at "indiscreet points" at the moment. So I have to make the change and then execute that change. I can't encapsulate a change and an execution into a single language concept but these are just the semantics we play with today.

Behind each invisibility cloak is a 3D model of a runtime. Each model contains a set of finite behaviors and their changing state. Any statement that mutates it's own behavior, creates an invisibility cloak.

Don't confuse these with threads. Threads are shiny, sparkly little stars, like the sparklers from fireworks night, that run around your 3D cones doing stuff. There may be many of these things in a single 2D or 3D model, all buzzy and excitable. Some running around the same cone, trying to find your threading bugs for you but as long as your cones don't have cracks you will be fine.

When you hear Ruby programmers arguing about that there are no static methods in Ruby, what they are saying is that Ruby is a 4D language and the person they are arguing with only knows 3D languages. It's just like the old arguments that prompted 2D experienced people to say that we could do anything in C that you could do in C++. Yes, I used to argue that one back in the day. Fundamentally true only because it's also true that you can build a house with matchsticks if you really, really wanted to.

Ruby offers far more than just it's 4D features. Open classes, modules and closures are different ways to describe static, 3D concepts. A language becomes 4D when it can vary it's behavior at runtime. This isn't a new concept on it's own. I used to write basic programs that added code as it ran 20 years ago but this is more than this simple concept.

When we look at programming we talk less about the detailed syntax of how features are coded and more at the best constructs that survive change and optimize re-usability. We don't have many strategies defining how to mutate code as it runs to augment the runtime model that is executing.

The best proof that I don't know what I am doing in 4D is to look at the invisible cloak. I think this shape needs to change to better describe the scoped change that a piece of behavior might adopt.

I wonder what 5D means?

BDD test framework Shoulda

Behavior Driven Development is an interesting slant on testing. There appear to be many opinions on its advantages and disadvantages. At the end of the day, if you are testing, you have already won.

So, the question is, how can you tweak your method to improve on your bugs-per-line-of-code metric. This post isn't about that because I have no idea if BDD or Shoulda will help.

Shoulda is an alternative BDD framework to RSpec that has been argued about for so long. I can't help you with that either.

Instead, I just started using Shoulda in a Rails app so thought I would share some complaints, because being constructive is just too much work.

I switch a simple controller test over to Shoulda and it ran and passed but the original 3 tests that used to pass are now reported as "0 tests, 0 failures, 0 errors". While I proved that if there was an error it did explain precisely what was wrong to me, this 0 tests thing is severely demotivating. It is amazing how watching the number of tests grow in your project can encourage you to continue to strive for perfection.

IDE integration is always a problem with new stuff. NetBeans allows me to run a single test case with ctrl-shift F6 which is convenient if you have few that are suddenly failing. No such luck with the Shoulda version, all tests all the time.

However, all this is trivia compared to being able to do something like this:

require 'test/unit'
require 'shoulda'

class Lion
def speak
"rarrrr hickup"
end
end

class TestLion < Test::Unit::TestCase

context "the lion" do
setup do
@lion = Lion.new
end

should "say rarrr" do
assert_equal "rarrr", @lion.speak
end
end
end

and get this explanation of what you did wrong.

1) Failure:
test: the lion should say rarrr. (TestLion):
<"rarrrr"> expected but was <"rarrr hickup">.

Craft your feedback as carefully as you craft your output.

Definition of old technology

A technology is old when Google returns forum hits with answers that have since been deleted from the forum.

Struts 1 still blows.

Christmas 2008 Connections

Another slant on this holiday period. Our family combined presents this year and find ourselves with a new 40" LCD 1080p TV, cheap by comparison. Expensive were the new cabinet required to hold it, cables to plug it in and investment in time admiring the details of the baby wilder beasts eyelashes as the croc eats them off.

Well this post is about connections because it seems all I have done is work out how to connect apparently useful devices together to produce alternate results. Lets start with the new WII.

The best way to by a WII is to purchase your kids college education using the National City Bank card and then use the points you accrue to invest in a gaming system to take your mind off the amount of money it cost you. So this "free" WII was plugged in using a low def composite cable (1) since Mario in low detail is still Mario.

The WII is internet connectable so that you can use the WII Shop online, oh how convenient that is. So a simple DHCP connection to the Linksys wireless router (2).

The welcome screen of the WII shows a set of "channels" to select. One is the CD with the game you plugged in last, another the WII Shop Online channel. Well if you head off to this shop you are offered additional channels to purchase in the "point" currency. Each "point" is equivalent to 1 cent US so the fact that it is a "point" only serves to help you forget you are spending real money. One of the items to purchase for a very reasonable 500 points is the "Internate Channel". I could not resist (3). What it appears to do is download and install a cut down version of the Opera browser into your WII so that you can navigate the web with with the WII remote. No flash, no video support but very large buttons to shoot with your WII remote. On the whole not a bad experience.

I needed to backup my Mac so invested in a Time Capsule which is a little white box that you plug some power into and hey presto you have backup (4). My first full backup took 27 hours. Needless to say the wireless part has a down side, however, now that it is just doing delta backups it is great. The Time Capsule is also a wireless access point but it didn't seem necessary to add a third subnet to the house.

A long time ago I was lucky enough to win a high end XBox from the Cincinnati DotNet User Group. Well it was finally time to crack the seals and see what she could do. A special high definition connection to the TV with the switch on the side of the cable set appropriately (5) gave us an excellent view of videos and music that we could buy if we wanted to. See, I only buy things that give me the option to buy more. If only Paulson could have come up with this strategy.

It didn't end there, with all these things to buy, what should one choose? Oh yes, Netflex, instant streaming of high def video through my XBox onto my TV, what could be better. Plus, bonus of bonuses, free for the first two weeks. I am in (6).

To hook up Netflix Instant Viewing through your XBox is not too hard but does require a little "out of the box" thinking. Firstly, spool through the stream of adverts that the new horrendous XBox console throws at you until you find the randomly inserted Netflix. Sometimes it doesn't appear, so you have to go out and back in until the right random ad appears. I was persistent enough to beat the ad rampage.

Once you click on this ad it downloads and installs something magical on you XBox that does nothing. Well I say nothing because it didn't do anything except tell me to go and find my computer and access the Netflix web site to create an account and enter a six character code.

Once you have created your account and entered all your relevant bank draining information you are ready to go. The first thing we did was go back to the XBox and try to work out how to get a selection of movies. That will not work. Don't do it. Wastes lots of time and there is likley some frustrated screaming and a little cussing going on as well. I feel sure this is in the Netflix business goals, "Maximise setup frustration to optimize relief when complete".

Instead, stay on the Netflix web site and select the movies you want to watch. Don't "Play" them even if it asks you to, that will just show them on your PC. Don't "Add" them because that means they will be arriving in the mail in a few days. Instead you have to find the few movies available for "instant viewing", hover over the "Add" button (don't click it), and a secret menu opens up inviting you to add the movie to your "instant queue".

Finally, with movies in your instant queue you can go back to your XBox controller and they will appear in the list of available moves to watch. Note, to go back into that list on the XBox later you will have to go and find the randomly displaying Netflix advert which offers you the opportunity to practice your zen deep breathing. We chose "Then she found me", some might call a chick flick but I call a delightful romp through the hideous decisions people make when in love.

Connection (7) is the XBox Extender which allows me to use the Media Center app on our little, slow, wireless connected laptop as a movie streaming hub. Yes, you guessed it, it's damned slow. However, we did find a nice use for it. It will play a slideshow of all the photos you have on your PC which allowed us a few minutes of joy with the "oohs" and "aaahs" and "do you remember that? No? Damn it thats were we met?" moments of our past.

The next connection is to my Mac Book Pro. Another $20 and I am in posession of a fine looking cable, kindley posted to me by my friend Apple. This connects the DVI port on the Mac with the HDMI port on the TV (8). The 17" laptop screen runs at 1920x1200 and the 40" TV runs at 1920x1080 interlaced. So if my post Christmas figurin' is anything to go by, a TV pixel is 2.3 times bigger but only 9/10ths the relative height. This makes for a grainy hard to read image that I can't distinguish the "i"s and "l"s on.

The last planned connection is a 17" 5x7 LCD picture frame to a 4G SD card from our camera (9). This was my present to my wife, the idea is, and note, this is how you make cool techy gagits romatic, that each time a pictures changes a new emotion enters the room. Say it together, aaahhhh.

The moral of this story is that connected life is an amuzing way to while a way a cold Christmas week.

Christmas 2008

Yes, it happened again.

3 days ignoring family squabbles,
1 day opening presents and contemplating their impact to debt,
2 days loosing battles with chocolate covered cherries,
1 additional day loosing the battle with Bourbon Fudge,
2 days contemplating why we do this,
3 days rebelling against productivity, staying up till 3am watching bad movies,
1 day realizing that time is running out so, re-insulated the attic to R49, replaced two windshields and a failing septic tank motor. Oh, correction, watched hard working people do these things.
1 day remembering how lucky we are,
The last day noting that this is going to happen again next year and there is nothing you can do about it so just smile, damn it.