Having ample documentation and solid test coverage for your gem is great. But
nothing beats dropping into a console and just playing around.
Make it easy on yourself, and easy on your users. Add these 7 lines to your
task :console do
require 'my_gem' # You know what to do.
Now, a suitable playground is only a
rake console away. For bonus points, if
your gem requires a bit of fixture data to do anything useful, you can stage
some data before starting the console. Even users who aren't adept at writing
tests should be able to give you steps to reproduce problems using this
console, in a clean environment free of their app code and other gems.
Almost a year and a half ago, I wrote a post entitled
"The Greenfield App Continuum". It
didn't get a ton of attention at the time. Then again, maybe it didn't really
deserve much attention. It was heavy on theory, and light on application.
That's because, at the time, it was only theory to me. That theory being: If
we start building an application as though we are completely ignorant of the
constraints our persistence layer will eventually impose on us, we'll end up
with an appication that's more pleasant to develop as a result.
I can't pretend that I'm the only person who's ever had that thought. Heck, even
a comment on that
article points to a book entitled
"Applying Domain-Driven Design and Patterns", and in Domain-Driven Design,
"Persistence Ignorance" is a thing. With a name and everything. However, it may
be telling that the rest of the book title is: "With Examples in C# and .NET".
So, when I was writing that post in 2012, even as I knew what I was writing
wasn't an original thought, as a Ruby (and Rails) developer, it certainly
And, again, at that point, it was just theory, to me. I hadn't tried it. Since
then, I have. And I've been meaning to write about that for a while now.
I'm calling it "The Willfully Ignorant Development Process."
This is the hallway to the Appriss on-site clinic. It's at
the end, on the left. I'll never forget walking down this hallway on Wednesday
morning, a week before Thanksgiving, because at the end of it, I found out that
I had cancer. Or, more accurately, "a highly suspicious 2.1cm mass in the
left testicle," according to the ultrasound.
But even then, deep down, I knew that was a nice way of saying "you've got
Conference: RubyConf 2013
Location: Miami Beach, FL, USA
Dates: 11/8/2013 - 11/10/2013
I've been maintaining a bunch of gems that integrate deeply with ActiveRecord
for going on 5 years now. I'm really proud of some of the things I've built, and
glad that some of them have even made their way into Rails core,
in a manner of speaking.
That being said, chasing a moving target is tough, and apart from Ransack, which
the good folks at Spree Commerce use, and have
taken up maintaining through the heroic efforts of Ryan Bigg, there's been very
little in the way of help from the large community of users. All of that has
conspired to result in a very exhausted me. I feel a fairly huge sense of
responsibility to maintain some of these gems, even though in many cases I
don't use them myself anymore, and I haven't been doing a great job of it,
lately. When I find myself with some spare time to hack, and instead of working
on things I'm interested in, I'm fighting a losing battle against ActiveRecord,
and resenting the time spent, it's time to optimize for happiness.
A month ago, I wrote a
post about being funemployed.
It marked the beginning of a month-long experiment: an alternative approach to
employment. Instead of applying anywhere, I listed the traits I was looking
for in my next job, and linked to the post via Tweets and on Hacker News. I
wasn't sure what to expect at the time, but I was hopeful.
The experiment was more successful than I could have dreamed, resulting in
greater than 40 companies reaching out. The list included young companies
looking for a CTO, companies you've never heard of, some you most definitely
have, and a few I've no doubt you'll be hearing more about, soon. It also
provoked mixed reaction. From accusations of being a
to those of being snarky, to the (completely
unwarranted) accusation of
an experiment like this brings its share of commentary.
I've learned a good deal from the experiment, I think, but this post is not
about that. Right now, I want to share some news I'm excited about.
In a couple of weeks, I'll be joining the team at
Appriss, which just happens to be in Louisville.
TL;DR - ActiveRecord: This is yak country.
One of the really "fun" things about writing libraries that extend ActiveRecord
is that I'm constantly running up against interesting problems that require a
choice between multiple less-than-stellar options to resolve. One such case
arose not too long ago when working on Rails 4 compatibility for Squeel. Since
the problem is niche enough (and my chosen solution weird enough) that I don't
expect anyone else to write about this, I figured I may as well. I have no idea
if you'll find it useful. Read on at your peril.
- snide and sharply critical comments.
Normally, I'd say that snark is a term that mostly applies to places like
Hacker News. Or, well, let's just say any comments thread on the Internet, ever.
But today I was talking with a friend, someone whose opinion I really respect.
He shared with me that some of my recent posts on hiring have been interpreted
by others as snarky. He's a nice guy, so he didn't say it, but didn't need to:
he thought they came off that way, as well.
Before I go any further: I'm sorry. Certainly, this is my blog, and I can say
whatever I want here, but snarky things are not what I want to say. Critical?
Sure, there are things that deserve criticism. But not snarky. That's not the
kind of person I normally am, and it's definitely not the kind of person I want
So, what happened?
Since last week, I've lost count of the number of interviews I've done, thanks
to a well-received article about my
recent "funemployed" status.
Through this process, I've grown to recognize a couple of important things:
- Doing eight or nine interviews in a day is insane. Don't ever try it. Keep to
four or fewer.
- The standard interview process is fundamentally broken.
I want to spend a little bit of time unpacking why I think that second thing.
Next week, I'm traveling to Moscow, to meet new people and speak at the
RailsClub conference about ActiveRecord! I'm
super-excited, as I've never been to Russia!
While we're on the topic of conferences, I recently got confirmation that I'll
be speaking at RubyConf. The talk's
"That's Not Very Ruby of You", and
we'll be chatting a bit about not-very-Rubylike Ruby code, and maybe even some
things that are very common in Ruby, but maybe... shouldn't be?
Have a pet peeve you'd like to see covered? Hit me with it in the comments, or
contact me on Twitter. Hope to see you in
If you read this word, and you write software, then you probably considered
whether I meant computational complexity, as commonly expressed using big O
notation by mathematicians, computer scientists, and those who just want to
sound really smart.
Otherwise, (again, if you write software) you might assume that I am referring
to cyclomatic (or conditional) complexity, a measure of the independent paths
through a computer program.
Otherwise, you probably just thought that these first few sentences are a great
illustration of complexity, and wondered why don't I just say what I'm trying
to say, and you'd be right.
If you're still reading, then I'm about to get to my point.
In the business world, the concept of an "elevator pitch" is well known. The
idea is that you craft a short summary of your company or product, such that it
can be delivered in the span of an elevator ride. Embracing the constraint of
brevity forces you to figure out what really matters, and place your emphasis
Yesterday, I was asked to write what amounts to an elevator pitch for myself.
The actual request was to "write a summary in 3 or 4 sentences," but make no
mistake: it's an elevator pitch. I hadn't done so before, so it was an
interesting exercise. I gave myself a 5 minute limit so I wouldn't overthink it,
and this is what I came up with:
If you use Rails, you're probably already using at least
a few lines
of code I wrote.
I truly love writing code in Ruby, but can occasionally be persuaded to hack
in other languages. I speak on
technical topics and
optimizing for happiness,
which for me generally involves
I both contribute to and maintain
open source projects, and I've worked remotely on
my past three jobs, so I know how to act
as a capable and considerate member of a distributed team.
If you haven't written an elevator pitch for yourself, try it! It's the kind of
quick reflection that might just show you a "value proposition" you didn't even
realize you had.
In software development, we don't generally worry about unemployment. We're so
used to being in high demand that we have enthusiastically embraced a relatively
recent euphamism for the term, in fact: funemployment. The idea is that since
things will work out, we should enjoy the time off while we can. This was a
"luxury" I've never enjoyed. Since I had a paper route when I was 13 years old,
I've been steadily employed, never taking a break. 23 straight years of
Today marks the middle of my first week at Wantful.
Wantful is building a unique approach to gift giving -- something that fills the
gap between essentially exchanging currency (gift cards) with one another, and
picking a single gift that ends up getting returned, anyway. I'm really psyched
to be part of the team, especially since my work will be addressing a problem
I've encountered all too often, myself!
Side note: I'm visiting SF for the first time this week. If you happen to be in
the Bay Area, and would like to check out our digs and maybe say hi, we're
throwing an ice cream social tonight from
6:00 - 7:30! I'd love to meet you -- be sure to click the link above and let me
know you're coming.
Overtime. It's a word used often by those who are compensated for their hours
worked, and brings with it the expectation of an increased rate of pay in
exchange for the impact the extra time has on their personal lives. In the
software development world, most of us find ourselves working on a salary basis,
and instead discuss things like "work/life balance" and "crunch mode."
These are, of course, simply euphemisms we use to talk about the expectation of
Looking for a previous post? Check the archives.