RubyConf 2015 Wetware Track


This year, when people asked me what I was speaking about at RubyConf, I got to say "absolutely nothing." This is the first time in 3 years I've been to a conference and not actually had to give a talk.

Instead, I was blessed with the honor of curating a track of my choosing. I was further blessed by having an amazing selection of proposals to choose from. My choice was a track composed entirely of "soft" talks that ask us to question the way we think about our work. Originally, I wanted to call it "Harder Skills" in order to bait the people who think "soft skills" are a waste of time into watching. In the end, at Avdi Grimm's suggestion, we renamed the track to "Wetware".

I'm posting the playlist here because I think these talks are important. The playlist is in the order they appeared throughout the day, so if you missed the conference, or missed a few of the talks, you can get a sense of the arc intended for the track.

I'd like to thank the organizers for trusting me to put a track together, but most of all I want to thank Laura Eck, Amar Shah, Brandon Hays, Joe Mastey, Sonja Heinen, and Nickolas Means for putting in all of the hard work to make this track the highlight of my conference-going experience. They were incredible, and your conference would do well to invite any or all of them to speak.


Talk: "Choices"


Conference: Keep Ruby Weird
Location: Austin, TX, USA
Date: 10/23/2015

We're faced with choices every day. Sometimes the right decision is obvious, like "should I have a cookie?" (The answer is ALWAYS yes). Sometimes, less so.

This is a talk about the choices we make. Come prepared to make some choices of your own, as your choices will have an impact on the direction our journey takes!


Talk: "How to Build a Skyscraper"


Conference: Full Stack Fest 2015
Location: Barcelona, Spain
Dates: 9/1/2015 - 9/5/2015

Since 1884, humans have been building skyscrapers. This means that we had 6 decades of skyscraper-building experience before we started building software (depending on your definition of “software”). Maybe there are some lessons we can learn from past experience?

This talk won’t make you an expert skyscraper-builder, but you might just come away with a different perspective on how you build software.


Using the ActiveRecord Attributes API


I've been working on a project at nVisium that has records (of the ActiveRecord kind) with attributes that are themselves a stored domain object. Until recently, I would have probably done one of three things (in decreasing likelihood) to handle this situation:

  1. Use serialization to store the attributes of the domain object in JSON, then wrap the AR object in a decorator to handle translations from the "bag of data" to my domain, even though it means doing the ActiveModel dance to allow me to use this object in a form, and ActiveRecord will always see this attribute as "changed", meaning unnecessary database operations.
  2. Come up with some convoluted way to represent this data using ActiveRecord associations, even though it would almost certainly mean I'd find myself using has_one somewhere (ick), and probably still wrapping the whole thing up to avoid using accepts_nested_attributes_for in forms.
  3. Gone the polyglot persistence route, even though it would mean taking on the ongoing operational overhead of managing another storage backend.

Thankfully, in Rails 5, the ActiveRecord Attributes API offers a fourth option, and it's much nicer. Even better, we can already use this functionality in Rails 4.2. Head on over to my post on the nVisium blog to read how.

Your Clever Code is a Jewel-Encrusted Lobster


I want to share a quick story with you. It's about one of the most memorable things I saw at RailsConf this year.

I saw it as I was walking back to the Westin from the convention center with my CTO after the first day of the conference. We were discussing the day's events, and what we would be doing that evening. Then I froze in my tracks, and asked him to hang on a second, so I could walk back and see if I saw what I thought I saw.

You know how sometimes you see something amazing and it takes a few moments to appreciate its gravity? So it was with Lobby:



You Should be a Conference Guide


I've had a couple of weeks to reflect on my RailsConf experience, and now that I have, I can safely say I enjoyed this year's RailsConf more than any previous year.

I started out thinking that this was largely because I was giving a talk I was already comfortable with, so I could relax. I'm sure that's part of it. And another huge part was no doubt the wonderful curation of the program by the program committee. But I think the single largest contributing factor to my enjoyment of RailsConf was my last-minute decision to volunteer as a guide, and I sincerely hope that everyone reading this considers doing so at their next conference.


Talk: "Humane Development"


Conference: RailsConf 2015
Location: Atlanta, GA, USA
Dates: 4/21/2015 - 4/23/2015

Agile. Scrum. Kanban. Waterfall. TDD. BDD. OOP. FP. AOP. WTH?

As a software developer, I can adopt methodologies so that I feel there's a sense of order in the world.

There's a problem with this story: We are humans, developing software with humans, to benefit humans. And humans are messy.

We wrap ourselves in process, trying to trade people for personas, points, planning poker, and the promise of predictability. Only people aren't objects to be abstracted away. Let's take some time to think through the tradeoffs we're making together.


Humane Development (the shirt)


At this year's Ruby on Ales and MountainWest RubyConf, I gave the first versions of a talk about Humane Development. The talk was well-received, and folks seemed to especially enjoy several of the slides. After MWRC, Brian Wisti tweeted:

I have no idea what I'm doing when it comes to creating T-shirts, but since when has that ever stopped anyone? So, I give to you the Humane Development Teespring Campaign! They'll be available through a week from today.

While the URL on the back currently redirects to the Humane Development blog post, I intend to put together a small site explaining HD in more detail at that URL.

Anyway, if you're grabbing a shirt, thanks for spreading the message!

Speaking: Ruby on Ales, MWRC, Ancient City Ruby, RailsConf, and Full Stack Fest!


I normally try to make a post here about upcoming conferences ahead of time. Does 3 days notice still count?

This week, I'm looking forward to heading to Bend, OR to speak at my first ever Ruby on Ales, and then heading straight over to Salt Lake City for a repeat of last year's fun times at MountainWest RubyConf. I'll be sharing some thoughts on something that's become really important to me lately: Humane Development.

I realize it's late notice, so if I don't see you there, maybe we can catch up at Ancient City Ruby or RailsConf?

Lastly, I'll be heading to beautiful Barcelona in September for Full Stack Fest! I won't be speaking directly about Humane Development there, but on something closely related that I can't really write about right now.

I'm really thankful for the opportunity to spend time in the company of so many great people. 2015 is shaping up to be a busy year, but that doesn't mean I don't want to spend time at your conference, too — especially if you'll let me talk to your awesome attendees about stuff I really care about.

Let's talk.

Talk: "Ruby after Rails"


Conference: RubyConf 2014
Location: San Diego, CA, USA
Dates: 11/17/2014 - 11/19/2014

What happens to Ruby when Rails dies?

Ruby rode the Rails rocketship to worldwide renown. While a handful of us were writing Ruby code before Rails came along, most of us owe Rails a debt of gratitude for taking Ruby mainstream, allowing us to make a living writing code in a language we love.

But opinions codified in Rails are falling out of favor. We're not writing apps that do heavy server-side rendering. Our apps have complex domain logic that grates against "The Rails Way."

Is that it, then? Has Ruby entered its twilight years?


Humane Development


[Update: This post (and the philosophy it described) was formerly titled Human-Driven Development, but I've since realized that Humane Development is a better term to describe its goals, so it's been updated accordingly]

Since taking on my role at nVisium, I've been given wide latitude to influence company culture in ways I haven't experienced before. This is a great thing, but it means that if I'm unhappy with how things are going from a culture standpoint, there's a pretty good chance that I'm directly to blame.

That's a lot of pressure, so I've been doing a lot of thinking. The bulk of my thoughts keep relating back to something I'm calling "Humane Development." I'd like to share those thoughts with you, since you are (most likely) a human.


In Defense of Alias


As some of you already know, I've recently started a new job as Director of Engineering at nVisium.

One of the first few things nVisium requested of me was to develop a coding style guide, so our code would read more consistently. Naturally, I used the community-driven guide maintained by Bozhidar Batsov (author of RuboCop) as a starting point, but ended up making my own tweaks (style is subjective, after all!).

Thanks to the magic of git diff I now have a record of styles I feel have gotten an unnecessarily bad rap, and I want to talk about one of them today: I prefer alias over alias_method.


Looking for a previous post? Check the archives.