Coding is "choose your own adventure" and today you're the Hero. In this talk we'll look at the powerful psychological blockers that prevent us from making the meaningful changes. We'll dig into historical experiments to unearth the secret motivators deep in the brain. You'll walk away with positive stories and actionable adivce on: how to persevere, take charge, and save the day. Cape not included.
The focus will be about how to empower yourself to make meaningful change. We will talk about psychological concepts such as learned helplessness and diffusion of responsibility. We will look at psychological experiements for these traits and then work backwards to understand how they encourage us to be passive when it comes to the direction of our codebases, frameworks, and even communities.
- https://en.wikipedia.org/wiki/Diffusion_of_responsibility
- https://en.wikipedia.org/wiki/Learned_helplessness
I will weave these powerful lessons into a narrative around open source changes and contributions. We will talk about setting goals, breaking them down into smaller pieces, and setting milestones.
I was working at a startup that was failing. Everyone in the company knew we were out of money and the product was going to be abandoned. Many in the company resigned themselves to their fate and played Gears of War in the office for 8 hours straight until the company finally died. After seeing how unhappy everyone was, I worked through my own psychological barriers to turn my misfortune into somethign positive. I turned to open source.
Since then I've spent a good amount of time teaching people how to code. I've seen every excuse for not getting started, under the sun. The hard part of programming isn't the computers it's the people. I learned how to help others motivate themselves, first individually then I began writing tools to help people contribute to open source.
I've seen numerous "junior" and "intermediate" developers go from "I'm not good enough for open source" to being regular contributors or even library owners. This talk will not be my story, it will be theirs.
What do you do when a maintainer leaves a project with over 44 million downloads? That is what we had to consider this year when Sprockets lost the developer responsible for more than 70% of the commits. In this talk we will look at recent efforts to revive Sprockets, and make it more maintainable. We will look into how your projects can be structured to avoid burnout and survive a change of maintainers. Let's save Sprockets.
Theme: Archeology, I'll wear an Indiana Jones outfit and scream "IT BELONGS IN A MUSEUM" while talking about Sprockets. Totally serious. Other gems include "Sprockets Why'd it have to be Sprockets?"
We will start off talking about the backstory, how Sprockets and the asset pipeline came to be, and how exactly Josh left the project. We'll then go into how I came to be involved with Sprockets as it's ownership was moved over to Rails. We will then cover several technical features that were implemented including directory aware file caching and source maps. While doing this I'll talk about tips and tricks for getting familiar with a new project. Specifically writing reproducing scripts and then using application debugging techniques to figure out what is happening. I used writing documentation for other's informational purposes and as a checksum to ensure that I actually understood what the project was doing and how. After this we'll look at how we are making sprockets more approachable. I want to change the API to remove or lessen the impact of god objects. I have a strategy for involving multiple developers with ongoing changes so that if one of us leaves there will be fallbacks. I plan to expand the user level documentation to cover all major use cases. Without the capacity of developers to understand how others will use a library it is very hard to get started working on it.
Even though sprockets has a ton of method documentation and tests, it is still incredibly hard to work with. By understanding why, we can fix those problems in Sprockets and help your project avoid the same pitfalls.
Every Rails developer at this confrerence uses Sprockets to manage their asset pipeline. The older ones know that "sprockets is awful" but they don't know why or what to do about it. I want to change that. I am heavily involved with Sprockets. Hard to say more without identifying myself.
Memory is the most critical resource for most Ruby applications. In this talk we'll dig into Ruby's heap dump capacity to debug production memory problems. In this intermediate to advanced talk we'll look at memory tooling for other languages and VMs like V8 and the JVM. If you've attempted to speed up an app and wanted to go deeper, this talk is for you.
We're going to talk about production memory in Ruby apps. We'll look at taking a Ruby heap dump, and what's in it. Then we'll look into using this to debug a specific problem. We will then look into how other languages handle heap dumps. Mostly node and the JVM. We'll compare different their different models and relative merits. Finally we'll conjecture about the future of memory tooling in Ruby and attempt to see the future.
We will talk about other memory related things such as the popular "freeze" patches and how the Ruby 2.3 pragama will affect your app performance.
This will be on the intermediate to advanced side of things. There will be a few direct takeaways, but mostly it is a think piece. The ideal attendee for this is someone who is vaugely aware of how Ruby retains and uses memory. They have already tried doing some performance benchmarking or tuning and are interested in going deeper.
I write a lot about memory. I also maintain a suite of very popular benchmarks for Rails apps. This talk will be very technical, but i'm good at using stories to explain technical concepts. It will still be engaging, interesting, and fun.