Greg Burghardt

I think this answers the question most directly. I don't think anyone in any specialty or field can use GPT-3 blindly. You need to do more than proofread it. You need proficiency in your own native language, English, and your area of research to really know if the ideas and concepts have translated accurately. This is a dangerous road, indeed. Your target audience is humans, and semantics are important. GPT-3 isn't yet up to this task.

@Basilevs I think that is the root cause. It's hard sometimes. I've done this before too. I try to make a point with a little flair (because otherwise it's a boring conversation about software) but the message I think I'm sending is not the message people are receiving.

That's the perspective I'm taking on "refactoring doesn't exist."

As an illustration, imagine if I asserted that digging holes never happens, because you ultimately fill it with something like gravel, cement, or sand. But at some point you had a hole in the ground before you filled it.

Even if the end result of implementing a feature means it looks as if refactoring never happened, that doesn't mean it didn't happen. It might have been the first in a series of 5 commits, but at some point it did happen.

Let me rephrase...

Otherwise, I think your answer is bang on what the OP needs.

I think "big picture" your could say that the net effect is that the refactoring didn't happen, but in the moment where you are evolving the application structure in a backwards compatible way, you are refactoring; that is what I am saying, and why your question got a down-vote.

While I see your point — refactoring doesn't happen in a vacuum — you also cannot define that little picture activity in terms of the bigger picture. This is one of those rare cases where you do need to focus on the little picture.

And sometimes people just need to see a smaller pull request to review something. There's always that, too.

Refactoring is a little picture activity done with the bigger picture in mind, but the intent is for that little picture change (that one commit) to get merged in with the possibility that the bigger picture never comes to fruition. You at least leave the application in a little better state than when you started.

I think that might be where a lot of people (including me) have a different idea about refactoring — it is about commits. It is about making some progress that won't go stale in some topic branch if you get pulled away. It's about integrating that work with other people's work in case it causes problems.

(2/2) A high priority bug might take you away from a feature. Now that refactoring commit goes to production without the associated feature implementation. A prerequisite for refactoring is having enough test coverage to feel confident you haven't introduced a regression. That's why refactoring exists. Done right it can be done by itself safely so you can respond to changing priorities without leaving a bunch of work in progress.

"Therefore, all code changes have to lead to behavior changes." — Be careful not to jump too far ahead. Even if the ultimate goal is to change something, the actual commit in version control doesn't change outward behavior. Potentially that change can be merged in safely provided you have good enough test coverage. (1/2)

You should research this, starting with @Steve's answer to this question. You have some misunderstandings about what constitutes refactoring.

@Dess, I think the heart of this answer is that you've done the experiment part, and now you've identified a more optimal structure. This answer is saying you need to split the changes you made in two: one PR to restructure, and a second PR to implement the new feature on top of the new structure. If this is not possible without breaking things then you aren't refactoring; you are rewriting.

And Basilevs, refactoring means changing the code without changing it's behavior (ignoring other distinctions like changes to code structure being "not refactoring"). Refactoring absolutely does exist, and your answer will continue to be down voted because of that assertion. Ignoring the literal interpretation of that first sentence, I do agree that we refactor for bugs and enhancements. You can refractor outside of that, even if it is perhaps premature to do so. It's a technicality that is preventing me from up-voting your answer, and is causing others to down-vote.

I think people are getting hung up on the very first sentence: "refactoring doesn't exist." If you ignore the TLDR, I think this answer is really good advice. If I understand your answer correctly, it's not that refactoring doesn't exist, it's that you need a goal, and it's hard to find a goal without doing some changes first before you scrap your work and start over. Experiment first.

What's to stop a clever person from claiming a business and then trash-talking people who leave reviews, or uploading incorrect photos? Or entering incorrect hours of operation? Maybe they state the business is closed on Saturdays (typically the busiest day of the week hypothetically) so people go next door to a business that is open? And the person perpetrating this fraud doesn't own the location; they own the business next door.

I think you might be getting stuck in the weeds here. You bring up valid points, but they are no more troublesome than what Google maps already provides.

And "indicate the business is in a restricted area" is completely different than "block access."

I also read once (I've since forgotten the source) that Google maps was struggling with law firms adding invalid locations. The law firms were real, but didn't actually have a physical office located at the address they indicated on their business record. The intent was not fraud, but to appear in local search results when people searched Google maps for law firms. Consumers and app developers incur some risk using these mapping services, and there doesn't appear to be a good workaround (hence the OP's question).

@Basilevs: Google already allows people to log in and "claim" their business so they can curate the Google maps business record. There is nothing inherently "invalid" about option 2, and it does not introduce any more risk than already exists in Google maps. To my knowledge, there is an approval process before you can "claim" your business record, but that won't prevent clever fraudsters from screwing with things. That's also why you shouldn't rely on these mapping services for legally verified information.

@Joachim That question appears to be about intellectual property laws, which is off-topic for this community as well.

I added a paragraph towards the beginning of my answer. I made an assumption that wasn't true. I assumed people would know not to just scale horizontally during times of slowness.

Ok, I think I see what you are aiming at.

It is probably configurable to a certain extent.

I'm not sure what the criteria is for these systems to determine when to spawn a new instance.

My answer has nothing to do with creating more message processors. It has to do with slowing down the existing processors.

This might be highly dependent on the system used to manage message processors.

I always thought these systems scaled horizontally when incoming traffic ramped up. This question implies the incoming traffic has ramped up, but the downstream dependencies are running slow.

The general idea is to slow down message processing. Adding instances of the message processor isn't going to slow down message processing.

I'm a little unsure how to clarify my answer, then. Why would you report DB delays to the cluster controller? I haven't done a lot of configuration work with these, so this might simply be a blindspot in my skillset.

Just for clarity, MP = Message Process, right?

I guess I'm confused why someone would ever scale up the number of instances when each one is running slow.

I assumed, based on the OP's question, that they would know not to do that. Perhaps I made an assumption that isn't true?

@Basilevs, if you have 1500 instances that are not doing any work, then how would 1 instance be able to accomplish anything?

And that's where increasing the queue size is essential. You don't want your queue to accommodate nominal usage. You need the queue size to accommodate the surge in traffic so your service can work through those messages at a pace the database can handle. Otherwise, you are just pushing this problem around, not solving it. You need a buffer, and the bigger message queue provides that buffer.

@jcollum, there are lots of bottlenecks besides CPU usage. Today, CPU usage is the bottleneck. Tomorrow? It could be I/O, or network, or memory. So, you check CPU usage and it returns 10%, but the database is running at 99.2% RAM usage. CPU is not the issue. It will still run slow. Don't tie your metric to a specific performance indicator in the database. You want to target something more general so you don't need to tweak your heuristic because you encounter an unforeseen bottleneck.

I feel like there should be plenty of prior art for "don't do things as fast when something is busy" but alas, I'm not a lawyer willing to fight the battle... or a lawyer.

I feel like there was another question in this community --- maybe one of the English language related Stacks --- that asked about using LLM's to correct grammar and style errors in academic papers when they were a non-English speaker. I wish I could find the question now. It was a great example of using AI as a legitimate tool, rather than trying to "cheat the system."

To be honest, I've never heard it pronounced it misdook.

I like this approach, because it gives people an opportunity to learn how to use ChatGPT as a tool, while still requiring the student to actually learn the skill. More than likely, machine learning will be tools that people use at their jobs, which requires 2 things: the person understands the base-level skills (learned in an educational setting) and the person understands how to use the tool. Understanding the skills and the tool will make that person more effective. Pandora's Box is open. We cannot close it. Just work with it. The rest is up to the student.

"So if something cannot be destroyed then it follows that it cannot be created." -- I don't see how one follows the other. Maybe I'm missing some philosophical argument here?

Didn't approximately the entire planet basically do this in 2020? How did we survive...

@Michael Unfortunately down-votes are common. This community has struggled for years to define itself. In the last several years, "good on-topic" questions tend to be very small in scope. I don't have a canonical list of good questions. I would say the best you can get is "highest voted questions within the past 3 years that have not been closed." And even then, you'll find some questions that would be closed today even though they were asked only a year ago.

I think questions about the history of something are more appropriate for a general purpose forum like Quora.

You also happened to pick a "name this thing" question. Naming things is notoriously subjective. Looking at the history of that question shows that votes were all over the place. Lots of up and down votes.

@Michael, a question simply containing text that reads roughly "are there any resources" does not necessarily mean the question is off topic. Many times people ask a perfectly on-topic question and include things like "is there any official documentation?" The heart of the question is not "where is the documentation". The title of the question is "Looking for the name for an abstract class that models functions as objects". The focus of the question is not finding resources.

That would fall into "asking for resources" which is also off-topic.