It was October 15th and I was spending a few minutes scrolling my LinkedIn feed when something caught my attention — an announcement for the kickoff of Toyota Racing Development's Hack the Track hackathon.

I don’t know much about racing, but I’ve always loved cars since I was a boy. I looked into this hackathon some more and started to become increasingly interested. It was an opportunity to build something using a unique dataset from the world of motorsports.

This was certainly something out of left field for me, but the more I learned about how racing teams deal with massive amounts of live-streamed data — from car sensors to weather systems — the more I realized something:

this was a perfect opportunity to push the BEAM’s real-time strengths into a completely new domain — motorsport telemetry.

After reading the contest description, one category stood out immediately:

Real-Time Analytics — Design a tool that simulates real-time decision-making for a race engineer.

That was it. The perfect match for Elixir, Phoenix, and OTP.

I hesitated for a night — it was a big leap into a domain I knew nothing about — but the next day, I joined the hackathon.

Now the question was: what would I build?

🧩 Making Sense of the Data Jungle

The organizers released gigabytes of CSVs: lap timing data, race results, track weather, and — most interestingly — telemetry data from the GR Cup race cars.

At first glance, it was overwhelming. Millions of rows, hundreds of fields with names like accx_can, pbrake_f, Laptrigger_lapdist_dls. I didn’t even know what half the abbreviations meant.

I started simple — using tools like less, grep, and Excel to poke around. Then it clicked: Each row wasn’t just a data point — it was a heartbeat from the car.

Telemetry captures everything happening inside a racecar every fraction of a second: speed, throttle, brake pressure, gear changes, acceleration, GPS position.

And if I could take those heartbeats and replay them live, I could recreate the rhythm of a race — not a static CSV, but a living timeline of events.

That idea became the foundation of what I came to call GRapple (because it grapples with lots of data 🙂):

a real-time race replay, analytics, and strategy system powered by Elixir and OTP.

⚙️ Turning Data into Motion

My first task was to sort the telemetry chronologically. That sounds simple, but the dataset wasn’t ordered, contained duplicates, and was over 11 million lines long, so I used Unix sort and uniq and wired those tools into Elixir for performance.

Once sorted, I used NimbleCSV to parse each lazily streamed event into well-defined structs. The core of it looks like this:

@doc """
  Parses the given Telemetry Data CSV file into a lazy Stream of chronological TelemetryPoints.
  WARNING: this function can take a few minutes if the CSV file is large (GBs)
  """
  @spec parse_stream!(filename :: String.t()) :: {integer(), Enumerable.t()}
  def parse_stream!(filename) do
    cleaned_telemetry_file = clean_file!(filename) # remove dups
    sorted_telemetry_file = sort_file_by_timestamp!(cleaned_telemetry_file)
    telemetry_count = num_data_points(sorted_telemetry_file)

    stream =
      File.stream!(sorted_telemetry_file)
      |> TelemetryParser.parse_stream(skip_headers: false)
      |> Stream.map(fn row ->
        try do
          TelemetryPoint.from_row!(row)
        rescue
          e in [MatchError, ArgumentError] ->
            Logger.debug("Skipping unparsable row: #{inspect(row)} (#{Exception.message(e)})")
            nil
        end
      end)
      # reject any rows that failed to be parsed
      |> Stream.reject(&is_nil/1)
      |> compute_deltas()

    {telemetry_count, stream}
  end

compute_deltas/1 does something interesting. It looks at the timestamps of two successive telemetry events, computes the delta of the next event, and stores this inside the struct for the current event. This way, when we replay the telemetry event live, we know exactly how long to wait between any two events and can simulate the race.

Then came the fun part: I needed a process that would emit those events live at the same timing intervals they originally happened (using our deltas from before). Enter the TelemetryReplayer.

At first, I was thinking to broadcast every telemetry row as a message on a Phoenix PubSub topic so other processes could subscribe, react, and compute metrics in real time. This would work great when I incorporate LiveView later on. But for now since I'm still building the backend, I decided I would keep it simple and just have the TelemetryReplayer cast each telemetry event to its associated car GenServer (which I would implement next).

At last, everything was starting to come together. I had gone from millions of rows of CSV files to well-defined data streaming in real time using the power of OTP. Seeing that first replay run felt surreal — after days of CSV wrangling, a virtual race had come to life in my terminal.

This was a truly motivating moment and I was ready to keep moving forward. It's not enough to replay the race live. If I could have one GenServer process per car consuming its telemetry events and keeping rolling metrics as its state, I could unlock a whole new world of possibilities when it comes to analytics and insight.

📊 Teaching GRapple to Think

Once the race replay worked, the next challenge was to give GRapple some intuition.

I built a MetricsServer, one GenServer process per car, that tracks real-time statistics — speed, throttle, brake pressure, soon acceleration, steering, and much more.

Each process consumes its car's telemetry events, and maintains rolling per-lap stats, smoothing raw signals with exponential moving averages (EMA) to highlight trends in driver behavior. Once a new lap starts, it stores the past lap in its own history. Each process is supervised by a MetricsServerSupervisor for fault-tolerance.

This way, I could get the metrics for any car in the race at any given time by looking at the state of its associated running process. It also helps tremendously in reasoning about the system and keeps things simple: each process knows its car's performance best. Using hand-crafted test CSV files, I started to see the system in action and it was mesmerizing. Data was flowing from a CSV file to the TelemetryReplayer to a car's MetricsServer, which would perform rolling metrics calculations in real time.

And this was just the beginning. Eventually, I am hoping to implement another dedicated Analytics process that will query each MetricsServer and derive higher-level race insights.

🧠 What I've Learned So Far

This project reminded me why I love Elixir and the BEAM.

• The Actor Model is perfect for modeling a race with multiple cars.
• OTP made concurrency predictable.
• Streams let me handle millions of rows lazily and efficiently.
• Elixir is the right tool for this job.

There's quite a bit until I get to the finish line with this project, but it's been refreshing stepping into the world of motorsports and a joy using Elixir so far.

🚀 The Road Ahead

In the next stage, I’ll start extending the MetricsServer to compute more metrics per car using the telemetry events. So far, I've implemented speed, throttle behavior, and brake pressure rolling metrics, but will need to add acceleration, lateral G (for cornering insight), steering, lap timing, and (if time permits) lap section comparison for more insight. Eventually, I will connect it to AI models via Replicate to simulate a race engineer that can answer live questions about performance and even strategize race decisions.

I'll be writing some more blog posts as I continue building GRapple for the Toyota Hack the Track 2025 challenge. Stay tuned.

Why I Chose to Build My Resume with LiveView

Before writing my resume in Elixir and Phoenix, I searched the web for existing solutions to the extensible, modular, versioned resume problem. I found a few options, the most prominent being RxResume and JSON Resume. I actually created an account on RxResume and tried creating my resume. I found it to be a very polished experience and excellent for most use cases. However, I wanted to own my data and version my resume content rather than the finished product. This led me to stumble upon JSON Resume. I liked the well-defined format, but didn't want to use JSON. I wanted to build something in pure Elixir that would

• Emphasize modularity and flexibility
• Support Git-based versioning
• Cleanly separate resume content and presentation
• Provide a streamlined development experience
• Make resume writing and editing fun

Eventually I decided I would build my own solution for myself. I might open-source the code in the near future, but for now, I am keeping my resume content along with the app code for easier versioning.

Designing Resume Data

I bootstrapped this project with phx_new version 1.8.0-rc3, which at the time of writing, had the latest and greatest of Phoenix features and updates. I really liked that it had DaisyUI and a theme-changer component out-of-the-box. It's nice to get dark-mode support free for easier nighttime resume writing.

The first step was to design my data. A good data definition goes a long way in thinking about and solving problems, so I opted for creating structs for all relevant parts of a Resume. This way, I can expect certain keys in my resume data and also receive compile-time checks.

defmodule LiveResume.Resumes.Resume do
  @moduledoc """
  Represents a Resume with basic personal and professional information.
  """
  alias LiveResume.Resumes.{
    Bio,
    EducationalExperience,
    Certification,
    Skill,
    Project,
    WorkExperience,
    Link
  }

  @type t :: %__MODULE__{
          bio: Bio.t(),
          education: [EducationalExperience.t()],
          certifications: [Certification.t()],
          skills: [Skill.t()],
          projects: [Project.t()],
          work_experiences: [WorkExperience.t()],
          social_links: [Link.t()]
        }

  defstruct bio: %Bio{},
            education: [],
            skills: [],
            projects: [],
            certifications: [],
            work_experiences: [],
            social_links: []
end

Here is my definition of a Resume. I won't show all struct code here for the sake of brevity.

Loading Resume Data at Runtime

Now that I had an outline of what my resume content would look like, I needed a way to store it in a file and load it at runtime for use in my app. Elixir has a useful function called Code.eval_file/2, which evaluates the expressions in a file and returns the result. Now all I needed to do was write a Resume inside a my_resume.exs file. But where would I store this file? As I mentioned before, I wanted my resume files to live in the codebase along with my app code for maximum simplicity and convenience. My main priority was to create an app that was useful to me and solved a real problem I had been having, not to share my code. In Phoenix projects, static files typically live inside the project priv/ directory, so I created priv/resumes to hold my resume .exs files. Here is an example of what my resume files look like:

Because this evaluates Elixir code, the application loads only version-controlled resume files that I control. It is not appropriate for uploaded or otherwise untrusted files.

# priv/resumes/test_resume.exs
alias LiveResume.Resumes.{
  Resume,
  Bio,
  Certification,
  EducationalExperience,
  Skill,
  Project,
  WorkExperience,
  Link
}

%Resume{
  bio: %Bio{
    name: "Your Name Here",
    headline: "Full Stack Developer",
    address: "100 Tawheed Way, Sometown, TN",
    phone: "(555)-555-5555",
    email: "me@me.com"
  },
  education: [
    %EducationalExperience{
      school: "Northeastern University",
      location: "Boston, Massachusetts",
      degree: "Bachelor of Arts",
      field: "Computer Science",
      start_date: ~D[2017-09-05],
      end_date: ~D[2021-04-16],
      grade: "cum laude",
      note: "Member of the Honors Program",
    },
    %EducationalExperience{
      school: "Madison Academic Magnet High School",
      location: "Jackson, TN",
      degree: "High School Diploma",
      note: "Honors",
      start_date: ~D[2013-08-01],
      end_date: ~D[2017-05-20]
    }
  ],
  certifications: [
    %Certification{
      name: "Certified in Cybersecurity (CC)",
      issuer: "ISC2",
      issue_date: ~D[2025-02-16],
      expiration_date: ~D[2028-02-29]
    }
  ],
  skills: [
    %Skill{name: "Elixir", strength: 8},
    %Skill{name: "Python", strength: 7},
    %Skill{name: "C/C++", strength: 7},
    %Skill{name: "JavaScript", strength: 7},
    %Skill{name: "Bash", strength: 6},
    %Skill{name: "HTML", strength: 7},
    %Skill{name: "Phoenix", strength: 7},
    %Skill{name: "ReactJS", strength: 4},
    %Skill{name: "React Native", strength: 3},
    %Skill{name: "TailwindCSS", strength: 5},
    %Skill{name: "Linux (Ubuntu, Debian, Kali)", strength: 9},
    %Skill{name: "Docker", strength: 5},
    %Skill{name: "Git", strength: 7}
  ],
  projects: [
    %Project{
      name: "LiveCalculator",
      description: """
      LiveCalculator is a LiveView calculator app. It works great!
      """,
      completed_date: ~D[2025-04-20],
      link: %Link{
        url: "https://github.com/my_account/live_calc",
        name: "github.com/my_account/live_calc"
      },
      skills: [
        %Skill{name: "Elixir"},
        %Skill{name: "Phoenix"},
        %Skill{name: "LiveView"},
        %Skill{name: "OTP"},
        %Skill{name: "JavaScript"},
        %Skill{name: "TailwindCSS"},
        %Skill{name: "Docker"},
        %Skill{name: "Fly.io"}
      ],
      details: [
        "Built a LiveView calculator app using Elixir, Phoenix, and OTP",
        "Leveraged Phoenix Channels and GenServers to handle all client interactions",
        "Used PicoCSS for UI styling"
      ]
    },
    %Project{
      name: "Bulls",
      description: "",
      completed_date: ~D[2025-05-13],
      skills: [
        %Skill{name: "Elixir"},
        %Skill{name: "Phoenix"},
        %Skill{name: "LiveView"},
        %Skill{name: "TailwindCSS"}
      ],
      details: [
        "Built an realtime multiplayer number guessing game",
        "Emphasizes idiomatic Elixir architecture and clean, component-driven design"
      ]
    }
  ],
  work_experiences: [
    %WorkExperience{
      organization: "Some Company",
      location: "Sometown, CA",
      position: "Software Engineer I, II",
      start_date: ~D[2021-12-01],
      end_date: nil,
      details: [
        "Held a software engineering position on the Software Team",
        "Developed software features, investigated operational issues, and fixed software problem reports",
        "Oversaw cybersecurity, ensuring compliance with industry-standard practices and hardening all network access points",
      ]
    },
    %WorkExperience{
      organization: "Another Company",
      location: "Sometown, ID",
      position: "Full Stack Software Development Intern",
      start_date: ~D[2020-08-01],
      end_date: ~D[2020-12-01],
      details: [
        "Developed core gameplay and UI features for a multiplayer party game built with React Native",
        %Link{name: "App selected as Apple App Store App of the Day in December 2022", url: "https://example.com"},
        "Practiced Behavior Driven Development and wrote integration tests using Jest"
      ]
    }
  ],
  social_links: [
    %Link{url: "https://github.com/my_account", name: "GitHub"},
    %Link{url: "https://linkedin.com/in/my_account", name: "LinkedIn"}
  ]
}

And with that, we've represented a resume in pure Elixir that is ready to be version-controlled and used in our LiveView; no database needed. With the Model done, now we move on to the LiveView.

Generating my LiveViews

At this point, I knew that I would need two LiveViews: one that would index all of my available resumes, and another that would show a resume. I could bootstrap both quickly with Phoenix's generator mix phx.gen.live Resumes Resume resumes throwaway:string rather than writing all of this myself. I used a generator even though I didn't have a database or Ecto schemas, mainly to get the preliminary context and LiveView starting point. The throwaway field was added because the generator requires it, but it was easy to remove all database-related code afterward. I also did this so that if the app's needs grew or I decided to use a database backend, the necessary scaffolding would already be in place. With that done, I had my routes and initial LiveViews set up. My router looked like this:

scope "/", LiveResumeWeb do
  pipe_through :browser

  # get "/", PageController, :home
  live_session :default do
    live "/", ResumeLive.Index, :index
    live "/resumes/:id", ResumeLive.Show, :show
    # live "/resumes/new", ResumeLive.Form, :new
    # live "/resumes/:id/edit", ResumeLive.Form, :edit
  end
end

Customizing the LiveViews

Phoenix uses 'layouts' to separate common page structure out of different views. This made it really easy to get started designing my pages. In fact, I mostly kept the initial app/1 layout in layouts.ex as is with a few edits. All I needed to do on my index page is list all resumes.

defmodule LiveResumeWeb.ResumeLive.Index do
  use LiveResumeWeb, :live_view

  alias LiveResume.Resumes

  @impl true
  def mount(_params, _session, socket) do
    {:ok,
     socket
     |> assign(:page_title, "All Resumes")
     |> assign(:resume_files, Resumes.list_resumes_friendly())}
  end

end

Now that our index LiveView has an assigns of @resume_files , I just need to render them. Here is my thin home page:

# index.html.heex
<Layouts.app flash={@flash}>
  <.header>All Resumes</.header>
  <ul class="menu menu-lg bg-base-200 rounded-box w-full">
    <%= for resume_file <- @resume_files do %>
      <li class="flex flex-row items-center">
        <.link navigate={~p"/resumes/#{resume_file}"} class="grow">
          <.icon name="hero-document-text" class="size-6" />
          {resume_file}
        </.link>
      </li>
    <% end %>
  </ul>
</Layouts.app>

It looks like this. Simple and clean, just what I was going for.

My LiveResume home page.

Building the Main Resume LiveView

Now it's time for the core of the entire app: the Resume LiveView. My vision was to enable myself to design my resume as a HEEx template. I've grown to really enjoy the Phoenix workflow of making template edits and seeing the changes refresh live. It's fast, effective, and fun. What I've learned over the years writing and editing my resume in documents and word editors is that they can be clunky at times and it's hard to get everything the way you want without researching each editor's specific way of doing things. As a Full Stack developer, the design language I know and use frequently is HTML and CSS. I don't want to learn how to format a document in MS Word, Google Docs, or LibreOffice individually. With DaisyUI and TailwindCSS, I could control every aspect of the display in a familiar way.

The one issue I kept turning over in my mind was how I would export the resume when finished. Ideally, I would like to export to PDF, but after doing some searching, I found that I would need some external dependencies for that and I did not want to go that route at this time. My solution to this is that when finished, I would just print the webpage and use the print controls to save the final resume as a PDF. The option to 'Save to PDF' when printing exists on all systems and the printing options are decently sufficient for controlling margins and other paging idiosyncrasies.

With my user-story in mind, now I could start implementing my dream resume builder. I wanted to take advantage of Phoenix's layout system to create swappable templates for my resume content. I wanted to use separate HEEx templates per resume layout, but how could I render different HEEx templates dynamically when the :show Live action can only render one template? My solution to this issue was inspired by how Phoenix itself handles routes in the application.

Dynamically Rendering Templates within a Live Action

If you've ever noticed at the very bottom of your web context, the one named <MyApp>Web, there is a small but powerful function that sits at the heart of routing in our application.

@doc """
When used, dispatch to the appropriate controller/live_view/etc.
"""
defmacro __using__(which) when is_atom(which) do
  apply(__MODULE__, which, [])
end

Kernel.apply/2 calls a function from a module with arguments. Phoenix uses this to figure out which template to render based on the actions defined in the router. We can reuse this idea for our resume templates.

First, I added a directory specifically for resume layouts in components/layouts/resumes which would hold each resume template.

I then created a small wrapper ResumeLayouts module for interfacing with it.

defmodule LiveResumeWeb.ResumeLayouts do
  @moduledoc """
  This module holds the Resume layouts.

  See the `layouts/resumes` directory for all templates available.
  """
  use LiveResumeWeb, :html

  embed_templates "layouts/resumes/*"
end

Now, each template defined in components/layouts/resumes is a function inside the LiveResumeWeb.ResumeLayouts module. Since the template name comes from a URL parameter, I use an explicit function allowlist instead of converting arbitrary input to an atom.

# show.html.heex
<%= if !@resume do %>
  <Layouts.app :if={!@resume} flash={@flash}></Layouts.app>
<% else %>
  {render_template(@template, assigns)}
<% end %>

But where did the @template assign come from? I parse it out from the URL as a query parameter in every request to the LiveView and store it in the socket.

# show.ex
@impl true
def handle_params(params, _uri, socket) do
  template = Map.get(params, "template")

  {:noreply,
    socket
    |> set_template(template)}
end

defp set_template(socket, nil), do: assign(socket, :template, "default")
defp set_template(socket, template), do: assign(socket, :template, template)

defp render_template("test", assigns), do: LiveResumeWeb.ResumeLayouts.test(assigns)
defp render_template(_template, assigns), do: LiveResumeWeb.ResumeLayouts.default(assigns)

The fallback clause handles unknown template names without creating atoms from user-controlled input. A simple test in the browser showed that dynamic resume template rendering was working, so I could continue building the templates and editor UI.

Building Out the UI

Rendering the resume in the template is where the real work takes place, so I took some time to carefully design a resume that I liked and worked for me. There's not much to say about it since it is just styling with DaisyUI and TailwindCSS. Here's how our test resume from above looks like using the default template I designed:

Here's what it looks like in dark mode:

It's nice to be able to build out your resume using the stack you know and love and seeing updates in real-time as the whole thing comes together as each component gets built.

I added a drawer UI component from DaisyUI to hold the theme-changer, template selection, and other settings. This way, the main resume design experience is kept clean with nothing in the way so I can focus on designing my resume.

The 'Reload Resume' button re-evaluates our resume .exs file in case we made any content changes to it.

Exporting

With my resume done, I'm ready to export to PDF or print if I want. Using the browser's print dialog, I can adjust the page settings before saving to PDF. I like to set the margins to 0.5 inches.

You may have noticed that the icons are missing in the final exported resume. This is because the hero icons included in Phoenix by default are SVGs that are not inlined but are instead fetched. When the browser tries to print (i.e. export) the page, since the SVGs are not included in the markup inline, they are skipped. There are some workarounds to this which I left for another day.

Challenges and Reflections

Throughout the project, there were a few challenges that needed tailored solutions. They included

• Navigating LiveView layout overrides
• Making the UI printable without compromising design
• Building a flexible component-based system for layouts
• Balancing developer UX and maintainability

In overcoming each of them, I tried to balance simplicity and extensibility. In case I want to take the project further by adding new resume fields, designing new resume templates, or using a database for persistence, I have the ability do so fairly easily without breaking existing features or templates.

Wrapping Up

Right now, this project is closed source, mainly because I am keeping my resume data with personal information alongside the application code for developer convenience. However, in the future, I might abstract the resume parsing and layout features into a separate library that could be released as open source for other developers. I am also working on solving the inline SVG issue during resume export.

LiveResume solved a real problem for me and it's how I write, design, and version my resumes from now on. I'm really enjoying designing my resumes in it especially with the tight feedback loop of Phoenix live reloading and endless customization options with DaisyUI and TailwindCSS.

I'm working on some other projects right now as well. Stay tuned for more app breakdowns.