Hardscrabble 🍫

By Max Jacobson

announcing metaphor loop

18 Sep 2015

Last month I started a podcast but I didn’t really publicize it because I wasn’t sure I was going to keep doing it. I put it on this site, hidden down in the footer, and I put it on iTunes, and I tweeted a few cryptic things like:

Today I released the second episode, which makes it real enough that I’m ready to share it.

metaphor loop

metaphor loop

(Click on the art to visit the show homepage, which has subscription links)

It’s about “how we think about programming”. I started out with an agenda, which was to argue that figurative language is the best tool for teaching code, or something like that, and I’m finding that I’m not sure what I think anymore, but I’m excited to keep exploring the ways people build understanding by interviewing programmers about what goes on in their heads.

The first episode was an interview with my old friend Corey Mendell. I had a really good time recording and editing it and the few people I shared it with seemed to like it too. I was immediately addicted.

I don’t think I have it in me to do it on a weekly basis like a lot of podcasts. Today I’m sharing the second episode, approximately a month after the first. So, monthly? Maybe.

This one features Vaidehi Joshi who I don’t even really know, but whose blog I really like. I’m happy with how this one turned out and think you’ll like it.

a few details

I’m not planning to have ads. I want this to be a fun, pure endeavor that makes no money. I’m not tracking subscriber counts or anything like that. I don’t want to know.

I’m licensing it under a creative commons license, because

  1. why not?
  2. I wanted to include some CC-licensed music, and it had a “share-alike” clause
  3. so why not?

By the way: part of the reason I made this is that I really like listening to podcasts and my ego would often hear them and think “why don’t they invite me on?” One thing I’m realizing is that inviting people on is kind of hard, because you don’t know if they’ll want to do it and maybe they’ll think it’s dumb? So: if you listen to some episodes and think you’d like to be on the show, let me know, and we’ll at least have a phone call and if it feels like a show, it’ll be a show.


pro tip open firefox tabs in background

08 Sep 2015

One good thing to know if you’re a firefox person: visit about:config and poke around, configuring things.

Here’s what happened today: I was watching a youtube video while browsing Twitter via Tweetbot. I clicked a link, which opened a new tab, pushing my video into the background. I diligently clicked the video’s tab to bring it back to the foreground so I could continue passively watching it while browsing twitter.

Then I clicked another link, and instinctively clicked the video’s tab to bring it back into the foreground again.

By the third time I did this, I realized I really wished there was a setting to automatically open tabs in the background. I tried googling it, but wasn’t really finding anything. So I checked about:config and searched through for “background”. The screen is a list of every configuration you can control. Many of them are boolean attributes, which can be toggled by simply double clicking the attribute.

I saw one, browser.tabs.loadDivertedInBackground;false and thought “hmm, maybe?” At this point, I’m not certain there’s even a configuration that does this, but I try toggling it… and … click a link from a tweet… and…

It did what I wanted. Sweet.

eighty character lines

05 Sep 2015

Last month we talked about RuboCop, which analyzes your Ruby code and nitpicks it. One of its most difficult to follow suggestions is to keep your lines of code no longer than 80 characters.

The creator of rubocop, bbatsov, explained his perspective on his blog:

We should definitely have a limit – that’s beyond any doubt. It’s common knowledge that humans read much faster vertically, than horizontally. Try to read the source code of something with 200-character lines and you’ll come to acknowledge that.

I’m totally on board with the short lines train. For me, it only gets tricky when dealing with nested stuff (examples to follow) which add a lot of space to the left of the first character of code. For example:

module MyGreatGem
  module SomeOtherNamespace
    module OmgAnotherNamespace
      module LolYeahOneMore
        class SomethingGreat
          class SomethingOk
            class MyGreatClass
              def initialize
                puts "OMG I only have 64 characters to express something on " \
                     "this line! And now it's more like 'these lines' haha"

Often strings are the first thing to get chopped up, as in that example.

The only approach I thought of to deal with that is to organize my code differently to not use many nested namespaces. That’s probably not the worst idea, honestly, but I’m writing this post to share an interesting style I observed in the wild (read: on github) that takes a whole nother approach:

# Excerpted from:
# https://github.com/net-ssh/net-sftp/blob/ebf5d5380cc533b69b308baa2e396e4a18abc900/lib/net/sftp/operations/dir.rb
module Net; module SFTP; module Operations
  class Dir
    attr_reader :sftp

    def initialize(sftp)
      @sftp = sftp
end; end; end

Huh! That’s a style I hadn’t seen before. RuboCop has many complaints about it, and I don’t totally love the style, but it’s a very novel and neat way to do it, and it certainly frees up columns to spend on your code if you’re planning to stick to an 80 character limit.

One possible alternative is to define your namespaced class using this shorthand:

class Net::SFTP::Operations::Dir
  attr_reader :sftp

  def initialize(sftp)
    @sftp = sftp

If you do that, you get 2 extra characters on each line. Sweet!

One problem: it sort of doesn’t work, at least not in the same way.

If you just look at that example, and imagine that you’re the Ruby interpreter trying to figure out what this code means, how are you supposed to know whether Net, SFTP, and Operations are supposed to be classes or modules? You have to already know by them being previously defined. If they haven’t been defined yet, you are well within your right to raise a RuntimeException to complain that this constant hasn’t been defined yet, rather than try to guess.

Both of the earlier longhand examples were explicitly explaining what the type of each namespace constant is. That pattern works whether you’re defining the module or class in that moment, or “opening” a previously defined module or class to add something new to it. This shorthand, while optimal for line length, only works when opening previously defined constants.

One downside of this approach is that, by relying on all of the namespaces being predefined, it becomes harder to test this class in isolation (it’s probably possible to do it through some gnarly stubbing but, harder). You’re also introducing some requirements about the order in which the files from your code need to be loaded, which feels kind of fragile.

One possible upside comes to mind. When you follow the typical pattern of writing out all the namespace modules and classes, you introduce some room for error: what if in one file you write class Operations by mistake (instead of module Operations)? You’ll get an error. That’s not too bad, honestly.

I think 80 is usually enough but if you’re doing too many contortions to stay in that box, try like 90 or 100, you’re still a good person.