January 7, 2014
The Distributed Tic-Tac-Toe KataInspired by something I've recently started with my apprentice Will, I got to thinking about concurrent and distributed logic.
It's one of those odd things that actually comes up a lot on most developers' day-to-day work, but perhaps we don't explicitly recognise it as such.
A lot of thick web client apps, for example, deal with issues relating to the fact that multiple clients may be interacting with the same data at the same time. Some handle it more elegantly than others.
But when was the last time you sat down and thought "I'm just going to spend a bit of time practicing writing concurrent logic"? I searched on Teh Internets, and couldn't find any code katas specifically designed to exercise those muscles.
So I've invented one, which I've been wrestling with this morning with various combinations of technologies.
The kata's requirements are quite simple:
The Distributed Tic-Tac-Toe Kata
Write a program that allows two players to have a game of Tic-Tac-Toe remotely. The program should know whose turn it is and enforce taking it in turns to make moves. The program should know whether a move made by a player is legal (i.e., is that square empty?), and be capable of detecting when the game is won or drawn. The outcomes should be reported to both players along with the current state of the game (e.g., by refreshing the screen)
To implement the game, you'll need to client applications. These could be dynamic web pages, or Flash applications, or Java applets, or desktop apps, or mobile apps - anything that can connect to a network, accept user input and display the state of the game, really.
You'll have some choices as to how you slice and dice the design. It could be that both clients handle the work between them with a peer-to-peer connection. Or maybe they both connect to a server that handle's the game logic and co-ordinates centrally. It's up to you.
To co-ordinate the 2-player logic, your distributed app will have to do a little dance. For example, if player 1 makes a move that doesn't end the game, then player 1 needs to be prevented from making another move until player 2 has completed her move. And so on.
Sounds easy, right? Well, off you go, then!
Remember to maintain your discipline. There's more to think about than in your usual code kata, where the problem is self-contained and all happens in a program running in a single thread in the same address space, all written in one programming language.
Once you've cracked it - perhaps trying out different technology solutions - then maybe consider a more complex multiplayer game. How about distributed Monopoly?
Posted 1 week, 6 days ago on January 7, 2014