A few years ago I wrote a version of the tile game Qwirkle including some rudimentary AI – github.com/bakert/qwirkle. It’s surprising how many good scoring positions you miss in the normal run of play and how little it seems to matter if you give away a Qwirkle to your opponent. The code is open source/MIT licensed.
I played a few games of Dobble with my niece and got curious about the algorithm used to generate the cards. It turns out it’s not trivial and one of the best ways to interrogate it is as a finite projective plane.
The maximum number of possible cards is n^2 + n + 1 where n is the number of symbols per card minus one.
Number of Symbols on Card
Max Number of Cards
2
3
4
13
5
21
8
57
12
133
The number of symbols on the card doesn’t have to be a prime number plus one but the algorithms found online require that.
I thought it was pretty interesting that 8 symbols per card allows 57 cards but the game itself comes with 55 cards. Presumably because once you put one card in the center 54 is divisible by both 2 and 3 for even number of cards per player in the common cases. I wonder which two cards are missing but not enough to look through them all!
The excellent pystache library is now unusable due to changes in setuptools. For this reason with somewhat heavy heart we have forked pystache and dropped support for python 2. We will attempt to get it instated as the official (pypi) version. If you’re starting with a new project you might prefer to use chevron but if you need a version of pystache you can find our fork at https://github.com/PennyDreadfulMTG/pystache.
In 2003 I spent half a day figuring out a bad Microsoft error. I hadn’t been able to Google the answer. And I guess this was before the days of Stack Overflow. So I wrote it up as a blog post – https://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction/
Because I’d been extremely frustrated by the error I included at the bottom, “If you’re having a similar problem but can’t work what I’m saying here, feel free to mail me on bakert+web@gmail.com – I wouldn’t wish my four hours on anyone!”
I never get email about any of my other blog posts. But Gmail tells me I’ve had at least 269 about this one. Including within the last two weeks! If you find this phenomenon interesting and wish to discuss it further, feel free to email me at bakert@gmail.com 😉
Sometimes you use a third party library and the interface is so well designed it’s just effortless. Something that would have been gnarly and murky becomes simple. The kind of library that gets ported to multiple languages because everyone wants access to it.
One slightly obscure example is feedparser, (originally) Mark Pilgrim’s python2 library for reading Atom and RSS feeds. Hiding all this nonsense:
behind a simple interface.
import feedparser d = feedparser.parse('http://www.reddit.com/r/python/.rss') print(d['feed']['title'])
>>> Pythonprint d.feed.subtitle >>> news about the dynamic, interpreted, interactive, object-oriented, extensible programming language Python print d.headers >>> {'content-length': '5393', 'content-encoding': 'gzip', 'vary': 'accept-encoding', 'server': "'; DROP TABLE servertypes; --", 'connection': 'close', 'date': 'Mon, 14 Oct 2013 09:13:34 GMT', 'content-type': 'text/xml; charset=UTF-8'}
Another library that has the same simplicity is Mustache logic-less templates. This one has been ported to literally dozens of languages. Every template I ever worked on was kind of a mess until I found Mustache. It’s actually the restrictions here that make it sing.
Hello {{name}} You have just won {{value}} dollars! {{#in_ca}} Well, {{taxed_value}} dollars, after taxes. {{/in_ca}}
Some other examples:
web.py – Dead simple web framework
BeautifulSoup – HTML/XML parser
requests – Python library for HTTP
humps – Underscore-to-camelCase converter (and vice versa) for strings and object keys in JavaScript (has been ported to Python as pyhumps).
Markdown – Text format with HTML representation that has taken over the web due to its simplicity and usefulness compared to actual HTML
In a recent code review my colleague took issue with the following code.
func Enqueue(properties Properties) (err error) {
logger := logging.GetLogger(ctx)
bs, err := json.Marshal(properties)
if err != nil {
logger = logger.With().Err(err).Logger()
} else {
logger = logger.With().RawJSON("properties", bs).Logger()
}
… go on to log some stuff and enqueue the supplied event with the supplied properties …
}
Specifically the question was around whether `bs` was a reasonable name for the variable holding the JSON version of the properties. My counterargument was that short names are better than long names when well understood and/or short in scope. And that Go has a C influence and favors short variable names which you can see in both the standard library and its examples. The Go encoding/json library calls []byte variously src and data (code), b, j and text (examples) – https://golang.org/pkg/encoding/json/
My colleague said it took them longer 0s to understand the var so they called it out as a nit (not a blocker) and that they care more about knowing what is contained within than if it is `[]byte` or not.
I ended up renaming it `propertiesJSON`. It did start a discussion about short variable names in general and in Go in particular. I’m still not sure how I feel about it. I did find some reading that seemed relevant though.
Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer c to lineCount. Prefer i to sliceIndex.