Let’s talk about language exploration. We’ll discuss how to learn a new language, considerations when introducing things to production, and come up with some ideas for Ruby and it’s ecosystem. Plan on dipping your toes in Elixir, Go, Haskell, Rust, and Scala during the session.
Concurrency is all the rage. When you have tons of data being shoved down your throat, you need all the help you can get. All the cool kids are turning to alternatives to try and keep up: node.js, clojure, erlang, elixir, Go. Popular thinking is that Ruby is too slow and “won’t scale.” But our favorite friend can support it very well. In this talk we’ll take a look at the actor pattern in Ruby with Celluloid and compare to similar solutions in other languages.
WebRTC brings peer-to-peer communication to the browser in a way that could revolutionize the modern web. Phoenix Channels are great for real-time client server apps, but sometimes parts of your application need lower latency that only P2P can offer. From telephony to video conferencing, P2P communication will drive the next generation of web applications. We'll review WebRTC from the ground up, and what you can expect when using it. Along the way, we'll see code from a real-world application and the lessons learned integrating WebRTC with Phoenix channels.
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.
When a Rubyist hears "concurrency" they usually Google Elixir, Go, or even Node.js. Turns out, Ruby can be great for concurrency! The Global Interpreter Lock (GIL) does NOT prevent Ruby programs from performing concurrently. In this presentation we'll discuss the true meaning of concurrency, explore the inner-workings of the GIL, and gain a deeper understanding of how the GIL effects concurrent programs. Along the way we'll write a bunch of concurrent Ruby code, run it on multiple interpreters, and compare the results.
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.
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.
You have been warned.
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.
Feature tests are one of the best ways to ensure reliability and consistency for web applications. But, as your test suite grows feature tests can become a performance bottleneck. This leads to developers running their tests less often or only on the continuos integration server. In some cases it means avoiding feature tests altogether.
Luckily, the release of Ecto 2.0 means that its now possible to run concurrent browser tests. Wallaby is a tool designed to take full advantage of that.
In this talk we'll look at how to configure a Phoenix application for concurrent testing, give a brief overview of Wallaby, and showcase how we can use data transformation and composition to quickly build a highly concurrent test suite.
ActionCable – одно из самых примечательных нововведений Rails 5, которое буквально всколыхнуло Rails сообщество: статьи, инструкции по применению, "лайки" и "репосты" в Twitter. Это не удивительно: минимум настройки сервера, использование бизнес-логики (и даже шаблонов!) в _каналах_, JS-клиент, который просто работает – это пункты "за".
Но есть и весомое "против": все это написано на Ruby – языке, который я очень люблю, но который пока еще сильно уступает в вопросах масштабируемости и производительности _конкурентных_ приложений, а значит, либо ваше приложение рухнет под нагрузкой, либо ваш чек за серверные ресурсы начнет стремительно расти.
А теперь давайте представим, что никаких "против" нет, а есть _идеальный_ ActionCable с приятным Rails интерфейсом и производительностью и надежностью Erlang/Elixir приложения (с "2 million connections"). Я хочу представить свою попытку "приблизиться к _идеалу_" – AnyCable.
VoiceLayer is a real-time voice messaging platform developed using the Phoenix Framework. Its media router core service must be resilient to a wide variety of adverse conditions, including software, hardware and even network failures.
According to the CAP theorem, a system can only meet two of the following three guarantees: Consistency, Availability or Partition Tolerance. We will characterize Available and Partition Tolerant (aka AP) systems and describe different implementation approaches.
One such approach is based on Riak-Core, which is the distributed systems framework that forms the basis of how Riak distributes data and scales. Despite Riak-Core being an impressive framework, at VoiceLayer, we took a different route and relied on Phoenix Tracker (a core component of Phoenix Pubsub) to meet our requirements. We will describe this approach details, contrast it to other solutions and discuss its tradeoffs.
So, you've played around with Ecto, and maybe even shipped an app or two that uses it. But you still have this sneaking suspicion that you might not be using it as effectively as you could, or maybe you just find yourself Googling for examples a little more often than you'd like.
Let's get you levelled up.
In this hands-on, practical talk, you'll learn about some of the foundational principles behind Ecto, and walk through a series of examples, starting from the very simple and ending with the truly gnarly, to help you understand how Ecto works and how to use it more effectively. You'll come away with a better understanding of Ecto, and a cookbook of examples you can refer back to when you need a refresher. Feel free to bring a laptop and code along!
With the announcement of Phoenix 1.3 supporting umbrella projects at ElixirConf 2016, I was inspired to start early on converting our Phoenix 1.2 application to umbrella. Since the umbrella project templates weren't publicly available yet, I had to find the seams in our single, monolithic application where I could start breaking it into OTP apps for the umbrella project.
I'll cover the thought process of how I broke up the app and what guidelines I use now when adding new code as to whether add it to a pre-existing application or to make a new OTP application. I'll share the common code I was able to share between our RPC server and API controllers, which I believe is a good behaviour for resource module in Phoenix 1.3.
Developing "hardware and hardware accessories" can be difficult and time consuming. Until now, you would have to constantly swap SD cards or create and push full firmware updates in order to iterate on your device. We want to make the development cycle as comfortable as possible by marrying the fundamentals of Erlang hot code reloading with connected Hardware in the Loop (HIL). Together, we will explore the Nerves development cycle through live demonstrations from mix nerves.new to mix firmware. Furthermore, we will push live code updates and even leverage the Phoenix Live Reloader on the Target. Finally, we will take a peek at executing ExUnit tests on connected hardware.
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.
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?
From the conclusion, it is to put a star on projects at GitHub. I'm very happy someone putting a star on my project. So if you already put a star on any projects, it encourage the open source community. But have you put a star on projects developed as oss used in your project? All of them? This talk proposes a solution that activates open source community by putting a star on projects which you depend.
Takayuki Matsubara is a software engineer at M3, Inc. His day job is building and maintaining web apps. He loves open source community, has created chrono_logger, Power Assert in Elixir and other various.
Ruby is used everywhere now. In this talk we will compare Ruby concurrency with Node.js, JVM, Erlang and others.
Ruby supports concurrency but with GIL, it can't run threads parallely. We will explore options available that makes this problem irrelevant.
Node.js doesn’t support concurrency or parallelism. Node.js is single threaded. It runs an event loop which makes non blocking IO possible. We will explore why Node.js fits well to only certain types of problems only
JVM supports native threads and can do parallelism. But in JVM memory is still shared among different objects. We will explore JVM architecture in regards with memory. Where JVM gets it wrong.
Erlang/Elixir achieves concurrency and parallelism with shared nothing, immutable data, first class processes, actor model. We will explore whether this approach is better for solving every kind of problem.
Talk will have deep comparison with all of these platforms in regards with what most real world project need,
Anil Wadghule, @anildigital
I am a geek but a senior software developer by profession, currently working for Equal Experts, India. When not programming, I spent time in exploring music around the world. Emacs is my text editor of choice. I love watching Japanese animes.
Making distributed systems that scale to many machines is easier done with Erlang/OTP than most other technologies. Deploying, managing and monitoring thousands of Erlang nodes prepared for massive load, however, remains a tough (and repetitive) challenge. In the context of the EU funded RELEASE project, the main task of WombatOAM is to provide the scalable infrastructure for deploying thousands of Erlang nodes. It provides a broker layer capable of dynamically scaling heterogeneous cloud clusters based on capability profile matching.
In this talk, I will tell you how the scalability and robustness capabilities of WombatOAM were addressed, allowing us to deploy and monitor 10,000 Erlang nodes running an ant farm simulation in 4 minutes. The talk will cover the journey – focusing on the analysis of WombatOAM (using WombatOAM, as we like dog food), on the applied techniques and on the key decisions taken when advancing WombatOAM.
Learn how to detect bottlenecks in concurrent system.
Explore an approach to scaling Erlang clusters.
Discover how to predict and prevent possible outages.
Developers, Support and Operations staff who believe devops is the way (and do not want to be woken up at night).
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
As software developers, a lot of the time we’re building applications that rely on some sort of network connection. Due to Ruby’s great abstractions we take most of the network related stuff for granted. We think we know how all of that works, but do we? Let’s go over the fundamentals together, learn about how Ruby models TCP Sockets and how we can make a good use of it.
This talk will explore the fundamentals of programming with sockets. This includes creating sockets, client and server life-cycle, reading and writing data, non-blocking IO and connection multiplexing. We’ll wrap up by looking at how those concepts are used in real world problems by web servers.
About Sebastian Sogamoso
Hola! My name is Sebastián. I am love pair programming and have a passion for teaching. I am part of the Cookpad, Inc team.
I organize RubyConf Colombia and I am also involved with local software development groups and help organize the Bogotá Ruby and Elixir meetups.
Delivered at WindyCityRails 2016 in Chicago, IL, USA.
Learn more about WindyCityRails at http://windycityrails.com.
"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.