This site mainly exists as a distribution point for my family photos to other family members. It sometimes also serves as a front face for other sorts of data that I want to share elsewhere, and for any web experimentation that I am doing at the moment.

The pictures web site is statically generated by a custom Java process that I put together. When Elsie plugs the camera into her iMac an rsync begins to to this Ubuntu Linux host. This provide a minimum of disaster recovery for the photos and gets the photos onto an external drive on the web server. It then uses ImageMagick to make the thumbnail sets, then writes out all of the html pages. All content is static so that I can simply mount the external drive under any web server or under a new OS installation.

I play Go on Kiseido server from time to time. I made good progress during the time that I was studying seriously. I'm realistically about 7kyu ("ie: I require 7 handicap moves from a 1dan aka black belt").

SmartGo is by far the best tool for learning, but unfortunately continuing to use this will have to wait until I upgrade to an Intel based system.

Go is usually played as a 2 player game on a 19x19 board, but it's really a fascinating piece of mathematics.

The only rules are: that which is surrounded by enemies dies of starvation, players take turns, a player may pass at any time. The other major "rule" of ko, is really just a consequence of the assumption that given the same board state and players making the "Best" move, then choosing a path that puts the board into a previous state will put it into an infinite loop... which would only be broken out of if after a possibly infinite amount of time, a player changed his mind. So it can be viewed as the game in fact being infinite, with implicit infinite loops being hidden from view. Even the end of the game is essentially terminated in an infinite loop. When both players pass, the first player to pass doesn't change his mind and the game stops. This can be thought of as an infinite loop of passes.

Most rule sets don't allow suicidal moves, though the mathematics is more general if they are allowed (because you can play in any open position in that case.) The game takes on a completely different character when generalized to N-players. I am no fan of silly and pointless variants on the basic game (which I won't name), but generalizing to N-players is a truly interesting variant - especially because the classical game is just a special case. In that case, the other players are both allies and opponents in different portions of the board. It is obvious who the opponent is only when there are two players. With N-players, this is the most important lesson with real world applications:

So going from 2 players to 3 players changes it from a perfect information zero sum game, to having a more poker-esque character in spite of still being a perfect information game. You win by being strong without inspiring so much fear that all efforts are directed towards your destruction. If your strength is indisputable, then the strategy is to get the others convinced to cooperate for their own survival.

And the other lesson that is also apparent in the classical variant is the requirement of two "eyes" (posessing a pair of undeveloped territories) to sustain life indefinitely; in which case, filling one of them is tantamount to suicide.

This javascript implementation of the Goban might be useful to create an Ajax implementation of an n-player Go server. (I don't know of any n-player Go servers at the moment, though some random developer in china asked for permission to port my .NET version (which originated in Java) code to his Java code a few years ago. I'm amazed that I was even be asked for permission, as I simply posted the source with no mention of license.) The board is the trivial step. I would have to create a good parser for the standard Go game file format to even think about doing a game server that would be of any use to anybody.

I also play around with Rubiks cube. I don't solve so much for speed as for simplicity of the solution, and being able to visualize the end result before making the moves. I take about two and a half minutes, and use 4 inefficient, but short processes (with a couple of variations requiring some judgement) to accomplish it. People that actually care about solving speed think of 30 seconds as being within reach of anyone who studies a speedcubing system with any seriousness. My solution is derived from the book linked at the top of the page, but I have replaced some of the long unexplained moves with shorter ones of my own that simply require a little more judgement to shorten the individual processes. If I have any goal in continuing to play with the 3x3, it's in being able to look at the cube as few times as possible.

I can solve the 4x4x4 in 30 minutes, and have managed to get a 5x5x5 cube as well. (Without memorizing any specific processes; free-form solve.) It took me a few hours when I finally got it, but I took about a half hour the second time. It's a matter of learning how to put the 4x4 cube into a state where it is equivalent to a 3x3 cube from that point forward. (From that point on it was solved in about 3 minutes. A few times before I got very close to the end before I realized that it can look like it's equivalent to a 3x3, but there are some twists that would not be possible in a 3x3 cube; making it impossible to solve as if it is a normal cube.