"Rush Poker" on Full Tilt

Full Tilt Poker introduced “Rush Poker” overnight. It’s a funky concept. As soon as you fold, you get rushed to a new table with a different set of opponents. So you don’t get to develop a feel for your opponents.

I played Rush Poker a little today to make sure Poker Copilot works with it. It does, for post-game analysis. However the HUD is useless, seeing as the players change after every single hand.

At first I played ultra-tight on Rush Poker, waiting for a great hand. Then I noticed that everybody was playing ultra-tight. As the wisdom says, when the table is tight, play loose. I did that, raising whenever I had a pocket pair or a picture card, as long as nobody had already bet or raised. It seemed to be a winning strategy.

I’m curious to see what the optimal strategy for Rush Poker will be in a few weeks time when many people have had a chance to develop a strategy.

Amsterdam, Documentation, and Mac Poker Software

I haven’t got much work done these last couple of three days. I found somebody to write the Poker Copilot documentation. Conveniently, he lives only a 2.5 hour train ride away from where I live. Better still, he lives in Amsterdam. I’ll visit an interesting city on the flimsiest excuse. As far as excuses go, visiting a person working with me is far from flimsy. So to Amsterdam I went.

The trip to Amsterdam meant I spent little time in front of the computer. You don’t go to Amsterdam to sit in a hotel room using a computer all day! So please be patient if you’ve sent me an e-mail recently and I haven’t responded yet.

What I did make time for was to check Google far too frequently to see if my “Mac Poker Software” experiment has made progress. Finally, this evening, Google admits that the site exists. I found this out by doing a Google query for “site:macpokersoftware.com”

Until this evening, Google always responded with:

Your search – site:macpokersoftware.com – did not match any documents.

Now Google says:

Screen shot 2010-01-18 at 10.35.55 PM.png

Excellent!

Coping with Apple’s Java Policy

Mac OS X 10.6 (Snow Leopard) comes with Java 6. And only Java 6. Want Java 5? Not possible as far as Apple’s Java team is concerned, although there are backdoor methods.

This is mostly a good thing. Java 6 is better than Java 5. It runs faster. It starts up faster. Garbage collection is better. It has new APIs and new methods in existing APIs.

But it’s not all good. Java 6 does not exist for PPC Macs. Some of my Poker Copilot customers are still using Tiger and Leopard on PPC-based Macs. So Poker Copilot must run on Java 5 as well as Java 6.

This makes things somewhat complex. I use Snow Leopard as my main development operating system. I can ensure that I compile in a format usable by Java 5 by using the “-target 1.5” parameter when compiling. But I also have to make sure I don’t use Java 6 APIs or methods.

The solution I have found to this problem is this: to have an automatic build process running on a second-hand PPC Mac Mini running Mac OS X 10.4 (Tiger). When I make changes to Poker Copilot’s source code, I commit them into my Subversion source control repository. TeamCity, an automatic build system, detects the commit, gets the latest source, and tries to build Poker Copilot on Mac OS X 10.4 (Tiger) on a PPC machine. If it works there it will work for all my customers. If it doesn’t work TeamCity notifies of the problem and I can fix it immediately.

This problem must be faced by Objective-C programmers too, because Apple introduces new Cocoa APIs with each OS X upgrade.

Poker Copilot Database Improvements

Some Poker Copilot users have been having sporadic hangs or really slow refreshes. I suspect this is happening for users with loads of hands in their database. Like 1 million+. So I’ve been doing some profiling of Poker Copilot’s database queries.

I’ve stumbled upon a couple of full table scans taking place. To translate into English “full table scan” is database-speak for “dog slow”. A simple tweak or two fixed this, and reduced the time it takes to import a million hands by about 10%.

More aggressive caching has given a further 10% improvement. I knocked another 2-3% off the import time by removing some columns that were being populated but never used.

I’ve also created a new denormalised table for Position Summary and Stake Level Summary. To translate again, “denormalised table” is database-speak for “table that has unnecessary redundant information but goes at light-speed”. For big databases, this reduces the time taken for Position Summary and Stake Level Summary updates by two orders of magnitude. Two orders of magnitude? That’s right, what was taking 25 seconds now takes 0.25 seconds. I suspect this is mostly happening because the denormalised table is small enough to be entirely held in memory.

The downside of the new denormalised table is that it adds about 10% to the time taken to import a million hands. But I think it is a good trade-off. On my iMac, importing a million hands takes a little under two hours.

These changes have not been straight forward. I find a problem. I implement a trial solution. I run a full import of all my test data, which takes about two hours. I then measure the results, not just for the import but also for the various summaries and filters. Sometimes I find the trial solution has made things worse. So I have to undo the trial solution and go to plan B. Then I repeat the whole escapade.

This takes time. Mostly spent waiting. Which is why I’ve been spending time on the Mac Poker Software mini-site experiment. I hope that the database profiling pays off to give all users a smoother, faster experience.

Last night, while letting a million hands load, I played two tables simultaneously. The HUD continued to update within a couple of seconds after each hand for the full duration.

I hope to release a test version of this update for you to try out within a few days.

Paid Search Listings?

Part of Patrick Mckenzie’s suggestions for giving the Mac Poker Software website a quick rise to Google stardom is to get listed in two search directories: JoeAnt and Yahoo! Directory.

It’s so long since I’ve since used an Internet directory, I forgot that Yahoo! started as a directory, back in the infancy of the world wide web.

To my surprise, you have to pay to be listed in these directories. JoeAnt costs $39.99. Yahoo! charges $299 per year, an amount that made my eyes pop out of their sockets in surprise, shock, and disbelief.

But it’s part of the strategy so I gulped loudly and frequently, whipped out my credit card, and went ahead. Let’s see, if I can get six extra sales from this strategy then the directory listing fees are covered. Seven extra sales and I’m ahead.

Mac Poker Software

A couple of weeks ago, I unexpectedly found myself in possession of a new domain name, http://macpokersoftware.com/. I think I put in a backorder for it about a year ago, then forgot all about it.

But what to do with this asset? In a friendly email conversation, Patrick McKenzie gave me a strategy for using the domain to attract focused web traffic: Optimise the heck out of the site with some content and links and let Google go do what Google does well.

The strategy goes something like this:

  1. Put a WordPress blog on the site.
  2. Put a discrete advertisement for Poker Copilot on the site.
  3. Write some pages of relevant content.
  4. Get the ball rolling with a couple of well-placed links.
  5. Wait a couple of weeks for the Google juice to start flowing.
  6. Gradually make the page promote Poker Copilot more aggressively.

Steps 1 through 3 are done. Step 4 will be done as soon as I click on the “Post New Blog Entry” button. 🙂

I hope to post an update here with the results of this experiment in a month or two.

If All Support Emails Could Be Like This

C. is using the free 30-day trial of Poker Copilot and hit a problem with importing PokerStars tournament results. Instead of just describing the problem, he sent me a 1 minute 16 second QuickTime movie showing me exactly what he was doing.

With the movie, the solution was immediately clear. It’s a common problem. The Poker Copilot filters were set to exclude data he expected to see.

In a recent update I added the filter description bar:

Screen shot 2010-01-12 at 10.51.33 AM.png

I introduced this small addition with little fanfare. No-one commented on it. But I believe it has significantly reduced the number of support emails.

Starring Hands for Later Review

Sometimes while playing online poker, I find myself wanting to look closely at a hand that went unexpectedly. I can’t do it while playing so I need a way to remind myself to go back later and look at it.

The next update of Poker Copilot will solve this problem by introducing starred hands:

Screen shot 2010-01-11 at 10.36.04 AM.png

The star is a toggle. Click it once to star a hand, click it again to unstar a hand.

You can filter by starred hands:

Screen shot 2010-01-11 at 10.39.10 AM.png

Poker Copilot’s Head-up Display (HUD) has a new icon to let you star the previous hand played at the table:

Screen shot 2010-01-11 at 10.41.30 AM.png

This is a seemingly simple addition that turns out to be hard to implement well. There were several design issues and threading issues that I had to solve.

92.2% Borrowed Code

92.2%. That’s how much of Poker Copilot was not written by me.

Let me explain. Poker Copilot consists of 15.4 MB of Java code. 14.2 MB of that code is third party libraries. 1.2 MB is code I wrote directly.

In that 14.2 MB of third party libraries, here’s what you’ll find:

Awesome libraries I use daily in my coding

Google Collections – Java Collections on steroids. Preconditions. Functional Programming

Joda Time – how Java’s Date and Time APIs should have been done

Awesome libraries important for Poker Copilot

JFreeChart – makes all of Poker Copilot’s charts

Commons IO – has some code-bloat removing IO libraries

Commons Lang – has some code-bloat removing String manipulation libraries

Ehcache – allows Poker Copilot to cache many database results

JGoodies Forms framework – makes laying out Swing GUIs a cinch. But I really wish I could use something like Apple’s Interface Builder

Quaqua Look and Feel – helps Java integrate better with Mac

Mac Widgets – a swag of UI components that make Java look like native Mac

Rococoa – lets Java use Cocoa libraries when there is no Java alternative

Spring JDBC – removes the boilerplate code from Java database access

Swing Worker – handles long-running GUI tasks

IntelliJ’s Forms Runtime – makes GUI forms work that I built with IntelliJ’s GUI Designer

H2 Java SQL Database

Libraries I use sometimes or seldomly

Cobra – Java HTML Renderer that nicely renders bullet points, in contrast to Java’s built-in HTML renderer

Pure Java Hand Evaluator – a library to give descriptions of Poker hands that I hacked a little to fit in better with Poker Copilot

javacsv – parses CSV files

JDatePicker – used in the custom date filter

JavaMail – for reading Gmail Inboxes

The rest are dependencies of the third party libraries.

This is, for most of us, modern programming. Few programmers create low-level driver code, compilers, or operating systems. Seldom do we have to write a charting component or implement a hashing algorithm. Our task is often wiring together many different high-level components and third party libraries. The challenge is to make the libraries co-operate, to make the interaction between components reliable and fast, and to make the user interface that controls the components responsive and intuitive.

Amazon Mystery of the Day

I buy a lot of books on Amazon. Amazon has some odd books in the “Our Recommendations for You” section. The titles I buy are diverse, and as a result the recommendations can be surprising. Today’s surprise:

sudantravelguide.jpg

A travel guide for Sudan.

I can’t say travelling to Sudan is high on my list of things to do.