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”?

José Valim announces Bumblebee and walks you through how to run ML modules in Livebook with just three clicks. Finally, he shows you how to embed a model into a Phoenix app. So cool!

Andrea Leopardi likens database migrations to git commits and wonders why we don’t leave them in the past and load an up-to-date SQL file instead. He also shares his approach to this in Elixir.

I had the honor of joining the fine folks at Elixir SF awhile back to talk all about how we’ve been podcasting on Elixir for a long time now. Tune in if you’re curious about such things and/or if you’d like to take a stroll down memory lane as I show old versions of our album art and play our intro music along the way.

The preso is average, but the Q&A near the end is above average, if you ask me. OH! And also we got Zoom bombed twice, which was a first for me. Thankfully, it was also a last. So far, at least…

Few genuinely need a multi-cloud setup. There is plenty of advice out there which mostly boils down to don’t do it, you will be worse off. Vex.dev is a startup that provides APIs for video and audio streaming. The hard part is real-time combined with massive scale - think hundreds of thousands of concurrent connections. They achieve this by using a combination of Fly.io, AWS and GCP. Jason Carter, founder of Vex Communications, is joining us today to talk about the multi-cloud setup that vex.dev runs.

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!

Our shows have chapters baked in now, whoop whoop! This post details some of the challenges we had to overcome to get that done, including a brand new open source Elixir library for reading & writing ID3v2 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.

Why are the right values important for a company that changed the way the world builds software? How does pair programming help scale & maintain the company culture? What is it like to grow a company to 3000 employees over 30 years?

Today we have the privilege of Rob Mee, former CEO of Pivotal, the real home of Cloud Foundry and Concourse CI. Rob is now the CEO of Geometer.io, an incubator where Elixir is behind many great ideas executed well, including the US COVID response programme.

Michael Guarino lays out how the engineering team at Plural brought K8s to the browser for their users:

Overall, we had a ton of fun building this feature. It allowed us to delve into an often unexplored area of the Kubernetes API, which I am honestly happy that we got to explore. This project also took an unexpected turn in its use of tmux and exposed us to a genuinely mind-blowing project in xtermjs (I’m shocked the community had the patience to write a full shell in javascript!).

Sean Moriarity:

A common argument against using Nx for a new machine learning project is its perceived lack of a library/support for some common task that is available in Python. In this post, I’ll do my best to highlight areas where this is not the case, and compare and contrast Elixir projects with their Python equivalents. Additionally, I’ll discuss areas where the Elixir ecosystem still comes up short, and using Nx for a new project might not be the best idea.

Sean is a prominent member of the Elixir community, so that’s the perspective on display here, but it’s a thorough and well-reasoned comparison. He concludes:

While there are still many gaps in the Elixir ecosystem, the progress over the last year has been rapid. Almost every library I’ve mentioned in this post is less than two years old, and I suspect there will be many more projects to fill some of the gaps I’ve mentioned in the coming months.

A reasoned critique of the often lauded with keyword that can be summarized as:

Return values from different expressions in a with block can only be distinguished by the shape of the data returned. This creates ambiguity in with’s else clauses that make code harder to understand and more challenging to modify correctly.

The author describes the problem in detail and even provides two alternatives to with..else that avoid the resulting ambiguity.

Today we talk to Mark Ericksen about all the things that we could be doing on the new platform - this is a follow-up to episode 50.

Mark specialises in Elixir, he hosts the Thinking Elixir podcast, and he also helps make Fly.io the best place to run Phoenix apps, such as changelog.com. In the interest of holding our new platform right, we thought that it would be a great idea to talk to someone that does this all day, every day, for many years now.

We touch up on how to run database migrations safely, and how to upgrade our application config to the latest Phoenix version. We also talked about some of the more advanced platform features that we may want to start leveraging, like the multi-region PostgreSQL.

We’ve been using Parker Selbert’s Oban library for years and he even helped us hold it right by improving our open source implementation!

So, Jerod invited him Backstage to discuss the library, how we’re using it, Parker’s plan to make it financially sustainable, his “freedom number” of Oban Pro subscribers, and a bunch of other random stuff along the way. Let’s go!

Connor Rigby shows us how easy it is to embed Elixir’s IEx console like they do with Nerves.

As is customary around these parts, we aren’t going to write much code. Just glue it together. First up, we’ll need a handful of dependencies.

Plug, Cowboy, and extty do all the heavy lifting.

Good ideas get legs and run. It appears that “self-destructing” TODO comments is a good idea, because the concept has now been implemented in Rust, Ruby, Python, and Elixir (as a credo check). Here’s some insight on that decision shared by the package author, Brian Underwood:

I talked with a couple of other people on the Elixir Slack about it when I started and we all liked the idea of doing it as a check (like with credo) as opposed to at runtime because that could fail on production (not very with the “stability” Elixir ethos 😅).

Compile time would be better, but if you wanted to implement something like the check of GitHub issues then you’re adding HTTP requests to your application’s compile, which maybe means that you’re app doesn’t compile if the HTTP request fails (like because GitHub is down, even if the issue isn’t closed yet).

Chris McCord gives a deep history on Phoenix LiveView, going all the way back to the state of Ruby on Rails in 2013 up to the present. A 30-minute read! (LiveView-based uploads looks particularly interesting to me, since I’m rewriting how our uploads work at the moment.)

The latest Phoenix release ditches webpack and npm for esbuild and… nothing?

Of course, these are just the defaults — docs for Elixir’s esbuild clearly state that NPM is still supported and you can always pass --no-assets and do things 100% your way. But it’s easy to underestimate the power of defaults, especially those that cover area outside of target audience’s expertise — which is the case of Phoenix devs and JS bundlers.

In this post, the author lays out how they stitched together an esbuild + npm setup that will likely scale alongside the frontend of your application. I will surely be trying this setup on our app over the next few weeks and might even video it if you’re interested in going along for the ride.

Alex Koutmos:

If you follow my blog, you have probably noticed that my articles usually revolve around some deep technical problems and how to go about solving these problems using the amazing Elixir programming language. These posts usually discuss the technical merits surrounding Elixir and the Erlang virtual machine, but rarely touch on the “human” aspects of Elixir.

The goal of today’s post will be to address some of the non-technical aspects of the Elixir programming language and talk about the profound impact they can have on your engineers and your business. I’ll start off by addressing one of the most common concerns I come across when it comes to Elixir - that being that “It is hard to find Elixir developers”.

An excellent goal for a blog post. I’d love to see more like this for each and every sub-community in the software world.

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!

Yejun Su is using Numerical Elixir’s new Livebook project for more than just Numerical Things.

Before Livebook, I write code in IEx, which is a REPL. It has some helpers to ease the way to explore code, but in my opinion, Livebook exceeds in two factors:

Code history
In fact, IEx can enable code history by setting export ERL_AFLAGS="-kernel shell_history enabled" in the shell profile file. You can also search the IEx code history with Ctrl-r and apply it. But as Livebook is essentially a notebook, you can see all texts and evaluation results without the need to set anything.

Visualization
Livebook has a clean UI. You can write documents in Markdown and evaluate Elixir code blocks. It is more continuous, you can review every step of your thought by scrolling the page.

This week on Ship It! Gerhard talks with Alex Koutmos about Elixir observability using PromEx. Why do we need to understand how our setup behaves? What is PromEx and where does PromEx fit in changelog.com?

Bonus! Tune in to our LIVE Friday evening deploy 😱 of Erlang 24 for changelog.com. Check the show notes for a link on YouTube. 🍿

Today we’re sharing a special crossover episode from The Changelog podcast here on Practical AI. Recently, Daniel Whitenack joined Jerod Santo to talk with José Valim, Elixir creator, about Numerical Elixir. This is José’s newest project that’s bringing Elixir into the world of machine learning. They discuss why José chose this as his next direction, the team’s layered approach, influences and collaborators on this effort, and their awesome collaborative notebook that’s built on Phoenix LiveView.

This week Elixir creator José Valim joins Jerod and Practical AI’s Daniel Whitenack to discuss Numerical Elixir, his new project that’s bringing Elixir into the world of machine learning. We discuss why José chose this as his next direction, the team’s layered approach, influences and collaborators on this effort, and their awesome collaborative notebook project that’s built on Phoenix LiveView.