Throughout history, the needs of the consumer, hardware limitations, and the capabilities of languages have set a pendulum in motion. At one side, the pendulum dictates that user interfaces be glorified forms with simple request-response semantics. At other times, the pendulum swings to the opposite extreme, and user interfaces become rich and dynamic, but they leave the programmer to deal with increasingly high technical mountains.
This pendulum dictates what compromises must be made at the user interface, but more interestingly, it determines how resources are consumed and allocated on the server, the language choices that impact each layer of an application, and the way we think of generic terms like "server" and "connection".
This talk will focus on the movement of the pendulum. We'll look at what forces in the industry set the pendulum into motion at each point. Finally, we'll look at why Elixir is succeeding in the face of the most recent and dramatic pendulum swing to date.
With Phoenix 1.0 out recently, it's time to look ahead! Together, we'll outline what's next for Phoenix 1.1, then explore some exciting new features that take Phoenix to another level of modern web development.
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.
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.
Conflict-free Replicated Data Types (CRDTs) are a hot new datatype in distributed programming that promise coordination-free and always eventually-consistent writes. Most of the stuff you will read about them is limited to the context of high-end distributed databases, but CRDT's are more flexible and shouldn't be limited to this field. In the talk, I will demonstrate how CRDT's are great for applications that have partial connectivity (including websites): updates can be applied locally, and when communication is possible, you can send the data back up, and the data will remain consistent even in the most byzantine (or apocalyptic) scenarios. There are even scenarios that can support multiple simultaneous editors.
Beyond that, I will also demonstrate how Elixir's metaprogramming can be used to compose complex models out of CRDT's that themselves exhibit the same exact features. I will also exhibit some newer CRDT features, such as shared-context and delta-operation CRDT's to overcome some of the shortcomings of older CRDT's.
I plan to keep the talk light on theory (the academic literature is sufficient for that).
In this talk we'll build a custom visual programming language that compiles down to Elixir modules. The language will be focused on generating chatbots atop an XMPP server, but the concept more broadly involves building a Rules Engine that generates runtime-configurable output based on input documents. We'll define an Abstract Syntax Tree for a custom language, a compiler that translates that AST into Elixir modules, and a UI for building the AST directly (i.e. no parser - this is not a text-based language). We'll also walk through the supporting web application that handles storing the AST as it's built.
The lines of connectivity extend beyond the web browser and into almost every device we own. Mobile phones, sensors, and wearable tech are only as powerful as the platform that interconnects them. The Phoenix Framework is that platform and goes beyond the web by providing an abstract of connectivity through channels. Together, we'll explore how to connect iOS, Mac OS, and Apple Watch to Phoenix using the ObjC channel adapter. To tie it all together, we'll see how we can seamlessly start a motorcycle from an Apple Watch, stream ride stats using an iPhone, and display this data on a Mac OS App. Phoenix is defining a new web. Let's find out what's possible.
We will walk through the development of a voice survey application using Phoenix, MySql, and the open source Asterisk PBX. We will build a simple web interface to create survey questions and display the results of completed surveys. We will build an Asterisk AGI application that reads the configured questions to a caller and accept touch tone responses which will be saved for later viewing in the Phoenix application. We will then demonstrate the application.
You want to perform integration tests on your development computer. As part of testing, you want a 3rd-party sandbox server to send its notifications to your computer, but, alas, your computer is behind a firewall.
In this session, you will learn how to set up an EC2 instance managed by Phoenix to relay communications bidirectionally between the sandbox and your development computer. See how a Phoenix channel eliminates polling and how an Elixir distribution primitive sets up the channel through the firewall.
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.
Phoenix is the new hotness. Elm is the new hotness. Let's turn up the heat by combining the two for fun and profit.
In this talk we will:
Create a simple Elm client app to demonstrate its Model-View-Update architecture
Enhance our Elm client by getting it to retrieve data from an API
Build a simple Phoenix data API to serve data to our Elm client
Swap our Elm client to use our newly generated Phoenix API
Discuss several ways that Phoenix and Elm can play together
Turn the dials up to 11 by combining Elm's Functional Reactive goodness with Phoenix's channels.
Have you always wanted to contribute to an Open Source project, but you're not sure how? The Elixir and Phoenix Framework communities are a great place to get started. In this talk you'll learn how to navigate the ecosystem, avoid missteps due to unwritten rules, find something to work on, and make your first contribution.
We'll start with the easiest things you can do, (ask a question! fix a typo in the docs!) move on to creating a bleeding edge project using the master branch of Phoenix so you can try out your changes, and go all the way through to building Elixir from source and patching the language itself.
It's been stated that in order to make full use of BEAM, the Erlang virtual machine, any language implemented on top of it needs to adhere to the semantics of Erlang.
Yet, other virtual machines, such as Parrot, stemming from the Perl 6 community, or JVM, the Java virtual machine, support a plethora of languages with differing semantics.
At the heart of these virtual machines, BEAM included, lies an instruction set. Specific commands that any language implemented on top of the machine in question has to be broken down into; any running program ultimately composed of. The instruction set comprises the extent of the virtual machine's understanding of what we want it to do and thus dictates its capabilities.
Let's examine BEAM's and contrast it to that of other virtual machines. In the end we might be able to answer if and why BEAM mandates Erlang's semantics. Or we might all become BEAM assembly programmers.
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
Learn how naively copying a grammar file from one parser generator to another won't work. Go back to the beginning and learn about lexers vs parsers, but discover that the power of interpolation changes the computational complexity and forces the lexer to be a push-down automata instead of a finite-state machines and how this maps to Erlang implementation of the tokenizers in native Elixir.
Understand that there are different types of parsers and what each of their names mean. Learn why some of the Ruby-ish feature of Elixir's syntax (like no parentheses function calls and do block) favor some parser types or others and why this complicates, writing the intellij-elixir parser.
Learn how intellij-elixir uses Elixir and JInterface to check parser equivalence and found bugs in native Elixir.
Slides (Viewable): https://kronicdeth.github.io/the-road-to-intellij-elixir-1.0.0
Slides (Source): https://github.com/KronicDeth/the-road-to-intellij-elixir-1.0.0/tree/gh-pages
Project (Source): https://github.com/KronicDeth/intellij-elixir/tree/v1.0.0
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
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.
Elixir (and Erlang) are often talked about as ""highly scalable"" languages. This talk will explore the ""other end of scalability"" - Elixir for the Internet of Things.
You will learn how to use Elixir with Nerves to build a small, powerful Elixir-based embedded system that boots in just a few seconds on a Raspberry Pi.
You'll also learn a lot about shipping real world products using Embedded Elixir.
Topics will include:
Using Elixir and Nerves to build production Internet-of-Things (IoT) devices
Advantages and tradeoffs in using Elixir (vs C) for embedded systems
How to explore these technologies with inexpensive devices like Raspberry Pi or Beaglebone Black
Live build, from scratch, of firmware for an Elixir embedded device
Managing the complexity of the cross-compile build environment
Remote debugging of IoT devices
Handling firmware updates safely and securely
The complexities of network configuration in IoT devices
Why Elixir is so suited to IoT
At Rose Point, we've been using Elixir with Nerves to build embedded systems for a couple years now, and we've shipped two commercial products based on the technology, with more in development.
We love this technology and believe it is an ideal platform for many Internet of Things devices. I'm excited to share our story with you.
Whether you're polling message queues, batching records to a datastore, or concurrently uploading a file in pieces to S3, interacting with external services is often complex. When this complexity mingles with your application logic your code becomes messy, hard to test, and fragile to change.
What if you could cleanup the mess with the use of Elixir streams? By choosing to describe these resources as `Enumerable` and `Collectable`, we can encapsulate this complexity and allow the purpose of the code to shine through.
Everyone is familiar with the classic streaming example:
The power of this way of writing code has very little to do with files, and far more to do with the way in which the `Enumerable` and `Collectable` protocols separate the concerns at work. There is tremendous untapped potential here for declaratively integrating external services with program logic simply and succinctly.
By implementing Enumerable for SQS, and Collectable for a task cluster, a stream could be just as easily be:
In my talk I'll cover concrete, practical ways you can encapsulate external resources in this way, yielding tremendous benefits with respect to clarity, versatility, and testing. I'll also go over some of the challenges presented by this approach, to include difficulties faced when making such streams proper OTP citizens.
Future changes to the standard library are likely to make great strides toward overcoming these difficulties, but they're already surmountable. My talk will show you how I've done it, and the decisions that you'll likely encounter along the way.
Elixir is an incredibly powerful language that sits on top of the battle tested and reliable Erlang ecosystem. This power is a big reason I am excited about building applications in Elixir. It enables us to write more of our application's stack in Elixir itself--especially compared to previous languages I have used.
Still, not everything can be written in Elixir. Sometimes you have to interact with the outside world, other tools, the operating system, or other code bases written in a completely different language. Thankfully, Erlang, and by extension, Elixir received a ""plays well with others"" award in kindergarten!
The Erlang ecosystem gives us several tools to work with other systems, processes, and code bases. In this talk, I'll cover the basics of each type of interoperability, as well as the pros and cons of each. These include:
Nifs: powerful native extensions
Ports: allow external programs to be treated like any other Erlang process
Jinterface: gives us interoperability with the Java Virtual Machine
These tools enable us to tap into the power of other ecosystems and make it easy to fit Elixir into our existing systems. This can be an excellent way to introduce Elixir into your organization and solve problems well-suited to Elixir.
This talk will start with the basics of match types, sizes, units, and encodings. We'll then cover function heads and logical branching with a real life example of recursive parsing using pattern matching. Towards the end, we'll cover how to optimize binary matching for BEAM and get feedback directly from the compiler.
This talk is relevant both to those new to Elixir and those looking to learn more about how to tune existing code for BEAM.
Building a real-world application with Ecto has taught me to think about building queries as data pipelines. In this talk, I'll discuss how this mindset helps build composable, reusable queries in Ecto that are easy to read and easy to extend.
I'll show lots of code around building and composing query pipelines. I'll also cover my approach to pagination, release as the hex package Scrivener.
One of Elixir's greatest strength are macros, and everybody knows that. However, macros are just one way to access a powerful and magical land: the compile time™.
In the last few months, I've been working on a gettext implementation for Elixir (under the direction of José). This library does most of its work at compile time.
In this talk, we'll have a look at what crazy things you can do at compile time as well as some examples of taking advantage of compile time in the wild (and in Elixir itself). We'll see how moving things from the runtime to the compile time has huge benefits in terms of performance, without sacrificing clarity and expressiveness. We'll dive into Gettext's source code as the main example of this.