Bio
Jacob is the world's foremost expert on (within the subset of people who: work in Ruby for a living, surf the Pacific regularly, and brew sour beers). He does all these things in San Francisco California, while working at Engine Yard.
title
Making Sour Beer and Software
abstract
Sometimes I make Ales. Sometimes I makes Lagers. And sometimes, I try to make the weirdest craziest (most delicious) $!#&% I can think of.
And this personality defect carries over into my day job at Engine Yard.
Sometimes, a bad idea turns into a good one. Sometimes, it gets poured down the drain.
Allow me to review a few of my monstrous creations, attempt to analyze why they flew or flopped, and what I learned.
As in all things, balance (and patience) is key.
notes
This is a (hopefully) fun and light-hearted talk, with the goal of inspiring people to go hack on something or try doing something in a new or weird way. I will talk about the process of making sour beer and I will talk about the process of making weird software hacks. There will be parallels. Conference Organizers permitting: I will provide homebrewed sour beers (examples of success) for tasting by conference attendees.
title
Being Present
abstract
It's the feeling of wind in your beard, or sand on your feet. It's immensely important, but so easy to forget.
Do you realize how much regular exercise and moments of Zen matter? I thought I did, I even gave a talk about it at a Ruby conference. And then I dislocated my knee cap. This sucks. So go climb a mountain or something, while you can! Work up to if you have to. Find something you can do with your whole body that inspires your mind, and do it regularly.
Strive to be a happier healthier programmer. Or, just be a surf bum like me.
notes
This is basically the same talk I gave at Cascadia Ruby conference, customized to the surf breaks near you. This talk is not about Ruby, just a case study in the lifestyle of one sometimes-effective programmer: me.
title
Living with Distributed Systems
abstract
We all know the problem of the monolithic rails app, and we've all accepted the divine words of Service-Oriented Architecture. But what does your world look like once you get there? Or say, maybe, three-quarters of the way there.
Allow me to show you some of the mistakes we've made at Engine Yard on this path. It can be a bumpy road, but I promise you the destination is worth it.
notes
I gave a similar talk at Rails Israel. Much of the content will be the same but I have some different ideas about how to present it. This talk is about building a comfortable multi-app dev environment (meaning, one where you can confidently write tests), so you can successfully ship distributed systems.
title
The Basics of Redis
abstract
I don't know if you people already knew this, but Redis is the ultimate tool for hacking something together and shipping it straight to production. And let me tell you, I've shipped my share of hacks to production.
The secret, of course, is key expiration. Plus you don't have to ship migrations, so reverting your hacks leaves way less cruft!
Allow me to show you some real-world examples. That you too may be engorged with the sense of power I first experienced when I realized how easy this is.
Cheat sheet: redis.set("foo", "bar") redis.get("foo") #returns "bar" redis.expire("foo", 5.minutes)
notes
This is nearly an intro level talk, but with a lesson I think many experienced rails folks have yet to notice. I hope to teach a mindset about building things with Redis as a backend (as opposed to (or complimentary to) traditional ActiveRecord). Real, substantial, hopefully-impressive, things.
title
How to fail at Background Jobs
abstract
From DRB, XMPP, AMQP to Resque and Rails 4. Running a background worker process is a tool I've reached for often. And while the underlying tools may change, the same problems seem to crop up in every one.
A failed request serves your fancy custom 500 error page, but what about a failed job? Is there such a thing as a "reliable" queuing system that will never lose OR double process any jobs? Are we talking about "simple" asynchronous method calls on models or should we build "pure" workers with only the knowledge of a single task? What does "idempotent" mean again?
Please allow me to enliven the debates.
notes
This is a mid-level talk that I think safely assumes you've done some sort of background processing before. I really do want to hear what people think or if/how they've solved these problems. I hope I can do that by presenting some options and allowing them to self-identify "that's what we do". The tools are great, but they all fall so short in answering (or even having an opinion) on these questions.
title
Extreme Convention over Configuration
abstract
Rails is pretty great. It looks for the definition of User in "user.rb". It knows that my views for WatsitsController are in views/watsits. And I can even have an auto-generated blog in 5 minutes thanks to scaffolding. But couldn't we go so much further?
What would happen if we took the rails ideal of Convention over Configuration to it's limits? How about default implementations of controllers. What about some default views? Couldn't our entire set of models be simply inferred from our database schema?
Let's go there.
notes
Ya, I wanna go there. This is a fun, exploratory talk where we look at "Clever but probably a bad idea" sorts of things.