Software is narrative • Hacker News Board

Re: Software is narrative

#41

Post by swsieber » Sat, Aug 05, 2017, 9:59 PM UTC

Textarcana wrote: post #36

noshbrinken wrote: post #31

Earlier quoted context omitted.

I definitely appreciated this early warning to get off the ride.

While I appreciate the spirit of what you are saying, the average time on page of 3 minutes 45 seconds (across 2k uniques) indicates most visitors are continuing past the paragraph you claim would be problematic.

Devils advocate: Do you know what the average time is to read the entire thing is? If it's 7.5 minutes, then one possible explanation is that your audience is split (50/50). Median time would be a much better indicator.

Re: Software is narrative

#42

Post by marcosdumay » Sun, Aug 06, 2017, 4:10 PM UTC

Textarcana wrote: post #16

marcosdumay wrote: post #14

Earlier quoted context omitted.

Your blog archive (where the title links to) seems to be broken.

Weird it just worked fine for me. http://infiniteundo.com/archive/filter-by/text

Oh, don't mind. My network connection was the one that had a problem.

Re: Software is narrative

#43

Post by girvo » Mon, Aug 07, 2017, 10:14 PM UTC

fragmede wrote: post #29

wickawic wrote: post #22

Earlier quoted context omitted.

Agreed. I think many people do a good job of logging when something goes wrong, and maybe they are good about logging inputs/outputs of a system, but I think that logging important decisions often falls off the table. Ideally I would like to take a request ID, grep the logs, and get an entire story of what happened to that request. In reality, this rarely happens!

> take a request ID, grep the logs, and get an entire story of what happened to that request. In reality, this rarely happens! If that's the situation you find yourself in, I cannot praise centralized logging with a good frontend highly enough because I frequently find myself trying to figure out what happened to a request, and it's like night and day. Needing to ssh anywhere and run grep against log files is functio…

Word of advice: the 'jq' tool for handling JSON files (couple with a glob like '*.log' or something fancier with xargs or parallel) will absolutely save your bacon in those situations. It's way more powerful than it appears on the surface.

We had a series of Docker json-file driver log files. It's done as a raw list (no array around it) of JSON objects -- which is a bit annoying to sort and filter based on properties of the objects.

'jq '[inputs]' (asterisk).log > combined.json' was my favourite command today; it combines all the files inputs and wraps them in an array correctly. No awk needed!

Combine that with its cute:

jq '.someProp as $var | test("some search"; "gi") as $r | if $r then ($var + $__loc__) else null end' (asterisk).log | grep -v "^null$" > filtered.json

And you're away to the races. Can then load the file directly in and group_by(.somePath) and it will all magically work!

Edit: had to remove the actual asterix symbols as they screw with formatting but are used for globbing the file names. Replace with the real character