Live data from Hacker News

Be careful of the examples you use. They stick

blog.thinkst.com

31–40 of 129 posts

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

#31

> 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?

Well, I’m also the sort of person who wouldn’t. Similarly, I also never copy&paste example code when reading documentation, instead, I immediately jump into writing my own variation. It took me a while to realize that’s not typical.

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

#32
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…

Ctrl-O is incredibly useful. Go back to an earlier command, press Ctrl-O repeatedly, and you re-run a series of commands. That doesn't work if some of them were deleted as duplicates.

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

#33
post #19

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…

I use ignoreboth -- it's not about saving disk and memory, it's about making the history more useful for searching. The ignorespace also helps avoid getting credentials saved to disk you don't want saved and is even more useful these days than it was in the past because we're no longer on multiuser systems where you really want to keep credentials out of commandlines entirely.

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

#34
post #5

Oh, absolutely. If you give people an example (and you should), the overwhelming majority will copy the example exactly and then only change what they are forced to change when it doesn’t work otherwise . Therefore, prepare your examples accordingly.

This may be an actual answer to the problem. If you show "someprefix" as an example, then give users a helpful error message if they actually type in "someprefix". Something like "Dear user, someprefix is only an example, please replace this with a name appropriate to your business."

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

#35

Why is "use more examples" the solution? If the users are copy pasting the code, why not just generate random strings thereby showing an example and also fulfilling their own requirement of non-identifiable strings?

A random string may look suspicious and the goal of this is to avoid suspicion

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

#37
post #5

Oh, absolutely. If you give people an example (and you should), the overwhelming majority will copy the example exactly and then only change what they are forced to change when it doesn’t work otherwise . Therefore, prepare your examples accordingly.

This may be an actual answer to the problem. If you show "someprefix" as an example, then give users a helpful error message if they actually type in "someprefix". Something like "Dear user, someprefix is only an example, please replace this with a name appropriate to your business."

No, you’ll only get “someprefix1”, and about 14 similar variants. What you need to do is either prepare a reasonable prefix valid for all (or at least most) users, or have the documentation to be dynamically prepared for each user, with a dynamically generated appropriate prefix for each user.

Alternatively, you’ll have to teach users what kinds of prefixes would be appropriate, with an example which is obviosly not appropriate for any of your actual user. This will take some length of text to explain, and many users will not read it, and may instead abandon your service.

Relatedly, I’ve always disliked when programs force me to name N number of things without adequately explaining

• What the names are (Is this some kind of group name? Instance name?)

• How the name will be shown. (Should I prefix the name with the company name myself, or will that always be visible? Will this name be shown together with numerous other names which are all UPPER CASE? Will the name be automatically converted to lower case?)

• If any of these names will be publicly visible.

• If any of the names can be changed later, and how hard it is.

• What characters are allowed (Are spaces, underscores, or dashes allowed? How about Unicode? Emojis? What is the normal naming scheme?)

• How long is the name allowed to be? (Will it be silently truncated at 8 or 16 characters (or grapheme clusters)?)

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

#38
I gave what my company calls a “lunch and learn” presentation once of some interesting tools. People liked it and shared my deck around which was cool. But then my quick/dirty examples started showing up in best practice (I loathe that term) decks shared to very large teams with my name at the bottom. A security guy, who I greatly respect, raised some questions and I had to go through the whole story with him and then find all references to my examples and fix them. It was pretty embarrassing.

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

#39
post #5

Oh, absolutely. If you give people an example (and you should), the overwhelming majority will copy the example exactly and then only change what they are forced to change when it doesn’t work otherwise . Therefore, prepare your examples accordingly.

About 5 years ago I made a blog post detailing how to use Traefik/LE with PHP. For about one day, I realized I had my personal email in the template for the warning email for when the Lets Encrypt cert is expiring. I still get emails warning random people that their domain is going to expire.

Prepare your examples accordingly.

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

#40
post #28

Can we please use `example.com` for an example domain name instead of like `somedomain.com`? It can create accounts with emails that someone can actually intercept.

There is also an entire TLD, .example so that you can put multiple names in a TLD and distinguish big-corp.example from my-local-store.example and it's clear that those aren't related, they just share a registry the same way as letsencrypt.org and wikipedia.org do
Post reply on HN