When I started this blog 13 years ago*, I went with Octopress, a framework built on top of
Jekyll with nice defaults. It had some features built-in that would have required various plugins in Jekyll, and
I remember being quite happy about it.
Unfortunately it didn’t last long, and its maintainer quickly abandoned it: the
last commit is from February 2016. I kept it for a while because it still worked, although I had more and more issues
due to several dependencies not supporting the latest versions of Ruby.
In the meantime, Jekyll continued to evolve while I was stuck forever with Octopress. I wanted to move to Jekyll,
but nowadays I have little time for side-projects, and I’d prefer to work on ‘useful’ things rather than spend a lot of
time migrating the blog from one stack to another, adapting plugins and custom code.
Well, nowadays painful migrations are not a problem anymore: I asked Claude Code to do it, and less than five minutes
later it was done. Something that would have taken me various evenings was done in a few minutes. I do want to
understand the code I generate with Claude Code or Codex, but in the present case the goal was to actually remove as
much code as possible to use Jekyll’s defaults.
Will this be a new start for this blog? Maybe, let’s see.
(*): It was not my first blog; before that I wrote a few posts in French in 2011–2012.
In 2023 I wrote only one article on this blog, but a few more on the tech blog of the
company I currently work for, Bixoto:
This explains why the present blog might look abandoned. It’s not, it’s just that over the years I’ve reduced the time I
spend on side projects and now 95% of my time doing technical stuff on a computer is during work hours.
March 2025 update: more posts:
January 2026 update: even more posts:
When using any library for Google Cloud you can specify a service account with GOOGLE_APPLICATION_CREDENTIALS, but
unfortunately that doesn’t work when using gsutil in shell scripts. The documentation suggests to use
gcloud auth activate-service-account, but that “activates” the service account for all gsutil invocations, and
doesn’t work if you installed a standalone version of gsutil —without gcloud.
I wanted to have one service account per project so that each project has access to the relevant resources only. The
solution I found is to use a Boto file: this is a ini-like file format used for AWS configuration, but gsutil also
supports it. You can tell gsutil to find such file with BOTO_CONFIG or give it a list of paths to look in with
BOTO_PATH.
In a simple project where the main code is a shell script, the setup would look like this:
$ ls -a
.boto
script.sh
service-account.json
In .boto:
[Credentials]
gs_service_key_file=/app/service-account.json
In script.sh:
#!/bin/env bash -e
export BOTO_CONFIG=/app/.boto
gsutil ...
This is a bit cumbersome compared to GOOGLE_APPLICATION_CREDENTIALS but it works well.