Sessions
Often, the endeavors of hiring and mentoring junior engineers and of bolstering diversity and inclusion efforts are seen as “nice to haves” at best and “extraneous” (or even “impossible”!) at worst. But in reality, building diversity and inclusivity and fostering the ability to incorporate junior engineers go hand-in-hand. Engineering teams should approach each of these efforts in service of the other.
Together, we'll articulate the value of investing in mentorship efforts in terms of their impact on the ability to attract and retain diversity. You will walk away with a clearer understanding of the connection between the two efforts, and ideas for incorporating mentorship and D&I processes at your place of work.
Background processing is a critical component of many applications. The serverless programming model offers an alternative to traditional job systems that can reduce overhead while increasing productivity and happiness. We'll look at some typical background processing scenarios and see how to modify them to run as serverless functions. You'll see the advantages and trade-offs, as well as some situations in which you might not want to go serverless. We'll also talk about the serverless ecosystem, and you'll walk away with the knowledge and tools you need to experiment on your own.
Small-dollar donations were critical in the last election. The first version of the software that powers ActBlue, the main player in the space, was written in Rails 0.10.
During 13 years, 30K organizations have used the platform to raise $3 billion.
Some lessons we'll be sharing on this presentation: how to scale a monolith to process 1.5M RPM and 250 payments/sec, how to be productive with a 110K line code base, how to minimize the pain of Ruby/Rails upgrades and technical debt.
Intended for beginner to intermediate developers, managers, and anyone interested in building a lasting system.
“I try to avoid it” or “just use !important” are things I hear developers say when it comes to CSS. Writing CSS that yields beautiful websites is an art, just as writing well-organized, reusable CSS is a science. In this talk, we’ll mix both art and science to level up your knowledge of CSS. We’ll revisit the basics to build a stronger CSS foundation. Then, we’ll step it up to SCSS, Flex, and pseudo-classes to build more advanced logic. And lastly, we’ll take a peek at what’s coming next with CSS Variables, Grid, and Houdini. By the end of the talk, you’ll be excited to work on CSS again!
JRuby is deployed by hundreds of companies around the world, running Rails and other services at higher speeds and with better scalability than any other runtime. With JRuby you get better utilization of system resources, the performance and tooling of the JVM, and a massive collection of libraries to add to your toolbox, all without leaving Ruby behind.
In this talk, we'll walk you through the early stages of using JRuby, whether for a new app or a migration from CRuby. We will show how to deploy your JRuby app using various services. We'll cover the basics of troubleshooting performance and configuring your system for concurrency. By the end of this talk, you’ll have the knowledge you need to save money and time by building on JRuby.
What if I told you there is more to a commit message than "-m"? Like source code time capsules, those pesky formalities can deliver wisdom and perspective about any code from the best possible source, the developer who just wrote it! Explore new facets of these time traveling rubber duck opportunities to increase their usefulness tenfold. Tools like templates, linters, hooks, and automation. Hear what Dr. Seuss can teach us about git, and don't miss the most helpful morsel of git customization around... how to open a new message in an editor other than vim!
Rails ships with some handy features, and most of that functionality is there because we have common problems; and those problems need a default solution. You need quick two-way communication between your client and server. Action Cable can solve that quickly, and get you up and productive with out setting up expensive external add-ons and complex integrations.
This magic is wonderful until you need to untangle how websockets, connections, channels, consumers, and clients all fit together. Let's look under the hood and see how everything is woven together.
When was the last time you ran rake db:reset locally?
My guess is not recently. Nor do you think of doing it frequently. And I want to persuade you that deleting your precious local environment this way is a Very Good Thing Indeed.
Because, friends, db:reset will not only delete your database, but it will seed it too.
And by spending quality time with your seeds file, I believe you’ll make your entire development team more productive.
You’ll give your project the opportunity to grow its own shared development environment – a beautiful, idealistic place where all devs can talk through the same problem in the same context.
Ready to reset with me?
Active storage works seamlessly in new rails applications - but how many of us only work on new applications? Migrating to Active Storage can be a daunting task on a production application. This talk will explain active storage, why you might want to use it, how it modifies your database, and the benefits and drawbacks of migrating your existing application. I’ll walk you through my painful journey migrating an existing application. You will leave this talk with a better understanding of the inner workings of active storage and with the confidence to tackle your own migration. This talk is appropriate for all levels of skill and no prior experience or knowledge of active storage is required.
Have you started using Webpacker or are you still doing everything with the asset pipeline? Do you not know what to expect if you start using Webpacker? Do you even need Webpacker? See what it's like to develop and maintain a Rails app with Webpacker or with just the asset pipeline side by side.
Our desire to use new tools and learn new technologies backfires when we don't take the time to fully understand them.
In 2018, we migrated from a REST API to GraphQL. Patterns were introduced, copied, pasted, and one day we woke up with queries taking 6s and page load times > 10s. Customers were complaining. How did we get here?
In this talk, we will discuss why we chose GraphQL, show practical examples of the mistakes we made in our implementation, and demonstrate how we eliminated all N+1 queries.
I'll answer the question, "if I knew then what I know now... Would I stick with a REST API?"
Let's roll up our sleeves and clean up some smelly code. In this session, we'll dig in to Primitive Obsession - what happens when our domain logic is all wrapped up in primitive data types? And most importantly, how do we untangle it?
Developing apps for users in different demographics is inherently differently than developing apps just for ourselves and for other programmers. Understanding the needs of our users and learning to foster empathy for them is just as much of a skill as learning Rails or ActiveRecord — and it’s a skill that’s relevant to all developers, regardless of their ability level or rung of the career ladder.
Everything fails at some level, in some way, some of the time. How we deal with those failures can ruin our day, or help us learn and grow. Together we will explore some tools and techniques for dealing with failure in our software graciously. Together we'll gain insights on how to get visibility into failures, how to assess severity, how to prioritize action, and hear a few stories on some unusual failure scenarios and how they were dealt with.
You may have heard the terms "Microservices" and "Service-Oriented Architecture" in the past, but you've tried to understand them by googling and asking people and that only resulted in either an incomplete picture of how it works or, more likely, a bunch of wildly varied and even conflicting information. Or maybe you do understand them, but getting from your Rails monolith to that structure is a fuzzy path at best.
During this presentation, you will learn the basics of these ideas, the problems they solve, the tradeoffs they impose, and some ways to migrate to them.
Modern life depends on cryptography. Did you get cash from an ATM this week? Buy something online? Or pick up a prescription? A cryptographic algorithm was needed to make it happen!
Increasingly, developers need to become familiar with the essentials of encryption. But MD5, bcrypt, DES, AES, SSL, digital signatures, public keys - what are they for, and why do we care?
Armed with only a vanilla Rails application and beginner-level Ruby code, this talk will demonstrate the key ideas in modern cryptography. We will also take a peek ahead to quantum computing and its implications on cryptography.
While most of Rails has evolved over time, the view layer hasn’t changed much. At GitHub, we are incorporating the lessons of the last decade into a new paradigm: components. This approach has enabled us to leverage traditional object-oriented techniques to test our views in isolation, avoid side-effects, refactor with confidence, and perhaps most importantly, make our views first-class citizens in Rails.
You've spent a lot of time preparing for this moment. Your palms are sweaty. You take a deep breath, walk into the room, and shake hands with the candidate. Welcome to the interview!
Interviewing can be intimidating and our industry is notorious for interviews that are arbitrary, academic, and adversarial. How can we do better?
Come be a fly on the wall for a real interview! At thoughtbot, we've put a lot of thought into crafting an interview that is both humane and allows us to accurately capture a candidate's strengths and weaknesses relative to the real-life work they will be doing.
Progressive Web Apps are a constellation of conventions. Those conventions fit neatly into Rails, without the need to introduce a complicated Javascript front end. By embracing core Rails technologies like ActiveJob, ActionCable, Russian Doll Caching, and sprinkles of Stimulus, you can deliver powerful and immersive front end web apps.
Do you measure and monitor your Rails applications by alerting on metrics like CPU, memory usage, and request latency? Do you get large numbers of false positives, and wish you had fewer useless messages cluttering up your inbox? What if there were a better way to monitor your Rails applications that resulted in far more signal — and much less noise?
In this talk, we'll share an approach that's effective at measuring and monitoring distributed applications and systems. Through the application of a few simple core principles and a little bit of mathematical elbow grease, firms we've tried this with have seen significant results. By the end, you'll have the tools to ensure your applications will be healthier, more observable, and a lot less work to monitor.
Often in Rails apps there is a need to accomplish tasks where we are less interested in modeling domain concepts as collections of related objects and more interested in transforming or aggregating data. Instead of forcing object oriented design into a role that it wasn’t intended for, we can lean into ruby’s functional capabilities to create Rails apps with sprinkles of functional code to accomplish these tasks.
Using Ruby at work is great… but sometimes it feels like a job!
This year, I rediscovered the joy of writing Ruby apps for nobody but myself—and you can, too! Solo development is a great way to learn skills, find inspiration, and distill what matters most about software.
Building a real app on your own can be overwhelming, but this talk will make it easier. From development to monitoring, you'll build a toolset you can maintain yourself. You'll learn a few "bad" practices that will make your life easier. You may even find that selfish coding will make you a better team member at work!
With the increasing number of home automation devices, our homes are getting smarter and smarter. How can Ruby help?
Instead of installing separate apps to control my many devices, I wanted to use HomeKit via Siri and the pre-installed Home app on any iOS device, for one unified experience.
This is a talk about how I created the first ever Ruby library for the HomeKit accessory protocol to bridge the gap between different platforms and just some of the exciting possibilities this could unleash.
On the 1st commit, things are getting started. On the 10th commit, the feature is live and users are giving feedback. On the 100th commit, users are delighted to be using the application. But on the 1000th commit, users are unhappy with the responsiveness of the application and the developers are struggling to move at the velocity they once were. Does this sound familiar?
We will go over some of the pieces of technical debt that can accumulate and can cause application performance and development velocity issues, and the strategies Clio uses to keep these kinds of technical debt under control.
A developer's primary responsibility is to ship working code, and by the way, it's also expected to be secure code. The definition of "working" may be quite clear, but the definition of "secure" is often surprisingly hard to pin down. This session will explore a few ways to help you define what application security means in your own context, how to build security testing and resilience into your development processes, and how to have more productive conversations about security topics with product and business owners.
Remote work is just like working in an office - minus the soul-crushing commute. How hard could it be?
Spoiler: it's actually pretty hard.
When I went remote, I was so excited to not pack a lunch that I didn't consider the implications of a quasi-reliable Internet connection or the psychological impact of spending so much time at home.
As it turns out, going remote isn't just trading a highway commute for a hallway one. It requires new skills and a mindset shift. In this talk, you'll learn how to assess your needs as a remote worker and gain a set of tools to help you succeed for the long term.
“There is customer service, and then there is Japanese customer service.” - Tadashi Yanai, CEO, Uniqlo
Americans visiting Japan are often dazzled by the quality of customer service they experience, but usually mistakenly perceive it as a well-executed form of customer service as they understand it from Western culture. The American notion of “the customer is always right,” does not apply in Japan, yet customer dissatisfaction is much less common. We’ll explore why this is, with some entertaining real-life examples, and discover lessons from it that we can apply to our work in the software industry.
We’re generally never officially taught to debug. No one tells us at bootcamp or in online tutorials what to do when our code doesn’t work. It’s one of those learn-it-on-the-job sort of things and comes with experience. As early-career developers, we get a lot of syntax thrown at us when we’re first learning, but in actuality, the majority of our time is spent trying to fix broken code. But why should we slog through it alone? Let’s explore some Rails debugging techniques together!
Sometimes your fastest queries can cause the most problems. I will take you beyond the slow query optimization and instead zero in on the performance impacts surrounding the quantity of your datastore hits. Using real world examples dealing with datastores such as Elasticsearch, MySQL, and Redis, I will demonstrate how many fast queries can wreak just as much havoc as a few big slow ones. With each example I will make use of the simple tools available in Ruby and Rails to decrease and eliminate the need for these fast and seemingly innocuous datastore hits.
Event Sourcing provides a full history of actions allowing us to understand how we get got there. Events can be replayed to backfill a new column, to fix a bug or to travel back in time. It is often described as a complex pattern that requires immutable databases, micro services and asynchronous communication.
In this talk, I will introduce you to Event Sourcing and present the simple framework we’ve built at Kickstarter. It runs on our Rails monolith, uses ActiveRecord models and a SQL database. And yet, it gives us super powers.
Have you ever tried MRI's JIT compiler in Ruby 2.6? Unfortunately it had not improved Rails application performance while it achieved a good progress on some other benchmarks.
Beyond the progress at Ruby 2.6, JIT development on Ruby 2.7 will be dedicated to improve performance of real-world applications, especially Ruby on Rails. Come and join this talk to figure out how it's going well and what you should care about when you use it on production.
Rails has been around for (can you imagine!) about 15 years. Most Rails applications are no longer MVPs, but they grew from MVPs and usually contain a lot of legacy code that "just works."
And this legacy makes shipping new features harder and riskier: the new functionality have to co-exist with the code written years ago, and who knows what will blow up next?
I've been working on legacy codebases for the last few years, and I found turning legacy code into a legendary code to be a very exciting and challenging process.
I want to share the ideas and techniques I apply to make legacy codebases habitable and to prepare a breeding ground for the new features.
How can we build communities that learn together? I owe my career to learning, starting from when I signed up for a bootcamp and plunged headfirst into Rails. I did not learn alone--I was surrounded by a group of people who came together around a set of educational goals.
After three years of working on software teams, I find myself intrigued by questions that take me back to my undergrad studies in the social sciences. In this talk I will weave together my personal experience in tech with social science research to start a conversation about creating inclusive, knowledge-sharing communities.
In this talk we'll introduce Zeitwerk, the new code loader for gems and apps that is going to be the default in Rails 6.
We'll cover what motivated me to work on it, which are the issues in Rails autoloading and why is it fundamentally limited, usage by gems, and interesting aspects of the implementation.
In microservices architecture, it is often challenging to understand interaction and dependencies between individual components involved in an end-user request. Distributed tracing is a technique to improve observability of such microservices behaviors and to help understand performance bottlenecks, to investigate cascaded failures, or in general, to troubleshoot.
In this talk, I will show how we’ve implemented distributed tracing in Rails apps using OpenCensus, a set of vendor-neutral libraries to collect and export metrics and traces, and real world examples from our system that consists of about 100 microservices built with Ruby, Go, Python, Node and Rust. I will also discuss other methodologies to improve “observability” of Rails apps in microservices and future direction.
If you feel pain in troubleshooting microservices of Rails, you’ll love distributed tracing.
During our Application Security deep dive we'll evaluate what application security is, and how to perform a security review on a Rails application. The application has common libraries and programming patterns we are familiar with as Rails engineers. In the security review, we'll explore what can go wrong and how we can fix it. Most importantly, we'll learn a few security mental models to help us discover security problems.
ActiveRecord is big. You just won't believe how vastly, hugely, mind-bogglingly big it is. It does a lot. Many would say it does too much. For me, the biggest issue is that it combines 2 distinct pieces of functionality — modeling the domain, and abstracting database access.
For years, I've dreamed of separating these 2, while still staying on Rails' golden path. I finally found a way to do that. The benefits are high: faster tests, simpler code, decoupling from the database, automatic schema migrations — without much downside. Let's take a look and see if it might be for you and your project.
Your app is slow. It does not spark joy. In this talk, we will use memory allocation profiling tools to discover performance hotspots, even when they're coming from inside a library. We will use this technique with a real-world application to identify a piece of optimizable code in Active Record that ultimately leads to a patch with a substantial impact on page speed.
Your phone wakes you up in the middle of the night. Your app is down and you're on call to fix it. Eventually you track it down to "something with the db," but what's wrong exactly? And of course, you're sure that nothing changed recently…
Knowing what to fix, and even where to start looking, is a skill that takes a while to develop. Especially since Postgres normally works very well most of the time, not giving you get practice!
In this talk, you'll learn not only the common failure cases and how to fix them, but also how to quickly figuring out what's wrong in the first place.
As engineers, we've spent years mastering the art of conducting technical interviews—or have we? Despite being on both sides of the table dozens of times, how often have we come away feeling that the interview didn't work as well as it could have? How many of our interviews have been just plain bad? How much time do we spend designing and improving our own interview processes, and what signals should we be looking for when it comes to making those improvements? In this talk, we'll examine the technical interview in depth, developing a framework for interviewing candidates "where they are" by focusing on answering two major questions: how can we ensure our interview process identifies the people and skillsets we need to grow our teams, and how can we interview candidates in an inclusive way that maximizes their ability to demonstrate their competencies? By the end, we'll have built out a rich new set of tools you can immediately apply to the hiring process in your own organization.
Trans and non-binary people are becoming increasingly visible in the workplace, as well as in community spaces such as meetups and conferences. Most managers and event organizers want to be inclusive and welcoming but frequently, in spite of their best intentions, often come up short. Wouldn’t it be nice to have an actual non-binary trans person just tell you what you should be doing and why? VOILA! Allow me to swoop in and fix your interview process, your community event, even your office space! Can you believe? Shamazing!
By entering the danger, you become the change the world needs. Do you know how to foster a culture of psychological safety? What are you doing to be inclusive for folks who identify as trans or gender non-conforming? What about people with a disability? Or women of color?
It’s well-known that our industry has poor racial and gender representation, yet we need more action from that awareness. This talk is about leaning in, being an ally, and making an impact. It takes courage to be a champion of diversity, equity, and inclusion.
On August 15, 2018 GitHub was deployed to production running Rails 5.2. This was a historic event; for years GitHub had been behind Rails and dependent on a custom fork of Rails 2.3. This talk will visit GitHub's past, including our tumultuous relationship with the Rails framework, and the grueling effort it took to get our application on the latest version. You’ll learn what mistakes to avoid and the reasons why such a difficult upgrade was worth it. We’ll explore what tracking master means for the future and establish that GitHub and Rails are in it together for the long haul.
This talk describes how our team made deep changes to the data model of our production system over a period of 2.5 years.
Changing your data model is hard. Taking care of existing data requires caution. Exploring and testing possible solutions can be slow. Your new data model may require data completeness or correctness that hasn't been enforced for the existing data.
To manage the risk and minimize disruption to the product roadmap, we broke the effort into four stages, each with its own distinct challenges. I'll describe our rationale, process ... and the lessons we learned along the way.
Your site was built for your external customers first. Data or workflow problems are solved on the Rails console.
But, two years in, your app has grown. Identifying, researching, and fixing those data and workflow problems takes more of your time and attention. It frustrates your business stakeholders, your customers and, of course, you.
This talk will look at a Rails-based web store–including inventory, payment processing, fraud mitigation and customer notifications–and explore how we can build tools into our apps to discover when things go sideways and then help get things back on track.
Rails’ migrations were a revelation when Rails came out, as it provided a way to manage your database schema, but also included many wonderful defaults that made all Rails developers pretty good at database schema design! But these defaults are just the beginning. Properly modeling your database can bring many benefits, such as fewer bugs, more reliable insights about your users or business, and developer understanding. We’ll talk about what makes a good database design by understanding the concept of normalization and why a properly normalized database yields benefits.
If you have ever worked in a Rails applications that needs to be available in more than one language you probably know how hard to maintain it can become over time, specially if more than one developer is involved in the process.
If you have never worked with localizations you probably will at some point in the future.
I want to share with you my experience. As a Spanish speaking developer I have worked in many multi-language apps, I have advice and a list of good practices that can help you in future localized projects.
If you’re a junior developer who’s ever wondered if joining tech was a terrible idea, this is the talk for you!
I was equally exhilarated and terrified to start my first job in tech. The road to success is often zigzaggy, and my view as to whether it was worth it - and whether I would make it - varied from one day to the next. Four years later, those fears have been dispelled, as have several key misconceptions I had about tech (and being a programmer). In this talk, we’ll explore them together (plus a few badass Rails tricks to help you level up).
Many developers fail to reach their productivity not due to lack of technical ability but for lack of mental organization and discipline. It's extremely helpful to always hold in one's mind the answer to the question: "What exactly am I trying to achieve at this particular moment?" It may sound like a no-brainer. However, many developers often can't answer this question. Here's how you can make sure that you always can.
You can use a hammer to drive a screw into wood, but I’d recommend a screwdriver. Why? And when is a hammer the better option? This talk will propose a framework to use when comparing alternative technical choices. I won’t decide for you, but will leave you with a structure to apply in your decision-making process.
The ruby toolbox is vast. While Rails provides a default experience, it leaves plenty of room for alternatives. In learning how to do something, you may uncover different ways to accomplish the same goal. Determine which tool fits best in your situation with these lessons.
When you're dealing with fifty million records, simple migrations can become very dangerous. Come and learn from my mistakes instead of making your own. We'll talk about what's going on behind the scenes in your database, and how to safely write and run some common migrations. Remember, uptime begins at $HOME.
You know your Rails application is slow. Customers are complaining, and your ops teams are provisioning even more servers but it just isn't helping. What now? In order to fix a performance problem, you have to be able to measure it and diagnose where it is. Profiling and benchmarking are our two tools for doing just that. In this talk, you'll get an introduction to the tools available for benchmarking Ruby code, and how to use a profiler to figure out where your program spends its time.
Every test suite has them: a few tests that usually pass but sometimes mysteriously fail when run on the same code. Since they can’t be reliably replicated, they can be tough to fix. The good news is there’s a set of usual suspects that cause them: test order, async code, time, sorting and randomness. While walking through examples of each type, I’ll show you methods for identifying a culprit that range from capturing screenshots to traveling through time. You’ll leave with the skills to fix any flaky test fast, and with strategies for monitoring and improving your test suite's reliability overall.
With at least $55 billion in open source-related acquisitions in 2018, you might think we finally figured out how to fund and monetize open source software. Unfortunately, we have only reached an awkward stage of growing pains! With conflicting goals, people are struggling to turn their OSS work into revenue while not losing the powerful open source effects which made the software successful in the first place.
From the perspective of someone who has gone through the pain of commercializing open source, let’s take a deeper look at the unexpected challenges and potential solutions.
About a year ago, I started to maintain Devise - one of the most popular Ruby Gems available. I had no knowledge of the code and a little experience with open source from a side project I developed myself.
Obviously, this was a very challenging task and I made a lot of mistakes in the process. The good thing is I learned a lot too.
In this talk, I will share with you some of the lessons I learned that I think can be valuable not only for open source but for our day-to-day work too.
RSpec Rails is RSpec's wrapper around Rails' testing infrastructure. The current stable version, 3.8, supports Rails >= 3.0, and Ruby >= 1.8.7, that's a lot of versions to support! With RSpec Rails 4, we're fundamentally changing how RSpec is versioned.
In this talk you'll see a pragmatic comparison of ways to version open source. You'll see how we ended up with RSpec's new strategy. You'll learn what's coming next : Rails 6.0 parallel testing and ActionCable tests. This talk focuses heavily on open source process, and is less technical, so should be accessible to folks of all levels.
“Life is pain, highness. Anyone who says differently is selling something.” - The Dread Pirate Roberts
Are you dreading an email from work while you’re at this conference? Ruminating over last week’s outage? Worried you’re not learning enough because you can’t stay focused on the talks?
These are three kinds of suffering we all experience at work: uncertainty, failure, and insufficiency. All three are an inevitable part of our work. But more than that: they are necessary. Join me to learn some ways to approach suffering that can make you happier, healthier, and even a better developer.
When external expectations build into burnout, it can feel like the only two choices are soulcrushing grind or fleeing from the pain. But what do you do when you return from your coffee break, your lunchtime meditation break, or your relaxing vacation -- and the dread and toil begin to destroy you again?
Sometimes taking a break or stepping back is enough to reset to a sustainable state. And sometimes it’s not.
Let’s talk about how to tell the difference, and what your options are when you can no longer bubblebath the burnout away.
In recent years, mindfulness and meditation have both become capital-B Buzzwords. It’s hard to read anything about mental health or “wellness” without a mention, and meditation apps and services are a dime a dozen. Are you curious what they mean?… but also not really sure if they’re for you, or worried they’re for hippies or otherwise, y’know, not actually real?
Trust me, I wondered the same thing. In this talk, we’ll go over what mindfulness and meditation can be: effective tools to help observe the emotional reactions and thought patterns that rule our day - and our interactions with other humans - without us even realizing it. We’ll cover the basics in an objective, non-judgmental way, you’ll finally figure out what mindfulness and meditation are, and you’ll come away with resources to start becoming more mindful in your own life.
Even with the simplest of problems, we can get stuck on code. It happens to engineers of all experience levels. This session will show you many strategies for getting unstuck.
We'll start by reframing the act of getting stuck as a positive. Then we'll talk about many strategies for identifying the problem and moving on. We'll discuss the psychology behind these strategies, and answer questions like "Why do my best ideas come to me in the shower?" Finally, we'll look at ways to harden yourself for the next time you get stuck.
Getting unstuck is a skill. This session will help you sharpen that skill, and prepare you for the next time you want to throw your keyboard out a window.
This is a sponsored talk by Weedmaps.
Every April, we observe Earth Day and celebrate our planet’s beauty and resources, its oceans and trees. But only days earlier, another kind of tree is celebrated, and Weedmaps experiences its highest traffic of the year. Come see techniques we’ve used recently to lighten the latency on our most requested routes ahead of the elevated demand. Do you cache your API responses but want a lift in your hit ratio? Does that Elasticsearch best practice you know you’re ignoring cause nerves? We’ll pass our solutions to these problems — on the left-hand side.
This is a sponsored talk by Heroku.
Rails 6 has officially added Multiple database support, and the options are overwhelming. We're here to help you make the right architecture decisions for your app. In this talk, we will look at performance gains and pitfalls to some common patterns including: separation of concerns, high-load tables, and data segmentation. We'll talk about read replicas, eventual consistency, and real-time (or near real-time) requirements for a Rails application using multiple Postgres databases.
This is a sponsored talk by Shopify.
At Shopify we ship code. A lot of it. 1000 PRs a day. This means that our security team can’t reasonably take a look at every change that goes out to Shopify’s core product, let alone the hundreds of other projects deploying every day. Our team has developed some awesome tools and techniques for keeping Rails safe at scale, and we’d like to share them with you.
This is a sponsored talk by Checkr.
Checkr’s mission is to build a fairer future by improving understanding of the past. We are based in San Francisco and Denver. We have found some limitations in only using JSON-based RESTful APIs to communicate between services. Moving to gRPC has allowed us to better document interfaces and enforce stronger boundaries between services. In this session we will share the lessons we have learned while incorporating gRPC into our application, walkthrough setting up a new rails project with gRPC support, and how we plan to expand our usage of gRPC in the future.
This is a sponsored talk by Citus Data.
I’m a Postgres person. Period. After talking to many Rails developers about their application performance, I realized many performance issues can be solved by understanding your database a bit better. So I thought I’d share the statistics Postgres captures for you and how you can use them to find slow queries, un-used indexes, or tables which are not getting vacuumed correctly. This talk will cover Postgres tools and tips for the above, including pgstatstatements, useful catalog tables, and recently added Postgres features such as CREATE STATISTICS.
This is a sponsored talk by Square.
Active Model is flexible enough to provide a model interface to APIs, not just databases! We’ll look at how to go beyond just including ActiveModel::Model to implement a rich set of Active Model features, including the recently-added Rails 5 Attributes API. How does this compare to Active Resource? What does it look like in your controller? We’ll answer these questions by exploring an example that wraps Square’s Customers API in a full-featured Rails model.
This is a sponsored talk by Skylight.
This breathtaking documentary series combines rare action, unimaginable scale, impossible locations and intimate moments captured from the depths of Rails' deepest internals. Together we will follow the lives of Rails' best loved, wildest and most elusive components. From the towering peaks of Rack to the lush green of Action Dispatch and the dry-sculpted crescents of Action Controller, our world is truly spectacular. Join the Skylight team on this incredible Journey to unearth the lifecycle of a Rails request.
This is a sponsored talk by Procore.
Have you ever gotten a bug report that is hard to believe and seemingly impossible to reproduce? Fixing these type of bugs can be draining, but often improves your understanding of the system. Come and learn the nuts and bolts of writing a good regression test that exposes the bug at the right level of abstraction. We will pay close attention to the structure of our code after the bug fix. Through incremental changes, we will drive improvement. I’ll show you how you can have code that is simpler to understand, follows project conventions, and is easier to test.
Is it a method? A database column? Over here, it's a field in a form. Over there, it's a parameter in a request. It's the thing we decorate in our views. It's the thing we filter in our controllers.
We call it an “attribute”, and it's all these things and more. We take it for granted, but this innocent little idea is a window into the beating heart of our web framework. Behind its magic are valuable lessons to be learned.
Join me as we delve beneath the surface of ActiveModel and ActiveRecord, to the complex abstractions that make attributes so powerful, and so elusive.
Raised exceptions in Rails 6 can hint the error pages to display a button that can invoke a resolving action. We call them actionable errors!
In this talk, we'll take a deep dive into what actionable errors are, and how they are dispatched through the Rails application errors handling mechanism.
We'll also write a small Rails plugin and use actionable errors to guide our users with better errors, and actions to resolve them. We'll learn how to define custom actionable errors and strategies around when and how to raise them to help our users to set up the plugin from the comfort of the error pages.
Have you ever wondered how something works deep in the guts of Rails or been stuck when a README says one thing but the code acts another way? Guides and docs are often the best way to get started but when they fall short, you may need to get your hands dirty.
Using method introspection, this talk will show you ways to confidently explore Rails code. By looking at common problems inspired by real-world situations, learn how to dive into Rails and teach yourself how any feature works under-the-hood.
Let’s go spelunking!
Do you want to know what ActionCable is and how it works, but don't want to build another chat application to learn it? Well buckle up, because we've got a treat for you. You're going to learn with lemurs and classical music.
The ActionCable Symphony is an illustrated and musical talk that will explore how websockets work by using classical music. We'll be using select audience member phones to play it. Learn about ActionCable, websockets, latency concerns, client interfaces, JWT authentication, and more in this once-in-a-lifetime experience.
You haven't lived until you've experienced lemurs playing a symphony orchestra on your phone using Rails.
Ruby is historically difficult to optimize due to features that improve flexibility and productivity at the cost of performance. Techniques like Ruby's new JIT compiler and deoptimization code help, but still are limited by techniques like monkey-patching and binding inspection.
Pre-evaluation is another optimization technique that works based on user-defined contracts and assumptions. Users can opt in to optimizations by limiting their use of Ruby's features and thereby allowing further compiler work.
In this talk we'll look at how pre-evaluation works, and what benefits it enables.
Kent Beck (TDD, eXtreme Programming, Agile Manifesto) has a couple new ideas. They both sound so terrible and impossible that they just might be totally amazing.
1. test && commit || revert If tests pass, commit everything. If they fail, revert everything. Automatically. Wild.
2. LIMBO. Anything that's committed is pushed. Anything that's committed by teammates is automatically pulled in while you work. So wild.
Does this work? Does it scale? Will I always be losing important progress because of a typo? Will this make me a better / faster / happier programmer?
We'll cover tools, process, deficiencies, mental models, and experiences. Show up and see what happens.
Have you ever caught yourself dictating code to a junior dev, rather than pairing? Or resorted to saying “best practice” because you knew you were right, but couldn’t articulate why? We can solve both these problems with “dialogic teaching,” a cornerstone of modern adult-education theory. In this talk, you’ll learn how to go from monologue to dialogue. You’ll learn how to teach developers of all skill levels in ways that center their goals and let you learn from them too. You’ll learn how to practice technical leadership when you’re right – and how to practice it when you’re wrong.
Empathy is the ability to understand and share the feelings of others. As developers, empathy for our users, our coworkers, and members of our community is an undervalued skill, since expressing emotions is often perceived as a weakness. But responding to the emotions of others is critical to working successfully on a team. This talk will frame emotions as neurological programs, with distinct triggers and multiple terminal states. The goal is to help us understand that when we act as fully realized human beings, and treat others the same way, the quality of our software will improve.
This talk explores the benefits of purposefully choosing when to type and when to talk, using remote work as an example that promotes very different communication skills than in-office work. We will examine our default modes of communication (typing vs talking) and what biases they involve and then use that knowledge to talk in a more nuanced way about how to make the most of remote work and how to avoid the well-known pitfalls.
Ugh. Management. Agile was supposed to free us from that, right? Self-organized, cross-functional teams who get stuff done without that old-guard hierarchy. In this fauxtopia, some developers were more equal than others. Can we get the healthy parts back without the Lumberghs?
To bring back healthy engineering management we first must de-mystify and de-stigmatize the concept of management. In this talk we will: * Explore the context of management * Learn the responsibilities of management * Discuss the techniques of management
As a developer, you'll be equipped to understand, empathize with, and influence your boss. As a manager, you'll build a foundation to help you better serve your team.
Society acts as though jerks are incapable of changing their bad behavior, as though somebody called .freeze on them. We devise all kinds of strategies for avoiding or placating them, even at the expense of others' happiness.
What if it didn't have to be that way?
This talk approaches jerks as the mutable objects all people are. If you think you might be a jerk, or if you're looking for a new approach to the jerks in your life, this talk is for you! We'll cover what makes a jerk and what the positive alternative looks like. You'll leave with a set of practical ways to defuse negative urges, hold yourself accountable, and transform your behavior in a variety of situations, such as meetings, disagreements, or when things go wrong.
Our native systems of conversational flow control might work fine for talking face to face, but they start to have problems when put into many of the conversational scenarios that arise as part of working on a modern development team. Other groups have faced similar challenges and come up with ways to facilitate and improve communication. I'm going to focus on a simple system of hand signals used by the Occupy movement who adapted them from the Quakers. These hand signals mitigate a number of problems with group discussions, including problems of communication over a laggy connection, and working with remotees.