In this post I show how you can setup a Kubernetes pod for reproducible development purposes on a single-node Kubernetes cluster using Rancher Desktop on Linux or Docker Desktop for Windows.

What are devcontainers?

At my quasi-hypothetical workplace, we are fans of Visual Studio Code’s development containers idea, or devcontainers for short.

In short, you add a specially crafted devcontainer.json file (and some docker yamls) to your repo, and the next time a new dev opens the project, they will be prompted by their VSCode whether they would like to have the whole development environment setup automatically.

Imagine the following possibly hypothetical situation:

You work in an organization or team that is heavily Python-focused, primarily due to operating in application domains where scientific computing is important.

The Scientific Python ecosystem, of which machine learning is just one admittedly major theme, is brilliant for this.

However, you would like to evaluate development stacks outside of the Python world for the implementation of small and higher-performance services, which don’t need SciPy, to augment your architecture.

The wonderful Emacs Org mode is the basis for the largest part of my personal knowledge management system.

However, as I’ve mentioned before, mobile accessibility is its weakest point.

In this post, I’m going to explain my possibly unconventional new solution to the important requirement I mentioned in that note-taking post:

Ideally, I would have easy access to my complete org database and any related files.

As you can easily deduce from the title of this post, the solution involves converting all of my org database into docx files, with the main motivation that the Dropbox mobile app has excellent support both for the fast previewing and searching through the contents of docx files, while it has none of that sort of support for .org or .md files.

This post is reproduced here with permission from The OrgMode ExoCortex.

org-roam v2, which was recently released, removed the update database on idle functionality (which I coincidentally contributed) as part of its simplification.

I agree with this removal, as I think it makes the most sense to keep the org-roam core as simple as possible.

That being said, being able to have the org-roam database update only when Emacs is idle can be helpful for some folks, like me, who C-x C-s quite often and notice a few hundred millisecond blocking delay on files of a thousand or more lines.

Welcome to open source vxlabs software development handbook.

It contains a number of best practices for building software, generally web-based, using Python on the backend and TypeScript for the frontend.

However, most of the guidelines are more broadly applicable.

Important note: These are only guidelines. They were never meant to be applied dogmatically. They are great when you are starting fresh, and their intentions are good, but please do understand and adapt to your situation.

Recently the great support folks at FastMail helped me to debug a rather irritating issue where emails that had languished in my inbox for too long, and were then processed by me to end up in the Archive folder, would get the date of archival assigned as the main email date, instead of the date of arrival.

For example, an email with a date in November of 2020 would get a new date of say February 21, 2021, if that’s the date that I finally got around to it and moved it to the Archive folder.

On the various and different platforms where I use Emacs and GnuPG encryption, I’ve traditionally always had a bit of a struggle setting up a suitable mechanism for private key passphrase entry, or pinentry.

Recently, I landed upon this extremely easy-to-setup and reliable solution where Emacs and GnuPG can be configured so that Emacs requests the passphrase via its standard minibuffer password entry mechanism, and then passes this through to GnuPG.