Every new language or framework needs time to prove itself in production, for its early adopter to try, fail, iterate, and document what they have learned. Elixir and Phoenix can leverage the 30 years head-start of the underlying Erlang platform, but for newcomers to the platform it is not always easy to find and apply Erlang best practices. This talk explores some specific security-related aspects of Elixir, Phoenix and the Erlang VM, through practical demonstrations and use-cases. Topics covered include: use of Erlang's 'ssl' module, distributed Erlang, and VM hardening against DoS attacks.
The purpose of this talk is to make people familiar with some of the Erlang/Elixir specific security considerations. It is focussed on those things that may surprise people coming to Elixir from other languages, and therefore skims over common attack patterns (XSS, CSRF, SQLI, etc.) and their mitigations.
Anyone planning to deploy an Elixir application, with or without experience in deployment/security using other languages/platforms.
Bram is a system architect and security advocate at Cisco Systems. His work focusses on massively concurrent back-end systems for IoT/IoE applications, preferably built using Erlang/Elixir, as well as PKI-based security solutions for such environments. He has previously built/designed API servers using Ruby on Rails, as well as VoIP soft switches in Java.
Starting with a brief explanation for why Elixir is an excellent choice for embedded systems, we will look at how to building a cool Elixir robot, using [Nerves](http://nerves-project.org). You will learn how to: * get started (often the hardest part) * structure an embedded OTP appplication * customise an embedded linux using Buildroot/Nerves * control your robot using an embedded web server * control your robot with [Slack](https://slack.com) You will leave this presentation with more than just inspiration; you will have an actionable plan to make something fun with embedded Elixir. You will also have a genuine stepping stone towards creating a robust and secure _Internet of Things_ product.
The audience should leave with a clear understanding of how to get started with embedded Elixir. It will be a practical, rather than purely inspirational talk.
Those with some Elixir knowledge, but no experience of using Nerves to embed Elixir.
Paul is a coder with 20 years experience (only a couple with Elixir, though). Paul has spoken at various conferences and events including RubyConf, The Naked Agilist, and guest lectures at Glasgow Caledonian and Edinburgh Napier Universities. Paul is now CEO of Cultivate Software. He was also part of the team that won the giant banana presented to Jim Freeze at Elixir Conf 2015.
With nearly 3000 commits and 200 contributors Ecto is one of the biggest and oldest Elixir repositories. Not only that - it's one of the most popular Elixir projects. And yet there's a lot happening all the time, especially now with the 2.0 release. Looking at the commit history of Ecto one can discover a journey most of Elixir developers take - first trying to force object-oriented habits into functional frame, later sprinkling some functional goodness here-and-there to finally entirely accept and embrace it and fully leverage OTP. The talk will take us through this journey focusing though on the more recent changes. Audience will discover how changes in the language affected the library and, in reverse, how the development of Ecto affected Elixir itself. For a short time, the talk will focus on the NoSQL integration, what it means and why it was possible to integrate, rather SQL oriented Ecto, with NoSQL databases that easily. We'll see exactly what architectural choices in Ecto and what features of Elixir allow for creating such a versatile software. Briefly, other database libraries (in Elixir and not only) will be looked into in search for the inspiration of some of the Ecto's features. We'll see how those ideas were incorporated, modified and expanded upon. The bulk part of the talk will centre on the recent changes, exploring and explaining them in depth. It will focus especially on changes affecting application's architecture and promoting functional style of programs: migration from Model to Schema, deprecation of callbacks and introduction of Ecto.Multi. With that last change, we'll discuss a new way of building application's service layer for database interaction that Multi makes possible and easy to build. Finally, together, we'll look into the future and wish how Ecto and it's ecosystem can be further developed and expanded.
* Gaining a better understanding of what functional programming means through analysis of real code and looking into it's evolution.
* Exploring how Elixir can be used for building flexible and clean software.
* Understanding basic concepts of Ecto, it's recent changes and new features.
* Finding out how database applications can be structured with the use of Ecto.
Intermediate developers familiar with Elixir and it's concepts. Some knowledge of Ecto may help but it is definitely not required.
Student during mornings, developer at afternoons and open source contributor by evenings. Michał is programming languages enthusiast, recently discovering various programming languages, but focusing mostly on the functional side. He's Interested not only by the regular web development issues, but also by the academic side of programming - the more computer-sciency stuff especially around language design, compilers, and virtual machines. He is a member of the Ecto core team and maintainer of the MongoDB adapter. He co-organizes the Silesian Beamers meetup that is gathering over a dozen attendees each month - there he hosted couple workshops and presented a talk or two. He's Google Summer of Code 2015 alumni, where he worked on Ecto and it's MongoDB integration supervised by José Valim himself. Occasionally he's blogging about various things at http://michal.muskala.eu/ and usually hangs out on IRC and Slack trying to help people starting their adventure with Elixir. When not programming he enjoys reading books, travelling, and sailing - no matter if sunny, rainy or stormy - it's even better if all of those are combined!
"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.
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.
Through Erlang, Elixir developers have access to some amazing tools for building resilient distributed systems. riak_core is one such tool: it provides the framework behind Riak’s high availability KV store. In this talk, I’d like to explore some unconventional architecture by using riak_core and Phoenix to build fault-tolerant stateful web applications. What happens when the app servers are also the database nodes? Can we avoid some of the traditional pitfalls of stateful servers? Is this a remotely good idea? Let’s take a look!
1) Stateless/stateful setups for web applications — what do these words mean?
2) CAP in brief, consistent hash rings for distributing work: what are the tradeoffs?
3) riak_core - what does it do? Paraphrasing Mariano Guerra’s excellent work.
4) Build a Phoenix application that cohabitates on a riak_core hash ring. What superpowers do we gain from this? What do we have to watch out for? Can we do cool tricks with load balancing or channels? In-memory databases for super-speedy responses?
5) Loosely comparable systems in production/prior art - Microsoft Orleans, Facebook Scuba, others
Intermediate+ Elixir programmers, web developers, students of distributed systems.
Ben works on service discovery, maps of the infrastructure, and human-system reliability.
This talk will discuss how the Phoenix team was able to create a single chat room with 2 million users on a single machine. Benchmarking WebSockets is a little more in depth than benchmarking HTTP requests, this talk covers the Tsung tool which was used for the benchmarks and how it can be configured for different testing scenarios. I will cover how Tsung was used to find the concurrent connection limits that Phoenix could handle. I will then cover the techniques that were used to find the parts of the Phoenix codebase with the bottlenecks that caused these limits and how these limits were overcome.
Learn how to benchmark WebSockets using Tsung Explore how to find and fix bottlenecks.
Anyone interested in Phoenix Channel performance.
Gary is a member of the Phoenix core team, often found answering questions on StackOverflow for the elixir and phoenix-framework tags. He is developer at VoiceLayer using Elixir and Phoenix on a daily basis.
José Valim, Elixir Creator, is a member of the Ruby on Rails Core Team and a writer for Pragmatic Programmers. Software developer for 8 years, he graduated in Engineering from the São Paulo University, Brazil and has a Master of Science from Politecnico di Torino, Italy. He is also the lead-developer of Plataformatec, a consultancy firm based in Brazil, an active member of the Open Source community and is frequently travelling and speaking at conferences.
Chris McCord is the creator of the Phoenix framework, and author of Metaprogramming Elixir and Programming Phoenix. He spends his days crafting OSS and web applications at DockYard. His current interests focus on new web technologies, distributed programming, and teaching others the tools of the trade.
Today's developer tools are mostly used in a very technocratic fashion where there's success and failure, 1 and 0. Either a tool thinks you're totally wrong or you're 100% right. You get shouted at or praised. There is no middle ground. Except there is. Credo, the first teaching code linter for Elixir, puts its focus on the in-between: How errors can be opportunities for learning. How AST analysis can be fun and educational. And how one can combine these features into a professional tool that gives straight results while still treating its users as human beings. This talk will show the importance of teaching, learning, user experience and interface design so everyone can see how the idea of "less dogmatic code analysis" led to the creation of a tool that excites Alchemists around the globe.
Phoenix and Phaser might sound like a cheesy pop band but get these two frameworks playing nice together and you're guaranteed a party. Both are blistering fast, and incredibly easy to use. Building multiplayer games has never been easier.
This talk will take you on a step by step guide building yourself a game template, and then using that template to create several multiplayer games. We will introduce you to the joy of creating games using these two wonderful frameworks, and demonstrate some of the possibilities, as well as highlighting some of the challenges and common pitfalls to avoid when developing multiplayer games.
Beginners and anyone interested in having fun with Phoenix channels.
Keith is a programmer, sailor and kitesurfer in any order. He is passionate software development and particularly enjoying building fun social games. He is currently writing a book of the same title as this talk
Nerves defines an entirely new way to build embedded systems with Elixir that could revolutionize an industry. Imagine booting to the BEAM VM in just a few seconds with your Elixir app in control of the entire system. Nerves makes this possible while replacing the traditional plethora of Linux init scripts or systemd configuration files with a toolchain that is delightful to use. The Nerves philosophy is that you already have a powerful, concurrent language to define what the system should do at start-up time: Elixir. Together, we'll explore the principles Nerves uses to create embedded systems that control 3d printers, power unmanned areal vehicles, and more. You'll see first-hand how Nerves can support service discovery, hot code swapping, and collaboration through PubSub messages and mesh networking. Finally, we will explore the Nerves development life-cycle; from running ExTest, to deployment and hot code reloading.
* Introduce developing embedded systems in Elixir using Nerves
* Explore the Nerves development life-cycle
* Demonstrate autonomous robotics using service discovery and messaging
* Execute tests, create user interfaces with Phoenix, and perform hot code updates
Creating devices and systems which enhance our environment is fundamental to our nature. The exploration into creating hardware that runs Elixir is geared toward the maker in all of us. Join us for an exciting demonstration into the creation of enhanced embedded systems with Elixir and Nerves.
Justin started his career as a recording engineer spanning several years in the early 2000’s. He transitioned to programming C++ apps in the public sector of local government in 2005 and eventually came to master iOS development while working for an interactive marketing company. During this time, he gained a passion for embedded systems, sparked from his love of riding motorcycles. Over the years, Justin has worked on a plethora of embedded projects from iPhone motorcycle starters to advanced brewing and distilling equipment. Recently, Justin founded Metasphere, an embedded software company primarily focused on building Bakeware and Nerves.
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.
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.
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.