Mike Zornek

A Visual Tour of Phoenix's Updated 'magic link' Authentication Code Generator

mike@mikezornek.com (Mike Zornek) — Tue, 27 May 2025 08:00:00 -0400

With Phoenix 1.8, the authentication code generator inside phx.gen.auth has been revamped, favoring an emailed ‘magic link’ authentication flow.

In this blog post, I’ll give a visual tour of how this looks to the user, what the core schemas/contexts look like, and I’ll sprinkle in some personal commentary as we go.

Background on authentication

When building any web application, user registration, authentication, and authorization are extremely common needs. The Phoenix team wants to help and provides tools and patterns to help get you jump-started.

The Mix task phx.gen.auth is one such tool. Using it inside a fresh Phoenix project, you can set up a community-vetted starting point to allow user registration and authentication.

You’ll also spot some small files created by the phx.gen.auth task related to Scopes a Phoenix 1.8 authorization pattern, but we will not be talking about authorization today.

Creating user registration and authentication flows have a large surface area for security concerns, and using a community-vetted approach like this is highly recommended. Even if you decide to roll your own, generating the community’s recommended code can be a valuable reference tool to inform your custom design.

The sample `Hello` project

The project we’ll be reviewing today was created by:

Installing a prerelease phx_new command:

mix archive.install hex phx_new 1.8.0-rc.3

Creating a new project:

mix phx.new hello

And generate authentication logic:

mix phx.gen.auth Accounts User users

You can find a repo with this code at https://github.com/zorn/magic-link-demo.

User experience

I consider myself a user-focused developer, so let’s start with a visual review of how this registration and authentication feels from a user point of view.

One of the first outcomes of running the code generator is a change to the site navigation. In the upper-right you now have links for Register and Log in.

Registration page

On the registration page, you’ll see a form asking for a single input value, the user’s email.

While password authentication is still an option, a password is not asked for at the time of registration.

Once filled out, the user is presented with a toast explaining that an email was sent to confirm their account.

Opening the confirmation ‘magic link’

When working in local dev, the Phoenix app runs with a web interface to a fake email inbox at http://localhost:4000/dev/mailbox/.

Upon clicking the magic link, the user is presented with a simple form that offers an optional checkbox to Keep me logged in (which will last for 14 days; see module attribute @session_validity_in_days).

This page is required because magic links can be “viewed” by automated systems, such as email link security tools or even URL preview cards seen in apps like Slack. We need to require a user action, and by using the form POST (which automated tools should avoid), we have stronger confidence that the token in this magic link will not be used unexpectedly.

Once the user clicks on the Confirm my account button, they will, in fact, be authenticated AND their account confirmed. On subsequent flows, the button will say Log in.

After authentication, the user is redirected to a predetermined signed_in_path or a stored user_return_to path and is presented with a toast saying they have been authenticated.

After the user is authenticated, the navigation changes to show the account email address, a Settings link, and a Log out link.

Log in with email

To examine the log in form, we will first Log out and see a simple toast with Logged out successfully.. Then, upon clicking the Log in link, you will see this page:

The upper half of the page invites you to Log in with email. Filling out an email will result in a toast saying, If your email is in our system, you will receive instructions for logging in shortly. That email looks very similar to the confirmed email we showed before.

Aside: It is good security practice to build systems so as not to leak user data. I suspect that is the intent of this message’s phrasing. However, the system is not doing this in all places. If you try to register with a known email address, it leaks the existence of the email in the system with has already been taken. There is a balance between pure security concerns and helping the user. You, as the system designer, should decide which path to take for your specific app. I wish the generated code was more consistent, however.

Log in with email/password

The bottom of the page offers a more traditional email/password form. It works as expected. If you are following along, you might be asking yourself, “But I did not create a password?”

An account can, in fact, have a password. It is set on the Settings page we will view below. However, out of the box, the Settings page and its Save Password form is an optional page, not all users would have seen.

Aside: I think it is a bit odd that this generator is doing Log in with email and a secondary (optional) Log in with email/password. In my own professional experiences, I’ve done each separately but never both at the same time. It feels like a UX decision that could lead to user confusion.

Settings

As an authenticated user, you’ll see that the Settings page provides two forms, one for Change Email and one for Save Password.

Change Email

When you put in a new email value and click Change Email the change does not happen immediately. Instead, a link with a token identity for a UserToken record that contains the request is sent via email. Only when that link is activated is the change applied.

The generator logic inside of update_user_email/2 will destroy any previous UserToken records, protecting against multiple change email links going out. All previous ones are deleted upon creation of a new change:#{user.email} token context. More on the UserToken schema below.

Save Password

Setting a password is not a requirement on the registration page.

To set the initial password (or change the current one), you need to fill out this form with a password value and a confirmation. Out of the box, this will require a 12-character length value, but other requirements can be added, and the generated code offers suggestions inside of User.validate_password/2.

You might note this form does not ask for the current password. Instead, this whole settings page utilizes a function from Accounts called sudo_mode?/2. The boolean function is documented as follows:

  @doc """
  Checks whether the user is in sudo mode.

  The user is in sudo mode when the last authentication was done no further
  than 20 minutes ago. The limit can be given as second argument in minutes.
  """
  def sudo_mode?(user, minutes \\ -20)

If the user attempts to load the setting page using a more stale authenticated session, they’ll get a flash redirect saying, You must re-authenticate to access this page.. Some other user experiences would ask for a confirmation of the current password; this is an alternative approach to that security need.

Aside: I don’t like the name sudo_mode?/2. For me, sudo implies an increase in privilege. I renamed the function recently_authenticated?/2 in my own fork of this logic.

Schemas

All of the core authentication logic is found inside Hello.Accounts. There are two main persisted entities.

  schema "users" do
    field :email, :string
    field :password, :string, virtual: true, redact: true
    field :hashed_password, :string, redact: true
    field :confirmed_at, :utc_datetime
    field :authenticated_at, :utc_datetime, virtual: true

    timestamps(type: :utc_datetime)
  end

The first is Hello.Accounts.User, and this is a schema for the persisted entity for the registered user. Most fields are pretty straightforward. Good to see the use of redact: true for those password-related fields.

I feel a little curious about the virtual authenticated_at field. This is a value that is patched into the User struct during calls to Hello.Accounts.get_user_by_session_token/1 and later evaluated by sudo_mode?/2. This feels like a performance choice, connecting values earlier in the call stack instead of repeating a database call later, but I’m generally suspicious of virtual fields as they lead to many questions when trying to understand how the fields are populated.

The second entity is Hello.Accounts.UserToken, and this schema creates a container of sorts that will be used for a variety of tasks.

  schema "users_tokens" do
    field :token, :binary
    field :context, :string
    field :sent_to, :string
    field :authenticated_at, :utc_datetime
    belongs_to :user, Hello.Accounts.User

    timestamps(type: :utc_datetime, updated_at: false)
  end

When you authenticate, in addition to the Phoenix session / cookie, a UserToken record is created. The reasoning for this is documented in the build_session_token/1 function:

  @doc """
  Generates a token that will be stored in a signed place,
  such as session or cookie. As they are signed, those
  tokens do not need to be hashed.

  The reason why we store session tokens in the database, even
  though Phoenix already provides a session cookie, is because
  Phoenix' default session cookies are not persisted, they are
  simply signed and potentially encrypted. This means they are
  valid indefinitely, unless you change the signing/encryption
  salt.

  Therefore, storing them allows individual user
  sessions to be expired. The token system can also be extended
  to store additional data, such as the device used for logging in.
  You could then use this information to display all valid sessions
  and devices in the UI and allow users to explicitly expire any
  session they deem invalid.
  """
  def build_session_token(user) do
    # ...
  end

However, this UserToken schema is used for more than just sessions.

When the system sends an emailed magic link to log in, that is a reference to a UserToken. Again, the power to expire these is very handy.

The system even uses UserToken when changing an email. The wanted new email address is encoded in the link sent over email.

Closing thoughts and nitpicks

So that is a quick visual overview of what you’ll find in Phoenix 1.8’s update phx.gen.auth code generator. Formal documentation has more detailed information and if you want to follow the community discussions that led to this change see this issue and PR.

I have mixed feelings about the change overall.

I think my primary concern is that this adds friction to the deployment of Phoenix toy projects that want user registration. Requiring the developer to acquire transactional email services is one more thing to deploy, and there are plenty of projects where I’d like user registration but desire to keep the dependencies as small as possible.

When I first heard about this change, I thought it would be opt-in, but there is no option to prefer email/password as the primary user flow. It is not a giant leap to generate code and then pull some of it back, remove the magic links, and introduce email/password during registration (I’m doing that for my current Phoenix sandbox), but an official option would be welcome.

Other small nitpicks I’d encourage others to consider when adapting this code for your own projects:

I think button labels should have a consistent case. This project has a mix of title-cased buttons and first-word-only capitalization. Many also have a left-pointing arrow, which adds some visual flair to help promote a primary page action but can be visually overwhelming when you see multiple buttons using it, like on the log in page.
I’m not sure why it says Change Email but Save Password. I wish it were consistent with the verb Change. I thought maybe it would only say Save Password when the password was missing, but in my experience, it was a static button label.

If you welcome this kind of nitpick criticism of your own project, I am available for Elixir Consulting. 😅

Ranked Vote Flick Demo

mike@mikezornek.com (Mike Zornek) — Thu, 01 May 2025 19:58:04 -0400

Took a few moments tonight to record a short demo of RankedVote.app (Project name: Flick) tonight.

Flick is a simple Elixir / Phoenix LiveView app that helps capture ranked votes.

This project was built to help the Elixir Book Club pick books, but it is open to all.

I’m going to moving on to other side projects and seems as good a time as any to capture this in action.

Your browser does not seem to support the video format. You can download the MP4 file directly.

Download MP4 Watch on YouTube

Conference Notes: CodeBEAM America (San Francisco) 2025

mike@mikezornek.com (Mike Zornek) — Mon, 10 Mar 2025 09:56:13 -0800

After a run of bad luck where I had to cancel Elixir-related conferences at the last minute (once because of the smoke storms that hit NY, and once because I got COVID before the conference), this week I enjoyed some time at CodeBEAM America 2025 in San Francisco.

I had a great time at the conference. The content was high quality and well presented. The in-person attendees totaled around 100 people, with another 150 online. I got some well-enjoyed real-world face time with a few old friends, online book club peeps, and maybe even some future clients.

Notable Talks

A few notable talks that landed for me:

Jenny Bramble and Adrian Dunston did an excellent talk, “Detective Hat: Investigating Production Issues,” reviewing how to approach production incidents, communicate with your peers, question assumptions, and ultimately learn from the experience. The pair was well prepared, and the content well delivered.
James Arthur code dropped Phoenix.Sync built on the back of ElectricSQL. I recently learned of Electric while catching up on the Local-first Conf videos just a few weeks ago. It was cool to learn that Electric is built using Elixir back then, but seeing some Phoenix-specific tooling drop was even more exciting. Kicking these tires will be high on my priority list.
Eric Saxby had a talk called “Acceptable Upgrades,” jam-packed with great code organization and testing strategies. I captured many handwritten notes, but the last one was to get the slides, as I could not capture them all.
Jason Axelson followed this up with another test-focused talk titled “Choosing an effective testing structure,” which had a bunch of great tips and library suggestions.
Digit did a talk titled “Nerves ❤️ Flutter” reviewing how the SmartRent Thermostat/Smart Home hub was built, and it was awe-inspiring. The nerves_flutter_support repo was made public as well to help people build on this.
Mitchell Hanberg gave us an update on the new Elixir Language Server, now named Expert. The now blessed official team has been hard at work building a new language server foundation built on the best of the previous three projects. A release still feels a few months away, but the update and teaser were much appreciated.
Kevin Barrett and Sloane Perrault did a talk, “CRDTs and the BEAM: Eventual Consistency Through Acronyms.” Having CRDT in the title, this was a session I’ve had circled on my calendar for months. The talk was an excellent review of how they are utilizing CRDTs to power the delivery of screen.garden, which allows real-time collaboration of standard Obsidian Markdown.

Conference Format

The talks were a mix of 40-minute and 25-minute sessions with ample time for hallway track discussions. A great balance.
There was a great 40-minute block each day for “Birds of a Feather” sessions. Early in the day, people voted on topics, and then the round tables where we ate lunch were signed for spontaneous discussions. I attended a table on WebAssembly, learning about wasmx on the first day, and then a table talking about Ash Framework and Igniter on the second day.

Vibes

While the majority of attendees seemed work-aligned with Elixir, there was also a healthy mix of Nerves, Gleam, and Erlang folks.
Everyone was very friendly and welcoming. There were people who had history and clumped together, but at the same time, I observed many people making space for new people to enter the circle and join in.
Presenting in pairs was popular and more so impressively executed. Everyone seemed well in sync with their presenting partner.
The chaos of the real world was not front and center in most talks (which is fine with me as I enjoy the escape), but it did leak through at times. I recall a specific moment when Ingela Anderton Andin was doing an OTP update. She was remote, presenting from her home in Sweden over video. There was some chatter at the end about how the conference would love to see her return in person in the United States in the upcoming year. There was an uneasiness in her reaction. Acknowledging without fully verbalizing the state of international relations. Seeing the forthcoming calendar of BEAM-related events, many happening in Europe, I had a similar response. I don’t know if United States citizens will be welcome there in 6 months.

Followup Learning Projects

Related to some discussion and possible project work, I bought the Ash book and started reading it on the plane ride home. I’ve worked with Ash before, but using the book to refresh my memory. I may even consider porting some of the Flick domain to Ash as a space to play around.
People were hyped about Cursor well over GitHub Copilot for AI codegen things. I need to experiment more with it.
Need to tinker with Phoenix.Sync.
I totally forgot about burrito. It was mentioned during Digit’s talk, and I should totally check it out in relation to building local-first software.

Burrito is our answer to the problem of distributing Elixir CLI applications across varied environments, where we cannot guarantee that the Erlang runtime is installed, and where we lack the permissions to install it ourselves. In particular, we have CLI tooling that must be deployed on-premise by consultants into customer environments that may be running MacOS, Linux, or Windows.

While I disliked the travel, and boy was I grumpy after the travel day on Wednesday, the conference was a tremendous success. This was my first time at a CodeBEAM event, and I highly recommend it.

Phoenix LiveView: Presenting DateTime in User's Time Zone

mike@mikezornek.com (Mike Zornek) — Wed, 22 Jan 2025 19:47:37 -0500

This past weekend, I added a feature to Flick (RankedVote.app) where we now present domain-specific DateTime values, like published_at and closed_at, on the live view page using the user’s time zone. I thought I’d capture some notes on how this was accomplished, some known limitations, ideas to solve those in your own work, and a set of resource links to learn more.

Elixir time zone basics

Out of the box, when working with Elixir DateTime values, you can only create values relative to the Etc/UTC time zone. If you want to represent values in other time zones, you will need a time zone database.

The Elixir docs discuss this and link a few options. For this post and the Flick project, I choose tzdata, and the following paragraphs will reference it specifically. However, the Elixir runtime is very flexible if you prefer another.

To add the dependency to your project, you’ll add it to the deps list in the mix.exs file.

# mix.exs
defp deps do
  [
    # ...
    {:tzdata, "~> 1.1"}
  ]
end

Then, you’ll need to configure it as your :time_zone_database in the config/config.exs file.

# config/config.exs
config :elixir, :time_zone_database, Tzdata.TimeZoneDatabase

With that in place, you can create values in a time zone.

iex> DateTime.new(~D[2016-05-24], ~T[13:26:08.003], "America/New_York")
{:ok, #DateTime<2016-05-24 13:26:08.003-04:00 EDT America/New_York>}

The user’s time zone

When I say User here, I refer to the web browser client requesting a web page from our server.

Sadly, when displaying a DateTime value in this user’s response, we are hampered by the fact that we do not know their time zone. The time zone is not included with the HTTP request.

Assuming the browser renders the page in an environment that executes JavaScript, the most approachable way to get this is via a function call like:

Intl.DateTimeFormat().resolvedOptions().timeZone;

MDN Reference for DateTimeFormat.

Aside: Curiously, the time zone and locale details of the user’s environment are not part of a permission prompt flow even though they leak sensitive data IMO. If viewing the page, assume you are giving up that info.

So, how do we use this relative to our live view page?

The first thing we will do is edit our assets/js/app.js file. We want to query the browser for the time zone and send it to LiveView via the params of the LiveSocket.

// assets/js/app.js
let csrfToken = document
  .querySelector("meta[name='csrf-token']")
  .getAttribute("content");

// Add this.
let time_zone = Intl.DateTimeFormat().resolvedOptions().timeZone;

let liveSocket = new LiveSocket("/live", Socket, {
  longPollFallbackMs: 2500,
  // And `time_zone` here.
  params: { _csrf_token: csrfToken, time_zone: time_zone },
});

From your live view module’s mount/3 function, you can access this time_zone value like:

  def mount(params, _session, socket) do
    # ...

    # The `time_zone` value will only be available when the live view is
    # rendering a `connected?/1` socket, so make sure to define a default.
    time_zone = get_connect_params(socket)["time_zone"] || "UTC"

    # ...
  end

Once you have the time zone value, any domain-specific DateTime you are storing in UTC can be converted using DateTime.shift_zone/2 for display to the user.

For the needs of my side project, I made a dedicated module called Flick.DateTimeFormatter, which helps me shift the DateTime values and format them to an expected style. It looks something like:

  def display_string(date_time_value, time_zone) do
    case DateTime.shift_zone(date_time_value, time_zone) do
      {:ok, date_time_in_time_zone} ->
        Calendar.strftime(date_time_in_time_zone, "%B %-d, %Y %-I:%M %p %Z")

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

With this in place, I can display a DateTime value from any live view in the user’s time zone.

A full implementation can be found in the Flick PR if you want more reference materials.

This is a half solution.

You might recall in a code comment above, I said:

The `time_zone` value will only be available when the live view is
rendering a `connected?/1` socket, so make sure to define a default.

You might also recall that when a user requests a URL, the live view first renders a non-connected DOM state. This DOM is delivered to the browser, and only then is a WebSocket established, and thus the live view becomes “connected”.

The outcome of this and the design of our solution is that the user will see the DateTime value rendered in UTC first (our default) and then flash into the browser’s time zone as the WebSocket becomes connected.

That kind of sucks, but for the simple needs of Flick, this felt acceptable and is where I left it.

Designing a more complete solution.

In a previous project, I built a meetup group platform. It had to display lots of DateTime values, and this kind of flashing would not have been acceptable.

For that project, we created a stack of fallback time zones.

When a user created their meetup group, they defined a default display time zone for the group. This was our fallback default.
When a web visitor was on the page, we executed JavaScript that would PUT the observed time zone we saw and then on the backend inside a standard controller we would store the time zone inside the session. This would be our ideal default, and would generally be available on everything except the user’s first page load of the site.

A Hook-based approach.

LittleAccountOfCalm of Reddit also suggests:

Pardon me, but why not render a <local-time phx-hook="LocalTime" id={@id} class="invisible">{@date}</local-time component, that has a js-hook like:

Hooks.LocalTime = {
  mounted() {
    this.updated();
  },
  updated() {
    let dt = new Date(this.el.textContent);
    this.el.textContent = Intl.DateTimeFormat("default", {
      dateStyle: "medium",
      // timeStyle: "short",
    }).format(dt);
    this.el.classList.remove("invisible");
  },
};

I recall seeing approaches like this before and you correct that this is just as reasonable of a solution for Flick’s needs. I vaguely recall requirements that made it a non-option for my other project (maybe due to time zone presentation in email copy) but a great addition to the post. Thanks for sharing!

Other Resources

I’ll leave you out with some related resources. Good coding, and if you have any questions, reach out.

Elixir’s DateTime docs are great and worthy of re-read.
My Flick PR where I added this feature.
Date and Time · Elixir School
I gave a talk Working With Time Zones in an Elixir Phoenix App back in 2020 at a local meetup. I have the video, but the embed on that page is currently down. Slides are there, which might be interesting.
There was an amazing talk at ElixirConf 2022 Kip Cole - Time algebra: a new way to think about and work with time. This strays from the practical demonstrations of this post but was a memorable talk that impressed me.
DockYards had their own recent demo blog post, which aligns with many of the things shared here: Getting and Displaying the User’s Local Time in LiveView
Simon Willison: Storing times for human events

Errata

I originally posted this with some links to a private repo. I’m not in a place to make that repo public but will recreate the linked code below.

// assets/js/app.js
// "When a web visitor was on the page, we executed JavaScript that would PUT the observed time zone we saw..."
window.addEventListener("DOMContentLoaded", (event) => {
  if (document.head.dataset.timezone == 0) {
    let user_timezone = Intl.DateTimeFormat().resolvedOptions().timeZone;
    console.log(
      "User timezone was unknown on dom load. Sending user timezone (" +
        user_timezone +
        ") to server.",
    );
    fetch(
      location.protocol +
        "//" +
        location.host +
        "/timezone?iana=" +
        encodeURIComponent(user_timezone),
    ).then((response) => {
      console.log(response);
    });
  }
});

# lib/guildflow_web/controllers/subdomain/timezone_controller.ex
# "... and then on the backend inside a standard controller we would store the time zone inside the session."
def index(conn, %{"iana" => iana}) do
  if Enum.member?(Timex.timezones(), iana) do
    conn
    |> put_session("timezone", iana)
    |> render("index.html", user_timezone: iana)
  else
    user_timezone = get_session(conn, "timezone")

    render(conn, "index.html",
      user_timezone: user_timezone,
      page_title: "User Session Timezone Status"
    )
  end
end

Personal Elixir Code Aesthetics

mike@mikezornek.com (Mike Zornek) — Sun, 29 Sep 2024 20:25:46 -0400

With my side project Flick hitting an MVP milestone and inspired by some conversations during Elixir Book Club, I thought I’d take a moment to document some code aesthetic choices I made in this project.

The order below is not ranked in importance. In fact most of this is nitpicky, but still my preference.

Whitespace between import and alias.

Alphabetically ordered alias declarations.

Avoiding multi-alias declarations.

  # lib/flick/ranked_voting.ex
  import Ecto.Query

  alias Flick.RankedVoting.Ballot
  alias Flick.RankedVoting.Vote
  alias Flick.Repo

Whitespace should be done with intention to separate distinct concepts; and for me, import and alias are distinct concepts.

I also list my alias declarations in alphabetical order, enforced via AliasOrder and use a preferred order across use, import, alias, and require via StrictModuleLayout.

I prefer to avoid multi-alias declarations like alias Flick.RankedVoting.{Ballot, Vote} since it makes searching the code base for module names harder to do. This is enforced with MultiAlias.

(Generally) prefer multiline do/end functions.

defp page_title(:edit), do: "Edit Ballot"
defp page_title(_), do: "Create a Ballot"

Unless I can express a group of functions in a simple stack (like the above code) I generally prefer multiline do/end function declarations. One reason for this preference is that my code editor can collapse the whole module in a nice way, making during exploration easier.

# This could be one line, but I prefer multiline do/end.
def get_ballot!(ballot_id) do
  Repo.get!(Ballot, ballot_id)
end

Use consistent DSL layout in test modules.

# test/flick/ranked_voting_test.exs
describe "update_ballot/1" do
  test "success: updates a ballot title and questions" do
    # ...
  end

  test "failure: `question_title` is required" do
    # ...
  end

  test "failure: can not update a published ballot" do
    # ...
  end
end

Test files can generally end up 2 or 3 times the line count of the module under test. To help keep this code organized and easy to navigate I use a style where I will list the function under test using describe and then various success and failure expectations in each test. For functions like list_ballots/1 that can’t fail, one might drop the success label, but looking at my code as it stands today, it looks like I kept it. 🤷‍♂️

I have far less consistency with my LiveView tests. Sometimes the describe breaks out new vs edit logic, other times it breaks out with or without authentication paths. I’m still evolving this and welcome ideas and good examples.

Invest in test fixtures

Arrange, Act, Assert. To help keep your arrange logic neat and tidy, invest in good test fixture tooling. These test fixtures should provide functions for entity creation in your test files as well as the known list of argument defaults (for tests that need to do something more custom but do not want to be burdened with a complete understanding of every argument).

These fixtures should use the actual domain context paths for creation and not raw SQL injection unless absolutely needed for performance or edge cases.

# test/support/fixtures/ballot_fixture.ex
defmodule Support.Fixtures.BallotFixture do
  @moduledoc """
  Provides functions to allows tests to easily create and stage
  `Flick.RankedVoting.Ballot` entities for testing.
  """

  alias Flick.RankedVoting.Ballot

  @doc """
  Returns a map of valid attributes for a `Flick.RankedVoting.Ballot` entity,
  allowing for the passed in attributes to override defaults.
  """
  @spec valid_ballot_attributes(map()) :: map()
  def valid_ballot_attributes(attrs \\ %{}) do
    Enum.into(attrs, %{
      question_title: "What day should have dinner?",
      possible_answers: "Monday, Tuesday, Wednesday, Thursday, Friday",
      url_slug: "dinner-day-#{System.unique_integer()}",
      published_at: nil
    })
  end

  @doc """
  Creates a `Flick.RankedVoting.Ballot` entity in the `Flick.Repo` for the passed in
  optional attributes.

  When not provided, all required attributes will be generated.
  """
  @spec ballot_fixture(map()) :: Ballot.t()
  def ballot_fixture(attrs \\ %{}) do
    attrs = valid_ballot_attributes(attrs)
    {:ok, ballot} = Flick.RankedVoting.create_ballot(attrs)
    ballot
  end

  @doc """
  Creates a `Flick.RankedVoting.Ballot` entity in the `Flick.Repo` for the passed in
  optional attributes and then publishes the ballot.

  When not provided, all required attributes will be generated.
  """
  @spec published_ballot_fixture(map()) :: Ballot.t()
  def published_ballot_fixture(attrs \\ %{}) do
    attrs = valid_ballot_attributes(attrs)
    {:ok, ballot} = Flick.RankedVoting.create_ballot(attrs)
    {:ok, published_ballot} = Flick.RankedVoting.publish_ballot(ballot)
    published_ballot
  end
end

Aside: I hate how the typespecs here use map() for the attribute map. I want to make that more detailed in the future, see issue #4.

Use tiny_maps to save horizontal line space in tests.

test "success: submitting valid form creates ballot and redirects", ~M{view, ballot} do
  # ...
end

When composing my test descriptions, I like to get the test "..." do on a single line. To help achieve that, I use the tiny_maps library to help me express repetitive argument maps with a more concise syntax: ~M{view, ballot} expands to %{view: view, ballot: ballot}. I generally limit this syntax sugar to test files but would not be against using it in the main source in the future.

Compose code to prefer clean line breaks

I love that Elixir ships with an opinionated formatter. However, even with the formatter, you still have a lot of influence on how your code is composed. I prefer it greatly when expressions are clean one-liners or otherwise avoid excessive indentation when breaking up complex terms.

To help explain, let me walk you through a test from Flick.

test "success: submitting valid form creates ballot and redirects", ~M{view} do
  payload = %{
    question_title: "What's your favorite color?",
    possible_answers: "Red, Green, Blue",
    url_slug: "favorite-color"
  }

  response =
    view
    |> form("form", ballot: payload)
    |> render_submit()

  # Assert upon submit the page redirects, and the ballot was created.
  assert {:error, {:redirect, %{to: redirect_target}}} = response
  assert "/ballot/favorite-color/" <> secret = redirect_target
  assert %Ballot{} = RankedVoting.get_ballot_by_url_slug_and_secret!("favorite-color", secret)
end

First, let’s take note that response is captured in its own line group. Technically, you could compose render_submit() to happen on the same line as assert, but by capturing response using its own line group, it helps separate the act vs. assert test concepts and avoids a very complex indentation variant.

# A complex multiline expression with lots of indentation, I am trying to avoid.
assert {:error, {:redirect, %{to: redirect_target}}} =
         view
         |> form("form", ballot: payload)
         |> render_submit()

Next, let’s look at the pipe feeding response. You could compose the code like this:

response =
  view
  |> form("form", ballot: %{
      question_title: "What's your favorite color?",
      possible_answers: "Red, Green, Blue",
      url_slug: "favorite-color"
  })
  |> render_submit()

I dislike this composition since it breaks the pipe. By moving the payload value assignment to its own line group, we end up with a cleaner pipe that, in my opinion, reads better.

payload = %{
  question_title: "What's your favorite color?",
  possible_answers: "Red, Green, Blue",
  url_slug: "favorite-color"
}

response =
  view
  |> form("form", ballot: payload)
  |> render_submit()

Embrace pipelines with custom utility functions.

# lib/flick_web/live/ballots/index_live.ex
def mount(_params, _session, socket) do
  socket
  |> assign(:page_title, "Admin: Ballots")
  |> assign(:ballots, Flick.RankedVoting.list_ballots())
  |> ok()
end

defmodule FlickWeb.LiveViewPipes do
  @moduledoc """
  A collection of functions to help express pipes when processing live view responses.
  """

  alias Phoenix.LiveView.Socket

  @spec ok(Socket.t()) :: {:ok, Socket.t()}
  def ok(%Socket{} = socket), do: {:ok, socket}

  @spec noreply(Socket.t()) :: {:noreply, Socket.t()}
  def noreply(%Socket{} = socket), do: {:noreply, socket}
end

Many LiveView functions require tuple return values like {:ok, socket} or {:noreply, socket}. To help allow call sites to be composed as a single pipeline, I use some utility functions like ok() and noreply().

Be consistent between module names and filenames.

If I have a module called Flick.RankedVoting.RankedAnswer it lives at the filepath lib/flick/ranked_voting/ranked_answer.ex

While I have good consistency inside my core domain contexts, this consistency fails with various Phoenix things. For example, FlickWeb.Ballots.EditorLive lives at lib/flick_web/live/ballots/editor_live.ex. I dislike that Phoenix generators put these modules in a folder called live that the module path does not express. I may fix that in the future.

Related blog post: LiveView Modules Must End in Live

Write professional documentation.

  @doc """
  Publishes the given `Flick.RankedVoting.Ballot` entity.

  Once a `Flick.RankedVoting.Ballot` entity is published, it can no longer be updated.
  Only a published ballot can be voted on.
  """

All public functions, especially those that represent the formalized domain API for your system, should get documentation.

Each documentation block should start with a single-line, terse summary, as those are used by ex_doc and other developer tooling to summarize function indexes. Every so often, look at the collection of function summaries of a module and try to make them all use consistent phrasing like “Returns noun given thing…” or “Raises Blah when stuff…”.

If referencing another module, function, or callback, use backticks to help the documentation system generate hyperlinks.

Use rewrap tools to hardwrap characters to 80 columns to help with GitHub diffing and more presentable Markdown.

Document your decisions.

Programming is all about tradeoffs. When making an intentional design or process decision with other valid approaches available, consider documenting what was considered and why you went with your approach. Your future self and peers will thank you.

I’ve documented some things related to timestamps, schema shape, and fixme/todo so far in Flick.

Make sure each FIXME has an issue URL.

Related to the above decisions, Flick allows FIXME comments but requests all FIXMEs include a link to a GitHub issue documenting the concern.

Avoid abbreviations and prefer expressiveness.

Prefer expressive variable names like _ballot over _.

Prefer expressive variable names like ballot_params over params when you think it helps improve clarity.

Words matter.

Invest time in an expressive and consistent ubiquitous language for your project. Continue to edit it over time as the terms evolve.

Find consistency in your project code regarding terms like create vs. new, update vs. edit, submit vs. save, params vs. attributes.

Do your best to align with existing Elixir community norms.

Craft typespecs to express your domain.

All public functions should have a typespec. Private functions can also have typespecs, depending on whether they will help with code clarity or change confidence.

Spend time and make those typespecs match the domain. For example, when accepting the identity of a Ballot use the Ballot.id() not a Ecto.UUID.t().

  # lib/flick/ranked_voting/ballot.ex
  @type id :: Ecto.UUID.t()

When building types for my main domain entities, I tend to build the main t() around a persisted entity value that is brought into memory from a Repo, and thus all post-creation values like id or updated_at are typed to their expected value, without the need for an | nil addendum.

To help write typespecs for non-persisted structs of this schema type, I make a schema_t() variant.

  @typedoc """
  A type for a persisted `Flick.RankedVoting.Ballot` entity.
  """
  @type t :: %__MODULE__{
          id: Ecto.UUID.t(),
          question_title: String.t(),
          description: String.t() | nil,
          url_slug: String.t(),
          secret: Ecto.UUID.t(),
          possible_answers: String.t(),
          published_at: DateTime.t() | nil
        }

  @typedoc """
  A type for the empty `Flick.RankedVoting.Ballot` struct.

  This type is helpful when you want to typespec a function that needs to accept
  a non-persisted `Flick.RankedVoting.Ballot` struct value.
  """
  @type struct_t :: %__MODULE__{}

Spend time writing typedoc documentation, it can be a helpful space to talk out the reasoning behind some of the types.

In addition to writing typespecs, when composing functions I also prefer pattern matching the struct and using guards to be explicit about incoming argument expectations.

  def change_ballot(%Ballot{} = ballot, attrs) when is_map(attrs) do
    # ...
  end

Dialyzer is not a runtime enforcement tool, but these are. They help enforce expectations earlier in the call stack and thus help you become aware of when things are not as they seem sooner.

Document your dependencies.

To help future you know why various dependencies were added to the project, add a minimal description before listing it.

  defp deps do
    # ...

    # For Observability.
    {:appsignal_phoenix, "~> 2.5"},

    # To Render Markdown.
    {:earmark, "~> 1.4"},

    # For security scans.
    {:sobelow, "~> 0.13", only: [:dev, :test], runtime: false},
  end

Document and validate function options.

  # lib/flick/ranked_voting.ex

  @doc """
  ...

  ## Options

  * `:action` - An optional atom applied to the changeset, useful for forms that
    look to a changeset's action to influence form behavior.
  """
  def change_vote(%Vote{} = vote, attrs, opts \\ []) do
    opts = Keyword.validate!(opts, action: nil)

    # ...
  end

If you offer a function that accepts options as the final argument, document them and validate them.

Validation helps ensure call sites do not include unexpected or typoed option keys and offers a clean space to provide a default value for the said option.

Aside: Not currently demonstrable in Flick, but is in some of my work project, I usually write rich typespecs for my options as well.

Compose PR titles for clarity and consistency.

With Flick, I work in focused PRs and have those PRs titled for clarity regarding what is changing. I like using prefixes like fix chore feat. These PR titles are enforced with a specific GitHub Action workflow. These PRs are squash merged and make for a (hopefully) readable main branch.

In the future, I might even be able to automate this to help with release notes.

Strive for database precision.

Be detail-oriented when building out your database tables.

If something can not be null, be explicit NOT NULL.

If a string can be really long, use :text. If you do use :string (which has length limits), then enforce those length limitations in Ecto.Changeset so the value is not trimmed quietly.

Virtual fields on Ecto schemas are almost never the right answer.

That was quite the hodgepodge of suggestions and tips. I had others, but they did not fit, or I don’t have good open source references yet.

If you liked these or disagree, let me know.

LiveView Modules Must End in `Live`

mike@mikezornek.com (Mike Zornek) — Tue, 03 Sep 2024 20:32:57 -0400

When working with LiveView you’ll notice people naming modules with the suffix Live, as seen in module names like FlickWeb.Ballots.IndexLive or FlickWeb.Vote.VoteCaptureLive.

A student I was mentoring once asked me what that Live suffix was for and if it was required.

We drafted some simple LiveView demos with modules that did not end in Live, and things worked fine. I had a gut feeling that this was required, but I could not put my finger on it.

Today, I was reminded when and why you need the Live suffix.

When using the live/4 router macro, you can optionally include an action like :new and :edit as seen in the examples below.

live "/ballot/new", Ballots.EditorLive, :new
live "/ballot/:url_slug/:secret/edit", Ballots.EditorLive, :edit

This action name will be available in the live view’s socket.assigns.live_action and can be a helpful signal when you are utilizing a live view for multiple purposes, such as a form for creation or a form for mutation, depending on the URL.

Should you use action names, your LiveView must end with Live. If it does not, you’ll see a compiler error like:

== Compilation error in file lib/flick_web/router.ex ==
** (ArgumentError) could not infer :as option because a live action was given
and the LiveView does not have a "Live" suffix. Please pass :as explicitly or
make sure your LiveView is named like "FooLive" or "FooLive.Index"
  (phoenix_live_view 0.20.17) lib/phoenix_live_view/router.ex:479: Phoenix.LiveView.Router.inferred_as/3
  (phoenix_live_view 0.20.17) lib/phoenix_live_view/router.ex:409: Phoenix.LiveView.Router.__live__/4
  lib/flick_web/router.ex:36: (module)

Looking over the related source code I kind of suspect this assumption could be removed in the future, but seems like a low impact and pain level so, meh.

I am happy to rediscover and document this. Hopefully, the explanation was helpful.

Announcing my New Full-Time Job

mike@mikezornek.com (Mike Zornek) — Mon, 27 Nov 2023 18:05:27 -0500

I have some big news: Starting December 4th, I’ll be working full-time as a Senior Elixir Developer for Allovue, where they build web-based accounting software for school districts.

This change is particularly significant because I’ve been self-employed as a freelance consultant for most of my career.

Frankly, finding consistent Elixir contracts over the last 18 months has been challenging. I’ve had some ongoing client work, but I have generally described the situation as underemployed to friends and family. While I continue to enjoy Elixir, compared to my historic iOS and Rails contracting, I found companies preferring full-time employees or more extensive consultancy team assignments. Sometimes, I was lucky enough to get subcontracts for such teams, but being outside of those relationships disadvantaged me.

With that context, I started to keep an open mind and consider different job openings a few months ago. When it came to Allovue, I felt aligned with what they were doing and looking for. The interview process took some time, and I kept my expectations in check because you never really know how these things will turn out.

When I eventually got the offer and considered all my observations about the opportunity, it was a good fit. My primary responsibilities will include:

Mentoring the junior contributors.
Owning individual threads of Elixir and LiveView work.
Helping explore larger product and architecture decisions.

I’ll share more as things get going. It’s going to be an exciting new year for sure.

Shutting Down ElixirClub

mike@mikezornek.com (Mike Zornek) — Tue, 04 Jul 2023 12:00:00 -0400

After six months, today I announced ElixirClub’s closure. For context and for those many souls who did not know:

ElixirClub is (was/hopped to be) an outcome-oriented community that helps Elixir developers finish their side projects.

I ran the site on Circle, hosted some weekly events and async project update threads – but the hard truth is that I was not able to create even the modest-sized community that I was aiming for.

There are reasons and lessons to be learned about pricing, pitches and what not. Ultimately it was very niche target and did not have a strong marketing angle.

I thought it was best to close it down, issue refunds (automated and manual) as best I can and move on. To what? I have no idea.

There is a awful bad taste anytime you put you and a side project of yours out there, …and it fails.

It’s been many years since I had a solid side project win and I’d be lying if I did not also share, I feel like I’ve lost some of the side project drive I’ve had in the past.

I am trying to “just keep swimming” as it were and even today have a new little side project in the wings, but I’m really hoping for a win soon™.

Elixir Rap Song

mike@mikezornek.com (Mike Zornek) — Tue, 14 Mar 2023 14:43:35 -0400

Had too much fun asking ChatGPT to generate haiku poems and rap songs about programming tools and languages. Here is one about Elixir.

Compose a rap song about how much programmers love the functional programming language Elixir.

Verse 1:
Listen up y'all, let me tell you 'bout a language that's dope
It's called Elixir, and it's more than just a little bit of hope
It's functional programming, and it's built to scale
You can build web apps, IoT, and anything else you wanna unveil

Chorus:
Elixir, Elixir, it's the language of the gods
Programmers love it, they're never gonna stop
With its easy syntax and its powerful tools
Elixir's the one that rules, yeah, Elixir's the one that rules

Verse 2:
Elixir's got it all, from concurrency to fault tolerance
And the syntax is so sweet, you'll never want to go back to nonsense
It's got pipes, macros, and pattern matching too
Elixir's so efficient, it's gonna make your code dreams come true

Chorus:
Elixir, Elixir, it's the language of the gods
Programmers love it, they're never gonna stop
With its easy syntax and its powerful tools
Elixir's the one that rules, yeah, Elixir's the one that rules

Verse 3:
So if you want to build something that's fast and robust
Elixir's the language that you can trust
You can build real-time apps and scale with ease
Elixir's the future, it's the one that's gonna please

Chorus:
Elixir, Elixir, it's the language of the gods
Programmers love it, they're never gonna stop
With its easy syntax and its powerful tools
Elixir's the one that rules, yeah, Elixir's the one that rules

Outro:
So now you know why programmers love Elixir so much
It's the language that's got the perfect touch
If you're not using it yet, you're missing out
Elixir's the future, it's what programming's all about.

Elixir Context Accessor Function: Which Return Type Do You Prefer?

mike@mikezornek.com (Mike Zornek) — Sun, 12 Feb 2023 13:55:42 -0500

During a recent Elixir Book Club meeting we had a back and forth discussion on a simple code style question:

When providing an accessor function inside your domain context, do you prefer a return type of {:ok, noun} || {:error, :not_found} or noun || nil ?

In my own historical work I’ve generally followed along with common Phoenix generator style of building out functions like get_noun/1 that return the noun or nil but moving forward I think I’ll be preferring fetch_noun/1 functions that use an :ok / :error tuple style return type.

The primary reason is expressiveness in the crash logs. Eventually there will be some crash and the stacktrace is going to show nil being passed into some function, and the function having an expectation of a real value type. In those moments it can take some time to understand where the hell nil is coming from. I think an error like noun_not_found will be more helpful.

I want to start keeping track of these personal preferences and so today I’ve also made a new guide for the Franklin project documenting Code Style: Context Accessors. There is some more background and reasoning about my preferences inside should you be interested.

While that guide expresses a preference towards fetch_noun/1 and the :ok / :error tuple return type, it also acknowledges that it might be helpful and supportive for the context to offer multiple accessor functions allowing the call sites to use whichever one is more appropriate. ` How about yourself? What return type do you prefer and why? Let me know.

A New Project: ElixirClub

mike@mikezornek.com (Mike Zornek) — Sun, 27 Nov 2022 21:14:14 -0500

Today I am announcing a new project of mine taking shape. It’s called ElixirClub.

ElixirClub is an outcome-oriented community that helps Elixir developers finish their side projects.

Working on a side project by yourself is surrounded by risks:

personal loss of focus
no accountability
endless time extensions
exploding scope

Even a completed side project might be considered a failure if it does not find its audience or fails to provide a reasonable return on your time investment.

ElixirClub is a community where people can plant their flag, declare their side project goals, and meet fellow Elixir developers climbing the same mountain.

Through a mixture of accountability, education, and celebrations, you’ll be part of a group that fosters successful habits to an ultimately successful side project.

What to expect as a member?

All the below community heartbeats are designed to help you shape the work needed to see your side project to its planned completion and build a habit loop for regular progress.

✅ Weekly async project check-ins to share wins, plan next week’s work and ask questions.
📅 Weekly live coworking sessions, offering a mix of face-to-face accountability and dedicated mic-off time-boxed work time.
📺 Themed live (and recorded) events around side project management concerns and Elixir-specific programming interests.
📝 Written guides and suggested tasks to wrangle your project and find your flow.
🤝 A code review trading board that allows members to exchange code reviews.

Membership to the community will require a modest monthly subscription. This choice helps pay for the community software, helps people solidify their dedication to their projects, and helps fund my work creating content for the group.

Right now, my priorities are to chat with folks who are good candidates for such a group and work at preparing a productive home to host everything.

If you would like to hear more about this in the future, please email me mailto:zorn@zornlabs.com?subject=ElixirClubSubscribe, and I’ll add you to my manual notification list.

If you are really excited about the group, please reach out and book some time on my calendar: https://savvycal.com/zorn/chat – I’d love to hear what side project you are working on.

Elixir Book Club: Testing Elixir, Starts November 13th

mike@mikezornek.com (Mike Zornek) — Sun, 30 Oct 2022 11:48:17 -0400

I am pleased to share the reboot of the Elixir Book Club.

Starting Sunday, November 13th at 10:30am (Eastern Time), we’ll meet for an hour via Discord to talk about our next book…

Testing Elixir

Testing Elixir Book Cover

https://pragprog.com/titles/lmelixir/testing-elixir/

I read this back in April of 2021 and thought well of it. It’s a good overview of the various testing tools available and how to apply them to Elixir scenarios and patterns (OTP, Ecto, Phoenix).

During the first meeting will review chapters 1 and 2. After that, we will meet to review two or so more chapters every two weeks.

To participate, you’ll need to join the Elixir Book Club Discord, and shortly I expect the main book club website to be current with our new book and dates.

Extra Credit?

If you are interested in software testing, I HIGHLY recommend this other book as well: Unit Testing Principles, Practices, and Patterns.

Unit Testing Principles, Practices, and Patterns Book Cover

https://www.manning.com/books/unit-testing

Where Testing Elixir will help you learn the tooling and explain the how, Unit Testing Principles, Practices, and Patterns will help you discover the why and ultimately assist you in crafting a resilient testing strategy for your projects.

I read this book in June 2022, and it hugely influenced me and how I want to test moving forward. It could serve as a great companion or follow-up book for people in our club, though the club’s focus is officially and exclusively on Testing Elixir.

Hope to see you at the book club!

Closing Thoughts on my Exercism Video Project

mike@mikezornek.com (Mike Zornek) — Mon, 24 Oct 2022 16:34:58 -0400

It was August 2, 2022, when I recorded the first video and blogged about my Exercism Elixir video project. I decided to join an upcoming cohort that would be working through the Elixir track on Exercism, a place to learn programming languages via coding challenges. I decided to video record myself working through the exercises, hoping to share the experience with others.

And now it’s all done! I posted my final “Learning Exercise” video on October 19, 2022. I unlocked the full Elixir syllabus and consider the project closed (for now).

Not overlooking an opportunity to recap the project, I figure I’ll capture a few thoughts to celebrate.

First, it feels incredible to FINISH something. I’ve had many project stall or otherwise end in a disappointing manner. Being able to see this through was very fulfilling.

I chose the project scope with meaningful intent. I wanted something more than a weekend but not longer than a few months. Technically this took about ten weeks with some vacation and moving distractions mixed in. It turned out to be a pretty good length of time.

The cohort was ok. We had a shared Discord server and encouraged daily check-ins and questions. People did help each other, but I feel like there was a lost opportunity to get more face time events. I attended a few video meetings, but they were more presentations than socializing. It’s a shame I didn’t make a stronger connection with anyone. Hard to do that over text-only chat. In the end, they did post a survey, and I recall sharing some suggestions. With luck, they will continue to mature the cohort idea and offer other languages.

Recording the videos was more stressful than expected. A handful of exercises stumped me, and the sessions would go long. Even the simple sessions went pretty long. I would not expect many people to sit through those unless they were notably stuck on an issue and found the video matching an exercise title. I know at least one person who did; he mentioned he recognized me during a Dockyard Academy call and shared as much. That was pretty cool.

As I consider more video content, I must condense the value better. If I do record longer sessions (or streams?) I should break out clips as the primary form of sharing and less so the full archive.

For now, I consider the project closed and will focus on other things. I could see myself coming back to work on more exercises someday. There are a ton. I completed 40 of them to unlock the syllabus, and there are still 116 available. My hat off to anyone who finishes all of them.

Exercism Elixir Track: Take-A-Number Deluxe (GenServer)

mike@mikezornek.com (Mike Zornek) — Wed, 19 Oct 2022 16:19:28 -0400

In today’s Exercism Elixir Track video, we learn about GenServer while completing the Take-A-Number Deluxe exercise.

Exercism Elixir Track: RPN Calculator Inspection (Links and Tasks)

mike@mikezornek.com (Mike Zornek) — Tue, 18 Oct 2022 12:27:46 -0400

In today’s Exercism Elixir Track video, we learn about Links and Tasks while completing the RPN Calculator Inspection exercise.

Exercism Elixir Track: Dancing Dots (Behaviours and Use)

mike@mikezornek.com (Mike Zornek) — Mon, 17 Oct 2022 15:36:56 -0400

In today’s Exercism Elixir Track video, we learn about Behaviours and Use while completing the Dancing Dots exercise.

Exercism Elixir Track: Lucas Numbers (Streams)

mike@mikezornek.com (Mike Zornek) — Fri, 14 Oct 2022 11:56:22 -0400

In today’s Exercism Elixir Track video, we learn about Streams while completing the Lucas Numbers exercise.

Exercism Elixir Track: Stack Underflow (Exceptions)

mike@mikezornek.com (Mike Zornek) — Tue, 11 Oct 2022 11:52:35 -0400

In today’s Exercism Elixir Track video, we learn about Exceptions while completing the Stack Underflow exercise.

Exercism Elixir Track: New Passport (With)

mike@mikezornek.com (Mike Zornek) — Mon, 10 Oct 2022 12:01:02 -0400

In today’s Exercism Elixir Track video, we learn about With while completing the New Passport exercise.

Exercism Elixir Track: RPN Calculator (Errors and Try/Rescue)

mike@mikezornek.com (Mike Zornek) — Fri, 30 Sep 2022 14:05:42 -0400

In today’s Exercism Elixir Track video, we learn about Errors and Try/Rescue while completing the RPN Calculator exercise.

Exercism Elixir Track: Need For Speed (Alias and Import)

mike@mikezornek.com (Mike Zornek) — Thu, 29 Sep 2022 13:31:02 -0400

In today’s Exercism Elixir Track video, we learn about Alias and Import while completing the Need For Speed exercise.

Some Early Thoughts on LiveView Native

mike@mikezornek.com (Mike Zornek) — Mon, 26 Sep 2022 08:00:00 -0400

This weekend I finally had some time to experiment with LiveView Native, working through the introduction tutorial during a Side Project Saturday event run by my local Apple developer group. After working through the tutorial, I demoed the results to my Apple friends. We had some great discussions about the pros and cons of the approach. Those discussions locked in some of my early hot takes, and in this post, I’ll try to capture and share some of my early thoughts and concerns.

What is LiveView Native?

LiveView Native is a project that aims to empower exsiting LiveView developers with the ability to deploy native applications using LiveView, with an initial focus on iOS and Android apps.

There are a lot of technologies at play, so I’m going to take a moment to summarize the players involved:

Elixir is a functional programming language that runs in the Erlang/BEAM virtual machine. This runtime excels at providing concurrent and fault-tolerant systems.
Phoenix is a popular framework used to build web applications in Elixir.
LiveView is a feature of Phoenix that lets people build interactive, real-time, and collaborative web experiences. It leans on an architecture where a websocket keeps the browser connected to a process on the server. As a user interacts with the page, events are sent to the server process, and then a declarative/reactive UI is updated based on the new process state.
Swift and SwiftUI are the primary programming language and UI framework pair for building modern/native iOS applications.
Kotlin and Jetpack Compose are the primary programming language and UI framework pair for building modern/native Android applications.
React is a frontend JavaScript framework used to create single-page web applications, a competitor to LiveView.
React Native is a framework used to build React-powered apps inside a web view wrapper running on iOS and Android. Because of its web view wrapper, React Native is known to be memory expensive and sometimes exhibit sluggish performance.
- Correction: I’ve been corrected by friends that “[React Native] doesn’t run inside a web view, but instead renders native iOS/Android views.” and thus my ignorance spotlighted. I feel like I got my understanding of this via as the comparison of LiveView Native using “native views” and React Native using “web views” so I want to walk back and try to be accurate and say once again, I don’t use these frameworks and I do not know what I am talking about.
- Update 2: This seems like a fair technical review of how React Native works.
Dart and Flutter are a programming language and UI framework pair that lets you build cross-platform mobile applications. The unique take of Flutter is that it does all of its own UI drawing, allowing for a much more controlled and speedy UI render. It can use component libraries to emulate its host OS, with varying degrees of success (re: uncanny valley effect).

Now, with all that said, what is LiveView Native?

In a traditional LiveView, we have a server process and a client web browser. The LiveView renders a template of HTML influenced by the process state and sends it down the wire. As new events are processed and the state changes, very terse diffs are sent to the client browser, allowing the user’s UI to be updated.

LiveView Native substitutes the client web browser for a native client view running on iOS or Android. Instead of writing templates in HTML, we write them in SwiftUI or Jetpack Compose. LiveView will continue to own responsibility for figuring out the view diffs while the mobile apps will render these SwiftUI or Jetpack Compose views just like they would if built more traditionally.

There is no web view like you’d see in a React Native app, nor is there any new UI framework like you’d see in Flutter.

It’s a unique take on the problem that unlocks potentially impressive solutions, but like any technology, you must understand your compromises.

Worlds Are Colliding!

I’ve been working with Elixir since 2017 and LiveView since it was announced in 2019. Before Elixir, I spent more than a decade doing Apple platform development, first on the Mac and then on the iPhone. By the end, I was teaching iOS programming classes at places like Amazon and Google via my job at Big Nerd Ranch. So when this announcement came out, I felt like worlds were colliding and said as much.

I have many historic pessimistic opinions on multi-platform frameworks that try to sell “write once, deploy everywhere.” I’ll get into some of those later, but first, I’ll share my tutorial observations.

My Day with LiveView Native

During the first half of Side Project Saturday, I worked through the Your First LiveViewNative App tutorial. This tutorial has you build both a Phoenix project and an iOS project.

In the Phoenix project, you build a CatsListLive live view with SwiftUI-specific heex template content.

In the iOS project, you’ll add some of the LiveView Native package dependencies and then configure the default ContentView to load the swifty LiveView view class, which points at a localhost:4000 URI via configuration.

When you launch the iOS app, the LiveView view class inside of SwiftUI will connect to the Phoenix server, which makes a live view server process for CatsListLive and then sends down the template. When received inside of iOS, the view hierarchy is injected, and then regular old SwiftUI will render it just as if it had complied typically.

You may notice that the SwiftUI code templated in heex has things like phx-click="toggle-favorite". When the button is “clicked” in the iOS app, the event is sent via the websocket to the live view process on the server, the state is updated per standard LiveView lifecycle mechanics, and then the template is re-rendered, and diffs are applied.

Another interesting thing in the demo is the use of navigationlink and traditional Phoenix routes and redirects to handle the “NavigationController” like push and back button behavior all iOS users are accustomed to.

Once I completed the tutorial, I presented the project to my peers. As I expected, there was general curiosity about how it worked compared to other multi-platform solutions (like React Native and Flutter). We clicked around the LiveView Native dependencies and reviewed how things were being built. I explained how the view diffs were very tight and not just some text-based XML diff. They asked questions about other SwiftUI view modifiers and how animations would be handled, which I did not know yet.

There was also a reaction of “this feels like a lot of complexity with many failure points” and “is this worth the complexity cost?” For them, I think that is an expected response. These people have embraced Apple platforms and are already building with Swift and SwiftUI. They have no appetite for learning Elixir, Phoenix, or LiveView for this new way to run an app or any genuine appreciation for the unique niche it can solve (real-time and collaboration experiences).

However, this tool is not really built for them. So who is this being built for? Time for hot takes.

What pain is LiveView Native is trying to solve?

The marketing site for the project states:

LiveView Native empowers developers to build native and web applications seamlessly with Phoenix. Now there’s no need to manage multiple teams or juggle multiple frameworks: The same developers can manage both, cutting down delivery timelines and freeing up resources to focus on innovation.

Given my experience, I find this statement to be suspect.

Any developer trying to build a LiveView Native app with no historic native mobile development experience will need to overcome a significant list of concerns.

They will need to compose templates with pseudo-SwiftUI/Jetpack Compose layout code. These UI/layout frameworks are drastically different from the HTML/Tailwind layout code they use. It’s a steep learning curve.
They will need to work around the lack of client-side JavaScript events (coming soon, maybe?). They may miss the inability to leverage existing JavaScript solutions already in use in their current LiveView solutions.
They will need to resolve offline experiences and real-world spotty connectivity/reconnection issues for phones in buildings/tunnels/elevators. (This is true of web-based LiveView as well.)
They will need to overcome the complexities of the Xcode and Android Studio IDEs, both extremely deep topics.
They will need to learn all the trials and tribulations of app store review and deployment. This may be the most significant risk (see below).
They will encounter harder-to-debug problems because of the complexities of this stack. There is no browser console to inspect/change things. Debugging is very different in Xcode/Android Studio.

I’ll also add that I have many friends already working in SwiftUI natively in Xcode daily. While SwiftUI can provide an unexpected boost to productivity for basic needs, there is a point where it falls down, and it is not easy to compensate for. If you observe the iOS developer community, this is a massive point of conflict and discussion. Depending on your LiveView Native layout’s complexity, you might be in for a world of pain.

Will Apple approve this?

I hate app store review and distribution exclusivity. It was one of the primary reasons why I left the platform years ago.

My concerns around “will Apple approve this?” was one of the first questions that came to mind watching the ElixirConf keynote announcement. The fact DockYard had already gotten an ElixirConf chat app through review was impressive, but unfortunately, past review approval does not guarantee future outcomes. I’ve seen many apps approved for years that suddenly get blocked for doing something they’ve always done.

Looking at the App Store Review Guidelines, we find section 2.5.2, which states:

2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.

The fact that we are editing the UI in real-time, potentially adding, removing, or changing features, feels like we violate this section.

However, if you search the web, you’ll find plenty of posts talking about iOS server-driven UI and even this recent conference talk that explains:

Companies like Airbnb, Spotify, Flipkart, Swiggy and several others use a technique called Server Driven UI, which allows them to remotely update their user interfaces based on the response received from the server. This allows them to bypass the review process and keep their apps sync on multiple platforms.

In this session, you are going to learn how to get started with building a server driven UI in iOS.

So I don’t know. 🤷‍♂️ It’s one of those things Apple keeps vague and open to interpretation. Having chosen to leave the platform because of these controls, I am incredibly hesitant to return and bet my business on app store whims.

Conclusions

LiveView Native is an interesting project with a unique take on the multi-platform framework problem space. I have doubts it can overcome the “lets LiveView people do mobile without knowing mobile” shtick, but I am happy to be proven wrong.

I don’t plan to be too active around the project (have no interest bowing down to Apple for app approvals ever again) and instead will invest my LiveView learning time into the new component attributes / UI library opportunities.

Based on my podcast listening habits and general community awareness, LiveView Native is a significant project for the LiveView community. I expect many to tinker with this in the coming months, and I look forward to reading their blog posts and findings.

PS: I hope people don’t take my positioning concerns about the project as a personal attack. The tech itself is very impressive. I fear this project won’t be able to honor the simplicity promise it is being promoted with. Teams who DO accept the extra complexity and tradeoffs of this “stack” may be empowered to build software that would otherwise take more time – it’s just there is no free lunch; they will still have to know a lot about mobile development to do so.

Random Leftover Draft Notes

I recorded a companion video walking through some of the code:

One company that comes to mind for this sort of thing is Sketch. They build a native Mac experience AND lean on websockets with an Elixir backend to enable a real-time collaborative experience. They do not use LiveView but do benefit from the BEAM.
I was disappointed with Xcode that when I copied/pasted Swift code from the tutorial into Xcode, it did not run a code formatter on save. My friends say you can configure plugins to help with that, but wow, I’m bummed that it hasn’t been defaulted by Xcode/Apple yet.
When composing SwiftUI templates in a heex file, we intentionally use things like phx-click, which make sense given the goals of the project. Still, I can’t help but note that when I was a mobile app developer, most frameworks took pride in using terms like “touch” and “tap,” so it can feel odd to see “click” in this space. Seeing people say “click” was always a smell that something did not belong. Like when people say Iphone or xCode.
One niche I think is perfect for Flutter is when you want to build a very styled/themed UI and want it to be the same across iPhone/Android. Things like video game menu UIs or brand/movie tie-in things.
It was neat to see the LiveView Native team use Apple’s own DocC tutorial template tooling. I was aware this was out but had not seen it firsthand.
One pro for LiveView Native is that it does have a path to migrate to traditional SwiftUI should the project benefit from a more conventional approach. That is not true of the others.

Exercism Elixir Track: Captain's Log (Erlang Libraries, Randomness)

mike@mikezornek.com (Mike Zornek) — Fri, 23 Sep 2022 13:36:32 -0400

In today’s Exercism Elixir Track video, we learn about Erlang Libraries and Randomness while completing the Captain’s Log exercise.

Exercism Elixir Track: Bread And Potions (Protocols)

mike@mikezornek.com (Mike Zornek) — Thu, 22 Sep 2022 11:32:09 -0400

In today’s Exercism Elixir Track video, we learn about Protocols while completing the Bread And Potions exercise.

Exercism Elixir Track: Community Garden (Agent)

mike@mikezornek.com (Mike Zornek) — Wed, 21 Sep 2022 11:41:57 -0400

In today’s Exercism Elixir Track video, we learn about Agent while completing the Community Garden exercise.

Exercism Elixir Track: Boutique Suggestions (List Comprehensions)

mike@mikezornek.com (Mike Zornek) — Tue, 20 Sep 2022 11:07:10 -0400

In today’s Exercism Elixir Track video, we learn about List Comprehensions while completing the Boutique Suggestions exercise.

Exercism Elixir Track: Remote Control Car (Structs)

mike@mikezornek.com (Mike Zornek) — Mon, 19 Sep 2022 10:45:55 -0400

In today’s Exercism Elixir Track video, we learn about Structs while completing the Remote Control Car exercise.

Exercism Elixir Track: Chessboard (Ranges)

mike@mikezornek.com (Mike Zornek) — Fri, 16 Sep 2022 12:23:28 -0400

In today’s Exercism Elixir Track video, we learn about Ranges while completing the Chessboard exercise.

Exercism Elixir Track: Newsletter (File)

mike@mikezornek.com (Mike Zornek) — Wed, 14 Sep 2022 13:25:01 -0400

In today’s Exercism Elixir Track video, we learn about the File module while completing the Newsletter exercise.

Exercism Elixir Track: Top Secret (AST: Abstract Syntax Tree)

mike@mikezornek.com (Mike Zornek) — Tue, 13 Sep 2022 11:44:14 -0400

In today’s Exercism Elixir Track video, we learn about AST (Abstract Syntax Tree) while completing the Top Secret exercise.

This exercise was a tougher one for me. I cut out a bunch of head scratching, but it still ended up being almost an hour. Ugh.

Exercism Elixir Track: File Sniffer (Binaries)

mike@mikezornek.com (Mike Zornek) — Mon, 12 Sep 2022 16:15:55 -0400

In today’s Exercism Elixir Track video, we learn about Binaries while completing the File Sniffer exercise.

Exercism Elixir Track: Boutique Inventory (Enum)

mike@mikezornek.com (Mike Zornek) — Sat, 10 Sep 2022 14:41:52 -0400

In today’s Exercism Elixir Track video, we learn about Enum while completing the Boutique Inventory exercise.

Exercism Elixir Track: Basketball Website (Access Behaviour)

mike@mikezornek.com (Mike Zornek) — Wed, 07 Sep 2022 17:07:30 -0400

In today’s Exercism Elixir Track video, we learn about Access Behaviour while completing the Basketball Website exercise.

Exercism Elixir Track: Take-A-Number (PIDs and Processes)

mike@mikezornek.com (Mike Zornek) — Tue, 06 Sep 2022 11:14:37 -0400

In today’s Exercism Elixir Track video, we learn about PIDs and Processes while completing the Take-A-Number exercise.

Exercism Elixir Track: Library Fees (Dates and Time)

mike@mikezornek.com (Mike Zornek) — Mon, 05 Sep 2022 11:57:33 -0400

In today’s Exercism Elixir Track video, we learn about Dates and Time while completing the Library Fees exercise.

ElixirConf Recap

mike@mikezornek.com (Mike Zornek) — Sun, 04 Sep 2022 13:25:37 -0400

This past week I attended ElixirConf in Colorado. It was my first time out at an in-person conference since COVID lockdowns. As much as I hated the travel, it was great to see everyone.

I got a lot of face time with a handful of people I had worked with over the last two years and a bunch of others whose company I have enjoyed via online meetups, book clubs, and Twitter. Even a tiny in-person conversation adds an extra level to those ongoing “online peer relationships,” and I’m happy to have made many new connections.

* Yes, it would seem many Elixir companies are still hiring; though I’d say only half the talks mentioned that when historically, maybe 75% of the talks would so 🤷‍♂️ maybe there is a slight dip.

For more photos, check out this album started by Todd Resudek.

The conference content was fantastic, almost overwhelming.. I’ll note a few big takeaways below, but a complete review would be quite extensive and is out of scope for this post.

LiveView Native – Brian Cardarella of DockYard shared a new project that aims to provide a way to build mobile applications that can act as a LiveView client. Using this, you can connect a mobile application to a LiveView process on the server and then render native views based on heex templates, intermixing LiveView Native view renders with “normal” platform views (such as SwiftUI used in the demo). More info can be found on the LiveView Native marketing site, GitHub project, and related Hacker News thread. It is still pretty early tech but has a lot of people buzzing. I’ll share more thoughts after I get a chance to kick the tires.

Elixir 1.14 is out! It includes Kernel.dbg/2, a new macro for debugging, PartitionSupervisor for handling some bottleneck scenarios, improved errors on binaries and evaluation, slicing with steps, expression-based inspection and more.
Phoenix 1.7 is immanent. It will include verified routes and component properties. It also has Tailwind built-in as the default. Chris also shared a roadmap for future work which included plans to integrate some aspects of the phx_live_storybook project as well as a rethink of LiveView/Component messaging (which was a point of issue Miki Rezentes brought up in her talk and I’m in total agreement with – right now it’s a bit clunky).
I had an excellent time in my telemetry class on Tuesday. Still have to finish my last lesson, but I had some beneficial experiences adding custom events and attaching common library events through a informative collection of sample projects.
I sat in on many sessions showcasing the continued evolution of Livebook. Nice to see this tool continue to mature and empower education and knowledge sharing.
Mark Ericksen did a presentation walking through some tools that can help make normal Ecto usage apply to a globally distributed database environment, as one would see on fly.io. I have not done a fly deployment (yet), but this is something I should check out.
juvet is a cool little in-dev framework for making Slack bots.
Kip Cole’s talk on Time Algebra and a new library called Tempo was an unexpected and impressive talk.
David Bernheisel is preparing a paid-for extension to his Ecto in Production resource. I can’t wait to support it.
Owen Bickford talked about his new WebAuthn LiveView component, which simplifies integrations that want to lean on this new auth tech. Looks extremely useful, and as iOS starts to promote PassKeys, I think many will seek this out.
And a lot more which I don’t have time to document.

Conferencing during COVID is stressful. I masked up aggressively during the plane trip to and from the show. I did not mask while attending. Most people did not mask. I’d guess maybe 5% did mask.

The big value of the show for me was socializing with people, from hallway chats to lunches and even some code pairing. Masking during these interactions would have been a notable hindrance. I have a hard enough time hearing people with my bad ear in these rooms, let alone adding a mask to my own voice (or theirs). If the conference required masking or if I observed a community norm, I was prepared to do so, but in the end, I did not. I’ll live with that outcome, keep an eye out for symptoms, and take an at-home test over the next few days. Bummed this stress point is even here, but those are the cards we are dealt.

The last takeaway I’ll note is a personal observation I need to return to sharing. As an iOS developer, I did many presentations and conference talks but have not mirrored this behavior with my presence in the Elixir ecosystem. In part, during the early years, it was mostly imposter syndrome – as an Elixir newbie, who am I to tell these people anything – but those days are past, and I really need to start giving back some.

I expect the ElixirConf videos to be shared publicly on YouTube in the next few months. Keep an eye out for more info on their channel.

ElixirConf Talks of Interest

mike@mikezornek.com (Mike Zornek) — Mon, 29 Aug 2022 16:38:56 -0400

I’m attending ElixirConf this week, and in preparation, I looked over the session schedule to see what talks are of interest to me. I figured I’d share my notes in case anyone is curious about what’s on my mind. If you are also in attendance, please say hi.

https://2022.elixirconf.com/schedule

Tuesday

Tuesday is the training day. I picked Instrumenting Elixir Applications.

I’ve been on projects using observation tools like open telemetry and DataDog but have never been personally responsible for setting it up, so I have a lot to learn.

Wednesday

Wednesday starts with a curious “virtual-only” morning session list. I think this was done to allow the sister NervesConf “sub-conference” to do its thing in the meeting spaces. I am not attending, so will most likely look to watch some virtual sessions in the hotel lobby and make friends with other stragglers.

After José Valim keynote, we have tracks of three topics:

Robust, Distributed, and Parallel Processing for Enormous Images Using SuperVisor, Node, Flow, Nx, and evision.
Porting Legacy Backend Services into Elixir, Seamlessly
Building a HEEX component library

I’ll be attending the HEEX component library talk. Improving my skill set at building components is high on my interest list right now, and I’m curious to see what Matthew has to share.

I’m likely to watch the recording of the Porting Legacy Backend Services later as that is also something of interest to me. So often, I try to encourage people to avoid the big rewrite, and this sounds like a good match for that since the summary includes “while keeping the user experience the same during the whole migration process.” 👍

I don’t have a current need for scalable image processing but will keep the talk recording in mind in the future.

Next up:

Livebook smart cells are amazing
Classifying Bot IP Addresses in Phoenix
The Elixir Of Web Scraping

I think I’ll be going to the Livebook talk. I’ve only done some basic Livebook writing in the past, but I have some ideas about building LiveView/collaborative UX demo tools and it would be helpful to see what’s new.

The other talks sound useful but are not active topics for me right now.

For the final Wednesday morning choices, we have:

Make a Soundcloud like app in a week and make it fit in a seven dollar box
Dx - a pragmatic inference system based on your Ecto schema
Cryptography and Elixir

I’ll be attending the Soundcloud app talk. Curious to hear how that project has progressed and very interested in the topics around file uploading.

After lunch, we have two choices:

Ecto in Production - Migration Edition
Let’s talk to Industrial devices with Elixir & Nerves

I’m not doing an IoT or Nerves stuff, so this is an easy call for me. Improving large-impact Ecto migrations is a welcome focus, particularly given my client’s data sizes.

Next up:

Delightful Multiplayer Editing with Phoenix
Workflows and use cases for Elixir Nerves

Anxious to see how the Felt team is doing UI collaboration. This is one of the big reasons a project should choose Phoenix LiveView. It’s a great fit.

Next up:

Going Global with a Normal Phoenix App
Keeping your IoT fleet afloat with Sink

I’m curious to hear how Fly.io deployments are working out and will surely appreciate people sharing their edge cases and other considerations.

Next up:

Match Specs: Fast Functional Filtering with Matcha
Introducing Juvet: Building Bots in Elixir

That Match Specs talk seems too deep so for me. The Juvet one sounds interesting. Some of my product ideas are tools to make Slack more reasonable, so bot programming seems like a topic I would enjoy.

Wednesday’s final sessions:

Time algebra - a new way to think about and work with time
Making Elixir Honk: Implementing An Elixir Audio Library In Zig

I’m interested in both of these talks, though I’ll probably give the audio talk my attention. I’ve worked alongside Chris and am curious about what he has come up with. Also, have a passive interest in continued interest in Zig and what people are up to.

Thursday

Thursday starts with a morning keynote from Brian Cardarella.

Afterward, session tracks start with:

Onboarding New Elixir Members
In Production with Elixir, Rust, and WebAssembly
Caching with the Postgres WAL

I’ll probably watch the recording of the WebAssembly talk and attend the onboarding talk. I’m less confident I’ll be doing education as a business moving forward, but I’m still big on mentoring and curious about what this talk has to share.

In-between sessions, Test Double is offering a “Double Up with Test Double” session, and I might stop by to say hi and get some advice on my CQRS project.

Next track choices include:

“How to Grow your own Juniors”: A guide to mentoring in an Elixir Environment
Quick Iteration in Elixir - Tips from 6 Years of Professional & Hobby Elixir Development
WebAuthn + LiveView

I’m interested in all of these talks, but WebAuthn is high on my interest level. I’ll be there.

Next up:

Selling Elixir
Seems Good Enough to Me: Working with Testers to Derisk Elixir Upgrades
Wordle: Elixir Flavour

I’m curious about these talks, but none are on fire for me. I might take this slot as an opportunity to mingle a bit. We’ll see.

Next up:

Roll Cages, Pit Stops, and Victory Laps: The Launch of Elixir and LiveView at Scale on the New Cars.com
Self Taught to First Job!
E2E Reactivity - using Svelte with Phoenix LiveView

As a contributor to the cars.com project, I’m anxious to see Zack’s retrospective.

Next up:

Axon: Functional Programming for Deep Learning
Serverless to Serving Elixir: Migrating Serverless app to run on Phoenix
Have you got the ExFactor? Writing a refactor helper

I’ll probably go to the refactor talk. Kind of curious how that project works, though again, I might use this time for mingling.

Next up:

SOLID code isn’t flexible
Using Livebook to Teach Elixir
Review of using Elixir for 4 years in production

Very anxious to see Brooklin Myers’s Livebook talk. I hear he is using it a ton in the upcoming DockYard class. The other talks look cool too but I will have to wait till the recordings.

Final tracks for Thursday:

Learn you some pattern matching for great good!
Connect the Docs
Shifting Left: Secure Coding in Elixir Livebooks

I’m interested in all of these talks, but the one on documentation is close to my heart, and I will attend.

Friday

Morning track choices start with:

To MVP and beyond, a year in LiveView
A Javascripter’s trip to Phoenix and LiveView
Exploring Elixir Codebases with Archeometer

Probably going to stop by the Archeometer talk. Curious to see what that project is all about.

Next up:

Flame On: Profiling Elixir and Phoenix apps with Flame Graphs in Live Dashboard
Designing Data Intensive Applications in Elixir with Flow
Understanding common network protocols with Elixir

I would like to try out that flame graph tool but will probably attend the Flow talk since it aligns with my event-sourcing interests.

Next up:

I was wrong about LiveView
Searching Your Elixir Code
Embedded Web Apps in Elixir with LiveState

I’ll probably sit in on Jason’s talk. While I like LiveView and think it’s an excellent choice for many projects, I’m not sure I’m as all in (as it sounds like he is). I still feel like if the app lends itself to request-response it can be better to embrace that simplicity, particularly for user-facing pages that are often presented on mobile phones.

The day closes with closing keynotes from Chris Grainger and then Chris McCord.

It feels like this is going to be a packed conference. While I’ve outlined talks that interest me, I need to remember that the value of going in person is seeing others, so if I have to skip out on some of these and catch the recordings, I think that is fine too. I suspect the recordings will have a quick turnaround since they are already doing the virtual component, but we’ll see.

Exercism Elixir Track: DNA Encoding (Bitstrings and Tail Call Recursion)

mike@mikezornek.com (Mike Zornek) — Sun, 28 Aug 2022 14:38:27 -0400

In today’s Exercism Elixir Track video, we learn about Bitstrings and Tail Call Recursion while completing the DNA Encoding exercise.

Today’s recording did not go nearly as bad as the Regular Expressions one but I still struggled with the Elixir Bitstring syntax and this took longer than needed. Bonus round of disappointment, you’ll get to see me with a haircut I did not like (and has since been ‘fixed’).

Exercism Elixir Track: Wine Cellar (Keyword Lists)

mike@mikezornek.com (Mike Zornek) — Fri, 26 Aug 2022 11:43:10 -0400

In today’s Exercism Elixir Track video, we learn about Keyword Lists while completing the Wine Cellar exercise.

Exercism Elixir Track: Log Parser (Regular Expressions)

mike@mikezornek.com (Mike Zornek) — Thu, 25 Aug 2022 13:26:42 -0400

This one went badly and took forever. I am awful with regular expressions and the lesson was painful for me to do. I can only imagine what it might be like to watch for others. However, in the spirit of transparency, here is the 1 hour 25 minute recording. Good luck with it.

In today’s Exercism Elixir Track video, we ATTEMPT to learn about Regular Expressions while completing the Log Parser exercise.

Exercism Elixir Track: Name Badge (If and Nil)

mike@mikezornek.com (Mike Zornek) — Wed, 24 Aug 2022 13:00:36 -0400

In today’s Exercism Elixir Track video, we learn about If and Nil while completing the Name Badge exercise.

Exercism Elixir Track: RPG Character Sheet (IO)

mike@mikezornek.com (Mike Zornek) — Tue, 23 Aug 2022 12:40:46 -0400

In today’s Exercism Elixir Track video, we learn about IO while completing the RPG Character Sheet exercise.

Exercism Elixir Track: German Sysadmin (Case and Charlist)

mike@mikezornek.com (Mike Zornek) — Mon, 22 Aug 2022 15:54:16 -0400

In today’s Exercism Elixir Track video, we learn about Case and Charlist while completing the German Sysadmin exercise.

Exercism Elixir Track: City Office (Docs and Typespecs)

mike@mikezornek.com (Mike Zornek) — Sat, 20 Aug 2022 14:38:17 -0400

In today’s Exercism Elixir Track video, we learn about Docs and Typespecs while completing the City Office exercise.

Exercism Elixir Track: Bird Count (Recursion)

mike@mikezornek.com (Mike Zornek) — Fri, 19 Aug 2022 10:54:32 -0400

In today’s Exercism Elixir Track video, we learn about Recursion while completing the Bird Count exercise.

Exercism Elixir Track: High Score (Maps and Module Attributes as Constants)

mike@mikezornek.com (Mike Zornek) — Thu, 18 Aug 2022 11:30:56 -0400

In today’s Exercism Elixir Track video, we learn about Maps and Module Attributes as Constants while completing the High Score exercise.

Exercism Elixir Track: High School Sweetheart (Pipe Operator and Strings)

mike@mikezornek.com (Mike Zornek) — Wed, 17 Aug 2022 12:24:27 -0400

In today’s Exercism Elixir Track video, we learn about Pipe Operator and Strings while completing the High School Sweetheart exercise.

Exercism Elixir Track: Kitchen Calculator (Pattern Matching and Tuples)

mike@mikezornek.com (Mike Zornek) — Tue, 16 Aug 2022 11:30:51 -0400

In today’s Exercism Elixir Track video, we learn about Pattern Matching and Tuples while completing the Kitchen Calculator exercise.

Exercism Elixir Track: Guessing Game (Default Arguments, Guards, and Multiple Clause Functions)

mike@mikezornek.com (Mike Zornek) — Mon, 15 Aug 2022 11:05:37 -0400

In today’s Exercism Elixir Track video, we learn about Default Arguments, Guards, and Multiple Clause Functions while completing the Guessing Game exercise.

Exercism Elixir Track: Log Level (Atoms and Cond)

mike@mikezornek.com (Mike Zornek) — Fri, 12 Aug 2022 15:05:52 -0400

In today’s Exercism Elixir Track video, we learn about Atoms and Cond while completing the Log Level exercise.

Exercism Elixir Track: Language List (Lists)

mike@mikezornek.com (Mike Zornek) — Thu, 11 Aug 2022 16:56:19 -0400

In today’s Exercism Elixir Track video we learn about Lists while completing the Language List exercise.

Exercism Elixir Track: Freelancer Rates (Floating Point Numbers and Integers)

mike@mikezornek.com (Mike Zornek) — Fri, 05 Aug 2022 13:14:55 -0400

In today’s Exercism Elixir Track video we learn about Floating Point Numbers and Integers while completing the Freelancer Rates exercise.

Exercism Elixir Track: Pacman Rules (Booleans)

mike@mikezornek.com (Mike Zornek) — Thu, 04 Aug 2022 11:16:06 -0400

In today’s Exercism Elixir Track video we learn about Booleans while completing the Pacman Rules exercise.

Exercism Elixir Track: Secrets (Anonymous Functions and Bit Manipulation)

mike@mikezornek.com (Mike Zornek) — Wed, 03 Aug 2022 11:50:51 -0400

In today’s Exercism Elixir Track video we learn about Anonymous Functions and Bit Manipulation while completing the Secrets exercise.

Exercism Elixir Cohort, New Video Series

mike@mikezornek.com (Mike Zornek) — Tue, 02 Aug 2022 19:39:16 -0400

Exercism, the popular platform that teaches programming via structured coding exercises, is going to be hosting a free August cohort for their Elixir track. They brand the endeavour an “Exhort”.

The Exhort is simple. We’ll give you and a bunch of other learners a space to learn together, add in some of our best mentors and Exercism experts, and support you as you work together through the Exercism Elixir syllabus over 30 days.

100% free

Starts August 8th. Lasts for 30 days.

Work through the track in your own time

Pair with each other or work as individuals

Commit to sharing your journey, and supporting others

I did a few lessons of the Elixir track last year when the new version of Exercism was launched and was impressed with how it all worked. The cohort sounds fun and a nice way for me to mingle with other looking to learn Elixir.

My plan is to record my work through the sessions and the first video / exercise is shared below.

For now I’m distributing these on my personal YouTube channel. The videos are pretty raw and longer than some historical educational content I’ve produced. I sharing my failures as well as my victories. It could be longer content than some might expect but I could see others enjoying seeing me work through the errors and typos too. We’ll see how it goes.

I also think the 30-day scope of the cohort helps me invest in the video series without worrying about a long-term content commitment to people. I’m still on the fence how I want to split my time in the coming months.

Elixir Style: Prefer Unnested Aliases

mike@mikezornek.com (Mike Zornek) — Fri, 01 Apr 2022 12:31:06 -0400

This post was originally written for my old ElixirFocus blog, and transfer here after its closure.

In Elixir, alias is a keyword we often use to create shorthand references to long-form module names allowing us to refer to RetroTaxi.Boards.Board simply as Board.

You’ll often end up with a collection of alias declarations at the top of a module, and Elixir offers two ways to format these.

One way is simple list such as:

alias RetroTaxi.Boards.Board
alias RetroTaxi.Boards.Column
alias RetroTaxi.Boards.TopicCard

The other way is an optional nested list like:

alias RetroTaxi.Boards.{Board, Column, TopicCard}

Sometimes this nested list is broken across separate lines and presented like:

alias RetroTaxi.Boards.{
    Board,
    Column,
    TopicCard
}

Style Recommendation

I highly recommend avoiding this nested presentation. The primary reason is to help keep the codebase plain-text searchable. By avoiding the nesting, you can quickly find which modules are referencing any module simply by searching for its name string like RetroTaxi.Boards.Column. Finding nested aliases would require a more complex regular expression or language server tooling.

If you want to enforce this style with a credo, check out Credo.Check.Readability.MultiAlias which is usually disabled on a default credo install.

Personal Phoenix 1.6 Upgrade Notes

mike@mikezornek.com (Mike Zornek) — Mon, 18 Oct 2021 12:00:00 -0400

This post was originally written for my old ElixirFocus blog, and transfer here after its closure.

Over the past few days I’ve been upgrading my projects to Phoenix 1.6 and like any project that comes out of a template-based generator, migrating a Phoenix project to a new version can be a little scary and error prone, particularly for people new to Elixir and Phoenix. Today I’ll share some personal notes and tips to hopefully make the process a little smoother.

Step 0: Skip the Manual Upgrade (Maybe?)

Depending on the scale and circumstances of your project you might consider just re-generating a new project using mix phx.new and bringing over your old code into the fresh template. I wouldn’t recommend this for any project that had meaningful git history or other collaborators, but for smaller personal projects it might be the path of least resistance.

You’ll probably want the new project generator regardless and can install it with:

$ mix archive.install hex phx_new

Step 1: Familiarize Yourself with the New Version

Before blindly attempting the upgrade it would be best to read the official blog announcement, review the project changelog and preview Chris McCord’s personal upgrade notes. You might want to also bookmark documentation for specific new features, like heex templates.

Step 2: Get Your Project is a Stable State

Make sure your project is building clean, the tests are passing and the typespecs are um, type spec-ing. Push your changes to remote and start a new upgrade-phoenix branch. It would be best if you work through the upgrade in chunks and verify these things as you go.

Step 3: Update Elixir and Project Dependencies

If you can, now is a good time to explicitly require Elixir 1.12 as the minimum version of your project. This is not an absolute requirement, but as described in the heex docs, it will improve your error messages:

Note: HEEx requires Elixir >= 1.12.0 in order to provide accurate file:line:column information in error messages. Earlier Elixir versions will work but will show inaccurate error messages.

  # mix.exs
  def project do
    [
      # ...
      elixir: "~> 1.12",
    ]
  end

If you are using an asdf for version management you might also want to update your .tool-versions file as well.

Next run mix hex.outdated to see what dependency updates are available. You’ll see a bunch of stuff for the new Phoenix 1.6 release, which at the time of this post is up to 1.6.2. For one of our currently outdated projects I get the following:

$ mix hex.outdated
Dependency              Current  Latest   Status
credo                   1.5.6    1.5.6    Up-to-date
dialyxir                1.1.0    1.1.0    Up-to-date
ecto_sql                3.6.2    3.7.1    Update possible
floki                   0.29.0   0.31.0   Update not possible
gettext                 0.18.2   0.18.2   Up-to-date
jason                   1.2.2    1.2.2    Up-to-date
mix_test_watch          1.0.3    1.1.0    Update possible
phoenix                 1.5.9    1.6.2    Update not possible
phoenix_ecto            4.3.0    4.4.0    Update possible
phoenix_html            2.14.3   3.0.4    Update not possible
phoenix_live_dashboard  0.4.0    0.5.3    Update possible
phoenix_live_reload     1.3.3    1.3.3    Up-to-date
plug_cowboy             2.5.1    2.5.2    Update possible
postgrex                0.15.10  0.15.12  Update possible
telemetry_metrics       0.6.1    0.6.1    Up-to-date
telemetry_poller        0.5.1    1.0.0    Update not possible

Using the above collection of versions you can update your mix.exs deps list. To verify these work try running the following commands in series:

mix deps.clean --all
mix clean
mix deps.get
mix compile
mix test

Fix any issues that popup and then you can commit your progress and start to consider some of the optional parts of the 1.6 upgrade.

Step 4: Migrate to `heex` Templates (optional)

The new template system is called heex (pronounced heaks) and is more HTML-aware, helping report issues like missing div tags at compile time. The new heex templates will help resolve a notable collection of common LiveView and CSS bugs as well as provide nicer inline functions.

While heex templates are great they are optional for now. Previous eex and leex templates still work but are considered deprecated. If you want to start to migrate to heex I would check out the docs for a quick overview and then start renaming your file extensions like:

app.html.eex to app.html.heex
live.html.leex to app.html.heex

For inline templates you’ll use the new ~H sigil instead of ~L sigil.

As you make these changes the compiler will inform you what needs updating. For my own RetroTaxi project most heex updates involved migrating HTML attributes like:

- <div id="topic-card-<%= @topic_card.id %>">
+ <div id={"topic-card#{@topic_card.id}"}>

and

- <button phx-click="start_discussion_phase" phx-target="<%= @myself %>"
+ <button phx-click="start_discussion_phase" phx-target={@myself}

I also ended up using the new <.form> component, which honors the tag aware templates while also addressing a known technical limitation of live_components being wrapped in a block, which is a common pattern inside forms.

- <%= f = form_for @changeset, "#", phx_submit: "save", phx_target: @myself %>
- <!-- stuff -->
- </form>
+ <.form let={f} for={@changeset} phx_submit={"save"} phx_target={@myself}>
+ <!-- stuff -->
+ </.form>

Step 5: Migrate to esbuild (optional)

With Phoenix 1.6 all new project templates will default to esbuild over the historic webpack for asset bundling. This was a change made in an effort to improve long term stability, as npm and webpack have been a huge source of bugs and maintenance issues inside the Phoenix project. This is however an optional change when upgrading older Phoenix projects.

If you already have invested in any webpack customizations you might just want to keep using it.

If your needs are simple and you’d like to give esbuild a spin it can be swapped in without too much work. Chris McCord’s upgrade document has an in-depth set of edits you can follow. I did those steps myself with RetroTaxi and then once I got it all working, went back and re-added my Tailwind dependencies following Mike Clark’s blog post. I ended up with a very basic package.json file.

Aside: One notable question I still have regarding esbuild is the new command: mix assets.deploy. It seems curious to me that running this with the new .gitignore patterns results in a dirty git state. Is this wanted/expected behavior? If you have any thoughts let me know.

Step 6: The Little Things

There are lots of little things you can notice comparing your current Phoenix 1.5 project with a freshly generated 1.6 project. In fact I recommend using mix phx.new hello (substituting your own project name for hello to help with easier copy and paste) and then compare the new project files 1:1 against your current project. You’ll no doubt notice things like:

the move from use Mix.Config to import Config and other related config file changes.
the addition of Swoosh, an email composition and delivery tool, to your project dependency list.
how the path of assets in an esbuild setup will effect your .gitignore file and other template references.
the introduction of topbar as a static JS library replacing the previous NProgress dependency.
slight changes to the generated telemetry descriptions.
slight changes to how the Ecto sandbox is started during test mode.
new complier warning suppressions for LiveDashboard, which will intentionally not be available in production by default.

For RetroTaxi I tried to honor these changes as much as possible.

One helpful tool to do this kind of template comparison at a glace is PhoenixDiffs:

https://www.phoenixdiff.org/?source=1.5.12&target=1.6.0

My Final Upgrade PR and Next Steps

The final RetroTaxi Phoenix 1.6 upgrade PR is here if you want to take a peek:

https://github.com/elixirfocus/retro_taxi/pull/24/

One new feature I have my eye on but did not get around too (yet) is Phoenix.Component. I should be able to use this in favor of some historic stateless LiveComponent modules, which is no longer recommended, as seen in the docs quoted below:

Note: previous LiveView versions allowed the :id to be skipped on live_component but those are now discouraged since the addition of function components, outlined in Phoenix.Component.

Hopefully these notes provide some help and comfort as you upgrade your own Phoenix projects to 1.6. I’m curious how we can continue to improve this process in the future and even have my eye on some new Elixir 1.13 changes that could help by “supporting developers who wish to create tools that directly manipulate and custom format Elixir source code”.

Thanks again to the entire Phoenix team for an outstanding release!

Elixir Terminology: Parameters vs Attributes

mike@mikezornek.com (Mike Zornek) — Mon, 13 Sep 2021 10:00:00 -0400

This post was originally written for my old ElixirFocus blog, and transfer here after its closure.

I’ve written about being explicit and mindful about programming terminology before and today we’ll look at another specific Elixir terminology example: parameters vs attributes.

If you create a new Phoenix app and use the generators to stub out a simple CRUD experience you will no doubt observe web controller functions like:

defmodule HelloWeb.PostController do
  # ...
  def create(conn, %{"post" => post_params}) do
    case Blog.create_post(post_params) do
      # ...
    end  end
end

And internal schema module functions like:

defmodule Hello.Blog.Post do
  # ...
  def changeset(post, attrs) do
    post
    |> cast(attrs, [:body, :word_count])
    |> validate_required([:body, :word_count])
  end
end

Observing function argument names like post_params (short for parameters) and attr (short for attributes) how do we reconcile those naming choices?

Parameters

When we say “parameters” we are usually talking about data coming into the system from external actors, like a user POST-ing data from a web form or an API accepting a request. Parameters are generally considered unsafe. Since the contents are dynamic they will almost always be made from maps using string keys to avoid the known runtime capacity limitations of :atom keys.

Attributes

When we say “attributes” we are usually talking about internal Elixir structures. When a function accepts a simple map argument labeled attr, as seen in our example, I think we can lean on the definition for attribute which says, “a quality, character, or characteristic ascribed to someone or something”.

While attr is a community norm for incoming function arguments, there is an unfortunate overlap with some official Elixir terminology. A module attribute is how we describe those at sign (@) declarations like @email below.

defmodule ContactSupport do
  @email "mike@mikezornek.com"
end

Short post today, but hopefully some helpful context about some community naming norms.

Using Schemaless Changesets to Separate Concerns Between the Web Context and the Business Context

mike@mikezornek.com (Mike Zornek) — Tue, 07 Sep 2021 08:00:00 -0400

This post was originally written for my old ElixirFocus blog, and transfer here after its closure.

With schemaless changesets you have the power to hand craft validations for specific web form presentations and define firm boundaries of responsibilities between your web presentation layer and the business-specific contexts of your app.

It’s a story we can all relate with. A new app is born using mix phx.new hello.

Some mix phx.gen generators are used to begin to shape a solution, perhaps something like:

$ mix phx.gen.html Blog Post posts body:string word_count:integer

And then over time the Post schema grows. Different web forms are needed and so multiple changeset functions are added for the diverging user tasks. You might even start adding virtual fields to schemas just to handle web form needs.

It gets to a point where no one wants to edit or refactor the schema since it has grown too large and complex.

How do get we get out of this mess?

Part One: Break Things Down

When you find yourself with a large schema I would first look to how you can break down this BIG noun into other smaller nouns.

Perhaps you have a large User entity. Maybe you could isolate and extract some of its responsibilities. Maybe introduce a Credentials entity and a user has many of them. Maybe break out a Profile and a user has one of those.

Perhaps you have an Notification entity that is being mutated to track its progress through some kind of delivery process to a third party. Maybe instead of an ever mutating string value of status you introduce a new entity for DeliveryAttempt and then notifications can have many of those and derive a status. With less mutation you likely will need less changesets functions and the code will naturally be more focused.

Breaking down domain concepts into smaller structures can improve the expressiveness and clarity of a codebase. Now, while I hope this little reminder can help brainstorm ideas for your own project there is another sneaky issue at play in our story and that is the changeset dependency problem.

Part Two: Breaking Your Changeset Dependencies

As useful as Phoenix generators can be to stand up a basic app, or to get through a tutorial introducing you to concepts about the framework, there is a dark pattern you would be wise to acknowledge if accepting its compromise.

In an ideal scenario an Ecto.Changeset should NOT have a dependency through line from an app’s business context into the web controller and onto the web form of the page.

Letting a changeset that low in the stack influence the web forms is dangerous.

Lets explain.

First, having any chunk of code touch too many layers begins to handicap your ability to refactor. I tend to align with the thought that “Good Code Is Easy To Change Code”. If you are looking for a simple measurement when evaluating the quality of a codebase, changeability is as good as any principle to lean on.

A common but brittle approach that creates strong dependencies across all the layers.

Second, having low stack changesets dictate web form behavior creates a dysfunctional approach to user experience design where you force the user to represent their work as it will (eventually) be persisted in a database table row. In an ideal situation you’ll be crafting custom web forms to capture user intent and then transform the incoming data into the needed persistance format. Do not let the database dictate the user interface!

Using Schemaless Changesets

So with all of that said, how does one use a schemaless changesets?

Normally if you had a defined an Ecto schema like Registration you’d build a changeset with code like:

fields = [:first_name, :last_name, :email]

changeset =
  %Registration{}
  |> Ecto.Changeset.cast(params["sign_up"], fields)
  |> validate_required(...)
  |> validate_length(...)

Creating a schemaless version is super easy and very much the same. Instead of starting the pipe with a schema type you instead start it with a simple tuple containing the data and some metadata about the data’s types.

data = %{}
types = %{name: :string, email: :string}

# The data+types tuple is equivalent to %Registration{}
changeset =
  {data, types}
  |> Ecto.Changeset.cast(params["sign_up"], Map.keys(types))
  |> validate_required(...)
  |> validate_length(...)

The data in this case can be a simple Map or a more defined struct. For example, in the RetroTaxi project there is a web form presented on the home page and so I built a Struct to represent the request like:

defmodule RetroTaxi.BoardCreation.Request do
  defstruct [:board_name, :facilitator_name]

  @type t :: %__MODULE__{
          board_name: String.t() | nil,
          facilitator_name: String.t() | nil
        }
end

Later when creating a changeset we use this schemaless pattern:

def change_request(%Request{} = request, attrs \\ %{}) do
  types = %{
    board_name: :string,
    facilitator_name: :string
  }

  {request, types}
  |> Changeset.cast(attrs, Map.keys(types))
  |> Changeset.validate_required([:board_name, :facilitator_name])
  |> Changeset.validate_length(:board_name, min: 1, max: 255)
  |> Changeset.validate_length(:facilitator_name, min: 1, max: 255)
end

Other than this difference, you can use the changeset with the Phoenix form tool just like before.

I’ll also take a moment to give a nod to the embedded_schema Ecto type which can be used here in place of the arbitrary Struct or Map; see the documentation for a full sample. My gut tells me to isolate usage of things called “schemas” to entities or values that will end up in the database for a greenfield project, but it’s a small preference. I also like the idea that the concepts of “changeset” need not be limited to the Ecto library.

The Missing Error Gotcha

The one issue you may run into with this schemaless changeset approach is that as you test validations on your web forms you will not see any errors. The reason for this is that traditionally the changeset you render in a POST request will come out of a Repo.insert/2 or Repo.update/2 error tuple and that changeset will have its action attribute set to a non-nil :insert or :update value. The Phoenix web form tools use the presence of this value as a signal to render the errors. For us, this means we need to set action explicitly like the sample below.

  def process_request(request, user_id) do
    changeset = change_request(request, %{})

    case changeset.valid? do
      false ->
        # In the first published version of this post we edited the `action` directly but
        # it is probably safer to use the defined `apply_action` function, though the
        # result is pretty much the same.
        # {:error, %{changeset | action: :insert}}

        # We need to force an action value so the Phoenix forms will display the errors.
        # Code is more explicit here for demonstration purposes.
        {:error, changeset_with_action} = Ecto.Changeset.apply_action(changeset, :insert)
        {:error, changeset_with_action}

      true ->
        # Perform the actual request.
    end
  end

Conclusion

With schemaless changesets you have the power to hand craft validations for specific web form presentations and define firm boundaries of responsibilities between your web presentation layer and the business-specific contexts of your app. Lots of people will not invest in this separation of concerns, and depending on the life-cycle of the application and the needs of your users that might be fine. If however, you find yourself making multiple flavors of changeset or adding lots of virtual fields to a schema just to make the web forms fit in – it might be time to rethink your approach.

Retro Taxi: September 2021 Update

mike@mikezornek.com (Mike Zornek) — Thu, 02 Sep 2021 09:00:41 -0400

This post was originally written for my old ElixirFocus blog, and transfer here after its closure.

A few months ago I kicked off the next sample project for this website, a team retrospective board built using Phoenix LiveView called RetroTaxi. More info about the project is available in the project kickoff and today I’ll share how it has been coming along.

From the scope of the original pitch document you’d like to think I would have gotten further along by now but a mix of client responsibilities and then a extended personal vacation kept me distracted. Over the past week however I have gotten back into the project and can show some basic things working.

First, a user can visit the home page and create a new board. This create board form also asks for their name, since they will be displayed as the meeting’s facilitator to future collaborators.

Create new board form.

With the board created you are redirected to the board page, which shows the custom title and displays the facilitator in the to-be-fleshed-out “who’s here” section.

Each board has four columns and each column has content cards. You can add cards to columns and you can edit cards. There is no active pub/sub between multiple people viewing the board and seeing the cards change (yet), that is still forthcoming.

Sample of current board with editable content cards.

The site is styled with Tailwind CSS through I wouldn’t say it represents a final visual language by any means. I hope to finish the project with a vanilla Phoenix LiveView setup and then move on to experiment with Surface for a fuller UI component experience.

Since I wrote the original cycle one pitch I feel like my understanding of what I want to build and how it will all work has been very fluid. I have pretty much dropped the concept of cycles and have just started tagging issues with a MVP1 label since this project’s progress has clearly not been constrained by time.

I’m going to try to be more deliberate with issues and pull requests moving forward so if you want a peek or contribute, check them out.

Hopefully I’ll also be able to start extracting some more code-specific blog posts from the project soon. If you have any specific questions, let me know mike@mikezornek.com.

Resources and Suggestions to Find Elixir-based Employment

mike@mikezornek.com (Mike Zornek) — Fri, 16 Jul 2021 16:12:03 -0400

This post was originally written for my old ElixirFocus blog, and transfer here after its closure.

The following is a collection of resources and suggestions for people looking to acquire full time or project specific employment writing Elixir. I personally lean more on consulting but the topic of Elixir employment comes up enough that I thought I’d share what I’m aware of.

Elixir Job Listings

First we have the aptly named elixirjobs.net, which provides an active catalog of known job listings.

I also highly recommend the #jobs, #jobs_chat, and #looking_for_contract rooms of the official Elixir Slack

Elixir Radar, which may be more well known for its weekly newsletter, also hosts a job board, which is usually promoted in said newsletter emails.

The Elixir Forum has a dedicated jobs tag that is less active then the above can still be a helpful link to track.

Don’t Let “Requirements” Scare You Away

One of my first web development jobs was with a company that at the time was looking for full time / experienced developer. I applied despite my limited experience and with only part time availability (I was still in college at the time). They hired me anyways, found a project that I could contribute to and ultimately provided a great environment to improve my skills.

The point being, many of these job descriptions do not fully convey the situation at these companies. If there is a company or opportunity that interests you, put yourself out there, introduce yourself and share what you are looking for. You never know how it might turn out.

Elixir Meetups / Personal Networking

While applying to a specific job listing can be the most direct approach to finding a new gig, there is something to be said for personal networking. Many Elixir meetups and communities are very approachable online right now. Get out there, introduce yourself (maybe even do a talk!) and be shamelessly direct, explaining that you are looking for work opportunities. Be like Bob Vance, Vance Refrigeration.

Elixir Companies

If you observe a company sponsoring an Elixir conference or other kind of Elixir event, they are most likely looking to hire people. You don’t even need to limit your search to current events; if that company sponsored an Elixir event years ago they are still a good target to contact.

You can also look for companies that have been promoted for their Elixir usage or are otherwise known to be using Elixir. If you spot a company that might be a good fit, reach out to them – even if they don’t have a job listing.

Self Promotion

If you have even a mildly active personal website or social media account, consider adding a static header or profile link to a blog post explaining what kind of job you are looking for. Rename yourself on Twitter or Slack to “Billy Beta is looking for Elixir work” to make it clear, even in unrelated posts that you are available for hire.

If you need to be more stealthy, consider a few private emails to friends explaining your situation and that you are looking for something new. So much of my own works comes from friends of friends. It is very helpful to have wide social nets to allow for good things to happen.

Be Prepared

Finally, be prepared. Know what you want and don’t want in a new gig. Write it all down (paper is better) and prioritize your interview questions to align with those needs.

I personally am very behind the People-first Business movement, see also the People-first Job Board, and so I align my own questions around those values and concerns.

Your ability to land an Elixir gig has never been better. Get out there and find something that is a good fit for you. If I missed any resources, let me know.

Improve the Clarity of Your Elixir Code Through Expressive and Consistent Language

mike@mikezornek.com (Mike Zornek) — Sun, 06 Jun 2021 12:00:00 -0400

This post was originally written for my old ElixirFocus blog, and transfer here after its closure.

One of our primary day-to-day responsibilities as programmers is to communicate. We need to express our ideas, explain our work and document our code. Having a strong vocabulary and explicit intentions behind the words you (and your team) choose can greatly help avoid confusion.

Take some time as a team to talk about how you name and describe things. Embrace productive confrontation when you identify inconsistencies and work towards creating (and documenting!) as much as a ubiquitous language as you can.

The following is a collection of terms I try to be mindful of in my own work. Hopefully this list helps inspire some of your own terminology choices.

Programming Terminology

Entity vs Value

An entity is a structure that has identity. An Account in my application has a unique identifier and is thus is considered an entity.

A value is a structure without identity. A Color in my application might be made up of three scalars like red, green and blue. Collectively they make up the Color value but there is no identity.

Some people might prefer the term record instead of entity in this context. I consider the terms fairly similar so would honor my team’s chosen preference.

Entity vs Row

Sometimes when we talk about entities we’ll get into the deeper discussions of how the entities are persisted, usually inside a database At that point I make a special case to change how I talk, being more explicit about the database row. Entity is how I refer to the in-memory representation of the structure, but if we are talking about database storage or SQL-specific things I want to use the term row to be more explicit.

Maps vs Structs vs (Ecto) Schemas

Maps, Structs and (Ecto) Schemas are all Elixir structure tools that we use to create entities and values. Each of these tools has their own purpose and constrains so I try to be explicit when talking about which tool we are using.

Create vs New vs Insert and Remove vs Delete

As you define the core domain nouns of your app you’ll inevitably start to build out a series of modules that help you manage these nouns. When designing the interfaces of these modules have an explicit pattern for how to name behaviors and try when possible to lean on community patterns. Ask yourself, “how does the Elixir language or popular frameworks use these terms?”

Delete and New as used inside of Elixir.

You can also take advantage of the various Phoenix/Ecto generates for a peek at some pattern recommendations from the framework authors. These are usually a great place to start, although I don’t consider the patterns to be gospel.

In addition to the working on the names of the modules functions themselves, you may also be involved in the user experience of an app and its own terminology. Ideally the nouns and terms from the interface down through the code will align but this is not always possible. Sometimes the needs of the user experience design require the terminologies to deviate. While not ideal, I’m fine with this – it just has to be done with intent and consistency. Write down the terms you have chosen and why.

Get vs Fetch

There are a few notable Elixir patterns to be mindful of with the terms get vs fetch.

First let’s check out Map.get/3 which will return a value for the given key or a default value if the key is not found.

iex> Map.get(%{}, :a)
nil
iex> Map.get(%{a: 1}, :a)
1
iex> Map.get(%{a: 1}, :b)
nil
iex> Map.get(%{a: 1}, :b, 3)
3

Next we have Map.fetch/2 which will return an :ok tuple or :error if the key is not found.

iex> Map.fetch(%{a: 1}, :a)
{:ok, 1}
iex> Map.fetch(%{a: 1}, :b)
:error

There is also a bang version of fetch, Map.fetch!/2 which will return the value or raise an exception if the key is not found.

iex> Map.fetch!(%{a: 1}, :a)
1

The takeaways from these language patterns I take note of are the following:

get_noun should return the value or a default if not found.
fetch_noun should return a :ok tuple or an :error tuple.
Any function with a bang (exclamation point) will throw an exception, and that exception should be documented inside the inline documentation.
In general I try to avoid creating bang style functions as I feel like Elixir exceptions should be exceptional. You may notice that the there are Phoenix code generators out there that will create a get! style functions in generated contexts. That is pattern I am aware of but question in newer code.

List vs Array

I do my best to be mindful of and embrace the terminology of the language I am working in, moment to moment. This means if we are dealing with a collection in Elixir I’ll say list and when we are dealing with a collection is JavaScript I’ll say array. In an Elixir context I’ll say map and in a JavaScript context I’ll say dictionary.

For a junior programmer this might seem like symantec nonsense but I think its an important distinction. Related, I honor the styles of the host language, for example using camel case for variables in JavaScript and underscores in Elixir. With luck a linter of some kind can help remind me if I loose my place.

Behavior vs Feature

When talking about what my code does I use the term behavior. I describe the behaviors I want to build and I document the behaviors I observe.

The term feature is more a product or marketing term, usually describing a collection of end user observable behaviors.

App and Business Domain Consistency

Document Your App’s Custom Terminology

While I have some personal preferences to share below, ultimately every app will have a custom vernacular for how they label things in the system. Spend some time getting team agreement on the meaning and intent behind these terms. Write them down. Review and evolve the glossary when needed. Having alignment on this language will be extremely helpful over time as you discuss what to code needs to do.

Authentication vs Authorization

Many people simply talk about “auth” systems without being explicit but it’s important to distinguish between authentication, figuring out who you are talking to, and authorization, figuring out if someone should be allowed to do something.

My own preference here is to use Sign in, Sign out and Sign up. I’m also ok with other variants like “Create Account” in the user experience as long as we are consistent.

I dislike log in since it is too easy to mix up the term “login” vs “log in”.

Account vs User and Settings vs Preferences

No strong personal preferences here, would have to consider the application context – but once again I am looking for consistency. If I were debating choices for a new app with my team I’d look at some industry competition to see what they do.

Language I Try to Avoid

Bad Code and Code Smell

I do my best to follow the retrospective prime directive which states:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Believing this, I try to avoid saying something is “bad code” or has a “code smell”. Those phrases package a lot of negative judgement which is not very constructive. Instead let’s look for opportunities to improve testability, or documentation or abstractions. No one wrote this “bad code” intentionally to sabotage the system. We are all members of an extremely immature and fast moving industry with diverse backgrounds and levels of experience. It is messy out there and everyone is learning as we go.

If you are doing a code review, instead of saying something has a “code smell”, kickstart a discussion around getting more context around the decisions and constrains that led to this code’s design. Ask if they considered an alternative or are aware of your concerns. These pull requests are opportunities for education and starting the process with judgement language is not going to result in many positive outcomes.

Understanding when to use String-based Maps vs Atom-based Maps

mike@mikezornek.com (Mike Zornek) — Mon, 31 May 2021 10:56:17 -0400

This post was originally written for my old ElixirFocus blog, and transfer here after its closure.

While browsing the ElixirForum the other day I spotted this question from Dominic which resonated deeply with my own experiences learning Elixir. Dominic asks:

I’m constantly being blocked by maps’ different construct %{:atom => "value"} vs. %{"string" => "value"} vs %{name: "value"}.

It does not appears to be consistent enough and in my case are often the cause of all “blockage” I have.

I understand them, I’m a long time Elm dev/fan and used to FP, but I don’t know why Elixir’s maps are so weird to me.

Later in the post Dominic notes he gets an error complaining about mixed keys: (Ecto.CastError) expected params to be a map with atoms or string keys.

So with all that said, why the lack of consistency? Why don’t people just use String-based Maps or just use Atom-based Maps? Why do all these Phoenix tutorials jump from one to the other?

The short answer is, if given the opportunity I think most Elixir developers would lean on Atom-based Maps at all times, but we need to work within the constrains of our deployments. As preferable as :atoms may be they are not garbage collected and if you are allowing dynamic content into the system (from say a web request) and converting that content to Atom-based Maps you leave yourself open to running out of memory from a bad actor or even just natural system behavior. It is for this reason the web request tooling within Phoenix will transform those payloads into String-based Maps.

With that explanation out of the way, let’s talk about Map syntax. While Dominic quotes three styles of map syntax there are really only two patterns to keep in your head:

%{"name" => value} which is a Map syntax using the arrow => token; and,
%{name: value} which is an arrow-less version of the Map syntax made exclusively for Atom-based Maps.

The third style Dominic shared, %{:atom => value} I would group into the arrow => camp. Maps can use Strings or Atoms as keys and so no real syntax sugar is present in this example.

I think one of the real jarring issues for people new to Elixir when it comes to the Atom-exclusive Map syntax is that it has the colon of the Atom key on the right-hand side. You’ll see this with Keyword lists as well. Having multiple ways to express a Map can be one level of confusion, but then to combine it with multiple ways to express an :atom feels like a compounding problem.

The good news, I can share as someone who has been doing Elixir for a few years now, is that this confusion is not something I’ve experienced elsewhere in the language. On the whole I’ve found Elixir syntax to be straightforward and approachable. Getting comfortable with the Atom syntax sugar of Maps and Keyword lists took a little time but eventually it stuck.

One of the deeper concepts that comes out of this discussion however is the need for String-based keys from content outside the system. I think it is very helpful to have that external boundary in mind when building your code. Let the web or API contexts handle validating or shaping those String-based Map values and then have a meaningful transformation into the Atom-based Maps that will accept values for your core layer. With that pattern in mind your tests can follow along, simulating String-based Map payloads for controllers and Atom-based Map values for core context testing, and thus avoiding the kind of Ecto error Dominic shared.

For more on boundaries check out the The Core and the Interface from the excellent Towards Maintainable Elixir series.

RetroTaxi Project Kickoff

mike@mikezornek.com (Mike Zornek) — Sun, 14 Mar 2021 16:55:21 -0400

This post was originally written for my old ElixirFocus blog, and transfer here after its closure.

Phoenix by Example is all about crafting educational content extracted from open source example projects. Today I am kicking off my latest example project, RetroTaxi!

From the pitch document:

A retrospective meeting is a regular practice of agile teams or any group of people who are looking for continued improvement to their team process, communication or habits. Successful retro meetings give the team an opportunity to reflect on what is working, what is not and what they want to do next.

Retrospective meetings can be executed in many different ways but with the advent of more people working remotely having an online collaborative tool to help execute the meeting and capture feedback is often advantageous. Some people will initially lean on collaborative tools like Google Docs to help execute a retro meeting and while it can work, it is not very elegant or structured. There are also dedicated retro tools but most are locked behind account registration, paywalls or try to do too many things.

This project aims to provide a simple, focused tool to help people run a retro meeting online. Our solution will value:

A registrations-free experience over formalized team management.

One-time use boards over detailed historic archives.

Conversations over analytical measurements or note taking.

A responsive web experience over platform-specific apps.

RetroTaxi will utilize Phoenix LiveView fairly heavily and should be a useful source of topics to discuss.

Project Goals

The first two projects of Phoenix by Example were fairly simplistic in nature and one of the first goals is of RetroTaxi is to do a more through exploration of a real world project process. As such you’ll see some early discovery time has been spent in preparing a pitch document, which is a slice of the larger Shape Up process.

Sample of some early discovery sketching and interface breadboarding.

Some mockups from the pitch document:

Board layout.

Card state.

The second project goal is to (hopefully) provide more useful and usable solutions to real world problems. When I built the GetShorty link shortener example there were no real aspirations that anyone would actually use the tool day-to-day, but moving forward I’d like to find small slices of opinionated, usefulness solutions to model the examples after. If you find this and have thoughts on retro meeting and the tools involved, please reach out. I’d love to hear your observations.

Next Steps

With the early discovery and my first pitch written I see the next steps as follows:

Sketch out the HTML/TailwindCSS needed to execute the design.
Build out the core contexts needed to model the behaviors of the board.
Create the LiveView to wire up the behaviors to the UI, breaking the interface into simple, testable components.
Refine the interactions and test non-happy path experiences (browser reload/rejoin).
Deploy and test the app to be used on the public internet.

The plan is to do this project in 6 weeks, with about 10 hours per week of dedicated time. I’ll be blogging my progress here so if you want to stay informed be sure to subscribe.

Securing Webhook Payload Delivery in Phoenix

mike@mikezornek.com (Mike Zornek) — Mon, 22 Feb 2021 14:00:00 -0500

This post was originally written for my old ElixirFocus blog, and transfer here after its closure.

Some of the most interesting and valuable behaviors we can build as web developers are through connecting different web applications together. Often times this comes in the form of webhooks, where one web app will POST events to your own web app. Keeping that communication secure is important and today we will take a peak into how you can secure webhook payloads in a Phoenix application.

Webhook Security 101

Webhook might sound like some scary, exotic term but at the end of the day webhooks are nothing more that a web server endpoint configured to receive HTTP POST requests in some agreed upon format. The concern however is, without any additional security, anyone could discover the endpoint and start sending their own malicious payloads to your web application.

To help secure a webhook, when you first set it up you’ll give the third party some generated secret. As an example, here is where you can store the secret while configuring a GitHub webhook:

When GitHub then sends the HTTP POST request they will include, in the headers of that request, a signature of the payload using the previously shared secret. As you process the HTTP POST request you can then generate your own signature, based on the incoming payload and the known secret, to verify the payload’s authenticity. If the secrets match then you have much more trust that the payload came from the correct third party.

Validating a Payload Signature in Phoenix

To get this to work in Phoenix we’ll need a few core behaviors.

First, we will want the ability to generate a signature based on a payload and a secret.

  def generate_payload_signature(_, nil) do
    {:error, :missing_app_secret}
  end

  def generate_payload_signature(payload, app_secret) do
    {:ok, :crypto.mac(:hmac, :sha256, app_secret, payload) |> Base.encode16(case: :lower)}
  end

Second we’ll need a way to pull out the signature from the connection’s request headers, if present:

  defp signature_from_req_headers(req_headers) do
    case List.keyfind(req_headers, "x-hub-signature", 0) do
      {"x-hub-signature", full_signature} ->
        "sha256=" <> signature = full_signature
        signature

      _ ->
        nil
    end
  end

Finally we’ll connect the dots creating a simple call site function where someone can pass in a Plug.Conn and a payload and ask if it is authentic.

  def is_authentic_payload?(%Conn{req_headers: req_headers}, payload) do
    case signature_from_req_headers(req_headers) do
      nil ->
        false

      signature ->
        is_payload_signature_valid?(signature, payload)
    end
  end

  defp is_payload_signature_valid?(payload_signature, payload) do
    case generate_payload_signature(payload, webhook_secret()) do
      {:ok, generated_payload_signature} ->
        Plug.Crypto.secure_compare(generated_payload_signature, payload_signature)

      _ ->
        false
    end
  end

  defp webhook_secret do
    Keyword.fetch!(Application.fetch_env!(:webhook_signature, :github), :webhook_secret)
  end

There are a few ways you could go about getting this check into your controller code. The most challenging part is that out of the box Phoenix does not make the raw body of an HTTP POST request available to you through the Plug.Conn struct. Instead a default Phoenix app uses parsers and converts such payloads into native Elixir value types.

One way to turn off this behavior is to edit your Phoenix app’s endpoint.ex file and remove the auto-parsing behavior for all routes of that endpoint. You can find some more info about doing this in the Plug docs in a section titled “Custom body reader”.

Since this parsing behavior is helpful for non-webhook requests in our example app, we will relocate the parsing configurations out of the endpoint.ex file and into the pipeline definition on the router.ex file. This way we can keep the parsing behavior working for the rest of the example app and do something custom for our webhook endpoint.

defmodule WebhookSignatureWeb.Endpoint do
  # CONDENSED FOR DEMONSTRATION

-  plug Plug.Parsers,
-    parsers: [:urlencoded, :multipart, :json],
-    pass: ["*/*"],
-    json_decoder: Phoenix.json_library()

end

defmodule WebhookSignatureWeb.Router do
  # CONDENSED FOR DEMONSTRATION

  pipeline :browser do
    plug :accepts, ["html"]
    plug :fetch_session
    plug :fetch_flash
    plug :protect_from_forgery
    plug :put_secure_browser_headers

+    plug Plug.Parsers,
+      parsers: [:urlencoded, :multipart, :json],
+      pass: ["*/*"],
+      json_decoder: Phoenix.json_library()
  end

end

Our next question is where do we this verification check? In our example app, we will keep the controller code focused on the behavior of processing the payload and put the behaviors for signature verification inside some plugs as part of the router’s pipeline for this specific endpoint.

The first plug will read the contents of the Plug.Conn body into a new assigns value :raw_body.

defmodule WebhookSignatureWeb.Plugs.RawBodyPassthrough do
  @moduledoc """
  This plug will read the body for `POST` and PUT` request and store it into a
  new assigns key `:raw_body`.

  This plug is used on certain routes in preference to the default Phoenix
  behaviors that would automatically decode the params and request body into
  native elixir values for a controller. It is a required choice since the body
  of a `Plug.Conn` can only be read from once.
  """

  import Plug.Conn
  alias Plug.Conn

  @spec init(Keyword.t()) :: Keyword.t()
  def init(options), do: options

  @spec call(Conn.t(), term()) :: Conn.t()
  def call(%Conn{method: method} = conn, opts) when method == "POST" or method == "PUT" do
    case Conn.read_body(conn, opts) do
      {:ok, body, _conn_details} ->
        Conn.assign(conn, :raw_body, body)

      {:more, _partial_body, _conn_details} ->
        conn
        |> send_resp(413, "PAYLOAD TOO LARGE")
        |> halt
    end
  end

  def call(conn, _opts), do: Conn.assign(conn, :cached_body, %{})
end

The second plug will pull out the signature from the HTTP request headers and then verify it matches our expectations.

defmodule WebhookSignatureWeb.Plugs.RequirePayloadSignatureMatch do
  @moduledoc """
  This plug will verify that the payload from a webhook request matches the
  accompanying header signature, based on a previously shared `webhook_secret`.

  When the payload is verified the connection continues as normal.

  When the payload is unverifiable the connection is halted with a 403 response.
  """

  import Plug.Conn
  alias Plug.Conn
  alias WebhookSignature.PayloadValidator

  @spec init(Keyword.t()) :: Keyword.t()
  def init(options), do: options

  @spec call(Conn.t(), term()) :: Conn.t()
  def call(%Conn{method: method} = conn, _opts) when method == "POST" or method == "PUT" do
    case PayloadValidator.is_authentic_payload?(conn, conn.assigns.raw_body) do
      true ->
        conn

      false ->
        conn
        |> put_resp_content_type("application/json")
        |> send_resp(403, "{\"error\":\"PAYLOAD SIGNATURE FAILED\"}")
        |> halt
    end
  end

  def call(conn, _opts), do: Conn.assign(conn, :cached_body, %{})
end

Finally we’ll bring it all together, defining an :api pipeline and using that pipeline for our GitHubWebhookController route.

defmodule WebhookSignatureWeb.Router do
  # CONDENSED FOR DEMONSTRATION

  pipeline :api do
    plug :accepts, ["json"]
    plug WebhookSignatureWeb.Plugs.RawBodyPassthrough, length: 4_000_000

    # It is important that this comes after
    # `WebhookSignatureWeb.Plugs.RawBodyPassthrough` as it relies
    # on the `:raw_body` being inside the `conn.assigns`.
    plug WebhookSignatureWeb.Plugs.RequirePayloadSignatureMatch
  end

  scope "/github", WebhookSignatureWeb do
    pipe_through :api

    post "/webhook", GitHubWebhookController, :webhook
  end
end

If the signature match is successful the controller will be allowed to do its processing of the payload values.

If the signature match is not successful we return a 403 response since “The server understood the request but refuses to authorize it.”

Show Me The Code

There is an example project with the behaviors expressed in this post on GitHub:

https://github.com/phoenix-by-example/webhook_signature

Understanding the Tradeoffs with Elixir Typespecs and Dialyzer

mike@mikezornek.com (Mike Zornek) — Wed, 20 Jan 2021 08:51:42 -0500

In today’s post I want to start a conversation around the tradeoffs of using Typespecs and Dialyzer use in your Elixir code.

Elixir is a dynamic, not a statically-typed language – and just to preemptively avoid the programming wars that might ensue, the given type system of a language is not a “good” or “bad” attribute by itself, but it will none-the-less influences the code we write.

For those who prefer or come to Elixir from a statically-typed language background you may be interested in learning more about Elixir Typespecs, described in the documentation as follows:

Elixir comes with a notation for declaring types and specifications. Elixir is a dynamically typed language, and as such, type specifications are never used by the compiler to optimize or modify code. Still, using type specifications is useful because:

they provide documentation (for example, tools such as ExDoc show type specifications in the documentation)

they’re used by tools such as Dialyzer , that can analyze code with typespec to find type inconsistencies and possible bugs

While I have done some limited work with typespecs in my side projects, in my current client project the decree has been made we will define typespecs for all functions, both public and private, and we have dialyzer checks built into the CI to report any reported issues.

On the face of this requirement I do not have a problem, it is very well meaning towards building a stable codebase. Who can disagree with such a goal? The realties however of seeing it through day-to-day are more complex. First, let’s talk about how dialyzer errors can sometimes be hard to debug.

One recent error I got back from dialyzer was something like this:

:0:unknown_type
Unknown type: Widget.t/0.

There was no function name, nor file name, nor line number to help me understand where this error was coming from. I was on my own. Luckily I knew the dialyzer check was clean before my I started my branch so I could at least look at my git diff for some ideas. This was not fun.

Another time I had a whole list of dialyzer errors reported back to me. Now if I was dealing with traditional complier errors I would work from the top of the list down, since sometimes when those first complier issues are resolved the later issues will disappear. Sadly when it comes to dialyzer errors that first error need not be what actually needs to get fixed. Many times you need to fix issues from the middle of the list first and knowing what to fix from that list is a learned art with its own dedicated learning curve.

Obtuse errors are bad enough but the second big issue for me is time. On a bigger project like ours it can sometime takes 10+ minutes to do a full dialyzer check the project. That long feedback loop can really slow down your day.

So where do we find the balance?

When it comes to Elixir code, my priorities of practices to enable a stable code base are as follows:

First, write tests. Validate your code behaviors and assumptions. Check the happy paths and check the sad paths. Do this for every project you ever write.
Second, use credo. Credo can analyze your project for Elixir style and consistency. Credo is extremely fast with helpful error messages that teach you not only how to fix something but why it should be fixed. Use this on any project that you work on for more than a few days.
Finally, use typespecs and dialyzer, but only for your public functions, and with a heavy leaning towards your own contexts and not the Phoenix-based modules that will be called based on dynamic behaviors like routes calling controllers. Use dialyzer for customer facing apps or anything open source.

Of course every project has unique needs and tradeoffs, but this is where I land in the general case.

I’d love to hear your thoughts on typespecs and dialyzer.

Introducing Phoenix by Example

mike@mikezornek.com (Mike Zornek) — Mon, 19 Oct 2020 18:23:47 -0400

Teaching has always been a big part of my self identity. Be it teaching at university, Big Nerd Ranch workshops or even my work with local tech meetups.

With my increasing enjoyment of Elixir and Phoenix I’ve been anxious to find a teaching outlet using these technologies. Additionally I want to find a unique spin on whatever I come up with, since there are already lots of great resources for learning Elixir and Phoenix and I don’t want steal anyone’s thunder.

My first result towards this effort is a “hello world” style example app and tutorial called greeter:

Greeter is a “hello world” example app to help introduce the core concepts of the Phoenix Framework written in Elixir.

This tutorial assumes no previous Elixir experience. In fact the first section will help you install and setup Elixir and Phoenix.

By the end of this example, you’ll have created a Phoenix app that can display a custom greeting message with a formatted name.

I’ve published the example repo under the Phoenix by Example organization name. I’ve also nabbed a web domain phoenixbyexample.com and a twitter account @PhoenixExamples.

I’m still not sure how this will work out over time but my plan is to record a few videos to accompany the example project. I would also like to work out some shorter tweet videos with some tips and tricks content.

The next project I’m thinking about would be a link shortener. I suspect I will not do a step-by-step tutorial for that one, but instead lean on code snippets pointing out the big ideas and then more videos.

The only really “bad news” is that I have a new Elixir Phoenix client project starting up so progress on these examples will be a little slower than I expected when I started pulling it together.

Feedback and project ideas very welcome. Let me know what you think.

Using Postmark's new Broadcast Email Stream via Elixir and Swoosh

mike@mikezornek.com (Mike Zornek) — Mon, 12 Oct 2020 13:51:26 -0400

In advance of adding some new broadcast email features to Guildflow I’ve built some additions to the Swoosh Elixir email library that allow one to use the new broadcast message stream feature of Postmark. Brief video tour and links below. Let me know if you have any questions.

Your browser does not seem to support the video format. You can download the MP4 file directly.

Download MP4

Video: An Introduction to Elixir

mike@mikezornek.com (Mike Zornek) — Tue, 14 Apr 2020 08:46:05 -0400

This talk was originally presented at the Philly Elixir Group April meeting.

Covers the basics of the language, what it can be used for and why it’s particularly helpful for certain situations. A great talk for people new to or curious about Elixir.

Your browser does not seem to support the video format. You can download the MP4 file directly.

Download MP4 Watch on YouTube

Slides PDF / SpeakerDeck

Links:

Video: Working With Time Zones in an Elixir Phoenix App

mike@mikezornek.com (Mike Zornek) — Thu, 19 Mar 2020 11:14:21 -0400

This talk was originally presented at the Philly Elixir Group February meeting.

“Today we are going to talk about time zones, specifically what they are, how Elixir handles them and then talk about some strategies you can apply when working with time zones in the context of an Elixir Phoenix app backed by an Ecto database.”

Download MP4.

Slides PDF / SpeakerDeck

Here are some of the reference links mentioned:

First ElixirConf, and Then Azeroth

mike@mikezornek.com (Mike Zornek) — Fri, 23 Aug 2019 15:20:41 -0400

Happy Friday everyone. Hope you all had a good and productive week. I myself am feeling pretty good.

Went heads down this week and made some project progress for both clients and personal endeavors. Today, Friday, I’m working from home. First cleaning up a bit and then probably some more client work. Would like to close a few threads before attending ElixirConf next week.

I’m going for four days. First two days are workshops and then two days of conference talks. My workshops will be:

Build Performant, Real-Time UIs with Phoenix LiveView - LiveView is something I have experimented with but have yet to get going in my projects. I am excited to get past the simple demos into more complex use cases.
Build a Smart Camera with Nerves, Phoenix, and Absinthe - I have almost no hardware experience and this is more of an experimental thing for me. Lots to learn!

It’s going to be a fun week. Over the last year I’ve really started to get over the beginner hump of Elixir and am ready to sink my teeth into some of the deeper aspects (or aspects like Nerves and embedded software I’ve never touched).

Sadly while I’m away at ElixirConf I’m also going to miss the opening of WoW Classic. I’m really excited to see how Classic works out as I’m not a fan of current retail WoW but still enjoy the lore and atmosphere of Azeroth. It sounds like the early days are going to result in a fair amount of login queues so maybe my Elixir distractions will be for the best.

Pretty sure I’m going to level a Gnome Mage as my main. Server is Herod (PvP).

Regardless to all this, I am also looking forward to September and a no more trips for a little while. As much as I like to get out I also love being home and enjoying my routines. I also need to start getting more time into my side project and start it’s marketing / validation path to see if it’s a real product or not. More to come on that.

Enjoy the weekend and have some fun.

Philly Elixir Meetup is Rebooting

mike@mikezornek.com (Mike Zornek) — Mon, 22 Apr 2019 10:00:00 -0500

After too long of a hiatus, the Philly Elixir Meetup group is rebooting!

https://www.meetup.com/PhillyElixir

Elixir is a functional programming language that is popular for building web apps and services using a library called Phoenix as well as GraphQL APIs using Absinthe.

Our first meeting back will be:

Monday, May 6, 2019
6:00 PM to 8:00 PM

PromptWorks
1211 Chestnut Street #400

RSVP: https://www.meetup.com/PhillyElixir

Even if you can’t make this first meeting, please join the group as we’ll have many more to come. If you have questions, shoot me an email. Thanks!

ElixirConf 2018 Notes

mike@mikezornek.com (Mike Zornek) — Sun, 09 Sep 2018 19:54:59 +0000

After attending ElixirConf I am as confident as ever that Elixir is a language, community and ecosystem I want to continue to personally invest and participate in.

About two years ago I made the decision that I needed to diversify my technical skills outside the Apple ecosystem. I then went on to experiment and research lots of different languages and frameworks, including EmberJS, Go, Rust, Elm, HTML5 updates, React and Elixir.

The Elixir interest started from a broad recommendation from Dave Thomas who I had years before followed heavily while doing Ruby on Rails development. Elixir also had gotten momentum from my interests in Functional Programming and looking to solve problems outside of traditional Object Oriented Programming design patterns. Over the last few months I’ve gotten deeper into Elixir and I really like what I’ve found.

I’ll do a post in the future about why I’m liking Elixir so much. It’s a potentially large topic and I want to give it the space it deservers.

ElixirConf was a great event. Two days of training and two days of conference sessions; I took it all in. My personal estimate would put the training day attendance at around 150 and the full conference at around 500.

While educational, I found the class pacing to be mixed. I felt one went a little too slow and the other a little too fast. There was a wide gamut of Elixir experience in the audience so I think it’s challenging for the instructors to find a pace everyone can agree with. That said, I learned a ton in each of the two more introduction-based classes I attended. I was envious of the more advanced classes that were covering GraphQL and hardware development using Nerves — I heard people were very impressed with them. Maybe next year.

For the conference days we had some great keynotes and session. I loved hearing José Valim (creator of Elixir) talk about the future of the language including the core teams failed experiments with adding a type system and why it’s not on the horizon. Chris McCord (creator of Phoenix) did a closing keynote, reviewing progress with the framework including a preview of Phoenix LiveView which was very impressive and has an opportunity to shake things up in the single-page app space. Aaron Renner had a great talk on taming complexity which mirrored some of my previous iOS code patters with way better naming. Aaron Votre’s excitement about GraphQL is contagious and I’m anxious to get my hands dirty. Andrew Bennett has some great tips in his Sustainable Testing talk. Daniel Azuma did a great job showing how we can mix and match Docker with traditional OTP deployments for unique benefits. Some time slots were competitive for my attention. I sadly missed Boyd Multerer’s Introduction of Scenic and Eric Oestrich’s Going Multi-Node session which both were well received from chat in the hallways. I’ll be sure to watch them on YouTube in the week ahead. In fact the majority of the conference keynotes and sessions are already posted on YouTube if you want to take a look.

Despite my general shyness, the community was very welcoming and friendly when I put myself out there. I had some great conversations during breaks and lunch. Hopefully these will continue on the community Slack and forums — I need to spend some more time with those.

Finally, everyone is hiring. Almost every speaker who represented a company said they were hiring. While I’m not looking for full time employment its relieving to see such hiring interest in a more niche language than say my current source of income, iOS.

Next year ElixirConf will be in Denver and assuming I find a way to keep Elixir active in my development schedule (I have a potential Elixir subcontract in the fall as well as some personal projects) I plan to be there.

For more on Elixir check out its homepage.

Mike Zornek

A Visual Tour of Phoenix's Updated 'magic link' Authentication Code Generator

Background on authentication

The sample Hello project

User experience

Navigation updates

Registration page

Opening the confirmation ‘magic link’

Authenticated navigation

Log in with email

Log in with email/password

Settings

Change Email

Save Password

Schemas

Closing thoughts and nitpicks

Ranked Vote Flick Demo

Conference Notes: CodeBEAM America (San Francisco) 2025

Notable Talks

Conference Format

Vibes

Followup Learning Projects

Phoenix LiveView: Presenting DateTime in User's Time Zone

Elixir time zone basics

The user’s time zone

This is a half solution.

Designing a more complete solution.

A Hook-based approach.

Other Resources

Errata

Personal Elixir Code Aesthetics

Whitespace between import and alias.

Alphabetically ordered alias declarations.

Avoiding multi-alias declarations.

(Generally) prefer multiline do/end functions.

Use consistent DSL layout in test modules.

Invest in test fixtures

Use tiny_maps to save horizontal line space in tests.

Compose code to prefer clean line breaks

Embrace pipelines with custom utility functions.

Be consistent between module names and filenames.

Write professional documentation.

Document your decisions.

Make sure each FIXME has an issue URL.

Avoid abbreviations and prefer expressiveness.

Words matter.

Craft typespecs to express your domain.

Document your dependencies.

Document and validate function options.

Compose PR titles for clarity and consistency.

Strive for database precision.

LiveView Modules Must End in `Live`

Announcing my New Full-Time Job

Shutting Down ElixirClub

Elixir Rap Song

Compose a rap song about how much programmers love the functional programming language Elixir.

Elixir Context Accessor Function: Which Return Type Do You Prefer?

A New Project: ElixirClub

What to expect as a member?

Elixir Book Club: Testing Elixir, Starts November 13th

Testing Elixir

Extra Credit?

Closing Thoughts on my Exercism Video Project

Exercism Elixir Track: Take-A-Number Deluxe (GenServer)

Exercism Elixir Track: RPN Calculator Inspection (Links and Tasks)

Exercism Elixir Track: Dancing Dots (Behaviours and Use)

Exercism Elixir Track: Lucas Numbers (Streams)

Exercism Elixir Track: Stack Underflow (Exceptions)

Exercism Elixir Track: New Passport (With)

Exercism Elixir Track: RPN Calculator (Errors and Try/Rescue)

Exercism Elixir Track: Need For Speed (Alias and Import)

Some Early Thoughts on LiveView Native

What is LiveView Native?

Worlds Are Colliding!

My Day with LiveView Native

What pain is LiveView Native is trying to solve?

Will Apple approve this?

Conclusions

Random Leftover Draft Notes

Exercism Elixir Track: Captain's Log (Erlang Libraries, Randomness)

The sample `Hello` project

Step 4: Migrate to `heex` Templates (optional)