Posted tagged ‘Go’

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.


December 18, 2009

There’s only two more posts for me on here before 2010, and due to not being able to think of anything else to post about, I’m going to place my top development-ish related New Years resolutions that I’m going to make up on the spot.

  1. Finish an iPhone app – I’ve started a few small apps but I haven’t had one fully finished in a usable form. I want to create at least one app and release it for free on the app store, just for fun.
  2. Design an elegant Report system – Our current application has difficulties generating reports due to bad code and weird business rules. I want to rewrite the entire report system into something elegant and fast.
  3. Play more Go – I really like Go, and I haven’t played much in the last year or so. I’d like to start more games in person and maybe schedule regular times to play online games. I feel that Go helps me as a developer for both its analytical possibilities, along with the strategic maneuverings that are useful in any office place.
  4. Be more awesome – This one is sort of vague. By being more awesome I mean to increase my productivity, make myself someone reliable that people go to for help, push the boundaries on development and research for my team, and generally become more awesome at work.
  5. Work on more home projects – This goes a bit along with the first one. I do a lot of development at work, but it’s a very narrow area of development. In order to really expand my abilities as a software developer I have to free myself of the project restrictions placed on me by my current priorities at work and do more spare-time development. Maybe I’ll make a game or improve some process that I do by automating it. Maybe I’ll find an open source project to contribute to. Speaking of…
  6. Contribute to an Open Source project – It’s often quite a bit more difficult than people make it sound to contribute to an open source project and have your changes accepted. Just reading up on the code for some projects in order to understand it enough to make a change can take a lot of time and dedication. I’d like to pick a project to help out on and contribute to as I feel it will help me as a developer along with giving back to the community.
  7. Improve my average pomodoro count – Currently my average number of pomodoros is lower than I would like. I’d like to increase how many pomodoros I complete per day by an average of 3-4. Trying to remove procrastination activities and learning how to focus better is still an ongoing process.
  8. Continue to update this blog – I’d like to be able to do another post like this one in about a year. That means not giving up on the blog and making it part of my routine so that it doesn’t get abandoned.

That’s just a quick list that I came up with in 10 minutes or so. It’s not exhaustive and I’m not sure if I’ll actually meet all of the goals but I’d like to try.

The Game of Go

December 7, 2009

This post actually has very little to do with programming, but is about a topic that some programmers might find interesting anyway. As the title implies, it is about the game of Go; which is also my favorite board game.

As a quick recap for those who don’t know, Go is an ancient chinese game developed around 4,000 years ago and played mostly by chinese, korean, and japanese people. However there is a growing player base in the US along with strong players in Germany and other areas of Europe. Go is the oldest board game still played in its original form, which is interesting because the rules are still being tweaked in official play. The game is played on a wooden board with 19 horizontal and 19 vertical lines called a goban. Two players place white and black playing pieces called stones on the intersections of the grid in an attempt to surround empty space and/or opponent pieces. Each player is attempting to control more of the board than the other player.

The rules are actually really simple. Players take alternate turns, starting with black, placing stones on the board. Stones of the same color that touch each other are considered a unit and treated as a single stone for the purpose of capture; to capture one you must capture them all. To capture a stone you must surround it with your own stones so that the unit no longer has any empty spaces next to it. Stones cannot be moved after they are placed unless they are captured, in which case they are removed from the board. You cannot place a stone on the board if placing it would result in immediate capture. This means you can’t place a piece on an intersection that has no free space next to it, unless that piece would capture a neighboring piece of the opponent and therefor free up some space. At the end of the game each player counts up the number of empty spaces their stones are surrounding and subtract from that the number of stones of theirs that were captured (Japanese rules anyway… there are variations). Whoever has the most points wins.

Now there’s a few extra parts to this. Since black goes first, black has first choice at placing a piece on the board. This gives black an advantage that is worth a few points. To compensate for this, white is given a ‘komi’ at the beginning of the game, currently often 6.5 points. This means that white starts with 6.5 points automatically for having gone second. The half point is there to prevent ties. There’s also an additional rule that the board cannot repeat itself. Certain configurations will result in what is called ‘ko’. From Sensei’s Library: “[Ko] describes a situation where two alternating single stone captures would repeat the original board position. Without a rule preventing such repetition, the players could repeat those two moves indefinitely, preventing the game from ending. To prevent this, the ko rule was introduced.”

The game is fairly easy to learn. Children as young as 2 can pick up the basic concepts and some strategies for the game. Wikipedia has one of my favorite descriptions about Go as it relates to mathematics: “In combinatorial game theory terms, Go is a zero sum, perfect information, partisan, deterministic strategy game, putting it in the same class as chess, checkers (draughts), and Reversi (Othello); however it differs from these in its game play. Although the rules are simple, the practical strategy is extremely complex.” Quite a bit more complex than chess I would say, while easier to learn. A game like that is something I find intriguing.

While Go is more popular in Asia, there is some support for it in the US as well. The American Go Association has a ranking system, official rulesets, holds tournaments, and tracks clubs where you can go to find players to learn or play the game. A friend of mine hosts a Promote Go website that has club listings in an easier to search form.

There are many websites and books to learn Go. A company called Slate and Shell publishes what is probably the largest set of English books on the topic. You can also play games online for free if you cannot get in contact with any players in your area. A great place to start would be KGS, which has a simple Java client that works on all platforms along with a server that hosts many games for free. There are other programs that use the Internet Go Server (IGS) protocol and can connect to a variety of servers, the most popular of which is pandanet. There are also computer opponents (stay away from them for the most part) along with computer learning games and versions for other platforms such as the xbox 360 and most mobile phones.

I encourage everyone to give the game a try as it can be one of the most mentally rewarding board games you’ll ever experience. If you’re ever interested in picking up a game with me, leave a comment or email me at jearil at gmail dot com.