Video recording and production done by ElixirConf EU
I started learning Elixir by creating a couple of simple libraries, and have never stopped writing libraries since. In this process, I learned a lot about Elixir and Erlang, open source, API design, extensibility, documentation, and people. I tried to distil all of this in a data validation library called Saul. In this talk, I will share my learnings and thoughts on the library side of software, showing off Saul as a practical example.
It is the story of the birth of a quadcopter built using a 3D printer, a Raspberry Pi 3 and some Elixir magic. I will begin from the genesis of the project up to a flying drone. Expect some code, some hardware and some 3D printing time-lapse.
Nextjournal enables living documents for researchers. Our goal is to make technical writing and scientific research easily reproducible and shareable through beautiful typography and live coding tools.
In this talk I'll show how Phoenix channels, GenStage and Erlang ports elegantly solved the complex challenges of building a multi-language, browser-based live programming environment.
"Building a Graphical IDE in Elm/Purescript for an Embedded Language that Compiles to the Erlang VM"
Our PLC programming language implementation gets compiled to BEAM files and runs in the Erlang VM. That allows us to take advantage of Erlang's distributed model, and through our custom websocket library the IDE can talk directly with a Cowboy handler running on the device, to get debugging information in realtime.
We'll also cover our choice of framework when porting the IDE to Purescript, good and less good parts of the two languages, and how they relate to Haskell.
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
Thanks to frameworks like Phoenix, web services can be developed quickly. The result is scalable, fast and easy to adapt. A perfect platform to create really complex web services. When software gets more complex, it gets harder to test. There are many different parameters one can supply, posted JSON data types can have different dependencies and the order in which things happen may play a role. Thus, even if Phoenix helps a lot in getting a correct and complex web service produced, there still are possibilities for mistakes. These mistakes have to be found and testing is a way to do so. QuickCheck helps to automatically generate test cases for such web services.
José Valim is the creator of the Elixir programming language and the Director of R&D at Plataformatec, a consultancy firm based in Brazil. He is author of Adopting Elixir and Programming Phoenix as well as an active member of the Open Source community.
Introducing Elixir and/or Phoenix to a team is not without its challenges. New languages and frameworks tend to be tech debt heavy as developers learn and iterate. At Bleacher Report, weäó»ve had great success with training developers to use Elixir by focusing on application standards, community developed tools and consistent testing practices. As a result of these practices, our code reviews are more meaningful and developers are able to move between applications with relative ease. This talk will provide app standard suggestions, lessons learned and code review guidelines that will help your organization adopt Elixir and Phoenix and enjoy all of the immense benefits they bring without incurring the heavy tech debt that generally comes with new language or framework adoption.
Protocols are an important part of the Elixir language, and they play a key role in many of its prominent libraries. However, it's not always obvious how and when to use them. In this talk, we'll demystify protocols and see how to leverage them to solve real-world problems. We'll walk through some practical examples to see how protocols can solve a variety of use cases. We'll start with some simple examples and end with relatively sophisticated scenarios. We'll even dive into the Elixir source code to see how protocols are implemented on the BEAM. After attending this talk, you'll have practical understanding of protocols and the use cases they can help solve.
Machine learning is a popular and rapidly growing field these days, but there aren't a lot of machine learning tools available in Elixir; some in the programming community have even suggested that BEAM isn't suited enough to the necessary number crunching to do serious machine learning work. Not so! In this talk, we'll walk through training a home-grown neural network written in Elixir on financial data from the S&P 500, then develop a Phoenix application to use that network to try to predict stock prices.
GraphQL is a query language for your unified API. What you ask for is exactly what you get. This holds true no matter what backend powers your API, whether an Ecto backed Database or other APIs themselves. How does this work in practice? In this talk we're going to walk through a service that exposes a 3rd party REST API via GraphQL, augmented with database driven metadata. We'll see how GraphQL can efficiently query both data sources without sacrificing client flexibility, and even provide push notification features not found natively via the REST API or the database.
Coming with Erlang R19 is the option to use your own distribution module. This creates the possibility for having auto-connecting Nerves devices without worrying about the local network or specifying node names upfront. In this talk I will explore the different solutions up until now. One of which was my first go at creating "distributed blinky" (having a led blink on 2+ devices taking turns). Then I will take a look at how we can create our own distribution module and see how we can leverage that so we don't need any upfront knowledge about node names and are independent of the local network. Our goal is to create an autonomously connecting Nerves cluster with zero effort! But, can it be done?
The elixir of life is a mythical potion that supposedly grants the drinker eternal life and eternal youth. This elixir was said to cure all diseases. Alchemists in various ages and cultures sought the means of formulating the elixir. Today, thanks to José we can all use Elixir, and once you have tried, it's hard to stop. Why Elixir is so addictive? How is it transforming lives?
In this talk we will take a fun peek at the development of Elixir, and remind ourselves how it all started. We’ll join a whistle stop tour through the years from inception, learning how both the language and the community got to where we are today. We’ll take a closer look at some examples of how elixir has transformed the lives of those who have jumped in with both feet. And finally we’ll take a cautious but brave look towards the future, what opportunities might lay in the road ahead.
Successful mobile games have huge amounts of simultaneous users, which requires a scalable server in the backend. Getting featured in a store can also cause a rapid rapid ramp-up, putting even further pressure on the scalability of the backend. In this talk I'll present how Ministry of Games is tackling the scalability problem with distributed Elixir. I will cover how our system is implemented in Elixir as well as some practical aspects of deploying the Elixir server to a Kubernetes cluster.
I would like to present a brief overview of the variety of tools available for visual reasoning about concurrency patterns, ranging from Erlang/OTP (Observer, erlyberly) through Elixir ecosystem (visualixir), to the toolset available for other concurrent platforms like Go (gotrace, streamtools). The second goal is to showcase a proof of concept for a visual tool that extends the feature set of the aforementioned ones, with a strong focus on specific Elixir abstractions (like GenStage + Flow), rather than concurrency primitives.
Erlang comes packed with a great tool for manually monitoring, debugging, and visualizing Elixir processes: observer. However, it is not always possible to use observer to monitor due to restrictions in the current world of mixed ecosystems, micro services, and docker containers. We offer a new solution :wobserver. It will allow you to directly monitor any node, while offering additional options like:
- web interface, view from anywhere, from any system [with a browser]
- api, json api for automated monitoring or integration with other applications
- system metrics, pre-formatted metrics, simple to integrate with other software
- node discovery, discover nodes behind load balancers and view them all through one single interface
- simple, just add it to your mix file and you are up and running
In the talk we will go through the background of the project and show you how to mount :wobserver into a Phoenix application, hook it up to Prometheus, and deploy it behind a load balancer.
There's a lot you can learn about the pitfalls of a language when you see literally hundreds of people all solving the same problems - and frequently making the same mistakes! In this talk we're going to start with some common, but less than optimal, solutions to some of the problems on exercism.io, and we'll do a step by step refactoring. We'll also add in some benchmarking to the existing exercism.io test suites to show the performance benefits of some of the refactoring that we do, and discuss the tradeoffs of the decisions that we're making to illustrate why this refactoring is beneficial.
Availability should be one of our major concerns when writing web applications, yet more often than not we ship code that is simply not resilient enough. Elixir and OTP provide powerful tools to improve resilience and increase availability: in this talk we'll look at how we can leverage them to provide continuous service even when our database is down. The talk will be a walkthrough of a refactor of an Elixir application with a Phoenix frontend, powered by PostgreSQL
Can you have one and only one process consistently in a distributed system using elixir? :global, :pg2, something else? What about network partitions and stuff? Let's build and test some examples.
Dealing with money should be easy, because crunching numbers is the most basic thing that every computer can do. On the other hand, the cost of a mistake may be quite high. I am going to discuss what properties does a financial system need in terms of CAP theorem and how does using Elixir language fit into the problem domain. The talk will cover handling rounding errors, designing APIs that gracefully handle network and hardware failures, and usage of "let it crash" approach in the design. It is also a case study of using Elixir in real life. Lets discuss Elixir and money!
At SQUARE ENIX, we recently opensourced a background processing library called TaskBunny. In this talk, we will go through:
- the design decision we made to use RabbitMQ instead of using Erlang process/OTP
- the features the libraries offer
- some implementations we like to share. For example, how TaskBunny uses the OTP supervisor to handle connection loss
Additionally we want to share our story on how we came to opensource our library. We were hesitant to opensource at first, because we thought that using RabbitMQ for background processing wouldn't look attractive to Elixir/Erlang developers. But we did it anyway and we are very happy about it. We hope our story will encourage other developers and teams to share their works as well.