RailsConf 2016 in Kansas City is one of the Ruby community’s most important international events. Working for a company which contributes to Ruby-related events as part of its strategy to build high-performance software teams, I felt like it would be a nice idea to share which talks I’ll attend, and the reasons why I wouldn’t miss them, hoping to help you decide how to spend your time during the event.
I tried not to be biased by who’s giving the talk, whether it’s sponsored or not, or any other factor — instead, basing my selection on the abstracts that I liked the most.
About the kind of topics that I like, I often tend to mix “show-me-the-code” and “soft” talks when I go to conferences. I think both are important to being a professional developer. However, on this occasion I wanted to shrink my list down to only 10 options and I winded up just picking technical talks.
So, here are the 10 talks, not ranked in any particular order, that I think you shouldn’t miss during RailsConf 2016. Or, putting it another way, if you were me you wouldn’t miss for anything.
Talk #1 – Real World Docker for the Rubyist
Docker is gaining popularity and promises to beat virtual machines (VMs) in the future. For those who haven’t heard of it, Docker is a more efficient alternative to using VMs. In a nutshell, Docker’s service layer runs over the host OS and creates isolated containers that include the app under development and all of its dependencies. VMs, on the other hand, don’t share the same OS instance. For example, two apps placed in two separate Docker containers will run on the same host OS. Conversely, two apps placed in two separate VMs will run on two different OS instances — and will therefore consume more resources. (I have recently written an article about how to use Vagrant to set up microservice-based projects hosted in separate repos, where I claim that Docker can be a better solution, if all your dev workstations are Linux machines).
I would attend this talk because, as developers, we should all be aware of the importance of improving our development environment: making it portable, easy to configure across the team, and should help stop, once and for all, the reaction of blaming the machine when we cannot reproduce an error. Also, I would like to see how Docker and Ruby fit with each other.
Docker’s gotten a lot of press, but how does it fare in the real world Rubyists inhabit every day?
Together we’ll take a deep dive into how a real company transformed itself to run on Docker. We’ll see how to build and maintain Docker images tailored for Ruby. We’ll dig into proper configuration and deployment options for containerized applications. Along the way we’ll highlight the pitfalls, bugs and gotchas that come with such a young, fast moving platform like Docker.
Whether you’re in production with Docker or just dabbling, come learn how Docker and Ruby make an awesome combination.
Related talk: How We Deploy Shopify
Talk #2 – Going Serverless
AWS Lambda allows developers to upload and run their code on a high-availability AWS infrastructure. It also takes care of managing and maintaining the server and operative system, scaling, memory balance, monitoring, logging, etc.
Serverless, on the other hand, “is the application framework for building web, mobile and IoT applications exclusively on Amazon Web Services’ Lambda and API Gateway.” (see Serverless repo on GitHub).
AWS Lambda only supports Node.js, Java and Python, so I’m a little bit curious, in a good way, about what this talk has to do with Rails. Moreover, the topic sounds interesting, useful and I always try to keep an eye open for new languages, frameworks and technologies in general.
Serverless is a new framework that allows developers to easily harness AWS Lambda and Api Gateway to build and deploy full fledged API services without needing to deal with any ops level overhead or paying for servers when they’re not in use. It’s kinda like Heroku on-demand for single functions.
Talk #3 – Inside ActiveJob
At one point, every large and complex system requires some background job processing. Introduced in Rails 4.2, ActiveJob provides an abstraction layer to create and put jobs into background, interfacing with libraries like Sidekiq or Resque.
The speaker promises to teach us how ActiveJob works internally, through building an asynchronous job processor from scratch, as a didactic approach.
ActiveJob made a huge impact when it landed Rails 4.2. Most job processors support it and many developers use it. But few ever need to dig into the internals. How exactly does ActiveJob allow us to execute performant, thread-safe, asynchronous jobs in a language not known for concurrency? This talk will answer that question. We’ll build our own asynchronous job processor from scratch and along the way we’ll take a deep dive into queues, job serialization, scheduled tasks, and Ruby’s memory model.
Action Cable extends Rails functionality with “real time” messaging through WebSockets.
RealTime updates using WebSockets are so-hot-right-now, and Rails 5 introduces ActionCable to let the server talk to the browser. Usually, this is shown as a Chat application — but very few services actually use chats.
Instead, Rails Apps want to be able to update pages with new inventory information, additional products, progress bars, and the rare notification. How can we make this happen in the real world? How can we handle this for unauthenticated users? How can we deploy this?
Let’s face it. This is me, every time I deal with an error involving the asset pipeline:
Needless to say, expectations for this talk are high.
“WTF asset pipeline?”
“What are all these errors?”
“Why is my app running so slow?”
If you’re new to Rails development, or just want some tips on deploying and running in production, this is the talk for you. Relying on real-world experience as part of the Heroku support team, we’ll talk through common issues (and a few funny ones) we see when people take their “but it works in development!” app to a production environment.
Talk #6 – The State of Web Security
A couple of years ago, Najaf Ali gave an insightful speech about how to improve security in Rails apps, where he stated that, generally speaking, we all as developers, suck profoundly at security.
In his own words:
We suck so hard at security, that there’s a whole thriving industry (i.e. InfoSec) whose sole purpose is to document all the ways in which we suck at security.
Among his various recommendations, the one that really stuck out, for me, was (quote):
The only way to defend against attacks is to understand them in as much technical depth as possible.
Since then, I have always tried to find some time for at least one talk about security trends — if there is one — when I go to tech conferences.
Join me for a wild ride through the dizzying highs and terrifying lows of web security in 2015. Take a look at some major breaches of the year, from Top Secret clearances, to medical records, all the way to free beer.
We’ll look at how attack trends have changed over the past year and new ways websites are being compromised. We’ve pulled together data from all the sites we protect to show you insights on types and patterns of attacks, and sophistication and origin of the attackers.
After the bad, we’ll look at the good – new technologies like U2F and RASP that are helping secure the web.
Talk #7 – Secrets of Testing Rails 5 apps
Rails 5 comes with a test runner out of the box, taking ideas from RSpec, Minitest and others. This new feature reduces running time and improves the output legibility.
This talk promises to allow us to catch up with the new
Testing Rails 5 apps has become a better experience out of the box. Rails has also become smarter by introducing the test runner. Now we can’t complain about not being able to run a single test or not getting coloured output. A lot of effort has gone into making tests — especially integration tests — run faster.
Come and join me as we commence the journey to uncover the secrets of testing Rails 5 apps.
Related talk: RSpec and Rails 5
Talk #8 – Rails 5 Features You Haven’t Heard About
We need to understand the tools we use. We never know when we are going to wind up using that small gem or hidden framework feature we heard about once in a meetup or a conference.
I wouldn’t miss this talk about several of Rails 5’s minor, not very well-known, features.
We’ve all heard about Action Cable, Turbolinks 5, and Rails::API. But Rails 5 was almost a thousand commits! They included dozens of minor features, many of which will be huge quality of life improvements even if you aren’t using WebSockets or Turbolinks.
This will be a deep look at several of the “minor” features of Rails 5. You won’t just learn about the features, but you’ll learn about why they were added, the reasoning behind them, and the difficulties of adding them from someone directly involved in many of them.
Elixir. I don’t know if it’s gonna pay my bills in the future, but I’m learning it. And I’m loving it.
Also, it is impressive to see how fast, and inconspicuously, Elixir has slid into Ruby conferences. Even Matz said that Ruby 3, currently under development, has sought some inspiration from the way that Erlang/Elixir solves concurrency.
This talk compares Rails ORM’s ActiveRecord with Ecto, its equivalent in Phoenix — Elixir’s framework, inspired by Rails.
I’m currently learning Elixir, and the fact that it is apparently quickly escalating, makes me want to keep an eye on it.
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.
Related talk: Rails to Phoenix
Talk #10 – Multi-table Full Text Search with Postgres
The last talk in the list is related to full text search. Some projects involve text searching across multiple entities. For example, I’m currently working on a web app that allows users to search text across titles and descriptions of Promotions, Products and Categories.
Depending on several factors, including the number of rows to be searched, the size and type of text columns, the number of tables and other efficiency related constraints, we may end up using Lucene, or Elasticsearch, or opt for less sophisticated solutions, like using SQL on your own database.
If we opt for the latter, we generally want to tune and optimize our queries — and that’s what this talk seems to be all about.
Searching content across multiple database tables and columns doesn’t have to suck. Thanks to Postgres, rolling your own search isn’t difficult.
Following an actual feature evolution I worked on for a client, we will start with a search feature that queries a single column with LIKE and build up to a SQL-heavy solution for finding results across multiple columns and tables using database views.
We will look at optimizing the query time and why this could be a better solution over introducing extra dependencies which clutter your code and need to be stubbed in tests.
Talk #10.5 – Excellence Through Diversity
I excluded this talk from the list above, because I know the speaker well and he works a few feet away from me, so I guess I’m probably biased. However, if you read up to here — and, by the way, THANK YOU, for that! — I must sound fairly convincing and must have gained your trust.
What I would say is that I’ve seen the talk being rehearsed here, at Moove-it. The topic is totally relevant, making you stop and think about this, so-called, “normal” social construct.
Great individuals often outperform their peers, and when going through school and applying for jobs this seems to be the most important aspect. But who is really outperforming whom? Also, what are we using to measure people? How do you know you’re being fair? Hiring is such a subjective topic and of utmost importance when building a team.
Let’s explore how our strengths and weaknesses affect ourselves and the team and, how we need to look past ourselves when building a team.
I hope this list helps you organize your time during the conference. Please feel free to chime in and recommend your own options. If you ever want to reach out during the event, our colleagues will be around the Moove-it booth.
Have a great conf!