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:
- 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.
- Come up with some convoluted way to represent this data using ActiveRecord
associations, even though it would almost certainly mean I'd find myself
has_one somewhere (ick), and probably still wrapping the whole thing
up to avoid using
accepts_nested_attributes_for in forms.
- 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.
Today's post is going to be short and sweet. Because I find myself using a few
settings in almost every single Rails app's
config/application.rb, I want to
share them with you, along with the rationale for each.
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
You know how sometimes you see something amazing and it takes a few moments to
appreciate its gravity? So it was with Lobby:
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
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: 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.
It's been a busy few weeks, with a visit to St. Augustine to speak at
Ancient City Ruby followed by a much-needed
vacation with my family. While I was on vacation, the results of a couple of
recent podcast interviews have gone online, so I wanted to share them here. In
both cases, we spent a good deal of our time talking about
Over the weekend, I pushed up an early version of the new Humane Development
site! I'm really excited about this, because it
now means the URL on the back of
the shirt has somewhere better to
point. In related news, if you're going to Ancient City Ruby this week, or
RailsConf next month, come find me for one of these sweet stickers:
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
Anyway, if you're grabbing a shirt, thanks for spreading the message!
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
I realize it's late notice, so if I don't see you there, maybe we can catch up
at Ancient City Ruby or
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.
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?
[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
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.
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
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.
Conference: Burlington Ruby Conference
Location: Burlington, VT, USA
Dates: 8/2/2014 - 8/3/2014
My keynote from Burlington RubyConf 2014 deals with big questions:
- What happens to Ruby if Rails dies?
- What makes us care so much?
- Just how long can I avoid laughing at a cat video in my own slide deck?
Not too long ago, I finally got around to trying out Elixir. It's amazing.
Seriously, you should try it out. It has this peculiar and compelling quality
of making me feel like I'm a better programmer than I am. It's that good.
Anyway, this post is not about how awesome Elixir is (very). Over the past few
days, I've been spiking out a small app to demonstrate some Elixir concepts to
my team. As it happens, the app I chose to build needed to do SNMP polling. I
knew that Erlang had really robust support for SNMP (it is, after all, a
language designed by a telecom company!), so I expected this to be simple.
Turns out that it wasn't as simple as I expected, as the information that was
out there was mostly geared towards experienced Erlangers (which I am not), and
seems to assume you want to run your own SNMP agent (which I do not). As such,
I thought I'd contribute what I've learned.
Conference: RailsConf 2014
Location: Chicago, IL, USA
Dates: 4/22/2014 - 4/25/2014
Rails has opinions about how we should organize code, interact with a database,
write tests, format URLs... just about everything. These conventions, the
wisdom goes, free us up to focus on the specifics of our application.
"Convention over configuration" becomes our mantra as development hurtles
forward with startling speed.
At some point, we stop. We take stock of what we've built, and it's a mess. How
did we get here?
Turns out, the decisions that Rails made for us had consequences.
Looking for a previous post? Check the archives.