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.