Forem: Mark Markaryan

Recruiting with AI and Elixir

Mark Markaryan — Wed, 08 Apr 2026 10:14:03 +0000

Source Code and Setup
Herbarium, Inc. Needs Help
The Candidate Workflow Graph
Talking to AI: The 3 Functions
Let's Try It!
Next Steps
"SNORK RECRUITING DOES NOT SCALE"?
References

Let's Build Something Useful!

At this point, you might be wondering, "Sure, the useless machine was fun to make, and to see what's happening behind the scenes is super-neat, but can we build something a bit more... useful?"

Absolutely! Let's build a recruiting website that uses AI to review submissions and filters out spam and mismatches.

Source Code and Setup

The source code for this exercise is available at https://github.com/shipworthy/recruit

You can clone the repo and run the code on your machine, or you can just follow along.

Herbarium, Inc. Needs Help

Business is booming at Herbarium, Inc. The pile of plants to be examined is growing.

Mr. Hemulen would love some help, but looking for someone is just too much work. To make things worse, last time he tried, he got buried under a mountain of applications that all looked so... meaningless. As if they were all written by a trembling herd of electricity-hungry Hattifatteners. No good.

Snork, a famed inventor, has a solution to Mr. Hemulen's problem. AI!!

Mr. Hemulen will provide a job description and Snork's tool will give him candidates that seem real and look like a potential fit for the job!

Easy! We just need to come up with a way to evaluate and curate submissions!

The Candidate Workflow Graph: Components

Excited, Snork starts sketching the steps of the workflow.

Some of the steps are inputs, some are computations:

Initial Inputs

The inputs for the workflow are:

the job description
the resume
the time of the submission

input(:job_description),
input(:resume),
input(:submitted)

Computations

Once all the inputs are in place, the workflow will compute:

before doing anything else, is this a real resume? and, if so,
the summary of the candidate's background, as it applies to Mr. Hemulen's job description.
the match score, 0..100 – is the candidate a good fit for the job?

compute(:resume_valid, ..., &is_resume_valid/1)
compute(:resume_summary, ..., &summarize_resume/1)
compute(:match_score, ..., &compute_match_score/1)

Hemulen-in-the-Middle Input

After reviewing the submission, Mr. Hemulen can input his decision for next steps. Chat with the candidate? Or no?

input(:decision)

The Candidate Workflow Graph: All Together Now

This all seems pretty straightforward!

Excited, Snork puts the whole thing together.

A couple of things become apparent in the process:

each of the compute nodes is unblocked when its prerequisites are met (e.g. :match_score is unblocked – and its function gets called by Journey – when :resume_valid becomes true).
thinking ahead, when something changes (e.g. we have the :match_score!), we'll want to let the candidate's web page know, so it can update itself.
since LLM processing (computing a summary or scoring) can take a while, we'll give those computations a more generous abandon_after_seconds than the default of 60 seconds.

Here is the graph that Snork came up with:

Journey.new_graph(
  "candidate",
  "1.0",
  [
    input(:job_description),
    input(:resume),
    input(:submitted),
    compute(
      :resume_valid,
      unblocked_when(
        :and,
        [
          {:resume, &provided?/1},
          {:submitted, &provided?/1}
        ]
      ),
      &is_resume_valid/1
    ),
    compute(
      :resume_summary,
      unblocked_when(
        :and,
        [
          {:resume_valid, &true?/1},
          {:job_description, &provided?/1}
        ]
      ),
      &summarize_resume/1,
      abandon_after_seconds: 300
    ),
    compute(
      :match_score,
      unblocked_when(
        :and,
        [
          {:resume_valid, &true?/1},
          {:job_description, &provided?/1}
        ]
      ),
      &compute_match_score/1,
      abandon_after_seconds: 300
    ),
    input(:decision)
  ],
  execution_id_prefix: "c",
  f_on_save: fn execution_id, node_name, result ->
    Logger.info("f_on_save[#{execution_id}]: candidate updated, #{node_name}, #{inspect(result)}")

    Phoenix.PubSub.broadcast(
      ResumeScreener.PubSub,
      "candidate:#{execution_id}",
      {:refresh, node_name, result}
    )

    :ok
  end
)

`f_on_save`: When Something Changes!

At the end of the graph, Snork added a bit of code to generate a PubSub message whenever any of the input or compute'd values get updated. The UI can listen to the message, and update itself whenever something changes.

Talking to AI: The 3 Functions

All that's left is to implement the three functions attached to the compute nodes!

is_resume_valid/1
the function that looks at the submission and determines if it's an actual resume.
summarize_resume/1
the function that looks at the submitted resume and summarizes and evaluates it in the context of the job description.
compute_match_score/1
the function that computes a score for "is the submission a good match for the job", from 0 (nope) to 100 (this is the perfect candidate for the job, at least according to the submission).

The first function, is_resume_valid/1, uses the facebook/bart-large-mnli model, executed via bumblebee / Nx to perform zero-shot classifications:

@resume_label "a professional resume describing a person's professional background and experiences"

def classifier_serving do
  Logger.info("Loading classifier model...")

  {:ok, model} = Bumblebee.load_model({:hf, "facebook/bart-large-mnli"})
  {:ok, tokenizer} = Bumblebee.load_tokenizer({:hf, "facebook/bart-large-mnli"})

  serving =
    Bumblebee.Text.zero_shot_classification(model, tokenizer, [
      @resume_label,
      "not a resume"
    ])

  Logger.info("Classifier model loaded")
  serving
end

def is_resume_valid(resume_text) do
  Logger.info("checking resume for validity")
  truncated = sanitize_and_truncate(resume_text)

  result = Nx.Serving.batched_run(ResumeScreener.ResumeClassifier, truncated)

  resume_score =
    Enum.find(result.predictions, fn p -> p.label == @resume_label end)

  {:ok, resume_score.score > 0.8}
end

This makes is_resume_valid/1 extremely inexpensive and quick to run.

If the resume is deemed valid, we then proceed to summarization and scoring.

These are more expensive operations, for which we use an actual LLM, gemma3:4b, hosted by Ollama. You can see these functions implemented in https://github.com/shipworthy/recruit/blob/main/lib/resume_screener/candidate_graph.ex

When a compute node's unblocked_when conditions are met, Journey calls its compute function, with all of the execution's values, expecting the function to return {:ok, computed_value}. For more information about f_compute functions, see Journey documentation.

Let's Try It!!

Application 1: "zap barometer zap zap"

Snork will use his graph to power his new recruiting website, but for now, he just wants to try it in IEx:

~/src/resume_screener $ iex -S mix

iex(1)> candidate = ResumeScreener.Candidate.Graph.new() |> Journey.start(); :ok

Mr. Hemulen has provided his job description, and someone emailed their application ("How did they get my email address?").

Snork is eager to use his new system to review the submission!

iex(2)> Journey.set(candidate, :job_description, File.read!("example_job_description.txt")); :ok
iex(3)> Journey.set(candidate, :resume, File.read!("example_resume1.txt")); :ok
iex(4)> Journey.set(candidate, :submitted, System.os_time(:second)); :ok

As soon as Snork "submits" the application, :resume_valid node becomes unblocked, and Journey calls its function:

09:03:38.579 [info] checking resume for validity
09:03:40.144 [info] f_on_save[C303R5YZYMVXXYGG4RETR]: candidate updated, resume_valid, {:ok, false}

...wait a second. This is not a valid resume? What is it??

iex(5)> {:ok, resume_valid?, _revision} = Journey.get(candidate, :resume_valid, wait: :any); resume_valid?
false
iex(6)> {:ok, resume, _revision} = Journey.get(candidate, :resume, wait: :any); resume
"zap barometer zap zap\n"

Oh. Right.

A little disappointing, but also... reassuring – this is what the system is supposed to do!

Application 2: "i would like to write my memoir."

Snork didn't have to wait long for another submission. Let's see what we got!!

~/src/resume_screener $ iex -S mix

iex(1)> candidate = ResumeScreener.Candidate.Graph.new() |> Journey.start(); :ok
iex(2)> Journey.set(candidate, :job_description, File.read!("example_job_description.txt")); :ok
iex(3)> Journey.set(candidate, :resume, File.read!("example_resume2.txt")); :ok
iex(4)> Journey.set(candidate, :submitted, System.os_time(:second)); :ok

Let's see!!!

10:05:41.875 [info] checking resume for validity
10:05:43.480 [info] f_on_save[CXZH2T9J5XV5B3XEDMR41]: candidate updated, resume_valid, {:ok, true}
10:05:43.492 [info] summarizing resume for candidate
10:05:43.492 [info] computing match score for candidate
10:05:54.163 [info] resume summary composed for candidate
10:05:54.179 [info] f_on_save[CXZH2T9J5XV5B3XEDMR41]: candidate updated, resume_summary, {:ok, "1.  **Overview:** Moomin Papa presents as a self-described writer and philosopher with limited formal experience. His background is primarily focused on personal adventures and a memoir project.\n\n2.  **Impressive Skills/Deliverables:** Adventuring (a unique selling point), writing skills, and a personal project (Substack).\n\n3.  **Relevant Skills:** None explicitly relevant to the job description. \n\n4.  **Missing Skills:** Extensive experience (14+ years) in application development, particularly with Elixir.  Lack of experience with IoT, Cloud Computing, and Big Data, which are key to Kelvin’s work. No demonstrable leadership or mentoring experience.\n\n5.  **Things to Ask:** What specific types of writing experience does he have? Can he quantify his “adventuring” experience and relate it to problem-solving?  Describe his familiarity with Elixir beyond the substack.  How does he handle ambiguity and complex challenges?"}
10:05:55.415 [info] match score computed for candidate, 15
10:05:55.421 [info] f_on_save[CXZH2T9J5XV5B3XEDMR41]: candidate updated, match_score, {:ok, 15}

YES!! We have a real resume. But why is the match score so low?

iex(5)> {:ok, resume, _revision} = Journey.get(candidate, :resume, wait: :any); resume
"Moomin Papa\npapa@valley.com | Moomin Valley | substack/adventures_in_the_valley\n\nSummary\nA writer philosopher with a lifetime of adventures is writing a memoir.\n\nSkills:\nWriting, adventuring.\n\nEXPERIENCE\nPresent: a writer.\n\nReferences available upon request.\n"

Oh. Ok, Moomin Papa.

Application 102: Hm.

After a few more of those cryptic "zap barometer zap zap"-style submissions, and a "low-match-score" application from Snorkmaiden (I don't care what AI says, I love you sis! ❤️), Snork is looking at application number 102.

~/src/resume_screener $ iex -S mix

iex(1)> candidate = ResumeScreener.Candidate.Graph.new() |> Journey.start(); :ok
iex(2)> Journey.set(candidate, :job_description, File.read!("example_job_description.txt")); :ok
iex(3)> Journey.set(candidate, :resume, File.read!("example_resume3.txt")); :ok
iex(4)> Journey.set(candidate, :submitted, System.os_time(:second)); :ok

So exciting!!

10:25:49.118 [info] checking resume for validity
10:25:51.878 [info] f_on_save[CX9LH56G7V8M4GH9E71TZ]: candidate updated, resume_valid, {:ok, true}
10:25:51.889 [info] summarizing resume for candidate
10:25:51.889 [info] computing match score for candidate
10:25:59.252 [info] match score computed for candidate, 92
10:25:59.266 [info] f_on_save[CX9LH56G7V8M4GH9E71TZ]: candidate updated, match_score, {:ok, 92}
10:26:07.485 [info] resume summary composed for candidate
10:26:07.501 [info] f_on_save[CX9LH56G7V8M4GH9E71TZ]: candidate updated, resume_summary, {:ok, "1. **General Overview:** Morgan Elix is a highly experienced Staff Software Engineer with over 12 years specializing in highly concurrent, fault-tolerant distributed systems, primarily using Elixir and OTP. <...>"}

We have our first candidate with a high match score!! Snork is so excited to pass Morgan's application to Mr. Hemulen!

Next Steps

Mr. Hemulen was excited to see Morgan's application. They had a good chat.

Morgan did not end up becoming Mr. Hemulen's assistant. Morgan wanted to put all the plants in rented buckets in "the cloud", and to charge everyone for looking at pictures of the plants. Mr. Hemulen didn't quite understand how this would make anything better. "This would just make EVERYTHING worse," he thought.

But Mr. Hemulen liked having an easy way to connect with qualified potential helpers, and he wanted to keep the system going.

Snork didn't want to keep running workflows by hand, so he put together a website around it. The website lets candidates upload their resumes, and shows Mr. Hemulen the list of real qualified candidates, with match scores and notes for each.

Snork was kind enough to open-source the website: https://github.com/shipworthy/recruit, complete with usage instructions in its README.md.

Peer Review: "SNORK RECRUITING DOES NOT SCALE"

It was spring, and Snufkin was visiting the Valley. He was curious about Snork's invention, and he seemed to really like it, but he also said "Snork Recruiting does not scale" before wandering off.

This made Snork think. "What did Snufkin mean? How would I 'scale' this?"

Stay tuned for the next blog! : )

References

Resume Screener on GitHub: https://github.com/shipworthy/recruit
Journey on Hex: https://hexdocs.pm/journey
Journey on GitHub: https://github.com/shipworthy/journey
Journey's Website: https://gojourney.dev
Cover image: generated by Google Gemini, seemingly trained on Moomin characters. Moomin character rights are owned by Moomin Characters Oy Ltd., https://www.moomin.com/

The Mystery of a Missing Greeting

Mark Markaryan — Thu, 11 Dec 2025 04:51:44 +0000

"Sure, I can build things quickly with durable workflows, but how do I debug them?"

I hear this question a lot, so let's solve this mystery!

Source Code and Setup

The source code for this exercise is available at github.com/shipworthy/journey_introspect.

You can clone that repo and follow its README's setup steps to run this sequence on your machine, or you can just follow along!

Some output in fragments below is omitted for brevity.

With logistics out of the way, let's go!

Welcome, Customers!

You are a technical co-founder. You just implemented the "welcome" sequence of your onboarding application, as a durable workflow. Your co-founder is surprised at how quickly you did it and how well it works.

Honestly, you are also surprised at how little code you needed to write:

iex(1)> import Journey.Node
Journey.Node
iex(2)> graph = Journey.new_graph(
  "Customer Onboarding",
  [
    input(:name),
    input(:email_address),
    compute(
      :greeting,
      [:name, :email_address],
      fn values ->
        welcome = "Welcome, #{values.name} at #{values.email_address}"
        IO.puts(welcome)
        {:ok, welcome}
      end
    )
  ]
)

The application spins up an execution of this workflow (Journey.start(graph)) for every customer, as they navigate your website. Customers are getting greeted. The business is booming.

The Mystery of a Missing Greeting

All of a sudden you get a call from your co-founder, Ms. Too-Ticky: "Mr. Hemulen, our newest customer, did not get his 'welcome' greeting! Why?!?"

No worries, Ms. Too-Ticky! Journey.Tools.introspect/1 to the rescue!

Mystery Solved?

Let's introspect Mr. Hemulen's onboarding execution. Did :greeting compute?

iex(5)> Journey.Tools.introspect(eid) |> IO.puts()
Values:
- Set:
  - name: '"Hemulen"' | :input
    set at 2025-12-10 09:02:16Z | rev: 1

- Not set:
  - email_address: <unk> | :input
  - greeting: <unk> | :compute

Computations:
- Outstanding:
  - greeting: ⬜ :not_set (not yet attempted) | :compute
       :and
        ├─ ✅ :name | &provided?/1 | rev 1
        └─ 🛑 :email_address | &provided?/1

Aha! :greeting is blocked – we have Mr. Hemulen's :name, but not his :email_address.

Mystery Solved! Hello, Mr. Hemulen!

As soon as Mr. Hemulen provides his email address, he is greeted:

iex> Journey.set(eid, :email_address, "hemulen@gojourney.dev")
Welcome, Hemulen at hemulen@gojourney.dev

All done!

:greeting should now be computed. Is it?

iex(7)> Journey.Tools.introspect(eid) |> IO.puts()
Values:
- Set:
  - greeting: '"Welcome, Hemulen at hemulen@gojourney.dev"' | :compute
    computed at 2025-12-10 09:03:06Z | rev: 4

  - email_address: '"hemulen@gojourney.dev"' | :input
    set at 2025-12-10 09:03:06Z | rev: 2

  - name: '"Hemulen"' | :input
    set at 2025-12-10 09:02:16Z | rev: 1

Computations:
- Completed:
  - :greeting (CMPR7RL0T7T2VTJAG9Z0748): ✅ :success | :compute | rev 4
    inputs used:
       :name (rev 1)
       :email_address (rev 2)

Yes! With Mr. Hemulen's :name and :email_address both in place, :greeting is done!

Ms. Too-Ticky is happy. Mr. Hemulen is happy.

One call to Journey.Tools.introspect/1... mystery solved!

Stay tuned for more adventures in Durable Workflows. ;)

References

The source code for this walkthrough: https://github.com/shipworthy/journey_introspect
Journey Library: https://hexdocs.pm/journey
Cover image: generated by Google Gemini, seemingly trained on Moomin characters. Moomin character rights are owned by Moomin Characters Oy Ltd., https://www.moomin.com/

Building a Useless Machine in Elixir

Mark Markaryan — Thu, 27 Nov 2025 04:54:42 +0000

A Useless Machine does one thing: when you turn it on, a mechanical paw reaches out and flips the switch back off. Useless, but fun.

Let's build one in Elixir!

To save us some code, and to give our Useless Machine object permanence, we'll define it as a reactive durable workflow using Journey.

1. Prerequisites

To play with this, you'll want to have Elixir 1.18 or 1.19, Docker (if you want to run your postgres database in a docker container), and some familiarity with Elixir.

If you use asdf, here is the .tool-versions file I used for this exercise:

$ cat .tool-versions
erlang 27.1.2
elixir 1.19.1-otp-27

2. Source Code

The source code for this exercise (+ a test) is available at https://github.com/shipworthy/useless_machine

If you want to just start playing with Useless Machine, not implement it, just clone the repo, follow its setup steps, and fast forward to section 5. Useless Machine: Let's Play.

If you want to follow along... well, follow along.

3. Create and Configure the Project

We'll start by creating a basic Elixir project, wiring up its dependencies (postgres, journey), configuring its database and journey logging, fetching dependencies, and creating the database.

This is largely standard Elixir stuff, so I'll list the steps, but won't spend much time discussing them.

Create the initial Elixir project:

$ mix new useless_machine
$ cd useless_machine

Wire Up Dependencies

Update your new project's mix.exs to add Journey, Ecto, and Postgrex:

defp deps do
  [
    {:journey, "~> 0.10.40"},
    {:ecto, "~> 3.12 or ~> 3.13"},
    {:postgrex, "~> 0.20 or ~> 0.21"}
  ]
end

Configure the Database and Logging

Create config/config.exs, with the following configuration:

import Config

config :useless_machine, ecto_repos: [Journey.Repo]

config :journey, Journey.Repo,
  database: "useless_machine",
  username: "postgres",
  password: "postgres",
  hostname: "localhost"

config :logger,
       :console,
       format: "$time [$level] $metadata$message\n",
       level: :warning,
       metadata: [:pid, :mfa]

Fetch Dependencies

$ mix deps.get

Start a Postgres Instance, Create the Database

Start a Postgres instance in a container:

$ docker run --rm --name postgres -p 5432:5432 -e POSTGRES_PASSWORD=postgres -d postgres:16

Create the database:

$ mix ecto.create

4. Implement the Useless Machine

Now that we have the placeholder project in place, let's implement our Useless Machine.

A Useless Machine may look similar to this:

  ┌─────────────────────────────────────────────┐
  │                                             │
  │  ┌────────────┐             ┌────────────┐  │
  │  │            │ 2. triggers │            │  │
  │  │  :switch   │────────────▶│    :paw    │  │
  │  │  (input)   │             │  (mutate)  │  │
  │  │            │◀────────────│            │  │
  │  └────────────┘ 3. "off"    └────────────┘  │
  │        ▲                                    │
  └────────┼────────────────────────────────────┘
           │ 1. "on"
       ┌───┴───┐
       │ user  │
       └───────┘

Luckily, it will only be a few lines of code!

Replace the contents of lib/useless_machine.ex with these 15 lines:

defmodule UselessMachine do
  import Journey.Node

  def graph() do
    Journey.new_graph([
      input(:switch),
      mutate(:paw, [:switch], &lol_no/1, mutates: :switch)
    ])
  end

  defp lol_no(%{switch: switch} = _values) do
    IO.puts("paw says: '#{switch}? lol no'")
    {:ok, "off"}
  end
end

This module defines

a graph with two nodes:
- input(:switch) — an input node, representing the switch, which we will turn "on",
- mutate(:paw, [:switch], &lol_no/1, mutates: :switch) — triggered on changes in :switch, it mutates the value of :switch, setting it to the value returned by lol_no/1 ("off").
the function, lol_no/1, which :paw will execute whenever the :switch is turned "on".

This defines your Useless Machine!

One last thing we need to do is to register the graph with Journey by adding these lines to config/config.exs:

config :journey, :graphs, [
  &UselessMachine.graph/0
]

5. Useless Machine: Let's Play

Now that we have everything in place, let's play with our Useless Machine!

Let's fire up iex!

$ iex -S mix

In iex, let's create a new Useless Machine execution:

iex(1)> graph = UselessMachine.graph(); :ok
:ok
iex(2)> execution = graph |> Journey.start(); :ok
:ok

Turn the :switch on!! ... and watch :paw promptly turn the :switch off:

iex(3)> execution = Journey.set(execution, :switch, "on"); :ok
paw says: 'on? lol no'
:ok
iex(4)> Journey.values(execution)
%{
  switch: "off",
  paw: "updated :switch",
  execution_id: "EXECRDYHBJ8X0RVD8BG0A7A5",
  last_updated_at: 1764109938
}

Was it a fluke? Let's try again:

iex(5)> execution = Journey.set(execution, :switch, "on"); :ok
paw says: 'on? lol no'
:ok
iex(6)> Journey.values(execution)
%{
  switch: "off",
  paw: "updated :switch",
  execution_id: "EXECRDYHBJ8X0RVD8BG0A7A5",
  last_updated_at: 1764109952
}

Ok, not a fluke.

No matter how many times you set the switch to "on", the paw immediately turns it back off.

6. Useless Machine: Durable!

Because Journey workflows are durable, our Useless Machine execution persists across time and reboots.

Let's try it!

Take note of the id of your Useless Machine execution (e.g. EXECRDYHBJ8X0RVD8BG0A7A5), quit iex (Ctrl+C twice), then start a fresh session:

$ iex -S mix

Load your old Useless Machine by its ID:

iex(1)> execution = Journey.load("EXECRDYHBJ8X0RVD8BG0A7A5"); :ok
:ok

and make sure that the Useless Machine is just as we left it:

iex(2)> Journey.values(execution)
%{
  execution_id: "EXECRDYHBJ8X0RVD8BG0A7A5",
  last_updated_at: 1764109952,
  paw: "updated :switch",
  switch: "off"
}

Just like before, as soon as you turn the :switch "on", the :paw flips it "off":

iex(3)> execution = Journey.set(execution, :switch, "on"); :ok
paw says: 'on? lol no'
:ok
iex(4)> Journey.values(execution)
%{
  switch: "off",
  paw: "updated :switch",
  execution_id: "EXECRDYHBJ8X0RVD8BG0A7A5",
  last_updated_at: 1764110367
}

The execution survived a restart. It is just as useless as before. ;)

7. Wrap-up

In under 20 lines of code, we built a (durable, crash-safe, and scalable 😂!) Useless Machine!

8. Links

Things referenced in this walkthrough:

Elixir Programming Language: https://elixir-lang.org
Journey on Hex: https://hexdocs.pm/journey
Journey on GitHub: https://github.com/shipworthy/journey
Journey's Website: https://gojourney.dev
Useless Machine on GitHub: https://github.com/shipworthy/useless_machine
Cover image: generated by Google Gemini, seemingly trained on Moomin characters. Moomin character rights are owned by Moomin Characters Oy Ltd., https://www.moomin.com/

Forem: Mark Markaryan

Recruiting with AI and Elixir

Table of Contents

Let's Build Something Useful!

Source Code and Setup

Herbarium, Inc. Needs Help

The Candidate Workflow Graph: Components

Initial Inputs

Computations

Hemulen-in-the-Middle Input

The Candidate Workflow Graph: All Together Now

f_on_save: When Something Changes!

Talking to AI: The 3 Functions

Let's Try It!!

Application 1: "zap barometer zap zap"

Application 2: "i would like to write my memoir."

Application 102: Hm.

Next Steps

Peer Review: "SNORK RECRUITING DOES NOT SCALE"

References

The Mystery of a Missing Greeting

Source Code and Setup

Welcome, Customers!

The Mystery of a Missing Greeting

Mystery Solved?

Mystery Solved! Hello, Mr. Hemulen!

References

Building a Useless Machine in Elixir

1. Prerequisites

2. Source Code

3. Create and Configure the Project

Create the initial Elixir project:

Wire Up Dependencies

Configure the Database and Logging

Fetch Dependencies

Start a Postgres Instance, Create the Database

4. Implement the Useless Machine

5. Useless Machine: Let's Play

6. Useless Machine: Durable!

7. Wrap-up

8. Links

`f_on_save`: When Something Changes!