Meeting Minutes for Everyone

This post proposes a system that can be used to document meetings in a simple and accountable fashion. It can be implemented using any kind of note-taking tools and is easily extensible.

Why you should take meeting notes

We spend a lot of our time dealing with each other. Most of this interaction is through meetings. Even so, people usually don’t take notes on meetings — they try to keep everything in their heads. Sadly, your brain is not the best place to store things. That’s why taking meeting notes — or meeting minutes, as these notes are formally called — is so important. It allows you to dump everything into a system that can be processed at your leisure.

Even so, how can you keep up with the pace of the meeting and take notes at the same time? That’s why having a system to handle minutes is a must.

A developer’s work is never done

The Tedium of Managing Code” by Lyza Danger Gardner is excellent (h/t @scriberty).

From the lede: “There’s a place motivation goes to die for web developers. It’s when something we have to do is simultaneously very, very hard and very, very uninteresting. You know, the corner of Hard and Boring Streets in downtown Must-Ship-to-Clientsville.”

To which I must add: word.

Our code base isn’t old by software standards, but in Internet years, it’s practically middle-aged. We used to be a monorail, but now we rock SOA, which is great!

However, we obviously have what any (every?) large-scale site has: cruft, dead code, junk drawer files. All those “ugh, I’ll clean this up later” helper methods, all that horrendously nested and specific CSS, so much clunky, janky javascript. We have it all. (You can be jealous, it’s all right.)

Improving your code with Android Support Annotations

If you haven’t heard of the Android Support Annotations library yet, you’re missing out on a neat new package that will help you catch bugs in your apps. Included in the library is a number of Java annotations, that will help Android Studio check your code for possible errors and report them to you. There are quite a few of them, so I only plan to go over a few of them here, but you should definitely check out the docs for more info about the rest.

@NonNull / @Nullable

@NonNull and @Nullable are probably the most basic of the support annotations, but also some of the most helpful! Annotate a parameter or method with either of these to denote if the parameter or method’s return value can be null or not, and voila, now Android Studio can give us a nice warning that we’re doing something unsafe.

Revisiting rails:update

Lately I’ve been revisiting some Rails apps which have been around for a while. These are Rails apps that started life somewhere in the 2.x era and are now on the latest (4.2.3 as of this writing), and they were upgraded in a series of steps over the past couple of years. So all that to say that these apps have been through a lot of changes.

When I’m doing Rails upgrades I tend to do the minimum necessary to get the app to the next version. Then I make some notes on things to revisit after the dust has settled. Sometimes those things happen, sometimes not. One thing I hadn’t done before is run rake rails:update on those apps. I had tried it a couple of times, but I would see a huge diff and shelve it for later.

But I think I was approaching it in the wrong way. Here’s what I’ve been doing lately:

1
2
3
4
bundle exec rake rails:update # and hit 'a' to accept all changes
git diff > ../rails_update.diff
git add . && git reset --hard # throw changes away
git checkout -b newify

After the Hero Comes

Don’t be a hero. Our work is about shared understanding, communication, and teamwork. I try very, very hard to never be a hero.

For those that aren’t familiar with the term Hero Coder, let me share. A Hero Coder is the one person that typifies the lone hacker trope. They work late into the night, all alone, and drop amazing volumes of code into your git repo each time they get on a roll. Unfortunately, nobody else on the team has an understanding of what’s going on in this new code. Your bus number is a little lower, your shared understanding has dropped, and the cost of supporting this coder’s work is unknowable.

This is why we do things like code review or pull requests, why we have demos, why we pair program. We’re on a team, and knowledge is not something to be hoarded.

StrongLikeBull - A Lesson in Recursion

&tl;dr;

I’ve created a new gem called StrongLikeBull that suggests what parameters to permit in your strong parameters configuration based on what request parameters a controller action receives.

After repeating the same task multiple times in a row, I start looking for shortcuts. The problem I was facing was how to configure Strong Parameters in our applications as part of a company-wide effort to upgrade to Ruby on Rails 4.2. There were a lot of controllers in the application I was configuring, and this quickly became a very tedious task. For each controller, I was configuring debugger lines in the controller action, examining the request params, and then manually figuring out how what the strong parameters format would look like. Then, given the strong parameter’s required field and permitted params, I could run the strong parameters expression against the request params and make sure I was getting the same output as input.

So after repeating this several times, I began to wonder if there was a better way. A Google search revealed nothing (perhaps I couldn’t figure out what exactly to search for). I also came across a more complex example: some of our api controllers get hit from external services, and we don’t necessarily know what params they are passing. Certainly some auditing was in order, but this also represented another strong case for the use of strong params. Finding no viable solution out there, I began to explore implementing my own.

Automating HiveServer/Hive Metastore Restarts After Lockup

Intro

At LivingSocial, one of the key components we use in the Hadoop ecosystem is Hive. I’ve been working here and seen us migrate from 0.7 up to (currently) 0.13. One of the problems I’ve encountered over the years has been HiveServer (1 or 2) or the Hive Metastore “locking up” – i.e. calls to the service just hang. Usually when this happens, someone from our warehouse team will go into the server and manually restart the init.d service (as we are not using Ambari or Cloudera Manager). However, depending on response times, this can cause issues when we have long running ETL jobs overnight.

This post addresses a new method I’ve recently discovered for emulating hive service lockups. These will probably be old hat for many java devs, but were new to me.