We’re currently making a Windows version of Poker Copilot for Mac. The Windows version is code-named Austin. If you want to be an beta tester of Austin, sign up here. And be eligible to win one of five free copies of Austin.
I’ve been using OS X exclusively for a few years, for work and for play. Since I stopped regularly using Windows, Microsoft released Windows 7, 8, and 8.1. Now that we are making Austin, I needed to get familiar with Windows again. I installed Windows 8.1 on a virtual machine and I was lost. I needed help.
To make sure that Austin plays nicely on Windows, for a few weeks I’ve hired Alex, a freelancer who spends most of his time doing things on Windows. He is spending a few hours every day testing Austin, and finding the things that do not feel right on Windows. Keyboard shortcuts, OS integration, the menu system, and window management are all being tested over and over again.
This barbary ape doesn’t approve of poor quality software.
In the process Alex has also found many small Poker Copilot bugs, inconsistencies, and oddities that have escaped my notice. So making a Windows version of Poker Copilot is also making the Mac version better. There are four main areas that are improving:
The first-time experience is improving significantly. Alex has a fine eye for detail. He records each experience with Poker Copilot that initially didn’t feel right or was confusing. An example: when Poker Copilot prompts you to enable instant hand history in PokerStars, until now, you’ve needed to follow that with a restart of Poker Copilot. The next update will automatically detect changes to the PokerStars hand history folder settings without requiring a restart of Poker Copilot.
Outright bugs are being located, hunted down, destroyed, and then, importantly, being retested. For example, it turns out that the View menu’s “View Options” screen was not working properly. Change multiple settings at once and only one of them sticks. The next update improves this. We’ve found several minor bugs like this.
Translations are improving. Alex’s mother tongue is German. So he has been able to evaluate the non-English use of Poker Copilot. He has found bad translations in the German translation of Poker Copilot, and some areas that haven’t yet been translated. This is a workflow problem that I’ll fix. The problem is this: some of the professional translators we’ve used only translated a file of strings, without then having a chance to check their translations running in Poker Copilot. So, for example, the english word “Record” was translated into German as Rekord. As a noun, in some contexts, this is correct. But as a verb, on Poker Copilot’s hand replayer, this is incorrect, and should be Aufzeichnen. I intend to make a better workflow for dealing with translations.
The general user interface is getting enhanced. I have thought carefully about each part of Poker Copilot’s user interface, and implemented it according to my opinions. Alex also has opinions, and often has been enquiring as to why things are done a particular way. I describe why, as best I remember, I chose to do things as I did. Sometimes Alex isn’t convinced and suggests a different approach. And sometimes he convinces me. For now this has only resulted in minor alterations, such as initial window locations, window titles, and some defaults. I’ve recorded bigger issues and will address them in the future in the next major version of Poker Copilot.
Quality Control is important
I wish I could do all the things that good software development teams do to ensure high quality software. According to Code Complete: A Practical Handbook of Software Construction, Second Edition, good teams execute formal design reviews, code inspections, pair programming, and high-volume beta tests. As a one-person company, I’m limited to less comprehensive techniques. Also, as a one-person development team, I’m limited by lack of motivation to do tedious-yet-useful tasks.
Until now, quality control in Poker Copilot has been a combination of unit testing, my own haphazard system testing, and customer feedback. It is clear to me now that this is not enough. Having a person dedicated – even for a few weeks at a time – to quality control is unbeatable for making a software product top-notch.
Things have been quiet here on the Poker Copilot blog lately. That’s because we’ve been busy working on a Windows version of Poker Copilot. The code name is Austin. It won’t be branded as Poker Copilot, because we are partnering with a big name in the world of online poker to bring Austin to reality.
We’ll have our first early access version of Austin available on May 16th, 2014. And we need your help (or the help of your Windows-using poker-playing friends).
In recent years, operating systems such as OS X have made it easy to monitor a file, folder, or set of files and folders for filesystem changes. This means a program like Poker Copilot uses fewer operating system resources (such as CPU) to find whether you’ve got a new hand history file in one of your hand history folders, or whether a hand history file has had a new hand added. It also makes the programming code dramatically simpler. Simpler code is less error-prone and easier to maintain.
I’ve tried twice to add file system monitoring to Poker Copilot. The first time was in the early days of Poker Copilot, in version 1, I think. It didn’t work because Full Tit Poker seems to keep a hand history file open all the time, rather than opening the file, adding a hand history, and closing it. Unfortunately OS X’s file monitor libraries don’t inform of the change until the file is closed. At least, this is my understanding of why the file monitor library works with PokerStars but not with Full Tilt Poker.
The second time I attempted to add file system monitoring was because I forgot that I had tried this years earlier and encountered the problem with Full Tilt Poker not closing files between writes.
If you open OS X’s “Activity Monitor” and watch CPU usage while Poker Copilot is running, you’ll notice that every 10 seconds or so, Poker Copilot has a sudden peak in CPU usage. That’s because Poker Copilot periodically scans through your hand history folders, looking for new files. Once a new file is found (defined as created within the last ten minutes), it is added to a list of files checked every second for changes. This is a quick process that doesn’t use noticeable system resources, because only a few files need to be checked.
This is one of the frustrating things about writing software (such as Poker Copilot) that is dependent on other third-party software (such as Full Tilt Poker). I don’t have just my own bugs and performance issues to worry about. I also need to code work-arounds for bugs in other software.
Poker Copilot used to have a Facebook page. Back then, managing it was clumsy and didn’t seem to offer many benefits. Now, Facebook has improved its product page dramatically. It’s also become the go-to source for news for many people. So we’re back.
The next update of Poker Copilot will give you SharkScope info directly in the HUD. Here’s how it looks:
The stats are fetched live from SharkScope’s website, so at first Poker Copilot will show “—” next to each statistic to indicate that the data is loading:
Some players have chosen to block their statistics from other SharkScope users. This is indicated with two X signs.
Not all players are in SharkScope’s database. If a player can’t be found you’ll see two question marks:
If you see two asterisks (**) something has gone wrong with contacting SharkScope. If this happens to you, you should send us an issue report, from Poker Copilot’s “Help” menu.
The SharkScope HUD layout defaults to showing “Av ROI”, “ITM %”, “Ability”, “Count”, “Profit”, and “Av Stake”. You can select from the full range of HUD stats from Poker Copilot’s Preferences:
As part of this change, there are now more slots available for custom HUD layouts:
Finally, this is all experimental and limited. If there is enough positive feedback, we’ll vastly improve SharkScope support in the next major Poker Copilot version.
, good teams execute formal design reviews, code inspections, pair programming, and high-volume beta tests. As a one-person company, I’m limited to less comprehensive techniques. Also, as a one-person development team, I’m limited by lack of motivation to do tedious-yet-useful tasks.
