Hey, I wrote one as well where I present an approach to developing apps in a proper way using LLMs. Although it’s not heavily about Elixir, it contains Elixir code snippets and the library where I tested the approach.
As a bonus, and perhaps a question, I recently experimented with writing a simple coding agent with MCP capabilities in Elixir, which can actually write and improve its own code. Is that something that the community would be interested in reading about?
I’ve started a series of articles about Elixir on dev.to. My latest piece covers Anonymous Functions - exploring creation, capture syntax, closures, and best practices.
I’m continuing my series of articles about Elixir on dev.to. My latest piece explores Named Functions - covering module organization, pattern matching, function clauses, and documentation techniques.
The article includes practical examples of:
Creating and organizing named functions
Working with function clauses and pattern matching
Understanding function arity and naming conventions
Implementing public vs private functions
Using module attributes and compile-time computation
The article walks through the entire process from fork to PR with a practical example of fixing Markdown formatting. Documentation contributions are a perfect starting point for newcomers who want to get involved in the Elixir community.
Hope this helps anyone looking to make their first open-source contribution!
I’m continuing my series of articles about Elixir on dev.to. My latest piece explores Pattern Matching in Functions - covering how to write elegant, declarative code by using function clauses instead of traditional conditionals.
The article includes practical examples of:
Defining multiple function clauses for the same function
Matching on different data structures (tuples, lists, maps)
Using guards to extend pattern matching capabilities
Destructuring complex data structures directly in function parameters
Implementing common design patterns with pattern matching
Following best practices for maintainable pattern-matched functions
New blog: “A Visual Tour of Phoenix’s Updated ‘magic link’ Authentication Code Generator”
With Phoenix 1.8, the authentication code generator inside phx.gen.auth has been revamped, favoring an emailed ‘magic link’ authentication flow.
In this blog post, I’ll give a visual tour of how this looks to the user, what the core schemas/contexts look like, and I’ll sprinkle in some personal commentary as we go. elixirlang
We just open-sourced Elixir Observer a tool we built to make it easier to explore and evaluate Elixir packages. It offers a cleaner UI, some package health insights, and quick links to docs, repos, and more.
I’m continuing my series of articles about Elixir on dev.to. My latest piece explores The Pipe Operator - covering how to transform nested function calls into elegant, readable pipelines that flow naturally from left to right.
The article includes practical examples of:
Understanding the first argument rule and basic pipe mechanics
Building simple transformations and working with multiple arguments
Creating complex data transformation pipelines
Combining pipes with pattern matching and control flow
Avoiding common pitfalls (wrong argument position, side effects, overuse)
Advanced techniques using then and tap functions
Real-world API request processing examples
Best practices for designing pipe-friendly functions
This foundational operator is a cornerstone of idiomatic Elixir code, making data transformations explicit and sequential while dramatically improving code readability and maintainability.
Last summer I migrated 4 year old production app to a multi-tenant architecture. After I finished the project I wrote up my thoughts but sat on it forever (I struggle to proof-read). This is the post on how we used Ecto.Repo behaviours such as prepare_query/3 to provide customers subdomains and tenancy via Postgres schemas. I’d be interested in hearing your feedback:
Two new posts from me, both about working with nested forms in LiveView.
The Phoenix docs give a basic explanation of how to render nested inputs with <.inputs_for />, but in the real world I’ve had some use cases that go slightly beyond the basic behaviour described in the docs.
I couldn’t find any other explanation online for how to achieve these things, so I wrote it up:
If anyone else has hit anything they’ve struggled with wrt nested forms and <.inputs_for>, please let me know! It might make a good topic for another post.