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 is here with us too.
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:
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
withblock can only be distinguished by the shape of the data returned. This creates ambiguity in
elseclauses 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.
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!
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-assetsand 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.
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:
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.
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.
Many great Phoenix LiveView examples exist. They often show the ease and power of LiveView but stop at multiple browsers talking to a single web server. I wanted to go further and create a fully clustered, globally distributed, privately networked, secure application. What’s more, I wanted to have fun doing it.
So I set out to see if I could create a fully distributed, clustered, privately networked, global game server system. Spoiler Alert: I did.
I like the way he frames his experience. He says the most remarkable thing about it is not what he built, it’s what he didn’t need to build in order to accomplish his goal.
Jose Valim (the creator of Elixir) recently asked developers from all programming languages to contribute a solution to a short coding challenge based on a real world use case that I had come up while building an Elixir application. Here’s what happened.
We wanted to make a self-hosted version of tools like Intercom and Drift for companies that have privacy and security concerns about having customer data going to third party services. We’re starting with chat right now but we want to expand into all forms of customer communication like email campaigns and push notifications.
Try out the live chat widget on their demo page.
This is one of the least ranty “I’ve switched from X to Y” posts I’ve read and it’s filled with knowledge regarding the importance of data structures:
If you have solid foundation, the house will come with little effort. If the foundation is mud and sticks on top of a trash heap, your life as a builder is going to be complicated.
This principle applies to tools in a broader sense. You want to do the least work possible when swinging a sledgehammer, so you design it such that the hammer is a much heavier material than the handle. This gives you leverage. If you designed your sledgehammer in the inverse, you’d have to swing it harder every time you used it.
This is an exciting development that brings Elixir into areas it hasn’t been used before. We also talk about what this means for Elixir and the community going forward. A must listen!
Queue up this episode and/or stay tuned for an upcoming episode of The Changelog where we’ll sit down with José after his LambdaDays demo to unpack things even more.
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…