A talk from Full Stack Fest 2015 (http://fullstackfest.com/)
Functional programming is being revitalized thanks to languages like Clojure, Haskell and Elixir. Even though Ruby is an object-oriented language there are many beautiful concepts in functional programming that we can borrow and successfully apply in our Ruby code.
In this talk I’ll show you how I mix FP with OO. I’ll introduce you to functional objects, explain the beauty of Proc-like behavior, the power of call method and explain why immutability matters.
Recorded & produced by El Cocu (http://elcocu.com)
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.
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.
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.
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.
They bridge your application and your database. They're object-relational mappers, and no two are alike. Join us as we compare ActiveRecord from Rails with Ecto from Phoenix, a web framework for Elixir. Comparing the same app implemented in both, we'll see why even with two different web frameworks in two different programming languages, it's the differing ORM designs that most affect the result. This tale of compromises and tradeoffs, where no abstraction is perfect, will teach you how to pick the right ORM for your next project, and how to make the best of the one you already use.
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.
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.
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.
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
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).
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.