Yep. The lack of a using/dispose is what put a spotlight on this piece of code because of the max connections exception that was thrown. Easy mistake to overlook.

The code above is in a one-time-use utility app that migrates data from one db schema to a refactored schema in another db which is why I wasn't concerned about the prepared statement that doesn't utilize parameterization.

Great discussion everybody, and thanks @Voxera for the interesting points you brought up

@Sid2006 yep. Didn't say it was. But it does make one single environment for all by running the same image in each container. That's how it addresses the "it works on my machine" really well.

If it's backend code, Docker to the rescue!

(2 of 2)

The new value to assign should only be assigned if it is bigger than the current value. Because of the mistake of passing the same parameter twice to Math.Max, each thread would replace the current value for its scriptId with every new potential value, even if it was lower than the previous one.

So in terms of the race condition, for each scriptId, if thread A assigns a value of 2 and later thread B assigns a value of 4, then there's no problem and everything works. But if thread B beat thread A to it, then thread B's value of 4 would be replaced by thread A's value of 2, and that's the problem.

Hey all. I'll give a little more context.

(1 of 2)

This is a specific, single line inside a batch of code that is running in multiple threads. Each thread has a batch of work to do for a particular scriptId, and each one potentially updates this particular dictionary of values. Without explaining all the details, multiple threads sometimes perform work for the same scriptId, but will produce a different value. This dictionary above is only interested in the largest value produced for each scriptId (The line resides within a lock block for thread safety, but I didn't show that part, only the line with the offending bug).

I agree with the prognosis of burnout. I relate. And getting ripped out of focus is quite painful, especially repeatedly so. It's almost like there's a physical consequence and it takes a toll on your brain. As far as addressing burnout, I find putting more time into a personal hobby helps me a lot. "This too, shall pass".

@Jilano it's not so bad, they're not completely the same. @C0D4 has clearly seen more sun than me.

@C0D4 omg I am so dense, wow. I re-read what Jilano wrote a few times and it never clicked. It's been a long day.

@C0D4 What's the inside joke all about?

@NoToJavaScript definitely, there are other ways to write it. Arguably better ways. The methods as they are could be abstracting away necessary logic internally, which was my primary point that I attempted to convey over the course of way too many words.

.

@NoToJavaScript that's manipulating a request, as in a single object, in this case a DTO. As such it's a builder pattern which abstracts away some of the details on how to add those optional properties. There may be some business logic like adding necessary headers or other sets etc that the package manages for each. Those are ok imo. That's not the same thing as a chain of jQuery (or similar) that is doing who knows what with the DOM of a webpage on each chained function as previously mentioned in this thread. Even still though there are other ways to write it.

Imo, in specific, selective situations (like manipulating generic data structures) it can be tolerated but know what it's doing in each situation and make smart decisions. Be able to back it up when critiqued.

Never thought of it like this. Awesome.

All those great events and such can be a cover-up/apology/excuse for how shitty you're treated.

Spaghetti is on the menu.

@bahua let's keep those buildings strong and true 👍

Y has a vertical line in the character symbol, so it's the vertical axis on a graph.

Also: experienced people who know what they're talking about also are aware that there's a lot they don't know (giving ground to second guessing). If you were going into this with no doubt nor worry at all you might be an inexperienced noob who has no business making those decisions. Look up the Dunning-Kruger Effect.

Second guessing your decisions is an extremely healthy exercise, especially when you feel you need somebody to guide you. Second guessing means lots of independent research to CYA. That's one way to become an experienced, senior-level lead that other people can rely on.

You have chosen wisely.

@Wisecrack very interesting. My assumption was about users here or on whatever platform it is clicking on their links and then giving them money directly somehow either from buying whatever literal product they are selling or handing over their credit cards through a phishing scheme of some kind. That, I can't imagine is very lucrative on a place like devRant or similar when the average user base has a certain degree of intelligence to see through that.

But, what you are describing is more like boosting numbers in any form like clicks or visits or search engine relevancy through link-backs, etc, is that right? That's probably their main motivation? I hadn't thought about it from that angle.

@Gregozor2121 the rant is about spam in general, and I use devRant as an example. No devRant tag needed.

Happy birthday!

then

@Demolishun what happens when you change your shirt, get a new pet tiger, get an energy drink?!?!

avatar.Subscribe("onChange", orderNewMousePad);

I might endure the woes you mention for a hoodie, but that's probably it for me.

@C0D4 gotcha. Honestly we have the same issue over here in our legacy code. We used to do those kinds of practices, and over the course of the last couple years we've been spending so much effort shifting away from it into a microservice architecture (which is such a breath of fresh air). This recent proposal prompted the "lashings" comment because, "Don't you dare undo all our work by making more tangled messes!"

@C0D4 there are exceptions, of course, where something like that can make sense.

I don't think it should never be the norm, though.

Outside of the exceptions, writing code like that forces a certain infrastructure behind it, which is a smell. The code shouldn't be the one to dictate that. In this example, all the databases involved have to have visibility to each other. They have to be on the same machine or on a network where they can communicate driven by the proc's instructions. They're tightly coupled which hinders the ability to scale easily.

@C0D4 I'm in the same boat. About 8 years ago I co-founded a software company as the only software engineer. 8 years later, we have ~60 GitHub repositories for all the code involved, from UI to server-side business logic to databases. I wrote a HUGE percentage of that code, probably near 80-90%. While I'll argue all day that my front-end skills are quite good, I'll readily admit that my back-end skills are stronger. It's accurate for me to call myself a full-stack dev. I can complete whatever needs to be done and do it well, but I also admit that there's stuff about it (including every facet of what I do) that I don't quite know. I'm not suffering from Dunning-Kruger. My JavaScript and CSS knowledge are not up to date to the latest and greatest. They're dated, mostly because I've been full-stack and haven't had time to keep up/specialize. That's the full-stack weakness.

So, I'm a back-end engineer with [a whole lot of] full stack experience.

/shrug

My preferred wording is:

"Back-end engineer with full stack experience"

"Front-end engineer with full stack experience"

etc