Lars is big on Elixir. Think apps that scale really well, tend to be monolithic, and have one of the most mature deployment models: self-contained releases & built-in hot code reloading. In episode 7, Gerhard talked to Lars about “Why Kubernetes”. There is a follow-up YouTube stream that showed how to automate deploys for an Elixir app using K3s & ArgoCD.

More than a year later, how does Lars think about running applications in production? What does simple & straightforward mean to him? Gerhard’s favourite: what is “human scale deployments”?

Lars Wikman on what it takes to learn software development and how he responds when people ask him how they should go about it:

At the time I was learning, I didn’t have access to any kind of bigger picture. I had limited resources. Limited documentation. I had so many limitations. I ran into them constantly and eventually found the next thing I could use to do cool stuff. If you try to teach someone to use an HTML form today, you will need to decide if you are talking about the basic idea or reality. Do we need to cover CSRF, captchas and how to do it in React? How about the backend? Starting out, I didn’t hear about half of the things I didn’t know; I think that made things easier.

When it comes to the software industry, this is the best of times. There are amazing learning resources available, a vast repository of free code that you don’t have to write, and lucrative job offers on the other end of the chasm.

When it comes to the software industry, this is the worst of times. There are too many learning resources to choose from, a crippling repository of free code that might stumble you, and overwhelming imposter syndrome on the other end of the chasm.

Lars sums it up nicely:

Hand someone a fish and they’ll never know that the ocean is vast. Teach them how to fish and they’ll be forever lost at sea.

This week we turn the mics on ourselves, kind of. Lars Wikman joins the show to give us a guided tour through ID3 esoterica and the shiny new open source Elixir library he developed for us. We talk about what ID3 is, its many versions, what it aims to be and what it could have been, how our library project got started, all the unique features and failed dreams of the ID3v2 spec, how ID3v2 and Podcasting 2.0 are solving the problem differently, and how all of this maps back to us giving you (our listeners) a better experience while listening to our shows.

I helped build chapter support for Changelog podcasts. Let’s parse some ID3 tags!

In today’s Kaizen episode, we talk about shipping Adam’s Christmas present: chapter support for all Changelog episodes that we now publish. This feature was hard because there are many subtle differences in how the ID3 spec is implemented. Of course, once the PR shipped, there were other issues to solve, including an upgrade the world kind of scenario. Since Lars Wikman did all the heavy ID3 lifting, he joins us in this episode.

Lars Wikman on the history of ID3 tags:

If you were a Winamp user back in the day, or curate an MP3 collection currently, you might recognize the humble ID3 tag. It is what the metadata in the MP3 file is made up of. First it was pretty limited in the version later dubbed ID3v1. Like any good 2.0 they added a ton more fields, features, removed character limits and it was suddenly ID3v2. The latest spec is ID3v2.4 while the most commonly adopted one seems to be ID3v2.3. I recently found myself having a reason to dig into this specification.

I wonder what reason he might have to dig into this spec? Could it be for a soon-to-be-announced collab with his friends at Changelog? 😏

This post is not about the technical intricacies of the format… This is about a simpler time, where people saw the wild possibilities of music on computers and when people cared about files, damnit. This is about some of the most interesting and entertaining things I’ve run across while reading the spec.

Lars Wikman reacts to Gerhard’s excellent conversation with Kelsey Hightower on Ship It!

So he essentially said, I’m interpreting here, that when it comes to deploying software to servers the documented manual steps for deploying something need to be the canonical reference. Then whether you build bash scripts, Ansible playbooks, Makefiles, Dockerfiles, Terraform, Kubernetes or something else to encode that procedure into something repeatable and scalable that’s a separate step. Having documented the process required to set it up means that there is an answer to the question: How do I get this running? An answer that doesn’t require you to parse the .yml files or grok Ansible roles and groups.

Lars springs forward from there with many thoughts of his own on the matter.

Bryan Cantrill, announcing Hubris and Humility:

… we found ourselves increasingly forcing existing systems out of the comfort of their design centers, we wondered: was our assumption of using an existing system wrong? Should we in fact be exploring our own de novo operating system? In particular, our colleague Cliff Biffle, who had a ton of experience with both Rust and embedded systems, had a vision for what such a system might look like (namely, the system that he had always wanted for himself!). Cliff dove into a sketch of his ideas, giving the nascent system a name that felt perfectly apt: Hubris.

There’s some serious innovation going on at Oxide and I can’t wait to see what they do next.

I don’t think I’ve ever had more distrust and as a consequence distate for software than in recent years. I don’t think its just me as a tech-nerd with artisanal tech-carpentry aspirations. I want people to build well, treat their users right and generally exercise some actual restraint. I see it very clearly and I react more viscerally than anyone non-technical in my surroundings. However, I see the frustrations and the consequences everywhere…

This week on Ship It! Gerhard talks with Lars Wikman (independent Elixir/BEAM software consultant) why sometimes a monolith running on a single host with continuous backups and a built-in self-restore capability is everything that a small team of developers needs. That’s right, no Kubernetes or microservices. After 2 years of running changelog.com, a Phoenix monolith, on Kubernetes, what do I think? Join our discuss and find out!

Lars wrote a Changelog Post introducing the PETAL stack last week. Now he’s back with something a little more actionable, for those intrigued by the proposition.

There’s a new stack in town. PETAL. It destructures to Phoenix, Elixir, Tailwind, Alpine and LiveView. So what is it? Well, it helps you build web applications. Let me tell you about it…

In a recent episode of JS Party we were told that you can program in CSS. But you can do some less complicated things with bigger payoffs. You can use CSS to track users that have JS disabled. Not sure how to feel about that. This post covers the rough idea of it and wants your thoughts on the practice.

The Nerves Keyboard project is a small group of enthusiasts using the IoT tooling from the Nerves project to build a mechanical keyboard that can be programmed and customized with Elixir. The work happens in the open and is currently moving towards the hardware stage. This is a quick getting-started tutorial.

Lars Wikman:

With Microsoft’s strong push into open source it is easy to assume that they are fully open source and that their flagship code editor and its cool LiveShare and Remote extensions are there to play nice with the wider world of free software and open source. This is not entirely the case as this post outlines.

Lars Wikman:

A bit of writing on what potential we leave on the table when we use tools that trade technical merit for other factors. And why Elixir just might have higher potential for web services than many other popular languages and runtimes.

Lars Wikman:

I’ve been thinking a lot about inexperienced (junior, if you must) web developers and just how much there is to learn about programming in general but the web in particular. You often hear people say that you don’t need to know everything but you should have a solid foundation. Well, how do you establish a solid foundation and how do you know if you have one? How do you get introduced to all the relevant terminology and how do you find out what you haven’t learned yet?

To help with this, Lars created a self-evaluation checklist tool.

Lars Wikman:

The Lumen Project is an alternative implementation of the Erlang VM, more known as the BEAM. It is designed to work in WebAssembly with the specific goal of bringing Elixir and Erlang to the browser with minimal overhead, tightly compiled rather than porting a full VM. Can it replace JS for some developers?

An excellent article, highly recommended. Lars hangs out in our community chat and suggested we do an episode with the Lumen team. Talks are underway, so stay tuned for that.