Little Go statistics update

I took the opportunity of the 1.6.0 release to have another look at Little Go’s App Store statistics. The last time I published these statistics was in September 2013, for version 0.12.0. In the 7½ years since then I have done nothing to promote the app, except listing it on Sensei’s Library. I’m therefore quite pleased to see that the app’s reach has increased substantially. Updates The total number of updates in the 11 days since the 1.

Little Go 1.6.0 released

Little Go 1.6.0 has been published on February 27 2021 on the App Store. This is the first release in almost 2 years, and it’s packed with improvements. You can read the release notes in the App Store update notes or on the GitHub release page. 1.6.0 is a landmark in the version history of Little Go because the app now incorporates its own SGF parser instead of relying on Fuego to read and write SGF data.

Goodbye Drupal, welcome Hugo!

15 years ago I migrated this website to the popular CMS Drupal. At first I loved Drupal, it was a nice and shiny tool for managing my content without having to deal with designing the appearance of the site. Over the years, however, I realized that running a dynamic website also has a cost, and that cost is keeping the software that drives the site up-to-date. With Drupal that cost is substantial: Security updates are constantly pouring in, and upgrading Drupal to a major new version invariably also means a major amount of work to be done.

Little Go 1.5.1 released

Always two there are, no more no less. A master release and a bugfix release.

Alas, it seems to have become almost a rule that, shortly after I publish a master release of Little Go on the App Store, some issue is found and I have to follow up with a bugfix release. So here I present to you version 1.5.1 of Little Go which was published on the App Store last Sunday night and which contains the fix for a bug that affected users on older devices with iOS 9.x and below.

The annoying thing is that this time the problem was a piece of code that I had added in 1.5.0 to make UI testing work. In other words, my effort to increase the software quality had exactly the reverse effect. At least the bug was easy to find and fix, just a property (accessibilityFrameInContainerSpace) that was introduced in iOS 10 and which I had forgotten to protect with an appropriate @available guard.

Here's the usual link to the GitHub release page.

Little Go 1.5.0 released

Little Go 1.5.0 has been published earlier today on the App Store. Version 1.5.0 is the first feature release since 1.2.0, almost 4 years ago.

The new version contains only a single feature: A new board setup mode in which you can place black or white stones in any order and combination to set up the initial board before you begin to play moves. This feature is a continuation of the work begun in version 1.4.0, where I added support for loading and saving .sgf files that contain stone and/or player setup nodes.

Also important in this version: I started to write automated UI tests. The main work was finding out how the UI testing API works and laying the groundwork for future tests (e.g. how to test the three different layouts, how to interact with the board to place a stone, etc.). Originally I had intended to automate all tests described in the manual testing script (file TESTING), but then I realized how much work this meant and I became completely paralyzed. Several weeks of stasis finally convinced me that the task of fully automating all UI tests would have to be broken down and completed with "baby steps" if the project ever was to see another release. So that's why in this version of Little Go there is less-than-might-be-expected UI testing.

That's all, folks. If you want you can finish by reading the App Store update notes or the GitHub release page.

Little Go 1.4.0 and 1.4.1 released

Little Go 1.4.0 has been published on January 15 2019 on the App Store, followed-up two days later by the 1.4.1 update that contained a high-prio bugfix. Version 1.4.0 is a maintenance and bugfix release that mainly focuses on updating the project to the newest development environment, Xcode 10.1 and iOS 12.1 SDK.

Although the bugfixes are quite substantial, the amount of time and work that went into them was dwarfed by what I had to invest into just getting the project to run again under Xcode 10.1! This is why I am dreading each new Xcode release: Apple's relentless push for technical renewal is sometimes disheartening for me because I do not code for the platform for profit, and my willingness to spend large amounts of free time on this project has certainly diminished over the years. Ah well...

There are a few things related to the Xcode upgrade that I want to highlight, and a short outlook on a future version 1.5.0. Read on after the break. Or check out the App Store update notes and the GitHub release page.

Manual teaser breaks vs. "Filtered HTML" text format

Placing the following line inside a Drupal story node's body (I guess it also works for other content types) adds a manual teaser break:


This works fine when the story uses the "Full HTML" text format. It stops working, however, when the story's text format is switched to "Filtered HTML" - in that case Drupal simply ignores the manual teaser break and auto-breaks wherever it sees fit.

For Drupal 7, a bug report was submitted 8 long years ago, and the issue is still open today. I can only imagine that they didn't fix it because a workaround exists: A site admin can add <!--> to the "Filtered HTML" text format's set of allowed HTML tags.

In Drupal 8 this workaround is no longer available because in Drupal 8 the "Filtered HTML" text format unconditionally filters out all HTML comments. A few days ago I submitted another bug report on for Drupal 8, and today I decided that I'm really not in the mood for going through all my old stories and switch those with manual teaser breaks to "Full HTML". Instead I wrote a patch that fixes the issue and that is now live on this site. If you're interested you can find the patch in the bug report referenced above.

Migrating from iPhoto to digikam

This is a longish story about how I migrated my photo library from Apple's discontinued iPhoto application to the open source program digikam (version 5.9.0 beta from March 2018). If you follow a similar migration path and make the same decisions as I did on what data to keep and what data to discard, then I hope you will find a reusable solution in this story. These are the pieces:

  • An AppleScript for the initial iPhoto export
  • A shell script for post-processing and preparing the exported data for the digikam import
  • The instructions how to configure digikam to make the import work
  • Optional cleanup work and sync'ing back of metadata to image files

A warning before you dig in: Although I have tried to explain everything in as much detail as I could, you should be prepared for surprises and an arduous migration - it certainly was for me.

Two bugs found in Drupal 8 Core

In the previous Drupal 8 site upgrade story, I mentioned that the link field type does not correctly render URLs with certain query strings. Example: is rendered incorrectly as

When I didn't receive any satisfactory answers to my plea for help on the StackExchange site "Drupal Answers", I decided to go bug hunting myself. The result: I found two bugs deep inside Drupal 8 Core! For the first bug I have submitted a new Drupal Core issue (issue 3007243). For the second bug I have contributed my analysis to the discussions of two existing Drupal Core issues (issue 2987114 and issue 1464244).

If you're interested you can hit the "Read more" button to find my detailed analysis. It's the same text that I wrote as answer on "Drupal Answers", but I'm reproducing it here to give my site a little bit more content 😀