DEV Community: Joseph Lozano

I created a March Madness predictor CLI in Elixir, then turned it into a web app.

Joseph Lozano — Fri, 19 Mar 2021 16:40:43 +0000

tl;dr It's deployed at https://ncaa-predictor.onrender.com

First step was getting the bracket done. The NCAA Tournament is broken into 4 regions, each containing 16 teams seeded 1 through 16.

The 1 seeded team, plays the 16 seeded team, the 2 plays 15, etc. The tournament is organized to favor the better seeded team, so 1 and 2 are on opposite sides of the bracket. In the end, the first round looks something like this

  @matchups [
    [1, 16],
    [8, 9],
    [5, 12],
    [4, 13],
    [6, 11],
    [3, 14],
    [7, 10],
    [2, 15]
  ]

Next, we recursivlely resolve the games, until there is only 1 left.

def resolve([ _ | _ ] = matchups) do
  matchups
  |> Enum.map(fn [team_a, team_b] -> resolve(team_a, team_b) end)
  |> Enum.chunk_every(2)
  |> resolve()
  end

Enum.chunk_every/2 is especially helpful here.

Next, we implement a naive approach, assuming the better seeded team wins

def resolve({name_a, seed_a} = team_a, {name_b, seed_b} = team_b) do
  if seed_a < seed_b do
    IO.puts "#{name_a} beats #{name_b}"
    team_a
  else
    IO.puts "#{name_b} beats #{name_a}"
    team_b
  end
end

And our base case

def resolve([{name, _seed} = team]) do
  IO.puts "#{name} wins!"
  team
end

Next, we just do this for each of the 4 regions, and put them in a tournament with eachother

def play() do
  final_four = for region <- ["WEST", "EAST", "SOUTH", "MIDWEST"] do
    winner = resolve(@matchups)
    {region, winner}
  end

  resolve(final_four)
end

And that's basically it!

But, better seeds don't always win. So I found some data on http://mcubed.net/ncaab/seeds.shtml, parsed it and came up with a map that shows the percentage of times a seed beats a given seed.

For the first seed, it looks like this

@data %{
  1 => %{
    1 => 50.0,
    2 => 53.3,
    3 => 62.5,
    4 => 70.7,
    5 => 83.3,
    6 => 68.8,
    7 => 85.7,
    8 => 80.2,
    9 => 90.0,
    10 => 85.7,
    11 => 57.1,
    12 => 100.0,
    13 => 100.0,
    14 => 0.0,
    15 => 0.0,
    16 => 99.3
    },
  2 => %{ ... }
}

For some cases, like against 14 and 15 seeds, there is no data, so in that case we assume the better seed wins.

Our resolve/2 function, now looks like

def resolve({_, team_a} = a, {_, team_b} = b) do
  team_a_win_pct = @data[team_a][team_b]

  {winner, loser} =
    if :rand.uniform() * 100 < team_a_win_pct or (team_a_win_pct == 0.0 and team_a < team_b) do
      {a, b}
    else
      {b, a}
    end

  seed_text =
    if team_a_win_pct != 0.0 do
      winner_pct = @data[elem(winner, 1)][elem(loser, 1)]
      "#{elem(winner, 0)} beats #{elem(loser, 0)} seeds #{winner_pct}% of the time"
    else
      "No data for #{elem(winner, 0)} vs #{elem(loser, 0)}. Assuming #{elem(winner, 0)} wins"
    end

  IO.puts(
    String.pad_trailing("#{elem(winner, 0)} beats #{elem(loser, 0)}", 21) <> "\t" <> seed_text
  )

  winner
end

And that's basically it for the CLI! You can check it out on Github if you'd like to check out the final version.

Now, for the deploy. I wrote a basic Plug router (no Phoenix for a project this small)

defmodule NCAA.Server do
  use Plug.Router

  plug(:match)
  plug(:dispatch)

  get "/" do
    {:ok, pid} = StringIO.open("")
    NCAA.play(pid)

    resp_text = StringIO.flush(pid)
    StringIO.close(pid)
    resp_text

    send_resp(conn, 200, resp_text)
  end

  match _ do
    send_resp(conn, 404, "not found")
  end
end

You can see we are passing in a pid to our NCAA.play function. This is because want to capture everything written, so we can send it back to the client (instead of to STDOUT).
That means all of our IO.puts(string) functions change to IO.puts(pid, string). Very straight-forward.

After the winner is calculated, we capture the string with StringIO.flush, and close the process. Then we just send it to the client with send_resp.

Next we need to make sure our server starts up. First in our mix.exs we change def application to

def application do
  [
    mod: {NCAA.Application, []},
    extra_applications: [:logger]
  ]
end

Then create NCAA.Application

defmodule NCAA.Application do
  @moduledoc false
  use Application
  require Logger

  def start(_type, _args) do
    port =
      case Mix.env() do
        :prod ->
          80

        _ ->
          Logger.info("Starting application at http://localhost:4000")
          4000
      end

    children = [
      {Plug.Cowboy, scheme: :http, plug: NCAA.Server, options: [port: port]}
    ]

    opts = [strategy: :one_for_one, name: NCAA.Supervisor]

    Supervisor.start_link(children, opts)
  end
end

In prod we start in port 80, otherwise 4000 is fine.

I deployed this to render. The build script is simply mix deps.get && mix compile and the run script is just mix run --no-halt.

Easy peasy. You can check out at at https://ncaa-predictor.onrender.com for the duration of the tournament, for just clone it yourself from Github and run it with mix run --no-halt.

Thanks for reading.

Testing With Elixir Part 0

Joseph Lozano — Fri, 12 Mar 2021 23:13:43 +0000

This is the first of what I hope will be many posts on testing in Elixir.

This is part 0, and not Elixir-specific. Just the basics of testing.

Given, When, Then

Every (unit) test should be able to be broken down into these parts.

Given some context or situation
When I invoke the function I am trying to test
Then I get the expected result

Let's take a trivial example. I am writing a function to capitalize every other letter of a string.

def spongebob_case(string) do
 # ???
end

Our given is the various cases we are trying to put under test.

cases = [
  "lorem ipsum dolor sit amet, consectetur adipiscing elit",
  "sed do eiusmod tempor incididunt ut labore et dolore magna aliqua",
  "Ut enim ad minim veniam",
  "quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat"
]

Our when is invoking the function with each case. We store this into a variable called actual.

actual = Enum.map(cases, fn kase ->
  spongebob_case(kase)
end)

Our then is making the assertion against our expected result

expected = [
  "lOrEm iPsUm dOlOr sIt aMeT, cOnSeCtEtUr aDiPiScInG ElIt",
  "sEd dO EiUsMoD TeMpOr iNcIdIdUnT Ut lAbOrE Et dOlOrE MaGnA AlIqUa"
  "uT EnIm aD MiNiM VeNiAm",
  "qUiS NoStRuD ExErCiTaTiOn uLlAmCo lAbOrIs nIsI Ut aLiQuIp eX Ea cOmMoDo cOnSeQuAt"
]

assert actual == expected

The full test looks like this:

defmodule SpongebobTest do
  use ExUnit.Case
  import SpongeBob, only: [spongebob_case: 1]

  test "spongebob_case/1 makes every letter other letter upper case" do
    cases = [
      "lorem ipsum dolor sit amet, consectetur adipiscing elit",
      "sed do eiusmod tempor incididunt ut labore et dolore magna aliqua",
      "Ut enim ad minim veniam",
      "quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat"
    ]

    actual =
      Enum.map(cases, fn kase ->
        spongebob_case(kase)
      end)

    assert actual == [
             "lOrEm iPsUm dOlOr sIt aMeT, cOnSeCtEtUr aDiPiScInG ElIt",
             "sEd dO EiUsMoD TeMpOr iNcIdIdUnT Ut lAbOrE Et dOlOrE MaGnA AlIqUa",
             "uT EnIm aD MiNiM VeNiAm",
             "qUiS NoStRuD ExErCiTaTiOn uLlAmCo lAbOrIs nIsI Ut aLiQuIp eX Ea cOmMoDo cOnSeQuAt"
           ]
  end
end

Generally we want to start with 1 simple case, then add more cases, (including edge-cases) as we build out the actual implementation.

Edge cases in this example would be:

What if there is an integer in the input? an emoji? You can't upper case those.
What if the input isn't a string?

Exactly how you handle those edge-cases is usually a product question. As the engineer writing tests, however, it is important that you think about them, and make sure that they are under test.

In future parts, we will talk about how to test GenServers/Processes. Dynamically generating tests, as well as looking at other assertions.

Thanks for reading.

Show Dev: One Million Words

Joseph Lozano — Thu, 13 Aug 2020 22:56:52 +0000

For the readers of my website (which doesn't always get cross-posted to Dev.to), you will know that for this month (as well as following months), I am going to attempt to write a blog post every weekday, inspired by TreTuna's 1000 words for 1000 days challenge.

Tre Tuna

@tretuna

This past week I committed myself back to reading. Currently, it's @swyx's @Coding_Career Handbook, swyx.podia.com/a/p5kuh.

With this, I'm commiting to another objective from Chapter 18, "Write, A Lot," I'm ramping up to the challenge of writing 1000 words/day for 1000 days.

05:25 AM - 10 Aug 2020

Now, the spirit of the challenge isn't to write 1000 public words (private notes also count), but I was thinking about how awesome it would be to have a blog with one million words.

Inspired by this, I am setting out to write at least one million words in my blog (though not necessarily in 1000 days). To help me reach this goal, I built a tool that takes an RSS feed and counts the number of words written. Accordingly, I have named it One Million Words.

This project is still very much a work in progress (for example, it expects your posts to be in a <main> tag), but I wanted to give this community a first peek.

The code is open source. I am very much open to feedback!

Without further ado: One Million Words

Some work I'd like to do:

Save requests to the database
Work on the design.
Automatically update when feeds are updated.
Support content in any arbitrary HTML tag, not just <main>

In future posts, I will walk through the code, the design decisions I made, and how I deployed it.

PS: If you are looking for a feed to try, and have at least one post on Dev.to, try https://dev.to/feed/username, eg: https://dev.to/feed/joseph_lozano

Picking a programming language (for 2020)

Joseph Lozano — Mon, 10 Aug 2020 23:09:02 +0000

spoiler alert: It's Elixir

Why I choose to program in Elixir

First, the negatives

Drawbacks

Elixir isn't a perfect language by any means. Here are some drawbacks of the language:

The static type checker (aka dialyzer) error messages are difficult to understand
The actor model and OTP don't have the best APIs, and they can be difficult to grasp at first
The tooling around the language (such as third-party libraries) is not as complete as say, Ruby, Python, or Java. (This is improving, however)

Positives

It's familiar

I have been programming in Elixir as a hobbyist since 2016, and professionally for a year and a half.
I know it better than I know any other language.
This means that I will more likely be most productive with Elixir compared to other languages.

It's simple

The Elixir language is simple and straight-forward. The build tools just work (I have spent entirely too much time trying to get IntelliJ to use the right JVM for Java projects)
Mix is really cool, testing (including DocTests) are built-in as a language feature.
Phoenix itself is readily familiar to anyone who has built MVC applications.

It's feature rich

Phoenix LiveView is a serious game changer for writing real-time apps with minimal JavaScript.
Seriously, if you haven't check out the 15 minute Twitter clone demo that Chris McCord does.
Phoenix gives you a lot of features out of the box.

It's powerful

Elixir has been used by several organizations to increase traffic. (See Discord, BleacherReport, and others)
Are my app going to have that much traffic? Well, not yet (and probably never), but a lot of this you get for free with the way Elixir concurrency and the Phoenix Framework work.

For all these reasons, Elixir is my language of choice for side projects and random hacking.

Sending email with Elixir and Phoenix 1.5

Joseph Lozano — Thu, 30 Apr 2020 00:23:41 +0000

This is part 2 in a series. In part 1 we created the users model using a generator. In this section, we'll be building the login flow by hand.

Let's start by creating the following files

live/session_live/new.ex
live/session_live/new.html.eex

Let's start with our template, new.html.eex

# lib/feenix_web/live/session_live/new.html.eex
<h1>Log in</h1>
<%= f = form_for :login, "#",
id: "login-form", phx_submit: "login" %>
<div>
  <%= label f, :email %>
  <%= email_input f, :email %>
  <%= error_tag f, :email %>
</div>

<div>
  <%= submit "Save", phx_disable_with: "Saving..." %>
</div>
</form>

This is a form very similar to our New User form, but we only need the email.

Next, let's do the LiveView

# lib/feenix_web/live/session_live/new.ex
defmodule PokerWithFriendsWeb.SessionLive.New do
  use PokerWithFriendsWeb, :live_view

  alias PokerWithFriends.Accounts
  alias PokerWithFriends.Accounts.User

  @impl true
  def mount(_params, _session, socket) do
    {:ok, socket}
  end

  def handle_event("login", %{"login" => %{"email" => email}}, socket) do
    socket =
      case Accounts.get_user_by(email: email) do
        nil ->
          socket
          |> put_flash(:error, "You need to create an account first")
          |> push_redirect(to: Routes.user_new_path(socket, :new))

        user ->
          # TODO: error handling for email
          Accounts.deliver_login_email(user)
            socket
            |> put_flash(:info, "Login email sent")
            |> push_redirect(to: socket.assigns.return_to)
          end
      end

    {:noreply, socket}
  end
end

This isn't as bad as it first looks

mount is doing nothing special

handle_event/3 is receiving the login event with the email. It then checks if a user with that email exists. If not, it forwards to the User/new page, if so, we call Accounts.deliver_login_email(user), leaving a note for ourselves to handle errors. In both cases, we add a helpful flash message

Next, let's create those functions in our Account module.

# lib/feenix/accounts.ex

def get_user_by(params) do
  Repo.get_by(User, params)
end

def deliver_login_email(%User{} = _user) do
  require Logger
  Logger.warn "deliver_login_email not implemented"
  :ok
end

Ok, we need to implement our login email. For that, I am going to be using swoosh

Add swoosh and phoenix_swoosh to your mix deps

# mix.exs
defp deps do
  ...
  {:swoosh, "~> 0.25"},
  {:phoenix_swoosh, "~> 0.2"},
  ...
end

In the our config, let's set swoosh to use the local adapter

config :feenix, Feenix.Mailer, adapter: Swoosh.Adapters.Local

Then, we need to define a mailer. I'll put it in the top level of feenix_web

# lib/feenix_web/mailer.ex
defmodule Feenix.Mailer do
  @moduledoc false
  use Swoosh.Mailer, otp_app: :feenix
end

In our router, there is a line if Mix.env() in [:dev, :test] do which has the live_dashboard route. Inside that if, let's add a new dev scope for our mailbox

scope "/dev" do
  pipe_through [:browser]
  forward "/mailbox", Plug.Swoosh.MailboxPreview, base_path: "/dev/mailbox"
end

Next, we need to create our emails. I'll do this in a new feenix_web/emails folder

# lib/feenix_web/emails/login_email.ex
defmodule FeenixWeb.LoginEmail do
  @moduledoc false
  use Phoenix.Swoosh,
    view: FeenixWeb.EmailView,
    layout: {FeenixWeb.LayoutView, :email}

  def login_email(user) do
    new()
    |> to(user.email)
    |> from({"Feenix", "login@localhost"})
    |> subject("Your login link")
    |> render_body("login_email.html", %{})
  end
end

And as you can probably guess from looking at the code, let's add a login_email.html.eex template.

Here is your login link:

<div>
  <a href="localhost:4000" />
<div>

We haven't created our token yet, but this is a great start.

Now, let's head back to our accounts context, and finish the deliver_login_email function.

# lib/feenix/accounts.ex
alias FeenixWeb.{LoginEmail, Mailer}
def deliver_login_email(%User{} = user) do
  user
  |> LoginEmail()
  |> Mailer.deliver()
end

Now, let's head over to the /dev/emails endpoint we set up and verify that we got the email!

In part 3, we will create the tokens that will actually allow us to login. Until then, happy coding!

My Mac Setup 2020 (for Elixir and Phoenix Development)

Joseph Lozano — Mon, 27 Apr 2020 13:51:23 +0000

I recently did a factory reset on my MacBook Pro. I thought that during the process I would write down what steps I took and what tools I used to get it ready for Elixir/Phoenix development. I am on MacOS 10.15.4

Somethings' Brewin

First thing I always do is install homebrew. Just follow the directions on the official website.

I use brew and brew cask to install almost everything. The only exceptions to this are programming languages (see below) Here's a list of everything I install on a fresh machine. Use brew cask <package> to install.

1password # My password manager of choice
firefox # I try to avoid the the tentacles of Google, so I use Firefox
clipy # Clipboard managers are invaluable
basecamp # I use basecamp personal (free) to keep track of what I am working on
visual-studio-code # Editor of choice
firacode # font of choice
openssl@1.1 # required for elrang
postgres # postgres.app
postico # postgres ui tool

Oh My Zsh

(Oh My Zsh)[https://ohmyz.sh/#install] is a must for me. Just follow the directions on the website. Since new versions of MacOS ship with ZSH as the default shell, its easier than ever. But if you are on an older version, you may need to install and set Zsh as your default shell. I use the gallois theme, and add the asdf plugin.

plugins=(git asdf)

ASDF

With all that installed, next is asdf-vm, my package manager of choice for programming languages. The main benefit it has over brew is that you can install older versions of programming languages, which isn't always possible with brew. Additionally, its nice to have one command for everything, rather than keeping track of kerl, kiex, nvm, etc. separately.

Head over to asdf to install. You can also use brew, but I prefer the git installation. Again, this lets me roll back if I need to. There is an issue with kerl the package manager that asdf uses behind the scenes, and the version of MacOS that I am on (10.15.4). Check out the following post to get it working: https://dev.to/andresdotsh/how-to-install-erlang-on-macos-with-asdf-3p1c

I am currently using the following versions, but you should use whatever is latest (asdf list-all <language>):

erlang 22.3.2 # takes a long time
elixir 1.10.3-otp-22
nodejs 14.0.0

You can set these (or whatever version) as the global default by using
asdf global <language> <version>, ex: asdf global elixir 1.10.3

VSCode

With that setup, we are almost done! Next is VSCode.
I use the following packages

Elixir LS # Aboslutely a must have
Beautify # Formatting html
dark+ Elixir

And I use the following settings in my settings.json

{
    "editor.fontFamily": "Fira Code",
    "editor.fontLigatures": true,
    "workbench.colorTheme": "dark+(elixir)",
    "files.autoSave": "onFocusChange",
    "editor.tabSize": 2,
    "editor.renderWhitespace": "boundary",
    "editor.parameterHints.cycle": true,
    "editor.renderControlCharacters": true,
    "files.trimTrailingWhitespace": true,
    "window.zoomLevel": 2,
    "editor.formatOnSave": true,
    "editor.wordWrapColumn": 100,
    "[json]": {
        "editor.defaultFormatter": "lonefy.vscode-JS-CSS-HTML-formatter"
    },
    "elixirLS.fetchDeps": false,
    "[HTML (EEx)]": {},
    "files.associations": {
        "*.js": "javascript",
        "*.ex": "elixir",
        "*.exs": "elixir",
        "*.eex": "HTML (EEx)",
        "*.leex": "HTML (EEx)",
        "*.html.EEx": "HTML (EEx)"
    },
    "beautify.language": {
        "js": [],
        "css": [],
        "html": [
            "HTML (EEx)"
        ]
    },
    "emmet.includeLanguages": {
        "HTML (EEx)": "html"
    }
}

"files.associations" and "beautify.language" is crucial to get autoformatting working correctly for *.eex files.

Gitlab and Github

Finally, set up your SSH keys so that you can clone and push your repositories. I primarily use Gitlab for my own personal projects (another blog post), and GitHub for things I intend to be public. Follow the instructions on Gitlab to setup a key, and add them to your accounts.

Closing

That's basically everything I did to set up my Mac for Phoenix and Elixir development in 2020. If I missed anything, or you just want to share what your setup looks like, comment below!

Setting up a new Phoenix 1.5 project! (With Phoenix LiveView!)

Joseph Lozano — Sat, 25 Apr 2020 22:10:42 +0000

Phoenix 1.5 is out! Phoenix Live view is now part of the Phoenix Framework! For a quick introduction to what Phoenix Live View is about, checkout this video by Chris McCord, the creator of Phoenix. This series will dive a bit more into setting up a new Phoenix app.

Check out the source repo

Part 1 will be about generating scaffolding code, and explaining a bit about how live view works.
In part 2 we will implement magic links, ala slack, and we will hide the app behind the login.

As in the video, we initialize the project with --live

mix archive.install hex phx_new 1.5.1 # Install the 1.5.1 phx_new generator
mix phx.new feenix --live && cd feenix # Create and enter the project
git init && git add -A && git commit -m "init" # create init commit

Users Users Users

Users are the center piece of any application. Our application will make use of ~Magic Links~ ala Slack, so no need for a password field. Let's generate our Accounts context and User schema.

mix phx.gen.live Accounts User users email:string username:string

Let's look at this command piece by piece

mix phx.gen.live New live view generators in Phoenix 1.5. The live view equivalent of mix phx.gen.html
Accounts The name of our domain context
User The module name for the schema we are creating
users The name of the database field attached to the schema
email:sttring username:string The fields and their types

Add the live routes to your browser scope in lib/feenix_web/router.ex:

live "/users", UserLive.Index, :index
live "/users/new", UserLive.Index, :new
live "/users/:id/edit", UserLive.Index, :edit

live "/users/:id", UserLive.Show, :show
live "/users/:id/show/edit", UserLive.Show, :edit

Next, let's go into the CreateUsers migration and unique indexes for email and username to the users table. The changeset function should now look like

# priv/repo/migrations/XXXXXXXXXXX_create_users.exs
def change do
  create table(:users) do
    add :email, :string
    add :username, :string

    timestamps()
  end

  create unique_index(:users, :email)
  create unique_index(:users, :username)
end

This will both create an index in the database (for fast searching) and create a unique constraint.

Next, let's update the changeset to enforce the new unique constraint. The new changeset should look like

# lib/feenix/acconts/user.ex
def changeset(user, attrs) do
  user
  |> cast(attrs, [:email, :username])
  |> validate_required([:email, :username])
  |> unique_constraint(:email,
    name: "users_email_index",
    message: "Account already exists. Please log in."
  )
  |> unique_constraint(:username,
    name: "users_username_index",
    message: "Username already in use. Please use another."
  )
end

And lastly, let's just fix the input in our new/edit form

# lib/feenix_web/live/user_live/form_component.html.leex
<%= email_input f, :email %> # change text_input to email_input

Now that we have the users set up, let's commit

git add -A && git commit -m "Set up user accounts"

Looking around

Let's check out our new application. and compare it to what we would have gotten if we used phx.gen.html as our scaffolding generator.

First thing to notice is that there are no controllers. Instead there is a live/user_live folder which contains both the LiveViews and templates. Also of note, is that there are only 2 LiveViews, Index and Show (as well as a FormComponent). Let's start with the index template.

Live Templates

# lib/feenix_web/live/user_live/index.html.leex
<h1>Listing Users</h1>

<%= if @live_action in [:new, :edit] do %>
  <%= live_modal @socket, FeenixWeb.UserLive.FormComponent,
    id: @user.id || :new,
    title: @page_title,
    action: @live_action,
    user: @user,
    return_to: Routes.user_index_path(@socket, :index) %>
<% end %>

<table>
# ommited for space
  <span><%= live_redirect "Show", to: Routes.user_show_path(@socket, :show, user) %></span>
  <span><%= live_patch "Edit", to: Routes.user_index_path(@socket, :edit, user) %></span>
  <span><%= link "Delete", to: "#", phx_click: "delete", phx_value_id: user.id, data: [confirm: "Are you sure?"] %></span>
# ommited for space
</table>

<span><%= live_patch "New User", to: Routes.user_index_path(@socket, :new) %></span>

The first interesting thing on the page is the if @live_action check, within which is a function live_modal. After that, the familar table. Each row in the table has a link to "Show" "Edit" and "Delete". But take a look at them a bit more closely. The "Edit" link is not a link at all. It is live_patch. And the href goes to the user_index_path with the :edit action. This is the @live_action above. So clicking on that link will trigger the modal, since it will set @live_actiton to :edit

Next the "Delete" link navigates to "#". It has an attribute phx_click: "delete". We will see how this works once we check out the live view.

Finally, the "New User" link at the bottom is also a live_patch like "Edit" above, however this time the action is :new.

Next, let's look at the Index LiveView proper

LiveViews

# lib/feenix_web/live/user_live/index.ex
defmodule FeenixWeb.UserLive.Index do
  use FeenixWeb, :live_view

  @impl true
  def mount(_params, _session, socket) do
    {:ok, assign(socket, :users, fetch_users())}
  end

  @impl true
  def handle_params(params, _url, socket) do
    {:noreply, apply_action(socket, socket.assigns.live_action, params)}
  end

  defp apply_action(socket, :edit, %{"id" => id}) do
    socket
    |> assign(:page_title, "Edit User")
    |> assign(:user, Accounts.get_user!(id))
  end

  def handle_event("delete", %{"id" => id}, socket) do
    user = Accounts.get_user!(id)
    {:ok, _} = Accounts.delete_user(user)

    {:noreply, assign(socket, :users, fetch_users())}
  end
  # rest ommited for space
end

The mount function sets up page initially. In this case, you can see that the socket is being assigned :users with users fetched from the database

handle_params is triggered by clicking on links with the live_patch function. The @live_action of :edit, :new, or :index is set automatically, and the appropriate assigns are applied to the socket.

Finally, handle_event is what was triggered with the phx_click attribute. The attribute value is the first arguement to handle_event.

The "show" template and live view is largely similar.

Live Components

Components are a mechanism to compartmentalize state, markup, and events in LiveView.

To see how this is being used in our app, first let's check out our live helpers at lib/feenix_web/live/live_helpers.ex

# lib/feenix_web/live/live_helpers.ex
def live_modal(socket, component, opts) do
  path = Keyword.fetch!(opts, :return_to)
  modal_opts = [id: :modal, return_to: path, component: component, opts: opts]
  live_component(socket, FeenixWeb.ModalComponent, modal_opts)
end

This explains the live_modal functions in our templates from earlier. We see here that live_modal is just a helper to invoke live_component for our ModalComponent.

Check out the ModalComponent, we see some an inlined live view template, which itself calls live_component with @component. @component here is our FormCoponent.

Components compartmentalize state, and we see for our FormComponent, it looks like a live view all on its own. There is a key difference though, since the unlike the LiveView, a Component, is not a separate proess (it is part of its parent LiveView process), it does not have a handle_info callback. Instead, from the parent LiveView, we can use send_update to update the Component state.

The update callback on Component is also invoked after mount.

Closing thoughts

One of my favorite things about Elixir and Phoenix is that there isn't a lot of magic that happens. And the magic that does happen is at just the right point of abstraction. As a developer, you define templates which get populated but the socket assigns. If the assigns change, the rendered page changes. It's really that simple.

If you have any corrections to this post, or anything that you feel like should have been included, please feel free to reach out to me at joseph@joseph-lozano.com

Edit:

So, by adding our unique contraints, we actually broke a few of the tests that came with our generator. Let's fix them.

The root of the issue is that we are creating a fixture user as part of the setup. Let's just create another set of attributes @save_attrs %{email: "other@email.com", username: "some username"}

Then, update the failing test to use the new attrs.

# test/feenix_web/live/user_live_test.exs:45
{:ok, _, html} =
  index_live
  |> form("#user-form", user: @save_attrs)
  |> render_submit()
  |> follow_redirect(conn, Routes.user_index_path(conn, :index))

In future posts we will make use of TDD to avoid this issue in the future.

Originally posted at https://joseph-lozano.com

Hello, World!

Joseph Lozano — Sat, 25 Apr 2020 22:04:03 +0000

I have been meaning to start writing a blog for some time. Now I have no excuse. The reasons for writing a blog, especially as a software engineer, are numerous, and don't warrant repeating here.

So, what to write about after the customary "Hello, World!"? I suppose an introduction

About me

Connexity

I have been a software engineer for just over 4 years as of this writting. I got my start at Viking Code School, an online bootcamp, then got my first job in the field doing Ruby on Rails development at an advertising company Connexity. As this was my first role out of bootcamp, there was of course a lot of learning.

One of the principle lessons I took away from working here is how important product domain knowledge is for a software engineer. As most junior developers do, I got started with simple tasks. Add a button here, fix a bug there, etc.; as I grew at this role, I gained a better understanding of the product, and even was able to contribute a small project of my own, an alerting app that I wrote in a new programming language called Elixir (more on that later). I wrote that project during 10% time, and while it never made it into production, I think it was one of the greater learning experiences during my time here.

CJ Affiliate

After working at Connexity for a time, I was ready to move on and try something new. I got a job at a CJ Affiliate, where I worked with Java, Scala, React, and towards the end of my time there, Haskell.
I bucked the trend where developers would move from languages like Java to Ruby, and I am very grateful that I did.

Working in languages such as Java, Scala, and Haskell changed me as a software engineer. Learning to work and think in types definitely helped me, and it was also here that I took on a bigger responsibily in DevOps, learning a lot about AWS.

Working at CJ was very structured. Pair programming was the norm, and doing solo work was highly discouraged. TDD was enforced, strongly, and demos, reviews, retrospectives and plannings seemed to take over the work-week. Nevertheless, I learned a lot. I learned how to write tests. I learned the benefits of pair-programming. I learned the benefits of frequent demos and the importance of working closely with product.

SimpleBet

Despite how beneficial working at CJ was for my growth as a software engineer, I was eager for more. I wasn't excited by the product, and I felt I was ready to leave the nest. I got a job at SimpleBet, at sports betting start up. At SimpleBet, I wrote nearly 100% Elixir, a functional programming language that quickly became my favorite language to write.

I was hired as a mid-level software engineer at SimpleBet, but took on the responsibilties of a senior engineer, and was eventually promoted into that role. Like any start I had to learn quickly, and as I a senior engineer, I participated in guiding junior engineers and helping to make key architecture decisions.

What's next?

Unfortunately, I was let go from SimpleBet due to the COVID-19 crisis, so I am available to hire. This was the principle reason for starting to write a blog. In the near future, I hope to write about the topics bolded above, so look out!

I am not especially particular about working in a certain programming language. I consider myself a generalist, and can pick up any programming language with some time.
I have experience working across both Object-Oriented and Functional languages, and static and dynamically typed languages, but there is always a whole lot to learn! I am eager to find a role where I can both continue to learn and make an impact, whether that is on architecture, culture, teaching other engineers. Reach out to me at joseph@joseph-lozano.com, and let's talk!

Originally posted at https://joseph-lozano.com