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.
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.
Elixir is an elegant and powerful language. This makes the Raspberry Pi a usable server for Elixir Applications. What would happen if we had a cluster of Raspberry Pi devices? Can Elixir and OTP help with the distribution of the application? What would you do with a 16 core and 4 GB of RAM machine?
I’ll explore different techniques to deploy to a Raspberry Pi Cluster and how we can use the Elixir processes to balance the load between the devices.
“Why do you stick everything in a database?” —Joe Armstrong
Modern application development can be tough. You need to remember things with long term storage, you need short term storage for the times when that’s too slow, and you need another kind of storage just to remember who you are currently talking to. This process is obsolete.
Elixir affords us other options in designing our applications. We have ready access to:
Accumulate only data stores
Built-in caching via `ets`
Hot code reloading
These tools make it simpler to spend effort solving problems instead of working to satisfy some request/response cycle.
Through a sample application, we will explore these techniques and hone our recognition of when it’s possible to bypass complexity with straightforward data flows.
Make your apps run on state instead of CRUD.
Setting up Ecto outside of Phoenix is really simple and can be a great way to get started learning about Elixir. In this live-coding presentation, we will set up Ecto in a test project and dive into some of the great things about Ecto and how to use it.
00:00 Luke Imnoff: Decompiling .Beam Files
04:54 Fernond GalianaL: GraphQL
10:52 Dave Thomas: Code Like its 1999
19:25 Robert Beene: Talking to the Machine
26:10 Powell Kimmey Elixir Maths
Chris McCord is a programmer with a passion for science and building things. He spends his time crafting the Phoenix Framework, working with the fine folks at DockYard, writing books like Metaprogramming Elixir, and teaching others the tools of the trade.
Let me take you through the idea and realisation of vutuv. The fast and free LinkedIn killer.
If you are a developer or company evaluating Elixir and looking for convincing and compelling reasons to do so, Bleacher Report is a case study in the fulfillment of the promises of Elixir and Phoenix. Iterative code samples will illustrate how our understanding and use of Elixir and Phoenix over the last two years have led to greater developer productivity and happiness and more reliable, responsive and efficient systems. With billions of monthly visitors and push notifications sent, Bleacher Report is in a unique position to show metrics that validate the aforementioned claims. Metrics will convincingly show that technical problems with fluctuating traffic problems have been eliminated through the adoption of Elixir and Phoenix. Finally, learn how we were able to train all of our former Ruby developers to become Elixir developers with minimal effort.
The Elixir eco system is moving fast. So fast that we sometimes look to how we did things in other languages to inform what we should do in Elixir. This is a good starting place but ultimately does us a disservice. Let's take a look at how to TDD a web-based API in Phoenix with a suite a of tools that have been optimized for the "Elixir Way"
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 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.
Dave Thomas is a programmer, one of the founders of The Pragmatic Bookshelf, noted author of The Pragmatic Programmer, Programming Ruby, and Programming Elixir, as well as many other books and articles.