Blog

Nara used to be the old capital of Japan, and nowadays it’s mostly known for its shrines (which are also part of the UNESCO World Heritage, like the ones in Nikko and Kyoto) and its hundreds of tame deer which roam the area freely. It’s a 50 minute train ride from Kyoto, so it’s easy to just hop on a train to get there.

Kyoto is probably the second most popular destination in Japan after Tokyo, and it’s seen as one of the most important historic centers of Japan.

It’s easy to get there by using the Ihari Shinkansen line, a ride that takes a few hours. Unfortunately, the trip to the freezing shrines of Nikko caught me off guard and got me a cold. I had to wear a mouth mask to keep my illness contained, as is usual in the country.

It also didn’t help that it was pouring outside, and our room in the ryokan wasn’t ready yet, so we had to find another place to kill a few hours.

Andy Bell created this small tool to find out the basic configuration of your browser and device, called mybrowser.fyi.

It’s simple, yet extremely handy as you can send this site to a client, and they can send back the results in an instant. It’s a lot easier than the old fashioned way by explaining to the client over the phone where they can find the about menu of their browser.

A few days into our trip to Japan we went on a quick outing from Tokyo to Nikko, a small village north of the huge busy metropolis. Nikko is mostly known for its numerous shrines, which are part of the UNESCO World Heritages.

Japan is a fascinating country: for centuries it was nearly fully isolated from other countries, creating a culture that’s vastly different from the rest of the world.

We wanted to travel to the country for ages, and last year (after careful budgeting and planning) we finally took an 11 hour plane ride to the other side of the world and discovered their beautiful nature, great food and amazing culture for ourselves. Our first stop: Tokyo.

I’ve been working on setting up my blog in a way that makes it possible for me to edit and update this website from anywhere. Jekyll makes it easy to create a website that’s fully portable by not working with a database, which makes it easy to just push and pull your data from Git, but until a few days ago I just compiled this website on my laptop. This works nice enough, but I have to rely on a traditional computer to do the updates.

To counter this, I’ve decided to move the build process to a VPS, so I can just build the website with a simple command over SSH, on any device that can remotely log in to this server.

Jekyll is nowadays a pretty well documented framework, and installing it to my Ubuntu 16.04 server was as easy as following the steps from the Jekyll website.

Unfortunately, running the jekyll build or jekyll serve command resulted in a mysterious error:

Error: \xE6 Code: US-ASCII

I noticed that this is the unicode character for the æ ligature, and I started looking for this character in my files to replace it with an HTML entity. I didn’t find the character in any of my files (not even in the exported site on my laptop), so this didn’t help.

I then tried to create a new jekyll site with the make command, and this website worked perfectly right away. Strange.

I then tried to add the posts from my website to the newly created site, and those also generated on the first try.

I found that the only difference between my site and the new site were that I used a few plugins to help me do some basic tasks (like creating a sitemap, for example). This resulted in discovering that the jekyl-autoprefixer plugin was the cause of the error.

This is an important plugin for me as I’m using flex and (more importantly) grid in my css, technologies that are not yet fully baked in all browsers, so they often need browser specific fallbacks which are automatically generated by autoprefixer.

I then found a blog post by Holly Becker, in which she solved a similar issue. She described that this problem was fixed by setting the Lang and Language variables to en_US.UTF-8 so Ruby (the environment that Jekyll uses) doesn’t fall back to an incompatible language. This didn’t solve it for me, but the error was similar enough to my issue that I felt that I was looking in the right direction at least.

While searching around I stumbled on a question on StackOverflow that mentioned the same solution, but with a few variables added. And voila: adding LC_ALL to en_US.UTF-8 solved the issue (with export LC_ALL=en_US.UTF-8).

I suspect that it’s also perfectly possible to change en_US.UTF-8 to your preferred language, given that it’s unicode compliant. The default charset of the locale is (if I understand it correctly) set to ASCII, which does not have the æ character available. This issue is probably not only related to that character, but the unicode charset is large enough to account for most non-ASCII characters.

A drawing of our cat, sleeping on the sofa.

I’m trying out Clip Studio Paint on my iPad Pro as a drawing app, and it’s quite nice. The lines feel a bit more refined that those drawn by Procreate, but it’s not a big difference. I’ll see if I’ll keep using it before my trial period ends.

A few months ago we spend around three weeks in Japan to discover their nature, culture and food. With our phones in hand we documented this trip, in which we traveled to Tokyo, Nikko, Kyoto, Nara, Osaka, Kobe, Hiroshima, Miyajima, Okayama and then back to Tokyo.

We filmed this footage with an iPhone 8, a Samsung Galaxy S5 and a Sony RX100 Mark III. Editing was done in Premiere Pro on a Macbook Pro 13” (2017), but the .hevc files out of the iPhone were nearly impossibly slow to work with, so they were first converted to a bunch of low resolution proxy files to make them usable in Premiere. Apparently Final Cut Pro X is a lot better for these (4k60) files, but oh well.