Story time! Back around 2008 when we were developing the first version of AWS CloudWatch (which was then code-named "Granite") we had two problems to solve:
1. What should the API for PutMetricData look like?
2. Where should we store that data?
(you know, minor issues)
At the time, we decided that #1 was more critical than #2 (and of course #2 depends deeply on the answer to #1), and that the best way to solve it would be to do some learning-by-prototyping - stand up an internal version of CloudWatch to dogfood with some other Amazon services and be able to go to prospective internal customers with a "working" service that they could kick the tires on, not just some API docs and paper prototypes. So I quickly hacked up an implementation of "GraniteDataStore" called "InMemoryDataStore", which would store every PutMetricData request in a HashMap and nowhere else.
When I sent the code out for peer review, my reviewer was aghast at the idea that we would stand up a service that would knowingly store different copies of the data on every server, and lose it all on process restart. I responded by renaming InMemoryDataStore to FakeInMemoryDataStore, but that wasn't enough. Finally, we settled on a name of (if memory serves) FakeFakeFakeDataStoreThatLosesAllYourData and that was enough to get my merge approved.
I (also at Amazon) once wrote a script that fetched data from a whole bunch of different sources and aggregated them into a single static snapshotted overview Wiki page (no, they weren't live-dashboardable, for...reasons). One of those sources was an oncall-diary, that had to be manually updated because it was tracking fluffy human things like sentiment and thoughts rather than ticket count. So, naturally, I put a `--yes-I-promise-that-I-have-updated-the-oncall-diary-page` flag on the script, and made it error out with a very clear error message (telling you what needed to be updated, and why) if that was not set.
I went off to do something else for a few months, came back, and found that script being run in a Cron job, with that flag hard-coded set. Sometimes even your clearest "watch out, do this thing!" naming won't do any good.
(I guess the takeaway from this is that the manual oncall diary wasn't all that important. Which was something I questioned at the initial requirements gathering, but ¯\_(ツ)_/¯ )
---
btw, _thank you_ (and your team) for CloudWatch. It's great, and I am continually frustrated by teams that ingest events, process them, and emit calculated metrics to PMET, rather than just logging and letting Log Insights figure it out. The extra overhead to change PMET-emission code every time we want to investigate some new measure is such a waste.
> my reviewer was aghast at the idea that we would stand up a service that would knowingly store different copies of the data on every server, and lose it all on process restart
> InMemoryDataStore
This...is just how in-memory data stores work, right? That's what "in-memory* means? Or am I missing something obvious?
In-memory data stores still typically have a concept of "durability" which you can think of as "the same transaction is committed on all servers in {some definition of a replica group}." So like any disk backed store, all servers see transactions consistently, and all have a copy of the data.
Obviously, there's no replication/transaction processing occurring when you're just storing stuff in an ordinary hashmap. Hence the Fake* naming.
int __THIS_IS_NOT_A_PLACE_OF_HONOR()
# no highly esteemed deed is commemorated here.
# nothing valued is here.
# What is here was dangerous and repulsive to us.
# This message is a warning about danger.
# The danger is still present, in your time, as it was in ours.
It's an example message proposed in a 1993 report from Sadina National Laboratories[1]. I doubt it's actually been legitimately written or used anywhere, but it's one of many such long-term messages intended to communicate danger thousands of years into the future, when the dangers of radioactive waste or even the prevailing language of the time may not be known.
Nuclear waste that stays radioactive for ten thousand years has an interesting design problem: how do you create a warning that people will understand after that much time has passed? A committee was created to study this problem, and one of the outcomes was formulating what message should be communicated. The above is that message.
The next step is figuring how to communicate that message in a language-agnostic and culture-agonistic medium.
The future will bring technology to harvest more energy or otherwise neutralize the waste.
I believe that future will come long before warnings in today's languages become unintelligible.
If there's some kind of apocalypse where science gets a hard reset, then sealed up nuclear waste is probably very low on the list of realistic and dangerous threats.
> The future will bring technology to harvest more energy or otherwise neutralize the waste.
Optimistic. My turn: The future will bring technology to make spiders talk to cats. Prove me wrong!
> If there's some kind of apocalypse where science gets a hard reset, then sealed up nuclear waste is probably very low on the list of realistic and dangerous threats.
Nuclear waste might be relatively low in the immediate time frame after a science-resetting apocalypse, but the societies emerging afterwards will probably appreciate having a warning before they build their new settlements and water wells on a nuclear waste site. Especially if that nominally sealed site seeps out radioactive sludge due to critical containment failure only long after the settlement was established.
This. What we currently call “nuclear waste” is just a fuel for a type of nuclear reactor that we could build, but haven’t yet built due to over–regulation of the nuclear industry. If we had extracted all of the energy from it then it wouldn’t be radioactive any more, and if we had reactors for doing that then we wouldn’t need to store anything.
Not sure what is hard about this? its a solved problem. Mounting a human skull has been an effectve sign for stay away for 10k years already. It wont change in 10k years.
As humans, we've opened more sinister stuff than that, way before having any clue about nuclear energy. No reason why our post-apocalyptic brethren won't do the same
It's more nuanced than that. Mounting a human skull could also mean: here's a graveyard where people have been burried with their most prized possessions. There's a really interesting documentary about Onkalo, a Finnish nuclear waste repository where they talk a bit about this. I think the conclusion they came to was make it look as boring as possible. Or at least more boring than the hassle to get in :-)
Perhaps boring and desolate, Though IDK how you could guarantee desolation over such a period of time. Hassle to get in by definition makes it interesting. It would probably only deter the same people that a skull would with muchless effort than razing the area though why not combine both?
Robbers, raiders, and treasure hunters would still go in.
The people that ignore the skulls would ignore anything anyway. Robbers, raiders and treasure hunters by definition risk their lives to gain money or power. Any warning must be assumed to be a trick if you are in that life.
"DO_NOT_USE_OR_YOU_WILL_BE_FIRED" is a running joke at Facebook, used when soft-deprecating a field or method where you can't immediately get rid of all users. Sometimes it migrates into open source products.
It's iconic enough that Facebook HQ has a conference room by that name.
There was a conference room at Yahoo named Sorry! that was used during many rounds of layoffs. The entire floor's conference rooms were all named thematically after popular board games.
> The entire floor's conference rooms were all named thematically after popular board games.
Getting OT, but I worked somewhere where the conference rooms were named after birds of prey (Eagle, kestrel, etc etc). The smokers' room was informally known as 'Puffin'
I'm shocked there was an interior room that allowed smoking. It must not have been in California this millennium.
I decided to stop smoking the day Jerry Yang held the door open for me and my band of misfits on our way to the outside smoking area. David Filo once asked me if he could share the panini station I was presently occupying in the cafeteria, URL's. I answered affirmatively but subsequently wished I had uttered "it would be an honor."
Still a thing in much of Asia, certainly Japan, Thailand - instead of "smoke anywhere so long as it is outside" it is more "smoke only in the designated place, inside or outside, not in the street". Being able to smoke at an inside restaurant table but not outside the front door out of respect for non-smoker diners very odd.
Do you remember the brief period around 2010 where people were vaping at their desks all day in normal office buildings?
There's a Google office that has a cluster of conference rooms with names like "Hell", "Limbo", "Jail", "No Time", "Over Your Head", etc. I've always wondered if telling an interview candidate "You'll be in Over Your Head today" has a psychological effect.
It could have one on employees too IMO. If I was the poor soul assigned to the long term maintenance of a legacy project, having to pass by Limbo, Hell and Jail everyday might just push you over
> You are aware of the corporate info on the reactjs.org page footer right?
They clearly weren't, and neither was I (not being in a role that uses React). Consider being less dismissive and more informative next time someone doesn't know something that you know. [0][1]
What's also quite cool that it discourages and additionally impedes usage of the function, because it really is called by a different name. I think it's true name is, ermmm, "nlnPrfrmNT". (I've ultimately decided to stay on the safe side too and not commit into writing the fullness of the dread name.)
As far as I know, there is still a configuration I wrote at a previous employer where I left the remark:
-----
-- STOP. YES, YOU.
--
-- THIS CODE IS A PROOF OF CONCEPT THAT DOES HORRIBLE THINGS TO THE PLATFORM.
-- THE FACT THAT IT WORKS AT ALL IS VERY VERY BAD.
--
-- DO NOT RUN THIS IN PRODUCTION. IF YOU DO, I WILL KNOW, AND I WILL FIND YOU.
-----
Nice. My favorite bit of code I wrote like that was when upgrading a bit of logging that previously caused a very scary outage last time another dev tried it. To mitigate the risk of it happening again when I attempted a similar upgrade a second time I gated it with a check to make sure a specific invariant wasn't being violated with a method called CheckForLandmines();
We had a script that would re-sequence all the jobs in the system, which you rarely want to do, as you have to put eyes on a bunch of physical locations. The password for the script was "BADIDEA"
One of my favorites is the warning you get if you enter the shell of an Oracle ZFS storage appliance:
+-----------------------------------------------------------------------------+
| You are entering the operating system shell. By confirming this action in |
| the appliance shell you have agreed that THIS ACTION MAY VOID ANY SUPPORT |
| AGREEMENT. If you do not agree to this -- or do not otherwise understand |
| what you are doing -- you should type "exit" at the shell prompt. EVERY |
| COMMAND THAT YOU EXECUTE HERE IS AUDITED, and support personnel may use |
| this audit trail to substantiate invalidating your support contract. The |
| operating system shell is NOT a supported mechanism for managing this |
| appliance, and COMMANDS EXECUTED HERE MAY DO IRREPARABLE HARM. |
| |
| NOTHING SHOULD BE ATTEMPTED HERE BY UNTRAINED SUPPORT PERSONNEL UNDER ANY |
| CIRCUMSTANCES. This appliance is a non-traditional operating system |
| environment, and expertise in a traditional operating system environment |
| in NO WAY constitutes training for supporting this appliance. THOSE WITH |
| EXPERTISE IN OTHER SYSTEMS -- HOWEVER SUPERFICIALLY SIMILAR -- ARE MORE |
| LIKELY TO MISTAKENLY EXECUTE OPERATIONS HERE THAT WILL DO IRREPARABLE |
| HARM. Unless you have been explicitly trained on supporting this |
| appliance via the operating system shell, you should immediately return |
| to the appliance shell. |
| |
| Type "exit" now to return to the appliance shell. |
+-----------------------------------------------------------------------------+
I like how it explicitly says "no, seriously, Mister Unix Wizard, we mean YOU."
This place is a message... and part of a system of messages... pay attention to it!
Sending this message was important to us. We considered ourselves to be a powerful culture.
This place is not a place of honor... no highly esteemed deed is commemorated here... nothing valued is here.
What is here was dangerous and repulsive to us. This message is a warning about danger.
The danger is in a particular location... it increases towards a center... the center of danger is here... of a particular size and shape, and below us.
The danger is still present, in your time, as it was in ours.
The danger is to the body, and it can kill.
The form of the danger is an emanation of energy.
The danger is unleashed only if you substantially disturb this place physically. This place is best shunned and left uninhabited.
I think there's a lot to learn from this message, even in your daily communication with people from other fields of exertise. It's very clear and communicates without any technical terms – if only all error/warning messages were a bit (!) like that.
For reference, the message parent quoted is a Long-time nuclear waste warning message:
I've seen commentary before that this messaging could actually backfire, if you imagine intrepid explorers seeing this message and thinking there must be some great ethereal power located inside, ready to be unleashed with the right set of rituals.
Only way this works is if the one reading it knows your culture was technologically advanced, for-real and not just in your own estimation, and has some appreciation of what that might mean.
Otherwise, "curse of the mummy? LOL, yeah, I'm sure that's a real thing. Must be something great buried here. Watch out for actual traps, but we're about to get rich, boys!"
> Only way this works is if the one reading it knows your culture was technologically advanced, for-real and not just in your own estimation, and has some appreciation of what that might mean.
This is pretty well guaranteed if they can read your message at all.
I alluded to European expeditions to Egypt for a reason :-)
Though maybe there's only a brief window of development in which a culture is both not superstitious enough to be scared by this, and also lacks the technology & knowledge to figure out what you actually mean and verify it themselves.
That's part of the design consideration, and the reason for the emphasis on "no value." I mean, humans gonna human, but you can still try to communicate a difference between "this is dangerous because we booby-trapped our buried treasure" vs "we don't want this."
Right, but that could probably be explained away as “Hah, they couldn’t figure out how to strike a deal with the ethereal being, but we have the best mystic in the tribe with us!”
I’m not saying the experts did a bad job at all. This is probably about the best you could do to communicate with a culture of unknown technological complexity, far off into the future. I’m just saying, as good as it might be, this communication is likely still pretty imperfect :)
> Right, but that could probably be explained away as “Hah, they couldn’t figure out how to strike a deal with the ethereal being, but we have the best mystic in the tribe with us!”
In a way that is true. You could in principle use the radiation from nuclear waste to do useful work (like generate electricity), but our sages haven't figured out a way to do so in a way that makes economic sense to us. The waste could be useful to a different civilization with better technology or worse natural resources.
I wonder if fudging the truth and being less specific is actually better.
"A terrible sickness is contained underground. It kills all who come close. We have done our best to contain it so it does not kill you, our children. We have hidden it. It is very deep. You are safe if you do not dig."
The purpose is not to control people's behavior over the next several thousand years. The purpose is to behave ethically with respect to people over the next several thousand years.
Wow, that brings back memories! I wrote this message, and it was a direct result of some very bad experiences from some people who thought they knew what they were doing -- but in fact had no idea. I don't know how well this message worked, but it warms my heart to see it again; thank you!
//
// Dear maintainer:
//
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 25
//
A small fraction of software developers work on safety-critical software. Safety-critical software is (or at least should be) developed with quite different methodologies, as the cost/benefit assessment is very different regarding development speed against number and nature of defects.
If there are lessons written in blood for the development of safety-critical software, they haven't propagated to the wider field of software development.
(Disclaimer: I don't work on safety-critical software.)
NASA's guidelines are not written in blood, but certainly in lost spacecraft. The most famous is the Mars Climate Orbiter that was lost due to ground system and orbiter using different units of measurement, but that's not the only example [1]
Only one of those particularly affected guidelines. After, anything that might end up in a pure oxygen atmosphere had to be non-inflammable, and very uncomfortable.
And they didn't even get any new regulations written that I've seen. The hand wheels for the horizontal stabilizer trim became too hard for average pilots to physically operate if the aircraft is going too fast and out of trim far enough (even without being outside the safe operating envelope). There was no regulation limiting how much force the trim wheels can need while within the operating envelope. AFAIK, there's still no such regulation. So the "fixed" 737 Max models didn't change the hand wheels, meaning the physical backup in case of a trim runaway might not actually be usable. Yet they certified it without changes, because there's no regulation saying that the safety backup wheels have to be physically usable by average pilots in the event the primary powered system fails!
Are we living in the same world? Encryption, weed, appliances don't do their jobs in the name of efficiency?
Seems like half the time it's the blood of the lobbyist or spook who didn't realize how heavy that suitcase full of benjamins was and the other half of the time it's the blood of whoever got trampeled when the moral panic turned into a moral stampede.
Cheap quips like "regulations are written in blood" are just high brow ways of saying "because I said so".
As the top level commenter points out, these sorts of messages coming from untrustworthy entities who's best interest only aligns with yours in passing are not held in high regard unless they come with some sort of justification since the entities in question (be they oracle or the EPA) do not have the reputation for honesty that they can rely on. If there's really a hazard, communicate the hazard and don't lie about it. The vast majority of the regulation of which you speak is far closer to the "no user serviceable parts inside" end of the spectrum than the "warning, landmines" end and that is why it's not taken seriously.
It really should be applauded, you own this thing and can fully control it, but that means you can do things with it we can’t save you from and will refuse to even try.
No need for a “security” team to lock away access from you, a very stern warning will do.
When I worked support for networking equipment every device had potentially multiple shells or APIs hidden that allowed you to do stuff that really only the engineers who made the thing should do / direct someone to do it.
I often walked trustworthy customers through using them as they knew if they did it then it was on them.
Most likely for support engineers working on "something went really wrong" cases to be able to provide you with debug commands that you should run, or for support engineers to be able to run such commands.
No I did, just not sophiscated to understand all of that. My basic understanding is that they put something in the piece of software that users should absolutely not touch, that's why I asked why it absolutely has be there.
That is, is there any chance that they can remove it from the hand of users without damaging the usability of that piece of software. The other commenters mentioned that support engineers may use it, so that answered my question.
+-----------------------------------------------------------------------------+
| You are entering the operating system shell. By confirming this action in |
| the appliance shell you have agreed that THIS ACTION MAY VOID ANY SUPPORT |
| AGREEMENT. If you do not agree to this -- or do not otherwise understand |
| what you are doing -- you should type "exit" at the shell prompt. EVERY |
| COMMAND THAT YOU EXECUTE HERE IS AUDITED, and support personnel may use |
| this audit trail to substantiate invalidating your support contract. The |
| operating system shell is NOT a supported mechanism for managing this |
| appliance, and COMMANDS EXECUTED HERE MAY DO IRREPARABLE HARM. |
| |
| NOTHING SHOULD BE ATTEMPTED HERE BY UNTRAINED SUPPORT PERSONNEL UNDER ANY |
| CIRCUMSTANCES. This appliance is a non-traditional operating system |
| environment, and expertise in a traditional operating system environment |
| in NO WAY constitutes training for supporting this appliance. THOSE WITH |
| EXPERTISE IN OTHER SYSTEMS -- HOWEVER SUPERFICIALLY SIMILAR -- ARE MORE |
| LIKELY TO MISTAKENLY EXECUTE OPERATIONS HERE THAT WILL DO IRREPARABLE |
| HARM. Unless you have been explicitly trained on supporting this |
| appliance via the operating system shell, you should immediately return |
| to the appliance shell. |
| |
| Type "exit" now to return to the appliance shell. |
+-----------------------------------------------------------------------------+
It depends. If you give a reason why, it opens up the door for people to argue about whether the "why" is a valid justification. It also can make people feel like the "why" does not apply to them.
For a larger, widely used project, the question isn't "why" make something internal, but "why not". The safe default is to not semi-permanently commit every half baked bit of code to the public stable semvered API boundary to support for who knows how many years, but to only do so after careful consideration and justification.
To add this disclaimer to every single bit of internal code is to drown your codebase in a sea of redundant comments - none of which are specific to the code, or even the codebase, but are instead rehashing "why encapsulation?" 101. This will only train readers of your code to ignore the low-value low-signal comments, and they will then end up asking the same question anyways, and "read the comment that's right there!!!111oneoneone" will be a fustrating experience for everyone, although they might not be able to articulate why.
The real question I'm curious about here isn't "why are internal things internal" - but why this internal thing must technically be public. Does this predate ES6 symbols? Is there a plan to switch to those at some point in the future? Is there a tracking issue? Or does this need to be accessed from elsewhere in a manner that makes Symbols awkward to use? Where?
Here it seems "INTERNALS" is the "why". If it's not a public API then of course it could change or disappear without warning between releases (including minor releases).
Ancient vanilla JS can accomplish similar by using wrapper functions.
var React = (function(){
var React = {};
var __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED = {};
...code extending/using React etc...
return React;
})();
// accessible: React.whatever
// inaccessible: __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED
However, there's always caveats where language level access controls don't let you quite express the access restriction you want. Perhaps you want to expose something to other official modules from the same constillation of libraries, for example (meaning you wouldn't be able to use Go's "internal"), without comitting to supporting the semver contract for any other arbitrary user of your API (meaning you might resort to similarly scary names.)
Which is awful, because I've seen a number of FLOSS projects that have perfectly good reusable code in their internal/ subdirectories. And I mean code by no means unique or specific to those projects.
And whoever says something about instability or APIs being subject to change without notice - they're wrong because those are Go git repos and one can always pin to an old tag or even a commit SHA.
If something is unusable (too specific, too fragile, too flaky), no one would use that anyway. A warning is fine and even welcomed, but a block is a slap in the face.
Go did that with casing, so you can tell visibility without lookup or needing to think. The internal/ is a package level restriction, so somewhat orthogonal in that they are for different levels
It's certainly not dumb. If you look at every large library, there are some forbidden internal symbols that are used in a lot of 3rd part projects. Many times those are more stable than the API, and often enough they get published as part of the API once a lot of people decide to depend on them.
It's maybe not dumb to use the forbidden internal symbols, but it's certainly dumb to go ask the folks who through naming and documentation have communicated almost comically loudly and explicitly that they don't want you using the symbols if it's cool if you use the symbols.
You would be surprised about how many times I've seen the internalVariableDoNotUse symbol to be exposed on the formal API of a library because everybody uses it already, it would be too much work to change it.
Interesting point. In naming it this way, the maintainers have committed to firing anyone who uses it, as an implicit guarantee of the public-facing API.
Fortunately they're free to rename it in their next release.
Perhaps something snappy like __secret_internals_do_not_use_or_version_specific_retribution_will_follow_possibly_including_firing
> at one point one of my teammates who is usually very calm and composed deleted some of the internals to “send a message”, which was reverted the next day because it broke a bunch of things for different teams. we didn’t do this again but this started a conversation
Oof. I worked with some people who would declare things deprecated, not discuss the deprecation with anyone, and then remove the deprecated code a short while later even if it was still working just fine.
Same logic: They wanted to "send a message". And it sucked for everyone. Many meetings were had and we usually had to get management to force them to put the (still working) code back and coordinate with other teams on a deprecation schedule.
Please don't force-deprecate things within a company to "send a message" like this. (Note: It wasn't Dan Abramov who did this)
Without a bit more context it's unclear that it was this bad. It sounds like the removed it for one day and then put it back in. This may have been the only way to effectively notify people still relying on it.
We had a deprecated server that we wanted to decommission. We announced this to the entire company. We pointed everyone to the new server, and asked for feedback if it couldn't fulfill any needs that the previous one did not &c. &c. We announced the date the server was going down. We inspected logs and guessed who might still be using it from IP addresses (one of the many reasons for wanting to deprecate the server was there was a single shared login for everyone using it :/)
Finally, on the announced date, we just unplugged the Ethernet cable and got contacted by several different people freaking out, wanting to know what happened to the server. We (as planned) plugged the cable back in and then asked them the same questions that had gone out globally. A month later the server was finally offline for good.
One way of interpreting this is that we unplugged the cable to "send a message" but we obviously did discuss the deprecation with lots of people ahead of time.
I too have learned the value of "turn it off and see who complains" as a last-ditch effort at determining who is still using something and why. It is remarkably effective. However, in at least one case it did take almost an entire week for someone to notice and complain.
This method caused a $10 million dollar, 10 hour long outage at a previous company. You should probably consider who will be complaining in the risk analysis before doing it ;P
There’s honestly no other way to do it. We did this way back when with TLS 1.1 depreciation. We couldn’t use “has anyone connected with TLS 1.1” because all that told us was someone had support for 1.1, not if they could support 1.2. So we turned it off intermittently with increasing frequency to try and generate support tickets.
Those aren't the same thing. A deprecation is a change in contract. A change in contract has to be worked out with consuming teams. In fact that's the whole point of deprecation: to kick off the migration process. Still need the rest of the process.
In contrast, this is about internals, stuff that was never part of a contract but that people use anyway. It comes up a lot in JS because the language doesn't enforce privacy. And it's super painful to not be able to change stuff you never made part of a contract--it freezes your whole codebase.
Is changing internals other people have come to depend on a good idea? Depends on a ton of context, but you should strive for a technical culture that allows this.
I worried somebody would interpret my tweet like this. This is not a fair description of what happened, and it seems like I'm throwing my coworker under the bus by allowing this implication.
When we're deprecating things, we normally keep them for years. In this case, this was not about a deprecation. It's about a case where internal properties were used with a clear agreement with our team that they are not supported, we will remove them without warning, and that the consuming code should always be ready for them to be removed.
When my coworker removed them, he didn’t “just” delete them but he shimmed it so that the consuming code would not crash (but also would not get the functionality). That’s the agreement we had with the teams when these dependencies were added.
The “sending a message” part was that despite our initial agreement, the features were nevertheless being depended on more seriously, and it wasn’t until after this incident that the severity was understood.
I sort of disagree. The best way to make people not rely on a behavior is to not have that behavior. If you want to be very, very sure that nobody relies on your service having very high availability, forcibly reduce its availability. Make sure it fails some small percentage of the time.
Similarly here, if you need to make sure nobody's depending on this thing, change its name regularly. Append a random number to the end of it and change it with each minor release or something.
Now, what you do NOT want to do is randomly pull the plug on your service or change the internals exactly once, with no notice, after a long time of stability. That's not helping people know not to rely on it; that's just hurting people who didn't read the sign. Quietly putting up a "deprecated" sign without ensuring people have time or opportunity to read it, waiting an unreasonably short time, and then breaking things is basically a Douglas Adams storyline more than a development practice.
None were quite so dramatic but I've worked with a few people with this kind of attitude. All of them were more interested in chasing shiny things and their own personal projects than in getting actual valuable work done.
One method I've seen used to motivate people to move away from deprecated API is: after deprecation is announced, in addition to print a length warning message, also add a thread-sleep call, with the sleep length gradually increasing over time. Consequently, the API will remain usable for maybe months after deprecation, but eventually it will become unbearably slow to discourage any continued usage.
> I need access to this queue to decide whether or not the current render was the last for a very custom React component. (YES maybe I can avoid it but currently, this is my requirement) the access must be from inside of this component.
I would love to know what problem they are solving. Whenever you start fighting the framework, you should back up and look for a different approach.
How is React even supposed to know if this is the last render for a component? If the user changes the state, isn't React obviously going to re-render the component?
> As if it were a swarm of bees, you should stay away from the SyncServices folder. Removing or modifying anything in the SyncServices folder - or in any subfolders within it - may cause unexpected issues.
I really don't like Dan Ambramov's style of communication. It's terse, impersonal and authoritative in a way that implies an attitude of "I'm right, you're wrong, stop wasting my time and go away". In my decade plus of experience in the software industry this has been a reliable indicator of the type of people I don't enjoy collaborating with.
I mean, I'm the kind of guy to obsessively worry about diplomacy in professional communications, and my first impulse still would have been to respond with "no" and close the issue, so as far as I'm concerned, he's well ahead of the curve.
I really don't want to put the question-asker on blast, because software is hard, and sometimes you're trapped in a quagmire and just need to fire out a question, but I'm not sure how many ways there are to respond to 'is it safe to push the button labeled "don't push this button, it's unsafe to push it, it's bad to push it, please don't push it, dear God just don't"?' Time is finite and some questions just aren't very good questions.
When I feel the need to contact developers about their code, I tend to think long and hard about whether them responding to my question is a good use of their time. I feel very uncomfortable making requests of others' time frivolously, and asking "is it safe to use this field in production?" would have made me feel as if I was making a fairly brazen demand to address what is ultimately a self-answering question. I probably would have spent some time thinking "is there something different and more useful that I can ask instead?"
In this regard, Dan Ambramov did a good job, as far as I can tell, of iterating and eliciting a useful, actionable feature request from the question-asker. He converted what could have been a negative interaction for both parties into something that potentially improves the project, and it's hard to ask for too much more.
Thank you for your feedback. How would you suggest that I should have responded to this issue instead? I agree that my response was authoritative, but I believe that is what was asked (the issue is seeking an authoritative “official” answer). And from the perspective of not wanting to break this person’s code (or anyone who stumbles upon similar advice), the authoritative “official” answer is an unequivocal no, “this is not supported”, as the name of the property states. Though, like I mentioned, we can’t really tell anyone what to do in their own code, so at best we can say what’s supported and what’s not.
I clicked the link to see what OP's problem was, and I really can't understand how anybody could take issue with the way you write.
I don't use React and I've never come across your name before today, so I think I'm a fairly objective observer. I would prefer that more people wrote like you do - clear, concise and to the point.
Some of this is probably culture shock. Dan grew up in Russia and immigrated to the UK. Russian engineering material is usually very direct. If you do something stupid, then it will say what you are doing is stupid. There is no thought towards the feelings of whoever is told they're doing something stupid. Western textbooks for better or worse try to not be as scathing and try to gently let the reader know that they are going down the wrong path.
I much prefer the Russian approach. We are professionals doing professional work, our feelings are not part of it and if your ego matters to you that's your own problem. It is objectively stupid to use something named __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED because, even if it works, you're not meant to use it! And they made it very, very, unmistakably clear. Dan did the right thing by not budging.
To be clear, I don’t think the person is stupid, and I don’t believe I’ve called them stupid. I appreciate the intent to support me, but I also find it a bit of a stretch that answering “is DO_NOT_USE supported” with “no, it’s not supported” must be a consequence of a culture shock. :) But I’m biased so idk.
I didn’t get the impression from the reader that they were a beginner, or someone struggling, or someone who doesn’t “know they’re on the wrong path”. My impression was that a professional came to get an authoritative answer on a level of support of an API, and I tried to provide it.
Oh, I didn't think you were calling them stupid! That's part of what I mean as the culture shock - that Westerners will respond to being told they're doing something stupid as if it was an insult to themselves, and not an insult on what they're doing, disregarding the fact that smart people can do stupid things and vice versa. What the OP was trying to do _is_ stupid, but that doesn't make them a stupid person. They could in fact be a very experienced engineer who has delivered beautiful and capable web apps. I don't believe your intent was to make the OP feel stupid, but perhaps the lack of sugarcoating and straightforwardness of your response makes it seem like that. I don't think you were impolite either, it's just that terse responses usually signal impatience and may get misconstrued as anger, despite the intent being to clearly communicate a simple message.
Fair enough! I feel like with questions like this, there is a lot at stake because they will be referred to in conversations (“should we use this field? seems like it’s no big deal”) so perhaps some of the bluntness of the property name rubbed off on my response.
Is it about his answers in the thread, or in general? How should he have sugarcoated it?
I'm not sure it's wrong in this case specifically, because an answer to a question like "can I stick my fingers into a power socket" shouldn't be "I'm not sure it's a good idea and we don't support it, but you be you", it should be more like "hey, don't do it, you'll die".
This blows my mind. Dan deals with so much belligerent user feedback and is nearly always positive, understanding and polite. To me he is the gold standard of open source communication.
To me, that's a pretty appropriate reaction. Someone is abusing something that is very explicitly not for that use. At some point, you have to be firm that what's being done is bad, and it being bad should be obvious.
Independent of this subject, he is a very strange person in communication. Take a look at the tweets he shared on his twitter account and you will understand what I mean.
I don't think I claimed it makes me cute? If I want to put a smiley, I do. I asked you a question because I was curious. If you don't want to elaborate and prefer to nitpick on my punctuation, that's cool with me.
It sounds like they're trying to avoid the Windows issue. Where they have incorrect/inefficient/weird behavior carried over from Windows 1.0 because someone somewhere did something they shouldn't have done and now it's expected behavior.
Sim City for Windows 3.x would read memory it recently freed.
This never crashed the program because Windows 3.x was more like a graphical shell on top of DOS. It wasn't a true multi-user or multi-tasking operating system. If you released memory, there wasn't anything else waiting to grab it from you. So the fact that you shouldn't read memory that's been freed, it went unnoticed.
Until they tried to run it on Windows 95. Then it would crash. A lot. The game was unplayable. Because Windows 95 was a multi-tasking operating system and it would reallocate freed memory to other programs that may ask for it.
So they put a specific check in Windows 95 to see if Sim City is running. And if it was, they essentially sandboxed its memory so nothing else could grab any memory it used.
While in this case, this isn't an example of a bug that was intentionally left in, it is an example of code written into an operating system to handle the bug of a single program.
But that's how they'd handle it. If PROGRAM X required certain behavior, they'd check to see if that program was running and alter behavior so the program would run. If feels like that's like half of what the registry is for.
This PDF from Raymond Chen (I don't know the source material) is a great example of the lengths the Windows team had to go to to maintain backwards compatibility between Windows versions. They spent an inordinate amount of time either working directly with application developers or, when that wasn't an option, changing Windows internals specifically to keep problematic Windows apps working.
This resonates: while replacing the obsolete 2d physics in a game to 3d, we renamed the old directories into a long 'dont_include_this', so it was easier to detect in the larger project.
> I'd like to put my hand in the disposal and turn it on so I can catch the lemon seed that's stuck down there and pull it out.
I wouldn't do that, there isn't enough space in there for your hand, a lemon seed is really small, and you will probably lose one or more of your fingers.
> Okay, but I have pretty small hands, and I take ninjitsu classes at the Y, I'm pretty sure I can do it.
OK, I actually know about garbage disposals, because I looked up data on them to use them as an example of something you would not casually hook up to the internet. (The CPSC tabulates reportable injuries on all kinds of consumer products).
About one person per month has a reportable injury due to an unfortunate encounter with a garbage disposal. Most years no one gets their fingers mangled. Also, they don't grind your hand to a bloody stump like you'd imagine from horror novels and movies.
The overwhelming majority of these injuries involve fishing broken glass out by hand. A significant minority of them involve dropping the disposal on oneself while installing or removing one.
So no, they're not "perfectly safe" with the power turned off.
The point is that most people overestimate the one danger and underestimate the others. So you have people having nightmares about a disposal consuming their arm - which literally never happens except in made-up stories - but not hesitating to reach into one to get a broken piece of a glass or jar, in no small part because they think "when the power is off it's perfectly safe to put your hand in the disposal". Not that you could drop it on your foot or something. Besides, the more typical injury is dropping it on your head while you're installing or removing it. See what I mean?
Well but... I feel people get injured from glass in garbage disposals not because they feel specifically safe to stick their hand into one which is off, but because I have a feeling people generally underestimate how nasty broken glass can be. It really is surprisingly easy to get cut on glass if you haven't had to deal with it for a while, and even when trying to be extra careful you can often get cut at least a little (through gloves even).
Doubly so if you are reaching for broken glass somewhere where you can't see, that's basically negligence, but still independent of what else that place could do. I just wonder if it would really be different if it was glass in just a pipe without a garbage disposal.
> I'd like to put my hand in the disposal and turn it on
You are not right (see the detailed sibling comment to your claim to rightness), and either you didn't understand what the original poster actually wrote or you decided to reply to them but say something that's at best tangentially related to their comment and at worst is a pedantic assault on a strawman.
Hence, peak HN.
... actually, "but I'm right!" with no evidence supplied for the assertion might be peak HN.
It is safe to put your hand in a garbage disposal when the power is off! This comment clearly is talking about the safety of your hand from the dangers of a powered-on garbage disposal. The other comment about dropping a garbage dispoal on your foot? no, that does not apply...
No. That was absolutely not the original comment...
The comment which was being replied to talked about the garbage disposal eating the hand. It is possible in any situation to invent other branching scenarios based upon word play off the original intent.
Just look at what started it:
> I'd like to put my hand in the disposal and turn it on
so I can catch the lemon seed that's stuck down there
and pull it out.
I wouldn't do that, there isn't enough space in there for
your hand, a lemon seed is really small, and you will
probably lose one or more of your fingers.
That has nothing to do with glass being in the sink, dropping things on your foot, or any other made up scenario.
Sorry - by "original comment" I meant the sibling comment I was referencing. Wrong word choice on my part.
The sibling comment refuted the idea that it's perfectly safe to stick your in a powered-off disposal, which was the made-up idea in response to the original post introducing the disposal metaphor.
1. What should the API for PutMetricData look like?
2. Where should we store that data?
(you know, minor issues)
At the time, we decided that #1 was more critical than #2 (and of course #2 depends deeply on the answer to #1), and that the best way to solve it would be to do some learning-by-prototyping - stand up an internal version of CloudWatch to dogfood with some other Amazon services and be able to go to prospective internal customers with a "working" service that they could kick the tires on, not just some API docs and paper prototypes. So I quickly hacked up an implementation of "GraniteDataStore" called "InMemoryDataStore", which would store every PutMetricData request in a HashMap and nowhere else.
When I sent the code out for peer review, my reviewer was aghast at the idea that we would stand up a service that would knowingly store different copies of the data on every server, and lose it all on process restart. I responded by renaming InMemoryDataStore to FakeInMemoryDataStore, but that wasn't enough. Finally, we settled on a name of (if memory serves) FakeFakeFakeDataStoreThatLosesAllYourData and that was enough to get my merge approved.