Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be careful of the examples you use. They stick

blog.thinkst.com

Post reply on HN
Print view View original

21–30 of 129 posts

Re: Be careful of the examples you use. They stick

#21

Post by kevincox »

nicexe wrote: post #9

I'm thinking if invalid characters in the examples given would be an acceptable solution. For DNS records this could be XML-like tags like . . On one hand, it prevents blind copy-pasting but on the other hand, your example is invalid.

For procedure documentation I often use ${service_namr:?} For similar reasons. If the variable isn't set you get a clear error. And it provides an easy way to use the template without modification.

It isn't perfect, common variable names may already be set or have been set in a previous execution of this playbook on a different problem. But it catches common issues while being convenient.

Re: Be careful of the examples you use. They stick

#22

Post by thaumasiotes »

l0b0 wrote: post #11

This is also an opportunity to think about the value of a piece of configuration. If an example configuration value works for 40% of users without modification, should that value even exist? Think Bash's `HISTCONTROL=erasedups`, which shouldn't be necessary to set in the 21st century. Or should it be auto-generated, like Docker's container names? In the very best case, the defaults are so good that an empty configura…

> This is also an opportunity to think about the value of a piece of configuration. If an example configuration value works for 40% of users without modification, should that value even exist?

This sounds completely insane. If a majority of people need something different, they shouldn't be allowed to have it?

Re: Be careful of the examples you use. They stick

#23

Post by ignoramous »

l0b0 wrote: post #11

This is also an opportunity to think about the value of a piece of configuration. If an example configuration value works for 40% of users without modification, should that value even exist? Think Bash's `HISTCONTROL=erasedups`, which shouldn't be necessary to set in the 21st century. Or should it be auto-generated, like Docker's container names? In the very best case, the defaults are so good that an empty configura…

> In the very best case, the defaults are so good that an empty configuration does what most people want.

More generally, defaults (including, default examples), matter: https://news.ycombinator.com/item?id=25646180

Especially for software which is mod-able, malleable, composable, configurable... defaults have a disproportionate impact on UX, DevEx etc. A reason why TLS 1.3 got rid of a laundry list of options, or why WireGuard is simply a joy to work with (as opposed to IPsec / OpenVPN), or why middleboxes on the Internet are a big hurdle to protocol upgrades, or how NewCloud companies like Cloudflare, Replit, Flyio, and Vercel have devex beyond what the Big 3 can muster up.

> Think ripgrep ... welp, I can't really think of many good examples.

Apple has got this spot on, across decades. Their products "just work", as they say so in their own marketing.

> Browsers need extensions

Now you see why Chrome is defaulting to Manifest v3 ;)

Re: Be careful of the examples you use. They stick

#25

Post by pdw »

saurik wrote: post #19
gray_-_wolf wrote: post #17

Earlier quoted context omitted.

> Think Bash's `HISTCONTROL=erasedups`, which shouldn't be necessary to set in the 21st century As in that it should be the default? Or only option? I personally do not have (and want to have) that set, and I am hardly alone. Any change in defaults fucks someone over, especially in things like bash, where you ssh into many machines with many different versions of bash...

Omg, I just read the documentation for erasedups and I'm actually shocked anyone would want that feature turned on, to the point where it never even would have occurred to me to implement it in the first place and if the feature worked like that without some way to turn it off I'd have been super angry :(. Maybe we are parsing that sentence wrong and by "shouldn't be necessary to set" the idea is "it is useful in sit…

Now I'm confused. Why would you want duplicate entries in your command history? I get that on an overloaded system in the 80s it might have taken a perceptable amount of time to filter out duplicates. But on a modern system you surely want it always enabled?

Re: Be careful of the examples you use. They stick

#26

Post by oakesm9 »

jan_Sate wrote: post #24

I find it funny how people would just happily use `someprefix` as the subdomain. Isn't it obvious that it's meant to be replaced with another prefix?

From the aricle footnotes:

> some-prefix is used in this post to protect our poorly chosen actual-prefix

Re: Be careful of the examples you use. They stick

#27

Post by adrian_b »

saurik wrote: post #19
gray_-_wolf wrote: post #17

Earlier quoted context omitted.

> Think Bash's `HISTCONTROL=erasedups`, which shouldn't be necessary to set in the 21st century As in that it should be the default? Or only option? I personally do not have (and want to have) that set, and I am hardly alone. Any change in defaults fucks someone over, especially in things like bash, where you ssh into many machines with many different versions of bash...

Omg, I just read the documentation for erasedups and I'm actually shocked anyone would want that feature turned on, to the point where it never even would have occurred to me to implement it in the first place and if the feature worked like that without some way to turn it off I'd have been super angry :(. Maybe we are parsing that sentence wrong and by "shouldn't be necessary to set" the idea is "it is useful in sit…

That option has nothing to do with limited disk space.

Eliminating the duplicates makes it much easier to search the history for a command that was used long ago instead of having to skip over hundreds of duplicates of some non-interesting command, such as "ls".

It also makes it much more likely that complex commands used a long time are still preserved. No matter how large you make your history file, it is much more likely that it will become filled with simple commands that you do not need to recall from history, instead of keeping the complex commands that you hate to retype.

Moreover, while having a command history is useful to avoid retyping some commands, some may be less willing to preserve a history from which it is easy to discover which have been their exact actions while using the computer, though for this it is preferable to also disable the saving of the history file.

Re: Be careful of the examples you use. They stick

#29

Post by TRiG_Ireland »

adrian_b wrote: post #27
saurik wrote: post #19

Earlier quoted context omitted.

Omg, I just read the documentation for erasedups and I'm actually shocked anyone would want that feature turned on, to the point where it never even would have occurred to me to implement it in the first place and if the feature worked like that without some way to turn it off I'd have been super angry :(. Maybe we are parsing that sentence wrong and by "shouldn't be necessary to set" the idea is "it is useful in sit…

That option has nothing to do with limited disk space. Eliminating the duplicates makes it much easier to search the history for a command that was used long ago instead of having to skip over hundreds of duplicates of some non-interesting command, such as "ls". It also makes it much more likely that complex commands used a long time are still preserved. No matter how large you make your history file, it is much more…

    $ cat ~/.inputrc 
    "\e[A": history-search-backward
    "\e[B": history-search-forward
This means that I can type the first couple of letters of a command, and then use the up and down arrow keys to cycle through history to search the rest of it. It makes life simpler for me, and confuses me only on the occasions when I've used `git stash`, so `git status` doesn't appear when I expect it to.

Re: Be careful of the examples you use. They stick

#30

Post by assbuttbuttass »

> When given an example, a significant number of users default to using that same example in their customisation. The behaviour is consistent across customers and configurations. This surprised us!

This is not surprising to me at all. Maybe the authors have never used an example before?

Post reply on HN