I'm insanely enthusiastic about Passion Projects, an initiative by Julie Ann Horvath and Github to highlight 'Incredible Women In Tech'
I even got to participate! My Passion Project for several years has been growing RailsBridge, in a way that lets us expand around the world, make the best use of volunteers, and, because it's an all-volunteer organization, create ways for new people to jump in and contribute immediately without needing anyone's permission. My talk at GitHub focused on the examples of leaderless organizations that inspired us.
The GitHub Streaming Eagles recorded the talk for posterity, and afterwards, Julie directed a short documentary about how I got started and how RailsBridge is kinda changing the world.
The first year I attended SRC (2010), Jim Weirich gave an amazing keynote about working through The Structure and Interpreation of Computer Programs. When I got home, I started a study group to do the same thing. It was just as educational as Jim said.
The next year I attended (2012), Brigitte Jellinek, a friend and one of the only academic instructors teaching Rails in 2012, cajoled me into giving a lightning talk with her; she spoke about teaching in an academia and I spoke about teaching at RailsBridge.
In 2013, Alan, one of the SRC organizers, asked me to give a real talk, a keynote, even! I had recently been inspired by a great history of programming, GOTO, by Steve Lohr that summarized: Much of the history of computer programming can be seen as the effort to expand the franchise -- to make it easier for more people to program.
My talk at SRC focused on how we 'Grow Programming', how we can accomplish more individually and how we can bring more people to programming. When we improve our languages and tools, we make it possible for people to solve their own problems using computers. We also have to fight the perception of programming and programmers that push away the people who we could be teaching.
One of the projects I worked on at ModCloth was a backbone app that we built to be almost all of the tablet site experience. We hoped that by avoiding full page refreshes we could create an experience that felt snappy and responsive.
We were very driven by performance concerns, but, when we launched it, realized we had no RUM (Real User Monitoring) in place to confirm our observation that it was faster. And making things worse, because we were never refreshing the page, the site performance information being sent to New Relic was all over the place.
This yak-themed talk, Benchmarking the New Front End: How to Quantify Single Page App Performance, given with Emily Nakashima is a performance talk, targeted at a mostly front-end audience. We ended up having to roll our own solution to front-end performance monitoring because the tools we take for granted on the server-side aren't yet available for monitoring client responsiveness.
Since this was part of an O'Reilly conference, the video is a little pricey. Our slides are available on slideshare. And for extra reading, we collected all our references in a bitly bundle.
After preparing our talk for Fluent, we realized that our message was not only for the front-end community; it's just important to make sure to make sure that the people who "own" performance understand that no matter how great server performance is, if the client has become slow or even unresponsive, the site performance isn't really being tracked at all.
(And if you're not measuring how users are actually experiencing your site, you're burying your head in the sand. Hence the Ostrich theme.)
Emily Nakashima and I intended this talk, Benchmarking the Front End: Expanding What Performance Means and How to Track it, for an audience composed of more Operations folks, and people who care about the full performance story. Some of the content overlaps with the Fluent talk, but we don't assume knowledge of javascript.
Because this was an O'Rielly conference, the video is behind a pay wall. But our slides, references, and further reading are purusable.
After reading two blog posts about how Ruby caches method lookups within a few months of each other, one by James Golick and one by Charlie Somerville, I decided to dig in and learn about the Ruby internals for a talk at Wicked Good Ruby.
Sheena McCoy, and I wanted to collaborate together since we found ourselves always working on separate projects at ModCloth, and seized this opportunity.
The video is available, though I step on my first joke out of the gate and it's terrible. There are also slides if that's your style. Or check out the references and reading we helpfully assembled. :)
By volunteering to help out at RailsGirls and Patchwork workshops, I've met amazing developers who are just getting started.
This talk, Learning Hard (and Amazing!) Things, is what I wish I had known when I started learning to program. This isn't a technical talk; its about me, people, and the Patriarchy.
Women are more likely to encounter people who will say things that will feel so shitty you'll want to quit programming. This talk is about putting my foot down, and refusing to leave. It takes grit and stubborness to fight back when people expect me to be not a developer, not a backend developer, and not a senior backend developer. And it's incredibly unfair that this is a requirement for women to succeed.
So I wrote a talk about it.
Most web developers have to support some old browsers. But the build the features we need, we often add snippets of code that adapt the functionality of older browsers; now we call these snippets polyfills. Polyfills are temporary; as our platforms evolve, we should pull out the polyfills when they become unnecessary. But we all know that usually doesn't happen.
This talk, Everything is a Polyfill: Automate Deleting Code for Front End Performance is a call to take polyfills seriously as a distinct layer in our app. As those develop, we propse using Sunset Tests, tests that mark temporary code and note its sunset date. The test failures occur automatically on sunset dates, and alert developers exactly what code can be removed. Sunset Tests are a way to efficiently mark code as expired, and make it easy to remove.
We're bullish on polyfills. Lots of people have done a great job of understanding the performance costs of large polyfils like jQuery, but for a large app, we'll always want to normalize and simplify our API, rather than scattering polyfills throughout our app.
Improve Web Perf Without Breaking Metrics, is the story of performance optimizations gone wrong. I was interested in why upgrading a large Rails app from Ruby 1.8.3 to 1.9, which was touted as a performance upgrade, ended up increasing response time. I ended up diving into the Ruby method cache, to understand the things we were doing that prevented us from taking advantage of Ruby optimizations.
But even after understanding the backend problems, we learned the Performance Golden Rule the hard way. For the average website, 10% of the time spent waiting for the page to load is spent on the back end -- DNS, the handshake, hitting the database, and in server code. 90% is spent on the front end.
So when we worked to optimize server code, it didn't noticable improve the experience of users, and it didn't noticable impact business metrics like page views or conversion.
So we started taking user's perception of speed seriously. We created a backbone app for the tablet users with the goal of being able to carefully prioritize requests to have the fastest experience possible. Unfortunately, we were relying heavily on third party performance monitoring tools, all built around time to window load. When the time to window load stopped matching the user experience, we found ourselves flying blind.
Service Oriented Architecture has been recommended as the solution to anything that ails a web app. Is your code hard to refactor? Write Services. Is your code slow? Write Services. Database falling over under load? Write Services.
This talk is meant to kick off a conversation that looks honestly at how services hold up a year or two down the line. How maintainable are services? What problems do they solve well, and what problems they make worse? This talk walks through some cautionary tales from my own experiences building out services.
The worst place for services is a large, not entirely understood, legacy code base in need of refactor. In those cases, the app doesn't need to be rewritten in services, it needs to be understood and refactored!
The potential downside of Service Oriented Architectures is an ecosystem of services that mirror the poorly understood app we started with, with the additional problems of many single-points-of-failure, added network latency, queuing missteps, and needing to scale up more app servers and database clusters to maintain equivalent performance.
These downsides also point to specific use cases where Services are a great solution, specifically where code is running in multiple locations or has significantly different uptime requirements. But it's not the solution to anything that ails the modern web app.
The talk recording from Ruby Conf Australia is available online, though the audio drops out at the end.