The Nazi party members at Nuremberg, J. Robert Oppenheimer at Los Alamos, and developers at exciting tech companies have something in common. The responsibility for what mark we leave on the world through our efforts or inventions rests on our own shoulders. We cannot push this burden to those who tell us what to do, and so we must be conscious about what it is that we're building and how it will be used. The repercussions of our actions come back to us if not legally, then weighing on our conscience.
We all play games. Not video games, but the “games” of communication and power between humans.
Even the most rational of us may be unaware of the drivers of our behaviour and the impact it has on our ability to work well with others.
Find out how an awareness of our state of mind, our biases and the dynamics of human communication can help us to understand each other, ourselves, and build better software.
There is nothing quite like the excitement of leading a team of engineers while your company is in the middle of a growth spurt. Before you know it you start to notice that the work habits that used to work great just don’t seem to be that effective anymore.
In much the way that cooking for two is quite different from cooking for two hundred, building your systems for scale requires a different approach to your work.
In this talk we will explore antipatterns that start to show up during growth and some techniques that you can use to address them.
The talk introduces Rubyplot - the plotting library created for Ruby. It focuses on the general design of a plotting library, its influence from John Hunter's Matplotlib, the design decisions that were influenced by Ruby and provides a perspective of the language from the eyes of a newcomer.
The talk further argues why Ruby should be used for scientific computing and urges Rubyists to contribute to the development of scientific frameworks.
How many different roles are there on engineering teams? Officially, there's probably just a manager and maybe a tech lead. Unofficially, you have technical specialists, company veterans, people focused on tools, and those who think deeply about the product.
In this talk we'll steal the best ideas from operating rooms, wartime deployments, and courtroom litigation. We'll see how it's possible to train, reward, and empower your teammates by respecting their uniqueness while also making room for very junior developers to join fast-moving teams.
Machines are all around us: recommending our TV shows, planning our car trips, and running our day-to-day lives via AI assistants like Siri and Alexa. We know humans should act ethically, but what does that mean when building computer systems? Are machines themselves—autonomous vehicles, neural networks that diagnose cancer, algorithms that identify trends in police data—capable of ethical behavior? In this talk, we'll examine the implications of artificial moral agents and their relationships with the humans who build them through the lens of multiple case studies.
How are you supposed to sing along with your favorite TV theme song every week if it doesn’t have lyrics? At my house, we “meow” along (loudly). We also code, so I built ‘Meowifier’ to convert any song into a cat’s meows. Join me in this exploration of melody analysis APIs and gratuitous cat gifs.
Quick and easy visualization is an important teaching tool and a wonderful way to see your ideas in action. Unfortunately, it is neither quick nor easy for rubyists to get from idea to visualization. You have to have a ton of extra stuff installed. You need to know game mechanics/math. You need to learn a whole other way of programming. It isn't something that is easy for a beginning programmer to pick up. This talk describes an alternative graphics and simulation library with a very clean API making it incredibly easy for newbs and experimenters to go from idea to visual simulation. Pew pew pew!
Congratulations! You’ve launched a RESTful JSON-based API, and now anyone can call your service by making HTTP requests. But is that enough? While HTTP-REST by itself can enable access to your service, an API client library can provide significant benefits in safety, security, readability, and ease of use. In this session, you’ll learn API client design patterns and best practices honed from releasing hundreds of APIs at Google, and you’ll discover tools that can take the tedium out of building, testing, and documenting your API clients for Ruby, and across other languages.
Rubyists are creators. While we’re traditionally tasked with building digital products, our skills can cross into the physical medium too. This talk demonstrates a non-typical way to use code to create products: building a Ruby program that generates dynamic plans for laser-cut physical products (e.g. laptop stands, picture frames, notebooks, etc). With size, fonts and patterns as variables, our app programs a system that allows a user, or a computer, to design an infinite number of variants. Attendees will leave inspired to explore new avenues to use their skills to do what we do best: create.
Have you ever wondered where the perception that technology is a masculine pursuit comes from? Or why we have to explain that, "no really, women are interested in computers too"? At the beginning of the modern technological era, to be a computer was to be an actual literal woman—someone trained in math and computations. Decades later, women are underrepresented in most technical pursuits, with an increasingly “leaky” pipeline leaving fewer and fewer throughout our career progression. Learn about the gendered history of computing and explore how we can write a new narrative of participation.
Are you constantly tapped on the shoulder for answers? Tired of being the Google for your team? Or perhaps you’re the new kid, having to ask a dozen different people to find answers to all your questions? These are the consequences of tribal knowledge. In this talk we’ll discuss how to have a team that self-serves, finds answers on their own, without forcing them to wade through a colossal employee handbook.
Fake news spread six times faster in social media than true stories. As technologists, our industry has built the tools that enable the spread of disinformation across social, the web, and beyond. But fake news is nothing new, it has been a part of each advancement in the technology that powers the spread of information, from the printing press to blogging. What makes fake news so appealing? Is it a tech problem or a human problem? In this talk, I will explain the psychology that makes fake news appealing to our brain, and what technology can learn about this psychology to build better tools.
Come laugh and cry with me as I detail my audacious quest for the world's perfect waffle.
You'll learn valuable life skills like properly assembling a Geiger counter (yes, waffles are radioactive), when and how to use solenoid valves to prevent batterpocalypse, and why you should never, under any circumstances, attempt to modify a self-heating chunk of searing metal in such a way as to make it sentient.
Join me for a whirlwind tour of my most ambitious Ruby hardware project yet. Even if the talk is terrible, you might get a questionably food-grade waffle out of the deal.
We tackle unique business challenges but are solving similar problems, and all too rarely will we talk through our designs and mistakes. Integrations, external APIs, data-stores - these might not be pure code but we can learn a lot from good object design when scaling our systems.
In this talk we’ll discuss how parts of a distributed systems rely on each other, how data flow can couple and propagate failure, and how common emergent patterns can encapsulate services to be resilient.
This is a journey of close calls, errors, and design smells researched into how a service gets simplified.
How can teams invest in and grow their less experienced developers into team-leading senior devs? I believe the first step is empowering them. On my team, we’ve created a process for each team member to lead and own one of our core features. Our early-career developers are learning client management and team leadership skills that they wouldn’t usually get to practice until they stepped into a senior role. In this talk, I’ll share our process and what we’ve learned so you can give your early-career developers valuable experience they need to become successful, senior team members.
We all know that Ruby can give us super powers, but can we use it do something truly magical - write a brand new Harry Potter completely automatically?
It turns out that Ruby and the dark arts of Natural Language Programming are a match made in heaven! Using some basic NLP techniques, a dash of probability, and a few lines of simple Ruby code, we can create a virtual author capable of generating a very convincing Potter pastiche. And if the life of an author’s not for you, don’t worry. In the last part of the talk, we'll explore how we can apply what we've learnt to everyday coding problems.
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 of the patterns for dealing with failure in service-based systems graciously. Whether you're integrating with an external system, building microservices, or designing serverless applications, you will gain insight on how to fail gracefully in both common, and uncommon circumstances.
Your dream mentor is right around the corner, but they don't need to know that! In this talk, you’ll discover how to find and work with the great mentors you deserve. You’ll learn how to extract insights tailored to you and to keep the great advice coming. The best part? You can use these strategies even if you're not in a formal mentorship program. Maybe you don’t even know what you want right now, and that’s ok! You can still receive mentorship to help you identify and grow into the next stage of your career. We don’t have to wait to be chosen--let’s help others help us.
The DC Abortion Fund collects extremely sensitive data about people seeking abortions. That's terrifying for the engineering team, who are responsible for keeping client data safe! We've made a lot of carefully measured ethical decisions about data intake and usage. In this talk we'll examine how we have done data modeling, collection, and scrubbing, and the ethical reasoning and tradeoffs we've made along the way.
As a Ruby developer, you use the command line, but do you take advantage of everything it can do? Join us for a demonstration of command line tools for Ruby developers. Increase productivity with search tools, shell functions, git aliases, tmux shortcuts and rbenv plugins. Want a better pry or irb? Supercharge it with shortcuts, macros and gems. Once you've perfected your setup, push it to GitHub so you can pull it and install it on any computer you want. Whether you're a reluctant minimalist or an experienced power user, you'll discover tools to make you a happier and more productive developer
In this presentation, I will be sharing my experiences running the programming unit for a government department for the over 15 years, using Ruby almost exclusively for the last 13. I will discuss our approach of having developers working directly with stakeholders to determine requirements, how we prioritize requests for new features, how we use Ruby for all types of applications, and our unique web application stack and how it uses defense-in-depth approaches to prevent and contain attacks.
Seattle has two of the longest floating bridges in the world, and in 1990, one of them sank while it was being repurposed. This accident was a classic complex systems failure with a massive PR problem and great documentation. That combination is an excellent frame for talking about incident retrospectives- the good, the bad, the vaguely confusing and unsatisfying. Come for the interesting disaster story, stay to learn about the language of blame and how to ask warm, thoughtful engineering questions.
Have you ever been tempted to subclass a core class like Hash or String? Or have you read blog posts about why you shouldn't do that, but been left confused as to the specifics? As a maintainer of Hashie, a gem that commits this exact sin, I'm here to tell you why you want to reach for other tools instead of the subclass.
In this talk, you'll hear stories from the trenches about what can go wrong when you subclass core classes. We'll dig into Ruby internals and you will leave with a few new tools for tracking down seemingly inexplicable performance issues and bugs in your applications.
Are your post-mortems reactive and unsatisfying?
The common post-mortem traces bad outcomes back to critical decisions so that we make different decisions in the future. But what if those decisions were sound? It tells us to stop making them!
In poker, as in software, variance is real and you can do everything correctly and still lose the hand.
In this talk, we'll talk about real post-mortems and problems with their conclusions. We'll rebalance our thinking to see when we might be learning the wrong lessons. We will learn about poker, taking risks, and a little about life.
When I became a parent, I was completely unprepared for the challenges that awaited me. I reached out to hundreds of fellow parents in tech and learned there are common challenges that simply aren’t spoken about. These focus around one fact that no one wants to admit... parenting is not fun. Parenting is stressful, difficult, and oftentimes incredibly lonely. But being a parent also makes people more organized, focused, and empathetic. We’ll explore these survey results to expose common trends and issues and discuss solutions that show how supporting parents helps all team members thrive.
As developers, our work is mediated through many tools besides languages. We use terminals, browsers, git, and the os. Not to mention editors. These are powerful tools that can be infinitely customized and extended. The tools can make common tasks easier or less error prone to perform. Or they can give you visibility into system behavior. But the options are bewildering and each customization has a cost. It’s time to make your environment work for you. This isn’t just a list of tips and tricks, but will also suggest how to evaluate whether a power tool or shortcut is worth your time.
"Walking into work one day, you see a raccoon in an embroidered vest carefully picking through some dumpsters. Startled, the raccoon shouts, 'Ack! No one is supposed to notice me!' before running away. Dumbfounded, you chase after them only to discover a magical world you never knew was right under your office..."
This talk is a choose-your-own-adventure, where you decide what you want to learn about Ruby's garbage collector!
Get an easy introduction to how garbage collection works, the clever performance optimizations used by Ruby, and even what the future might look like.
In this presentation, we'll cover techniques in Ruby 2.6 that reduce "dead space" memory overhead found in all Ruby programs today. First, we'll cover the compilation process of Ruby programs, instruction optimizations, as well as internal data structures used for running Ruby code. Next, we'll look at how to use this information to maintain liveness of Ruby objects in the code. Finally, we'll take all the information we covered so far to develop a technique for reducing dead space in the heap. Remember to mark your calendar because this presentation will be remembered for generations.
Is your technical interview optimized? Could it use a refactor?
Do you ask candidates questions that could actually influence your production codebase? Or, do you ask them about problems that are solved and standardized? Or worse, contrived and trivial?
Have you ever asked any of these questions:
Find min or max in a list
Implement a sorting algorithm
FizzBuzz (or any contrived algorithm)
“Now can you do it recursively?”
Leverage your production code and commit history to make your next interview more effective in identifying the right hire. All while having more fun.
Who loves getting paged at 3am? No one.
In responding to incidents -- either at 3am or the middle of the day -- we want to feel prepared and practiced in resolving production issues. In this talk, you'll learn how to practice incident response by simulating outages in production. We'll draw from learnings from our simulations at Stitch Fix, like technical implementation strategies, key metrics to watch, and writing runbooks. You'll walk away from this talk with the superhero ability help your team simulate incidents in production.
Be prepared for your next incident!
To many Rubyists just starting out, gems can appear very mysterious. You list them in a Gemfile and run 'bundle install' or install them directly with 'gem install'. Suddenly, your programs gain more functionality than they had before. But what are gems? What makes them work? How can you make your own to share with the world? Let's find out.
Do you want to write the parallel program with Ruby? Ruby 3 will offer new concurrent abstraction: Guild (code name) which enable to run Ruby programs in parallel without difficulties. This presentation will share our current design of Guild and discussions. You can see how to write a parallel program with Guild with prototype implementation.
Often when we think about performance, we see it as "if it takes 20 milliseconds to do X, doing X 10 times will take 200ms". It turns out, there's a lot more to it than that. In this talk, you'll learn about various aspects of performance, circumstances that could make scaling a particular code path non-linear, and even how optimizations can make your app slower.
Your team’s code review practices cause ripple effects far into the future. In this play, see several ways a single code review can go, then fast-forward and rewind to see the effects – on codebase and culture – of different code review approaches.
The setting: an office conference room. The characters: a developer, who’s written a chunk of new Ruby code, and a team lead, who’s about to review it. The code is not great.
See a fast-paced montage of ways things can go. Recognize patterns from your past and present. Learn scripts for phrasing criticism constructively. And laugh.
Meet Red. Red is a reducing lemur, and he loves to sum things using the reduce method. The problem is, with Ruby 2.4+ and the sum method he's starting to think reduce isn't that useful anymore. Distraught, Red asks his master for advice, and she sends him off on a grand journey to learn the true powers of the reduce method by reimplementing various methods from Enumerable.
Join Red on an illustrated adventure through the land of Enumerable as he learns to map, select, find, and more using his trusty reduce.
If you're new to Ruby and Functional Programming, this is the talk for you.
Memory is limited resource of physical devices. Although mruby is smaller than MRI, it’s not small enough for cheap and easily avaiable devices. But there is another frontier: ROM. Many boards has larger Flash ROM than RAM. However, Ruby is too dynamic to put into ROM just as it is. How can we use ROM to implement classes of Ruby, and how small can we make mruby? It’s a thirty-minutes mission to explore strange new worlds.
Prefer composition over inheritance is something you’ve probably heard. You may have even heard more strongly worded arguments against inheritance. This talk will give you the knowledge you need to know whether or not inheritance is a viable solution. While preferring composition is often the right answer, the Ruby language has deep ties into inheritance and we should know it well. If you’re new to Ruby, Object-Oriented programming, or just curious what all the hubbub is about - this talk is aimed at you.
We've all thought "what is this thing supposed to do?" or "why was this done that way" moment when looking through codebases and unless there's documentation or you can find the author, the answer is often hard to find. There are many options to document code from comments to internal wikis, so I'll discuss a heuristic for evaluating the options based on the accessibility (how far away is the answer?) and accuracy (how likely is it that what I'm reading is out of date?) to build a case that the git commit message is likely where you should spend your energy documenting. I'll share my workflow and
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 to decrease and eliminate the need for these fast and seemingly innocuous datastore hits.
Many people believe that ruby applications are inherently slow, yet oftentimes it is the lack of optimization and not the language that is at fault. But how do you even get started with this daunting task of performance optimization? For those that do not have a computer science background, understanding all the different ways of algorithm optimization can sound scary and overwhelming. Some may have a good handle on the theory behind things like the big O notation, but struggle to put it in practice. This talk will focus on a tangible and data driven way to measure and optimize code performance.
Have you tried the JIT compiler included in Ruby 2.6 preview releases? It's easy, just include "--jit" option to a ruby command or set RUBYOPT="--jit" environment variable. You've just learned how to enable it.
But wait, are you sure you can use it? What the hell is going on behind it, why is there a GCC process under your Ruby process, and why can JIT even make your Ruby program even slower? In this talk, you'll be prepared to try the brand-new Ruby's secret power on production from the next Christmas.
Despite best intentions, sometimes you just have to write similar code over and over again. This leads to a massive maintenance burden down the road. But, there’s a better way: have the computer write the code for you.
Code generators are shrouded in mystery and can sound unapproachable, but they aren’t! I’ll show you how code generation is no different than web development and why Ruby has all of the tools to build one quickly. You’ll leave this talk knowing where you could apply code generation in your own code base and how to get started!
Business is slow for Ruby Private Investigator, Deirdre Bug. She’s on the verge of switching industry when she gets a call from an anxious young man. "Some class methods have gone missing," he tells her breathlessly. "I need your help."
Deirdre takes the case and begins exploring Ruby objects behind the scenes. Though she thinks she's on familiar ground — Ruby's object model, method lookup — she's about to discover that she really has no clue.
00:00:16 Michael Hartl
00:01:17 Christen Rittiger
00:02:30 Tori Machen
00:06:42 Jennifer Tran
00:11:33 Jeremy Schuurmans
00:14:13 Kazumi Karbowski
00:18:33 Justin Searls
00:23:27 Jacob Crofts
00:29:20 Roman Kofman
00:34:15 Ariel Caplan
00:38:03 Jamie Gaskins
00:42:14 Aja Hammerly
00:45:47 Isaac Sloan
00:50:45 Zackary Schroder
00:55:49 Junichi Ito
01:00:40 Tom Black
01:05:40 Quinn Stearns
01:09:44 Antoine Lecl
01:13:27 Scott Istvan
This year has been big for JRuby! We're pushing the edges of performance on the JVM and now see large frameworks running much faster than CRuby. This talk will cover the optimizations we've done in 2018 and what impact they're having on performance. We'll go through several features that did not optimize well before the recent work. We'll talk about supporting new Rails versions and how we're working to make Rails apps more reliable, more concurrent, and more scalable. Finally we will discuss what the future holds and how you can get involved.
Think you can't take on a leadership role because you're too junior? Because you're in a remote office? Because you don't have "manager" in your title?
The truth is that all of these blockers (and more) are artificial. How do I know this? Because over the past 6 months, I could answer yes to all three of the questions above. At the same time, I was able to co-lead the engineering effort on one of the most complex parts of our company's product. We'll explore how to bridge the gap between that title you wish you had versus the impact you can actually have.
In one timeline, a quick path to clarity. In the other, a long and painful journey trying to understand the obscure intent of a line of code. The only difference between the two realities? The revision history...
This is a story about writing maintainable software. But rather than the code itself, we’ll see how a well-crafted revision history is as important to maintainability as choosing the right abstraction. We'll explore the differences between a useful history and an unhelpful one. And you'll learn about the practices, tools and techniques that help make the difference.
I used Ruby to cheat at a computer game, and it was so much fun. Come to this talk to hear about a game solver that analyzes a screenshot of the game and calculates the correct answer. We'll chat about dynamic image analysis, perceptual hashes, and the traveling salesman problem. I promise, it's going to be great.
Have you ever asked someone to do something, and they hear the exact opposite?
Why do miscommunications happen? Does knowing why matter? And more importantly, how do you achieve your original desired request?
If you want to learn more ways to influence those around you, this talk is for you! You’ll learn about different causes for failed communications, and different workarounds you can apply for different failure modes. Come to this talk to add another tool to your communications toolbox.
This talk shows how to introduce new syntax-ish stuffs using meta programming techniques and some more Ruby features not known well by many Rubyists. Have fun with magical code!
Show Ruby features to hack Ruby syntax (including Binding, TracePoint, Refinements, etc)
Describe stuffs introduced by these techniques
method modifiers (final, abstract, override)
Table-like syntax for testing DSL
Safe resource allocation/collection (with, defer)
As engineers, most of the software we build is built for a specific purpose. Whether to serve web pages or solve math equations, that purpose makes our code meaningful and easy to comprehend.
But under the hood, it is generic software - software that solves whole classes of problems at once - that powers our applications. Ruby has one of the most vibrant ecosystems of such software, but good luck studying its design principles in any tutorial or coding school.
Instead, join me for a dive into this mysterious, hidden world, and learn to contribute where it counts: at the root of the problem
Congratulations, you've been entrusted to lead a team! But wait... what does that mean? You didn't go to school for this. You may not have even been told what your job exactly is. Some call this new responsibility the "Stone of Triumph".
In this talk, we'll explain leading and managing (and how they're different), outline what success looks like, and show techniques to get there. You'll learn how to build the skills and tools to carry the "Stone of Triumph" with less pain, and set yourself up for a long and happy career leading creative and technical teams.
Want to build a Bot without the hassle of provisioning and managing servers? Amazon’s got a service for that and it’s called AWS Lambda - it executes your code only when needed, scales automatically and you pay only for the compute time you consume.
There’s one problem with Lambda - it doesn’t support Ruby! Let’s checkout multiple options on how to build a Ruby Bot and package it into an executable which you can run on any machine without the need to actually have Ruby installed.
In 1945, the Memex was supposed to be the ultimate personal library. In addition to storing information, users could navigate, organize, link, and share data. But tragically, it was never built.
73 years later, I’m building one in Ruby. I’ve created dozens of importers for different services I use, organized the 10M data points into a graph schema, and used Ruby to tie everything together. Almost all aspects of my life and personal history are now available through an API.
I’ll go over the history of the Memex, how I used Ruby to build my own, and do a demo of what I can do with it.
Isomorphic web programming framework
dRuby implementation on browser
I show you a web- board game demonstration using these gems.
Modern web applications actively use real-time features. Unfortunately, nowadays Ruby is rarely considered as a technology to implement yet another chat – Ruby performance leaves much to be desired when dealing with concurrency and high-loads.
Does this mean that we should betray our favorite language, which brings us happiness, in favor of others?
My answer is NO, and I want to show you, how we can combine the elegance of Ruby with the power of other languages to improve the performance of real-time applications.
When Gustave Eiffel built his namesake tower, it was nearly twice as tall as the tallest structure on Earth. His crews built it in an astounding 22 months, pioneering new construction techniques to deliver it in time for the opening of the 1889 Exposition Universelle. It was amazing then, and it’s just as captivating today.
We all say we want to do groundbreaking work, but what does it actually take to push an organization forward? The answer starts long before the work itself. Let’s see what we can learn from how Gustave Eiffel went about building his record-shattering tower.
Unlike many other languages, Ruby doesn't have great design for documentation. Perl has "perldoc" feature and users easily access documents of modules by "perldoc" command. Python has "docstring" feature and users can access it on REPL. Those are each language's design of importance. The features are not just tool, it contains toolchains and eco-systems. Users of these languages benefit from good documentation design, so library authors write good documentation for them.
I'll talk about new Ruby 3's standard documentation design. It pretty improves your development experience.
Come solve logic games with Ruby, learn about minimax algorithms, and turn a paper into code. There are lots of "solved" problems out there that don't have a good library available -- learn how to write one yourself. We'll take a paper written by Donald Knuth (the "father of analysis of algorithms" and author of "The Art of Computer Science") and use it to solve a game called Mastermind that many people (including me) played as children. We'll look at the game, walk through the paper, turn the prose and math into code, understand minimax algorithms, and never lose at Mastermind again!