Intellij IDEA: Run goimports on file save

goimports is a Go tool to remove unused and add missing imports. It also formats your code the same as go fmt.

This is one solution for running goimports when saving *.go files in Intellij IDEA. If you have a better way (not involving snark about emacs), please comment.

Assumptions

  1. You have goimports installed. If not, install with:
    1. go get code.google.com/p/go.tools/cmd/goimports
  2. You’re probably using the golang plugin. That plugin isn’t necessary for this goimports-on-save business, but if you’re using Intellij to write Go code then you might as well use the plugin, too.

Big Picture

  1. Create a shell script to run goimports against the incoming file name if it is a .go file
  2. Add an external tool to Intellij that runs that shell script against the current file
  3. Record a macro that runs that tool and then saves the file
  4. Override ctrl/cmd+S with that macro

Details

1. Create the shell script, like so:

#!/bin/sh

if [[ $1 == *.go ]]
then
  goimports -w $1
fi

2. Add a new external tool to Intellij

  1. ctrl/cmd+, to open up Settings
  2. Filter on “external tools”
  3. Click the “+” icon to add a tool
  4. Name the tool, uncheck “open console”, paste the full path to your shell script in the “Program” field, and add $FilePath$ in the “Parameters” field.
  5. Save the tool
  6. Optionally, in Keymap, give this a keyboard shortcut
  7. This will now show up in the “Tools” menu

Screen Shot 2014-03-29 at 6.31.21 PM

3. Record a macro that runs the tool and saves the file

  1. “Edit” menu — “Macros” — “Start recording macro”
  2. “Tools” menu, then click your new tool
  3. “File” menu, then “Save all”
  4. Finish recording your macro, and give it a name, such as “go_imports_on_save”

4. Override ctrl/cmd+S with that macro

  1. ctrl/cmd+, to open Settings, then filter on “Keymap”
  2. In the keymap, filter on your new macro name, such as “go_imports_on_save”
  3. Double-click it, select “Add keyboard shortcut”, and then hit your normal save combination on the keyboard, such as ctrl/cmd+S
  4. It’ll prompt you to remove the default. Accept it.

That’s it. Now, when you save your .go files, goimports will run and overwrite the contents of your editor. All other files are left alone.

Hat tip to this stackoverflow answer for inspiration.

 

Ice Ice Baby

In Defense of Silly Programs

To learn a  programming language, you must either

  1. Write a compiler for language
  2. Write programs in the language

A handful of canonical first-programs have risen in the past few years. TODO lists and Blog Engines are popular because they’re easy enough to start and difficult enough to cover a non-trivial swath of a language’s ecosystem such as documentation, packages/modules, build systems, package manager, support network, and so forth. They also generally require integration with a database, which at least in most OO languages can lead to understanding at least one major framework and consequently that framework’s abstractions, typically ORM-y, for interacting with a database. This is all good stuff.

We choose first-programs such as these because they feel productive and non-wasteful. At the end, we may have something that we will actually use. Perhaps someone else will use it. We sometimes bridge what we know with what we want to know: “I will rebuild my  years-old Java app in Erlang.” Or we are ambitious and think “As my first program, I will write a peer-to-peer multicast semiotic real-time high-frequency-trading low-latency chat server with transactional semantics and fault-tolerant properties.”

All of these are valuable and valid.

When I started learning Go, I started with the Go Tour, “How to Write Go  Code”, and the FAQs. I documented my learning. I picked through the language spec and Effective Go and at that point needed to stop reading and start coding. But what to build?

I was driving to the pizza shop when Ice Ice Baby played on the radio. The thought came to me that this song probably had some great Ruby Gem  names. And just like that, Gemmer was born.

Gemmer is a stupid program. In short, it accepts an artist and song name and uses the lyrics of that song to suggest new names for your Ruby Gems.  It’s the most impractical and useless  thing I’ve ever written, if one defines practical and useful as “something that myself or others will use in service of a real problem.” You should know that “bacon” is taken, but “harpoon” is currently available.

Here’s the thing: I had a lot of fun writing it (Ice Cube’s “No Vaseline” lyrics still make me laugh), and I covered a fair amount of ground in the Go ecosystem beyond the contents of the Go Tour:

  • io (file and http)
  • regexes
  • command line flags
  • custom Sort types
  • unit testing
  • xml and json marshaling/unmarshaling
  • Resources such as http://golang-examples.tumblr.com/ and https://gobyexample.com
  • How to read / use Go’s package documentation
  • A somewhat manicured list of projects at http://code.google.com/p/go-wiki/wiki/Projects
  • Gowalker and Gosearch

Silly programs are not a waste of time. In fact, I’d argue that they create an environment conducive to early-stage learning because of the liberation that comes with knowing that the only point is to learn. The one significant downside is that we require critique in order to grow, and a program such as this, tossed into the void, will likely not encourage such feedback. That’s OK, though, because these silly getting-started programs are first steps that help build an understanding of the ecosystem which you apply to future, more serious projects.

Fun and joy are essential ingredients for learning. If TODO lists and Blog Engines are your thing, great. If not, I encourage you to dispense with the notion that programs should be useful and important. If you’re writing code, you’re probably learning, and that will be more valuable than the binaries you produce.

2013 in Review; What’s Coming in 2014

Preview

New job, sold 2 houses, attended some conferences, read a lot, learning banjo, learning Go, excited for 2014, preparing for 2015. Be kind.

New Year, New Job

In January 2013, I made a decision that folks close to me thought was at best questionable, at worst just plain stupid and foolishly risky, and to one, made me a communist-slash-terrorist-slash-socialist-slash-anti-American: I left a fulfilling, stable job, working with a fantastic team, to take a temporary 2-year stint working for the U.S. Government.

Why? I believe in the organization’s mission and want to contribute to software, systems, and teams that protect American consumers. In addition, I consider this an opportunity to both serve my country and also to learn an incredible amount in a relatively short period of time.  During the first year here, I got my hands into a bunch of tech: Python, Django, Postgres, MongoDB (don’t hate, you meanies), a smidgen of Clojure and coffeescript, and AWS.

Mostly, though, the areas in which I’ve learned are much different from what I expected. I took this position to code… but now I don’t write much production software. ‘Tis true, that old saw about “software is easy; people are hard.” Writing software for the government is no more or less difficult than writing it in the private sector. However, delivering software is more so, in my experience so far. I’ll devote considerable energy in 2014 toward reducing the friction that exists for shipping code in my organization.

I’ve been extraordinarily blessed in my career to work with fascinating, talented people. I’ve worked for 5 different organizations since graduating college, and at each one I’ve been surrounded by a cast of characters as rich as a Dickens novel. The new job has ratcheted this blessing to 11. You can see some of what we’re working on at http://cfpb.github.io/

This new job presented for my family and me a challenge we hadn’t yet faced:  my prolonged absence. From January 13 to March 8, I spent my weekdays in Washington, DC and came home on the weekends. None of us were prepared for how this would disrupt our relationships, routines, emotions, energy, commitments… the stuff that makes a family a family.

I was not prepared for how this DC immersion would attack my senses.

Two and a half years prior (May 2010), I had left an office job and begun working remotely, from home. Working from home is glorious. What happens after a bit of it, though, is that the volume knob of life goes way down. No office chatter. No stupid shirt Fridays. No casual jeans day (because when you work from home, every day is shorts and slippers day). No traffic, no road rage, no highways, no traffic jams, no anticipating the moves a tractor-trailer is going to make 1 mile down the road and how can you avoid it. You wake up, you get coffee, you sit in your perfect chair in front of your tailor-made computer, you get to your work, and you get so deep, for so long, that the world evaporates and all that’s left is you and the things you’re building. The silence and focus become addictive.

Then, in January 2013, I left my Hobbit-like existence to spend 2 months in D.C. I was unprepared for the assault. The people. The noise. The aggression. The ambition. The traffic and  food and loud hotel doors and rats and microwaved leftovers and dudes in trench coats and roads where everyone double-parks and $10 lunches and 2 months without a single night of sound sleep and all you want is an hour of peace and quiet and the only way you get it is too much bourbon but at least you got some sleep.

And also: The Coffee at Swings and the bagels with lox at G-Street. Nights in the hotel lobby with colleagues I admire and for whom I now harbor considerable affection. Walking past the White House twice a day. Watching people live their lives. Seeing people dancing in the streets. Gray and black squirrels playing in Lafayette Park. Bicycles everywhere. Field trips.

I needed it. At the time, it was incredibly uncomfortable. I came to appreciate it, though, as necessary. I had become brittle, and that brittleness needed breaking apart. My family and I got through it just fine (after a while), and I’m grateful to have stretched those muscles.

A Journey Concluded

When my first daughter was born, 10 years ago, I told my wife that one quality I wished for our daughter was a willingness to take risks. It was therefore important that we model that behavior. Three months later, on the eve of my 29th birthday, my wife and I purchased our first investment property. The next month, we bought another. And by March of the following year, we bought a 3rd. We anticipated that in time she would come to understand the risk we took, the reasons, and the rewards. This was 2003-2004.

We sold 1 in 2006, and since the Summer of 2012 the remaining 2 have required considerable time and energy as we  prepared the houses for sale. Though I do not regret having become a landlord, I am thankful to be done. The sale of these houses in 2013 represents for our family a considerable winding down of external commitments and a renewed ability for us to focus on us. I am grateful for both the homes we provided to others, and now for the time I’ve gotten back with my wife and kids.

As for my 10-yo and her risk propensity… it’s a work in progress. She rode her first big(ish) coaster this summer and was terrified the whole time, but she’s since forgiven me. Still, she loves to sled down “Death Mountain” (our neighbor’s yard), so I consider it a win.

Disengagement

Contributing to OSS projects such as MXUnit and CFMongoDB over the last half-decade has brought with it rich friendships with amazing people across the world. Regrettably, in 2013 with a new job and significant time spent with our investment properties, I effectively disengaged from the development community I’ve been so close with for the past 5 years. I haven’t contributed anything noteworthy to either of those projects; I quit blogging; and I gave no conference presentations in 2013.

The first was largely because I no longer write or use ColdFusion in my day job (this is not an excuse, but an explanation however lame). The second is laziness. And the third was intentional, which bears details. If you’ve ever delivered a presentation, you know that it’s an iceberg: a 30-60 minute presentation can require 30-60 hours of preparation. For me, presentation == preparation. I once gave the same talk twice, and it was miserable. I know people who can deliver the same thing year after year, with tweaks. I respect that, but it ain’t me. Consequently, knowing that 2013 would be devoted to a new job and the sale of our rentals, it seemed irresponsible to commit to a presentation. Something would have had to suffer, and it could not have been work or those properties. Thus, it would’ve been the presentation that suffered, and it’s not fair to any audience member to knowingly stand on stage knowing you phoned in the prep. I adopt the Shaun T Insanity philosophy here: Go Big or Go Home.

I hope to re-engage in some technical communit(y|ies) in 2014. Software comes and goes, but relationships endure. I don’t yet know what this looks like, though I’ve been noodling over the idea of starting a DevOps / Continuous Delivery oriented Meetup in my area. One thing is certain: I need to commit to contributing to open source more in 2014. I ask you to consider doing the same.

Conferences

Not only did I not present, it’s the first year since 2008 that I haven’t attended a conference related to Adobe technologies. Adobe MAX, cf.Objective… damn, I miss you people!

However, as the world is small, I attended 2 new-to-me conferences this year and at both of them I connected with people from my CFML life.

In July, I attended SeleniumConf in Boston. Fantastic conference and venue! All of the videos are available, and I can’t say enough good things about Noah Sussman’s talk on Continuous Improvement and Jason Leyba’s keynote on migrating to Selenium 2.0. Jasons’s presentation was ostensibly about Selenium, but really it was about team and organizational culture.

An after-hours highlight was hanging out with Bob Silverberg and some folks from the Mozilla QA team…  sharp people and a pleasure to talk with. Catching up with Bob and Brian Rinaldi near Fenway was also cool. Saw a big-ass rat on the street, which reminded me of my time working in Baltimore City. Cities should have contests involving their rats.

In September, I witnessed first-hand what the hype was about for Strangeloop. It did not disappoint. Notable for me were Jen Myers’ keynote on “Software Development for Everyone”, which is one of the most inspirational talks I’ve ever seen, and Kyle Kingsbury’s talk on database partitioning, where he demoed Jepsen.

The conference party was held at The City Museum, which is one of the most amazing places I’ve visited. I was blessed with the company of some of my brilliant/fun/hilarious work colleagues as well as the inimitable Mark Mandel and Sean Corfield. If you’ve been to the City Museum, you’ll understand when I say that the day after, every hole in the ground I saw I wondered, “Can I slide down that?”

My notes on the presentations I attended are at Strangeloop and Selenium Conf.

In 2014, I’d like to attend Philly ETE, Velocity, and potentially Oscon. If FlowConSF goes to 2+ days, I’ll consider that, as well.

One highlight of the year wasn’t a conference, but a presentation: Gene Kim presented at the Washington DC Continuous Delivery Meetup (my notes), and the next day he came to speak at our office. Fantastic! We talked, among many other things, about improving the relationship between development and security teams. While I certainly don’t expect the kind of transformation that the “John” character experiences in The Phoenix Project, any movement in the right direction is most welcome. Gene pointed me to “The amazing Twitter Infosec Presentation”, which I recently watched. Notes and links are here.  Gene, if you’re reading… thanks!

Reading

Having read a fair amount this year, a few titles will stick with me.

Two others that I’m in the process of reading are The Field Guide to Understanding Human Error and Release It! The Field Guide has been a worldview-changing book, and Release It, even though I’m only 1/3 or so in, is shaping up to be one of the most important technical books I will likely read in my career, at least with respect to shipping high-quality software and building resilient environments.

What’s Coming in 2014

At work, I’ll continue to focus on automation, moving toward continuous delivery, and reducing the time from idea to providing value in production. This requires building safe, secure, robust operating environments.

In general, this year I intend to focus on learning. It sounds strange to say that; after all, shouldn’t we always be learning as much as we can? Obviously. However, life has a way of “just happening”, and before you know it half a year has gone by and you realize you’ve been heads-down on a project, grinding away day after day, and you pull your head up and go “What the hell happened?”

I intend to mindfully, deliberately emphasize learning. In practice, this means setting aside scheduled, sacred time at some point in the day — most likely early morning and mid evening — for working on personal projects and interests.

For tech, I’m currently very excited about Google’s Go. My thinking is this: at work, I get exposed to a fair amount of useful tech… Python and Clojure in particular. So in my own time, I’d prefer to learn something that I certainly won’t see during my day job. This helps expand perspective, keep nimble, and puts another potential solution in the toolbelt. So far Go has been fun to learn, seems to be very well designed especially with respect to concurrency abstractions, and is growing a passionate community.

For personal joy, I finally picked up a Banjo. Why? Some of this. A bit more  of this. But mostly, this.

I’ve been threatening asking my wife to get me a banjo for Christmas for the past few years, and each year… disappointment. Before Christmas this year, I inadvertently saw an Amazon order email with “Banjo” in the subject. It was as if I were Ralphie, and I had just spotted a Red Ryder BB Gun in my parents’ closet. I was psyched, and then it hit me: “if my dear bride bought me this thing, then I better not let her down. I gotta learn it.” During the subsequent days I spent hours reading and watching videos about how to play the banjo so that I’d be ready for December 25th. A few days pass, and this little box arrives, addressed to me. I open it, and… it’s a banjo Christmas tree ornament. Yet another letdown.

By this point, however, I was committed. So, me and a Deering Good Time banjo are gonna make racket and annoy everyone in the house. Even our new dog (yet another life change for us this year). 

Preparing for 2015

As I wrote at the beginning, the new job is term-limited. This will have me out pounding the pavement, at 40 years old, in January 2015. It’s obviously imperative to be preparing for this transition now, and not a month or week prior. While in general I believe things generally work out in the end, fortune favors the prepared mind. My current fear, as silly as it sounds, is that I’ll continue to gain experience that’s only valuable in my current organization or one like it. That’s not a smart position for anyone to put themselves in.

So, what to do? It’s a work in progress, but at the least I think it looks like this:

  1. Find ways to help other people do great work. This includes
    1. contributing more to open source
    2. engaging in one or more technical communities
  2. Devote time every day to learning interesting things that aren’t necessarily directly applicable to my current position

Outro

Never have I been more aware of and humbled by my incredible privilege in this world. To be well-educated, live where I live, work where I work and have worked, known who I know and have known. I want to do better about appreciating this and not taking it for granted.

Despite daily reminders of the horrors of this world, we live in amazing times and would do well to remember this and to honor it. Be well, do good, be kind. Happy 2014, everybody.