Friday, 27 December 2013

SeeingStars Second Beta Available

I managed to get a few hours over the Christmas period to work on SeeingStars. I’ve added a crash reporter, an issue reporter (accessible from the Help menu), and a “There’s a new update available” mechanism. Not much else has changed.

Download it here.

Saturday, 21 December 2013

SeeingStars 1.0 Beta Version Available

 A few days remain until I release SeeingStars: Real Time Odds for PokerStars on Mac OS X

Sign up here to be notified when we release AND get a 50% discount.

You can now download and use SeeingStars 1.0: Beta Test Version. I’m releasing this early version to help flush out issues, and to make sure things work on a range of computers.

Seeing stars screenshot version 1 pre alpha

Please send feedback to support@pokercopilot.com. Bug reports welcome.

Wednesday, 18 December 2013

SeeingStars: Coding yet Procrastinating

A few days remain until I release SeeingStars: Real Time Odds for PokerStars on Mac OS X

Sign up here to be notified when we release AND get a 50% discount.

I spent two hard day’s (well, two hard half-day’s) coding, and realised that I was no closer to releasing SeeingStars at the end of the day. I had avoided doing the dull work that needs to be done to make sure SeeingStars works at all window sizes, and instead decided that the screen-scraping engine underlying SeeingStars just HAD to be turned into an independent service that I can run and use from Terminal. “To make it easier to test and support”, I told myself. “To make the code better structured and aesthetically pleasing”, I imagined. The truth was, I was simply procrastinating.

Better-structured, aesthetically pleasing code satisfies my somewhat OCD nature. Spending time doing this gives me the illusion of progress. But actually, for version 1 of a product, I believe the most important thing is getting something usable running in the hands of real users. Nothing beats delivery. I should make that a mantra:

“Deliver the product. All else is secondary”.

Thursday, 12 December 2013

SeeingStars: Test test test

A few days remain until I release SeeingStars: Real Time Odds for PokerStars on Mac OS X

Sign up here to be notified when we release AND get a 50% discount.

This screen-scraping stuff is fickle. A small change to the layout of the screen, the window size, or colours, and the screen-scraping techniques can fail. A small change to one part of my screen-scraping code, and card recognition can fail. Like humans, my program doesn’t like change.

Therefore I’ve been creating lots of automated tests. So if problems do occur, they’ll be easier to isolate and fix.

I like automated tests. They make me feel more confident about my code. They allow me to fine-tune things and still expect existing code to work - or to find out quickly what broke.

Meanwhile, SeeingStars is soooo close to being ready for beta-release. Some more testing, some better results at various window sizes, and it’ll be beta-release time.

Wednesday, 11 December 2013

"Merry Christmas" EASILY outsells "Happy Holiday"

Should you write Merry Christmas or Happy Holidays on cards? That’s a personal choice, but if you are into selling, then ConversionVoodoo claims that their large A/B test results in “Merry Christmas” converting way better:

As you can clearly see, “Merry Christmas” killed it, nearly doubling the click through rate of the other subject lines. 5.47% vs 2.90% is a clear winner with statistical confidence.

Tuesday, 10 December 2013

Multithreading is easy? If only...

There’s a well-argued, thoughtful blog essay on blog.smart bear.com, arguing that multithreaded programming is easy:

Perhaps you’ve accepted the common fallacy that “Multithreading is hard.” It’s not. If a multithreaded program is unreliable it’s most likely due to the same reasons that single-threaded programs fail: The programmer didn’t follow basic, well known development practices. Multithreaded programs seem harder or more complex to write because two or more concurrent threads working incorrectly make a much bigger mess a whole lot faster than a single thread can.

Oh I wish that “multithreading is hard” were a fallacy.

Writing a background thread that performs a long-running calculation? easy. Especially the examples from the multithreading books, which are almost invariably Fibonacci calculations, a somewhat irrelevant example, because Fibonacci numbers can be calculated quickly without the need for multithreading.

Writing a background thread that can be cancelled immediately, that gives useful progress information, that doesn't leave other threads indefinitely blocked if cancelled, and that cleans up after itself if cancelled? hard.

For my single-threaded code I have great static analysis tools, IDE magic, and testing frameworks, all which help me write clean code. For my multi-threaded code, I'm on my own. Let one, just one, mutable variable escape from a thread, and suddenly I have non-deterministic error possibilities, delightfully difficult to reproduce, to find, and to fix. Perhaps I’m coding while tired, and I inadvertently make a mutable list escape from its thread. My programmer’s toolkit is not smart enough to detect this subtle error. Now I’ve got an error that may not occur today. It may not occur within the next month. It may not occur ever. Or just possibly I now have a new source of really subtle errors.

That reminds me of a war story. I joined a software team for version 2 of their project. My main task was making some slow things go much faster. I did that. And then really strange things started happening. I eventually found a mutable data structure shared between threads. When the system was slow, this bug was hidden and never had a chance to occur. By fixing other problems, suddenly this bug, that had been in the system for a year but had never caused a known problem, was causing crashes daily.

My main product, Poker Copilot, is heavily multi-threaded. To minimise the pain of multi-threaded bugs in Java, I follow these guidelines I created just now:

  • Use Java’s own excellent Executor framework. It was introduced in Java 5; before that we had to use horrible low-level multi-threading techniques.
  • Read, re-read, and re-re-read the canonical Java Concurrency in Practice. Readable, thorough, and written by Java deities.
  • Use immutable variables and classes fanatically. Returning a list? Don’t. Instead, return an immutable copy of the list. Creating a new class? Make it an immutable, final class. By default go for immutable options. Google’s Guava Java libraries have a comprehensive set of immutable data structures that make this easy.

Saturday, 7 December 2013

SeeingStars: Table Size Detection

One of the shortcomings in SeeingStars to date has been that you need to manually tell it whether you are sitting on a 6-max table, a 9-max table, or a heads-up table. This is because my initial attempt to make this automatic wasn’t reliable.

Today I tried a new approach for detecting the table size, and it seems to work reliably. My initial tests have passed 100%. Tomorrow I’ll try it with a much larger set of test data. 

Thursday, 5 December 2013

SeeingStars goes Fuzzy

A few days remain until I release SeeingStars: Real Time Odds for PokerStars on Mac OS X

Sign up here to be notified when we release AND get a 50% discount.

I’ve now added a little bit of fuzzy logic to SeeingStars. SeeingStars (partly) works as follows when determining the rank of the cards (eg. Ace, King, Queen…) displayed:

  1. Grab screenshot of poker table window.
  2. Convert screenshot to a two-colour image.
  3. Extract a sub-image where the card rank is displayed.
  4. Convert the sub-image into a string of bits.
  5. Check that string of bits against a dictionary I prepared in the lab.

However that process can be upset by the nature of automatic image manipulation. Occasionally SeeingStars can’t tell what the card rank is. But there is a solution: by adding some fuzziness to the process, I can get pretty close to 100% accuracy for detecting. Using a core Computer Science concept called the Levenshtein distance, SeeingStars can detect close matches. It makes me content to use and relearn concepts I learnt in university years ago. It allows me to answer the question: “does that screenshot sub-image sort-of, kind-of look like a particular rank?"

 

Tuesday, 3 December 2013

SeeingStars: Where is it?

I aimed to release SeeingStars on November 9th. But it wasn’t ready. There is a product. It works, but not as well as I’d like. It has a website, a logo, an app icon. But the product itself needed a bit more work. Then I got distracted, by quick trips to Tunisia and Belgium, by a cold, and by an urgent problem with our flagship product Poker Copilot.

But I’m working on SeeingStars again. It will be here very soon. Within the next few days I hope to have an “Alpha testing” version available.

Stay tuned...