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.
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.
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.
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
Show some results in the standard output is the first experience in how to debug your code. What is the next step? Probably, the first answer that you found was: start the observer. After some minutes with an awesome feeling, you asked yourself: What I should look here?
In this talk, you will meet some tools, learn how to debug and profile your system, check crash dump and how to find and deal with the most common cause of failure. More than that, you will understand the concepts behind the reports and the observer tool.
Like many of you, the organization I work for is deeply invested in an ecosystem other than Elixir, in our case Rails. However, we have lots of engineers interested in Elixir. The question: how do we get the rest of the developers interested and convince the bosses that Elixir is a worthwhile technology to invest in?
In deciding what to do, we had to consider the potential impact to our service (the Boss really frowns on taking down the site and annoying paying customers), the scope of the project (the Boss frowns on developers disappearing for a month to play with cool shiny things), intriguing the other engineers (engineers like cool shiny things). Balancing all these concerns was the key in getting buy-in from everyone.
We decided to build a status monitoring device using Nerves that shows the high level health of our app at a glance. We have LED strips showing recent apdex scores for our app (via NewRelic’s API), recent error rates (from Honeybadger), and the status of recent builds (from CircleCI), along with a big red flashing light for when Pingdom says our site is down.
For about $100 in parts, and a couple weekends of hacking, we built an appliance that was useful to the organization, showed off the power of Elixir/OTP, and was just darn cool!
In this talk, I'll go through how we created the appliance, the things we learned, and how this was a great project for introducing Elixir to the company. We’ll discuss why a Nerves based hardware project made sense given what we wanted to accomplish and the level of Elixir chops on the team. We’ll walk through the initial proposed design, and talk about how it evolved as we actually wrote the code. Finally we’ll take a look at the source code we ended up with, and see the monitor in all its glory.
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.
 - http://blog.drewolson.org/composable-queries-ecto/
 - https://hex.pm/packages/scrivener
As programmers, we know that the right abstraction unlocks new ways of thinking about the problems we solve. But can they do more? Can an abstraction exemplify our values? What might that look like? How would it feel to use? Do these words I'm typing right now even make any sense?
I'd like to share a recent experience with Elixir and Phoenix that convinced me, more than ever, of the power a well-chosen abstraction can have to create a truly joyful development experience.
"A Transmuting Journey: From a Ruby on Rails Monolith to Elixir and Elm Microservices "
MyMeds&Me is a startup company based in central London that provides a software as a service for pharmaceuticals to track the side effects of medications in a systematical way and exports the reports in a standardised format for the clients safety system. The current application is based on Ruby on Rails, Postgres and ElasticSearch and is hosted per client in a virtualised infrastructure managed by Puppet at a GxP compliant hosting provider. On the verge to grow the business we face some fundamental issues with the Rails application and it's architectural design. In order to grow the business and be able to scale the Dev team we had to find solutions for it. We addressed the issues in a new platform with a quite different approach. Different to Ruby on Rails but also probably to a typical Elixir/Phoenix application. In this session I want to present the solution we came up with and share the experience we made in this transmuting journey from a Ruby on Rails monolith to Elixir and Elm microservices.
What are the benefits and drawbacks of using an event-driven microservice architecture? Why did we need a new infrastructure approach? Why did we choose Elixir? Why didn't we use a distributed Elixir application? Why did we choose Elm for frontend services? Which challenges we had to face? How was the transition phase for the team?
Elixir and Erlang developers with any range of experience interested in software architecture and design.
Volker Rabe is a Technical Lead Architect at MyMeds&Me, a startup company based in Central London that provides a software as a service for pharmaceuticals. Previously he worked for xing.com and otto.de. Software architecture, application design and test automatisation is what he's passionate about with the focus on creating efficient solutions and sustainable software.
Nerves defines an entirely new way to build embedded systems with Elixir that is ready to revolutionize the industry. Embedded systems have never been easier to create using familiar tools and frameworks, and now we are making it even more connected.
Together, we will explore new features in Nerves which make debugging your target even easier. Learn how to create stunning user interfaces for touchscreen displays using Phoenix. Perform ExUnit on your target device, and more
Join us to learn more about the exciting new features which makes Nerves a powerful and productive tool for creating amazing new products.
Elixir's plug library is one of the most powerful packages we have within hex. It does not only serves as a foundation for Phoenix but also allows everyone to intercept and modify HTTP requests on the fly. Have you ever wondered how phoenix interacts with the underlying web server? In this talk you will learn how to work with plug. You will see some of plugs implementation details and learn just enough to build your own web server for plug and gain a better understanding of the relationship between Phoenix and Plug