| Melville | Ferntower | Earn | |
|---|---|---|---|
| 10:00 - 10:45 | videoMiniTest & Rails: Total BFFs Mike Moore |
videoFailure for Fun and Profit! Kerri Miller |
videoMetaphors are like knives. You can use them to cut yourself and if you throw rocks at them, they fall apart Jan Krutisch |
| 11:00 - 11:45 | videoGiven - Designing a Language Jim Weirich |
videoBack to Front: One man's journey from server to client side. Philip Roberts |
videoThe Web of Tomorrow Bruno Aguirre |
| 12:00 - 12:45 | videoLeading software teams well Chris Parsons |
videoDevs and Depression Greg Baugues |
|
| 12:45 - 13:45 | Lunch in the Meikle Restuarant | ||
| 13:45 - 14:45 | video Lightning talks | ||
| 15:00 - 15:45 | videoCooking Infrastructure with Chef Mathias Meyer |
videoA Beautiful Partnership: UX Tony Pitale |
videoBe wrong, but try things. Franck Verrot |
| 15:45 - 16:15 | 1/2 hour break | ||
| 16:15 - 17:00 | videoRuby the Arduino Way Austin Vance |
videoI-motion Fernand Galiana |
|
| 17:15 - 18:15 | video Keynote by Evan Henshaw-Plath | ||
| 18:15 - 18:30 | Wrap up | ||
| 19:00 - 20:30 | Dinner in the Meikle Restuarant | ||
| 20:30 - 00:00 | Party and Highland Dancing | ||
As well as being a super ruby developer for ModCloth, Rachel organises Rails Bridge - a non-profit organisation that works to increase diversity in tech by putting on a variety of awesome free events, such as free weekend workshops where women learn Ruby on Rails from volunteers.
Evan Henshaw-Plath, is better known as Rabble the anarchogeek and CTO of Neo.
Rabble was the first hire and lead developer of Odeo.com through the pivot to Twitter. From there he was architect at Yahoo Brickhouse where they built the social location platform, Fire Eagle. He has spoken extensively on startups, software development, media, social change. Other speaking engagements include: Web 2.0 Expo, OSCON, Rails Conf, XTech, Mobile Active, Emerging Telephony Conference, Emerging Communications Conference and more.
Computer programming was once seen as “women’s work.” Ada Lovelace, Grace Hopper, Adele Goldberg, and others played pivotal roles in paving the way for today’s computing professions. So why then do we see so few women in our community? We’ll cover the history of women in computing, possible causes of the gender imbalance, and ideas for how our community can shape a future that includes more women.
Elise is software developer, marketer, and aspiring polymath. She’s obsessed with surfacing data for easy consumption and does so with lots of ruby and javascript. In 2012, she completed LivingSocial’s Hungry Academy program. She is currently on a 6-month fitness sabbatical, finding out her body’s potential and tracking improvement as she goes.
Jessica is vegan, loves cats, and when she is not outside playing she can be found writing code for G5. Find her on twitter: @jlsuttles.
Every networked application has to deal with security threats, and the code in your application might not always be able to deal with them: someone running off with hardware, a malicious DBA, or a zero-day exploit, for example. Cryptography helps in these situations, and is frequently required in a compliance audit too. Protect your data with exciting acronyms such as HTTPS, GPG, AES, RSA, ECC, DSA, and more; learn about the quick and easy ways to get it right, the difficult ways to get it wrong, and the fantastically difficult ways to get it right that particularly esoteric situations will demand.
Bryce is a software engineer at Basho, makers of the Riak database. He also runs the Miami Ruby Brigade, and really would enjoy doing more front-end design but finds back-end work more entertaining.
We often feel motivated when we start a new job. We want to do well, make a positive impact, and work hard. Too often that desire to work hard fizzles away and we get burned out. Have you ever spent hours during the day thinking about being somewhere other than work? Have you ever felt isolated from your coworkers? Have you ever felt anger, disgust, or apathy towards the work you do?
Burnout is common and it is dangerous. It can negatively affect your work, your coworkers, your organization, and also your life satisfaction. I will use psychological research to discuss the signs of burnout, how to spot it (in yourself and others), what you can do when it occurs, and ways to keep the fire inside you alive.
Erin is a PhD I/O Psych student destined to never graduate. She’s an amazing aunt, a researcher, a world traveler, stats instructor, and validation seeker. She has spoken on the topics of the lack of women in technology and perfectionism. She is bilingual in sarcasm and English.
Rails has always been great for building APIs, but it could be even better. The rails-api project provides a couple of gems that give you tools to build even more awesome APIs. In this talk, Steve will show you how rails-api can help you build great APIs, no matter if they’re REST, Hypermedia, or backing a JavaScript SPA app.
Rails committer, Jumpstart Lab instructor, nomad philosopher.
This talks is about using rubymotion from a ROR developer perspective. This will be an in depth journey of getting an app from 0 to appstore. Venturing down this new big world was not without excitements and frustrations. You’ll be left with some great take-away and tips, that will make your path to enlightenment, hopefully less painful. Lots of code and common use cases will be covered so hang on to your panties…
Owner of a small software consultancy based in Denver Colorado. Beloved host of DeRailed, Denver based ruby on rails group, is my attempt to build a great local community. In my copious spare time, I contribute to open source projects. Of recent, I’ve been tackling the ios world and so far managed to avoid doubling up on my prozac intake… Word!
Every aspect of our lives has been transformed by the invention of general-purpose programmable computers. As a result, it’s tempting to believe that computers can solve any logical or mathematical problem; that if we throw enough time, money and nerds at a question, we can produce a program which answers it.
Unfortunately the universe is never that convenient. There are hard theoretical limits on what programs are capable of doing, and there will always be easily-stated problems which are impossible for any computer to solve.
This talk uses Ruby to tell a nail-biting, maths-free story about the source of a computer’s power, the inevitable drawbacks of that power, and the impossible programs which lie at the heart of uncomputability.
Tom is a computer scientist and programmer, and the founder of Codon, a digital product consultancy in London. He works as a consultant, mentor and trainer, helping companies to improve the quality and clarity of their approach to creating software products, usually on the web. He has lectured on optimising compilers at the University of Cambridge, co-organises the Ruby Manor conference, and is a member of the London Ruby User Group. His new book, Understanding Computation, is published by O’Reilly in May.
Rails 4 is switching to MiniTest from Test::Unit. What does this mean for you? MiniTest is more than an exercise in minimalism, it’s a full-featured testing framework. Using MiniTest, we can change our approach to application design and build Rails apps that are more flexible, easier to refactor, and more maintainable.
We’ll get straight to the good stuff: How to test validations. When to stub and when to mock. How to use fixtures, and when you should skip them. Can your model tests be faster? What about controller tests? And why you’d choose it over RSpec.
Have you worked on apps where the tests are mocked to the hilt and impossible to change when refactoring? Or wasted time hunting through dozens of files to find all the downstream methods called from one controller action? Or simply thrown tests away because your team can no longer maintain them? Then this session is for you.
Mike is a cool guy and loves ruby. He’s the author of the minitest-rails gem. According to this picture he likes table tennis and grows a mean beard.
Mike’s beard defies all logic. Mike did not grow his beard, he just flexed his jaw and pushed the hair out. Mike tried to get his beard trimmed once; his beard took the scissors from the barber and stabbed him in the eye. When Mike’s beard gets to a perfect length it stops growing. Each hair on Mike’s beard holds the soul of a victim. Mike’s beard blogs and codes and tweets and links and books faces.
Given is a lightweight framework for writing executable specifications. The evolution of the Given DSL was a multi-year process, starting with a simple idea and looking for a way to best express the concepts as a Ruby-based DSL. Currently written as a layer on top of RSpec, it makes the Given/When/Then style of specification very explicit. Although its goals are modest, there are some interesting technical details about its design and implementation. This talk will walk you from the initial conception of Given, through its design, and onto its unusual implementation, hopefully given you a unique perspective on the building of an expressive DSL.
Jim Weirich first learned about computers when his college adviser suggested he take a computer science course: “It will be useful, and you might enjoy it.” With those prophetic words, Jim has been developing now for over 25 years, working with everything from crunching rocket launch data on supercomputers to wiring up servos and LEDs on micro-controllers. Currently he loves working in Ruby and Rails as the Chief Scientist at New Context, but you can also find him strumming on his ukulele as time permits.
I have Type II Bipolar and ADHD. For years, I was crippled by intermittent depression and a general inability to get shit done. I’m fortunate, I got on the right meds five years ago and have been remarkably stable since.
Many developers are not so lucky.
Software development is a good place for people with depression and bipolar. It accepts the socially isolated. It accommodates irregular sleep patterns and inconsistent bursts of productivity. It seeks those with the grandiosity to believe that they can solve problems others can’t.
We need to bring depression out into the sunlight, and make it as acceptable as diabetes or cancer. We need depressed developers to know that they are not lazy or weak, but are suffering from a treatable medical condition.
I’ve been programming most of my life, and in Ruby for the last three years. I serve as Director of Client Services at Table XI, where I help translate tech into client speak and back.
In my free time, I write, speak at conferences, code, cook and travel. In 2012, my wife and I spend six weeks traveling Western Europe, including two weeks on a thirty-cow organic dairy farm. We spent the first five weeks of 2013 touring Turkey.
Check out my blog for more info: baugues.com
User experience (UX) is most often thought of as architecting or designing the way in which our users will interact with content, features, or a system as a whole. I also consider UX as a critical part of a cohesive team; they defend the user.
I’ve had the benefit of working with some of the finest UX designers in the industry. I’m even dating a UXer. While this talk won’t address that particular relationship, I will impart ways to improve the working relationship between software development and UX teams. In this talk I’ll:
If you have the pleasure of working with UX, or want to learn why you should be more involved with your UX team, you’ll enjoy this talk.
Tony Pitale is a developer at LivingSocial in Washington, DC, where he builds software to help merchants and their customers. He’s been developing with Ruby for seven years, and built the libraries Legato and MailRoom. In his free time Tony dabbles in photography and winemaking, and hangs out in DC.
There’s no magic mojo that helps a designer notice bad design; there’s no secret compendium of design mysteries that developers just don’t have access to. Good interaction design is fundamentally about keeping your senses honed – noticing the little things and respecting user intuition will help you pinpoint exactly what it is that makes an interface flow. In this talk I won’t be showing code – I’ll be breaking down the usability of the world around you, and preaching the virtues of interaction awareness. Trust me: you’ll never look at a microwave the same way again.
Cameron Daigle is a designer at Hashrocket, a magical, mysterious place where the role of “designer” often means you’re wireframing one day, art-directing the next, and coding jQuery plugins sometime in between. He’s been working on Rails projects since the early days of the platform – and wrangling browsers into submission since long before that – but through it all has maintained a deep and steadfast love for beautiful user experiences.
There’s a beautiful dream: you push a button, you run a command, and minutes later you have a fully configured server serving requests.
Thanks to infrastructure automation tools like Chef, we’re pretty close to that, in a Ruby-friendly way, no less.
We’ll look into automating setting up basic pieces of your infrastructure, an application server, a database and a deployment, using just Chef, going through all the bits and pieces that make it an incredibly powerful tool to have at your disposal.
Infrastructure head honcho at Travis CI and author of the Riak Handbook.
Do you actually know how to deliberately acquire, sharpen, and retain a technical skill? In this talk, I’ll discuss common strategies to enable you to be more focused, creative, and productive while learning, by using play, exploration, and ultimately failure. You’ll leave knowing several “Experiential Learning” patterns and techniques that can help you turn failure into success.
When was the last time you failed in a spectacular fashion? Was it really so bad? If you want to succeed, you first need to take a little time to fail.
Kerri Miller is currently a Software Development Lead at Blue Box Group. Prior to that, she was a developer on Amazon.com’s Personalization team and has worked with a number of start-ups in the action sports industry. A passionate learner, she has worked as a lighting designer, puppeteer, sous chef, and professional poker player, and enjoys hiking, collecting Vespas, and working with glass.
I hate to break it to you, guys, but Ruby is 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.
Sarah Mei is a Ruby developer from San Francisco who has been programming since the days when Java was the new hotness. For the last three years she’s been at Pivotal Labs running client projects. Four years ago, in order to avoid being the only woman at her local Ruby meetups, she co-founded RailsBridge, which since then has taught Ruby and Rails to over a thousand women on five continents. Recently, after reading four Jane Austen books in a month, she very nearly rewrote her bio in the style of the 18th-century minor English gentry.
Ever experienced staring at a blank file or a blank piece of paper and desperately trying to come up with an idea? Yep. We’ve all been there. Problem is that this isn’t how most people think. Most of us think by doing.
I will share with you some of my approaches for exploring problem spaces, and talk about how I decide which things are just props that allow me some thinking space and which ones are worthwhile projects in their own right.
Nat is a technologist and interaction designer, who was probably the first Polish child on the internet in the history of um… the internet. Likes beer and glitter.
Love it or hate it, client side web-apps and JavaScript are here to stay. But fear not, Ruby programmer: JavaScript isn’t as cruddy as you think, and writing “proper” applications in the browser can even be fun—honest! However, you are wise to tread carefully. This is a new and dangerous land, where callbacks rule and you can’t just throw more servers at your performance problems.
In this talk, I’ll take you through some of the things I’ve learned over the past two years of moving a complex financial forecasting application into the browser, and hopefully prepare you for the coming apocalypse.
I am the CTO and co-founder of Float, a web-app that helps small business owners understand, monitor and forecast their cash-flow.
I spend most of my work days wrestling with Backbone and Rails, and my spare time hacking on ridiculous side projects, throwing myself off diving boards, or trying to learn to play the piano.
A lot of reliance for Web Application Security is put in the framework that’s used. But here’s the bad news … it will fail you. There’s no such thing as perfect code, and web application frameworks are no exception. So how do you avoid the panic upgrades when a security alert hits your e-mail Inbox? This talk aims to give you some ideas about what you can do to make your application more robust and allow you to sleep more easily at night.
I’m an IT Security professional based in Scotland. I’ve been in IT Security for 12 years now, with the last seven focusing on penetration testing/ethical hacking.
Currently director at a Scotland based Security Testing consultancy called ScotSTS.
Many who code aspire to lead software teams and help others to achieve great things. However, being a great coder does not automatically make you a great manager, or a great leader. Nor does being able to recognise bad management imbue you with the skills to do any better.
A number of myths about management pervade: some think that leading means “being in charge” and telling others what to do and how to do it, whereas nothing could actually be further from the truth. Others feel a great weight of responsibility, and are paralysed into inaction by a fear of “getting it wrong.”
To make things worse, developers can sometimes feels like management is only natural career progression path, yet many fear this means they have to give up coding for good, and focus on velocity charts, burn downs and an endless eternity of email.
Let’s bust some of those myths. In this talk you will learn:
Come along if you’d like to learn to take the reigns and lead teams to the next level, without micro-managing them or giving up coding entirely.
Chris is an itinerant programmer, trainer, writer and speaker. He was the owner of the Ruby consultancy Eden Development, and now consults in technical architecture and agile management, and trains and coaches teams in BDD, automated testing, clean code and great team practices. In 2012 he co-founded the public training programme BDD Kickstart with Matt Wynne.
Metaphors and analogies are powerful tools to make the indescribable describable and the nonunderstandable understandable.
As with every tool misused, though, they can be dangerous, leading to wrong conclusions or creating unwanted side effects.
By showing a few analogies and metaphors that are commonly used in our field and how taking them too far makes things worse instead of better, I’ll try to show you ways of detecting these fallacies and at the same time drop some serious opinionated shit on your heads, like a pigeon after the third taco. Or something.
Jan is a freelance web dude, tech consultant for publishers and media companies, community glue gun wielder and code artist from Hamburg, Germany. He thinks too much about a lot of things and loves to talk about a lot of things.
“Fat models” cause maintenance issues in large apps. Only incrementally better than cluttering controllers with domain logic, they usually represent a failure to apply the Single Responsibility Principle (SRP). “Anything related to what a user does” is not a single responsibility.
Early on, SRP is easier to apply. ActiveRecord classes handle persistence, associations and not much else. But bit-by-bit, they grow. Objects that are inherently responsible for persistence become the de facto owner of all business logic as well. And a year or two later you have a User class with over 500 lines of code, and hundreds of methods in it’s public interface. Callback hell ensues.
This talk will explore patterns to smoothly deal with increasing intrinsic complexity (read: features!) of your application. Transform fat models into a coordinated set of small, encapsulated objects working together in a veritable symphony.
Bryan (@brynary) is the founder of Code Climate, an automated code review tool for Ruby apps, and the lead organizer of the Gotham Ruby Conference in NYC. For the last seven years, he’s been an active in the Ruby community as an acclaimed speaker, author and open source contributor. In 2009, he received a Ruby Hero Award for his efforts.
Have you read all of those great pattern books for programmers? Smalltalk Best Practice Patterns, Design Patterns, Patterns of Enterprise Application Architecture, The Joy of Cooking, and more. James has and while that probably says some creepy things about what he means by, “curling up with a good book,” it’s also handy at times.
Lets face it, there are a ton of patterns. Some of them are pretty obscure and rare. Some of them really help though. When you hit the “Ah ha” moment with these special few, you are forever changed as a programmer.
Did you know Composed Method doesn’t just help you write smaller methods, but it can actually tell you what belongs in them too? I think most of us have learned that using super is usually better than monkey patching, but do you know that boring old Template Method is often better still? Did you know that designing a simple State Machine is most of the battle in building a Buzzword Bingo compliant Hypermedia API?
There are two ways you can cram all of this not-so-ancient wisdom into your head: read half the Internet or come to this talk. Choose wisely!
James is a long time Rubyist who has written code and documentation that ended up in the language itself. He now spends his Wednesday mornings recording the Ruby Rogues podcast with a handful of close friends that also happen to be wicked smart programmers. They often interview even smarter programmers, so James lives in a constant cycle of learning new things. This is the good life.
Databases with only one relationship type and no ability to add properties to their relationships are square, not relational (I’m looking at you, postgres). In this session we’ll look at a truly relational database – neo4j. We’ll look at what it is, why you’d want to use it and how it changes your data modeling and development process when you start using graph databases. Whether you’re coding social apps or just want to manage a web of things, learn how neo4j can change the way you think about storing your data.
@PeterBell – Evangelist/hacker @hackny, trainer @github , Author @pearsonplc, Lean startups, Ruby/Groovy/Clojure/JS/NoSQL/Node/Mobile Cofounder @CTOSchool, Instructor @GA
What’s the deal Writing software is great, websites, applications, and scripts are things we interact with every day. What about writing software that we can interact with in the physical world? From automated sprinkler systems that turn off when you pull into your drive way, to scoreboards at the company foosball table physical computing opens a door for the innovator inside every software engineer.
It’s too hard Not true, there are amazing libraries and compilers that let us write software for Arduinos in the best language, Ruby. Think about it no C, no headers, and no static types, just plain old ruby. That is a good deal.
In this talk I will go over a few of the most popular Ruby libraries for interacting with an Arduino, talk about some basics of each library and then spend time on how these libraries and Arduino can interact to create applications that respond in the physical world. There will be t-shirts shot from a robotic cannon.
I am Austin, a web developer for Pivotal Labs., in Boulder Colorado. I love building web apps. When I am not working, I really enjoy doing anything outdoors, I travel as much as I can, and when I do I try to immerse myself in new culture.
During the last 12 months we have seen a rapid rise in the discussion of “proper” object-oriented approaches to designing Ruby and/or Rails applications. One sound-bite that comes up frequently goes something like “You need to change your code to Tell, Don’t Ask”. But what does that mean in practice? It probably means exactly the opposite of what you think it means.
Dr Kevin Rutherford is author of the vastly under-rated Reek code smell detector, and the vastly over-rated book ‘Refactoring in Ruby’. If you have ever used Unix System V or transferred money between bank accounts, you’ve unwittingly used his code. He was using vi before you were born.
The web is changing and new changes are coming.
How will the new RFCs will affect the web as we know it?
What technologies will raise again? Is Ruby prepared for this changes?
I want to answer these questions and talk about new web technologies and how we need to change to adapt to this upcoming era.
From web sockets to WebRTC. From distributed to decentralised.
The storm is coming… are you ready?
Bruno (aka Cuervo) was raised by a Telecommunication’s tribe of savages where he was taught the ways of Distributed Computing and Async Protocols. The urbanisation of the tribe’s lands and Emperor penguin migration cycle led Cuervo to the HTTP way, and now he seeks to unite both ways.
Being Open Source dependent, he leads several Open Source Projects, is also a Gemini and enjoys long walks on the beach.
Most developers will be brimming with ideas, some of which end up as side-projects. But what happens when you decide to turn one of these side-projects into an actual business? A product that you charge people money to use and that you hope will one day become your full-time gig?
What follows is a cautionary tale, warts and all, from someone who has been there, done that and got the t-shirt. Hear from a fellow developer: what it’s like to build and launch a product in your spare time; how your developer brain can actually work against you; why your idea might be doomed from the start; and ultimately, how to make the right choices to maximise the chance your bootstrapped startup will be a success.
Founder of crowd.fm, Ruby/Rails hacker, cyclist, and organiser of Manchester’s Bootstrap Business Club.
The story of the quest to make bundle install faster; in which Rubyists around the world inadvertently DDoS rubygems.org, witness its ignominious death, and vow to rebuild it from the ashes stronger than it was before. Then, a tour of the changes; why is Redis so much slower than Postgres? Marvel at the gorgeous metrics and graphs used to measure and optimize; gasp in delight as we track, live, exactly how many Heroku dynos are needed. Finally, a happy ending: today, the server responds to requests TWO ORDERS OF MAGNITUDE faster than it did before.
André Arko has been a Rubyist for 8 years, leads the Bundler core team, is the author of the jquery-rails gem, and generally spends more time than he probably ought to doing web and ops development.
Scientific papers are published in the goal of showing that certain techniques, given a set of protocols and materials, are deterministic. The reproducible character of such small facts is then reused to be the foundation of larger theories.
But scientists have a secret: most of their experiments are showing bad results. The vast majority never publishes those bad results, afraid of being cut down on budget because of them, and public funds are wasted by these practices.
Us software developers have the tendency to take practices from those scientists, but we should try hard not to hide bad results, and communicate about them.
In my (short) career, I failed a lot at trying new concepts and new practices, and fet ashamed at having even tried. Let’s make our community a better community, and start communicating about things that can hurt our peers.
Entrepreneur, Ruby & JS developer, conference organizer.
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.
Since its inception, MagLev has been the subject of numerous talks, impressive demonstrations, and lots of interest. Many people are interested in running Ruby and Rails applications on a state of the art Smalltalk VM, but adoption has been slow, in part due to to a lack of examples of real world usage. This talk will solve that problem.
In 2013, we started moving our financial applications at VersaPay Corporation to MagLev and are excited to tell you about it!
In this talk we’ll go over the reasons behind, the methods employed, and the barriers to, moving our Sinatra and Rails apps on Ruby Enterprise and MySQL to MagLev and GemStone/S. You’ll learn lots about separating and maintaining applications, and you’ll have a real-world example to point your boss to when you suggest moving your own project to MagLev.
In the third grade, Steven missed an opportunity to corner the Hockey Trivia video game market when he made such a huge mess of his software he had to rewrite it. As with most rewrites, it was a huge failure, and Steven still hasn’t forgiven himself. Since then, he has been obsessed with learning how to produce high quality software, and has been helping teams do just that. Along the way he’s developed tools, delivered talks, and yelled over pints about how to improve software.
MonoRail apps (or monolithic Rails applications) are so 2010. Service Oriented Architecture offers some great solutions to simplifying app complexity, but breaking applications into services trades code complexity for communication complexity. Building interconnected features that require two services to be changed simultaneously can test your confidence in SOA as a solution to complexity. This talk covers some great patterns and anti-patterns for managing development work across teams and services in your shiny new service oriented architecture.
Jesse is delightfully opinionated about code craft(wo)manship and testing. Her experience in ruby, Rails, and javascript comes from her years as a software mercenary at Pivotal Labs. At ModCloth she’s introducing testing and tools expertise to their obstinate (but lovable) developers. She also enjoys volunteering teaching women ruby and Rails at RailsBridge workshops in the San Francisco Bay Area.
When New Relic made the move from Ruby 1.8 to 1.9, we found a significant improvement to garbage collection time, so we explored what was going on in MRI’s garbage collection internals. Starting with the fundamentals of object creation and garbage collection in MRI, we walk through the C internals from Foo.new through garbage collection. We’ll explore the idiom and optimizations in the C source and leave you feeling comfortable to work in the code yourself. Once we arrive at the end of the rabbit hole, we’ll examine the garbage collection algorithms used in Ruby 1.8, 1.9 and 2.0.
Officially, Chris is the Developer Evangelist at New Relic. Unofficially, Chris is a happiness engineer. He spends his time working on things that hopefully make someone’s day better, which makes him a bit of a Swiss-Army® Knife. When Chris is not on a plane, he’s on a soap box evangelizing the merits of coffee, open source, DevOps, travel and of course, Ruby. You can find him on the Internet as amateurhuman, including on Twitter and GitHub.