Containerizing your dev environment

Pål Nødseth — Tue, 27 Oct 2020 00:00:00 +0000

A couple of weeks ago I listened to another great episode of the BartJS podcast where containerization was discussed, spesifically containerization of your development environment. When visiting their homepage now I couldn't find the episode in their overview, but here's a direct link: Remote - Containers i VSCode - Droplet 6. I definately got curious about it, and so the last couple of days I've been trying it out for myself.

Containerizing your dev environment means you would create an isolated environment for your source code to run in. If you are a team working on the same repo, this would mean you'd all work in the exact same environment. No more "but it works on my machine". Another benefit is that you don’t have to “pollute” your own file system with all kinds of tools and extensions. They are only installed in this isolated environment.

I borred this description which explains it in an easy to understand way:

Develop with a consistent, easily reproducible toolchain on the same operating system you deploy to.

Quickly swap between different, isolated development environments and safely make updates without worrying about impacting your local machine.

Make it easy for new team members / contributors to get up and running in a consistent development environment.

Try out new technologies or clone a copy of a code base without impacting your local setup.

Getting up and running in VS Code

So I gave it a go, and I’m impressed at how easy it is to get up and running in VS Code. You install the Remote - Containers extension. Then you create a devcontainer/devcontainer.json file in your repo. This is the file VS Code looks for, which has the settings for which extensions to install etc. Also, you need a Dockerfile containing the “recipe” for the Container creation (which files to copy, what commands to run etc). If you are familiar with Docker you've definately written a Dockerfile before. If not, Docker has a great tutorial here

Once you've done this you're basically all set and it's just a couple of clicks to get the container up and running.

Will I start containerizing my dev projects?

The short answer - no. I haven't felt too much on any of the pain points this workflow solves - yet. But this might change. I can definately see why this would appeal to some projects and teams. The idea of having a "cleaner" file system is also somewhat appealing. Let's say I would want to try Rust. I download a repo, spin up a container and install Rust in that container - keeping my local filesystem untouched. Mmm!

Eleventy - initial impressions, and Turbolinks

Pål Nødseth — Mon, 18 May 2020 00:00:00 +0000

I’m really glad I settled on using Eleventy for my blog. After the initial “finding my way around”, I feel like I’ve got the hang of how Eleventy works.PS: If you don’t know what eleventy is, I write about it in my first blog post

What I like about Eleventy so far:

The ability to mix different input formats for my web pages. So far I’m using Nunjucks templates for web pages that need some logic handling, and markdown files for my blog.
They way you create pages and content from data. I love that I can simply write a function that returns whatever data I need, which is then fetched on build-time and ready for use in my templates. Check out this example of how to create pages from data. So far I’m getting data for my bookshelf page and my top Spotify artists page. Feels good not having to fetch that data in the client.

Turbolinks

I've also added Turbolinks to my site. Turbolinks works this way: Whenever you click a link on my site, instead of doing a full page reload Turbolinks hijacks the click event. It then fetches the page and basically swaps out everything inside the body tag. Getting Turbolinks up and running couldn't be easier. You just drop the script tag in your and it works. 🥳 It's a nice and easy way to get the instant page load you get with a SPA.