Elixir + OTP framework is an incredibly powerful combination. We leverage it to build highly scalable and distributed web apps, and IoT systems. But can we use that power to re-create a popular RPG battle system using basic OTP concepts and LiveView? Sharpen your swords and pack your bags of holding because we’re gonna find out!

I have always liked developing tools that assist me in my life and in my programming workflow. So when I attended the ElixirConf 2018 Nerves advanced training and came home with a nice 7” Raspberry Pi touchscreen I knew that I didn’t want it to just sit there and collect dust. So I put it to work and integrated it into my daily workflow.

In this talk I will describe the programs that I run on a Raspberry Pi that sits on my desk and have become a valued part of my daily workflow. The programs are built with Scenic, Phoenix and BlueHeron.

We have delivered a large distributed event-driven solution in AWS with GraphQL API’s. Learn how our architecture evolved and how we optimized absinthe for production.

Startup engineering teams have to be agile, responding quickly to customer needs and shipping them in days or weeks, not months. This often involves taking on technical debt to survive. Startups that find success, however, reach an inflection point where customers rely on their service, so it needs to be dependable and scalable to retain customers. These needs require changes in communication, planning, development, and deployment practices - a shift from a startup mindset to an enterprise mindset.

Veeps succeeded in bringing to market a platform that provided what was wanted: a livestream experience that both the artists and fans enjoyed. With that success came growing pains. Bottlenecks in the Rails app caused headaches, as the demand for their platform outpaced the platform’s ability to keep up. Veeps decided it was time to take the next step, and brought in DockYard to help.

In this talk, Veeps CTO Vinnie Franco and DockYard Senior Software Engineer Mike Binns discuss this process: the initial pains felt on the legacy app, the decision to bring in DockYard to help, the process improvements that Veeps and DockYard put in place, and the decision to rewrite the Veeps app in Elixir.

Combining LiveView & Presence to quickly and easily solve the type of problem that would normally require a team of people

The title says it all- we wrote an entire SPA in LiveView! And it was great. Want to know how we did it? Come to this talk!

Most LiveView projects are small or feature-oriented: a table that sorts without reloading the page, a real-time analytics dashboard, or perhaps a chess game between friends. We had an ambitious project to roll our entire product into one LiveView app, which meant we needed authentication, routing, a navigation stack, state-dependent validation and progressions, asynchronous communication with our backend, and per-customer skinning. As a bonus, our SPA is embedded in third-party websites, so we had to deal with Javascript sourcing, third-party cookies, and security concerns as well.

Although we had a JS pro on our team, we all preferred writing Elixir. So we went for it, and you can too.

This talk will examine our architecture, approach, and lessons learned. We’ll look at code samples, best practices, and worst practices. Along the way we’ll see how LiveComponent and Surface are driving the edges of what’s possible. At the end I hope that you’ll create a new frontier with your own LiveView app. And then we’ll all write a little less Javascript.

An introduction to the Promox library (https://github.com/dsdshcym/promox/) Why does it exist? What features does it provide? How it differs from Mox and Mimic? Why should you pick Promox over Mox?

Everything you ever wanted to know about the Phoenix LiveView lifecycle…including two new incredible features: live sessions and lifecycle hooks!

Join me as we dissect a Phoenix LiveView session for a better understanding of its flow: how users move from a stateless request to a stateful connection, when live patches and live redirects can provide a single page application feel, and where event handlers respond to user interactions.

Introducing live sessions– these provide scope-like segmentation for live routes. We will explore the new options available and discuss how to upgrade existing apps.

Introducing lifecycle hooks– an advanced feature that opens up integration points in the LifeView lifecycle. A look into the do’s and don’ts of lifecycle hooks and how they can provide consistent behaviour across multiple LiveViews.

There’s something magical about small teams that is hard to put words to. Teams whose impact is far greater than just the efforts of the individual members. The kind of team that leaves observers asking “how do you even??”. This phenomenon is especially true for teams able to harness software technology in ways that multiply and accelerate their efforts.

What is it that makes these teams work?

Why is it that the smaller teams seem to be able to effect change and retain focus in ways that larger teams struggle to do? What technology choices, cultural decisions, principles, and values allow for an environment where great small teams thrive?

There’s a commit in our Git repository from the 8th of January 2018 with the message “Backend in Elixir, Maybe? 🤷‍♂️”. We were complete Elixir beginners when we launched the WHO Covid-19 service in 2020. Now, in 2021, 3 of the 4 worlds’ largest and most impactful social impact Covid-19 services on WhatsApp in the world are powered by Elixir using Turn.io. The South African National Department of Health launched the national Covid-19 vaccine registration programme on Turn.io a few weeks ago and the first million registrations have completed for those of ages 50 and older. Soon the registrations will be open for those of 35 years and above and we’re expecting many millions of registrations to occur within a few days.

We are convinced that to remain focussed on our huge social impact ambition, we must remain small.

We’ll be talking about how Elixir is foundational to this endeavour. How the language design, the principles, and the philosophy is extremely well aligned with teams wanting wanting to punch well above their weight to deliver their best work.

Adopting a new language is more than just a technical journey. A language is only the right tool for the job if your engineers can wield it well. So, as a technical leader you don’t just select a language or a framework based on its technical capabilities and how suited it is for the problems you need to solve, you also try to optimize for the skills your team already has, for a robust ecosystem surrounding that language, for strong community support, and so much more. Elixir lays claim to all of these features and I’ve seen teams ramp up on Elixir with astonishing speed, delivering robust, high-value projects to their organizations in record time. Don’t believe me? I’ll walk you through one such success story in which a small team of engineers who were mostly new to Elixir managed to over-deliver on a complex project in just three months. You’ll learn why we chose Elixir, how Elixir enabled us to be successful, and some of the practices and techniques that will help your own team adopt Elixir.

Why globally distribute your app? It’s a better experience for your users. LiveView rocks even more when it’s close! Elixir nodes can be clustered together. The ElixirLang Getting Started Guide walks you through doing that. What isn’t obvious is how to distribute the nodes in multiple geographical regions. It isn’t because it’s hard for Elixir, it’s because it’s a hard networking and operations problem.

This presentation will show you how, as a single developer with no special operations knowledge, you can leverage Fly.io to globally deploy your “ordinary Phoenix application”, securely cluster it, and overcome complex database replication scenarios. We’ll cover the following things:

• What we mean by an “ordinary Phoenix application”
• Why being closer to your users matters
• How Fly.io lets you deploy to multiple regions
• Working with multi-region Postgres databases
• Challenges and solutions for working with read-replica databases
• Demo a new library that helps you get it done

Elixir is a great language but many developers lack an intuition for the performance characteristics of their code.

Using Elixir and BEAM source code and bytecode, this talk will explore the basic performance characteristics/timings of various Elixir operations/data structures, and talk about profiling code. Along the way we’ll dig into various ways of writing faster code to solve problems.

Have you used break! or IEX.pry, but curious how you would do that on a production node? Are you running a cluster of multiple nodes and want to be able to trace safely? This talk is for you, because we are going to cover tracing on Heroku and AWS. How that works under the hood, and ways you can safely trace and what you be careful of when do.

Startup engineering teams have to be agile, responding quickly to customer needs and shipping them in days or weeks, not months. This often involves taking on technical debt to survive. Startups that find success, however, reach an inflection point where customers rely on their service, so it needs to be dependable and scalable to retain customers. These needs require changes in communication, planning, development, and deployment practices - a shift from a startup mindset to an enterprise mindset.

Veeps succeeded in bringing to market a platform that provided what was wanted: a livestream experience that both the artists and fans enjoyed. With that success came growing pains. Bottlenecks in the Rails app caused headaches, as the demand for their platform outpaced the platform’s ability to keep up. Veeps decided it was time to take the next step, and brought in DockYard to help.

In this talk, Veeps CTO Vinnie Franco and DockYard Senior Software Engineer Mike Binns discuss this process: the initial pains felt on the legacy app, the decision to bring in DockYard to help, the process improvements that Veeps and DockYard put in place, and the decision to rewrite the Veeps app in Elixir.

In a real-world situation, the course of action that brings the most business value isn’t always the most elegant solution—I’m sure I’m not the only one who’s ever remoted into a production application and copy-pasted Elixir code, or had to interface with some legacy portion of a business that’s still using emailed excel documents to operate an enterprise-scale operation! There will always be the need for one-off scripts to be run in your apps. This can be a recipe for disaster if there’s something wrong with your code! At PepsiCo, we decided to create a system for these kinds of one-shot tasks that aims to minimize the risk potential while maximizing business velocity and developer productivity, which we call “Chores”. In my talk, I’ll explore the implementation and features of our library, go in-depth about the philosophy behind them, and explore some of things I learned along the way! And to make sure I cover my buzzwords, there will be meta-programming, LiveView, and OTP!

How to scale Ecto with Postgres to handle large amounts of data effectively and efficiently. As database table sizes grow, how can you best use ecto’s features to avoid common pitfalls and keep your application fast and stable. How to better use postgres indexes to work with Ecto at scale.

Your first contribution to an existing in-house application can be like eating ice cream too quickly on a hot summer’s day – your excitement and enthusiasm result in a painful headache as you struggle to understand the domain and navigate the codebase. Elixir and the surrounding ecosystem have an excellent reputation for beautiful documentation and onboarding tools, but these practices don’t always migrate to in-house applications hidden from public view.

Together, we’ll discover the principles and practices of living documentation and how Elixir’s tooling supports its implementation. At the end of the presentation, you’ll leave with a set of techniques and methods to elevate your application’s onboarding experience to prevent the next ice cream headache.

wasmCloud is a secure, distributed, cloud native actor system runtime that lets developers define and deploy business logic as WebAssembly files (actors). This session walks you through the journey from a pure Rust runtime to a Rust and Elixir/OTP hybrid–learn the what, why, and how of this transition to an even more powerful, robust cloud service. Learn about some of the amazing things we were able to do “for free” that were impossible in the previous architecture.

This talk shows how we create a ‘Casual’ and minimalistic website of kokura.ex, a local Elixir community in Japan, with Phoenix, and publish it.

We’ll show the following process:

• Build it with Docker to fix each of the versions of packages
• Prepare to build CI and CD to make operations easier
• Put it on Heroku to release the website to the public quickly

We started with a Ruby-based environment and migrated it to Elixir, step by step. This talk walks through the architectural decisions along the way and shows how we ended up with a simpler and much more performant platform.

This talk will discuss the benefits of declarative testing with Wallaby and writing tests to improve user experience.

This talk will propose and show the implementation of a framework named “Pratipad” to solve the intrinsic complexity of IoT systems. We use Elixir for its implementation because the highly expressive nature of Elixir and the distributed computing infrastructure of Erlang OTP make it possible to integrate and simplify complex systems with a single technology.

IoT systems will achieve people’s goals in the real world by collecting and analyzing sensor data from IoT devices. Moreover, building such systems promotes adopting edge computing.

Such an IoT system consists of three layers: device, edge, and cloud layers. The advantages of collecting sensor data emitted by the device layer through the edge layer are as follows:

• Reduction of traffic from the device layer to the cloud layer
• Adding information to enhance the data sent from the device layer
• Ensuring security by isolating the device layer from the network.

On the other hand, edge computing brings complexity to the system. The following two issues add complexity to it:

• There are too many options of programming languages and communication protocols for configuring each layer.
• There are too many options for the sensor data acquisition and processing method.

To solve these two problems, we will first propose a method to build an IoT system using only Elixir instead of other languages. Next, we will propose a new framework named “Pratipad.” It supports both unidirectional and bidirectional data flow and defines how to process data in Elixir DSL declaratively. Finally, we also show the implementation of it.

Our method enables each layer to communicate with the other through the OTP distribution protocol. Furthermore, by separating the data flow from the processing, it will be easy to see the whole picture of them. Thus, our method solves the two problems mentioned earlier.

The library off_broadway_otp_distribution, which I developed as part of implementing the proposed framework, was introduced in the following podcast:

#054 AST Parsing using Sourceror with Lucas San Román - Thinking Elixir

https://thinkingelixir.com/podcast-episodes/054-ast-parsing-using-sourceror-with-lucas-san-roman/

This talk can be enjoyed not only by those who are interested in IoT systems but also by those who are interested in Elixir itself. It will show implementation using macro and metaprogramming that take advantage of the expressive nature of Elixir and using distributed computing implementations that take advantage of the capabilities of Erlang OTP.

Pattern matching is ubiquitous in Elixir and it is fantastic. It brings an explicit clarity to directing control flow and assigning values, but it comes at a cost. Pattern matching exposes a data type’s internals.

That means we risk relying on details that could change and if they do we risk invalidating all of our patterns and causing a lot of work.

So we are left with a choice - should we have abstract data types which hide their internals but be left with no (or limited) pattern matching. Or pattern match on internals and live with the consequences?

In this talk I want to explore this tension and ask is pattern matching bad?

(Spoiler, no!)

I will explore a list of possible resolutions to this tension (some of which are older than me), and see if we can describe some Rules for the Match.

In short I want to ask, can pattern matching play well with abstract data - can it be good in the abstract?

Synonymity and homonymity make name disambiguation difficult. To ease this difficulty, I combined two unmaintained Elixir string comparison libraries and added preprocessing and a double metaphone algorithm. The result is a comprehensive map of scores for pattern identification and machine learning. This talk will address the pre-processing, algorithms, and scoring as well as the strengths and limitations. A live demonstration of scoring will allow us to identify patterns. We end with a discussion of how to gain further benefits from the scores.

Do you know how a CPU works? How does the CPU know when to add two numbers or grab something from a memory location? What exactly are all those 1s and 0s doing?

In this presentation, I’ll break down how I learned about assembly language programming, machine code, digital electronics, and the exciting early days of computing by writing a 6502 CPU emulator in Elixir. By utilizing Elixir’s amazing pattern matching abilities and memory-safe operations, we can watch a virtual 6502 CPU step through each instruction it encounters. Furthermore, with the magic of Phoenix LiveView, we can take it a step further by displaying the entire memory stack and disassembler in a web browser – including interacting with virtual hardware!

The 6502 CPU was first introduced in 1975 and eventually made its way into many very popular and influential early computers such as the Apple II, Commodore 64, Atari 2600 (and other families), BBC Micro, and even the Nintendo Entertainment System. With a history that strong and old, you may think that its best days are behind it. However, according to the manufacturer, hundreds of millions of 6502 CPUs are produced and shipped every year. It has a relatively small but powerful instruction set, making it a great beginner’s introduction into bare-bones and/or retro computing.

Surface is a component library for Phoenix, built on top of Phoenix Live View. It takes years of sensibilities from React, Vue.js and other front-end Javascript frameworks, and brings them to the Elixir community.

The hidden superpower of Surface is not just its declarative component interface, compile-time validations, or its patterns for composability. The true power is its ability to usher in a new era of Elixir developers from the Javascript and front-end communities who are looking for higher-leverage solutions to building web interfaces.

In this talk, I will show the power of Surface through example, by way of introducing React and Vue.js apps, then upgrading them to Surface and showing the unique capabilities that Elixir and Surface can offer.

With the advent of telemetry and other observability services, introspecting production systems have become an essential tool to delivering reliable software. However, having an always-online system that constantly pushes data over the air does not fit all use cases. We need to rethink how we handle observability for IoT devices that use unreliable networks and come with costly price tags for sending telemetry data. In this talk, we will look at a case study solving these problems with Nerves devices and introduce a new library to help you with the next Nerves project you build.

Managing BGP sessions and peering is a laborious and manual process generally. At Subspace, we built out a centralized system to administer our BGP sessions across our global network.

This talk focuses on how a network programming neophyte built out the initial version of our BGP system and why building with a beginner’s mindset can actually produce interesting and novel results. There’s a reason this is a core engineering principle at Subspace.

We’ll also cover how expertise in a domain is critical in refining and polishing that initial MVP and how that tension between the expert and the beginner yields a stronger and more resilient product.

The talk will start by discussing the advantages of using factories to speed up writing your tests. It will then discuss the reasonable criticism leveled at factories by Sasa Juric. This will help us highlight our goal: a solution that is maintainable (in response to Juric) while still providing the benefits of the factory pattern.

The talk will both cover ExMachina, the most common factory library, as well as teach folks how to write their own factory from scratch. After that, it will cover the patterns that need to be put in place to keep them useful and maintainable.

The talk will wrap up by covering how to start rescuing an overwhelming factory, moving to maintainable patterns.

Walking out of this talk, people should be able to immediately be able to improve their test suites and therefore increase their happiness as developers.

I’ll walk through certain design decisions (and their implications) of the design of Ecto by comparing to SQLAlchemy. Start with the challenge of mapping relational algebra (which became databases and SQL) into procedural or functional execution (which is how we write programs), touch on how both languages approach compound data, then look at how each answers the question “how can I best help a developer work with a database?” Which flows are easier or harder, where they are different and why (e.g. migrations, “when do we make real DB calls?”), which ones integrate with the host language, its customs, and its ecosystem. If there’s time, I can take a high-level look into what it would take to build something like Ecto in Python or SQLAlchemy in Elixir.

This talk shows how to create a membership site that can be used for production in 20 minutes using Phoenix and phx_gen_auth.

With phx_gen_auth, you can develop a membership site or EC site on Elixir and Phoenix in a in few minutes to few days. phx_gen_auth is a library that provides Phoenix with login, member registration, password reminder, and member information changing features, validation checking for these features, and email transmission handlers.

However, it requires furthermore following customization of you:

• Emails
• Input validations
• Page display messages
• Page designs
• Sign up confirmation

I explain with an example of customizing them, based on my much enough development experiences and business background.

In addition to the built-in feature, I’ll also explain the points when applying phx_gen_auth to your pages.

Stunt doubles exist in your code! Or they could, if you have the tools to make use of them. Let us walk through best practices on utilizing Mox - a testing library in Elixir - to make your tests as accurate as they can be in a mock environment. We’ll go through how to make an effective behaviour that gives you a comprehensive picture of your code’s journey that’ll make it easy for your teammates (and future you, let’s be real) to follow what your code is doing.

Ever wondered how you can build something like Google Docs? Using Elixir’s powerful fault-tolerance and concurrency capabilities along with Phoenix’s excellent support for building real-time systems out-of-the-box, these two are all you need to know to build your own real-time collaboration app.

With our experience and learnings building Slab compressed into the talk, the goal is to get you going quickly by choosing the right™️ approach and tools. We’ll also use Operational Transform, a collaboration and consistency architecture to ensure reliability and scalability when coauthoring. Starting with a basic plain-text implementation on the frontend, we’ll also show how to support formatting and more using an advanced editor like Quill.js.

Some Assembly Required: To get the most out of this session, you must be comfortable writing code in Elixir and Phoenix, and ideally have at least some understanding of OTP and websockets.

Phoenix LiveView is a great way to to add a rich client experience to your Phoenix/Elixir application without needing the complexity of a Javascript framework like Angular and React. However, there are some times in building LiveView apps where you might want to add functionality on the client side. Web Components, or more specifically, Custom HTML Elements, are a tool you might not have thought to reach for in these situations. LiveView already excels at generating and managing HTML Elements, and since Custom HTML Elements are still just HTML Elements, things work out surprisingly well. In this session, we’ll share our experience building several real-world Phoenix apps with Web Components. We’ll briefly review how Custom Elements work and how easy they are to build and work with. We’ll look at common scenarios in our LiveView apps where Custom Elements can help us. We’ll also share our open source library that helps Custom Elements fit into LiveView even more seamlessly.

By the end of this talk attendees will understand the basics of property-based testing, how to confidently write a custom generator which creates realistic test input, and how to structure their new test code within their project.

We’ll walk through a case-study of a wildcard matching library in Elixir, and confidently replace most of its example-based tests with a single property-based test.

To start, we’ll briefly examine different strategies for property-based testing and pick the most appropriate one for this library. In our case, we can model our wildcard implementation off of the bash wildcard implementation. In other situations, testing for symmetric properties or invariants might be more appropriate.

Next we’ll write our first test and see what happens when we run into our first error. An error doesn’t necessarily mean there is a bug in the code - we’ll talk about the input that was generated and how it exposed undefined behavior for our library, leading to a new feature.

Now that our test is passing, we can look at gathering statistics and using them to create better input data for our library - it turns out that our first attempt was not doing a very good job of creating realistic input data.

This will mean writing a custom generator, which we’ll build up from the existing generators. We’ll look at examples of custom generators and also how they can shrink when they discover an error.

Lastly, we’ll talk about how to organize custom generators in your projects, how to run tests on CI, and then look at some interesting errors which the property-based tests discovered.

Nerves has been used extensively to successfully deploy Elixir to low resource devices such as: Raspberry Pi, BeagleBone, etc. Despite this there are no documented use-cases today of using Nerves and Elixir to run a 3D printer. Building a real-time web UI on an embedded device has traditionally been cumbersome, requiring both back and front end frameworks. However, the rise of Liveview has provided a streamlined option for building real time web UIs just using Elixir. In this talk I’ll show you how to build a simple web UI for controlling a 3D printer, using Nerves, Liveview, and other libraries within the Elixir ecosystem.

Controlling a 3D printer is usually done over a USB connection. I’ll show you how to use Nerves and a Raspberry Pi to communicate via USB. Since most 3D printers have little memory, we’ll need to send and receive messages efficiently. Connecting to a 3D printer during feature development isn’t always practical, so I’ll discuss a few strategies for mocking out hardware. Finally we’ll talk about using Liveview to wire up the system we’ve built into a web UI to see the printer status and send commands in real time.

It’s one thing to read about Phoenix LiveView on Hacker News. It’s another thing to make a toy project over the weekend. Joshua Plicque has been shipping production LiveView code for about a year now…..and he’s shouting from the rooftops that the promises of Phoenix LiveView are true!

In this talk, we shoot past the theory and jump into real-world problems that have been solved with Phoenix LiveView.

• Using Phoenix PubSub to broadcast messages to LiveViews
• Caching expensive operations with an Elixir Agent, along with a cache busting strategy
• When to abandon LiveView and reach for Javascript (surprisingly rare!)
• Phoenix LiveView File Uploads - soup to nuts
• Using the URL as a temporary data store with Ecto

Codedge, founded in 2015, was the first Elixir developer consultancy in Dallas, TX. Two guys, fresh out of college, could pick literally any tech stack, so why not choose the fastest, most reliable language in the world? 6 years later we’re doing work for everyone from startups to Fortune 100s, and our development process has never been better. This is a talk about our journey, the lessons learned, and where Elixir really came through. Covered topics include our full pipeline process through Gitlab CI, our deployment process with Kubernetes, and our code structure using the bits of Elixir and Phoenix that work best for us.

The goal of this talk is to shed some light on another way of thinking about development problems. A lot of problems that can be solved with Elixir application code are better solved with database code.

This talk is written from the perspective of a teacher turned software engineer. Adopting a new language is much like learning many other things. Most problems in tech are people problems. Focusing solely on the tech can lead you down the wrong road. To successfully adopt Elixir, you need to prepare your organization and team for the journey. While no one talk can cover all the specifics of every org, one talk can cover many of the generic challenges that face every org. If you want to know what problems Elixir doesn’t solve, what to do to prepare your team for Elixir, common pitfalls of adopting Elixir, common joys of adopting Elixir, and how to track your Elixir learning journey this talk is for you.

Background jobs with Oban are integral to the business side of many applications. Knowing that your jobs function correctly in isolation, and when composed with other jobs, and when integrated with the rest of the system is essential for peace of mind. Fortunately, Oban provides all the tools necessary to test jobs at any level of isolation. Together we’ll explore how to make optimal use of Oban’s robust testing functionality for unit, integration, and acceptance tests.

Come learn how to test Oban jobs from the inside out—from asserting that workers return correct values to assuring every job in a queue is executed as it would be in production.

If you are new to Phoenix, you may be puzzled by its concept of “context.” As well-meaning as it seems, confusion soon arises when it comes to intra-context dependencies and context-straddling schemas, which happen, well, more often than you’d want to admit. If we don’t organize our contexts carefully, we may find ourselves in trouble as our application grows.

Although there are a million ways where contexts can go wrong in a Phoenix application, we can also find open-sourced projects that demonstrate good use of context. This talk is an attempt to find out how to best leverage the power of Phoenix context by looking at those projects and learn from the mental models behind their context design. Shall we?

This talk shows how to make multiple clients, including users and IoT Devices, real-time update GoogleMap Application. What do you want to imagine with multiple clients real-time updating GoogleMap Application? In this talk, the features of it are as follows:

• Display and monitor IoT devices like drones on a map.
• Checking members’ positions concurrently with navigation when moving in a group.

Such applications require real-time user experiences, but their implementation tends to be very complicated. However, it can be easily implemented by using Phoenix’s Pubsub, Presence, and LiveView. LiveView provides a rich real-time user experience. PubSub provides a simple Realtime Publisher / Subscriber Service. In addition, Presence realizes Tracking to Processes and Channels. By using them, you can monitor the activity of multiple devices and update their location information in real-time on GoogleMap. Also, show some client implementations.

In June 2020, I joined PepsiCo eCommerce and was asked to build a new team that would focus on creating user interfaces for some of the data products being built within the organization. We knew that we wanted to use Elixir, we had a rough idea what the first project would be, and we needed to deliver that project by the end of the year. In this talk, I will present a case study of how we built that team, what went right, and what went wrong. I will discuss the major technical decisions that we made, why we made those decisions, and the long term impact of those decisions. Finally, I will talk about the two secret ingredients that ran through everything and were key to helping us build a successful team: Elixir and Lean software development.

Whether or not you’re new to the Elixir language, there’s a place for you in our small but strong global online community.

bandit is the name of a pure-Elixir HTTP server written specifically to serve Plug based applications. It features support for HTTP/1.1 & HTTP/2 connections via both HTTP & HTTPS, and has been written with correctness and simplicity in mind from day one. While it is still in active development, bandit (and its lower-level companion library Thousand Island) have an ambitious goal to become the go-to foundation for networking and HTTP in Elixir.

In this talk I’ll talk about bandit’s surprising origin story, show how low-level networking is a perfect showpiece for OTP, and hopefully shed some light on what happens in the network stack underneath every Phoenix application.

Along the way we’ll live-code an implementation of a couple of RFCs, demonstrate the power and safety of pattern matching, and explore some of the dustier corners of the HTTP specification.

If you’ve ever wondered about the nuts & bolts of how networking works in Elixir, or even wanted to try building your own service, this talk is for you.

https://github.com/mtrudel/bandit

If there is any tool in my Elixir developer toolbox that comes close to giving me “super powers” it’s Fred Hebert’s Recon Library. Recon is an incredibly powerful and useful library for introspecting running systems.

We’ll cover basic and advanced usage, some real-world stories and tips-and-tricks.

You’ve heard of “Let it Crash” and that’s wise advice. Most of the time. Other times a custom exception might be a better choice. Let’s talk about what exceptions in Elixir truly are and how they work to gain some intuition for when they are the right tool to reach for. They can play very nicely alongside error tuples. Even if we never raise them. I’ll discuss a case in which I named an exception a “fumble” because it might be recoverable.

Have you ever found a bug in your LiveView code because your app somehow had invalid and incoherent state?

• “Your total is -$500.”
• “Your return flight is <date in the past>.”
• “The temperature is -600°F.”

When programming user interfaces, it’s important that we do not display inconsistent states to our users. But how can we prevent those bugs?

By making those invalid states impossible to represent!

Join me as we walk through several LiveView examples that have bugs because of invalid states. As we fix them, you’ll learn to model domains in a way that makes rendering invalid states impossible. Your users and your future self will thank you.

Toronto is a city of cyclists. The Toronto Bike Brigade is pairing volunteer cyclists with community organizations that serve isolated, vulnerable people, seniors and health care providers to deliver supplies during the COVID-19 pandemic. The Bike Brigade offers free delivery service for organizations and individuals in need.

Hundreds of volunteers cyclists are delivering food hampers, prepared meals, groceries, care packages, and other items. We’re on the road seven days a week. To manage this all, we’ve built a Phoenix LiveView application that allows our dispatch volunteers to plan deliveries and communicate with our cyclist volunteers, and allows our cyclist volunteers to see their routes.

This talk will give an overview of the organization and technology behind it. We’ll discuss scaling from a spreadsheet-powered organization to custom software, our beliefs about building humane user experiences for our volunteers, and how Elixir/Phoenix LiveView makes it possible for a solo developer to build impactful technology for the common good.

Breakdown of Ecto Multis, all the parts and pieces from uses to structure and commonly used functions.

Machines, within distributed applications, operate by exchanging messages with cloud services and other remote machines. Secure, private, and trustworthy connected applications must protect these messages from eavesdropping, tampering, and forgery.

Ockam is a suite of open source programming libraries and infrastructure that make it simple for applications to dynamically create end-to-end encrypted, mutually authenticated, granularly authorized, lightweight secure channels that protect messages, end-to-end — from their source to their destination.

This enables secure communication between application layer entities that are not directly connected by simple point-to-point transport connections. En-route encrypted messages can travel over multiple transport layer connections and can be stored in message queues, databases or caches for asynchronous, end-to-end protected communication between entities that may not be online at the same time.

In this talk, we’ll dive into the design of Ockam’s Elixir libraries and the protocols they implement to provide end-to-end secure and private communication.

This is the story of how we built a distributed system to keep track of a single count. With more than 100 thousand users connecting to a single channel and users joining in bursts of thousands, Phoenix Presence was too heavy. Instead, we reached to OTP to solve our problem. We’ll walk through the process of building a system that can keep track of every single connected process and increment a counter each time they join. If a socket drops off, we have to reliably decrement that counter. We’ll talk about how to run a single global gen_server process across multiple nodes. We’ll learn how we can fan out gen_server’s so that a single gen_server does not become the bottle neck. Finally, we’ll learn how these pools of gen_servers can use a registry to communicate their local count up to a global counter module. This global count is then broadcast to every connected socket once every two seconds, regardless of how many nodes are running.

At Savi Solutions we were tasked with building a fault-tolerant, highly-scalable video streaming platform with minimal operational costs. Elixir and Erlang VM (BEAM), coupled with Riak Core, provide a perfect fit by allowing distributed services, consistent hashing, routing, sharding, replicating, and near-linear scalability through decentralized distribution of work.

In this presentation I will cover the strategies and lessons learned in setting up, distributing, and scaling video streaming processes such as:

• The ins and outs of setting up a Riak Core cluster with Elixir and Kubernetes
• Distributing video stream processes via horizontal partitioning (VNodes)
• State and process handoffs for fault-tolerant Kubernetes rolling updates
• Cluster monitoring and autoscaling

By the end of this presentation, you will have a better understanding of the Riak Core toolkit and its ability to pair with Elixir and Kubernetes in building distributed, scalable, fault-tolerant applications.

At SparkMeter we deal with remote IoT devices that may be offline for hours or days. None of the existing messaging protocols met our requirements for low data consumption and visibility into the message queue so we did what any engineers would do and built our own. This talk explores the challenges we had with existing solutions, how our solution addressed our needs, and how the approach has worked so far.

Do you have a monolithic Absinthe GraphQL application? Is your team growing so fast that your monolith is struggling to handle that growth? Do you wish you could implement a service oriented architecture but still have a single unified Graph for your clients to consume? Then Federation might be for you! Learn how to implement Federated services with Absinthe behind a gateway.

Zigler is a library which allows you to easily write NIFs (low level code) for Elixir that are good citizens of the BEAM. This talk will take a peek at some of the internals to see how Zigler creates a bridge between the two languages.

GenServers are one of the first and most powerful tools we reach for when dealing with state. Without intentional planning, though, it’s very easy for a GenServer to grow into a Big Ball of Mud that’s hard for the team to understand, painful to change, and almost impossible to test.

In this very practical talk, we’ll dig into a handful of techniques for improving the testability of GenServer implementations and saving yourself from maintenance headaches. We’ll consider lessons from the object oriented community, including things like dependency inversion and separation of pure functions from state manipulation. We’ll also dive boldly (some would say recklessly) into controversial topics like mocks and stubs.

My goal is for attendees to leave with three or four concrete ideas they can implement in their codebase today that will pay dividends toward their team’s happiness and peace of mind for years to come.

Creating video conferencing systems has always been challenging. While the most used standard - WebRTC requires from the user quite a deep understanding of what is going on under the hood, the new abstraction layer created in Membrane Framework allows us to hide all the low level, network connected things. During this talk, I will go through the new SFU API and how it makes the developer experience much easier, both when creating a new Phoenix application and integrating with existing systems.