A few years ago we were bringing on board a large group of new developers to the team. Most had a light testing background, some exposure to git and no real pairing experience. It didn’t take long to realize the number of commits on our project slowed down dramatically. Commits still happened, but they were generally large coarse grained commits with hundreds of line changes across many files.

After some gentle nudging about checking in early and often I realized the message wasn’t sticking. For the most part people waiting until they had completed a whole feature story to actually commit the code. So I figured it might be time to give things a bit of a push.

I remembered a plugin we tried out with Jenkins called the Continuous Integration Game. You got points for passing builds and adding tests and losing points for breaking the build and breaking tests. The experiment increased the testing a bit on that team, but it never really caught on. Still you have to keep on trying.

The rules were simple:

• Every day you win by having more commits.
• More commits in a row means you can rib you’re coworkers about it.
• Blocking someone by committing between the time they pulled locally, merged, and ran tests was worthy of extra taunting.

Commits started picking up. After much joking commits were coming early and often. The experiment worked well enough that I wasn’t even giving feedback anymore. Early and often was the default.

As a 10 year old I read 100 books in a single summer. I’d read on the bus, at lunch, and waiting for soccer games to start. Ended up with a healthy bookshelf. When I switched to programming in the 90s I swept the bookstores at least once a week picking up books on Perl, Javascript, CGI, HTML.

Eventually I filled up several bookshelves with my technical library. When I picked up a first generation iPad I decided it was time to go all digital. I had experimented with Safari online, but it was never a replacement for my library. I went cold turkey with buying paper books. At this point I was mostly purchasing a lot of pragprog titles and transferring them to iBooks. And beta books don’t ship in paper.

A few weeks ago I realized I had moved to a subscription model. Now I just download my books from pragprog when I need them. No need to keep a bunch of titles in my library when I can pull down the up to date versions. I can also read them on my laptop, iPad, or iPhone anytime I want with a nice retina screen.

As a developer SSH is something I have to think about maybe once every few months when I’m setting up a connection for someone pairing in tmux for example. Cutting and pasting public keys can cost real time when a line feed gets inserted inadvertently or something gets clipped.

So assuming ssh isn’t working and you can’t connect it turns out there’s a pretty helpful debug mode on the client and the server. For the client you simply add the -v mode and get a pretty good idea about what’s going on:

ssh -v tmux@10.0.1.4 -i ~/.ssh/tmux_ssh

If that isn’t enough then you can just launch another ssh service on another port in debug mode.

sudo /usr/sbin/sshd -d -p 4444

Then you can just connect your client to the debugging server with a port specification:

ssh -v -p 4444 tmux@10.0.1.4 -i ~/.ssh/tmux_ssh

From that you should be able to get enough information to quickly debug the problem.

(My first experience with SSH was way back in 2000 when our 16 year old Unix sysadmin switched all the developers to SSH from raw telnet overnight because he could. All of us were on Windows or Classic Mac OS back then without any default SSH client software, and it cost us at least a day of pain to get everyone back to work.)

Short conversation at the office today. I declared that I wasn’t a big fan of ternaries and that I typically used them only for simple one line statements and almost never in returns and never nested. One of the developers challenged me on why the ternary operator is frowned on and I admitted I didn’t have much in the way of data. After some digging on the interwebs.

Github’s style guide has the most common approach to the ternary:

“Avoid the ternary operator (?:) except in cases where all expressions are extremely trivial.”

—Github style guide

Support for using ternary’s in return statements is generally supported as well. There is general agreement that nesting ternaries is a bad practice. Static analyzers like Rubocop and Checkstyle include checks for nested ternary operators.

Historically ternary operators bothered me because I missed them sometimes when scanning through code. If and else are hard to miss on a quick scan. I’ve adjusted to using them for one simple one liners as the terseness is nice. Nesting them strikes me as abuse, much like single letter variables or predicates methods that have side effects.

I’ve had a pretty good run of luck grabbing a colleague to look at my code. The last four or five times it’s been a classic rubber duck case.

Me: So here I’m stubbing out the partials in this view spec since I only want to test this conditional logic.

Colleague: OK.

Me: So it keeps failing when I stub the partials and pulling the in anyway even though it works in similar cases. See I’m just pulling in ‘/users’.

Me: Oh, I probably don’t need that forward slash in users.

Me: Thanks again.

If you don’t regularly grab someone to look over your shoulder on a frustrating problem, you might want to start the practice. You can even use a real rubber duck and explain it to them, but for me it seems to work better with a real person.