Sunday 9 June 2013

A real life project: The Walking Skeleton

Using tests to create The Walking Skeleton

Ever been working on a piece of software, think you have it finished only to have your heart broken my some integration or deployment problem? The first step in the GOOS book is to use tests to create a walking skeleton in the hope of avoiding these problems. It's really great advice for any software project.

I created two tests to drive out the walking skeleton, starting with the simplest behaviour that I think the game can have.

A game that no-one joins

Test number 1, a game that no-one joins. Doesn't sound like much, but when you take into account that we want something that can be deployed from this there's quite a bit of work. Implementing this test means we need the Poker Game app, a runner to control the app and a way to detect UI output from the application.

I need to create these components to get this test to pass and when I do I should have something like this.



The Poker Game Runner allows the tests to interact with the Poker Game. It will start the application and acts as my main point of interaction with the application.

The Poker Game is the application itself. After this test it will do nothing more than display a console message that the game is starting, wait for a while and display a message saying that it is quitting because there are no players.

The Console Scraper allows me to read whatever is written to the console by the Poker Game. I can use this in the test to verify that the correct messages are being displayed.

It's not the whole picture yet though so I need to introduce another test.

A game that one player joins

The first test doesn't quite give us the walking skeleton we need because there's one other very important component that doesn't get exercised by this test, the XMPP server. To get that I introduce a second test, a game that one player joins. It still is not enough to do anything really interesting, but to pass this test I will need the player to communicate with the dealer. Implementing this behaviour means setting up an XMPP server and having a player communicate with the dealer through it by asking to join the game.



With the XMPP Server added I can now verify that there is some kind of interaction between the dealer and the players.

To finish this test I create a Fake Player that I can control within the test. At the end of this test, the Poker Game will register with the XMPP Server, the Fake Player will ask to join the game through the XMPP Server and the Poker Game will react by displaying that the player has joined.

Final Note

I need to start thinking about the next test now, and that's not too easy. Normally at this stage in development I begin to wonder how many acceptance tests I'll have and how complicated they will be. I could really test the whole system by adding more and more acceptance tests, but I could see that getting ugly further down the line with complicated and buggy tests.

So, I'm wondering, how much do I test with acceptance tests and when do I decide to test directly on the class with the behaviour? From my understanding of the GOOS book, in my test where a player asks the dealer for permission to join the game, I shouldn't care what message is sent to the dealer. The point is just to introduce 2-way communication between the dealer and a player and any message can do that. I'll test the dealers reaction to messages directly on the dealer when they are needed.


Saturday 27 April 2013

A real life project: The business of Texas Hold 'em

I'm still in the preparation stage but I want to backtrack and come at the problem from a different point of view, the business. In this case the business is a poker game, to be more precise Texas hold 'em. I think I'm lucky here because I have some experience with the game so I (helped by some internet searching) can act as the source of the business knowledge.

This post may read more like a rough guide to Texas hold 'em, but knowing the business is extremely important when developing software. The finished code should contain the terms that I use here and should model the processes I describe.

Let's start by agreeing some basic terms for the game. There's a lot more terms in Texas Hold 'em than I mention here, but I'm limiting it to the terms that I will use in the game.

Terms

General

Game - starts with the dealing of hands to players, and finishes when one player wins the hand.
Tournament - a series of games.

Betting


  • Round of betting - This is when the players can bet, check or raise. It occurs after the private cards, flop, river and turn.
  • Cash - money held by each player for the purpose of betting.
  • Blinds - forced bets by the first and second players left of the dealer. First to the left plays the small blind and the second plays the big blind.
  • Pot - all the cash that has been bet.
  • Check - player indicates that they do not wish to bet and the turn moves to the next player
  • Bet - player puts money into the pot
  • Call - player puts enough into the pot to stay in the game
  • Raise - player puts more than enough into the pot.
  • Fold - when a player quits the game.

Dealing


  • Button - aka the "dealer button", that shows the position of the dealer on the table. This moves one position to the left with each game.
  • Private cards - each player gets two cards that are for their eyes only.
  • Hand - these are the best cards that a player using for the game. A hand is made up of 5 cards selected from the private cards that the player holds and the community cards.
  • Community cards - the cards that are dealt face up. Players use three and sometimes four or five of these cards to make up their hand.
  • Flop - when the first three community cards are dealt.
  • Turn - the fourth community.
  • River - fifth and final community card.

Hands in order of strength (low to high)

Outside of the basic terminology, knowing the ranking order of the hands is really important. 
  • High Card - nothing of value in the hand so the highest card is used. Cards are ranked in the order 2 - Ace.
  • One Pair - two cards of the same value.
  • Two Pair - same as above, but twice.
  • Three of a Kind - three cards of the same value.
  • Straight - five consecutive cards of any suit.
  • Flush - five cards of the same suit.
  • Full House - A hand consisting of 3-of-a-kind and a (different) pair.
  • Four of a kind - four cards of the same value.
  • Straight flush - five consecutive cards that all have the same suit.
  • Royal Flush - 10, Jack, Queen, King, Ace of the same suit.


Playing a game

The easiest way to understand something is by doing it, so let's run through a game. For this game we'll have four players sitting in order from left to right, Holly, Mike, Ann and Dave.

Before any cards are dealt

The button is in front of Holly so she's in the dealer position. That doesn't mean that she will actually deal, that will be handled by the game. This only gives a way to keep track off the order.

Before any cards are handed out the blinds must be paid. Mike is to Holly's left and then Ann so Mike pays the small blind of 10 and Ann pays the big blind of 20. Two cards are dealt to each player starting with Mike and ending with Holly.

First round of betting

Dave must act first because he is the first player after the big blind. Checking isn't an option for Dave because of the blinds so he has three options. He can a) Call by matching the big blind, b) Raise by putting in more than the big blind or c) Fold and leave the game. Dave decides to fold and the play moves to Holly.

Holly has the same choices as Dave and she decides to call by matching the big blind with 20 and moving the play onto Mike. Mike also wants to call and seeing as he put in the small blind he puts in just 10 more to bring his contribution to the pot up to 20. This round of betting ends with 60 in the pot.

The Flop

The game moves on by dealing the flop, AH, KH, 7C. Play moves again to the player left of the button, Mike. Mike choices are to a) Check, or b) Bet. Folding is also an option but this would not be wise because he can stay in the game for free by checking. Mike checks, Ann checks and that leaves Holly with the decision of betting or checking. Holly bets 100 which forces the others to either fold or pay 100 to stay in the game. Mike is first and he calls Holly by putting in 100. Ann folds and she is out of the game.

We now have a pot of 260 and community cards AH, KH, 7C.

The Turn

With that round of betting over the Turn card is dealt and its AD. Betting again is to Holly's left and that's Mike. This time Mike bets 100 and it's back to Holly. Holly calls Mikes 100 and raises another 100. The betting goes around again because of Holly's raise and Mike calls Holly's bet by putting in another 100.


We now have a pot of 660 and community cards AH, KH, 7C, AD.

The River

The last card is dealt and it's the 8C. This moves us into the final round of betting, starting again with Mike. Mike checks and leaves the decision to bet with Holly. Holly bets 200 and Mike calls the 200.

No more betting can take place and there are no more cards to be dealt so the players turn over their cards to see who has won.

Holly turns over AC, KC. Mike turns over AS, 10S.

With the community cards AH, KH, 7C, AD, 8C the players make the best hands they can. Holly can make a full house of aces and kings (AH, AD, AC, KH, KC). This beats Mikes best hand of triple aces (AH, AD, AS, KH, 7S).

Holly wins the pot of 1060 with a full house.


There you have it, that should be a good enough overview of the business side of things. I know that this post  may seem to have little to do with software development but trying to build a system without this knowledge will lead to failure. It also leads us nicely onto the next section, which is to take this business knowledge and start breaking it down into pieces of behaviour.

Sunday 24 March 2013

A real life project: Early choices that need to be made


At this stage I need to make some important decisions for the project. These choices will become more difficult to change once I start so I want to make sure they are kept to the minimum but necessary.

The thing I'm trying to do is to tell the big story for the system in terms of software development rather than just the business. At the end of this posting you should have a good idea about what I'm going to build and how I'm going to build it.


The language

I can't do anything without first deciding on a language to use. For that purpose I've decided to go with Python. I've got tons more experience in C#, but Python does have some pros:
  • This is a learning exercise and it's a great opporunity to get my Python skills up to a decent level
  • I plan on using free code from other sources when available. Lookng around the web I came across a lot more useful Python than C#
  • Python is a dynamic language, so I'm guessing that this will make development easier (sounds like famous last words)
  • It isn't C#
This decision doesn't come without risks, and it's best to identify them now at least:
  • I'm inexperienced, having done little more than kata's in Python
  • Refactoring; I've heard that refactoring tools in dynamic languages aren't as good as the refactoring tools for dynamic languages
  • Tooling in general. I'm used to the juggernaught that is Visual Studio .Net and here I'm reducing myself to the free and opensource world 


Communication in the game

I need some way for the dealer and palyers to communicate, so after a little investigating I've decided to follow the guys in the GOOS book and use XMPP.
Advantages here are:
  • It's what they used in the book
  • It's a standard
  • Python has a few nice libraries available for the purpose. I'm going to use SleekXmpp 
Risks:
  • Again, lack of experience. But I lack experience in the whole area so I can't avoid this risk


The Architecture

Everything you've read so far would fall under the heading architecture, that is, if you have read it. There is a chance that you've just skipped through the above text and jumped to the picture, so here it is. All of the choices I've mentioned above should be in this picture.


The Development Environment

So, whats the requirement in a development environment? Well, I want to be able to work as quickly as possible, have as much integration as possible and achieve lots while doing very little. To be more precise I need:
  • A nifty editor. Someone recommended Sublime Text to me a while back and I'm pretty happy with it so far. It's got some cool plugins so I reckon it should meet all or most of my needs.
  • Source control, I'm choosing git. Again this will be a learning experience because I haven't done that much with git. It integrates nicely with Sublime Text though.
  • Continuous Automated testing. NCrunch got me addicted to this and I was gutted when they started charging a lot of cash for it. I'm going to use some python scripts combined with Growl to achieve this.
  • Refactoring. It's a must. I don't know how I ever developed without it (waaay slower at least). It's really suited to a static language like C#, but how will it fair in a dynamic language like Python? I'll be using the Rope extension for Sublime Text.
  • Testing. I've got PyUnit for writing the tests, but I still need a way to do end to end tests. Seeing as the main UI will be the console, I've written a script to intercept any writing to the console. Hopefully this will do the job. 
This is all I can think of for setup now, anything I've missed will have to be added along the way.

One of the things I love about developing today is that more than likely someone else has done something before and blogged about it. Most of the development environment decisions came from this posting.

Next step is to do some analysis on the basic behaviour I expect out of the system.


Saturday 23 February 2013

A real life project: Poker Game

I was recently involved in a discussion about how an implementation of a poker game might work out and I've decided to run with the idea. I've never created anything useful in my spare time before, I prefer to read and tinker with ideas, so this is a big undertaking for me. Trying to find the time to see it through will be a challenge because I have a) a day job and b) a life outside of development, but, the more I think about this project the more interesting it sounds so, yeah, let's give it a go.

There's a chance that I'll tinker with this idea for a while and then move onto something else, so I need some motivation:
  • I'm a fan of the GOOS book and I've been thinking about building the project they work on. There's lot of similarities between the two project so it's a good chance to follow through on that
  • My day job limits me to stuff that is necessary to there, so this is a chance to work with technologies that I wouldn't normally
  • Blogging it gives me a something I've never had before, a start to finish record of a project.

So there's the idea and the motivation, all that's left is to go ahead and do it, but first the sales pitch.


Sales Pitch

It's a poker game with developers in mind. Developers will be able to write a poker player in any language that they choose and have their algorithm compete against other developers algorithms in a poker game.

It's going to look something like this


The dealer will handle all of the usual dealer tasks, like dealing the cards, managing the pot and telling the players when it's their turn. Once there is a common language defined (in this case poker terms like Bet, Raise etc.) the dealer and the players can interact.

Some Initial Analysis

I don't think this is going to be a trivial project, which is one of the things that attracts me to it. There will have to be communication between the dealer and the players and allowing different software components to communicate like this is a new area for me. Another big area is the poker logic.

The communication between the players and the dealer

There's two challenges in this area. Firstly the communication will have to be two way so all components will need to both listen and send messages at the same time. Keeping the dealer and all the players synchronised should be a bit of work. I'll have to work to avoid things like one waiting indefinitely for another. 

Secondly, there will need to be some privacy in the communication when the dealer deals the initial hands; each player should only see their own hand. The simplest type of communication would be for everyone to poll a database table, but that would allow all the players to see all the hands. In the GOOS book they use the XMPP protocol to handle messaging; using XMPP would allow me to send direct messages and would (I think) give me a nice messaging setup. I haven't done anything like this before so I need to do some swotting up on messaging in general first.

Whatever I end up using is going to have to meet these two requirement:

  • Two way communication 
  • Private communication


Poker logic

Dealing from the deck of cards, keeping track  of the pot, keeping track of the game and figuring out who's hand has won. A quick look around the web tells me that none of this stuff is as easy as I would first think (nothing ever is on software, is it?) I'm already comfortable with the rules of Texas Hold 'em so knowing the business area is a bonus to me. There's lots of stuff to do here, more than I would like really so hopefully other people will have developed something similar before and there will be bits and pieces of code I can re-use out there.


So there it is, lots of work ahead but I think I'm going to like it.