This is a talk turned into a web page done right. It seems like it should be a simple thing to do, but often the results are confusing and hard to read. Not here, well done!
Making Hard Things Easy
11–20 of 202 posts
Re: Making Hard Things Easy
#12Excellent 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.
Pretty much the same, though I usually just keep the file open in a side terminal. I want to use stuff like cheat.sh (ex. curl cheat.sh/grep) but I never remember.
Re: Making Hard Things Easy
#13and impossible things difficult (hence no longer impossible)!
Re: Making Hard Things Easy
#14I really disagree strongly with the take on bash. The best solution is not to add tooling on top of bash or memorize its idiosyncrasies. It is to not use bash. That is the only way to escape its pitfalls.
Re: Making Hard Things Easy
#15This is a great description of things that seem like they shouldn't be so difficult but can have many complications. The SQL part seems to double-down on a conceptual failure rather than demystifying it though.
A query's logic is declarative which defines the output. It's the query plan that has any sense of execution order or procedural nature to it. That's the first thing to learn. Then one can learn the fuzzy areas like dependent subqueries etc. But being able to see the equivalence between not-exists and an anti-join enables understanding and reasoning.
Using an analogy such as procedurally understanding of written queries only kicks the can further down the road, then when you're really stuck on something more complicated have no way to unravel the white lies.
Re: Making Hard Things Easy
#16This is a great description of things that seem like they shouldn't be so difficult but can have many complications. The SQL part seems to double-down on a conceptual failure rather than demystifying it though. A query's logic is declarative which defines the output. It's the query plan that has any sense of execution order or procedural nature to it. That's the first thing to learn. Then one can learn the fuzzy area…
> The SQL part seems to double-down on a conceptual failure rather than demystifying it though.
She talked about a mental model to help her understand the query (it can be useful), and mentioned that it probably is not how the database actually processes the query.
Re: Making Hard Things Easy
#17Earlier quoted context omitted.
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.
Right. I don't think you're supposed to read them top-to-bottom.
Use `/` and search for the things of interest (keywords, arguments, options, etc...). Use n/N to quickly jump forward/back.
Re: Making Hard Things Easy
#18that was fantastic. i didn't watch the talk, i opened up the transcript and thought to myself i would read a few slides and see if i enjoyed it. that was maybe 20-30 mins ago and i finished it all. really well done, i enjoyed it from start to finish.
i like the way she broke it down. i feel like the author addressed ways to learn and communicate effectively and also grounded it in very concrete terms. i don't want to get too much into psychology or anything which i really am not qualified to talk about but i feel like going through these types of ways of learning and communicating is a continued exercise in ego deflation and in pragmatic problem solving.
i liked the SQL order-of-query-operations thing, the bash and shellcheck thoughts (i will use `-o all` from now on), i am curious to play with the DNS tool (the article links to https://messwithdns.com/ but the actual URL - taken from the text - is https://messwithdns.net/ , FYI), and i enjoyed the part about HTTP (i was hoping she would talk about SPDY and whatnot, i have not even begun to explore such things and am curious what that is all about).
i am going to read the two posts linked the behind-the-scenes on "hello, world".
thanks for the link!
edit: two things this made me think of:
1. the XKCD comic "ten thousand": https://xkcd.com/1053/
2. Mark Russinovich on git: https://twitter.com/markrussinovich/status/15784512452490526...
Re: Making Hard Things Easy
#19I really disagree strongly with the take on bash. The best solution is not to add tooling on top of bash or memorize its idiosyncrasies. It is to not use bash. That is the only way to escape its pitfalls.
That's easier said than done, and completely getting rid of bash may often not be worth the time and effort. But in general I agree, anything remotely complex I try to offload into scripts written in less idiosyncratic languages. Having some tools to help avoiding mistakes with the last 5% that stay bash scripts is super helpful in that case.
Re: Making Hard Things Easy
#20I really disagree strongly with the take on bash. The best solution is not to add tooling on top of bash or memorize its idiosyncrasies. It is to not use bash. That is the only way to escape its pitfalls.
a part of me agrees with the aim of what you say: why not start afresh with something that is less prone to accidents? and i do agree with that idea. but i think it is also somewhat impractical to ignore that pretty much every server i've ever interacted with has a default, vanilla, bash installed, and if i know how to use that, it helps me get by.
not to say we can't and shouldn't try to do better.