Those of you with big Poker Copilot databases are probably familiar with the longish “Optimising Poker Copilot database…” process that runs whenever you start Poker Copilot. The next update partly eliminates this. The optimising will only be performed if there’s at least 10,000 additional hands in your database since the last optimising process. This means Poker Copilot will start up much faster.
I’ve never had a complaint about the slow starting up, but it certainly affects me when testing new features and searching for bugs. So I guess I’m the main beneficiary…
I’m the author of poker software called […]. I’ve read through your blog posts. I see you have a deal where you offer a free license to bloggers in exchange for a review. i really like that idea and am thinking of offering it myself. i was just curious how you handle the disclosure? Do you allow or want the bloggers to disclose to their readers that you offered them a free license in exchange? i would think that would taint the review, even if you obviously allow fully unbiased reviews.
A good question. My answer:
I tend to be very open to my customers about how I publicise my software. I’m quite happy for bloggers to disclose or not disclose, as they choose, that they got a free license. I’m also happy for them to write positive or negative reviews, short ones, or long ones, in a language I may not understand. With this promotion I’m seeking links in context, that help my Google ranking. I’d never do paid links to promote my software. That’s a big Search Engine Optimisation (SEO) no-no.
I _have_ learnt, however, to hold back the free license UNTIL the review is posted… Otherwise sometimes the review never materialises…
Therefore I have cancelled development of the next major version of Poker Copilot for Mac OS X, Poker Copilot 3. This was not a knee-jerk reaction. I’ve spent much time in the last two months contemplating how best to act.
But not all work on Poker Copilot is over. I’m going to take some of the planned – as well as some already-added – improvements from Poker Copilot 3 and add them to Poker Copilot 2. These will be free updates for all existing Poker Copilot 2 customers. All current and future Poker Copilot customers will continue to receive full support. I’ll keep fixing problems that arise as the online poker rooms update their software.
Support for PokersStarsBE (Belgium-specific PokerStars) added.
What’s fixed:
Merge Network stats now back to normal.
Note that the Merge Network all-in EV values are still wrong in some cases, and are likely to stay wrong. This is because of Merge’s idiosyncratic hand history format. In some situations there is not enough info in the Merge Network hand history file to calculate this correctly.
While the world of online poker remains in a critical situation, I’m spending time on a mini-project to learn HTML5 and the latest greatest JavaScript techniques. As I’m sure most of my Poker Copilot blog readers are not so interested in this, I’ve started a new blog to follow this project.
We see a lot of feature-driven product design in which the cost of features is not properly accounted. Features can have a negative value to consumers because they make the products more difficult to understand and use. We are finding that people like products that just work. It turns out that designs that just work are much harder to produce than designs that assemble long lists of features.
Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. The more features there are, the more likely one will develop problems or will interact badly with another. In software systems, there is a storage cost, which was becoming negligible, but in mobile applications is becoming significant again. There are ascending performance costs because Moore’s Law doesn’t apply to batteries.
Features have a documentation cost. Every feature adds pages to the manual, increasing training costs. Features that offer value to a minority of users impose a cost on all users. So, in designing products and programming languages, we want to get the core features—the good parts—right because that is where we create most of the value.
We all find the good parts in the products that we use. We value simplicity, and when simplicity isn’t offered to us, we make it ourselves. My microwave oven has tons of features, but the only ones I use are cook and the clock. And setting the clock is a struggle. We cope with the complexity of feature-driven design by finding and sticking with the good parts.
An advantage of using blogging software created and maintained by an Internet juggernaut is that when they add new features, your blog gets them too, for free. The Poker Copilot blog uses Google’s blogger.com service. Blogger now has these new snazzy ways to view this blog:
I’m continuing with my HTML5 experiment. It now has context menus (aka right-click popup menus) and editable text. I’m still astounded how much one can achieve with little code. If one can work out the right code to use. For example, this single function is all I needed to write to implement context menus (with a little bit of additional CSS and jQuery support):
function dubbiyaPopup(x, y, items) { var clear = function () { $('.dubbiyaPopupOuter').remove(); }; clear();
$('body').append(''); $('.dubbiyaPopupOuter').css("left", x + "px"); $('.dubbiyaPopupOuter').css('top', y + 'px').fadeIn(200); for (var i = 0; i < items.length; i++) { var item = items[i];
var s = '#dubbiyaPopupItem' + i; $('.dubbiyaPopupOuter').append('
' + item.text + '
'); $(s); } $('.dubbiyaPopupOuter').click(function (e) { var id = e.srcElement.id; var s2 = 'dubbiyaPopupItem.'; if (id.substring(0, s2.length) === s2) { var num = parseInt(id.substring(s2.length)); var itemFunction = items[num].itemFunction; itemFunction.call(this); } });
Although there’s not much code there, it took me a couple of hours to make it work properly. Actually, I’m not sure if it works properly because testing it properly is awkward.
I’m subjecting myself to a self-run crash course in everything JavaScript. Here’s what I’ve learnt:
JavaScript is almost certainly the most-used programming language on the planet. That’s because we all surf all day, and the only language that runs within a web browser is JavaScript.
JavaScript was created in only 10 days, under enormous pressure from his managers, by one person, Brendan Eich. This means it never got the chance to be tested thoroughly and refined. Eich, by the way, means Oak in German, and the Java programming language – which has almost nothing to do with JavaScript – was originally called Oak.
To make using JavaScript bearable, one should use a JavaScript library such as jQuery or Prototype.
If you are not a programmer, this post won’t interest you.
I’ve continued a little on my HTML5 experiment, which you can see here if you are using the latest and greatest Firefox, Safari, or Chrome. I’ve added Undo and Redo – use [Cmd] + Z for undo, and [Cmd] + [Shift] + Z for redo.
Adding Undo and Redo seems complicated unless you know one of the proven software design patterns for implementing this. For example, the Command pattern. Each action, such as moving a shape around, has a Command object, which contains two methods: one to perform the move, and one to perform the undo. These are kept in an undo stack. When the user performs an undo, you pop the stack, call the undo method on the command object you popped, then push the command object onto the redo stack.
JavaScript makes it extremely easy to implement this, because of its first-class functions, aka lambdas; and the low-hassle way to create objects. Creating an object can be done on the fly without any class definition:
After spending recent years programming mostly in Java and a little in Objective-C, I have mixed feelings about these JavaScript constructs. It is awfully easy and concise to code features such as Undo and Redo. On the other hand, the code lacks all type-safety features that catch many simple programming mistakes at compile-time.