Good tests are isolatable, repeatable and deterministic. Good tests don’t touch the network and are flexible when it comes to change. Bad tests are all of the above. Bad tests are no tests at all - which is where I found myself with a 5 year legacy codebase running in production and touching millions of customers with minimal use-case documentation. We’ll cover this experience and several like it while digging into how to go from zero to total test coverage as painlessly as possible. You will learn how to stay sane in the face of insane testing conditions and how to use these tests to deconstruct a monolith app. When life gives you a big ball of mud, write a big ball of tests.
Agile companies need timely and reliable access to data to make critical business decisions. In the enterprise world, this is accomplished with expensive and esoteric data warehousing solutions, while younger organizations make do with generic analytics platforms. In this talk I will introduce an agile approach to business intelligence that drives decision support, feeds data analysis, and delivers flexible reporting capabilities.
We will explore the complete architecture of a lightweight BI system that is used in the real world to capture and analyze customer information, monitor user behaviour, feed machine-learning algorithms for decision support, and deliver real knowledge and value to business stakeholders.
At Tapjoy we process over a million jobs an hour with Ruby. This talk is a discussion of tools, techniques, and interesting problems from the trenches of scaling up over the last two years. Expect to learn a lot about Ruby job queues (beyond Resque/Sidekiq), performance, concurrency and more.
DEF CON Capture the Flag is the world series of computer hacking, with hundreds of teams from all over the world trying to qualify, and a select few competing on site in Las Vegas. For our first time hosting this event, we picked a Ruby-based stack running the game, which has teams attempting to defend their network services while hacking opponents' and stealing secrets.
What's involved in competing in DEF CON CTF? How did we build two complete competitions in five months? What kind of teams survive the experience?
Last year at this very conference John Duff spoke about how Shopify scales while maintaing one of the longest lived and largest Rails deployments, and how we affront the challenges that come with growth. Shopify in 2013 became more than twice the size in every single aspect; requests per minute, GMV, merchants, number of developers, etc.
After CyberMonday 2012 it became clear that if we wanted to survive CyberMonday 2013 we needed to spread the load across more than a single huge database, and move to a model of smaller databases to enable horizontal scalability. This is the story of how, in 2013, we more than doubled the number number of databases that power Shopify, and all the challenges that come along when sharding a living, breathing and money producing Ruby application.
If you get 10 minutes into this talk and decide you don't really like the topic, the topic will change! If you don't like the speaker, well ... there's no accounting for taste.
The Cobbler's Production Console Has No Shoes. Don't give all your great stuff to your end-users, build something nice for yourself as well. We'll look at a few of the things I've built for myself at LivingSocial and hopefully will inspire you to do the same.
Do-It-Yourself Mocks and Fixtures. Big projects need some custom love. factory_girl, ActiveRecord fixtures and mocha demo nice, but sometimes they wear out their welcome in a big code base. How hard could it be to do yourself? Let's find out! It might be easier than you think.
Track yer Big Stuff without screwing up production with Humperdink. With over 2500 translation keys in one app, we decided to build out some tooling to track at runtime what was and wasn't being used so we could prune out the dead stuff.
ALL THE ANALOGIES We've all tried to wield the construction analogy to help figure out what the heck it is we do. Let's get creative and think of 10 other ways that don't quite capture it either.
The state of diversity in open source contributions is abysmal. With the number of female OSS contributors at a shockingly low 1.5% and other groups not even documented, we need to ask what we can be doing better as a community. We’ll discuss the barriers that people face contributing to our open source projects and what we can do to increase participation.
When you think "GitHub", you're probably thinking of what we lovingly refer to as GitHub Dot Com: The Web Site. GitHub Dot Com: The Web Site runs on an incredibly interesting infrastructure composed of very powerful, cleverly configured, and deeply handsome servers. This is not their story.
This is the story of the other 90% of our infrastructure. This is the story of the 350 AWS instances, 250 Heroku dynos, and dozens of Rackspace Cloud, Softlayer, and ESX VMs we run. This is a story of tooling and monitoring, of happiness and heartbreak, and, ultimately, of The Cloud.
Changing code is easy. Changing code with confidence isn't. Even the most robust, mature test suites have blind spots that make large scale changes difficult. At GitHub we use Science to instrument, compare results, and measure performance of parallel code path experiments to see how new code runs against a current production baseline. This talk will show you how to Science, too.
Once you’ve properly structured your Rails app, you’ll begin to find logical seams in your domain logic. These seams can be the perfect opportunity to extract a software component into a stand-alone service.
Using a live-in-production example, we’ll walk through how we build and integrate services at Union Metrics. We'll go over some tips and patterns we've discovered as well as about some of the pitfalls and things to avoid when building and deploying stand-alone services.
Getting big things done is important. We praise big accomplishments, but those involved can usually point to the small decisions and actions along the way that made it all possible. Structuring teams, projects, systems, and processes to embrace smallness enables the big things to evolve and succeed. This talk will cover ways in which the teams behind TripCase have succeeded and failed while making big things happen one small step at a time.
It's your first day at Hogwarts.com, and everything is wonderful and thrilling. You dig in to classes, and soon find a dusty book with a cryptic warning:
"Do NOT on any circumstances make ANY change to this magic incantation without talking to Doug first!!!"
Sound familiar? Approaching a legacy code base can feel like unraveling a mystery, not just about the code, but about the personalities who wrote it. What tools and techniques can help you solve the maze of twisty code? Let's explore how to get a handle on legacy code, how to negotiate joining an existing team of developers, and how we can get a summa cum laude at graduation.
00:00:00:00 - Christopher Krailo (User Groups are Awesome)
00:03:22:00 - Aaron Lasseigne (Interactions)
00:08:58:11 - Mando Escamila (Lone Star Ruby Foundation)
00:12:59:00 - Jeremy Perez (From Intern to FTE)
00:21:13:22 - Jeffery Davis (3 Functional Programming "words" that exist in Ruby)
Most Computer Science curriculums offer at least one course that focuses on databases. Most of the time, these courses promote relational database management systems (RDBMS) by emphasizing the relational model, relational algebra, data normalization, and Structured Query Language (SQL).
Key/value data stores are increasing in popularity but our mental model for storing data is still primarily relational.
In this talk, we'll explore data modeling for key/value stores using the Uber mobile application as an example.
Heroku operates the largest fleet of Postgres databases in the world. Service oriented architecture, infrastructure as code, and fault tolerance make it possible. Come hear how the Heroku Postgres team uses a handful of Ruby applications to operate and scale the largest herd of your favorite elephant themed RDBMS.
Working well with other developers: it's difficult and it's crucial. Many projects that fail do so due to social problems, not technical problems. The ability to communicate and work with lots of different kinds of developers and stakeholders can be a superpower almost as awesome as writing software.
Sadly, there's no manual for developers to read about effective collaboration. But we can still try to better understand different kinds of developers and how to work with them. We can pick up some ideas for how to survive working in a team, or how to lead a team. We can learn how to get from our imperfect teams now to a better team in the future.
Collaboration is hard, but we can learn it and make it our superhero power.
CLOSING COMMENTS 4