≡ ≡

I'm Wynn Netherland. I follow Jesus. I dig APIs, dotfiles, and text mode. I work at GitHub. Folks call me @pengwynn.

I don't know jack (yet)  

My head is still spinning from Tim Caswell's lightning talk at Big Ruby where he showed off jack, his new programming language. (I'll post a link to the video when it's available. The gamepad-driven demo was amazing.) The simple yet powerful syntax looks like an excellent starter language for new programmers. I'm intrigued especially at the function syntax:

{arg1, arg2, arg3| body } is Function --> true

I want to see how my seven-year-old picks up something like this since she's shown interest in Ruby already.

How to get great support as a technical user

One of my favorite parts of working at GitHub is helping our Supportocats answer support requests. Since I focus mainly on the GitHub API, I get to work with our more technical users. I've shopped at BestBuy enough to know what it's like when you think you know more than the staff.

Nearly nine months of helping technoweenie pursue Inbox 0 at the API Help Desk has changed the way I ask for tech support for other products and services.

Use the right channel

In the software industry, many of us have friends who have founded or work on some of our favorite services and tools. With those personal relationships, it seems easier to shoot an @reply or DM on Twitter. For site down questions, that's often good enough, but 140 chars just isn't conducive to describing (much less troubleshooting) most issues.

For GitHub, our support form makes it simple to reach out and say Halp! Sending an email to support@github.com works, too. Including "API" in the subject line routes you straight to the API team.

Many open source projects have mailing lists, issue trackers, and IRC rooms to talk about issues. Find the right channel before you send a flurry of questions to a project maintainer.

Get to the point

Once your request makes it to the top of the support queue, it has to be grok'd by a human. Verbosity is your foe here. The more you write, the longer it takes to distill your words into your actual issue. Not just once, but each time your ticket is passed to someone else on the team, it has to be reinterpreted.

Include details

Your chances of getting speedy help go up substantially if you can avoid that dreaded "more info please" follow up. Photos, screenshots, URLs, stack traces, and other facts help speed up the six stages of debugging. If you're calling a HTTP API, the developer has a hard time refuting curl output.

Don't piggyback issues

Many request tools thread messages by subject or ticket number. You might be tempted to reply to that six month old email because the person who helped you last time seemed to know what they were talking about. Unless the issue is directly related, chances are you're delaying your new ticket because there's more previous conversation to wade through on the other end.

Don't be insecure

Most support queues use plain old unencrypted email. Please, please, please never send passwords, API tokens, credit cards, or other sensitive information in email. Always mask or omit sensitive info in email. Be sure to scrub that stack trace or log snippet you're including, too.

Be classy

You might have justified rage because a certain feature has been long broken and no one seems to care. Just don't let frustration undermine your own cause. Name calling and insults might make you feel better in the moment but it won't bring you any relief. Most support folks are extremely professional. They like to help or they wouldn't do what they do.

That said, humans are more inclined to help when they're treated like, well, humans.

Oh yeah, we're hiring Supportocats.

Project badges: ease or sleaze?

Erik and Mislav have an interesting discussion going on a Faraday commit on the merits of those badges in GitHub repository READMEs.

I use them in a few of my projects, but lack of consistent size and Retina support have me leaning towards removing them.

Project badge screenshot

What's your take? Ease or sleaze?

Rdio-cli does lyrics  

In another dotfile discovery, I ran across makeitpersonal in Artem's dots. makeitpersonal makes it easy to fetch lyrics in plain text using curl. Naturally, I didn't waste time adding this to rdio-cli. By default, it looks up the current track, but you can override artist or song title, the former being quite useful for covers.

$ rdio current
Now playing: That Old Time Feeling / Rodney Crowell / This One's for Him: A
Tribute to Guy Clark

$ rdio lyrics
Sorry, We don't have lyrics for this song yet.

$ rdio lyrics --artist="Guy Clark"

And that old time feeling goes sneakin' down the hall
Like an old gray cat in winter, keepin' close to the wall
And that old time feeling comes stumblin' up the street
Like an old salesman kickin' the papers from his feet

And that old time feeling draws circles around the block
Like old women with no children, holdin' hands with the clock
And that old time feeling falls on its face in the park
Like an old wino prayin' he can make it till it's dark

And that old time feeling comes and goes in the rain
Like an old man with his checkers, dyin' to find a game
And that old time feeling plays for beer in bars
Like an old blues-time picker who don't recall who you are

And that old time feeling limps through the night on a crutch
Like an old soldier wonderin' if he's paid too much
And that old time feeling rocks and spits and cries
Like an old lover rememberin' the girl with the clear blue eyes

And that old time feeling goes sneakin' down the hall
Like an old gray cat in winter, keepin' close to the wall

You can install rdio-cli from Rubygems or from the source on GitHub.

Bootstrapping consistency  

One of the best features of Rails is its consistent project layout. Thoughtbot recently shared how they use a ./bin/setup script to bring consistency to the project setup.

Regardless of the bin/setup file’s contents, a developer should be able to clone the project and run a single, consistent, reliable command to start contributing.

At GitHub, we use script/bootstrap, but the idea is the same — a consistent user experience to get from zero to productive on any new project. Whether I'm writing docs, extending GitHub with service hooks, or hacking our internal support tools, I know I can just clone the repository and run script/bootstrap to jump right in. Thanks to a patch from Matt Emborsky, this works for my dots, too.

We also don't stop with the project bootstrap. Our projects normally have script/test for running the local test suite, script/cibuild for running tests on the continuous integration server, as well as the usual script/server, and script/console scripts where applicable.

As a result, I spend less time thinking what to run and just run.

Open Government book now open source

As a contributor to the Open Government book from O'Reilly a couple of years ago, I was thrilled to see Laurel and Daniel release it on GitHub as part of the #PDFtribute to Aaron Swartz.

Aaron contributed Chapter 25 in which he argues that government transparency doesn't go far enough:

Perhaps even more useful than putting government documents online would be providing access to corporate and nonprofit records. A lot of political action takes place outside the formal government, and thus outside the scope of the existing FOIA laws. But such things seem totally off the radar of most transparency activists; instead, giant corporations that receive billions of dollars from the government are kept impenetrably secret.

You can read this chapter and the entire book in PDF, ebook, and mobile formats.

TIL: Easy UPSERTS in MySQL

I've long loved upserts in MongoDB, but I suppose my desire to keep my SQL vanilla for Rails caused me to overlook easy upserts in MySQL using ON DUPLICATE KEY UPDATE:

INSERT INTO table (`user_id`, `some_expensive_count`) 
  VALUES (1, 333333)
  ON DUPLICATE KEY UPDATE `some_expensive_count` = 333333;

If the INSERT would cause a duplicate value in a PRIMARY KEY or UNIQUE index, an UPDATE is performed. Easy peasy.

TIL: \A > ^

Whether it be in Vim, JavaScript, or Ruby, ^ is a go-to pattern for matching the beginning of a line. As Ben Toews schooled me today, if you're needing to match the beginning of user input, it's better to use \A which matches the beginning of a string:

>> "javascript:alert(123);\n/*\nhttp\n*/" =~ /^http/
26
>> "javascript:alert(123);\n/*\nhttp\n*/" =~ /\Ahttp/
nil

There's also \Z, something to keep in mind the next time you use validates_format_of in Rails.

vim-sensible  

A sane starting point for your .vimrc from Tim Pope, one of the community's most prolific plugin writers.

Think of sensible.vim as one step above 'nocompatible' mode: a universal set of defaults that (hopefully) everyone can agree on.

Looks like a great starting point to build upon by cherry-picking from other people's Vim setups instead of starting with an opinionated setup and whittling down from there.

dotfiles.github.com  

As I've written previously, I've learned a lot just by digging through dotfiles on GitHub. Adam Jahnke and I set up a guide to help others looking to fork, share, and mine them for tips and tricks.

We're starting small, but we aim to be a curated list of the best dotfile projects, files, and one liners, which we'll dispense at the @octodots Twitter handle.

Contextual TODO list counts in your zsh prompt

One of the nuggets I picked up from Zach Holman's dotfiles was putting a count of my todo.txt items in my right side zsh prompt. That little number now nags me any time I use my terminal.

Then I had the idea of displaying contextual counts for all those TODO, FIXME, and HACK notes we often use in our projects. With some help from Jesse, my dream has come true:

Now, if I'm in a project with any of those custom notes, the counts appear in my right side prompt in addition to my regular personal todo.txt tally. Check the function in my dotfiles repo if you're interested or have ideas on how to improve it.

Looking for more? View the archives or grab the feed.

You might like