I hate to break it to you, guys, but Ruby is almost old enough to drink. What started out as a small community full of fun, silliness, and connection has been growing. Our small codebases are now large. Our small *companies* are now large. And the large companies have finally figured out that they want in, too.
So maybe it's time to start tackling Real Problems and Real Solutions in the world of Real Innovation. Maybe it's time for the community to grow up, stop playing around, and get Serious™.
But…that's not who we are. Our community thrives on creativity, play, and luck. And those things aren't just a weird perk like not having to wear shoes in the office - creativity, play, and luck, when present, actually produce better software. As we grow our projects and our teams and invade the corporate cube farm, there are some things we can lay aside, and there are others we must hold on to as if our very identity depended on them.
Because it does.
Ruby on ales wouldn't be the same without our best friends closing the show.
We'll have their talk description up here soon.
The last few months have been pretty brutal for anyone who depends on Ruby libraries in production. Ruby is really popular now, and that’s exciting! But it also means that we are now square in the crosshairs of security researchers, whether whitehat, blackhat, or some other hat. Only the Ruby and Rails core teams have meaningful experience with vulnerabilites so far. It won’t last. Vulnerabilities are everywhere, and handling security issues responsibly is critical if we want Ruby (and Rubyists) to stay in high demand.
I’ll discuss responsible disclosure as an end-user, as well as repsonsible ownership of your own code. How do you know if a bug is a security issue, and how do you report it without tipping off someone malicious? As a Rubyist, you probably have at least one library of your own. How do you handle security issues without inviting attacks on the old code? Don’t let your site get hacked, or worse yet, let your project allow someone else’s site to get hacked! Learn from the hard-won wisdom of the security community so that we won’t repeat the mistakes of others.
If you've ever done anything in ruby, you've probably used rubygems and to search or install your favorite gem. On October 17, 2012, rubygems.org went down. A Dependency API was built to be used by Bundler 1.1+ to speed up bundle install. Unfortunately, it was a bit too popular and the service caused too much load on the current infrasture. In order to get rubygems.org back up the API had to be disabled. You can watch the post-mortem for details. http://youtu.be/z73uiWKdJhw
Members in the community stepped up and built a compatible Dependency API service called the Bundler API. Working with the rubygems.org team, we were able to bring the API up for everyone within a week. In this talk, I will cover the process we went through of extracting the API out into a separate Sinatra app that now runs on Heroku. I'll go over how the API works and how Bundler itself uses it. Since we don't have direct access to their database, we needed to build a syncing service to keep our local cache up to date. We'll discuss the original sequential implementation of the sync code and how we improved performance through the use of a consumer thread pool. The sync time down was cut from 16 mins to 2-3 mins. Next, we'll talk about the productization steps we took for visibility to make sure the app is performing well.
We're prototyping a replay service, to replay production traffic to different Heroku apps. With this we can compare the performance between the current MRI app in production and the same app running on JRuby. This will also allow us to test any changes/features against real production load. We'll go over how to set this up.
As technology continues to grow at an increasing rate, why is our educational system stuck in a pre-technology age? Why is programming rarely taught even at a High School level? Why do stereotypes of the isolated, nerdy programmer continue to linger, driving away smart, creative people from computer science degrees?
'The Three Rs' of Reading, Writing and Arithmetic have come to stand as the cornerstones of education in this country. We need to step into the 21st century and add a fourth R -- Programming. As a community of programmers and Ruby lovers, we should work to advocate Ruby as the fourth R.
This is not just an education problem. This is also a diversity problem, and even a technological advancement problem. Negative programming stereotypes drive away women and minorities. Difficulty finding programming talent hampers technological innovation and growth. The technology community has stood by for decades waiting for education to catch up -- instead, we need to be the catalyst of change within the system.
I want the flying cars I was promised, and teaching today's children programming from an early age is the fastest path to a Jetsons future.
At the end of 2011, I switched from being a Ruby consultant to being one of the lead maintainers of the biggest OSS Ruby projects. Best part is: I get paid to do it.
During that time, I've learned an awful lot about what it means to be responsible for something as massive as this project. Refactoring the code without causing tears for loyal users has been an extremely interesting problem to have.
I have some rather interesting stories to tell, like the time I renamed most of the files deliberately on purpose, or that time I ripped out a component that people depended on, and everyone was still happy. There's even been times where code has been moved out of the models and into new classes, which seems to be the cool thing to do.
Building services and integrating them into Rails is hard. Often times we talk about how nice it would be if our Rails apps were smaller and we had nicely encapsulated services. And it would be, but services introduce complexity. If you build your application this way from the beginning, you're going to do extra work and probably get some of it wrong. If you wait too long, you've got a mess on your hands.
At Yammer, we work constantly to clean up the mess that worked well in the early days, but has become troublesome to maintain, scale, or handle lots of data. We're tasked with pulling things out of the core Rails app, standing them up on their own, and making sure they do what they do really well and really fast.
With over 20 services now running in production, we've learned some lessons along the way. Services that seem clean and simple in the beginning can turn into development environment nightmares. Temporary data double-dispatching solutions turn into duplication and developer confusion. Monitoring one app turns into monitoring a suite of apps and handling failure between them. This talk is a look into the tradeoffs, mistakes, and solutions that we deal with every day and how we're able to maintain velocity given the additional complexity.
At the end of the day, having services and a smaller Rails codebase makes for scalable development teams, happier engineers, and smoother and more predictable production environments. Getting there is full of tradeoffs and hard decisions -- sometimes we do it right, sometimes we fuck it up, but we usually have a story to tell.
We as rubyists tend to write software that runs on the web, without a deep understanding of what it would take to write the plumbing for that same software. I think it's useful to have a basic understanding of how some of the lower level components of a system work. I'll discuss the basics of systems programming, using Ruby. I'll talk about syscalls and kernel space vs user space. I'll cover a bit about file descriptors and what they're for. And hopefully I'll walk through a small example of a working webserver using those primitive syscalls.
Many of us came to Ruby by way of Rails (including yours truly about six years ago). We came because our current solutions were clumsy and inconvenient. We came because we appreciated the relative simplicity that Rails offered. And we came because we believe that change is often a good thing. But not all changes are beneficial. Over several blog posts, books, and a couple of years, the Rails community has begun to choose complexity over simplicity.
Let's talk about why. And let's talk about how we can try to recapture that simplicity that we so once adored.
It was the summer of 1993. I skipped out on the second game in a baseball double header to go to Lollapalooza with my cool older cousin. It was the first concert of my choosing (previously Hall & Oates, then The Grateful Dead). That day changed the course of my life.
I saw Rage Against the Machine which led to Inside Out which led to Revelation Records which led to Youth of Today, Bold and Gorilla Biscuits. Through those bands I'd learn about straightedge and veganism. I would discover a whole world of diy subcultures.
We made our own zines before there were blogs as a way to communicate across great time and distance. We formed our own bands to perform the soundtrack to our lives and ideals. We organized venues for our bands and friends' bands to play. We booked tours across timezones and oceans to see the world and meet new people.
We built our own networks and economies, in both gifts and exchanges. We created an aesthetic that was ours, a tribal identity. We created systems to record our story. We defined our lives on our terms.
Demo tapes were our Minimum Viable Product. Shows and tours were our meetups. Protests and convergences were our conferences. Cover songs were our permissive licenses. DIY was our flat organization. We didn't ask permission or forgiveness. We built, scammed or stole everything we could.
Punk rock is made of people. Open source is people. That we make music or software is just an artifact of the ideals we hold dear. All of these things I did when I was a kid in basements and tour vans, I'm doing again now on the internet and in office buildings.
What I didn't realize then, was that all of that was perfect training for the world of open source software.
Adrift at sea, a GPS device will report your precise latitude and longitude, but if you don't know what those numbers mean, you're just as lost as before. Similarly, there are many tools that offer a wide variety of metrics about your code, but other than making you feel good, what are you supposed to do with this knowledge? Let's answer that question by exploring what the numbers mean, how static code analysis can add value to your development process, and how it can help us chart the unexplored seas of legacy code.
We are fortunate as software developers to spend our lives learning. Our careers require us to keep pace with an industry that innovates like few others and we adapt ourselves to constant change. Given the amount of time we dedicate to learning it is surprising that we don’t make a greater effort to improve our cognitive ability itself. Cognitive function can be improved with some simple techniques that apply broadly in our profession, and it only makes sense that we should expend at least as much effort improving our ability to learn as we do actually learning.
This presentation will offer you some immediately actionable steps to improve your cognitive ability and be more efficient with your programming studies. You’ll learn techniques mnemonists use to memorize random pages of binary digits, how your brain physically changes as you learn something new and how simple changes in your daily routine can have a deep impact on your work.
We spend hours refactoring our code and preparing for roflscale, why not spend some time optimizing our brains?
Computer science was dominated by women until the 1970's. Women like Ada Lovelace and Grace Hopper paved the way for technical professions today. We'll cover the history of women in computing, possible causes of the gender shift, and ideas for how our community can shape the future.
Craft beer is great. Ruby is great. When you can combine the two, you get a product that can only be described as Liquid Awesome. In this session, we will go over the brewing process and show how Ruby can help make better beer using automation, temperature control, and recipe analysis. We will look at a Ruby application created with recipe design and testing in mind, as well as a Ruby-based brewery control system run on a Raspberry Pi.