Nix already provides a neat way to create a development environment with strong guarantees in terms of reproducibility. However, it still requires developers to install it on their computer which, even though Nix doesn’t install anything in directories such as /usr, can be met with some resistance. On the other hand, VS Code’s devcontainers allow a developer to start working on a project without too much hassle granted they use VS Code and have Docker running.

Nix Flakes are a new feature of Nix 2.4 (still prerelease as of this writing) to make Nix derivations composable and can be used to distribute derivations to other people. This is not a post about what Nix Flakes are though and I recommend reading the series from Tweag (first here) to get up to speed if you haven’t already. Support for flakes is of course not very widespread.

My project Chunked has essentially three components: The API is an executable written in Haskell containerised and deployed on Cloud Run so I don’t have to worry about infrastructure. It’s also using Cloud SQL with PostgreSQL. Projections are also written in Haskell but deployed on GKE Autopilot since they have to run continuously. If you don’t know anything about CQRS / Event Sourcing, it doesn’t matter for the rest.

I’ve started working on a new pet project recently called Chunked. It is an app which hopefully will help me (and others) streamline my study by integrating flashcards with exercises and specimen exam papers in one place. All the code base is built with Bazel and the server-side components are written in Haskell. With Cabal, you can use the option --pedantic to transform all warnings into errors to easily make sure you got rid of all of them.

About a year ago, I started to use conventional commits for my personal projects and at work and haven’t regretted it so far. It led me to more clearly communicate what changes are about. My commit history is a lot more manageable as a result. Conventional commits are a specification for formatting commit messages that’s lightweight and readable by both humans and machines. Even without using tools that can parse them, it’s still useful for developers alone.

Any software project has to make a trade-off between building new features and making the current system more resilient and easier to maintain. Too often, management pushes for new features and, before you know it, you end up with a big ball of mud where any change takes ages due to the accidental complexity that gathered over time. Complexity leads to bugs and soon enough, changes become risky. Developers get terrified at the idea of shipping anything but trivial things.

Many companies rely on tools such as LastPass or 1Password to manage and share passwords. These tools are very useful if you care about security, as of course you should but they also come with their own set of problems. I have always been a bit frustrated using these and had been on the lookout for a better alternative. I wanted a tool that didn’t rely on a third-party and that could be used inside a terminal.