DEV Community: Paweł Świątkowski

Portable mruby binaries with Cosmopolitan

Paweł Świątkowski — Wed, 07 Jan 2026 11:59:23 +0000

One of my main interests with mruby is its ability to create standalone executables. As explored in this post, this is absolutely possible and works well. However, there is a classic issue of most standalone binaries: they can only be run on the same, or very similar, system as the one they were built on.

For example, if I take an executable from my mruby Hello World project, built on amd64 Linux, it won't work on Silicon Mac:

$ ./hello
exec: Failed to execute process: './hello' the file could not be run by the operating system.
exec: Maybe the interpreter directive (#! line) is broken?

Mruby does have some cross-compilation capabilities, but I'll be honest: it always felt intimidating, complected and I never actually got it working from Linux to MacOS. So, are we doomed here? Is it possible to build standalone binaries for MacOS without a MacOS docker image or something?

While reading the changelog of mruby I noticed one entry there that got me curious:

New Platform: Cosmopolitan Libc

I never heard about Cosmopolitan, but a quick search revealed that it is what might address the issue mentioned above. From the project's website:

Cosmopolitan Libc makes C a build-anywhere run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine. Instead, it reconfigures stock GCC and Clang to output a POSIX-approved polyglot format that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS on AMD64 and ARM64 with the best possible performance.

Alright, let's give it a try then!

Building an mruby project with Cosmopolitan

The regular steps to build a standalone binary are as shown in the Rakefile:

Build mruby
Generate bytecode from the Ruby code, using mrbc built in step 1
Compile the binary using a C entry file and the bytecode generated in step 2

For Cosmopolitan, it's simple, but we need some initial setup.

First, let's download the Cosmopolitan toolkit from https://cosmo.zip/pub/cosmocc/. I extracted it to ~/Downloads/cosmocc for the purpose of this article.

Then we can build mruby using it:

COSMO_ROOT=~/Downloads/cosmocc rake MRUBY_CONFIG=cosmopolitan

NOTE: At the time of writing, I needed to remove mirb (this line) from the config, because it failed to compile with Cosmopolitan.

Then we can generate the bytecode. Note the different executable name:

./mruby/bin/mrbc.com -Bhello_world hello.rb

Finally, compile the entry file:

~/Downloads/cosmocc/bin/cosmocc -std=c99 -Imruby/include main.c -o hello mruby/build/host/lib/libmruby.a -lm

After that we get a binary hello. And if I copy it over to my Mac, it just works there! The binary size is larger, of course, which is the understandable price. But if it is fine for the project you are working on, for sure this is a simpler way than providing multiple binaries targeting different platforms.

Using Elixir head version with Mise

Paweł Świątkowski — Mon, 05 Jan 2026 09:46:27 +0000

In 2025 I followed the direction many people headed in and switched my version manager to mise-en-place. It has been going really well for me, but recently I came across a problem which took me a bit to figure out (and few very frustrating conversations with LLM, which did not lead to anything). I wanted to test some code with unreleased version 1.20 of Elixir, straight from git.

How to do it? It's really simple in retrospect. Here are the steps:

1. Build Elixir

$ git clone https://github.com/elixir-lang/elixir.git 
$ cd elixir
$ make

Verify it's built correctly:

$ bin/elixir --version
> Elixir 1.20.0-dev (88cbabf) (compiled with Erlang/OTP 28)

2. Link it in mise

mise link elixir@head /path/to/elixir

3. Verify this works

$ mise x elixir@head -- elixir --version
> Elixir 1.20.0-dev (88cbabf) (compiled with Erlang/OTP 28)

And it's done. Whenever you want to run something with Elixir head, you can just mise use elixir@head.

Of course, this should work in a similar way for everything that is handles by mise version control.

Integrating Pagy with Hanami (2025 edition)

Paweł Świątkowski — Mon, 10 Nov 2025 10:53:43 +0000

Back in 2018 I wrote a post about connecting Hanami (then 1.x) and Pagy gem together. My verdict was not that favorable. I had to write quite a lot of glue code to make it work and perhaps the worst thing was that I had to pass the request object to the template to make it work.

However, things have changed since then:

Hanami is now 2.3, its persistence layer is more mature, based on ROM and allows to fall back to almost-bare-Sequel via relations.
Pagy released version 43 this week. It's advertised as a complete rewrite of its internals and APIs.

We needed a leap version to unequivocally signaling that it's not just a major version: it's a complete redesign of the legacy code at all levels, usage and API included.

There's no better time to take it for another spin then!

The code

I quickly spun up a fresh Hanami app, created a migration:

ROM::SQL.migration do
  change do
    create_table :people do
      primary_key :id
      column :name, String, null: false
      column :email, String, null: false
      column :birth_date, Date, null: false
      column :added_at, DateTime, null: false
    end
  end
end

Then created a relation:

module Pagynation
  module Relations
    class People < Hanami::DB::Relation
      schema :people, infer: true
    end
  end
end

Next I generated the action and added Pagy to it.

require "pagy"

module Pagynation
  module Actions
    module People
      class List < Pagynation::Action
        include Deps["relations.people"]
        include Pagy::Method

        def handle(request, response)
          pagy, records = pagy(people.order(:name), request:, client_max_limit: 40)
          response.render view, pagy: pagy, people: records
        end
      end
    end
  end
end

This looks more or less like the tutorial code from the Pagy website. The only exception is that I have to pass the request directy. If not passed, Pagy expects self.request to be defined. This does not work with Hanami, where the request is passed as an argument (in a functional flavour), not burned into the controller instance.

Let's now examine the view:

module Pagynation
  module Views
    module People
      class List < Pagynation::View
        expose :people, decorate: false

        expose :paginator, decorate: false do |pagy:|
          pagy
        end
      end
    end
  end
end

This is standard Hanami stuff. We passed :pagy and :people from the action via the render method, now we need to pass it on to the template. I used decorate: false here to keep the things as simple as possible (data is a simple hash, not objects). With people and paginator exposed, all that's left is to craft a template using it.

<h1>People list</h1>

<table>
  <thead>
    <tr>
      <th>Name</th>
      <th>Email</th>
      <th>Date of Birth</th>
    </tr>
  </thead>
  <tbody>
    <% people.each do |person| %>
      <tr>
        <td><%= person[:name] %></td>
        <td><%= person[:email] %></td>
        <td><%= person[:birth_date] %></td>
      </tr>
    <% end %>
  </tbody>
</table>

<div>
  <%= raw paginator.info_tag %>
</div>

<div>
  <%= raw paginator.series_nav %>
</div>

The paginator.info_tag and paginator.series_nav are Pagy's HTML helper to render some status info and pagination links. They are, of course, quite barebones, but more than enough to test stuff.

This all led me to this beauty, with working limit URL params, working links etc.

New verdict

This is basically great.

Everything worked pretty much out-of-the-box. If I were to imagine how seamless a pagination library for Hanami could be, this would likely look like that. Great improvements from Pagy maintainer.

The repository to try it out yourself is available here on Codeberg.

Happy paginating!

Chekhov's gun principle for testing

Paweł Świątkowski — Sat, 02 Nov 2024 12:53:33 +0000

It’s not an uncommon notion that writing tests is more of a storytelling task than a technical one. Most recently I encountered it in The Bike Shed podcast, but you can find blog posts and conference talks about it as well. And if it is a storytelling act, perhaps we should look into narrative principles to make our tests better?

One of the first rules that comes to my mind when thinking about storytelling is Chekhov’s gun rule. What’s it about? In Anton Chekhov’s own words (I’m quoting after Britannica):

One must never place a loaded rifle on the stage if it isn’t going to go off. It’s wrong to make promises you don’t mean to keep.

Aforementioned Britannica also provides a definition as follows:

principle in drama, literature, and other narrative forms asserting that every element introduced in a story should be necessary to the plot

How does that apply to our tests-storytelling? Imagine you are writing a test for a piece of e-commerce functionality. You have products in categories, and these categories have some kind of constraints on the buyer. The most obvious example would be that alcohol cannot be sold to people under the age of eighteen. In our case, such people cannot add such products to the cart.

Let’s see an example test code - I’m using Elixir here, but this applies to most languages:

test "don't allow adding products to cart when age constraint is not met" do
  buyer = %Person{
    name: "John Smith",
    age: 17,
    country: :uk,
    registered_on: ~U[2023-09-16T18:17:22Z]
  }

  category = %Category{
    name: "Alcohol",
    external_id: 3242,
    constraints: [
      %AgeConstraint{min: 18}
    ]
  }

  product = %Product{
    name: "Triple Hazy IPA",
    category: category,
    sku: "TRI-557",
    added_at: ~U[2022-01-01T12:16:54Z]
  }

  cart = Cart.init(buyer)

  assert Cart.add(cart, product, quantity: 2) == {:error, :constraint_violated}
end

This is not exactly a bad test, but it violates Chekhov’s gun principle in multiple places. Every scalar introduced in our test “arrange” part is a gun in Chekhov’s terms. It’s there on the stage. The reader might expect it to go off. We have 10 scalars here, 11 guns on stage. What does going-off mean? That by changing this value to some other, the test should start failing. Let’s examine our scalars:

name: "John Smith": no matter to what we change it, it won’t make the test fail
age: 17: if we change it to 18 or 22, the test will fail
country: :uk: will not fail (unless we implement country-based constraints, but we do not for now)
registered_on: <date>: does not matter
name: "Alcohol": does not matter
external_id: 3242: what’s even that? does not matter
min: 18: changing it to 15 will make the test fail
The remaining free from product, name, sku and date of adding do not affect the test
quantity: 2: again, does not matter

Summing up, only two out of our eleven guns can go off here. About 18%. The rest is a pure distraction, leading the reader astray if they try to understand the test dynamics.

How do we fix it? By using abstractions! Tests need their abstractions just like your regular code does. And just like with regular code, you should make sure your abstractions are right in a given context. Here one potential abstraction is a factory. Let’s see how the improved version could look like:

test "don't allow adding products to cart when age constraint is not met" do
  buyer = person_factory(age: 17)
  category = category_factory(constraints: [%AgeConstraint{min: 18}])
  product = product_factory(category: category)

  cart = Cart.init(buyer)

  assert Cart.add(cart, product) == {:error, :constraint_violated}
end

The test is visibly shorter now. It contains just 5 non-empty lines. Every scalar here matters and there are just two of them. This way we don’t overwhelm the reader and they can likely quickly draw a conclusion: aha, so the buyer is 17 years old, but the constraint is that they need to be at least 18, so the :constraint_violated error is returned. Makes sense.

Corollary: Make your guns visible

This is just my addition to the narrative principles:

If something is to go off, show it before.

People rather don’t like these deus ex machina moments. If there is something that is important for the test to pass, show it explicitly. Don’t hide it under the abstraction.

Imagine that in the test above the first line just says buyer = person_factory(). Asked during the code review about it, the developer says that in the factory default age is actually 17, so there’s no need to repeat it. This is a misuse of the abstraction. Don’t rely on what’s hidden. In theory everyone should be able to go into the factory and change the values - and tests should still pass. Some people even swear that defaults in factories should be random because of that.

Summary

To make your tests better and more readable (telling story in a better way), eliminate all the data that is irrelevant for the test flow. Leave only things that are important - values that, when changed in a certain way, will make the test fail. On the other hand, don’t hide important stuff in the abstractions. Make the narrative flow without readers scratching their heads.

Enhancing Your Elixir Codebase with Gleam

Paweł Świątkowski — Tue, 06 Aug 2024 12:00:00 +0000

Do you write Elixir but sometimes miss the benefits of type safety we have in other languages? If the answer is "yes", you may want to take a look at Gleam. It is a relatively young language that runs on top of the BEAM platform, which means it can be added as an enhancement to an Elixir codebase without you having to rewrite everything.

In this article, we will add Gleam code to an Elixir project.

Why Use Gleam for Elixir?

First, let's ask ourselves a question: why would we use Gleam? The Elixir ecosystem is mature at this point, with a multitude of great solutions for everyday problems. Ecto and Phoenix make a really powerful combination for writing web applications. Elixir itself is a dynamically typed language, which is great for some applications but opens the door to a whole class of errors.

Imagine you're working on a critical payment processing system in Elixir and need to ensure your core logic's absolute reliability
and correctness. Despite Elixir's strengths, its dynamic typing sometimes leaves room for subtle bugs. Enter Gleam. It's a statically typed language for the BEAM platform that promises to enhance your system's robustness. Where Elixir falls a bit short, Gleam can shine. Let's explore how to integrate Gleam with an Elixir project, so we can have the best from both languages.

We want our core business logic to be written in Gleam while the surrounding code is in Elixir (somewhat akin to the idea of a "functional core, imperative shell", although in the functional world, it's rather a "pure core, stateful shell"). We will take this idea very far, establishing a physical boundary between the two worlds.

Let's see how to get there.

About The Project

To witness the power of Gleam in action, we will implement a feature in a made-up application to manage students at a university. We will take care of their enrollment in courses. Our business rules will look as follows:

A student can be enrolled in a course.
Every course has a limited number of seats and a finite-length waitlist. If a student tries to enroll but all the seats are already taken, they are put on the waitlist (if there are spots there; if not — the enrollment is rejected).
If someone with a reserved seat cancels their enrollment, the first person on the waitlist takes their place.
Some courses have age limits: only students older than a certain age can enroll.

We will start the implementation by creating a fairly standard Phoenix and Ecto application:

mix phx.new student_roll
mix ecto.create
mix phx.gen.live Enrollment Student students name:string date_of_birth:date
mix phx.gen.live Enrollment Course courses name:string max_students:integer waitlist_size:integer min_age:integer
mix phx.gen.schema Enrollment.Enrollment enrollments student_id:integer course_id:integer waitlisted_at:datetime
mix ecto.migrate

With this basic structure in place, we can add Gleam into the mix using the mix_gleam library. We will follow the steps from the project README. First, install mix_gleam:

mix archive.install hex mix_gleam

Now prepare the project to use Gleam by adding some entries to mix.exs's project definition:

@app_name :student_roll

def project do
  [
    archives: [mix_gleam: "~> 0.6"],
    app: @app_name,
    compilers: [:gleam | Mix.compilers()],
    aliases: [
      "deps.get": ["deps.get", "gleam.deps.get"]
    ],
    erlc_paths: [
      "build/dev/erlang/#{@app_name}/_gleam_artefacts"
    ],
    erlc_include_path: "build/dev/erlang/#{@app_name}/include",
    prune_code_paths: false,
    # rest of the function
  ]
end

Note that this assumes you are changing an existing mix.exs file generated by phx.new. These are required steps to make the Gleam code work with Elixir, as outlined in the documentation. You don't need to understand every single change here (I, for instance, don't). The important thing is erlc_path which tells the compiler where to find compiled Gleam files, so we can use them in our project.

Next, also in mix.exs, we need to add the Gleam standard library and testing framework to our dependencies:

defp deps do
  [
    # others
    {:gleam_stdlib, "> 1.0"},
    {:gleeunit, "~> 1.0", only: [:dev, :test], runtime: false}
  ]
end

Finally, fetch dependencies and create the src directory where the Gleam code will live:

mix deps.get
mkdir src

Let's Write Some Gleam

With all the setup in place, we can now start writing our business logic in Gleam! In the first iteration, we will skip the waitlist functionality, but we will still create a system that checks if enrollment is possible. Let's start with a src/enrollment.gleam file. src is the directory at the top level of the project, where mix_gleam expects you to keep your Gleam code.

We will put the following code in the file:

pub type Student {
  Student(id: Int, age: Int)
}

pub type Course {
  Course(id: Int, min_age: Int, seats: Int, seats_used: Int)
}

pub type RejectionReason {
  NoSeats
  AgeRequirementNotMet
}

pub type EnrollmentDecision {
  Enrolled
  Rejected(reason: RejectionReason)
}

pub fn enroll(student: Student, course: Course) -> EnrollmentDecision {
  case student.age >= course.min_age {
    False -> Rejected(AgeRequirementNotMet)
    True ->
      case course.seats > course.seats_used {
        False -> Rejected(NoSeats)
        True -> Enrolled
      }
  }
}

There are quite a few things to unpack here, so let's take a quick crash course on Gleam.

What's Happening Here?

In the first part, we define a bunch of types. Types are the heart of typed languages. Here we need a Student, a Course, an EnrollmentDecision, and a RejectionReason.

Taking a Student declaration, we define not only a type itself but also its constructor, a Student with two arguments: id and age. You can note that we don't include the name here, even though we defined it before in the Elixir schema definition. The name is just side-data. We don't use it for anything related to business logic (unless you have a requirement, such as that only people with names starting with E can take a course).

A type like RejectionReason defines two constructors, which we can basically read as no seats left or the age requirement not being met.

At the end of the code block, we define an actual enroll function. It takes a student and a course, and using a case statement, makes some decisions about the pending enrollment command. case is the only flow control structure in Gleam (there is no if, for example). In this example, we first check the age requirement, and if it's met, we check if seats are left.

With that code ready, we can now write a failing unit test. Let's add a student_roll_test.gleam file in the test directory (this is a naming convention that mix_gleam expects). In that file, add the following:

import enrollment.{Course, Enrolled, Student}
import gleeunit

pub fn main() {
  gleeunit.main()
}

pub fn enrolled_test() {
  let course = Course(id: 1, min_age: 21, seats: 10, seats_used: 9)
  let student = Student(id: 10, age: 20)
  let assert Enrolled = enrollment.enroll(student, course)
}

There's a bit of boilerplate here, but in essence, we create a test function that builds a course with id = 1, min_age = 21, seats_limit = 10 and seats_taken = 9.

Then, we create a student who is 20 years old (therefore too young to enroll). Finally, we try to enroll them. On running mix gleam.test, you get the error:

Running student_roll_test.main
F
Failures:

  1) enrollment_test.enrolled_test: module 'enrollment_test'
     #{function => <<"enrolled_test">>,line => 12,
       message => <<"Assertion pattern match failed">>,
       module => <<"enrollment_test">>,
       value => {rejected,age_requirement_not_met},
       gleam_error => let_assert}
     location: enrollment_test.enrolled_test:12
     stacktrace:
       enrollment_test.enrolled_test
     output:

Finished in 0.011 seconds
1 tests, 1 failures

This is good, but not great. Let's improve the output by using gleeunit/should, a library that makes the unit testing experience better in Gleam:

import enrollment.{Course, Enrolled, Student}
import gleeunit
import gleeunit/should

pub fn main() {
  gleeunit.main()
}

pub fn enrolled_test() {
  let course = Course(id: 1, min_age: 21, seats: 10, seats_used: 9)
  let student = Student(id: 10, age: 20)
  enrollment.enroll(student, course)
  |> should.equal(Enrolled)
}

Now, the output is much more readable:

Running student_roll_test.main
F
Failures:

  1) student_roll_test.enrolled_test: module 'student_roll_test'
     Values were not equal
     expected: Enrolled
          got: Rejected(AgeRequirementNotMet)
     output:

Finished in 0.011 seconds
1 tests, 1 failures

Now, let's fix the test by calling it using a student who is old enough, and we will have a pass:

Running student_roll_test.main
.
Finished in 0.012 seconds
1 tests, 0 failures

Now that we have the first test figured out, we should write some more tests to cover interesting branches in the code. But one important question still lingers: How do I call this from my Phoenix project?

Calling Gleam from Elixir

Let's start working on the Phoenix side of our project. Go to lib/student_roll/enrollment.ex and define two
functions related to the enrollment process:

def enrolled?(course_id, student_id) do
  from(e in Enrollment, where: e.student_id == ^student_id
    and e.course_id == ^course_id and is_nil(e.waitlisted_at))
  |> Repo.exists?()
end

def enroll(course_id, student_id) do
  student = get_student!(student_id)
  course = get_course!(course_id)

  # some logic should go here

  %Enrollment{}
  |> Enrollment.changeset(%{student_id: student.id, course_id: course.id})
  |> Repo.insert()
end

We will write a test checking the enrollment logic:

describe "enrollment" do
  import StudentRoll.EnrollmentFixtures

  test "enroll a student" do
    birthday = DateTime.utc_now() |> DateTime.add(-18 * 365, :day)
    student = student_fixture(%{date_of_birth: birthday})
    course = course_fixture(%{min_age: 22})

    assert {:ok, _} = Enrollment.enroll(course.id, student.id)
    assert Enrollment.enrolled?(course.id, student.id)
  end
end

And it passes! But it should not. We created a student who is roughly 18 years old, but the course requires that the students be at least 22. This is because we did not plug our Gleam-written business logic into the mix. Let's fix this now.

Calling compiled Gleam modules looks to Elixir the same way as Erlang modules. You invoke modules by prepending : to the module name. In our case, this will be :enrollment. We will also have to pass something that Gleam can interpret as its Student and Course types. This is the boilerplate I mentioned earlier.

def enroll(course_id, student_id) do
  student = get_student!(student_id)
  course = get_course!(course_id)

  student_age =
    DateTime.utc_now() |> DateTime.to_date() |> Date.diff(student.date_of_birth) |> div(365)

  seats_taken =
    Repo.aggregate(
      from(e in Enrollment, where: e.course_id == ^course_id and is_nil(e.waitlisted_at)),
      :count
    )

  case :enrollment.enroll(
        {:student, student.id, student_age},
        {:course, course.id, course.min_age, course.max_students, seats_taken}
      ) do
    :enrolled ->
      %Enrollment{}
      |> Enrollment.changeset(%{student_id: student.id, course_id: course.id})
      |> Repo.insert()

    {:rejected, reason} ->
      {:error, reason}
  end
end

Our enroll function is slightly inflated, so let's walk through it.

First, we need some more data. We calculate the student age in Elixir here and also fetch the number of already enrolled students. Second, we build a structure that Gleam will interpret as its type. These are just tuples, where the first element is the name of a type, followed by several fields required by the constructor.

# Gleam: Student(id: Int, age: Int)
{:student, student.id, student_age}

# Gleam: Course(id: Int, min_age: Int, seats: Int, seats_used: Int)
{:course, course.id, course.min_age, course.max_students, seats_taken}

Finally, we call :enrollment.enroll with these tuples. If we run the test now, we will get:

1) test enrollment enroll a student (StudentRoll.EnrollmentTest)
  test/student_roll/enrollment_test.exs:131
  match (=) failed
  code:  assert {:ok, _} = Enrollment.enroll(course.id, student.id)
  left:  {:ok, _}
  right: {:error, {:rejected, :age_requirement_not_met}}
  stacktrace:
    test/student_roll/enrollment_test.exs:136: (test)

This is exactly what we wanted to have! The test does not pass because the student is too young.

pub type RejectionReason {
  NoSeats
  AgeRequirementNotMet
}

pub type EnrollmentDecision {
  Enrolled
  Rejected(reason: RejectionReason)
}


# in Elixir:
# :enrolled | {:rejected, :age_requirement_not_met} | {:rejected | :no_seats}

We've made the first step. We called the Gleam code from Elixir, got the results back, and interpreted them back into Elixir idioms (a result tuple of {:ok, term()} | {:error, term()}).

We should now write any remaining tests we want to run in Elixir. Remember that at this point, the enrollment process is thoroughly unit tested in Gleam by Gleeunit, so perhaps we don't need to duplicate all the cases — only the ones that have consequences in Elixir (but this is up to you and your testing strategy).

After this, we can refactor the enroll function to look nicer and more reader-friendly.

defp get_gleam_student!(id) do
  student = get_student!(id)
  student_age =
    DateTime.utc_now() |> DateTime.to_date() |> Date.diff(student.date_of_birth) |> div(365)
  {:student, id, student_age}
end

defp get_gleam_course!(id) do
  course = get_course!(id)
  seats_taken =
    Repo.aggregate(
      from(e in Enrollment, where: e.course_id == ^id and is_nil(e.waitlisted_at)),
      :count
    )
  {:course, course.id, course.min_age, course.max_students, seats_taken}
end

def enroll(course_id, student_id) do
  course = get_gleam_course!(course_id)
  student = get_gleam_student!(student_id)

  case :enrollment.enroll(student, course) do
    :enrolled ->
      %Enrollment{}
      |> Enrollment.changeset(%{student_id: student_id, course_id: course_id})
      |> Repo.insert()

    {:rejected, reason} ->
      {:error, reason}
  end
end

This looks better. You could even hide get_gleam_student!/1 and get_gleam_course!/1 in a module called, for example, GleamTypes. This way, other contexts that potentially call these structures in Gleam will have them readily available.

But that's not all. We still have some work to do.

Implementing the Waitlist

If you recall, our initial requirements also included a waitlist.

This is missing in the implementation above; now is the time to fix it. This will allow you to see how changing the code in both Gleam and Elixir works. I strongly recommend you change the logic in Gleam first, unit-test it, and only then, write the Elixir proxy code (although if you fancy some strict TDD, you can start with some red Elixir tests too).

But before diving into the code, let's ask ourselves one design question: How should we represent the waitlist? Should it be a number (waitlist_size) or maybe a list of students? This is the classic question in functional design and probably deserves a separate article to address it fully.

In our project, for already-signed-in students, we just pass a number of them, not a list of them. This time, we will model the waitlist as an actual list to make things more interesting.

First, we need to change our domain model by extending the Course type:

pub type Course {
  Course(
    id: Int,
    min_age: Int,
    seats: Int,
    seats_used: Int,
    waitlist: List(Student),
    max_waitlist_size: Int,
  )
}

And then the list of enrollment decisions:

pub type EnrollmentDecision {
  Enrolled
  Rejected(reason: RejectionReason)
  Waitlisted
}

After that, we have to adjust our existing Gleam tests because now they fail with the following message:

error: Incorrect arity
   ┌─ /home/user/dev/student_roll/_build/dev/lib/student_roll/test/student_roll_test.gleam:10:16
   │
10 │   let course = Course(id: 1, min_age: 21, seats: 10, seats_used: 9)
   │                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Expected 6 arguments, got 4

This call accepts these additional labelled arguments:

  - max_waitlist_size
  - waitlist

And we also have to modify the Elixir glue code that calls Gleam:

defp get_gleam_student!(id) do
  get_student!(id)
  |> to_gleam_student()
end

defp to_gleam_student(student) do
  student_age =
    DateTime.utc_now() |> DateTime.to_date() |> Date.diff(student.date_of_birth) |> div(365)

  {:student, student.id, student_age}
end

defp get_gleam_course!(id) do
  course = get_course!(id)

  seats_taken =
    Repo.aggregate(
      from(e in Enrollment, where: e.course_id == ^id and is_nil(e.waitlisted_at)),
      :count
    )

  waitlist =
    from(e in Enrollment, where: e.course_id == ^id and not is_nil(e.waitlisted_at))
    |> Repo.all()
    |> Enum.map(&to_gleam_student/1)

  {:course, course.id, course.min_age, course.max_students, seats_taken, waitlist,
    course.waitlist_size}
end

# the enroll/2 function stays the same

Now let's write a failing test in Gleeunit:

pub fn waitlist_exceeded_test() {
  let course =
    Course(
      id: 2,
      min_age: 0,
      seats: 10,
      seats_used: 10,
      max_waitlist_size: 2,
      waitlist: [
        Student(id: 1, age: 22),
        Student(id: 2, age: 13),
        Student(id: 3, age: 54),
      ],
    )

  let student = Student(id: 4, age: 22)

  enrollment.enroll(student, course)
  |> should.equal(Rejected(NoSeats))
}

pub fn waitlisted_test() {
  let course =
    Course(
      id: 2,
      min_age: 0,
      seats: 10,
      seats_used: 10,
      max_waitlist_size: 2,
      waitlist: [],
    )

  let student = Student(id: 4, age: 22)

  enrollment.enroll(student, course)
  |> should.equal(Waitlisted)
}

One of these tests will accidentally pass (because we reused the NoSeats rejection reason, which might be a dubious choice). But the other one fails. Let's fix it now by actually implementing the waitlist. We need to import the gleam/list package on top and change the branch which previously resulted in NoSeats:

import gleam/list

# ...

pub fn enroll(student: Student, course: Course) -> EnrollmentDecision {
  case student.age >= course.min_age {
    False -> Rejected(AgeRequirementNotMet)
    True ->
      case course.seats > course.seats_used {
        False ->
          case list.length(course.waitlist) >= course.max_waitlist_size {
            True -> Rejected(NoSeats)
            False -> Waitlisted
          }
        True -> Enrolled
      }
  }
}

The final part will be done in Elixir. We have decided that a person should go to the waitlist, but now we have to persist it. Again, let's start with a test:

test "waitlist a student" do
  student1 = student_fixture()
  student2 = student_fixture()
  course = course_fixture(%{max_students: 1, waitlist_size: 10})
  Enrollment.enroll(course.id, student1.id)
  Enrollment.enroll(course.id, student2.id)
  assert Enrollment.waitlisted?(course.id, student2.id)
end

Then we need the waitlisted? function:

def waitlisted?(course_id, student_id) do
  from(e in Enrollment,
    where:
      e.student_id == ^student_id and
        e.course_id == ^course_id and not is_nil(e.waitlisted_at)
  )
  |> Repo.exists?()
end

Finally, we implement the infrastructure part, persisting the waitlist in the database. In the
enroll function's case statement, we need to handle the :waitlisted return type case:

:waitlisted ->
  %Enrollment{}
  |> Enrollment.changeset(%{student_id: student_id, course_id: course_id, waitlisted_at: DateTime.utc_now()})
  |> Repo.insert()

All the tests pass now. We have, therefore, successfully implemented a waitlist function in our Gleam/Elixir application!

Looking at the requirements, we still have some way to go. We haven't touched on canceling an enrollment (when a user has successfully enrolled in the past but is no longer interested). Hint: this handles moving a person from a waitlist to a regular enrollment, so we at least need this type as a return value:

pub type CancellingEnrollmentDecision {
  Cancelled
  CancelledWithWaitlistProcessed(Student)
}

There's also a big topic that can be explored further but was not even covered in our requirements: how we should handle uniqueness. Everyone should be able to enroll in a given course only once, and they should not be able to cancel if they are not enrolled. There are at least three ways to model that behavior between Gleam and Elixir, but that's a topic for a separate article.

Why Did We Do It Again?

Everything we've done here could, of course, all have been written just in Elixir. The code would be shorter and in one language. In most cases, splitting the responsibilities between Elixir and Gleam probably would be a questionable choice. However, I personally think it's something worth considering if:

You like to model your application with types and are missing this from Elixir.
You expect your business logic to grow in complexity and want guarantees from a statically typed language to help you manage that complexity.
You want a strong separation between pure business logic and stateful application code.

If any of these are true for you, consider this arcane-looking setup. In any case, it's good to be aware that it is possible.

Wrapping Up

I have shown you how to call Gleam from an Elixir application and how to interpret the results. We wrote tests in both
languages and some glue code.

Happy coding, whether you choose to do it only in Elixir or you also make use of Gleam!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

Checking Efx - testable effects for Elixir

Paweł Świątkowski — Sat, 13 Jul 2024 11:32:17 +0000

Mocking in Elixir is always a hot topic, mainly because of people coming from different other technologies having different expectation. The most "cannonical" solution, Mox, gives a lot of security with regard to what the fake implementation returns, but requires a bit of a ceremony from the programmer. Other solutions like Mock, Rewire or Bypass offer more ad-hoc mocking, but t the price of the tests heving to be synchronous. Then there's Mimic, which offers ad-hoc mocking and supports async
tests.

In this busy area, a new library appeared very recently. It's called Efx and its description does not even mention mocking:

A library to declaratively write testable effects

It immediately cought m attention, because it seems to implement what I described as "purity injection" some time ago. As a programmer, you write a default impure implementation of the code, but you mark it as an "effect". Then in tests you replace a stateful implementation with something more predictable (you "inject purity") and you can enjoy nice, stable and
fast tests.

This post is a result of taking the library on a quick testing round. I decided to use it to the exact same problem as in the "purity injection" post. To remind, when you create a new order in your e-commerce application, you need to assign it a number. The number needs to be unique within a tenant and it should not contain ambiguous characters. The naive implementation, with which we started, looked like this:

defmodule OrderNumber do
  def generate(tenant_id) do
    candidate = 
      :crypto.strong_rand_bytes(4) 
      |> Base.encode32(padding: false) 
      |> replace_ambiguous_characters()

    query = 
      from o in Order, 
      where: o.tenant_id == ^tenant_id and o.order_id == ^candidate

    if Repo.exists?(query), do: generate(tenant_id), else: candidate
  end
end

Now, let's change this code to support effects in Efx's terminology. We will have two: one for generating a random string and another to check if the sequence has already been used.

defmodule Commerce.OrderNumber do
  use Efx

  def generate(tenant_id) do
    candidate =
      generate_random()
      |> replace_ambiguous_characters()

    case check_existence(candidate, tenant_id) do
      true -> generate(tenant_id)
      false -> candidate
    end
  end

  @spec generate_random :: String.t()
  defeffect generate_random() do
    :crypto.strong_rand_bytes(4)
    |> Base.encode32(padding: false)
  end

  @spec check_existence(String.t(), integer()) :: boolean()
  defeffect check_existence(candidate, tenant_id) do
    import Ecto.Query

    from(o in Commerce.Order,
      where: o.tenant_id == ^tenant_id and o.number == ^candidate)
    |> Commerce.Repo.exists?()
  end

  defp replace_ambiguous_characters(string) do
    string
    |> String.replace("I", "1")
    |> String.replace("O", "0")
  end
end

Both generate_random/0 and check_existence/2 effects are compiled to a regular functions, which are called inside generate/1. There's nothing too fancy in it, so let's see about testing it. In the first test we want to check if the ambiguous characters are replace, so we want our RNG to generate a sequence with such characters:

defmodule Commerce.OrderNumberTest do
  use Commerce.DataCase, async: true
  use EfxCase

  alias Commerce.OrderNumber

  test "replace Os and Is" do
    bind(OrderNumber, :generate_random, fn -> "A5O0I1" end)
    bind(OrderNumber, :check_existence, fn _, _ -> false end)

    assert OrderNumber.generate(1) == "A50011"
  end
end

The bind/3 function replaces the implementation of effects from a default one to a fake one. Now our generate_random/0 function returns A5O0I1 strings, which then replaces the ambiguous characters. We also need to bind the implementation of check_existence here, even though we actually know that the database is empty so the check would pass. There are two reasons to do so:

We want to do it - isolate all side-effects in tests, so tests are faster and less reliant on the infrastructure
We have to do it - because Efx forces us to

If we don't bind the check_existence, we would get an error:

** (RuntimeError) Mock for function check_existence/2 missing
    (efx 0.1.11) lib/efx_case/mock.ex:95: EfxCase.Mock.get_fun/3
    (efx 0.1.11) lib/efx_case/mock_state.ex:66: anonymous fn/5 in EfxCase.MockState.call/4
    (elixir 1.16.0) lib/agent/server.ex:16: Agent.Server.handle_call/3
    (stdlib 5.2) gen_server.erl:1131: :gen_server.try_handle_call/4
    (stdlib 5.2) gen_server.erl:1160: :gen_server.handle_msg/6
    (stdlib 5.2) proc_lib.erl:241: :proc_lib.init_p_do_apply/3
Last message (from #PID<0.405.0>): {:get_and_update, #Function<1.67167648/1 in EfxCase.MockState.call/4>}

After this is done, we can test more elaborate cases:

test "use first candidate when existence check is false" do
  bind(OrderNumber, :generate_random, fn -> "ABC" end)
  bind(OrderNumber, :generate_random, fn -> "123" end)
  bind(OrderNumber, :check_existence, fn _, _ -> false end)

  assert OrderNumber.generate(1) == "ABC"
end

test "use second candidate when first existence check is true" do
  bind(OrderNumber, :generate_random, fn -> "ABC" end, calls: 1)
  bind(OrderNumber, :check_existence, fn _, _ -> true end, calls: 1)
  bind(OrderNumber, :generate_random, fn -> "123" end)
  bind(OrderNumber, :check_existence, fn _, _ -> false end)

  assert OrderNumber.generate(1) == "123"
end

Here we bind the effects few times. The second test shows calls: 1 option passed, which makes sure that bind only binds once. After that, the next bound implementation is used.

Finally, just to be sure, we may want to write a test actually calling the database:

test "check against actual database" do
  bind(OrderNumber, :generate_random, fn -> "ABC" end, calls: 1)
  bind(OrderNumber, :check_existence, {:default, 2})
  bind(OrderNumber, :generate_random, fn -> "123" end)

  %Commerce.Order{tenant_id: 1, number: "ABC"}
  |> Commerce.Repo.insert!()

  assert OrderNumber.generate(1) == "123"
end

Binding with {:default, arity} lets us call the original implementation. This has to be done fully intentionally, not cutting corners.

We have successfully tested our order number generator in a much cleaner way, compared to my original post, without passing dependencies as an argument. Overall I think this is a very promising approach that, aside for improving using fake implementation in tests, nudges the developer in a nice way to:

Think about side-effects when writing the code - you need to wrap them in defeffect
Keep the number of impure functions in the module as low as possible - you have to always bind them all
Use @specs - defeffect requires them; although there are no type checks whether a fake implementation adheres to the spec, at least having to define it might help to visually identify problems.

I think Efx is a great addition to Elixir ecosystem and I salute the author. Nice job!

Don't refactor the code

Paweł Świątkowski — Thu, 13 Jun 2024 18:52:10 +0000

This is a piece of advice someone gave me a long time ago. Unfortunately, I don't really remember who, so I cannot properly attribute (although chances are they heard it somewhere too). But I decided to re-share this.

What is refactoring? I'm sure we can find multitude of definitions. But with modern software development process it often becomes synonymous with any kind of code changes that do not add, modify or remove features. In other words, a non-product work. In effect it often becomes a blurry term and cause of tension between product stakeholders and the dev team.

Who among us did not hear that on a status meeting: "Yesterday I spent most time refactoring the code around X"? I know I did. No less, I probably said a phrase like that more than once. What does this mean? What did you really do? This is hidden behind "I refactored" term. "I did an important technical work you would not understand" is another way of framing that.

And this is exactly the problem with "refactoring the code". In many cases it means doing a really important work, but it's indistinguishable from almost-slacking-off, like renaming variables for no apparent reason.

And this is what I mean by "don't refactor the code": use different words when talking about things you did, are doing or plan to do. Don't "refactor". Instead try these:

I made the code more performant (identified N+1, found inefficient processing of a large amount of data)
I made the code more open to change (mostly should be justified by prediction that we will be changing this area more often now)
I made the code more defensive (failing early and with a clear message if run with incorrect arguments - because other teams are using it incorrectly and it leads to a subtle bugs)
I added the tests for an untested area (good rationale: because it failed few times recently; bad rationale: to increase our arbitrary code coverage metrics)
I added more logging / instrumentation (so we can understand better what is going on)
I change the code to meet our new style guide (because we will change it often)

Communicating like this is not only makes it easier for others to understand what was changed, but also helps you decide if the change you plan to make really makes a difference. Not being able to hide behind an umbrella "refactoring" term also helps to keep the changes more focused and easier to review for your colleagues.

Creating Custom Exceptions in Elixir

Paweł Świątkowski — Tue, 05 Mar 2024 11:25:35 +0000

Exceptions and exception handling are widely accepted concepts in most modern programming languages. Even though they're not as prevalent in Elixir as in object-oriented languages, it's still important to learn about them.

In this article, we will closely examine exceptions in Elixir, learning how to define and use them.

Let's get started!

Elixir and Exceptions

There is no single golden rule that covers when to use exceptions, especially custom ones. Throughout this article, I will keep to a definition of exceptions from StackOverflow:

An exception is thrown when a fundamental assumption of the current code block is found to be false.

So, we can expect an exception when something truly exceptional and hard to predict happens. Network failures, databases going down, or running out of memory — these are all good examples of when an exception should be thrown. However, if the form input you send to your server does not pass validation, there are better expressions to use, such as error tuples.

Check out our An Introduction to Exceptions in Elixir post for an overview of exceptions.

You might wonder how Erlang's famous "let it crash" philosophy works with exceptions. I would say it works pretty well. Exceptions are, in fact, crashes, as long as you don't catch them.

The Anatomy of Elixir's Exceptions

The most common exception you may have seen is probably NoMatchError. And if you've used Ecto with PostgreSQL, you also must have seen Postgrex.Error at least a few times. Among other popular exceptions, we have CaseClauseError, UndefinedFunctionError, or ArithmeticError.

Let's now take a look at what exceptions are under the hood. The easiest way to do that is to cause an exception, rescue it, and then inspect it. We will use the following code to dissect NoMatchError:

defmodule Test do
  def test(x) do
    :ok = x
  end
end

try do
  Test.test(:not_ok)
rescue
  ex -> IO.inspect(ex)
end

The output will be:

%MatchError{term: :not_ok}

As we can see, this is just a struct with some additional data. Using similar code, we can check CaseClauseError.

%CaseClauseError{term: :not_ok}

We can do more using functions provided by the Exception module:

> Exception.exception?(ex) # note that this is deprecated in favour of Kernel.is_exception
true
> Exception.message(ex)
"no case clause matching: :not_ok"
> Exception.format(:error, ex)
"** (CaseClauseError) no case clause matching: :not_ok"

And can peek even deeper by using functions from the Map module:

> Map.keys(ex)
[:__exception__, :__struct__, :term]
> ex.__struct__
CaseClauseError
> ex.__exception__
true
> ex.term
:not_ok

Armed with that knowledge, we create a "fake" exception using just a map:

> Exception.format(:error, %{__struct__: CaseClauseError, __exception__: true, term: :not_ok})
"** (CaseClauseError) no case clause matching: :not_ok"

However, this is not how we will define our custom exception. And before we dive into custom exceptions, let's try to answer one important question: when should we use them?

When Should You Use Custom Exceptions?

The most common use case for custom exceptions is when you are creating your own library. Take Postgrex, for example: you have Postgrex.Error. In Tesla (an HTTP client), you have Tesla.Error. They are useful because they immediately indicate where an error happens and how to determine its cause.

Most of us, however, do not write libraries often. It's more likely that you work on a specific application that powers your company's business (or its customers). Even in your application's code, it can be useful to define some custom exceptions.

For example, your application might send webhook notifications to a URL defined in an environment variable. Consider this very simplified code:

defmodule WebhookSender do
  def send(payload) do
    url = System.get_env("WEBHOOK_ENDPOINT")
    HttpClient.post(url, payload)
  end
end

You can reasonably expect that a WEBHOOK_ENDPOINT environment variable is set on a machine where your application is deployed. If it's not, that's a misconfiguration. To paraphrase the earlier definition of exceptions from StackOverflow, it's a "fundamental assumption of the current code being false".

Of course, running that code when System.get_env call evaluates to nil will result in an exception from HttpClient. However, instead, you can be more defensive and perform a direct check in the WebhookSender module.

Imagine you swap HttpClient for BetterHttpClient in the future, and all exceptions change. Now, throughout your application, you must fix all the places where you use a reported exception (for example, when providing an informative error message to the client). And this is because you changed a dependency, an implementation detail.

How to Define a Custom Exception in Elixir

As we have seen, exceptions in Elixir are just "special" structs. They are special because they have an __exception__ field, which holds a value of true. While we could just use a Map of regular defstruct, this exception would not work nicely with all the tooling around exceptions.

To define a proper exception, we should use the defexception macro. Let's do this for the webhook example we looked at earlier:

defmodule WebhookSender.ConfigurationError do
  defexception [:message]
end

It is as simple as that. You can then improve the code of the WebhookSender:

defmodule WebhookSender do
  def send(payload) do
    case System.get_env("WEBHOOK_ENDPOINT") do
      nil -> raise ConfigurationError, message: "WEBHOOK_ENDPOINT env var not defined"
      url -> HttpClient.post(url, payload)
    end
  end
end

If you run this code (of course, assuming the variable is not set), it will show an error just like with a regular exception:

** (WebhookSender.ConfigurationError) WEBHOOK_ENDPOINT env var not defined
    exceptions_test.exs:24: (file)
    (elixir 1.14.0) lib/code.ex:1245: Code.require_file/2

This exception clearly shows where the error originated from: a WebhookSender module. Imagine that, instead, you see something like HttpClient.CannotPerformRequest here. Chances are you are using HttpClient in multiple places in the application. First, you must traverse the stack trace and find out which HttpClient invocation is the culprit. Then, you still have to figure out the actual reason for the error.

Note that :message is just an example of a field you can define on the exception. Although it's a nice default, it is not strictly needed.

defmodule SpaceshipConstruction.IncompatibleModules do
  defexception [:module_a, :module_b]
end

raise SpaceshipConstruction.IncompatibleModules,
  module_a: LithiumLoadingBay,
  module_b: OxygenTreatmentPlant

When this code runs, however, it will crash on attempting to format the exception message:

** (SpaceshipConstruction.IncompatibleModules) got UndefinedFunctionError with message "function SpaceshipConstruction.IncompatibleModules.message/1 is undefined or private" while retrieving Exception.message/1 for %SpaceshipConstruction.IncompatibleModules{module_a: LithiumLoadingBay, module_b: OxygenTreatmentPlant}. Stacktrace:
    SpaceshipConstruction.IncompatibleModules.message(%SpaceshipConstruction.IncompatibleModules{module_a: LithiumLoadingBay, module_b: OxygenTreatmentPlant})
    (elixir 1.14.0) lib/exception.ex:66: Exception.message/1
    (elixir 1.14.0) lib/exception.ex:117: Exception.format_banner/3
    (elixir 1.14.0) lib/kernel/cli.ex:102: Kernel.CLI.format_error/3
    (elixir 1.14.0) lib/kernel/cli.ex:183: Kernel.CLI.print_error/3
    (elixir 1.14.0) lib/kernel/cli.ex:145: anonymous fn/3 in Kernel.CLI.exec_fun/2

    space_exceptions.exs:5: (file)
    (elixir 1.14.0) lib/code.ex:1245: Code.require_file/2

There are two ways to fix this without having to manually pass an error message every time:

Add a message/1 function to an exception module.

defmodule SpaceshipConstruction.IncompatibleModules do
  defexception [:module_a, :module_b]
  def message(_), do: "Given modules are not compatible"
end

Here, an argument to the function is an exception itself, so you can construct a more precise error message from it. For example:

def message(exception) do
  "Module #{exception.module_a} and #{exception.module_b} are not compatible"
end

Provide a default message.

defmodule SpaceshipConstruction.IncompatibleModules do
  defexception [:module_a, :module_b, message: "Given modules are not compatible"]
end

Repackaging Exceptions

One interesting use case for custom exceptions is when you want to "repackage" an existing exception to fit a specific condition. This can make the exception stand out more in your error tracker.

For example, we did that with database deadlocks at the company I work for. Deadlocks are one of the hardest database-related errors to track, but they are just reported as Postgrex.Error. We wanted clearer visibility over when these errors happen (compared to other Postgrex.Errors) and on which GraphQL mutations.

So, I added an Absinthe middleware checking for the exception. It looks like this:

defmodule MyAppWeb.Middlewares.ExceptionHandler do
  alias Absinthe.Resolution
  @behaviour Absinthe.Middleware

  def call(resolution, resolver) do
    Resolution.call(resolution, resolver)
  rescue
    exception ->
      error = Exception.format(:error, exception, __STACKTRACE__)

      if String.match?(error, ~r/ERROR 40P01/) do
        report_deadlock(exception, __STACKTRACE__)
      else
        @error_reporter.report_exception(exception, stacktrace: __STACKTRACE__)
      end

    resolution
  end

  defp report_deadlock(ex, stacktrace) do
    original_message = Exception.message(ex)
    mutation = get_mutation_name_from_process_metadata()
    try do
      reraise DeadlockDetected,
        [message: "Deadlock in mutation #{mutation}\n\n#{original_message}"],
        stacktrace
    rescue
      exception ->
        @error_reporter.report_exception(exception,
          stacktrace: __STACKTRACE__
        )
    end
  end
end

This might seem like a lot of code. Let's break it down a little. When an exception is raised, we check if its message contains ERROR 40P01 (code for a deadlock).

Then, we raise a custom DeadlockDetected exception and immediately rescue it to send it to an error reporter, such as AppSignal.

Now, instead of generic Postgrex.Errors, often mixed with other database exceptions, we have a separate class of exceptions just dedicated to deadlocks. And custom exception messages allow us to quickly identify the mutation with deadlock-unsafe code.

Repackaging Exits as Exceptions

Another case for custom exceptions is when you want to transform an exit into an exception. This might be because your error reporting software does not support exits, or you may just want a more specific message than the default.

The most common case for exits is timeouts:

defmodule ImportantTask do
  def run do
    task = Task.async(fn -> :timer.sleep(200) end)
    Task.await(task, 100)
  end
end

ImportantTask.run()

In the above code, we spawn an async task that takes 200 milliseconds to complete, but we allow it to run for 100 ms. Here's the result:

** (exit) exited in: Task.await(%Task{mfa: {:erlang, :apply, 2}, owner: #PID<0.96.0>, pid: #PID<0.103.0>, ref: #Reference<0.131053822.3597205508.67962>}, 100)
    ** (EXIT) time out
    (elixir 1.14.0) lib/task.ex:830: Task.await/2
    (elixir 1.14.0) lib/code.ex:1245: Code.require_file/2

It's pretty generic, isn't it? Let's make it a bit nicer.

defmodule ImportantTask do
  defmodule Timeout do
    defexception [:message]
  end

  def run do
    task = Task.async(fn -> :timer.sleep(200) end)
    Task.await(task, 100)
  catch
  :exit, {:timeout, _} = reason ->
      error = Exception.format_exit(reason)
      raise Timeout, message: error
  end
end

ImportantTask.run()

Here, we define a custom Timeout exception, then catch an exit and raise an exception instead. The result is:

** (ImportantTask.Timeout) exited in: Task.await(%Task{mfa: {:erlang, :apply, 2}, owner: #PID<0.96.0>, pid: #PID<0.106.0>, ref: #Reference<0.342776.2255814665.42176>}, 100)
    ** (EXIT) time out
    exits_to_exceptions.exs:12: ImportantTask.run/0
    (elixir 1.14.0) lib/code.ex:1245: Code.require_file/2

While you may consider that this error message is still a bit cryptic, it adds two main quality-of-life improvements:

An ImportantTask.Timeout exception, which makes it easy to assign the error to a particular piece of functionality in your code.
A line from our code in the stack trace (exits_to_exceptions.exs:12: ImportantTask.run/0). Note that the default exit message does not include this, so it's much harder to find the offending place in the code.

Wrapping Up

In this post, we learned how to define custom exceptions in Elixir. They are very useful when building a library, but they also have their place in your application code.

By repackaging generic exceptions or trapping and re-raising exits, you can make your code much easier to debug if something goes wrong. Your future self (and your colleagues) will be grateful!

Happy coding!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

Reconfiguring your application live with dRuby

Paweł Świątkowski — Wed, 10 Jan 2024 21:47:08 +0000

dRuby is a pretty old but relatively unknown part of Ruby standard distribution. I first wrote about it here in 2018 and I have to admit that to this day I haven really found a production use case for it. However, I still think it a gem worth knowing, even if only to impress you Ruby friends on a conference afterparty.

To demonstrate what dRuby can do, we will write a simple application. It will periodically check Mastodon API of ruby.social server and check for new messages (called toots). To keep things as simple as possible, we'll just use net/http as an HTTP client. Here's our first draft:

require "net/http"
require "json"

class RubySocialChecker
  ENDPOINT = "https://ruby.social/api/v1/timelines/public?local=true"

  def call
    response = Net::HTTP.get(URI(ENDPOINT + "&limit=1"))
    parsed = JSON.parse(response)
    @last_toot_id = parsed.first["id"]
    run_loop
  end

  def run_loop
    loop do
      response = Net::HTTP.get(URI(ENDPOINT + "&min_id=#{@last_toot_id}"))
      JSON.parse(response).each do |toot|
        puts toot['uri']
        @last_toot_id = toot['id']
      end
      sleep(5)
    end
  end
end

RubySocialChecker.new.call

If you run it and you're lucky (i.e. someone posts something), you will see links to new toots being printed to stdout. As you see, the code is not particularly complicated. So let's complicate it with seemengly no good reason. In the next step we will extract a configuration to a separate class:

class Config
  attr_accessor :interval, :debug

  def initialize(interval: 5, debug: false)
    @interval = interval
    @debug = debug
  end
end

class RubySocialChecker
  ENDPOINT = "https://ruby.social/api/v1/timelines/public?local=true"

  def initialize(config = Config.new)
    @config = config
  end

  def call
    response = Net::HTTP.get(URI(ENDPOINT + "&limit=1"))
    parsed = JSON.parse(response)
    @last_toot_id = parsed.first["id"]
    run_loop
  end

  def run_loop
    loop do
      response = Net::HTTP.get(URI(ENDPOINT + "&min_id=#{@last_toot_id}"))
      parsed = JSON.parse(response)
      if @config.debug
        puts "[#{Time.now}] Fetched #{parsed.size} toots"
      end

      JSON.parse(response).each do |toot|
        puts toot['uri']
        @last_toot_id = toot['id']
      end
      sleep(@config.interval)
    end
  end
end

Hmm... This starts to look serious! We now have a config, which we pass to the checker. The config specifies how often we should check for new toots and also has a flag for a debug mode. In this mode we output a message with how many toot we just fetched, so you can at least see that something is happening.

We can run our checker in a debug mode now:

config = Config.new(debug: true)
RubySocialChecker.new(config).call

Okay, but why did we do that? Because now we want to add dRuby. This gem essentially allows you to "hook into" your running Ruby program from another process in a controlled manner. Let's add dRuby server to our program right before the code starting the checker.

require "drb/drb"
uri = "druby://localhost:8787"

config = Config.new
DRb.start_service(uri, config)

RubySocialChecker.new(config).call

Now, run the program (note that the debug mode is off) and now in a different terminal window fire up IRB. In the IRB session, do the following:

irb(main):001> require "drb/drb"
=> true
irb(main):002> DRb.start_service
=> #<DRb::DRbServer:0x00007f60d2da7868 ...>
irb(main):003> config = DRbObject.new_with_uri("druby://localhost:8787")
=> #<DRb::DRbObject:0x00007f60d27d3d10 @ref=nil, @uri="druby://localhost:8...
irb(main):004> config.debug = true
=> true

If you now look at the terminal where your program is running... Magic! The debug messages started to show. Now let's spice the things up a bit:

irb(main):005> config.interval = 1
=> 1

The logs show up even faster. We haven't touched anything in the running program, it does not read from any database on each loop step, but we managed to alter its behaviour from the outside. It's also worth noting that the IRB process does not know anything about the checker or config. If you try to reference them, you'll see the uninitialized constant error.

irb(main):009> RubySocialChecker
(irb):9:in `<main>': uninitialized constant RubySocialChecker (NameError)
    from /home/katafrakt/.asdf/...
irb(main):010> Config
(irb):10:in `<main>': uninitialized constant Config (NameError)
Did you mean?  RbConfig
    from /home/katafrakt/.asdf/...

See this in action:

Ok, but why?

Like I said, you probably won't benefit from it in your Rails application. Web applications are stateless by nature and here you need some in-memory state to hook into. However, there are some cases, mostly long-running processes, where this can be useful. The first time I've seen a magic like that, although it was not in Ruby, was an IRC bot, in which admin was able to turn some features on and off live, add people to denylist etc., all without restarting the application.

It might also be an alternative to logs. If you have, for example, a scraper that scrapes thousands of pages, instead of log results every 100 of them, you can expose an interface over dRuby to ask how many pages you checked, how many had useful results and even return these results.

But even if you don't do any of these things, it's good to know that doing things like that is possible and you don't even have to install any additional gem to do that.

You can read more about dRuby in the docs. Or you can even buy a book about it.

Functional domain modeling in Elixir

Paweł Świątkowski — Wed, 25 Oct 2023 07:16:41 +0000

In this blog post I want to explore how using techniques from functional modeling can improve the code written in Elixir. We will see if this way we can avoid some common pitfalls often met in Elixir codebases that lead to convoluted code and, especially, to overly complex (and slow) tests.

For the purpose of this, we will be implementing the following piece from a Library (as in book borrowing) domain: borrowing a book. I am fully aware that libraries work differently in different places of the world, so I picked a handful of requirements. To borrow a book, the following conditions must be met:

A patron must have an active subscription in the library
A patron can have at most 5 books borrowed at any time (so if this is a sixth book, it cannot be borrowed)
A patron cannot have any unpaid fines from keeping the books for too long

Many of us will on instinct write a code similar to this:

def borrow_book(patron_id, book_id) do
  with {:ok, _} <- get_active_subscription(patron_id),
      [] <- Finance.get_unpaid_fines(patron_id),
      currently_borrowed <- get_currently_borrowed_books(patron_id) do
    if length(currently_borrowed) <= 5 do
      Borrowing.create_changeset(patron_id, book_id, DateTime.utc_now())
      |> Repo.insert()
    else
      {:error, :too_many_borrowed_books}
    end
  else
    [%Fine{} | _] -> {:error, :unpaid_fines}
    {:error, :subscription_not_found} -> {:error, :no_active_subscription}
  end
end

defp get_active_subscription(patron_id) do
  case Subscriptions.get_active(patron_id) do
    nil -> {:error, :subscription_not_found}
    sub -> {:ok, sub}
  end
end

This code is not inherently bad by any means. It can be followed quite easily to check what requirements have been implemented. It has reasonable separation of concerns (subscription checks in Subscriptions context etc.). However, at least for me, it does not have a great look'n'feel and also has some more objective issues:

It creates tight coupling between current module (supposedly Borrowing) and other modules - Subscriptions and Finance. Some changes in those module might cause necessity to make changes in this module as well. This is especially visible in tests: if the test setup required for get_active_subscription changes (because, for example, you check it in an external service now, instead of a local database), you have to adjust the setup for test testing borrow_book; otherwise it won't work.
It mixes "technical" concerns of saving into the database with domain logic.
It accepts pretty meaningless IDs (numbers, uuids) as input. If you make a mistake and call it in the reverse order borrow_book(some_book_id, some_patron_id), it will be relatively hard to detect what went wrong.

Let's see if applying techniques of functional modeling can help us here.

Functional what?

But first, we need to finally get to the definition of functional modeling. I'm going to use the definition from @jakub_zalas article:

Functional domain model

Jakub Zalas ・ Oct 13 '23

#kotlin #softwareengineering #functional #ddd

A functional domain model is made of pure functions and immutable types.

Immutable part is really easy in Elixir, because things are immutable by default, until you try really hard to make them mutable. But the other part is interesting and, in my opinion, often overlooked in Elixir, given it's usually advertised as functional language.

Just to recap: a pure function means that for any given input it returns the same predictable output. In other words, it does not have side effects or rely on such - current time, database data, external API calls, I/O etc.

Using pure functions in functional domain modeling allows us to concentrate on the essence of the domain - verifying domain requirements - instead of dabbling with everything around that. We will see what we can do with our little function.

Let's model the domain functionally!

But first, let's reiterate on the requirements:

A patron must have an active subscription in the library. A patron can have at most 5 books borrowed at any time. A patron cannot have any unpaid fines from keeping the books for too long

I made them a little more terse, but also underlined a couple of things. These are the information we need to run our business logic. We don't (for now) care how to obtain it. We just assume it is available to us. There are a few possibilities of how to pass it into our function, but we will use the simplest one, which is: positional arguments.

@spec borrow_book(Subscription.t() | nil, list(Borrowing.t()), list(Fine.t())) :: any()
def borrow_book(active_subscription, currently_borrowed, unpaid_fines)

Or actually we could simplify it even further, if we feel like it, by using just primitive values:

@spec borrow_book(boolean(), integer(), boolean()) :: any()
def borrow_book(has_active_subscription?, number_of_borrowed_books, has_unpaid_fines?)

Whether to choose the first option or second is a choice you need to make. First one is more verbose, makes it more clear what you should pass by just looking at the types. However, in a way, it does create some kind of loose coupling. If you change the name Borrowing to Lending, you will have to change the type signature of the function (although logic would remain untouched).

The first definition is at the same time more open to extension in the future. Maybe if unpaid fines amount to less than $10 you still can borrow? Or perhaps you can if you only have one from last month? Since you have a list of unpaid fines at hand, you might change the check without changing the signature of the function. Using only the primitive values, you'd have to change boolean argument has_unpaid_fines? to some other, like integer sum_of_unpaid_fines_amount.

Leaving this quandary aside, let us note on important thing here: we no longer reference neither the book, nor the patron herself! It turns out that to make a decision whether a book might be borrowed or not, in this case, these are not exactly needed. This is also very important observation: a pure domain function makes a decision whether something should happen or not and returns it. It doesn't necessarily need to execute that decision.

After all this talk, let's now try to actually write the function's body (I picked the first signature, by the way):

def borrow_book(active_subscription, currently_borrowed, unpaid_fines) do
  cond do
    is_nil(active_subscription) -> {:error, :no_active_subscription}
    length(currently_borrowed) >= 5 -> {:error, :too_many_borrowed_books}
    length(unpaid_fines) > 0 -> {:error, :unpaid_fines}
    true -> :ok
  end
end

I used cond here instead of with, because in my opinion it fits a bit better now. This might have something to do with my Ruby background though, where I'd use guard clauses with early return in the beginning of the function to check potential failures and only then execute the happy path. However, you could just as well still use with.

It might seem that this function does not do a lot compared to our original function. That observation is 100% correct. It does much less. In fact it does precisely what we wanted it to do: checks the domain requirement. Nothing more, nothing less. It does not rely on any mutable global state (a.k.a. the database), it does not write to the database - it simply makes a decision whether borrowing can happen or not.

As you can imagine, testing it is a bliss. No setup, no transactions and Ecto sandboxes. You just use ExUnit.Case, you call the function and assert on the result.

There is only one question lingering here...

Okay, but what next?

The domain logic of our application does not exist in vain. Let's be honest here: most web application are glorified wrappers over the database. Almost every request consists of three phases: fetch some data, process this data, persist the result in the database. We are going to build upon this observation. We will take out pure domain function and will make a "functional sandwich" (also sometimes called I/O sandwich or impureim sandwich). This technique bases on isolating "impure" part of the application to the beginning and the end of the request handling, while the middle remains functionally pure. The whole sandwich builder is usually called (at least in DDD-ish circles) a service layer. We need such layer too.

defmodule Library.Borrowing.BorrowingService do
  def borrow_book(patron_id, book_id)
    # something
    # call our pure function
    # something
  end
end

It looks familiar, doesn't it? The implementation might look familiar too:

def borrow_book(patron_id, book_id) do
  subscription = Subscriptions.get_active(patron_id)
  unpaid_fines = Finance.get_unpaid_fines(patron_id)
  currently_borrowed = get_currently_borrowed_books(patron_id)

  case Domain.borrow_book(subscription, currently_borrowed, unpaid_fines) do  # <- !!!
    :ok ->
      Borrowing.create_changeset(patron_id, book_id, DateTime.utc_now())
      |> Repo.insert()
    {:error, error} -> 
      {:error, error}
  end
end

One might say we did not win a lot, but actually we did. We have our core function called in a marked line. Everything before it is preparation, everything after is "post-processing". Our core function is well-tested, so we probably don't need to exhaustively test the service. Only 1 – 2 "plumbing tests" (the name comes from Filip Pacanowski), but this is not a domain logic testing. It just checks if we connected the building blocks correctly.

To retrospect

We split our initial function into two. One of them is a pure function, which means that it's super-easy and super-fast to test. Incidentally, it also handles the most important part of the whole implementation - the actual domain logic. The other function adds "two slices of bread" on both sides of the function: to prepare the required data and to save the result in the database (if needed).

With that we separated the concerns a little but. If the data source or database schema changes, only a service function should be affected. The domain logic stays the same and the function in the Domain module is unaffected by the change. In the opposite direction, if the domain requirements change (for example with allowing to borrow even if there are some unpaid fines), only the domain function will change.

It is, of course, possible that both functions will have to change at the same time: if the change in requirements causes the need to fetch more or different data. In our case, let's imagine that a book of "erotica" genre can be lent only to adult patrons. In that case not only you need to actually fetch a patron and a book, but you also need to pass additional data to the domain function. This might quickly lead to an explosion of the number of the argument. There are some ways to improve this situation, but this is outside of the scope of this article (perhaps I'll write another one).

All in all, I think this kind of the design is not only more functional, but more testable and a bit nicer on the eyes (easier to scan). And I certainly would prefer writing more code like this than like our initial borrow_book version.

On using Phlex

Paweł Świątkowski — Wed, 04 Oct 2023 07:20:12 +0000

Seb Wilgosz recently published an article Phlex with Hanami on Hanami Mastery. It made the latest Ruby Weekly issue as the first item and generally was quite well received. I write this post as an addendum to Seb's article, giving my perspective on using Phlex in Ruby applications.

Important note: you should probably read Seb's article first, as I don't do an introduction to Phlex here.

Establishing credentials

Who am I to talk? I have been using Phlex in my toy project, writing a forum engine in Hanami. I also added it to some pages in one of my oldest Rails projects, serving a small community in production for 10+ years (source code not available). It's not too much, but more than just playing around with hello worlds.

Phlex – a missing view layer we always needed

The most important characteristic of Phlex in my opinion is that, at least for Rails, it's a view layer we never had but always needed. Rails, despite stating that it's MVC, does not really offer much on the "V" front. It feels much more like a model-template-controller, where templates are dumb and typical responsibilities of a view are shoved into a model, controller or a separate kind of object (like form objects). Oh, and there are helpers that do not fit anywhere in this model.

Let's take a quick example. The requirement is:

User has an optional avatar attached. In the user profile view we display that avatar. If the avatar is not present, we use a placeholder image. However, if it's a VIP user, the placeholder image is different than the one for a regular user.

With "traditional Rails" I wouldn't be surprised if I saw it added as avatar_url method of a User model. The alternative is to put the logic directly in the ERB with ifs and elses, or to use a helper method. The first issue here is that Rails does not really offer an answer on where to put that kind of logic. The second - that all these options are flawed in some way:

In a model – this is a purely presentational thing, it simply does not belong in the model
In an ERB file – it makes the template less readable, the logic is not reusable (unless you use partials) and perhaps more importantly: it's really hard to test, as Rails basically offers only testing views by executing the whole controller action
In a helper – it is probably the right place, but many people will reject this as "not OOP enough"

How would that look in Phlex? (a proper view layer)

class UserProfile < Phlex::HTML
  def initialize(user)
    @user = user
  end

  def template
    div(class: "user-profile") do
      img(src: avatar_url)
    end
  end

  private

  def avatar_url
    if @user.has_avatar?
      @user.avatar_url(:small)
    elsif @user.vip?
      "/path/to/vip_avatar_placeholder.png"
    else
      "/path/to/avatar_placeholder.png"
    end
  end
end

That's it. this is just a Ruby object with a state (user is available via an instance variable) where we can define all kinds of helper methods we want. It's all collocated together, you don't need to do file-jumping in search of a definition of user_avatar_url helper method. It's also testable.

Phlex is Ruby - it's extremely testable

To test the code above you don't need to instrument the whole request machinery. You don't even need a user persisted in the database, you also don't need to set up a session. It's a simple test, testing exactly what you need to test. It's also extremely fast to run.

require "phlex/testing/view_helper"

class TestHello < Minitest::Test
  include Phlex::Testing::Nokogiri::FragmentHelper

  def test_user_with_avatar
    user = build_user(avatar: "some_file.png")
    output = render UserProfile.new(user)
    assert_equal "/path/to/avatars/#{user.id}/avatar.png", output.css("img").attr("src")
  end

  def test_user_without_avatar_but_vip
    user = build_user(avatar: nil, vip: true)
    output = render UserProfile.new(user)
    assert_equal "/path/to/vip_avatar_placeholder.png", output.css("img").attr("src")
  end

  def test_user_without_avatar
    user = build_user(avatar: nil, vip: false)
    output = render UserProfile.new(user)
    assert_equal "/path/to/avatar_placeholder.png", output.css("img").attr("src")
  end
end

Phlex is Ruby - you can do Ruby things with it

Phlex views being pure Ruby classes mean that you can do everything what you could do with any other Ruby class. I, for example, use a mixin to include common typography helpers in a Phlex view.

class ArticlePartial < Phlex::HTML
  include Ui::Typography

  def initialize(article)
    @article = article
  end

  def template
    article(class: "article") do
      heading1(@article.title)
      subtitle(@article.motto)

      div(class: "content") { @article.content }
    end
  end
end

In this example both heading1 and subtitle are just methods in Ui::Typography module.

But that's not it. If you really want it for some reason, you can do really fancy Ruby things, like this:

class Page < Phlex::HTML
  def template
    emph = [:i, :b, :u].sample

    div do
      plain "this text will have "
      public_send(emph) { "emphasis"}
      plain " of some kind"
    end
  end
end

On each render, the word "emphasis" will randomly be underlined, bold or in italics. Because why not?

Phlex is Ruby - you can package it

If you have a set of components, such as Card, DataTable, PaginationControls etc., that just accept simple primitive values (strings, numbers, arrays, but not objects such as models), you can easily put them in a gem. And suddenly you have a distributable design system, which you could use across several applications - and have them look the same.

Some final words

This is my experience with working with Phlex so far. However, there might be some questions popping up in your head.

Should I rewrite everything in Phlex?

Phlex has some downsides. The most important is that is abstracts out HTML as Ruby and it might have some negative consequences on your workflow. If you are copying a lot of HTML from open source projects, StackOverflow or HTML file prepared by your designer, you will have to convert everything into Phlex Ruby code. This might be a huge slowdown.

Another problem is if you expect a designer or a UX specialist to actually modify HTML templates in your project. While ERB views are almost-HTML, Phlex views are not. It might be difficult to comprehend how they work for people not knowing Ruby.

How does it compare to ViewComponent?

I have used both ViewComponent and Cells when ViewComponent has not yet been born. They both offer a bit different approach, in which you put a mini-controllers inside your templates. There controllers perform some logic and then render another template, defined in a separate file. For many people, this might feel more familiar or more in line with Rails philosophy.

I personally think that the Phlex approach is closer to the original Rails approach to views. It does not introduce the whole new layer of those mini-controller-components rendering their own views (so you get model-view-template-component-componenttemplate), but rather replaces the dumb default view layer with something smarter, more Rubyish and testable.

Of course, everyone's mileage can vary. These are just tools that are, in fact, very different and it's not like one is automatically better than another.

Data migrations in regular migrations and why you (probably) should not do that

Paweł Świątkowski — Mon, 18 Sep 2023 21:58:35 +0000

Every once in a while I read Lucian Ghinda's Short Ruby newsletter and I see a "take" there which begs for some elaboration and at least slight disagreement. So I decided to try to write these short (but too long for a tweet) replies here.

Today's topic comes from issue #59, where Matt Swanson touches the topic of data migrations.

(here is a link to the tweet)

So what's wrong here? I think the first of all we need to divide what Matt conveniently put together, because "don't reference Rails models in migrations" and "don't run data migrations in schema migrations" are two separate rules coming from different backgrounds.

Don't reference models

The rule of not referencing models relies on the fact that the code of the models change and it might change a lot. In fact, the assumption here is that the migration referencing a model will successfully run on Monday, but won't run on Thursday, because the model file changed and the assumptions made in migration code are no longer correct.

I generally agree that the points in the tweet can greatly reduce the risk of that happening. Although at the same time these points are not realistic. Just how would you "run migrations in dev often" during your two-weeks vacations? Fortnight is definitely enough time in larger projects for model and migration to go out of sync, resulting in a migration not being able to run.

However, I don't want to sweat on it, because that's up to your team if you want to take this risk. The second part is much more interesting.

Don't run data migrations along schema migrations

Let's say it out loud: the migrations were thought as a tool to consistently modify database schema across the environments. If you don't believe me, just check how the table keeping track of the migrations already run is called.

However, in time, people started to use it to run data migrations too. It have few obvious upsides:

You already have a tool for that
Everyone in your organization is expected to run migrations in dev environment regularly, so they will have their data in sync automatically. You don't need to announce on Slack that "everyone please run rake data:backfill_order_numbers".
You already have a step of running it in your deployment pipeline and you don't have to add anything new

In my experience, these advantages start to fade when the project (and especially the database) grows. Here are some problem I encountered with this approach:

Data migrations can take a lot of time. If you put schema change with data migration in the same file, you might and up with a table locked exclusively for a prolonged amount of time, effectively bringing your app down.
Data in production database is often far more exotic than in staging/test environments. The migration might pass on staging, but will fail on production, because of some weird data in the database. Now your pipeline is blocked and you either have to revert or submit a hotfix.
It's not uncommon to have parameterized data migrations, where you first run it for only some tenants or just in some countries. When you check that everything works fine, you proceed with another batch.
You have little control over when the data migration is run. In my current company, for example, you just put your PR in a merge queue and you don't really know when it will be merged (and deployed). Sometimes it's hours later. With data migrations, that might put significant stress on the database, it's better to have very strict control when it's run.
Similarly, you might want to merge and deploy the code during working hours, but run the data migration in off-hours (or even during the weekend). But you have coupled one to the other, so you cannot really do that.
Last but definitely not least: if you write your data migration as a rake task, you can actually write tests for it. Do you write tests for your migrations?

To me personally, these points highly outweigh the comfort of using schema migrations for data migrations. Sure, you lost the comfort of using the tool that's already there, but at the same time you put the stability of the app, the well-being of the whole team and your peace of mind at risk.

So I guess my "counter-take" is:

At least think of having the process of running data migrations in separation from your schema migrations, knowing what's at stake.

DEV Community: Paweł Świątkowski

Portable mruby binaries with Cosmopolitan

Building an mruby project with Cosmopolitan

Using Elixir head version with Mise

1. Build Elixir

2. Link it in mise

3. Verify this works

Integrating Pagy with Hanami (2025 edition)

The code

New verdict

Chekhov's gun principle for testing

Corollary: Make your guns visible

Summary

Enhancing Your Elixir Codebase with Gleam

Why Use Gleam for Elixir?

About The Project

Let's Write Some Gleam

What's Happening Here?

Calling Gleam from Elixir

Implementing the Waitlist

Why Did We Do It Again?

Wrapping Up

Checking Efx - testable effects for Elixir

Don't refactor the code

Creating Custom Exceptions in Elixir

Elixir and Exceptions

The Anatomy of Elixir's Exceptions

When Should You Use Custom Exceptions?

How to Define a Custom Exception in Elixir

Repackaging Exceptions

Repackaging Exits as Exceptions

Wrapping Up

Reconfiguring your application live with dRuby

Ok, but why?

Functional domain modeling in Elixir

Functional what?

Functional domain model

Jakub Zalas ・ Oct 13 '23

Let's model the domain functionally!

Okay, but what next?

To retrospect

On using Phlex

Establishing credentials

Phlex – a missing view layer we always needed

Phlex is Ruby - it's extremely testable

Phlex is Ruby - you can do Ruby things with it

Phlex is Ruby - you can package it

Some final words

Should I rewrite everything in Phlex?

How does it compare to ViewComponent?

Links

Data migrations in regular migrations and why you (probably) should not do that

Don't reference models

Don't run data migrations along schema migrations