Live data from Hacker News

Be careful of the examples you use. They stick

blog.thinkst.com

61–70 of 129 posts

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

#61
post #48
post #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 the…

I did a similar thing as part of a "lunch and learn". NodeJS + Express was super fresh and I did a small example app. When returning the user profile, I just queried the database and returned the entry displaying some properties on the frontend. The team lead was like "show us the request in the console", and I opened it up and there was the non-encrypted password, createdAt date and basically all the not-needed prop…

No need to cringe, this is exactly what demos are. A hack to demonstrate functionality.

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

#62
post #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.

I'd rather try the defaults, see if it works or what doesn't work, or just to gain some experience for how everything involved works, and then work off of that known baseline. Anything else just feels like randomly throwing shit at the wall to me. Especially if I'm not familiar with the thing I need the example for.

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

#63
I think this is also true for trivial / hypothetical examples. I used to work at a global company that would use 'acme' as an example domain, including for emails and such. Because when we started, the domain didn't exist so test emails would just disappear in void.

Until the domain was registered and is actively being used.

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

#64

Earlier quoted context omitted.

A reasonable compromise would be to allow changing defaults whenever there's a major version bump. ripgrep seems to have a major version bump every 18 months or so, which seems a bit excessive. OTOH vim went through 9 versions in 30-something years which seems more reasonable. Although I think there was more churn early on. ISTR vim 6 being around for a long time.

Does vim follow semver? (vim predates semver...) So how do you know you're comparing apples-to-apples? Look at the breaking changes in each ripgrep major release. I don't use major releases as a means of breaking popular workflows. I use major releases even when there are very small breaking changes with minimal impact.

> Does vim follow semver?

I don't think vim follows semver, although a lot of old unix software, and also Free Software, would use major version bumps to indicate compatibility breaks. Semver was in many ways the documentation of what a lot of software was already kind-of doing.

But vim was used as an example by the GP, so re-using it as an example to show what I thought was a sensible major-release schedule (instead of, say, coreutils, or glibc, or glib/gtk, or perl, or Qt, etc...) seemed appropriate.

> I don't use major releases as a means of breaking popular workflows. I use major releases even when there are very small breaking changes with minimal impact.

A breaking change is going to break someone's workflow. (See also, Hyrum's Law, xkcd 1172.)

As a user and developer, my preference is for breaking changes to be put off as long as possible, and then all applied together every few years or so. (Or never :-) That way, I don't normally have to pay that much attention to updates, even if an app gets new features. But when there's a major version bump, I can check the release notes carefully and know to keep an eye out for anything unusual/different.

If I only ever ran one program, it wouldn't be a big deal. But I don't, I run hundreds regularly. If they all have breaking changes once per year, that averages out to me needing to check over two sets of changes that might impact me every week.

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

#65
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.

Yeah I think this is the only good solution, really. Otherwise it's just often unclear which things are required to have a specific value, and which things can be replaced. In this example, I'm sure plenty of people thought it was possible that "someprefix" was required, rather than just an example.

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

#66

This isn't quite the point of the article, but we allow people to apply for student discounts for our service, and provide the following example that we ask users to send to us over Intercom: > Hello, could I please apply for the student discount? > > [PLEASE READ AND DELETE THIS – After sending this initial message, please attach a proof of your student status, such as a photo of your valid Student ID so we can proc…

I think you should just remove that example entirely then. It barely adds anything and as you said it is causing recurring issues.

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

#67
post #48
post #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 the…

I did a similar thing as part of a "lunch and learn". NodeJS + Express was super fresh and I did a small example app. When returning the user profile, I just queried the database and returned the entry displaying some properties on the frontend. The team lead was like "show us the request in the console", and I opened it up and there was the non-encrypted password, createdAt date and basically all the not-needed prop…

hah what i did involved a db too, a string based query without sanitization introducing a possible sql injection. The input never came from a user and was sourced from a config file but i still should have known better. I learned that if you put it in a slide, no matter scope/purpose, it better be production quality because people are just going to copy/paste.

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

#68
post #63

I think this is also true for trivial / hypothetical examples. I used to work at a global company that would use 'acme' as an example domain, including for emails and such. Because when we started, the domain didn't exist so test emails would just disappear in void. Until the domain was registered and is actively being used.

There used to be a blog where someone registered DoNotReply.com and posted all the replies he got as a result of companies using that as a default reply-to in emails — which often included sensitive information.

It’s not around anymore but here’s a discussion of it when it was up:

https://boards.straightdope.com/t/donotreply-com/442816

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

#69
In-band signalling often seems to have this issue where it's not 100% clear what is part of the message and what is part of the meta-message.

Edit: I think it's mildly amusing and further drives the point hom that some people in this thread missed endnote 1, where you say it was not the actual prefix.

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

#70
post #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 the…

> best practice (I loathe that term)

Me too :( One of my coworkers keeps talking about “best practice” all the time. And he writes the most broken garbage of anyone I’ve met in a long time.

I’m often feel like quitting, because I do not enjoy working with him. But I like the company I work for. And I don’t want to spend time trying to find a new job at the moment.

Post reply on HN