Mendelt Siebenga

Acer Iconia A500 review

2011-09-01T22:11:00.000+02:00

A couple of weeks ago I bought an Android tablet, the Acer Iconia A500. Today I received an email from Acer asking to fill in a short survey to tell them what I like and don't like about my new tablet. I might as well share my thoughts on this tablet in a short review on my blog.

The Acer Iconia is one of the first generation Android Honeycomb Tablets. The specs are pretty much interchangeable. Dual core 1 GHz Tegra 2, 10 inch 1280 x 800 screen etc. Just like the Asus Eee Tab and the Samsung Galaxy Tab 10.1 and many other tablets that will probably follow. Instead lets look at what makes the Acer different from all these similar tablets. The tablet is available in a 16 and 32 Gb version and you can choose if you want it 3G enabled or if you just want to use Wifi. I went for the cheapest version with 16 Gig and no mobile internet.

First lets look at the positives
The reason I went for the Acer is connectivity. Besides the standard connectors this tablet has a mini-HDMI connector and two USB ports, one for connecting to a computer and another one that can act as a USB host so you can connect a keyboard, a mouse or even external harddrives.
I'm not a big fan of proprietary skins on Android devices. I rooted my HTC Desire phone to get rid of Sense so another reason to choose the Acer is the version of Android installed on it. Apart from adding a couple of its own apps Acer hasn't changed a lot about the standard Honeycomb experience. This is the closest you can get to vanilla Honeycomb without rooting your tablet.
And last but not least I just like the way this tablet looks. The two dark metal strips along the longer sides make it stand out from other tablets. It looks and feels well made.

Of course there are also a couple of minor issues with this tablet.
First of all there is Android itself. I got the tablet with Android 3.0 installed and even though the OS itself feels stable and responsive many of the applications that were preinstalled felt flaky. Especially the Android Market and the browser crashed a lot. With the update to 3.1 many of these problems were solved but the Android Browser is still very slow on pages with some javascript. I expected better from the company that made Chrome.
Another thing that irritates me is the power adapter. It has a very short chord so when you're charging you have to sit within 1 meter from a power outlet if you want to use your tablet. And instead of connecting to the mini USB connector like most phones the tablet has a separate power connector so you can't charge the tablet from a computer.

All in all this is a really good tablet. The extra USB connector is something that is very usefull in every day use. I often just connect the keyboard from my computer when typing email and you can easilly plug in a USB stick to watch a movie. Compared to the iPad the screen dimensions are better for media consumption. You can watch widescreen movies at 720p.

Building Android projects with Jenkins, Ant and Mercurial

2011-08-03T14:44:00.000+02:00

I have recently set up a Jenkins build server for my Android projects hosted on Bitbucket. It’s not difficult but there are a couple pitfalls and the information on how to do this isn’t available from one single place so I decided to document the process and put up the information over here. Maybe other people will benefit from having a step-by-step guide too.

I'm using Bitbucket to store my projects so I'm going to use Mercurial for source control. I want to use SSH for authentication. It's a bit more of a hassle to set up but I don't like to store my Bitbucket credentials in Jenkins.

Right now I'm using the generated ant build scripts. I might switch to Gradle or Maven in the future so stay tuned for updates.

These are the versions I used for this guide:

Ubuntu Server 11.04 Natty Narwhal (I love typing these names)
Mercurial 1.7.5
Jenkins 1.423
Java OpenJDK version 1.6.0_22

Preparation

I’m assuming you already have a fully functional machine with a Debian flavored OS like Ubuntu. If you want to use another Unix need to replace all the apt-stuff with the package manager of your choice.

First let’s get our system up to date and install a couple of prerequisites.

apt-get update
apt-get upgrade
apt-get install openjdk-6-jdk ant mercurial

If you’re running on a 64-bit system you will also want to install ia32-libs to enable the Android SDK to run in 32-bit mode.

apt-get install ia32-libs

The Android SDK

Now we've got that over with lets get started for real. First we need to decide where we want to put the Android SDK files. I chose /opt/ But you can put it anywhere you want. Lets download and extract the files we're going to need there

cd /opt
wget http://dl.google.com/android/android-sdk_r12-linux_x86.tgz
tar xvfz android-sdk_r12-linux_x86.tgz

This will download and extract all the files to /opt/android-sdk-linux-x86.

The last thing we need to do is to update the sdk. This will make it download all the files it needs to actually build stuff. It's easy to get confused here because normally you'd do this with the GUI the nice people at Google built for us. But when you're logged in to your build server through a terminal like me this won't work. Luckilly it's easy to update the SDK from the command line.

/opt/android-sdk/tools/android update sdk -u -f

This will just download all the available packages. The -u switch keeps the SDK from trying to show any UI. -f forces it to overwrite any previously downloaded stuff if there is a newer version available. Remember to do this whenever there are new versions of Android available.

Now go make some tea. This will take a while.

Setting up Jenkins

The next step is to set up Jenkins. This is a bit easier because Jenkins is available as a .deb package. You can add the Jenkins repository to your sources and then install it.

echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list
apt-get update
apt-get install jenkins

You now have Jenkins running on port 8080 on your server. Unfortunately Jenkins is wide open after you install it. Let's set up some password security first.

Go to http://:8080 with your favorite browser and select Manage Jenkins/Configure System Select Enable Security Go to Select Security Realm and select Jenkins's own user database Now click Save at the bottom of the screen.

Now you can add some users who have access to Jenkins. Select Manage Jenkins again, now go to Manage Users to do this. The link to add a user is hidden on the left side of the screen.

After you've finished adding users you have to go back to the Configure System screen and select how you want to authorize users. For Authorization select one of the last three choices depending on how much control you want over what users can do.

Source control

Now lets see if we can get Jenkins to get our project from Bitbucket. First we need to install the Mercurial plugin. Go to Manage Jenkins / Manage Plugins and install the Mercurial Plugin on the Available tab. If this tab is empty refresh the plugins on the Advanced tab.

Now we're going to set up ssh authentication. Jenkins has set up it's own account on the server so we're going to create a keypair for that account and add it to Bitbucket with the right authorizations. That way Jenkins can login to Bitbucket and clone our repository. You're probably still logged in to the command line of your buildserver. Create the keypair like this:

sudo su - jenkins
cd
ssh-keygen -t
less ~/.ssh/id_rsa.pub

Just use the default path for the keys and press enter when you're asked for a passphrase. The last command lists the public key Jenkins will use to access your repository. Copy this key go to the account settings on your bitbucket webpage, look up the box with SSH keys in the title, paste in your key and click Add key. That's all there is to it.

Now we should be able to clone our repository. Make sure you're still logged in as the Jenkins account in your terminal and type:

hg clone ssh://hg@bitbucket.org//

You'll probably be asked if you want to add the bitbucket key to the list of known hosts. Type yes and go on, Mercurial should now get your complete project for you.

Configuring the build

Point your browser to your Jenkins page again. Log in and select New Job. Type the job name for your build and select Build a free-style software project. And press Ok

Select Mercurial for source code management and type

ssh://hg@bitbucket.org//

for your repository URL. Set the branch to default and you're good to go. No need to enter passwords because we set up SSH earier. Click Save and test out if Jenkins is able to clone your repository.

Now all we have left to do is to tell Jenkins how to build our project and we're done. We do this by adding a build step on the build configuration page. Just click Add build stepand choose Invoke Ant

You can now add build targets for Ant. For this example you can use clean and release to make a release build. If your build.xml file isn't right at the root of your project you need to click Advanced and tell Jenkins where to find it relative to your project root.

All we need to do now is tell Ant where it can find the Android SDK. We do this by adding an environment variable in the properties field.

sdk.dir=/opt/android-sdk

and we're done.

Android development resource links

2011-05-15T15:34:00.025+02:00

I've been playing with the Android SDK and I have a growing list of bookmarks to Android dev resources for my own use. I thought the best place to keep them would be here on my blog. That way other people can benefit too. I'll keep updating this list so feel free to add suggestions in the comments.

Official stuff

The Android website
Downloading and Installing the Android SDK
SDK Documentation
SDK Reference
Android tools
UI design guidelines
Android developers blog
Android is open source, here is the source

Tools and libraries

IDE’s: Eclipse, Netbeans, IntelliJ IDEA or Motodev Studio
Android UI utils – Create icons and other assets for your app
RoboGuice - Android IoC framework.

Android developers with blogs

A Commons Blog - Mark L. Murphy from Commonsware
AndroidAudioHacks.com
AndroidBlogger
Android-er
Badlogic Games – Mario Zechner
Android Engineer – Matt Quigley
Wagied Davids
Zero Credibility - Jeffrey Blattman

Android books

The busy coder's guide to Android Development and Advanced Android Development are free books from Commonsware. Their paid subscription will get you more up to date ebooks on Android development.
Android in Action
Beginning Android 3
Pro Android 3

Android community

stackoverflow.com - Developer Q/A site with an active android dev community.
androidforums.com
xda developers - lots of info on rooting phones, some on development
anddev.org

Google IO 2011 session videos

Google IO 2010 sessions

Google IO 2009 session videos

Google IO 2008 session videos

The big move

2011-03-15T14:57:00.001+01:00

People who visit here more often probably noticed that my blog has been down a couple of times the last few months. The problem was that after giving up on hosting it on an (expensive!) windows server I tried unsuccessfully to host my blogengine.net blog on Ubuntu with Mono. I could probably get this to work but it takes too much time and effort. So I decided to move to a hosted blog on Blogger. This way I can spend more time blogging and less time on blog administration.

If you’re on a stylish white blogger page right now you’re already on the new blog. Have fun and expect most of my old content to appear there over time. If you’re on my old coffee themed blog you’ll probably need to move to mendeltsiebenga.nl. Or you can wait. As soon as I have all my content moved over I’ll point mendeltsiebenga.com to the new blog too.

Abusing using

2011-02-14T12:00:00.000+01:00

When we went from unmanaged to managed languages we got rid of the headache of having to do manual memory management. Unfortunately that meant we also lost destructors and with them the ability to do some nice tricks. Luckily we can still do some of these tricks with the using keyword. Lets take a look

One of the nice things you could do with destructors in c++ was to tie the execution of a piece of code to the scope of a variable. You did this by putting the piece of code in a destructor of some object, every time you instantiated that object on the stack you were assured your code would be run when that object left scope.

But wait, we still can do this with using and IDisposable.

Oh boy! Silly example time!

Lets say you’ve got a bunch of freeloading friends. You kept score on how many rounds of beer you bought last night in a dictionary and now you want to confront them with the ugly truth by putting the contents of that dictionary online in an html table.

var rounds = new Dictionary<string,int> {{"Me", 6}, {"Bill", 3}, {"Pete", 1}};

Formatting html tables can be a lot of busywork. You need to keep track of all elements. Every <td> needs a </td>. This can get messy fast!

First we create a helper class that will print and keep track of elements:

   1: class HtmlElement : IDisposable

   2: {

   3:     private string Element;

4:

   5:     public HtmlElement(string element)

   6:     {

   7:         Element = element;

   8:         Console.WriteLine("<{0}>", Element);

   9:     }

10:

  11:     public void Dispose()

  12:     {

  13:         Console.WriteLine("</{0}>", Element);

  14:     }

  15: }

Now printing tables (or any kind of simple html) is easy.

   1: using(new HtmlElement("table"))

   2:     foreach (var row in rounds)

   3:         using (new HtmlElement("tr"))

   4:         {

   5:             using (new HtmlElement("td")) Console.WriteLine(row.Key);

   6:             using (new HtmlElement("td")) Console.WriteLine(row.Value);

   7:         }

Every html element we print is tied to the scope of the using block it’s in. When we get to the end of the block the closing element is automatically added. Simple and pretty readable.

I’ve seen this trick used in all kinds of places where you want a piece of code guaranteed to run after some other operation. Transactions in nHibernate use the same mechanism for example. Keeps you from typing catch/finally blocks around every transaction.

Running a Git repository on Ubuntu using Gitosis

2010-10-06T13:00:00.000+02:00

20I’ve been using Git for a couple of small projects that I’ve been hosting on github.com but version control for my bigger ‘secret’ projects still runs on a windows machine with visual svn server.

Now that I’m starting to use Mono for a couple of projects so I’m playing with linux more. Last week I decided to try to try out gitosis on an ubuntu server. I found out it’s pretty easy to use when you know your way around git but for a noob like me some things weren’t immediately clear. Eventually I solved most problems I ran into, so I decided to write up the steps I took to install gitosis on ubuntu 10.04

I got most of my information from this a blogpost by Gary Dolley, I’ll probably point to this it a few times but this post is from 2007. Things have become a bit easier by now.

If you’re not used to git and gitosis there are two things that might be a bit unclear when you start. So we’ll tackle them first.

First of all there’s authentication. If you’ve used github you should be familliar using public/private key-pairs for authentication but for those who havn’t here’s the short version;

Instead of using passwords gitosis wants you to store a key-pair in the home directory of every computer you use git on. You can then tell gitosis the public key and it uses public/private key magic to authenticate you whenever you push or pull changes. It sounds complicated but its easier to use than the traditional username/password hassle and it’s more secure too.

The other weird thing gitosis does that’s actually very practical when you get the hang of it is that it uses a git repository to store all configuration. This makes management very easy. Want to add a repository? Just pull from gitosis admin on your local workstation, change some config files, commit your changes and push them back. Easy as that.

Enough talking, lets get started.

Installing Gitosis

First we need to get git onto your ubuntu server machine (if you’re using a different flavour of linux things might be different for you. I’ll try to point out possible differences). In the original description you had to pull it from a repository somewhere and then install everything yourself but as there’s a gitosis package available we’ll just use that

sudo apt-get install gitosis

This will install gitosis and create a gitosis user. Next we need to create the admin repository where gitosis stores it’s configuration. To do this we also need to have a public key for the first user we want to give access to the repository. I like to be able to administrate my gitosis server from the command line of the server itself so unlike Gary’s post who uses a keypair from a client machine I’ll just create a key-pair for the user on the machine gitosis runs on. I’ll show how to add more users on different machines later.

ssh-keygen -t rsa

this should do the trick. It will create a private/public key pair in the .ssh directory of your home dir. It will also ask you for a key phrase to encrypt your keys. You can keep this blank but it’s a good idea to enter something here.

Now we can run

sudo -H -u gitosis gitosis-init < ~/ssh/id_rsa.pub

to create the admin repository. Note that the aptitude package has added the ‘gitosis’ user we’re using here. Many descriptions on how to use gitosis run gitosis as ‘git’ so some of the commands look different.

git clone gitosis@{your-servername}:gitosis-admin.git

will clone the admin repository to your home dir where you can edit things.

Adding a (remote) user

You can take a deep breath now, after all this hard work we can move on to the fun (and useful) stuff. Adding users and repositories. Lets get started by adding a user on a remote workstation with rights to the admin repo.

First we need a public/private key pair for the user on your workstation. If you’ve been using github for version control you probably already have a key-pair set up. If not you can create a keypair with

ssk-keygen -t rsa

If you’re using windows you can run this command from the git-bash shell. Be sure to enter a passphrase.

After this you can copy your public key to your server.

scp ~/.ssh/id_rsa.pub {server-admin-user}@{your-servername}:~/

Copy it to the keyfile directory in the gitosis admin repo and rename it to {username}.pub where username is the name you want to use for this user in your gitosis.conf file.

Next edit your gitosis.conf file it should look a bit like

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = {your-user-name@your-server}

You can add the user you just added to members, just use a space to separate user names.

members = {your-user-name@your-server} {your-workstation-user-name}

You update gitosis by pushing these changes back to the repo, git add, git commit and git push work just like you’re used to. Now you should be able to clone the admin repo on your workstation too.

git clone gitosis@{your-server-name}:gitosis-admin.git

Git should ask you for your passphrase. If it asks you for your password instead you did something wrong adding the public key. A common mistake is forgetting the .pub at the end of your key file. If it asks for a passphrase but then still won’t let you in you probably mistyped something in your gitosis.conf file.

Next we’ll get gitosis to do some real work by storing something more than just the admin repository.

Adding a repository

Adding a repository is easy now. First we add a group to your gitosis.conf file. If you followed all the steps until now you can do this from your workstation.

[group {project-name}]
writable = {project-name}
members = {member1} {member2} ...

Push these changes back to the remote repository and gitosis will update.

Now you can create a project directory somewhere on your workstation. Git init, add files, git add and git commit. You can let git know about the remote repository like this

git remote add origin gitosis@{servername}:{repositoryname}.git

and then you can just push and pull from your new repository.

That’s all for now. I hope this will help you. Please let me know if I made any mistakes so I can fix them for the next reader.

JavaScript Tetris update

2010-04-07T13:00:00.000+02:00

Here’s the last post in my JavaScript Tetris series. Time to show the final version of the Tetris implementation I built. It’s not completely finished but I did come pretty far. I only put in a few hours in total. I’m going to race through the final implementation in this post. After this I’ll go back to writing about C#. I promise :-)

There’s a couple of stories I want to implement in this post;

Rotating blocks
Bounds checking. We want to make sure blocks don’t move outside the playing field.
When a block reaches the bottom of the playing field it has to stack up in a wall.

Rotation

The first big change I made was to implement rotation. It’s actually pretty easy to rotate a block 90 degrees. Just swap the x and y coordinates of all the squares that make up the block and make one negative. Negative x means rotate left and negative y means rotate right. To make it possible to rotate around other points than 0,0 I just move the block before and after the rotation. Blocks now have a center of rotation property too.

Bounds checking

In order to implement this easily I had to shift around some object responsibilities. Blocks didn’t know about their position, so in order to know if a block was outside of the playing fields I had combine information from the game object (block position) with information from the block (block shape). It would be more logical to have blocks maintain their own position. After I made this change it was pretty easy to check if a block moved outside of it’s bounds.

tetris0.04.rar (15.32 kb)

Wall

This seems like a pretty big feature but most of the functionality for it was already there. All the wall has to do was maintain an array of blocks and do some collision detection. I had this implemented in a couple of minutes. Hooking it into the presenter and the game object was easy too. I actually spent some time moving the bounds checking logic into the wall object too.

Thoughts

There’s still some stuff missing. You can’t start/stop the game. The game doesn’t detect when you lose. And most importantly it doesn’t keep score. These are all pretty easy to implement but my goal isn’t to build a complete implementation of Tetris. It’s to learn more about JavaScript.

So how do I feel about JavaScript now? To be honest I’ve got mixed feelings. It’s a pretty interesting language. Lots of functional elements. I like that. And I’d like to get a bit more into the prototypical nature of JavaScript objects. But there’s a lot not to like about JavaScript too. I had some issues where different browsers worked differently. For example I wrote some tests checking the type of returned objects that broke in Internet Explorer. On other occasions Chrome and Firefox were too lenient with functions that were passed incorrect parameters and failed in a completely unrelated place.

Oh, and there’s no parameter overloading for functions.

I might be spoiled with my programming languages but JavaScript seems a bit like version 0.9b of a language that’s going to blow everyone away in version 2.0. (and yes, I know I’m going to be flamed for this)

JavaScript Tetris part III

2010-03-28T13:00:00.000+02:00

Here’s just a short update on the Tetris project (if you can call it a project). I had a pretty busy week but I did find some time to play around some more with JavaScript, try out some GOF creational patterns, and build a nice domain model to make working with squares and blocks a bit easier.

This time I wanted to make the falling blocks look like real Tetris blocks. Right now the whole game state is pretty much an x and y position of the falling block, but in order to draw more complex blocks my domain model needs to get a bit bigger too.

The first thing I did was encapsulate x,y value pairs in a Vector object. I built a Square object with an x, y and a color and I built a Block object to hold several square objects to form one of the well known Tetris blocks.

The Vector, Square and Block classes only expose their properties through methods, that way they can’t be changed after creation. Actions on these objects will just return a new object, for example moving a square will leave the old square unchanged. This is something I’m used to in C#, and it looks pretty clean in JavaScript too. Not sure if this is common practice.

   1: function Vector(x, y) {

   2:     this.x = function() { return x; }

   3:     this.y = function() { return y; }

4:

   5:     this.moveLeft = function() {

   6:         return new Vector(

   7:             x - 1, y);

   8:     }

   9: }

This is a small snippet of the Vector class to illustrate my point. The x and y are implemented as functions instead of properties. The Game object stores the current position in a Vector and just calls moveLeft when the user presses the left button to get a new vector one step to the left. This means I go around creating and throwing away more objects. But I have less side effects, which seems more elegant to me especially in a functional-ish language like JavaScript.

In order to make it easy to build the seven types of blocks from code I tried implementing some of the creational patterns. Eventually I things weren’t so complex that I needed a factory object or a builder so I went with a simple factory method ‘buildBlock’.

   1: Block.buildBlock = function(color, coordinates) {

   2:     var squares = new Array();

3:

   4:     for( var i in coordinates) {

   5:         squares.push( new Square( coordinates[i][0], coordinates[i][1], color ) );

   6:     }

7:

   8:     return new Block( squares );

   9: }

Instead of creating this method in the constructor method of Block like I normally do I tacked this method on to the Block constructor. This way you can call it without having an instance of Block, a bit like a static method in C#.

Now I can define the different types of blocks like this.

   1: Block.blocks =

   2:     [

   3:         Block.buildBlock('maroon', [[-1,0], [0,0], [1,0], [2,0]]),

   4:         Block.buildBlock('lightgrey', [[-1,0], [0,0], [1,0], [1,-1]]),

   5:         Block.buildBlock('magenta', [[-1,-1], [-1,0], [0,0], [1,0]]),

   6:         Block.buildBlock('darkblue', [[0,0], [1,0], [1,1], [0,1]]),

   7:         Block.buildBlock('green', [[-1,0], [0,0], [0,1],[1,1]]),

   8:         Block.buildBlock('brown', [[0,0], [-1,0], [1,0], [0,1]]),

   9:         Block.buildBlock( 'cyan', [[-1,1], [0,1], [0,0], [1,0]])

  10:     ];

Pretty clean if I say so myself.

As usual you can download the code and play around with it yourself.

tetris0.03.rar (13.79 kb)

Next up, rotating blocks.

JavaScript Tetris part II – some tests

2010-03-21T12:00:00.000+01:00

Here’s a little update on the JavaScript front. I’ve been busy working on Tetris this weekend. Lots of new stuff to learn and lots to do. First of all I got a list of issues from Sebastiaan Janssen that needed fixing (thanks, that was exactly the kind of feedback I was hoping for). I’ve been playing around with unit testing JavaScript with QUnit. Of course my existing code wasn’t really testable so I had to refactor things a bit too. And I tried to test-drive a couple of small stories.

I’m not going to list all the code I wrote in my posts anymore. It makes for pretty dull reading and you can download the code and read it at your own leisure. I’m sure the code is a lot more readable in your editor than on my blog anyway. I’ll just list a couple of interesting pieces and try to work out more of the concepts in my blog posts.

First of all here are the issues Sebastiaan wanted me to fix:

I’m using the JavaScript const keyword but IE doesn’t support this.
Setting css styles can be done a bit cleaner.
JavaScript in the .html file
You can’t use arrow keys to move blocks. This is a problem on laptop keyboards without a numeric keypad.

The first three were easy to fix, I added a user story for the fourth issue. As this was the only user story that came from a potential user I put it right at the top of my backlog.

Refactoring

I want to start test-driving things, QUnit is a nice new toy that I want to start using. But unfortunately my code is a bit of a ball of mud. Luckily it’s not big so we can’t call it an antipattern yet. But it’s a good time to start separating some concerns.

I want to pull out pieces of functionality and put them in their own objects. Something like a model view presenter architecture would be nice with a TetrisView object to encapsulate drawing and reacting to user input, a TetrisGame object to handle game state and a TetrisPresenter to tie the two together.

This is what the tests look like,

   1: module('tetrisGame');

2:

   3: test('when initializing', function() {

   4:     var game = new TetrisGame();

5:

   6:     equals(18, game.yPos, 'block starts on the right y position.');

   7:     equals(5, game.xPos, 'block starts on the right x position.');

   8: });

9:

  10: test('when running the game loop', function() {

  11:     var game = new TetrisGame();

12:

  13:     game.gameLoop();

14:

  15:     equals(17, game.yPos, 'block moves down.');

  16:     equals(5, game.xPos, 'block stays in the same horizontal position.')

  17: });

18:

  19: test('when moving left', function() {

  20:     var game = new TetrisGame();

21:

  22:     game.moveLeft();

23:

  24:     equals(4, game.xPos, 'block moves left');

  25:     equals(18, game.yPos, 'block stays at the same height');

  26: });

27:

  28: // etc...

I’m not yet 100% happy with them. I like how QUnit pushes you to a context-specification-ish test style. But it’s easy to assert too much in one test which is a bit of a test-smell to me.

I like how easy it is to build stub and mock objects in a dynamic language. I played a bit with these in tetrispresentertests.js if you want to have a look.

Tell me a story

The iteration backlog for this iteration (today) looks like this.

The user can steer blocks with the arrow keys.
Blocks can’t move outside of the playing field.
When a block reaches the bottom of the playing field a new block should appear at the top

Now that I’ve got game logic, presentation logic and the view separated out nicely it’s easy to add some tests for these stories and implement them. I’ll just let the code speak for itself.

tetris0.02.rar (12.36 kb)

Diving into JavaScript with Tetris

2010-03-16T12:00:00.000+01:00

To prepare for the Devnology meeting next month I have to write a version of Tetris in a language of my choosing. I had already fired up Visual Studio to build a kick-ass C# XNA version with explosions and 3D visuals when I realized it would be much more fun and educational to pick a language I’m less familiar with. I’m pretty sure there will be Ruby, Python, Java and Haskell implementations by some people who are pretty good at programming in those languages so I decided not to pick any of those obvious languages. But I’d still like to invest my time learning something I’m actually going to use, so Cobol wasn't an option.

I picked JavaScript.

The next couple of posts I’m going to be building Tetris using JavaScript and jQuery. I’ll pick a couple of stories every few days to implement and if I’m lucky I’ll have something resembling Tetris in a couple of weeks to show off. I actually hope I’ll get some feedback when I do things wrong. Most of my JavaScript experience has been adding simple onclick handlers to html files and pulling my hair out because of DOM incompatibilities. The new JavaScript frameworks hide all the DOM ugliness so it’s a good time to dive into JavaScript again.

In this first post we’ll get started implementing a couple of easy stories. I chose the following three.

As a user I can see a playing field that is 10 units wide and 18 units high.
Blocks fall one unit every second.
As a user I can steer blocks left and right with the arrows on the numeric keypad.

Lets get started.

As a user I can see a playing field that is 10 units wide and 18 units high

The first story is too easy. The display is just going to be a div. So we create a tetris.html file like this:

   1: <!DOCTYPE HTML>

   2: <html>

   3:     <head>

   4:         <link rel="stylesheet" href="tetris.css" />

   5:     </head>

   6:     <body>

   7:         <div id="field"></div>

   8:     </body>

   9: </html>

and the stylesheet:

   1: #field

   2: {

   3:     position: relative;

   4:     top: 40px;

   5:     left: 50%;

   6:     margin-left: -100px;

7:

   8:     width: 200px;

   9:     height: 360px;

10:

  11:     border: solid grey 2px;

  12: }

I decided on a block size of 20 pixels so the field is 200 by 360 pixels.

Blocks fall one unit every second

For this story to work we first need to be able to draw blocks. jQuery makes this pretty easy. Especially since blocks are just going to be small div’s with a big border in this first version, so our first pieces of JavaScript look like this:

   1: function drawBlock(x, y) {

   2:     var block = $("<div class='block'></div>").css('top', (17 - x) * 20).css('left', y * 20);

   3:     $('#field').append(block);

   4: }

   1: function clearBlocks() {

   2:     $('.block').remove();

   3: }

In order to draw a block every second we need some sort of gameloop that is called every second. So I put something like this in the jQuery document ready handler :

   1: $(document).ready(function() {

   2:     setInterval( "gameLoop()", 1000);

   3: });

and the gameloop:

   1: var verticalPosition = 18;

   2: var horizontalPosition = 5;

3:

   4: function gameLoop() {

   5:     verticalPosition--;

   6:     clearBlocks();

   7:     drawBlock(verticalPosition, horizontalPosition);

   8: }

some css for the blocks:

   1: div.block

   2: {

   3:     position: absolute;

4:

   5:     width: 12px;

   6:     height: 12px;

   7:     border: solid black 4px;

   8: }

And voila, we’ve got movement on our screen. Pretty easy actually.

As a user I can steer blocks left and right with the arrows on the numeric keypad.

We still can’t call this a game though. Movement is nice but without interactivity we might as well be looking at dancing hamsters. We want to be able to steer our block around.

jQuery makes registering a keyboard handler pretty easy. We can just add:

   1: $(document).keydown(keyHandler);

and the handler:

   1: const keyCodeMoveLeft = 100;

   2: const keyCodeMoveRight = 102;

   3: const keyCodeMoveDown = 98;

4:

   5: function keyHandler(keyEvent) {

6:

   7:     if(keyEvent.keyCode === keyCodeMoveLeft) {

   8:         horizontalPosition--;

   9:     }

10:

  11:     if(keyEvent.keyCode === keyCodeMoveRight) {

  12:         horizontalPosition++;

  13:     }

14:

  15:     if(keyEvent.keyCode === keyCodeMoveDown) {

  16:         verticalPosition--;

  17:     }

18:

  19:     clearBlocks();

  20:     drawBlock(verticalPosition, horizontalPosition);

  21: }

Next time we’re going to look at tooling to make testing and debugging all this a bit easier and we’re going to get a bit more OO.

You can download the code in this post here:

tetris0.01.rar (1.02 kb)

Using xUnit.Net with .Net 4.0

2010-01-19T12:00:00.000+01:00

I’ve been using xUnit.Net for a while now. It’s just a tiny bit cleaner and slightly less abrasive than other .Net unit testing frameworks. Leaving out unnecessary stuff like [TestFixture] and shortening Assert.AreEqual to the equally clear but shorter Assert.Equal don’t seem like big improvements but when you type them several times a day tiny improvements start to add up. I also like the use of the [Fact] attribute instead of [Test]. It shifts the focus from testing to defining behavior. So how do we get all this goodness working with the Visual Studio 2010 beta?

Creating tests is as easy as it normally is, you can just reference xunit.dll it in your 4.0 test-projects. Running your 4.0 tests can be a problem, the testrunners included in the xUnit.net package are compiled against the 2.0 framework so they won’t load 4.0 test-assemblies.

The obvious solution is to just download the source and compile it yourself. (+1 for open source!) Make sure you select the .Net Framework 4 and not the .Net Framework 4 Client profile in the project properties for the console runner because it uses some logging functionality that’s not available in the client profile. Everything will just run after this.

I found an easier solution on Mark Needhams blog In his article xUnit.NET: Running tests written in Visual Studio 2010 he explains how you can run the 2.0 console runner with the 4.0 clr by adding a section to the .config file instead of recompiling the whole thing. Adding the following lines to the xunit.console.exe.config should do the trick;

   1: <configuration>

   2: ...

   3:     <startup>

   4:         <requiredRuntime version="v4.0.20506" safemode="true"/>

   5:     </startup>

   6: ...

   7: </configuration>

I found the same trick works with the gui runner too. Unlike the console runner it doesn’t come with a config file so you need to create one yourself, add the <startup> section and it will load 4.0 test-assemblies.

When you want better VS.Net integration there are some other testrunners you can use. The easiest here is good old TestDriven.Net. You can download the version 3 beta for Visual Studio 2010 integration and run your 4.0 tests with it.

Another testrunner that works is the one included with Resharper. Normally it isn’t free but Jetbrains has released a public beta for version 5 that works with Visual Studio 2010. To get xUnit.Net working with Resharper you need the xUnit.Net contrib project. The maintainers have done a great job keeping it up to date with Resharper 5.0 alpha and beta builds so they’ve got a version for the latest beta available.

Agile architecture part II, SOLID or YAGNI?

2009-07-15T13:00:00.000+02:00

In a previous post about agile architecture I reasoned why big design up front isn’t a good solution to the problem of handling complexity in software. The best solution is architecting your application to avoid complexity as much as possible. At the end of the post I suggested reducing complexity by not implementing anything you don’t need right now. This principle is well known as YAGNI, short for You Aint Gonna Need It. Don’t implement anything you don’t need now. This will keep complexity down making it simpler to extend when you do need it. There’s another solutions to handling complexity though. You can reduce complexity by modularization. In software engineering we’ve got the SOLID principles for this. Unfortunately the SOLID principles seem to go against what YAGNI tells us. They tell us to add interfaces, separate out our dependencies and add all kinds of structures to our code that we don’t need just yet. So what’s it going to be SOLID or YAGNI?

The idea is actually quite simple. Lets look at a purely theoretical piece of software consisting of one component that can have ten states. Now we want to implement a new feature that will cause our piece of software to double in size. You’d think it would double in complexity too but you’d be wrong. When we add a similar component with ten states the total amount of states isn’t 10 + 10 = 20 but 10 * 10 = 100. So instead of doubling the complexity we’ve squared it. This is why spaghetti software will get unmaintainable really fast when size increases.

What we can do to contain this complexity is by separating our software into components or modules. If we construct our software so that we can reason about it’s parts instead of the whole thing we can still fit it in our heads. We don’t need to look at all the 100 states in the previous example when we can the software as separate modules or components. Then we only need to reason about the separate parts and the thin interfaces where they touch each other.

This is where SOLID comes in. I won’t get into the details of the SOLID principles here. Just bing them and you’ll find enough hits to explain them. But they give us guidelines on how to partition our software, hiding complexity behind well-defined interfaces and separating components so we can handle them by themselves giving us the ability to handle each part of our code as if it was alone in the world.

So I think we can use them both YAGNI does not tell us to refrain from adding lines of code we’re not going to need. YAGNI tells us not to add complexity we don’t need. SOLID is about removing complexity by separating out components.

Agile architecture, embrace change by reducing complexity

2009-06-27T16:32:00.000+02:00

Software development can sometimes be very counterintuitive. For example, when people started building larger software systems halfway through the last century one of the things they discovered was that changing existing software is often far more difficult and error prone than building new software. Most developers rediscover this somewhere in their first year of being a professional developer. They start out with a new project and as time goes by changes start taking more and more time, this can be very hard to explain to a client and usually we don’t until we get completely stuck and tell the client we need to start from scratch. I think this practice has been responsible for most of the bad reputation software development has.

So if changing software is such a hard thing to do we just have to do things right from the beginning. Analyze all requirements the client could ever have, make a design that incorporates all those requirements and then build that, this way we should never have to change anything. Sounds like a great plan but there are three things that make this quite impossible. Clients, stupid programmers and the rest of the world.

First of all clients don’t know what they want. It seems like I’m just trying to shift blame away from developers like me but I’m not. This is just a fact we have to deal with in our profession. Clients are not omniscient. They learn during a project and learning makes them change their mind. Of course there are ways to make sure clients don’t do silly things like this. You can spend more time doing requirements studies so they have a chance to change their mind before we start building or we can write everything down in big contracts so clients aren't allowed to change their mind anymore.

But then we encounter our next hurdle, stupid programmers. See, now I’m laying blame directly at our own feet. Programmers aren’t omniscient either. When you ask them to design a system they will make mistakes. The bigger the system the more mistakes. And most of these mistakes will only show up once you’ve built the system, meaning you have to change the system and we didn’t want to do that. Of course there’s an easy solution for this. You don’t let developers design the system anymore. You’ve got architects for that, they’re easy to find, they live in ivory towers.

So now you’ve spent a year creating the best requirements. Your architects have created a bulletproof design, you can now safely build your system right? Well no. Now you’ve got the real world to contend with. And it changes too.

I think we can safely conclude that resisting change isn’t a solution for our problems. Agile methodologies acknowledge that fact. Agile tells us to embrace change. But how do we make sure our software doesn’t make us regret this? We need to architect our software to embrace change too. Instead of going to around the problem like we used to do we need to get to the bottom of it and eliminate it from our software.

But how do you architect software to be changeable? Well this is another counterintuitive aspect of software engineering. In other engineering practices we have to contend with natural laws that constrain what we do. In structural engineering gravity is a big constraint. When you want to be flexible you build bigger foundations. In electrical engineering Ohm’s law is a constraint, so when you want to be flexible there you build in bigger cooling fins and more powerful power supplies. Software engineering is different in this aspect. Our main concern is complexity so preparing for change by over dimensioning your foundations will only work against you, you’re only making your software more complex, that will not help you fight complexity.

An agile architect will always go for simplicity. Do the simplest thing that will actually work, don't build things you’re not sure you’ll need. Keep responsibilities separated and abstract away everything.

Using a nested Master Page with ASP.Net

2009-06-17T13:00:00.000+02:00

The first thing I actually missed from Webforms are nested masterpages. Fortunately they’re not missing at all, they just figured out those MVC guys (and galls) like code so much, they don’t need no stinkin’ templates for something as trivial as this. And of course we don’t. Here’s how to roll your own.

Masterpages are a great way to keep your webpages DRY. Repeating layout/markup/header stuff goes into the masterpage. This is great until you create a bigger site with more than one masterpage. Suddenly you’re repeating code between masterpages. So we go up one more level. We make a masterpage for the masterpages. Yes it’s tortoises all the way down.

We start with two normal masterpages. Master.Master and Child.Master. I’ve always been good in coming up with original names. They’ll both look a bit like this:

   1: <%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>

2:

   3: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

4:

   5: <html xmlns="http://www.w3.org/1999/xhtml" >

   6: <head runat="server">

   7:     <title><asp:ContentPlaceHolder ID="TitleContent" runat="server" /></title>

   8: </head>

   9: <body>

  10:     <div>

  11:         <asp:ContentPlaceHolder ID="MainContent" runat="server" />

  12:     </div>

  13: </body>

  14: </html>

Now we want Master.Master to look exactly like this. And we want Child.Master to look exactly like this but add “Child – “ before the title and we want the content of the child in VERY BIG LETTERS, so we’ll put a <h1> </h1> tag pair around the ‘MainContent’ contentplaceholder. I wanted to use <blink>, my favorite tag but it’s not supported anymore.

Of course we can just add all this to Child.Master and be done with it but we want to re-use the Master.Master code. So lets use Master.Master as a masterpage. This works just the way you’d expect. You just add a ‘MasterPageFile’ attribute to the Master tag and use ‘asp:Content’ tags to fill in the contentplaceholders. The big difference with content-pages is that you nest asp:ContentPlaceHolder tags inside the content. These can be filled in later by your pages. This is how your Child.Master will look.

   1: <%@ Master MasterPageFile="~/Views/Shared/Master.Master" Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>

2:

   3: <asp:Content ID="TitleContent" ContentPlaceHolderID="MainContent" runat="server">

   4:     Child - <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server" />

   5: </asp:content>

6:

   7: <asp:Content ID="MainContent" ContentPlaceHolderID="MainContent" runat="server">

   8:     <h1>

   9:         <asp:ContentPlaceHolder ID="MainContent" runat="server" />

  10:     </h1>

  11: </asp:content>

Have fun!

ASP.Net MVC … Wow!

2009-06-15T13:00:00.000+02:00

I’ve been very happy on the windows programming side. I used to do web-programming but frankly ASP.Net web forms ruined that for me. Agreed… it’s very good for quickly setting up administrative websites that run inside the firewall. It has all the right abstractions allowing you to quickly piece together simple grid-based CRUD webapps without worrying about state, postbacks, javascript or even HTML. But when you want to build fun websites that look good and are designed to run on the big bad web these abstractions start to work against you.

Lately I’ve been getting a bit restless though. I need to learn some new stuff. Frankly my job is boring, right now I’m responsible for maintenance and support for a legacy C++ MFC system *yawn* so time to get back into web programming. Enter MVC!

Agreed, this is nothing new. Every other platform has had it’s web MVC framework for ages, even .Net has had monorail. But for me it’s new. And completely cool!

The architecture

I’ve been working with all kinds of UI patterns on the windows side. MVP, MVC, MVVM and so on hold no secrets for me but the web variant of MVC is a bit different for me. The whole routing thing took some getting used to, the controllers/view interaction is very simple compared to the windows world and I had to do some reading to get an IoC container working. But other than that the programming model is beautiful. No complicated page lifecycles but still every bit as extendable as we’re used to.

Testability

In web forms I had a whole bag of tricks to make things testable. Eventually I got some sort of MVP model working where I abstracted away all the page logic to a presenter object that was running behind the page. But the way pages behaved with controls throwing events all over the place this wasn’t as easy as it should have been. You had to be very keen on testing to go this route. In MVC things are the other way around. You have to try very hard to put logic in your views, although I have seen people manage this. Controllers are testable by default and everything is mockable. Great stuff for a TDD junkie like me.

Control

In web forms I had all but given up on java script. The controls you put on the page had their own idea about what javascript should run and you had to fight with these to ajaxify your pages. In MVC you have much more control over how your pages look in HTML. This also makes it very easy to add javascript. I’ve even ordered my first jQuery book.

What am I building?

Wouldn’t you like to know? Right now the project I’m working on is still in the proof of concept phase. I’m trying to get some basic functionality working. If I’m more sure about the possibilities I’ll put a first version online. But that probably won’t be until the end of this year. But you can expect a lot of MVC posts from me in the future.

Looking back at Open Space

2009-06-14T13:00:00.000+02:00

Last weekend I helped organize the Dutch Open Space Code Day. This wasn’t the first open space event I’ve been to but it was the first one where I was involved in the organization. Kees Dijk and me got the idea from the UK Open Space Code days that are organized by Alan Dean. And with some help from Imtech ICT, who kindly provided space, coffee and lunch, we got going.

So what did we do all day?

After a short introduction we started the planning phase. This is typical of open space, there are no scheduled speakers, all the scheduling is done at the start of the first day. Attendees propose sessions themselves, everyone votes to see what sessions are most popular. Then sessions are shuffled around to fit the available time and space. The schedule stays fluid for the rest of the event but most of the planning is done right at the start.

I can imagine this is a nervous moment for most open space organizers. What if no-one wants to propose a session? We had nothing to worry about in this respect. Many of the attendees were accomplished speakers on other conferences and I was confident they would also step up here. I wasn’t disappointed. On the right is what the schedule looked like after a couple of minutes proposing sessions.

After the sessions were voted on, combined and thinned out a bit we got going. Subjects ranged from Silverlight to DDD and design by contract, all interesting stuff. The first round of sessions started a bit late. So after only an hour it was already lunch time.

Most people just ate lunch while continuing the morning sessions. We had plenty of time planned for lunch so after about an hour people started coming back to the main room to get some coffee and get ready for another round of sessions. The afternoon round of sessions went by just as fast as the morning sessions.

On the whole I can say the day was a success. I had some worries that there were too many high-profile speakers attending and that this would kill the interactive nature of open-space but this just didn’t seem to be a problem. A couple of things could go better. People didn’t really seem inclined to move from session to session. Normally this is a mechanism in open space that ensures attendees get the most out of the sessions and sessions that are less interesting die out. In this case the quality of content in all the sessions was very high so there wasn’t much need for people to move between sessions.

The focus of Open Space Code is supposed to be on coding. This never got off the ground. Most people had laptops and some code examples were shown but at the end of the day no code was checked in to the Google Code repository that was provided for this day. This probably had to do with the fact that people had to specifically ask to get access to the repository. Next time we’ll try to streamline this process by providing access to a version control system beforehand. This way people can prepare code samples before the event.

I also got some suggestions to make the sessions a bit shorter next year. This time we had two sessions of two hours each to give people enough time to actually do some coding. Next time we’ll probably do three 1,5 sessions instead. This might fit in better with lunch too.

All in all the day was a big success. I’m really looking forward to my next open space event.

Pomodoro

2009-05-30T13:00:00.000+02:00

I finally gave up and went with the hype. I admit it, I bought my first piece of Apple hardware. It wasn’t even as expensive as I thought it would be and its shiny. I always had a soft spot for brushed stainless steel.

Here it is, my first Apple product.

So why am I blogging about a kitchen utensil you might ask? Well, actually this fruity piece of stainless steel is a productivity enhancer. Let me explain.

Focusing your work is often hard. And many tasks, like programming, need focus. Lots has been written about how interruptions from telephones, coworkers or managers will ruin productivity. But there’s a dirty little secret here. Even when you leave them alone most programmers are perfectly capable of interrupting their own work. They read blogs, have a chat at the coffee machine or read email. Having some time to wind down between work is of course good but but only when you’re able to do focused work in between those distractions.

Part of the problem is that our expectations about ourselves are too high. We expect ourselves to be able to do hours and hours of work. In exceptional circumstances this is possible, when you get into the mythical state of ‘flow’ time just flies by and todo-lists shrink at an alarming rate. But in most circumstances you need short periods to rest your mind in between work. The trick is to keep those rest-periods short and to really focus during work.

Enter the pomodoro. Or in my case a stainless steel apple-timer.

The idea comes from Francesco Cirillo who had the same problem us programmers have when studying. Days of study would fly by but when he looked back at what he accomplished during those study he was usually underwhelmed. In order to improve matters he used a tomato shaped kitchen-timer to keep an eye on time. He lives in Italy where a tomato is called a pomodoro and so the pomodoro technique was born.

Francesco realized he needed to do things to be able to focus, time his work-periods and rest-periods and write them down to be able to see if he improved. The technique is actually really simple, just simple enough to work.

The first thing is to achieve focus. You can do this by splitting up your time into periods of focused work with rest-periods in between. The pomodoro technique uses 25 minute work-periods with 5 minute rest-stops in between. After 4 of these you get a longer rest-period.

To make sure you know what you need to do in these periods you need to keep a couple of simple lists. First you need to make a to-do list of the tasks you plan to do during the day. Just write down several tasks on a piece of paper. Set your timer to 25 minutes and start working. When the timer rings you mark a successful pomodoro and take a 5 minute break, you can talk to a colleague go to the bathroom.

The real trick is dealing with interruptions. Normally this is the hard part. Most interruptions can’t be delayed indefinitely. But because your pomodoro is only 25 minutes long you can often delay interruptions till the next break. Write it down, mark an interruption and continue the pomodoro.

If you want to know more about this check out these resources

Agile maturity

2009-03-23T12:00:00.000+01:00

In the ten years I’ve been programming I’ve learned two pretty important things.

Project success is about people and teams. No matter your process, good teams will succeed (usually in spite of your process) and bad teams will fail.
Every time you make a rule about something, people will stop thinking about that thing and blindly apply the rule.

This sounds pretty bland, even Chinese fortune cookies usually have more interesting things to say, until you think about one of the consequences. You need good people for project success but if you give them too much rules they will stop thinking and become as smart, or as stupid as the rules. Most Methodologies seem to think that more rules is better. If a rule doesn’t benefit you it surely won’t hurt too much, just implement as much as you can and things will surely get better.

This is one of the reasons I’ve never been fond of things like CMMI, the heavier your process, the more rules you implement, the more mature you are. All in the name of repeatability. You don’t want successful projects to be a fluke you want them to be repeatable. This sounds really good but I think you throw out the baby with the bathwater. You can’t repeat success by copying and pasting because the most important factor is people and you can’t copy and paste people.

This is why I have some trouble with Scott Ambler’s ideas of an Agile Project Maturity Model. Don’t get me wrong. I like the idea of having some scale to rate agile implementations but I don't think the scale Scott proposes has much value. It takes all the faulty assumptions from CMMI and applies them to agile. It just doesn’t fit! Agile is not about repeatability, it’s about adaptability. This is why I’d like to propose a different scale, one based on the Dreyfus model.

I think maturity is about learning. And, coincidentally so is the Dreyfus model. It has five levels

Novice - rigid adherence to rules
Advanced beginner – limited situational perception
Competent - deliberate planning
Proficient - holistic view of situation, rather than in terms of aspects
Expert - no longer reliance on rules, guidelines, maxims

I think organizations learn just like individuals. These levels can be applied to teams and organizations. You see this in Ken Schwaber’s books on Scrum for example. Organizations starting with Scrum should first start applying all the rules very rigidly, but after some time this is counterproductive. The rules can be adapted in project retrospectives, the organization is learning.

A mature organization should apply the right rules to the right projects leaving their professionals with enough room to react to changing requirements in every situation. A mature organizations should also recognize that less mature teams within that organization will need a different set of rules than more mature teams.

Not all quality is free. But it’s cheaper than you think

2009-03-08T12:00:00.001+01:00

I started writing a reply to this post but it got kind of long, by the time I started thinking about adding pictures it dawned on me that it’s probably a good idea to write my own post on the subject.

The discussion here is based on an idea from lean development. Traditionally people thought that quality had a price. Removing defects has a cost so more quality means higher cost. Lean production tells us this is not true. If you remove the defects sooner you can remove them cheaper. By removing the cause of the defects you can prevent them from being added. This will not only improve the quality but actually remove the cost of fixing the defects. Agile methodologies like XP show us that this works for software too. Up to a point.

There are a couple of ways you can prevent defects from appearing in your software. The two most effective things you can do are TDD or test first development and pair programming. Both give you early feedback about defects and prevent you from introducing them. Both have their own types of defects they will prevent. Test first programming seems suited for removing defects related to low level behavior of components in your software. Pair programming has a more wide range of defects it will prevent, having two pairs of eyes and two brains look at the same piece of code. I’ve found that most errors it prevents are maintenance related. High level interaction problems are usually too complex to find this way.

The biggest improvement in quality you will get from these methods is not so obvious though. I’ve found both methods force you to think about low level specifications before implementing them. Writing a test forces you to think about how the code you’re testing is going to behave. You’ll have to specify this behavior in your test before implementing it. Writing down executable specifications like this is very powerful. I’ve found the dynamics of TDD don’t feel like testing at all. It focuses the development effort but TDD will not replace testing. Simply because you won’t find all classes of errors.

I’ve found two places where developer testing breaks down.

The most obvious place is in testing your requirements. Requirements are notoriously imprecise. Problems in writing down the requirements or in interpreting the requirements will often only be found in an additional inspection phase. Software might be working correctly but is it actually doing the right thing. Usability issues also fall in this category.

Integration of components is also a source of defects that won’t be found with TDD or pair programming. In simple cases where components just call each other integration issues are often found by the compiler. But in more complex cases, for example when components should work together in a multithreaded application defects are almost inevitable.

I don’t think you can eliminate inspection. Software is just too complex. I don’t think zero defects is achievable either. But when looking at common development practices today I think there is a lot of low hanging fruit. Most development organizations can indeed save on inspection and defect-removal by increasing quality using these practices. But even then they’ll be a long way from zero defects.

The original fallacy was to think the cost of removing defects was a straight line that went up. But assuming the cost per defect is a straight line with a downward slope is too simplistic too. Here’s the picture I promised:

Quality will eventually cost you money when all the easy bugs are gone. But until then we should invest in it as much as we can.

Chaos in WPF

2009-02-22T12:00:00.000+01:00

I’ve been reading up on math lately. Mostly chaos theory and nonlinear dynamics. I still don’t get why they don’t teach stuff like this in school, I might have even found math fun if they had done so, part of the fun of these areas of mathematics are the cool graphics they produce. Everyone knows the Mandelbrot set, but in this post I want to focus more on chaos theory. And to make it interesting for my usual readers lets draw some pictures with WPF

But first some math to scare off all the wanna-be geeks out there. We’re going to have a look at the logistic map.

xn+1 = xnr(1 – xn)

This function was thought up by the mathematician Pierre François Verhulst to model population growth. The function models two things, bigger populations grow faster until they get too big, then growth will be limited by competition for resources. When you look at the function you will see that it’s a non-linear difference equation.

The fun starts when you start playing with r. For small values of r the x will quickly go to zero and stay there. Things get more interesting for r > 1, first x will stabilize on some value. The stable value for x gets bigger as r gets bigger, but for values of r bigger than 3 x will actually start to oscillate, first between 2 values, then between 4 values, then 8 and then the behaviour of x will become chaotic. You can plot this out and you will get a nice fractal-image. If you zoom in on part of the image you will see the same image repeated.

I wanted to see if I could plot this. My previous toy project was done with WinForms but I found drawing pixels a bit cumbersome. This time I wanted to try out WPF. I found that drawing single pixels in WPF is not trivial either but with a little help from the WriteableBitmap component I could access single pixels in a bitmap. I’d like to have a simple panel component that I can reuse for simple toy projects like this so I quickly built a nice BitmapPanel. Here’s the interface definition. The source code for it is included in the project files if you want to see how it works.

   1: public interface IBitmapPanel

   2: {

   3:     int PixelWidth { get; }

   4:     int PixelHeight { get; }

5:

   6:     event Action Redraw;

7:

   8:     void SetPixel(int x, int y, byte color);

   9:     byte GetPixel(int x, int y);

  10: }

You get redraw events every time the panel changes shape. You can retrieve the size of the panel and you can get and set pixels. Simple enough but usable.

I now could put the bitmap panel on a window and build a presenter object around it. The presenter is where all the interesting stuff happens, it looks like this:

   1: public class ChaosPresenter

   2: {

   3:     public IBitmapPanel View { get; set;}

4:

   5:     public void Initialize()

   6:     {

   7:         View.Redraw += RedrawHandler;

   8:     }

9:

  10:     private void RedrawHandler()

  11:     {

  12:         var width = View.PixelWidth;

13:

  14:         for (var i = 0; i < width; i++)

  15:         {

  16:             var factor = i*3f/width + 1;

  17:             Iterate(i, factor);

  18:         }

  19:     }

20:

  21:     void SetPixelScaleY(int x, float y)

  22:     {

  23:         var ycoordinate = (int)((1.0f - y) * View.PixelHeight);

  24:         var index = x + ycoordinate * View.PixelWidth;

  25:         View.SetPixel(x, ycoordinate, (byte)((View.GetPixel(x, ycoordinate) + 0xFF) / 2));

  26:     }

27:

  28:     private void Iterate(int x, float factor)

  29:     {

  30:         var number = .2f;

31:

  32:         for(var i = 0; i < 100; i++)

  33:         {

  34:             number = GetNextIteration(factor, number);

  35:         }

36:

  37:         for(var i = 0; i < 1000; i++)

  38:         {

  39:             SetPixelScaleY(x, number);

  40:             number = GetNextIteration(factor, number);

  41:         }

  42:     }

43:

  44:     private float GetNextIteration(float factor, float value)

  45:     {

  46:         return factor*value*(1f -value);

  47:     }

  48: }

It wraps the IBitmapPanel and redraws the complete diagram every time it resizes. The RedrawHandler is where stuff happens. It maps different values for r between 1 and 4 on the x axis of the bitmap panel and calls Iterate for all those values of r. Iterate starts at x = 0.2 and throws away the first 100 iterations. This allows x to stabilize into the typical behavior for that value of r. Then it iterates through the next 1000 values and plots them. GetNextIteration is my implementation of the logistic function. You can play with the values in Iterate if you like. By changing the number of iterations on line 32 you can see how quicly x settles in it’s typical behaviour for different values of r for example. I got the image at the start of this post by iterating 10 times before starting to plot. You can see that x settles pretty quick for most values of r, but near r = 1 and r = 3 it takes more iterations for x to settle down.

The executable can be downloaded here: ChaosExecutable.zip (5.43 kb)

And code is available here: Chaos.zip (10.36 kb)

I can’t go to bed right now

2009-02-12T12:00:00.000+01:00

Someone is wrong on the internet.

In the past few episodes of the stackoverflow podcast Joel Spolsky and Jeff Atwood already talked about SOLID principles and TDD saying they don’t really care for it, they both seem to have been successful without it. They also admitted neither of them had any real experience with this style of programming. This is why I find it really surprising Jeff even took the trouble of writing another blog post about this voicing his opinions about a set of principles he clearly has never practiced.

First of all I find this post very unprofessional. In the short ten years I’ve been programming I’ve seen lots of practices, rules, patterns, principles, styles and methodologies. Some of them are successful, some of them aren’t. Some of them work in some situations and some of them never work and I never get tired of hearing people talk about what worked for them, what didn’t work for them and why. This post isn’t about that. Jeff admitted to not having much experience trying these principles, he does seem to have a couple of issues with rules though.

Jeff also seems to completely miss the point on what principles actually are. He goes on a rant of why rules are bad but principles aren't rules. In fact I think they are almost the opposite of rules. Rules are what made the 2Life Crew change the lyrics of their hit song Me so horny without changing its meaning. Principles are what drives you to not let your little sister listen to it. Rules tell you what to do in any situations. Principles describe where you want to go leaving you to decide what the next step will be to get you just a little closer.

The case for or against SOLID and TDD seems familiar. It’s an old discussion of efficiency vs. effectiveness. Not doing TDD and not doing things SOLID lets me write loads of code really fast, its really efficient. But programming is not about writing code. This may surprise some people. Programming is design. It’s about thinking. It will surprise you how few lines of code an average programmer writes, so typing is not a bottleneck. There are other bottlenecks. Maintenance and readability. SOLID and TDD address these bottlenecks leading to well partitioned readable code. The dynamics of writing code change from frantic sprints and evenings of bug-hunting to a sustainable pace.

More about dependency injection

2009-02-01T12:00:00.000+01:00

In a previous post I talked about problems caused by singletons and how to solve them using dependency injection. I mainly talked about constructor injection. In a reaction to that post Roy Tang voiced his concerns about scaling contructor injection. In real life applications you often have a lot of dependencies, passing them through constructors can become a problem in real life solutions where you’ve got objects with lots of dependencies. Usually when manual IoC does not scale anymore I use an IoC container. But this might not always be an option. In this post I want to talk about a few ways to get around this problem.

Are you solving the right problem?

Often problems like these are indicators of other problems. The first thing to look for when you’ve got classes that have too many dependencies is the single responsibility principle. Classes often have too many dependencies because they do too much. You might want to split up that class in a few more granular classes.

One solution to avoid is reusing dependencies between classes. For example it might be tempting to rewrite this;

   1: class ClassA {

   2:    public ClassA(ILogger logger, ClassB objectB) {

   3:       // ...

   4:    }

   5: }

6:

   7: class ClassB {

   8:    public ClassB(ILogger logger) {

   9:       // ...

  10:    }

  11: }

to this:

   1: class ClassA {

   2:    public ClassA(ClassB objectB) {

   3:       // ...

   4:    }

   5: }

6:

   7: class ClassB {

   8:    public ILogger Logger {get; private set;}

9:

  10:    public ClassB(ILogger logger) {

  11:       Logger = logger;

  12:    }

  13: }

Eliminating ClassA’s dependency on the logger, it can just reuse ClassB’s logger, right? Well no, this breaks the single responsibility principle. The logger reference has become part of the public interface of ClassB effectively giving ClassB an extra responsibility as a LoggerProvider.

Alternatives to constructor injection.

Constructor injection is not always the right way to do things, so you might want to inject your dependencies somewhere else. Property or method injection might be good alternatives.

Property injection exposes dependencies as properties. Property injection is a bit more flexible than constructor injection but also a bit more dangerous. It allows you to set dependencies one at a time, this can be good when you’re testing something that doesn’t need the full set of dependencies reducing the size of your tests. But it can also cause objects to be only partially initialized causing problems. Property injection is very powerful but it gives you a lot of rope to hang yourself with too, be careful using it outside of an IoC container.

If a class only uses a dependency in one method you might want to pass that dependency as a parameter to that method instead of having it passed into the constructor, this is called method injection. For example the following class:

   1: public class Shape {

   2:    public Shape(Canvas canvas) {

   3:       // ...

   4:    }

5:

   6:    // ...

7:

   8:    public void Draw() {

   9:       // draw to the canvas

  10:    }

  11: }

might be better implemented as:

   1: public class Shape {

2:

   3:    // ...

4:

   5:    public void Draw(Canvas canvas) {

   6:       // draw to the canvas

   7:    }

   8: }

Using Defaults

In addition to using different forms of dependency injection when needed you can reduce the amount of code by providing default dependencies. I wouldn’t do this in large projects because adds some coupling but it can be a good way to reduce the amount of “wiring” code and still maintain some testability.

For the ClassA class from the first example would look like this:

   1: class ClassA {

   2:    public ClassA()

   3:       : this(new LoggerImplementation(), new ClassB())

   4:    { }

5:

   6:    public ClassA(ILogger logger, ClassB objectB)

   7: }

Providing you with a two options. You can then use the default constructor in your code and the DI constructor in your tests.

For large applications using an IoC container still gives you the most flexibility with the least trouble. I hope I’ve given a good overview of the options you’ve got for maintaining dependencies when you don’t have access to one of those.

Fun with planets

2009-01-08T12:00:00.000+01:00

Over the holidays I finally got around to doing some recreational coding again. The results even surprised me so I thought I’d share it with my blog-readers. So here it is, your very own planitarium. Planets flying around with real gravity just like Newton taught us (who needs all that fancy new-fangled relativity anyway), and if you feel like it you can even play God and slingshot planets into outer space. Just try clicking anywhere in or around the window.

I also included the source code although I’m not particularly proud of it. I’ve spent more time playing with the program than actually writing nice code. It’s been a long time since I’ve actually written code without tests. The code itself is quite simple. There’s a galaxy object that contains and handles all the planet interaction. There’s a body object that comes in two flavours, a normal one and a mousebody that represents the mouse position. They both implement IBody so the Galaxy doesn’t care what bodies there are. The normal body objects fly around. The MouseBody always has the position of the mousepointer and only has mass when you push a mousebutton.

That’s about it. There’s a planetariumview and a presenter object that handle painting the whole planet stuff. There’s a Time object that wraps a timer for the heartbeat and there is a program that wires it all together.

Enjoy! and let me know if you do anything fun with it.

Code:

Planetarium.rar (13.85 kb)

Binary:

Planetarium.exe (16.00 kb)

Why software engineering is NOT like structural engineering

2008-12-14T12:00:00.000+01:00

While cycling home from work today I was listening to the Deep Fried Bytes episode with Rico Mariani. I should have been warned by his introduction; “He has an analogy for everything”. But since he seems to be a smart person the good old “Software engineering is just like structural engineering” caught me by surprise. I thought we ditched that one together with the waterfall process.

Usually this analogy is used to get people to do big up front design. “You wouldn’t start pouring concrete for the foundations when you don’t know how many stories your building should have” In structural engineering you need to finish a design before you start building.

But in software engineering all we do is design. Sure, in waterfall you have a design and implementation phase. But if you look more closely implementation has nothing to do with building anything. It’s design on a more detailed level, code is design too just like UML. The only thing we do that looks the slightest bit like building is deploying our software. Luckilly I’ve never seen anyone deploy software that they havent designed yet.

The forces in software design are also completely different from structural engineering. Any good software design is highly decoupled. This means that you don’t have a foundation that should change whenever another part of the “building” changes. In structural engineering you don’t have that luxury. We don’t have the technology to decouple gravity yet so every time you add to your building you’re going to need a bigger foundation.

Another reason we’re so big on decoupling is that software engineering is hard for completely different reasons than structural engineering. Complexity is a much bigger factor in software. Requirements change a lot more too. I’m not trying to say software engineering is harder in any way or that structural engineers don’t have problems with complexity or customers who change their minds. But in software engineering these things play a much bigger role. Luckilly we can handle these problems by decoupling the different parts of our design so we only have to handle the complexity of the individual components and can change around pieces if the customer needs something new.

So if software engineering is all about complex and flexible designs how should we go about creating them? Waterfall tells us to finish our high level design first and then fill in the details. The problem with this is changing requirements and no feedback on the quality of the design. Should we do bottom up design then? Start small and add more pieces later like agile tells us to do? I think we should do both. Work bottom up but be shure you have a rough sketch of what you’re trying to design. Don’t spend too much time on it because you’re probably going to throw it a way at least a couple of times before your building is finished.

Using Singletons Safely

2008-12-09T12:00:00.001+01:00

The singleton is probably the best known of the GoF Design Patterns, it’s also the most controversial. I try avoid using singletons in my code when I can but since the singleton is a very simple but powerful pattern I sometimes sin against the decoupling gods and use one or two of them. Lots of stuff has been written about creating singletons. In this post I want to show you how properly use a singleton and contain most of the damage singletons do.

This post was inspired by a Twitter discussion I had with @LaTtEX who blogs here

First lets talk about all the reasons not to use a singleton. The objection I hear most against singletons is thread safety. The problem here is that if two threads access the the singleton simultaneously when the singleton isn’t created yet the singleton might accidentally create two instances of itself. The naive implementation has this problem and even some solutions that have been suggested like double checked locking aren’t completely thread safe. This isn’t why I dislike singletons though. I think the biggest problem with singletons is coupling.

Singletons are accessed through static methods. Calling a static method couples your code to the implementation of that method so every call to the Instance property or method of a singleton makes your code harder to test and harder to maintain. A call to a singleton by definition has side effects. Usually these are very large, singletons are usually used for resource intensive objects that you only want to create once. You don’t want to be coupled to code with severe side effects.

My strategy for defusing singletons is actually quite simple. Reduce the number of MySingleton.Instance calls. Lets say we have a singleton for logging that we want to use in a repository class, something like this.

   1: public class Repository

   2: {

   3:     public IEnumerable<MyClass> ReadObjects()

   4:     {

   5:         Logger.Instance.LogMessage("ReadObjects started");

6:

   7:         // ..code..

8:

   9:         Logger.Instance.LogMessage("ReadObjects finished");

  10:     }

11:

  12:     public void StoreObject(MyClass anObject)

  13:     {

  14:         Logger.Instance.LogMessage(String.Format("StoreObject {0} started", anObject.Id));

15:

  16:         // ..code..

17:

  18:         Logger.Instance.LogMessage("StoreObject finished");

  19:     }

  20: }

Coupling-wise things can’t get much worse than this. Every time something is logged Logger.Instance gets called making our Repository object depend not only on the Logger class but also on it’s implementation as a singleton. This is not something we want our repository to be aware of. We can easilly make this a bit better by creating the instance once and reusing it.

   1: public class Repository

   2: {

   3:     private Logger logger = Logger.Instance;

4:

   5:     public IEnumerable<MyClass> ReadObjects()

   6:     {

   7:         logger.LogMessage("ReadObjects started");

8:

   9:         // ..etc..

The code is a little bit better because I’m not repeating my mistake over and over but I’m still not satisfied. Let’s see how I can improve this even further.

   1: public class Repository

   2: {

   3:     private Logger logger;

4:

   5:     public class Repository(Logger logger)

   6:     {

   7:         this.logger = logger;

   8:     }

9:

  10:     public IEnumerable<MyClass> ReadObjects()

  11:     {

  12:         logger.LogMessage("ReadObjects started");

13:

  14:         // ..etc..

15:

Here I used the constructor to inject the logger instance into my class. This is a simple concept but it has a big impact on the flexibility of your code. Your classes aren’t aware of how objects need to be instantiated anymore. This makes code more testable and maintainable. You can inject a class that derives from Logger, as long as it works the same as its base class this will just work. Usually I even hide classes that provide a common service like logging or caching behind an interface to decouple usage of instances even more from their implementation.

If you really paid attention you probably noticed that by having the Logger injected into the Repository in its constructor you have made the instantiation of the singleton a bit less lazy. You might never even call ReadObjects and never need the Logger. If you really need instantiation to be that lazy you could inject the Logger as a parameter into the ReadObjects method, I found that usually injecting in the constructor is fine.

You might say that by pushing the call to Instance out of my repository into the code that creates the repository I have only moved the problem somewhere else, and you would be right. But this problem can actually be solved by moving it. As long as you move it in the right direction. I’ve put the code that creates the repository and the code that gets an instance of the Logger together. If you do this for more of your code you’ll end up with creation and usage of your classes nicely separated with all the code that’s responsible for wiring up your application nicely centralized.