Archive for the ‘Go’ category

From iPhone to Android

June 2, 2010

Starting this friday I’ll be losing my wonderful iPhone and immersing myself into the world of Android with the HTC Evo. The decision has less to do with dissatisfaction with the iPhone or the merits of Android, and more with moving from AT&T to Sprint. My fiancé had been on Verizon and I was on AT&T. Her contract was up and we decided to merge to a family plan of some sort to save money. While originally we were going to move her to AT&T, she didn’t like any of the phones and AT&T was a bit expensive (and a pain to set up). After some research, it became a simple math problem that Sprint won out by saving us $50 a month.

Android Logo

The Android Logo is a little green robot man. Hopefully he will prove to be friendly.

So I’m selling my iPhone (eBay link) and switching to the Evo in order to save some money. However, this does bring up an excellent opportunity as a developer. Mainly in starting to learn about Android development for making mobile applications.

I find the Android development environment quite interesting. I’m not as big of an eclipse fan, preferring IntelliJ IDEA myself, but the Android integration with Eclipse is mighty slick. Having it bring up the simulator was probably as easy as it is for the iPhone. Interesting opportunities arise.

While programming for the iPhone is all done in Objective-C, programs in Android are done in Java or other JVM compatible languages. The ability to use Scala or Groovy for making mobile applications. Granted the integration for Scala and Groovy might not be as good as straight up Java, but it’s still a benefit that it’s available. Also, since I’m a Java developer at my day job, jumping into Android programming should be a lot easier as I will just need to get used to mobile development and not a whole programming language at the same time.

However there are parts of my iPhone I will miss. Since I play Go a lot, I’ve been very involved using a program called Boardz for turn based play. I’m not sure if there’s a good alternative app for the Android (I’m sure I’ll be looking on Friday). However, if there is not it actually provides me with an excellent opportunity. Basically to create my own version for the Android.

You see, I’ve always been interested in doing personal projects, but I’m never able to come up with a good idea. Having an excellently delivered piece of mobile software that will be unavailable on my new platform gives me a perfect opportunity to recreate a similar program for myself and others. I’ve already started a bit by starting a project to convert parts of the Fuego Go library over to Java. Ideally when I have a basic library for dealing with SGF files and game moves along with calculating things like ko and final scores, I’ll be able to plug in a nice Android interface to it and build a server, maybe on App Engine, to handle game events.

If anyone is interested in collaborating on a project like that, drop me a comment. I’ll have some actual code posted to my github project page later today.

Relating Development To Go

May 14, 2010

This is a really niche topic of discussion. Those who have both practiced software development and played/studied Go may appreciate the relation. If you’ve never played go and are not a software developer… well I can’t really help you there. However, today I found the similarities astounding.

There are a lot of terms from Go that are used to describe the game or situations in the game. Things like “lightness” and “flexibility” where your stones are spread out to cover a larger area but with gaps in the middle. The idea being that since they are spread out you’re not too attached to any one stone and can adjust your battle plan by sacrificing a single weak stone rather than being forced to protect a large group of more valuable, and yet still weak, stones. If you cluster your stones together too much, especially at the beginning, you’re said to be over concentrated and are not being very efficient with your stones. Your stones can become “heavy” when they’re too large to lose, but very difficult to keep from being captured. You are forced to make moves that benefit your opponent more than yourself just to make sure you don’t lose those heavy stones.

Japanese style floor goban. Large board tables like this are often made of Kaya, a rare japanese tree known for it's properties as Go board. They are often very expensive.

What does this have to do with software development? Quite a bit actually, especially if you follow the Agile Development Methodology. When creating a software design, you will be more rewarded if you keep your design light and flexible, able to adapt to new change as it happens. The ability to sacrifice (refactor) a weak section will help your greater strategy of winning (producing a complete product). When pieces of your development get heavy, they are difficult to refactor, possibly because they’re not designed to be tested. When modifying that section of your code, it tends to break other sections. Since you built a bad foundation early on and refused to sacrifice it (refactor), you end up being stuck trying to save a dying design and spend a lot of time and effort for little gain.

Once you’ve sacrificed enough bad designs and followed your test driven development to the proper design, your code becomes flexible and more maneuverable. In Go terms, sections of it become “Alive“. Building off of those sections, as long as you keep to your design principles, makes fixing bugs and developing new structures a lot easier.

There are several ways to play go. There is speed Go, where you give yourself only a few seconds to play your piece. There is Go played with a normal time limit, usually an hour or so for each player with some overtime after that. And there’s games which are not timed at all. Speed Go often results in a lot of mistakes, however you can finish a game a lot faster. The result won’t be the best however, and you wouldn’t want to use it to represent your skill in the game. Regular Go is what is good enough for most people. You spend a reasonable amount of time thinking about most moves, but in general you rely more upon any experience you have than reading out the board. In an game that isn’t timed you can really sit and concentrate on your move. You might think about dozens of possibilities of what you could play and the replies your opponent can make and future moves you would make to those replies, etc. It can take a long time, but the resulting moves can be brilliant at times, and often will result in the best game.

I find that too many people play Speed Go in their development efforts. They’re told “Fix this bug” or “Make something that does this” and they open up their IDE or programmer’s editor or echo and cat and put some code in files trying to solve the problem as fast as possible. Problems are dealt with as they come up. There isn’t really a design per say, just how the code all comes together. The problem with this is that the code created by Speed Code is often very problem specific and difficult to fix and modify. There’s no flexibility, and often pieces of the code are heavy.

The last form, coding without a time limit, can yield some surprising results. I’m not saying that you should give everyone unlimited time to code even the most simple of things, nothing would get done. Nor should you try to get the “perfect” design before coding anything, as what you’ll get in the end won’t be worth the time spent. Rather I think that, especially at the start of the project, some actual thought should be put into what you’re coding. This thought shouldn’t be just in your head however, it should be in the form of Tests. If you write up tests that utilize the code you haven’t even written yet, you can get a good design before you code. If it seems hard to test, try something else. You should be writing and throwing away tests as you work on the design of the piece of code you’re tackling. This is equivalent of reading ahead moves in a Go game, seeing where the pieces might lead.

Of course there’s only so far reading ahead will get you. Soon enough you’ll have to implement what you’ve designed and look at the next piece. However, don’t assume just because you have tests and an implementation and that they all work that you can’t change them any more. Everything you write should be flexible to be rewritten or refactored and thrown away or modified to handle new business rules or requirements. Having the tests in place will make modifying the code easier as you’ll see where things will break and can modify them accordingly.

I noticed this correlation in my own code just today. I was finishing up an implementation before moving on to the more difficult part of my project when I realized that from the structure I have built up and the loose framework that I’ve designed, the “difficult” part of the project was able to be solved in the framework that currently existed. The same framework that I’ve built up and torn down and built up several times over the past few months.

Go/Chess Timer with Camera

March 5, 2010

So as I mentioned previously, I’ve been interested in building things recently. I haven’t yet purchased an Arduino yet (I’m waiting to find the right package and for some spare money), but I still think about projects that I want to do. I’ve glanced at several things that other people have done and while making my own skill crane might be pretty cool, I came up with another idea that’s been floating through my head for a few days now.

I’m a big Go fan, so for me making something related to Go would be interesting. There are lots of programs for playing games on the internet which have the unique advantage of recording the games that you play so you can exactly review them later. For physical games, you need to create a kifu to record the game, which requires that you write down your move after you make it. Writing the move down however can be distracting from thinking about the game. In major games, professionals will have a recorder who sits and records all of the moves for them (they also keep track of time), but that’s not very feasible for the majority of players.

So the idea is to make a device that automatically creates kifu for physical board games. I think there is a fairly obvious path for doing this as well. In a tournament style game of Go, players would use a Go/Chess timer for keeping track of how much time each player has. The devices are generally a box that sits on the side of the board with two largish buttons on top and two clocks underneath. The clocks show the time for each player. When it’s your turn, your clock is counting down the time. When you finish your turn, your clock stops and your opponents clock starts counting down. There’s a few more advancements that can happen in these clocks like dealing with overtime and such, but that’s the basic principle.

Creating the clock with an Arduino shouldn’t be too hard. Two buttons (plus maybe a few more for configuration), two LCD screens, and maybe something to make noise when you run out of time should be fairly easy to wire up and program for a basic timer. What I’d like to do though is also attach either a web camera connected to a computer (laptop) or a digital camera that has a remote shutter control. The idea is that when you press the button to signify that your turn is over, the web or digital camera takes a picture of the board. You can use these pictures later to manually recreate the game in like an SGF file, or if I’m feeling really ambitious utilize some digital photo analysis and recognize where the pieces are played and automatically create SGF files. This way you can review even your physical game after having played it.

The PS3 eye Toy camera is my current target camera platform. There are USB drivers that make it run on windows (and I can look for Linux drivers) so I can pull data off of it. Since I acquired my camera with the Eye of Judgement game, I already have a neat stand that is designed to look down on a surface. When a button is pressed, the Arduino can send a signal over the serial cable to the laptop (or other computer) to signify that an image should be taken. If I later use a digital camera with a remote shutter control, then the whole process wouldn’t need a separate computer at all.

I realize that the same thing can be done just using software on a general PC and designating two keys for the timer, but I think having a dedicated device with better buttons that feels more like a game timer would be a more enjoyable experience. Also the ability to add blinking LEDs and/or sound when your time is running out would add to the overall feel.

If I ever do make it, I’ll be sure to post some info about the end result and some pictures. I’m going to go back to pondering my future building plans.