Little Go 1.3.0 has just been published on the App Store. This is a technical and bugfix release whose focus is on updating the project to the iOS 9.3 SDK, and on fixing an evil ko detection bug that might have been responsible for many bug reports that I have received due to the infamous "The computer played an illegal move." alert. Many thanks to Denis Martynov for helping me with identifying this bug. I promised to release the bugfix

[...] as soon as possible, probably next weekend.

This was in June 2015 - over a year ago :-(

To find out about the changes that are in the release, either read the App Store update notes or hop over to the GitHub release page to see the changelog.

A mobile app that integrates the Fabric mobile platform and the Crashlytics crash reporting framework requires two things to successfully communicate with the Fabric / Crashlytics server platform:

• The Fabric API key: This is required at build time so that the build process can upload the debug symbols that later are required to symbolicate crash reports. The API key is also required at runtime so that the app on a customer device can submit crash reports.
• The Fabric build secret: This is also required for uploading debug symbols at build time.

Whoever knows these two pieces of information can freely interact with the Fabric / Crashlytics server platform on behalf of the app, so obviously you want to restrict knowledge of the information to people who can be trusted. This article shows how to keep API key and build secret private even in an Open Source project like Little Go where, by definition, there is the desire to publish everything.

Here's a line of code that I recently sighted when I had to dig through ancient Excel VBA cruft at work:

Falsch = True

For German speakers: The code works because it uses a non-keyword (Falsch) as the variable name. For non-German speakers: "falsch" is German for "false", so the original code can be translated to:

False = True

After a moment of disbelief, I couldn't help but admire the amount of badness that is compressed into this single line of code - there is even a philosophical statement here! It's so fabulous that I consider it to be a real piece of computer programming art!

This is the story about my second exploration journey in Elite Dangerous. Read more after the break.

As recounted in the description of my first exploration journey, I had travelled in a decently equipped Asp Explorer. For the next journey, though, I wanted to improve some of the modules, most importantly I wanted a class A frame shift drive so that I would be able to make longer hyperspace jumps. To earn the necessary credits, I decided to check out how Power Play works. I decided to join Aisling Duval, partly because of her looks (being in the mid-forties does not prevent me from being juvenile sometimes :-)) but mainly because the actions required from her followers seemed to be the least warlike.

As mentioned in the conclusion of the previous post, space exploration in Elite: Dangerous has fired my imagination and my space romantic spirit. Abandoning all restraints, I have decided to celebrate my career as a galactic explorer as fully as possible - for my own enjoyment if not for anyone else's - by creating documentaries of each of my trips. Let's see where this leads.

I would like to begin the series with a brief report of my first journey, where I dip my toes into the space-cold waters of the galactic unknown. The goals: Leave the bubble of inhabited space, sniff the galactic wind, maybe find an unclaimed star and try to make it back alive to report the sights. Also, earn a few credits :-)

A few months ago, Elite: Dangerous (or ED for short) came out for the Mac. I immediately bought the game, for old time's sake (I have been playing both the original Elite on the C64 and Frontier on the PC) and because it promised to be a playable game - as opposed to the perpetual alpha status that Star Citizen has been in now for years! After the break, I try to give a few of my first impressions from the time when I started to play the game, together with a summary of what ED means to me now after having played the game for a bit over 3 months.

Yesterday Little Go 1.2.0 has been published on the App Store. This is a major new feature release that took fully 9 months to complete - in the end the release was dragging out for much longer than intended due to stability issues with the new iPhone 6+ user interface design. Hopefully I nailed all those pesky bugs.

This time I won't bore anyone with a repetition of the changes that are in the release. You can either read the App Store update notes or hop over to the GitHub release page to see the changelog.

OpenLDAP 2.3 (released in 2005) introduced a new way for configuring the slapd daemon. The traditional method was a configuration file (/etc/ldap/slapd.conf on Debian) that could simply be edited with a text editor. The new way follows the Eat your own dog food maxim: The configuration is stored in a set of LDIF files (stored under /etc/ldap/slapd.d in Debian) which cannot be edited directly with a text editor. Instead, all changes must be done via LDAP operations. Funny enough: In order to configure the daemon, the daemon must already be running.

slapd-config, as the new configuration method is called, may be a technically cool feature, but from a casual sysadmin's point of view it is nothing but a major pain in the butt! So you want to quickly change slapd's log level to diagnose some authentication problem? OK, first check the documentation to see where the log level option is located in the configuration schema, and how its attribute is called. Then query the running daemon to look at the current value(s). Then write an .ldif file that contains the change. Then issue a complicated ldapmodify command that requires more cryptic options than tar and cpio combined. Of course the .ldif file contains an error, so diagnose & repeat. After maybe 20 minutes the job is done. Phew, only 20 minutes to change the daemon log level, I am such an LDAP wizard!

Actually when I did this just now it took me more like an hour because I am so not used to the procedure (another explanation might be that I'm just stupid, but hey, I think that's not it). Since I don't want to repeat the experience, I have started to write up some recipes on my wiki. Here's the link in case you are interested.

Another 19 months have passed since my last report from the spam front. This time the news is not so good.

Although the overall spam rate has dropped again, for the third time in a row, and is now at 11 messages per day (down from 14 messages per day), the other side of the medal is that SpamAssassin's recognition rate has also dropped for the third time in a row. This time the drop has been so marked that it has overcome the benefits of the spam rate drop, causing the average number of spam mails that have made it into my inbox to increase to 1.6 messages/day (up from 1.4 the last time).

This is the first increase of that all-important figure since I switched to greylisting almost 5 years ago! This turnaround is slightly scary because it means that for the first time ever spammers have actually become better in getting their junk into my inbox. I refuse to be overly alarmed at this point, and I hope that this trend will not continue, but if it does I will have to consider new measures, such as starting to use blacklists.

For more statistics details, see this wiki page.