I spent the last hours before release hunting down an extremely obscure bug. If your Mac was set to the Tunisian timezone and you had hand histories for April 2009, Poker Copilot would crash. Tunisia changed their daylight savings rules this year and my date library wasn’t aware of the changes. Which caused another library to think April 1st, midnight, was late March 31st. Which caused yet another library – the charting library – to panic, as it thought it was finished dealing with data for March.
Ah, the life of a modern programmer! We have great off-the-shelf libraries, but occasionally, like petulant children, they refuse to play together. And then we have to act like mediating adults and force them to co-operate.
Now I’m taking the girlfriend out for lunch to celebrate.
I just uploaded what I hope is the final beta release of Poker Copilot 2. You can download it here.
This solves the final serious issue I mentioned yesterday. That issue prevented the HUD from working with PokerStars if your PokerStars app was somewhere other than in your Applications folder.
I’ve also turned auto-refresh back on, once all your hands are loaded. To be precise, the charts and stats auto-refreshed after each hand, if
there are no more than 5000 hands in your database; OR
if anyone was considering a mac but was worried about their poker suffering, I wouldn’t: poker lives, and it lives on the mac!
The blog post has something to say about Poker Copilot:
Although it is fairly basic vs Poker Tracker 3 or Hold’em Manager, it does go someway to filling the void. I’ve only been using it for 24 hours but I had zero problems setting it up, it hasn’t missed any hands, hasn’t frozen or had any other compatibility tantrums. Something that neither Poker Tracker or Hold’em Manager can claim, at least in my experience.
That’s exactly what I aim for with Poker Copilot. Software that simply works.
There is only one serious known issue remaining. Once I fix this Poker Copilot 2 will be just about ready for release. Except I’ll need to make new screenshots, a new video demo, and update the help text.
I’ve been quietly rolling out new beta releases every day or two. The latest beta, as always, is here. Thanks to those who have been looking out for new updates and trying them out.
There was an unexpected side-effect of releasing the beta: sales! I activated the “register” and “buy now” functionality in the beta for the sake of testing. I didn’t actually expect people to use these features to buy version 2 yet. But some people did. Early adopters, you are a small software company’s best friends.
C’mon Steve! New zealand is not on another planet where nobody knows the history of the US of A, where some kind of “community gaps” had and still have some importance to lots of people, to say it mildly! The election of Obama does not erase USA’s not so far racist past.
To an American my surprise may seem naive. But I’ve lived in four countries – New Zealand, Australia, UK, Germany – and have never seen an official form asking for my race. That’s not to say that those countries have no race issues. But some effort is made to pretend they don’t exist.
Anyways, now I’m curious to see New Zealand birth certificates from previous generations, to see if race used to be recorded.
Here’s a copy of Barack Obama’s birth certificate:
As a New Zealander, something here amazes me: the race of his mother and the race of his father are recorded. Does this still happen today in the USA? For what purpose would Hawaii record this information?
What if a few months later someone adds another method:
public class Threshold {
private long threshold = 0;
public synchronized long getThreshold() { return threshold; }
public synchronized void setThreshold(long threshold) { this.threshold = threshold; }
public boolean isZero() { return threshold == 0; } }
Suddenly it is not thread-safe. The person who added the new method didn’t realise that all accesses to threshold had to be protected. Now the isZero() method might be checking the value of threshold midway between the setThreshold() method changing it. The results are unpredictable.
This is a bad problem. Here’s why:
the code compiles.
the unit tests still pass.
the app testers will not detect the bug
almost of the time the code will still work. But sporadically, unpredictably, unfathomably, the code will fail.
I found – and fixed – such a problem in Poker Copilot a few days ago.
Currently the only way I know of to detect such problems is careful code reviewing. In a one-person company, careful code reviewing isn’t possible. In most other software teams it is possible but doesn’t happen.
So what can be done about it? I don’t know. It would be nice if a class could be marked as synchronized. Then all methods would automatically be synchronized. It would also be nice if there existed an annotation to indicate the same thing. Our static analysis tools would be then able to ensure that all methods were indeed synchronized.
This is one of many examples that demonstrate how brittle thread-safe code is.
If you bought Poker Copilot 1 on or after 22nd March, you are entitled to a free upgrade to Poker Copilot 2. Your license key for Poker Copilot 2 will be sent in the next week or so.
If you bought Poker Copilot 1 before 22nd March, you can upgrade for $29.95. You can buy an upgrade here.
Regards,
Steve ————————————————— Steve McLeod Founder, Poker Copilot http://www.pokercopilot.com
Under the early access program (EAP), I’ve now released the first beta release of Poker Copilot 2. It’s EAP build 27 and you can download it here: http://pokercopilot.com/eap.
There may still be bugs; I’m actively testing at the moment.
Improvements since the previous EAP build include:
a one-third reduction in time needed to load hands into the database
a much more stable HUD. I spent much time last week profiling the HUD, and fixing inefficiencies and threading problems
…software which has been released to users for software testing before its official release. It is the prototype of the software that is released to the public. Beta testing allows the software to undergo usability testing with users who provide feedback, so that any malfunctions these users find in the software can be reported to the developers and fixed. Beta software can be unstable and could cause crashes or data loss.
