An ElixirConf™ Production - Copyright © 2016
Paul is an insatiably curious developer who has spent the last year deploying Elixir projects using a variety of methods. He is an active part of the local Ruby user group, where he helps to organize and present on topics ranging from Elm to OPS and is currently nurturing a love of functional programming. When he's not losing arguments with computers he can be found exploring Oklahoma on his bicycle and drinking copious amounts of coffee.
Releasing an Elixir application can be baffling. We have excellent libraries at our disposal but the real world is littered with requirements and edge cases that can make using these tools difficult. This workshop will explore the individual steps of building a release. We will follow Distillery's lead through constructing and running a compiled Elixir application. You'll leave with the ability to assemble a release by hand, a solid foundation for troubleshooting and customization, and a healthy respect for what Distillery does. Elixir knowledge is highly recommended, ops knowledge is optional; curiosity is required.
Rob Keefer, PhD, is Co-founder and Chief Scientist at POMIET, a software systems consultancy. He has 20+ years of experience delivering innovative software solutions that implement approaches for better human/computer interaction. Rob has authored several articles, white papers, and presentations on software craftsmanship, Agile practices, and user experience design. Rob holds a Masters in Human Factors Engineering and a Ph.D. in Computer Science. He has worked across several industries with more than 30 clients including Major League Baseball (mlb.com), FedEx Office, and TIAA-CREF.
Whether you have experienced the awesomeness of developing with Elixir and Phoenix, or simply want to learn how to take advantage of modern multi-core CPUs, the concurrency that Elixir provides is a great start to amping up the performance of your applications. In this hands-on workshop you’ll be introduced to concurrent programming concepts and the methods for implementing these concepts in Elixir. At the end of the workshop you will have built a fault-tolerant, multi-process communication application. Topics covered in this workshop include working with multiple processes, the blackboard software architecture, plus Elixir specifics such as GenServers, Supervisors and Workers.
Greg is a member of the Nerves core team and loves to help new people join the Nerves community by writing documentation, answering questions in Slack, and giving presentations. He’s also quickly becoming an Elm evangelist.
Developing a custom hardware/software embedded system can seem like a daunting or even impossible task. With Elixir and Nerves, you can quickly get started with a Raspberry Pi-based project and walk away from this one-day precompiler session with your own WiFi-enabled, video-streaming webcam and all the skills you need to customize it.
This session is beginner-friendly. That includes those who are new to Nerves, new to Elixir, or even new to working with hardware. Some programming skills will be required, but working code will be provided along with the hardware, so you only need to make changes that you’re comfortable with. It’s very unlikely that you’ll melt, damage, or ruin anything. ;)
Sonny Scroggin is a software engineer with broad interests in the world of computing. He is a core team member of the Phoenix Framework and is working on various libraries within the Elixir ecosystem. You can find him presenting or teaching others about Elixir, Phoenix, and other tools and libraries in the local user groups in Nashville, TN and at conferences around the world.
Phoenix is an Elixir framework for building scalable web services with realtime connectivity across all your devices. Together, we’ll take a guided tour of the framework, going from the very basics, to building our own realtime application. You’ll see the framework’s foundations, core components, and how to use Phoenix to write powerful web services. We’ll start by exploring the foundations of the framework in Elixir’s Plug library, followed by the core components of Phoenix’s Router and Controller layers. Next, we’ll review the View layer and build an application together as we learn each concept.
We’ll finish by using the PubSub layer to add realtime functionality to our application.
Along the way, attendees will see how to apply advanced features like router pipelines and plug middelware and receive tips on how to structure a Phoenix application for real-world services.
Dennis Beatty is a 26-year-old software engineer at Podium, favorite older brother to five, and Utah's worst mini golfer.
Ecto makes it incredibly easy to work with slightly more advanced SQL features. There are several gotchas to dealing with some of these though. I have discovered some of these while maintaining a database of scraped data and a basic recipe app. By recreating these in a simple manner, we can easily understand the need for upserts and fragments. We will be able to explore the handling of many-to-many relationships (including a discussion of put_assoc vs cast_assoc) and talk about the best way to efficiently insert and update high volumes of records.
Niall is a software engineer based in Berlin, Germany. He can be mostly found building API’s in ruby an elixir. Even though he works on software to help machines to talk to machines, he has a strong interest in usability. He wishes the rest of the internet shared is interest.
API versioning is hard. Upgrading versions usually involves pain, for a public-facing API, that pain is usually borne by the customer depending on our API. Instead we’re trying to take the pain out of versioning an API, at least for the user.
Inspired by Stripe’s API (https://stripe.com/blog/api-versioning), we’ve been working on implementing rolling, ‘point-in-time’ versioning for our API. It allows new features and changes to be made to the API regularly, instead of having to wait for a major version upgrade. But more importantly, it keeps the whole process simple for users. Users only need to think about versioning if they want to. They can build an integration when they sign up, and know it will continue to work without needing changes. If they want new features they can upgrade to newer versions on their own timeline.
Implementing multiple versions of an API sounds like a terrible idea. Just the thought of branching business logic in multiple places based on what version you’re serving makes me shudder. Instead of implementing multiple versions, we can implement just one version, the latest version, and layer the older versions on top of this.
Functional languages are great for transforming data, and if you’re using Elixir for Plug-based web applications this pattern works very nicely. Phoenix is a perfect example of this - it’s basically a collection of plugs that transform a connection as it makes it’s way through the application.
With this in mind, using elixir and transformation modules, we can step through versions by transforming our requests and responses. We’ve been using this to keep our API customers happy and our codebase clean and I’d love to talk more about it.
Ben currently works as the infrastructural engineer / mad science programmer / whatever is needed that day at System76. He is a graduate of the Computer Science program at Vanderbilt University. His professional interests include open source, software craftsmanship, Elixir, and whatever shiny new thing just came out. He spends his free time snowboarding, dreaming about snowboarding, and recovering from snowboarding injuries.
We all love greenfield projects but more often than not we have to build on legacy databases of widely varying quality. Listen to a few war stories and in the process learn tips and techniques for dealing with bad table and column names, unfortunate data types, questionable serialization formats, inconvenient table structures, and inconsistent historical data.
Osa Gaius is an engineer at Mailchimp. Previously, he worked at Luma, where he helped build realtime web apps and IoT devices in Elixir. He organizes the Elixir Meetup in Atlanta, where he educates newcomers to Elixir using interactive workshops. In his free time, Osa crafts hip hop beats and dances Tango.
Members of the Elixir community often receive the question: “why should we use Elixir?” The answer to this nuanced question remains elusive, and this talk argues that the answer is not primarily technical. This talk argues that answering this question, as a community, will define the success or failure of the language. This talk presents an approach to answering this question by exploring Elixir’s place in the history of functional programming. In particular, it provides an analysis of why functional languages like Elixir fail to garner widespread adoption and diverse communities. Secondarily, it takes the position that Elixir’s utilization of the Erlang virtual machine, is both an advantage and disadvantage. More importantly, this talk offers a way forward by highlighting approaches that the community can take to avoid the mistakes historically made by the functional programming community.
Engineering manager for sensay.it. Lifelong newbie with a late start into tech 3 years ago at 32. Now a fan of building bots, writing elixir code and lately poking at the blockchain.
Why would you want to use (or suggest) Elixir to a startup? Over the past 5 months that's exactly what we've been doing. Transitioning from ruby to elixir has been a great experience, but we've noticed unexpected benefits that suit startups perfectly.
Some of the benefits we've noted: Uptime, release speed, scaling, onboarding and recruiting.
I'l share some experiences on how this can be something you can use in your own startup, or pitch to your existing team.
Chris is a software engineer building services and applications for Le Tote. Although he started out writing C for embedded systems, these days he spends his time in Elixir, Haskell, Elm, and Rust. When not writing code for work, Chris can be found writing code for fun, talking about the joys of functional programming, playing pinball, roasting coffee, or building Lego with his kids.
Elixir and Erlang provide powerful mechanisms for building systems that are always available. But when it comes to building distributed systems that need consistency Erlang leaves many of the implementation details up to the programmer.
In this talk we'll discuss the trade offs between systems that are always on and systems that are consistent. We'll look at the types of guarantees that standard Erlang tooling gives us as well as their shortcomings. Finally we'll look at several patterns and techniques for building consistent, distributed systems using elixir.
I'm a software engineer working for DockYard, and the creator and maintainer of several open source Elixir tools/libraries, such as Distillery, Conform, Timex, and others.
With my new role being focused full-time on implementing the next phase of deployment tooling for Elixir, I want to share with the community what those tools will look like, what will and will not be part of the core Elixir tools, and what problems we're aiming to solve in this phase, and in the future.
Beginner, Intermediate, Advanced
Jerel worked for a number of years as an independent contractor building software in the public safety, medical research, and agriculture spaces. He now uses his Elixir skills at Toyota Connected building software for car sharing around the world.
You wrote a beautiful Elixir application and have been running it on one node. Now you need to add additional nodes for scaling or resilience. The web layer works fine as-is but you have a few processes that should run once in the entire cluster, not on every node. What to do? In this talk I'll show how we've solved some problems at Toyota Connected using Swarm and GenStateMachine and how you can apply similar solutions to your application.
I've been involved in Elixir since 2013 and it's taught me (and is still teaching me) so much. I believe the software industry would have been better off if Erlang/BEAM had a larger impact earlier, but let's make up for lost time and enjoy what we can of it now. I've been programming professionally for 20 years and consider myself a mid-career programmer. There's so much left to learn and enjoy about programming!
Well, the first rule of Fight Club, I mean: process dictionary is that we don't talk about process dictionary. That's wise because people new to functional algorithms and immutable data structures may use it as a crutch, however, once we're comfortable with that background, we should no longer be afraid of it. There's legitimate reasons when to use it and when not to use it, which we'll discuss in this talk.
Brien Wankel is a Principal Engineer at Lab Zero in San Francisco, CA where he focuses on Elixir development and deployment. He spends most of his free time with his family exploring the remote backcountry of Arizona and the Southwest in their self-supported off-road adventure vehicle, Jolene. He enjoys thinking about the dusty gravel intersection where off-grid meets technology.
Get started exploring your vehicle’s electronics network safely and responsibly. With a Raspberry Pi 3, Nerves, Elixir, and a few open source tools, diving into your vehicle’s interior CAN-bus network is easier than you may think. This talk will demystify the process by going over how I used these tools to tap into the brain of my Jeep adventure rig, Jolene, in order to add a few new features.