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.

Mark Eriksen:

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.

You can think of this like Intercom or Drift, only it’s open source and self-hosted (unless you use their hosted offering).

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.

Elixir creator José Valim stopped by the Thinking Elixir podcast to reveal what he’s been working on for the past 3 months: Numerical Elixir!

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…

This is a great rundown by José Valim of what the Elixir community has been up to recently and what’s coming in 2021. Exciting times! I’m particularly excited by the upcoming JIT compiler for the Erlang VM and what it might do to improve compilation times.

As the editor of the Elixir Radar newsletter, I read lots of articles related to Elixir every single week. Along the year I read probably more than 700 articles, so I could curate the best ones and send them to Elixir Radar’s subscribers.

In this article, I share the 11 most popular articles on Elixir Radar in 2020. Those are the ones that had the biggest engagement from Elixir Radar subscribers in each month of 2020, in terms of CTOR (click-to-open rate).

Sometimes a seemingly simple and straightforward function hides a surprising performance profile.

This blog post shows how to combine a few tools available with Elixir, OTP, and related ecosystem in order to understand and improve the memory footprint of an HTTP call.

FooBar |> defmodule([{:do, (
  a
  |> foo()
  |> def([{:do, a |> Kernel.<(0) |> if([{:do, a |> bar(-1)}, {:else, a |> bar(1)}])}])

  a |> bar(b) |> defp([{:do, a |> Kernel.*(b) |> IO.inspect()}])
)}])

I’ve got a fever and the only prescription is more |>s.

We’re joined by co-founder of Plataformatec and curator of the excellent Elixir Radar newsletter, Hugo Baraúna. We talk Elixir podcasts, the start of a new chapter for Hugo, his experimentations with Elixir Radar, curating content, how to make money, stuff like that.

Steven Fuchs loves his Sonos, but…

While it is the radio of the future, our most common usage is as the radio of the past. We tend to tune it to one station and leave it there. By far, our most common interactions with the system are changing the volume and pausing/playing the music, often creating scrambles to find a phone to turn down the volume in order to answer a different phone. What we needed was an analog interface to this digital system that was always at arms reach.

Hackers gonna hack. Steven reached for Elixir and scratched his own itch with this very cool little hardware project. Here’s a demo video of it in action.