Implement Heroku style log colorization

[zakwilson]

No description provided.

[troy]

👍

[lmarburger]

This is a great idea. I see one problem using lengths, though. If I have the hosts web1, web2, etc, the same program on all of them will be the same color.

What if we just summed up the unicode value of each character?

idx = (event.data["hostname"] + event.data["program"]).unpack('U*').inject(&:+) % 5

I don't know if this is the best way to get an integer value from a given string. It's just the first thing that came to mind.

[troy]

This is a fantastic comment, and I was also wondering whether I'd like it. I encountered a similar problem where related hosts' output was the same color (your 1st example), but I actually preferred that output over many different colors (your 2nd example).

That said, I can imagine lots of cases where (a) the hostname+program lengths would be unintentionally overlapping, or (b) the overlap did indicate a relationship like webN, but it wasn't the one I wanted.

What about combining these with another gap you identified, and changing --force-colors into --colors={h,p,hp,none}? The default would be --colors=hp (your 2nd example) when color terminal emulation was detected, but someone could also use --colors=p for the same behavior as Heroku's CLI (and your 1st example) or --colors=h to make it easier to spot multiline output from the same sender.

One important thing to note is that we only have 5 characters, so color collisions are going to happen anyway. We can try to make them less of an issue, though.

[troy]

BTW, I'm all for the sum of the Unicode character values like you described.

[lmarburger]

What about combining these with another gap you identified, and changing --force-colors into --colors={h,p,hp,none}? The default would be --colors=hp (your 2nd example) when color terminal emulation was detected, but someone could also use --colors=p for the same behavior as Heroku's CLI (and your 1st example) or --colors=h to make it easier to spot multiline output from the same sender.

I could see that being useful. I think that's worth exploring in a new PR. No sense holding up colors while we discuss if/how to accomplish it.

[zakwilson]

How about (event.data["hostname"] + event.data["program"]).hash % 5?

[lmarburger]

👍 I knew there had to be a better way to turn a string into an integer.

[troy]

Looks great. Can you add ansi to the papertrail.gemspec as a dependency?

[troy]

This PR implements #51.

The output is so much easier to skim. Nice work @zakwilson.

[lmarburger]

This line can be removed as it's included as part of gemspec

[troy]

Thanks, gents. Talked a bit more here and ended up with these changes. The bigger ones:

• use the hash method @zakwilson suggested to choose the colors

• add a new --color option which can take 1 of 4 values: host-program, host, program, or off. These choose which variable(s) to colorize based on. The default and behavior already in this PR is host-program. If someone says --color=host or --color=program, then only the hash of the specified attribute is used to choose the color.

  Ideally this is a constrained set within OptionsParser. This page) has an example:

      # Optional argument with keyword completion.
      opts.on("--type [TYPE]", [:text, :binary, :auto],
              "Select transfer type (text, binary, auto)") do |t|
        options.transfer_type = t
      end

The smaller one:

• rename --force-colors to the singular --force-color

For all of these, the last option should win.

[troy]

@zakwilson I just updated my comment from yesterday with 2 changes.

[troy]

Continuing in new PR from different branch (above).