Live data from Hacker News

Making Hard Things Easy

jvns.ca

1–10 of 202 posts

Re: Making Hard Things Easy

#2
Excellent talk. She seems to be a very likable person. She is right about Bash being full of "gotchas" and trivia and memorizing them all is very hard, but I think it is nice to memorize some trivia. For instance, I tended to forget the order of the arguments of the find command, and I would lose time trying to remember its syntax when I'm in front of a machine with no readily available internet connection. So I committed to learning and memorizing the most common command line tools and some of their "gotchas". I used Anki for that, and some mnemonics, and the return on the investment has been worth it I think.

Re: Making Hard Things Easy

#3
post #2

Excellent talk. She seems to be a very likable person. She is right about Bash being full of "gotchas" and trivia and memorizing them all is very hard, but I think it is nice to memorize some trivia. For instance, I tended to forget the order of the arguments of the find command, and I would lose time trying to remember its syntax when I'm in front of a machine with no readily available internet connection. So I comm…

I maintain a file with commands that I don't use often (ex: increase volume with ffmpeg, add a border to an image with convert, etc). I even have a shortcut that'll add the last executed command to this file and another shortcut to search from this file.

Re: Making Hard Things Easy

#5
Well said! I'm in manufacturing, not web tech, so the hard things I work with are very different (RS-274 G-code, servo motion systems, PLC/SCADA network connections are a few examples), but it's interesting to see the overlap in causes of difficulty like trivia, gotchas, frequency of use, and visibility. And disheartening to see that the web tech community is so open and friendly and communicative, while controls engineers may rarely hang out on forums but rarely share anything even close to this outside of a $2,000 training course.

And not to nitpick, but I don't have Julia's email, but when struggling with hard things like DNS I hate to have someone bounce off this little roadblock...her link to to the demo of the DNS exploration website is pointing to the .com, when it's actually at the .net TLD:

    messwithdns.net
                                 ^^^    =/=       ^^^
Looks like someone needs an HTML linter... :)

The correct link - https://messwithdns.net/ - is actually pretty neat!

Re: Making Hard Things Easy

#6
post #3
post #2

Excellent talk. She seems to be a very likable person. She is right about Bash being full of "gotchas" and trivia and memorizing them all is very hard, but I think it is nice to memorize some trivia. For instance, I tended to forget the order of the arguments of the find command, and I would lose time trying to remember its syntax when I'm in front of a machine with no readily available internet connection. So I comm…

I maintain a file with commands that I don't use often (ex: increase volume with ffmpeg, add a border to an image with convert, etc). I even have a shortcut that'll add the last executed command to this file and another shortcut to search from this file.

Oh, that's a great idea. I have a doc that I maintain by hand, either via ">>" or editing directly. Time to go and make a shortcut. Do you do any annotation to help with the search?

Re: Making Hard Things Easy

#7
post #2

Excellent talk. She seems to be a very likable person. She is right about Bash being full of "gotchas" and trivia and memorizing them all is very hard, but I think it is nice to memorize some trivia. For instance, I tended to forget the order of the arguments of the find command, and I would lose time trying to remember its syntax when I'm in front of a machine with no readily available internet connection. So I comm…

I tended to forget the order of the arguments of the find command, and I would lose time trying to remember its syntax when I'm in front of a machine with no readily available internet connection.

The man pages are readily available.

The bash man page is huge and hairy, but comprehensive, I've found it pretty valuable to be familiar with the major sections and the visual shape of the text in the man page so I can page through it quickly to locate the exact info I need. This is often faster than using a Internet search engine.

Re: Making Hard Things Easy

#8
post #6
post #3

Earlier quoted context omitted.

I maintain a file with commands that I don't use often (ex: increase volume with ffmpeg, add a border to an image with convert, etc). I even have a shortcut that'll add the last executed command to this file and another shortcut to search from this file.

Oh, that's a great idea. I have a doc that I maintain by hand, either via ">>" or editing directly. Time to go and make a shortcut. Do you do any annotation to help with the search?

Usually no annotations, as I typically search by command name. But sometimes I edit the file to add comments if there are many examples for the same command.

Re: Making Hard Things Easy

#9
post #7
post #2

Excellent talk. She seems to be a very likable person. She is right about Bash being full of "gotchas" and trivia and memorizing them all is very hard, but I think it is nice to memorize some trivia. For instance, I tended to forget the order of the arguments of the find command, and I would lose time trying to remember its syntax when I'm in front of a machine with no readily available internet connection. So I comm…

I tended to forget the order of the arguments of the find command, and I would lose time trying to remember its syntax when I'm in front of a machine with no readily available internet connection. The man pages are readily available. The bash man page is huge and hairy, but comprehensive, I've found it pretty valuable to be familiar with the major sections and the visual shape of the text in the man page so I can pag…

> The man pages are readily available.

True, but I find the man pages not easy and quick to parse.

Re: Making Hard Things Easy

#10
post #4

TiL: The shell does not exit if the command that fails is a part of any command executed in a && or || list except the command following the final && or ||. Reference: https://www.gnu.org/software/bash/manual/bash.html#index-set

This is because && and || are often used as conditionals:

    [ -e README ] && cat README
avoids an error if the file README doesn't exist, and

    [ -e README ] || echo "You should write a README!"
works the opposite way.

What's more pernicious is that pipelines don't cause the shell to exit (assuming set -e) unless the last command fails:

    grep foo README | sort
does not fail if README doesn't exist, unless you've also used `set -o pipefail`.
Post reply on HN