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…

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.

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.

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!

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. 🍿

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.

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…

I thought it’d be cool to get mix test and mix format running on pushes to the changelog.com repo, so I gave GitHub Actions the old college try. After (not too much) futzing around on my own, I figured I’d have more success by getting an expert to help out. Good call be me! 😆

In this ~1 hour jam session, we go from zero to a successful Actions workflow. I learned a lot along the way, and you might too by joining us on the journey. Thanks, Jonathan!

Wondering why your Phoenix application is recompiling dozens or hundreds of files every time you make a small change? Cross-module compilation dependencies are often to blame.

Chris McCord:

Phoenix v1.5 has been released with LiveView integration. This release makes it easier than ever to build interactive, real-time applications. We put together a quick screencast to show just how much you can accomplish in 15 minutes with LiveView

After José’s announcement yesterday I just had to get my hands a little dirty and kick the tires.

José and the Phoenix team just announced this cool new dashboard for monitoring real-time performance of your production Phoenix systems. I’ll be setting this up and kicking the tires on changelog.com ASAP.

Jam session! I sat down (metaphorically) with Phoenix’s new LiveView feature to see if I can integrate it into our admin to provide a Google Docs-esque experience for podcast co-hosts.

This is my first long-form video where I work toward a goal with no clue how to actually get there. Please let me know if you dig this style in general and/or if you have any advice on the particulars.

José Valim, writing on the Dashbit blog:

I have thought about launching “Devise for Phoenix” probably hundreds of times. I had long conversations with Chris McCord (creator of Phoenix) and co-workers about this. Helping Phoenix users get past the burden of setting up authentication can be a great boost to adoption. At the same time, I never found a proper way to approach the problem.

You can probably guess what’s coming next…

About 2 months ago I decided to handwrite a simple and secure authentication solution on top of a Phoenix application.

Cool stuff. Click through to learn the details of what he came up with (and what’s happening next).

Jerod is joined by Chris and Desmond (co-hosts of the ElixirTalk podcast) to catch up on what’s moving and shaking in the Elixir and Phoenix communities. We discuss what’s attractive about Elixir, what it means to have the language finalized, why folks are so excited by Phoenix LiveView, the ambitious new Lumen project that’s bringing Elixir to WebAssembly, and more.

Jonathan Clem:

What I’m most excited for with Phoenix LiveView isn’t necessarily the cool technology that it really is, but more the freedom that it gives me to quickly implement nice-to-have features that would otherwise be too much work to bother with.

I’m having a lot of fun with Svelte right now, but it’s probably time for me to turn my attention to LiveView. Where there’s enough smoke, there’s usually 🔥…

Conventional template languages like EEx use a form of interpolation to embed a programming language into a markup language, which can result in some ugly code that can be difficult to write and debug.

Temple is written using pure elixir.

There are some good ideas here, for sure. (Click through for code samples.)

My concern with this (and with pretty much all non-HTML style template languages) is cognitive overhead for folks who’d rather be writing HTML. That being said, if I were creating a web app from scratch all by my lonesome, I’d 💯% give Temple a go.

Phoenix 1.3 introduced the idea of Contexts, which I’m generally very much in favor of. However, I wish there was a little bit more structure to the idea. It’s so open ended that I’ve found deciding where best to put a function kind of tricky, and then I frequently end up with duplicate behavior across contexts or have a hard time finding functions later on because the module they’re in made sense at the time, but it doesn’t make as much sense now.

So, I’m proposing the idea of a Primary Context and a Secondary Context.

I’ve also struggled to determine just how to use Contexts to my benefit. It seems that Devon is trying an add more structure approach whereas I have (so far) gone with a YAGNI approach.

Adam Wathan was gracious enough to invite me on Full Stack Radio to discuss why and how we built this very platform that I’m using to write and you’re using to read.

Most of the show focuses on Elixir itself, with topics ranging from pattern matching and immutability to the pipe operator and deployment. Adam also got me to confess a dirty little secret… I still don’t really know what GenServers are! 😱

Nick Janetakis joins Jerod backstage to talk shop. We discuss how Nick is using the Changelog.com source code as a guide to build his video course platform, coding practices we’ve developed over the years, how to balance between shipping features and creating content, newsletters as the new social network, how Nick makes his videos, and a whole lot more.

Chris McCord and team have (finally 😉) open sourced Phoenix’s much anticipated LiveView feature and Dennis Beatty has a great video/explainer on how to build a simple counter with it.

I’m watching this space very closely for future changelog.com features and can’t wait to give it a spin!

As a reminder, LiveView is an in-development feature of the Phoenix web framework that helps you create rich, interactive experiences while writing very little (ostensibly, zero) JavaScript. In Chris’ words:

Phoenix LiveView is an exciting new library which enables rich, real-time user experiences with server-rendered HTML. LiveView powered applications are stateful on the server with bidrectional communication via WebSockets, offering a vastly simplified programming model compared to JavaScript alternatives.

In the linked post, Chris shows a lot of examples of LiveView in action, demonstrating what it’s capable of.

Here’s a feature-complete snake game, in 330 LOC, which requires zero user-land JavaScript.

Impressive!

This release ships with exciting new features, most notably HTTP2 support, improved development experience with faster compile times, new error pages, and local SSL certificate generation.

I’m excited to upgrade us so we can get up and running on H2! 💪