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 Humane Development.
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 URL.
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 Development.
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 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.
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.
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.
Conference: MountainWest RubyConf
Location: Salt Lake City, UT, USA
Dates: 3/20/2014 - 3/21/2014
We all know that intelligent species learn from mistakes, right?
There's just one problem: Life is too short to make every possible mistake! Also, some mistakes are more costly than others. What's the ambitious learner to do? I'm glad you asked! I'm an expert at making mistakes, and I'm happy to share as many of them as I can possibly fit into a 45-minute time slot with you, my dear conference attendee!
We'll discuss a variety of exciting mistakes, ranging from the misapplication of metaprogramming techniques to letting emotions become barriers to new technologies to why it's a horrible idea to stretch a gel keyboard wrist rest across a room, even if it seems like an awesome plan at the time.
Recently, my friend Kinsey Ann Durham asked if I'd be willing to be a mentor for gSchool. I agreed, despite being unsure what to expect. I've never mentored someone in a "dev bootcamp" before. Yesterday, she introduced me to Kaylee Edmonson, who I'll be mentoring for the next 6 months. Kaylee asked if I had any advice for "a non-programmer entering the programming world," and I wanted to share my response to that question here.
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 project's Rakefile:
task :console do require 'irb' require 'irb/completion' require 'my_gem' # You know what to do. ARGV.clear IRB.start end
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 felt novel.
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 cancer."
Looking for a previous post? Check the archives.