TLDR; How to setup MacOS with Nix. Context Being a long time Linux user, I wanted to know if I can reproduce my development environment on a brand new ARM 64 MacOS machine. Package Manager MacOS doesn’t have a builtin package manager, which is quite confusing when coming from the Linux world. I already tried MacPorts and Homebrew in the past but was not convinced by them. Nix This time, I wanted to try something new, namely Nix, which I already use in other projects to setup my development environment (via nix-shell).

This is a really small post to celebrate that the go-mod-upgrade project has just reached 1000 stars on GitHub 🎉 I started the project 5 years ago when learning Go. At that time, I was writing a lot of Node.js code and I was used to the yarn upgrade-interactive command. When switching to Go, I couldn’t find a similar tool so I decided to write one, mainly to learn Go. In the meantime, people started to contribute to the project and added awesome features like workspace support, the recent Go 1.

TLDR; How to build ARM containers with Podman. Context ARM architecture is a hot topic for me right now. It all started with the Raspberry Pi (obviously), followed by the Apple M1 processor, and lately the AWS Graviton Processors. Despite all the buzz around it, docker images are not really universal: an amd64 image won’t work out of the box on an ARM processor. This article describes how to build ARM containers using Podman instead of Docker.

TLDR; How to bootstrap Flux with Forgejo. Context I’m currently using a Raspberry Pi as a home lab, mainly to learn Kubernetes “the hard way” by installing and configuring as much as possible, instead of relying on managed services like EKS or GKE. See for example my previous post on Longhorn and Tailscale. The next tool I wanted to try is Flux, a GitOps operator for Kubernetes. Reading their Getting started guide, I discovered that they support multiple Git providers, and one that I find particularly interesting for my home lab, which is Gitea.

TLDR; How to expose the Longhorn UI through Tailscale. Context Longhorn is a cloud native distributed block storage system for Kubernetes. To access their web UI, we have to create an Ingress to allow external traffic to reach the Longhorn UI. The documentation uses the Nginx Ingress Controller, but as I’m using Tailscale instead, I wanted to see if it’s possible to expose the Longhorn UI to my tailnet. It turns out it is possible, and here is how to do it.

It’s been a long time but I’m back now ! A lot has changed since my last post (8 years ago), both personally and professionally. Regarding this blog, it’s still powered by Hugo but a few things have changed, notably: I’ve moved from Netflify to Github Pages (more on this below) I’ve switched from Gandi to OVH for the domain name I’ve switched from Vim to Neovim as my main editor, and rewrote my config in Lua I’m using Nix to manage my development environment (still need to use it for Github Actions) Netlify I used to use Netlify Large Media to store my images.

TLDR; This article describes a way to gradually migrate shared Mithril components from version 0.2 to 1.x. Documentation Before we start, I have to say that Mithril has a great migration page which you should definitely check out before reading this article. There is even a tool named mithril-codemods which will automatically convert your code. Context Here is the context: you’ve written multiple applications with Mithril 0.2 and you have extracted some of your components as npm modules so that they can be shared among your projects.

Until a few days ago, I was using Ghost as a blogging platform. While the project is great, maintaining it is not so great: you have to (sometimes) update Node.js, install new dependencies, update the database, … While all these tasks are quite easy, you have to do it every time there is a new release, which is quite cumbersome for a simple blog like this one. Recently, I’ve been looking for an alternative, and quickly found static site generators.

Intro What does it look like to develop a modern desktop application ? Traditionnaly, people think there are only 2 ways to do it : using proven technologies like Java or C#, you build a native application which integrates greatly with your operating system (like Word or Excel) using web technologies like HTML, CSS and JavaScript, you create a web application that runs inside a web browser (like Gmail or Facebook) Well, there is actually a third approach : building native application using web technologies like HTML, CSS and JavaScript.

Part of our job as a developer is to learn new programming languages. But why ? Can’t we just stick with a small number of languages and use our precious time to do something else ? It turns out that learning new languages means learning new paradigms, new ways of doing things, and is in fact quite fun. Once you know the basic concepts, it’s fairly easy to learn a new one.