In this talk, we'll walk through the design of a collaborative music composition environment using Elm for a frontend that interacts with a Phoenix-channels based backend. We'll see how we can use the building blocks that Phoenix provides to allow us to build collaboration and persistence features to an Elm-based frontend and represent the frontend application's data structures and actions nicely in Elixir for persistence and transfer.
In this talk, we will explore how developers new to functional languages tend to gravitate towards old patterns, and the new patterns they can learn to replace these with. To give this context, we will review how one functional newbie converted an existing Rails application to Phoenix. The goal of this talk is to give a perspective of a newcomer to the Elixir of today.
Elixir: Power of Erlang, Joy of Ruby
I’m a language nut. I love trying them out, and I love thinking about their design and implementation. (I know, it’s sad.)
I came across Ruby in 1998 because I was an avid reader of comp.lang.misc (ask your parents). I downloaded it, compiled it, and fell in love. As with any time you fall in love, it’s difficult to explain why. It just worked the way I work, and it had enough depth to keep me interested.
Fast forward 15 years. All that time I’d been looking for something new that gave me the same feeling.
Then I came across Elixir, a language by José Valim, that puts a humane, Ruby-like syntax on the Erlang VM.
Now I’m dangerous. I want other people to see just how great this is. I want to evangelize. I won't try to convert you away from Ruby. But I might just persuade you to add Elixir to your toolset.
So come along and let me show you the things that I think make Elixir a serious alternative for writing highly reliable, scalable, and performant server code.
And, more important, let me show you some fun stuff.
This talk will be in dialog with Avdi Grimm's book "Confident Ruby". It will also be a distant echo of Kent Beck's book "Smalltalk Best Practice Patterns". We'll talk about what confidence looks like in code, and how to achieve it. We'll look at examples of non-confident code in Ruby, briefly look at how to make them less timid, and then spend quality time with them in Elixir.
Confidence is reflected in code which clearly states its intention. It means removing the clutter of conditionals and error handling which obscure meaning and flow. Elixir provides many language-level constructs to make confident code the natural path to follow. Pattern matching, multi-clause functions, guard clauses, and protocols all foster code confidence. Tagged tuples provide significant, non-nil return values, and structs provide a form of type system. We'll introduce each of these and show how they can work together to even greater effect. We'll work up to supervision trees, the ultimate trump card in confident Elixir code.
Let's look at a quick example involving inserting a new record into a database. In Ruby, we might use the ActiveRecord save method, which returns boolean true on success and false on error. This pushes us toward a branching conditional.
In Elixir applications, there's often the need to have persistent connections to external services such as TCP connections to database servers. In this talk, we'll explore how to build such connections in a way that takes advantage of some of Elixir's most appreciated features: concurrency and resiliency. We'll see how to make such connections concurrent, e.g., making them asynchronous or using pooling, and how to make them resilient by reacting to network failures and disconnections. We'll reserve some time to explore TCP connections in particular and talk about dealing with binary protocols.
After this talk, you'll be able to take advantage of the techniques I discussed to build connections to external services in your application or in libraries you're developing (database drivers are great candidates for these techniques).
This talk is directed at anyone who has just enough Elixir experience to be able to understand the language syntax and core principles (such as its concurrency models) and that is familiar with the basics of OTP (such as GenServers).
Andrea is a programming enthusiast with a soft spot for functional programming and beautiful code. He loves learning new stuff. He strongly believes in accessible culture and education and in open-source software. He's active in the Elixir community and uses almost exclusively Elixir for work purposes.
Elixir/Erlang systems are typically powered by thousands, or sometimes even millions of processes, which, in order to work together, frequently send messages to each other. To send a message to a process, we need to obtain its process id (aka pid). In this talk I'll present various ways of achieving this seemingly simple task. Drawing from my own experience in wheel reinvention and choosing inappropriate solutions, I'll discuss strengths, weaknesses, and caveats associated with each approach. After the talk you will not only be able to find your processes - you will also be able to select the best approach for each given situation.
To systematically present typical techniques that can be used in one of the most important task of almost every Elixir/Erlang based system.
Mostly people who are just starting to explore concurrency in Elixir/Erlang. More experienced programmers might also discover some useful tips.
Simpli.fi takes part in nearly two million and growing ad auctions per second. Each auction is for only a fraction of a penny; but at this frequency, such fractions can accumulate to tens of thousands of dollars in minutes.
Our real-time accounting system is built with a mixture of Elixir and Erlang. It achieves high throughput while servicing 25,000+ (doubling every 8 months) active ad campaigns worldwide. Our performance can be directly measured in dollar figures in real time. Downtime and inaccuracy are both immediately obvious and costly.
We wrote this application in Erlang and it has been in production for over two years. Today we do all new development in Elixir. I'll discuss the evolution of our approach and how the Erlang VM has proven a great fit for real-time accounting. I'll also talk about how we've revised our design and assumptions over the course of scaling ten-fold.
When it comes to releasing your Elixir app, there are a couple of ways to handle it with pros and cons to each. I created Exrm and Conform to simplify this process and provide a path for using the Erlang VM's capability for performing hot upgrades/downgrades.
In case you aren't familiar with it, Exrm (Elixir Release Manager) is a library which at it's core exposes a mix task (`mix release`) which builds your Elixir application and packages it as a tarball for easy deployment. By default it contains everything you need to run your application, including the Erlang runtime. It is highly configurable though, and can allow you to build cross-compiled releases for platforms like the RaspberryPi, and much more.
Conform is a configuration management library inspired by cuttlefish (a library built by Basho for Riak), and is designed to allow you to expose a simple init-style configuration file in production, defined by a schema, which contains translation to common data types, custom transformations of your own design, and validation rules (such as valid ranges, etc).
The purpose of this talk will be to walk you through taking a simple Phoenix application, defining a configuration schema with Conform, building and deploying a release with Exrm, configuring the release, and handling a simple upgrade/downgrade scenario. I will also talk briefly about using Exrm without Conform, and things to keep in mind during development when targeting releases for deployment.
Frameworks are a great help to web developers in all languages. The productivity increases are real, but there's a catch. Framework elements tend to entangle and overshadow an application's domain entities. This effectively chains the application to the framework. Choosing a new framework, or choosing a new interface entirely, almost certainly means a rewrite. Elixir and Phoenix offer a way out. We can build an application in pure Elixir before we ever run "mix phoenix.new". We can test this application in isolation to improve our confidence in it. We can bring it into a new Phoenix project as a dependency. Then Phoenix can do what it does best, be the application's web interface.
* Expand our understanding beyond traditional patterns of web application development.
* Explore new techniques that Elixir and Phoenix make available.
* Understand the Elixir and Phoenix constructs which make these techniques possible.
This talk is for anybody who is interested in web development.
Lance is the principal author and maintainer of the Phoenix Guides. A Senior Software Engineer at GoPro, he lives in Berkeley, California where he enjoys music, art, and the culinary joys of the Bay Area. He's also been a professional web developer since "state of the art" meant Perl scripts in an Apache cgi-bin directory.
Electronic invoices are a critical part for trade in Mexico. If invoices are not created and delivered in time, we can generate serious problems such as complete loss of cargo ships, representing millions of Mexican pesos in losses.
We had a legacy system developed in Java from 8 years ago. It had a lot of problems including:
Big memory footprint (24 GB per server)
A lot of servers in order to distribute load and isolate errors (15 servers)
No proper error handling and messages for troubleshooting
No statistics (they produced more load in the system)
We built a new system that resolve all these problems and provide a better foundation for future services. This is the backend that will be used in all the retail and online Apple Stores in Mexico. We wrote the backend in Erlang and Elixir, with additional micro-services in Python, C++ and Java for XML validation and PDF generation.
In this presentation I will talk about:
How we trained the team of java/ruby in Elixir/Erlang
Metrics about the new system (from 15 to 4 servers, etc.)
Problems we face
How to introduce Elixir/Erlang in a company with a lot of investment in Java
This talk will give you an overview of the power and richness that the larger Erlang ecosystem provides; including features that you might not even know exists, as well as some of the ways of thinking about programs when running on the BEAM, Erlang's Virtual Machine.
Be it Scala, Clojure, JRuby on the JVM, or F# on the .NET CLR, you can be productive in the language, but without spending some time educating yourself about the larger ecosystem, you wouldn't expect to take full advantage of the power you get from running on that VM.
The same is true for Elixir and the BEAM. While you can get far using just Elixir alone, you will miss out on the what that Erlang community brings to running on the BEAM.
By opening your mind to the broader ecosystem, you gain an advantage over everyone who never looks beyond Elixir.
This talk will give you overviews of
What OTP gives you that you don't have to do yourself, for when you have to have more power than simple agents and tasks
What the Erlang VM does to help you manage concurrency
How you can take advantage of types in a dynamic language
How to take your automated testing beyond just simple unit and integration style testing
Ways to monitor a live running application on the BEAM
With Elixir and Phoenix, the toolkit for building web applications has expanded dramatically. Beyond Phoenix's routers and controllers awaits a whole new world of features and ways to build reliable systems. With this talk, you'll see how.
When learning or adopting a new language, you naturally draw on your existing domain knowledge as a stepping stone. Building a web app in one language is much like building one in another. You handle requests, responses, and for most languages, give little thought to stateful processes and long-running subsystems. However, with Elixir and Phoenix everything is different. We can compose applications using isolated, stateful subsystems that a regular stateless request can interact with and leverage.
Over the course of the talk we will take a practical approach to building a small application in Elixir, walking through all the steps and describing what language features we are taking advantage of and why. Along the way we'll explore GenServer, OTP, backpressure management, synchronous vs asynchronous calls, a testing strategy, and integration into a Phoenix application.
The end result is a fully functional Elixir project, integrated into a Phoenix application.
With all of the Python, Node.js and C++ libraries for connecting to sensors, actuators, and other devices, it's easy to dismiss Elixir as a language for physical computing. Nothing could be farther from the truth. Between binary pattern matching, a functional approach to transforming low level data, and natural support for recovering from the hiccups of real world hardware, Elixir is an ideal language. The main parts missing have been low level library support.
This talk starts with a discussion of the options for connecting to hardware devices, challenges and pitfalls of each technique, and tips for minimizing frustration. It will provide an in depth view of using the nerves_uart library, your laptop, and an inexpensive FTDI cable to interact with sensors, motors, smart phones via Bluetooth LE, and more. Each example will show how Elixir can beautify some really ugly hardware interfaces. Finally, the talk will end with how to remove the tether to your laptop by creating standalone embedded devices with Nerves.
Object-oriented programmers can have a dogmatic approach to language patterns. Whether it is analyzing, debating or criticizing various implementations, the passion for patterns emerges from the need to both communicate intent and categorize code. The patterns do more than define code, they describe it. So, what happens when we lose objects? When state fades away? When paradigms shift far more than a change in languages?
In steps Elixir. With syntax similar to Ruby but firmly grounded in the functional paradigm, it represents an easy transition for Rubyist into functional programming. But what about the beloved patterns? It turns out that understanding how functional languages implement some of the common object-oriented patterns can demystify this new paradigm. Plus learning new functional patterns can provide new solutions to old problems.
Have you ever wondered about why you might use multiple levels of supervisors, or when you might use a strategy other than one_for_one? What about practical examples of how you might do a live code update? Or how to send code down to a node that just joined a cluster? Rudimentary, but effective, failover between cluster nodes? I created an Internet Relay Chat (IRC) bot-OhaiBot-to explore each of these topics. I'll do a walkthrough of the design, running, and update of the bot, focusing not necessarily on OhaiBot, but on why and how I came to certain solutions. No previous knowledge of IRC is necessary. Audience participation, particularly for the clustering aspects, is encouraged.
Elixir and Phoenix are built on a foundation of concurrency, speed and reliability. Thinking beyond the browser, these features are ideal for the backbone to any successful mobile application. Together we will explore leveraging the powers of Phoenix and WebSockets to get started building realtime mobile applications in Swift. Along with a basic introduction to Apple's (relatively) new language Swift, we will explore how to setup a mobile application to communicate with a Phoenix application in realtime using Phoenix Channels. We will also discuss the impacts of some of the newer Phoenix features, like Presence, and how these can be used to enhance your applications. Attendees will get a brief introduction to the basics of iOS development, explore how to easily connect Phoenix and iOS applications through WebSockets, and discover how to use the power of Elixir and Phoenix to create complex realtime applications and games.
Static typing versus dynamic typing is an age-old debate amongst computer scientists and programmers, and the fact that we still argue about it suggests that there is no single right answer for all circumstances. But what if we could have the best of both worlds by combining the safety guarantees of static type systems and the freedom and flexibility of dynamic type systems? In this talk, I will present an introduction to an optimistic, gradual type system as implemented by the Dialyzer tool for Erlang and Elixir. I will highlight the differences and trade-offs between static and dynamic typing, and present optimistic, gradual typing as a good compromise.
Binary protocols are all around us, HTTP/2, HPACK, or DNS are only a few examples. Pretty efficient on the transport layer they reduce size dramatically and enable a set of great features. But they are often more complex to implement and reason about.
In this talk you will learn how you could implement a given binary protocol with Elixir. We will take a look at binary pattern matching, de- and encoding of strings and integers, binary data frames and extracting tests from RFC specs. And, we will take a look at how to implement the HPACK protocol as part of the HTTP/2 protocol so you will learn some of that along the way as well.
One of the many goals that both Elixir & Phoenix share is developer’s productivity. There can be two aspects of productivity: short-term and long-term.
In this talk we’ll explore how using Elixir’s umbrella project feature can help with long-term productivity when working with potentially large codebases. As a example we’ll walk through building an imaginary system: Acme Bank. We will see how we can break up this system into a collection of smaller applications, each of which has a well defined boundary, domain model, set of responsibilities, and can be worked on independently. We’ll compare this approach to microservices-based architecture which is being adopted by many organizations and we’ll see if we can achieve some of the benefits without incurring some of the drawbacks.
Test driven development is a core part of our process at Gaslight, and for our first couple of Elixir applications, we struggled adjusting to writing tests in our Phoenix application after years of working with RSpec and Rails. Luckily, we’ve come up with several conventions, tips, and tricks to help developers write simple, easy to understand unit and feature tests. In this talk I’ll describe how we structure tests, test setup, and helper objects to make TDD as painless as possible. Specific topics I’ll cover are:
Naming conventions for organizing tests
Using factories and helpers to clean up your setup
Splitting tests into files to group them by context
Keeping your feature in order with page modules and Hound
Writing assertions to generate useful failure messages
Refactoring is an important aspect of writing software, it makes reading and understanding your code easier for the rest of the team. How many times have you read some code, thought ""who wrote this code?!"" only to have `git blame` display you as the author 6 months ago?
Functional programming makes moving code around very easy, however there is more to refactoring than relocating code. In this talk, we will go over some of the features offered by Elixir, Phoenix and Ecto that can be used to make reading and understanding your code much easier and as a result of this, more maintainable for future you and your team. From getting rid of those nested case statements, to restructuring your entire application.
We've heard the arguments for functional programming, and maybe we're even convinced, but that doesn't change the fact that we have a body of code in Ruby and people paying us handsomely to work on it. Even if you want to move to functional programming, it's hard to take the leap from experienced Ruby developer to functional programming n00b. This talk addresses these concerns with code. We'll look at how to use the lowest hanging fruit from functional programming in our daily work with Ruby. As a bonus, we'll also look at how to do the same thing in Elixir, and see how familiar Elixir feels to a Ruby developer.
One of the great things with Erlang is how easy it is to distribute. Distributed Erlang makes applications transparent when porting them from a single computer to multiple computers in a network. There are still areas for improvement though, and the OTP team is working on improving the scalability and services of Distributed Erlang. In this talk we'll see what plans we have for the Erlang Distribution.
- How Distributed Erlang works today, some issues with it and how to avoid them
- The future of Distributed Erlang
- Anyone interested in building scalable applications with Elixir or Erlang
Zandra is working in the Erlang/OTP team at Ericsson, and is currently focusing on improving the scalability and efficiency of Distributed Erlang. Although her Elixir experience is limited she is happy to be a part of the community and to see it grow.
As a young community, we have to resist the urge to reinvent the wheel for foundational libraries and instead look to the battle-tested awesomeness that is OTP. When designing complex systems with many moving parts in Elixir, we should ask ourselves the following question: has OTP done this?
In order to answer that question in this talk, we'll first look at the gen_fsm, gen_event, and gen_server libraries. We'll see some examples illustrating how, where, and why they should be used for building robust, fault-tolerant, and distributed systems.
A broad discussion of some of the built-in database options like ETS and Mnesia will follow. We'll examine the pros and cons of each system, and take a look at some examples.
Lastly, attendees will get a brief overview of OTP-style releases and how they can fit into modern deployment infrastructure.
This talk will explain how time works around the world, how to deal with it on computers in general and with Elixir specifically.
Even big names such as Apple, Microsoft, Twitter have had problems with time causing bugs that meant that APIs, Zunes or iPods would stop working. Many of these bugs could have been prevented with better general knowledge about time.
Most programmers have to deal with time issues such as DST and timezones. But few know the difference between GMT, UT1, UTC and TAI.
The talk first provides a short introduction to how modern time measurement evolved and how it works today. Covering solar clocks, trains, caesium atoms, astronomy, timezones, legislation, leap seconds and more.
A particularly interesting part of the presentation is a Phoenix app showing a live clock with the relationship between the Daylight Saving Time, atomic time, timezones and leap seconds.
Tzdata is the only Elixir library for providing timezone information. I will explain how the first versions relied heavily on macros/metaprogramming. And why I changed it so the new version uses ETS tables and makes more use of OTP concepts and concurrency. This use of OTP means you can have more up to date timezone information on Elixir than on other platforms.
Then, some general recommendations and best practices for developing software that has to work with date and time.
Finally an overview of Calendar (and related packages for Phoenix and Ecto) and how they incorporate the aforementioned best practices.
General overview of the talk:
General introduction to time
Overview of Tzdata structure and how OTP makes it better
Best practices for working with date/time
How Calendar and related packages work