SNMP in Elixir


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.


Talk: "Curmudgeon"


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.


Talk: "Don't"


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.


You're Already a Programmer


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.


7 Lines Every Gem's Rakefile Should Have


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.

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.

The Willfully Ignorant Development Process


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."


On Cancer


A hallway I'll remember.

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."


Anyone Interested in ActiveRecord Hackery?


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.


I Found My Next Job, and It Surprised Me


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 "prima-donna" [sic], to those of being snarky, to the (completely unwarranted) accusation of brilliance, 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.


ActiveRecord.where.not(:sane => true)


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.


On Snark


snark [snärk]

  1. 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 to be.

So, what happened?


Interviews are Broken


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:

  1. Doing eight or nine interviews in a day is insane. Don't ever try it. Keep to four or fewer.
  2. The standard interview process is fundamentally broken.

I want to spend a little bit of time unpacking why I think that second thing.


Upcoming Talks! (TLDR; RailsClub, RubyConf)


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 entitled "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 Miami!

Looking for a previous post? Check the archives.