Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

You still get something very close to 64 bits of information, so it would actually work, or at least would work better than converting the integer to double.

Not that it's actually a good idea.

# ? Apr 20, 2017 04:02

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 07:56

zergstain: Dec 15, 2005

Is storing the high and low parts in two 32-bit integers not an option?

# ? Apr 20, 2017 07:20

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

It's essentially an opaque identifier, so like a string or an ArrayBuffer is probably the better representation.

# ? Apr 20, 2017 08:16

vOv: Feb 8, 2014

If you represent them as strings you could compare them for equality easily. I haven't written anything that cares about inodes since OS class so I'm not sure what other things you usually do with em.

# ? Apr 20, 2017 08:24

b0lt: Apr 29, 2005

vOv posted:

If you represent them as strings you could compare them for equality easily. I haven't written anything that cares about inodes since OS class so I'm not sure what other things you usually do with em.

That's the only thing you do with them.

# ? Apr 20, 2017 08:49

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Some platforms have some nonportable functionality to do things with files identified by their inode rather than a path, but that's still just using them as an opaque identifier that happens to be a number.

# ? Apr 20, 2017 17:29

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Recently got hired to replace a retiring greybeard who still writes C# like

C# code:

DatabaseContextWrapper unitOfWork = null;
try
{
    unitOfWork = databaseContextFactory.GetUnitOfWork();
    //etc
}//no catch - this is using but by hand
finally
{
    unitOfWork.Dispose();
}

Also doesn't know/believe in ?? and .? and is bad at naming stuff - but at least he admits that.

This codebase was never too old to not be able to use using, in case someone is thinking it's for style compatibility.

# ? Apr 20, 2017 17:35

CPColin: Sep 9, 2003; Big ol' smile.

And the classic "set a variable to a value and then immediately set it to something else" move. I'm surprised he doesn't set it back to null in the finally block with a "// GC" comment.

# ? Apr 20, 2017 17:46

dwazegek: Feb 11, 2005; WE CAN USE THIS

CPColin posted:

And the classic "set a variable to a value and then immediately set it to something else" move. I'm surprised he doesn't set it back to null in the finally block with a "// GC" comment.

In this case the first null assignment is necessary, otherwise it wouldn't even compile.

The code is also missing a null check in the finally block, which will make debugging all sorts of fun if the factory ever throws. This shouldn't even pass code review, use a goddamn using block, that's what it's for.

# ? Apr 20, 2017 18:13

CPColin: Sep 9, 2003; Big ol' smile.

Ha, the missing null check made me think the assignment was unnecessary!

# ? Apr 20, 2017 18:16

Eggnogium: Jun 1, 2010; Never give an inch! Hnnnghhhhhh!

dwazegek posted:

In this case the first null assignment is necessary, otherwise it wouldn't even compile.

The code is also missing a null check in the finally block, which will make debugging all sorts of fun if the factory ever throws. This shouldn't even pass code review, use a goddamn using block, that's what it's for.

Actually that lurking NullReferenceException is why I think it would just be cleaner to just have DatabaseContextWrapper unitOfWork = databaseContextFactory.GetUnitOfWork() right before the try.

# ? Apr 20, 2017 18:24

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

It wouldn't be that big a mystery to debug because that's all the finally block exists to do and it'd be obvious of something weird was happening like an assignment to the UOW inside the try block, so I'm not super offended by the lack of a null check. I am offended that he didn't bother to learn and use new language features. At least he's not afraid of LINQ as far as I can tell.

# ? Apr 20, 2017 18:39

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Consulting horror time.

I was booked for a one-day session with a customer on writing custom analyzers for SonarQube next week.

Problem 1: The person who booked the engagement assumed I'm a SonarQube expert because I set up a SonarQube instance for a demo once.
Problem 2: I discovered that SonarQube C# analyzers are actually Roslyn analyzers. I haven't messed around with Roslyn analyzers since it was still in beta, several years ago
Problem 3: No one else at the company has ever done this before so we have nothing pre-existing I can borrow and fake my way through the day
Problem 4: Because of Problem #1, no time was allotted for preparation. I am fully committed for the next several weeks.
Problem 5: None of the above matters very much because the audience is manual QA testers.

I sent a semi-polite email to our sales people requesting the following:
1) We involve technical people in sales discussions
2) We stop assuming that because someone has worked with a tool or technology at some point in the past, they are automatically prepared to provide in-depth instruction in any aspect of that tool or technology with zero preparation.

I was also given something for the same customer to have a three-day workshop with non-technical business analysts around how to use SpecFlow to do BDD. Also. they don't have any existing unit testing practices in place. :argh:

# ? Apr 20, 2017 18:42

dwazegek: Feb 11, 2005; WE CAN USE THIS

Eggnogium posted:

Actually that lurking NullReferenceException is why I think it would just be cleaner to just have DatabaseContextWrapper unitOfWork = databaseContextFactory.GetUnitOfWork() right before the try.

Not entirely. This way somewhat forces all usage of the unitOfWork to be in the try scope, which means that it'll always be disposed. With your method someone could accidentally put a call between the assignment and the try scope, which seemingly would work, until it throws, and unitOfWork doesn't get disposed.

There are also a couple of cases where the runtime can insert an exception where you wouldn't expect it. In your case, if that happens after assignment, but before entering the try scope, then unitOfWork wouldn't be disposed. ThreadAbortExeption is the only one that I can think of at the moment, but I'm pretty sure there are a few others.

All of which comes back around to the original point, just use a using block, that would generate code that handles all issues correctly, without the possibility of loving it up, is also far more idiomatic. It also has the added benefit of not allowing unitOfWork to be reassigned again in the try scope, which is an easy way to otherwise miss disposing a disposable resource.

# ? Apr 20, 2017 18:45

Eggnogium: Jun 1, 2010; Never give an inch! Hnnnghhhhhh!

dwazegek posted:

Not entirely. This way somewhat forces all usage of the unitOfWork to be in the try scope, which means that it'll always be disposed. With your method someone could accidentally put a call between the assignment and the try scope, which seemingly would work, until it throws, and unitOfWork doesn't get disposed.

There are also a couple of cases where the runtime can insert an exception where you wouldn't expect it. In your case, if that happens after assignment, but before entering the try scope, then unitOfWork wouldn't be disposed. ThreadAbortExeption is the only one that I can think of at the moment, but I'm pretty sure there are a few others.

All of which comes back around to the original point, just use a using block, that would generate code that handles all issues correctly, without the possibility of loving it up, is also far more idiomatic. It also has the added benefit of not allowing unitOfWork to be reassigned again in the try scope, which is an easy way to otherwise miss disposing a disposable resource.

All good points I didn't think of, and yes we can all agree this is a solved problem with using.

# ? Apr 20, 2017 18:49

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

dwazegek posted:

There are also a couple of cases where the runtime can insert an exception where you wouldn't expect it. In your case, if that happens after assignment, but before entering the try scope, then unitOfWork wouldn't be disposed. ThreadAbortExeption is the only one that I can think of at the moment, but I'm pretty sure there are a few others.

To be fair, I don't believe even a using block will protect you against this. Using -- like foreach, await, lock, and many other keywords --is entirely a C# feature, and all it really does is internally rewrite your code to a more verbose thing that you could've written out manually. And the assignment will not fall within the try-block generated by the using, as mentioned here: https://msdn.microsoft.com/en-us/library/yh598w02.aspx#Anchor_1. So even with using you're potentially susceptible to untimely ThreadAbortExceptions.

With that said, Always Be Using Using.

# ? Apr 20, 2017 18:56

dwazegek: Feb 11, 2005; WE CAN USE THIS

Munkeymon posted:

It wouldn't be that big a mystery to debug because that's all the finally block exists to do and it'd be obvious of something weird was happening like an assignment to the UOW inside the try block, so I'm not super offended by the lack of a null check. I am offended that he didn't bother to learn and use new language features. At least he's not afraid of LINQ as far as I can tell.

Until it makes its way into production, and the original exception is swallowed, leaving you with a log entry relating to the null ref exception that doesn't tell you anything of what actually went wrong.

While I can't be certain what happened here, I have seen similar things with colleagues of mine. Compiler complains about unassigned variable usage? Just initialize it as null, problem solved. At no point do they realize that they just turned a compile time error into a runtime error. Also, if the variable was unassigned in certain code paths before the null assignment, then it should be pretty obvious that the variable is now null in certain code paths, so you probably want a null check.

Your example is definitely something that should be caught in review though. Even if he'd recreated a using block's behavior perfectly, it still wouldn't be acceptable to write that piece of code that way.

# ? Apr 20, 2017 18:57

dwazegek: Feb 11, 2005; WE CAN USE THIS

LOOK I AM A TURTLE posted:

To be fair, I don't believe even a using block will protect you against this. Using -- like foreach, await, lock, and many other keywords --is entirely a C# feature, and all it really does is internally rewrite your code to a more verbose thing that you could've written out manually. And the assignment will not fall within the try-block generated by the using, as mentioned here: https://msdn.microsoft.com/en-us/library/yh598w02.aspx#Anchor_1. So even with using you're potentially susceptible to untimely ThreadAbortExceptions.

With that said, Always Be Using Using.

Huh, I was certain that it generated the assignment in the try block. But after looking at the generated IL, I must be mistaken, it does indeed do as you said. Well, at least I learned something new

# ? Apr 20, 2017 19:10

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

New Yorp New Yorp posted:

to do BDD.

This prompts me to ask for some recommendations for reading on BDD?

# ? Apr 20, 2017 21:22

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Thermopyle posted:

This prompts me to ask for some recommendations for reading on BDD?

Don't. Just write good unit tests. BDD is awesome in a very narrow set of circumstances and of dubious benefit outside of those circumstances. Despite this client being in the "dubious benefit" category, someone with limited understanding sold them buzzwords. :cry:

# ? Apr 20, 2017 22:59

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Overheard at a client, who happens to be 100% Microsoft stack.

"No one on our DevOps team knows PowerShell!"

It turns out they renamed their "ops" team to "devops" and now claim to be doing devops. Beautiful.

# ? Apr 20, 2017 23:05

Hughlander: May 11, 2005

New Yorp New Yorp posted:

Overheard at a client, who happens to be 100% Microsoft stack.

"No one on our DevOps team knows PowerShell!"

It turns out they renamed their "ops" team to "devops" and now claim to be doing devops. Beautiful.

I'll reiterate my position, "If you have a role called Dev Ops you're playing buzz-word bingo, not doing DevOps"

# ? Apr 21, 2017 00:02

Evil_Greven: Feb 20, 2007; Whadda I got to,
whadda I got to do
to wake ya up?

To shake ya up,
to break the structure up!?

Hughlander posted:

I'll reiterate my position, "If you have a role called Dev Ops you're playing buzz-word bingo, not doing DevOps"

Reminds me of this:
https://www.youtube.com/watch?v=nvks70PD0Rs

# ? Apr 21, 2017 00:31

kitten emergency: Jan 13, 2008; get meow this wack-ass crystal prison

New Yorp New Yorp posted:

Overheard at a client, who happens to be 100% Microsoft stack.

"No one on our DevOps team knows PowerShell!"

It turns out they renamed their "ops" team to "devops" and now claim to be doing devops. Beautiful.

lol

# ? Apr 21, 2017 00:38

RandomBlue: Dec 30, 2012; hay guys!; Biscuit Hider

Hughlander posted:

I'll reiterate my position, "If you have a role called Dev Ops you're playing buzz-word bingo, not doing DevOps"

I changed my legal name to Dev Ops.

# ? Apr 21, 2017 01:39

boo_radley: Dec 30, 2005; Politeness costs nothing

RandomBlue posted:

I changed my legal name to Dev Ops.

I'm a dad, so I'm practicing DevPops.

Today: We had an engineer turn over an SSIS package that had a dtsconfig with variables named, ex. PRODSQL, PRODWEBSVR that were all pointing to Dev; a hardcoded reference to test data on a network share; and a hardcoded production db reference. Nobody who's checked it out had been able to make heads or tails of it, and visual studio locks up trying to open it.

He had a Jr Dev do the PR and tried to push it through ci/cd, which refused to deploy it. The go live date for all of this was today, so he called in sick.

# ? Apr 21, 2017 04:50

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Hughlander posted:

I'll reiterate my position, "If you have a role called Dev Ops you're playing buzz-word bingo, not doing DevOps"

I say the same thing. Including to this client. They don't get it.

# ? Apr 21, 2017 06:06

fritz: Jul 26, 2003

boo_radley posted:

The go live date for all of this was today, so he called in sick.

That's an advanced technique.

# ? Apr 21, 2017 14:23

NewForumSoftware: Oct 8, 2016; by Lowtax

boo_radley posted:

The go live date for all of this was today, so he called in sick.

Don't know if I've ever seen this in person but I'll be honest, I kind of feel bad for this guy. Even if he is an idiot.

# ? Apr 21, 2017 15:20

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

NewForumSoftware posted:

Don't know if I've ever seen this in person but I'll be honest, I kind of feel bad for this guy. Even if he is an idiot.

Yeah, sometimes you just get in over your head. Or at least its happened to me. I like to think its happened to most people because it makes me feel better.

# ? Apr 21, 2017 15:28

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Thermopyle posted:

Yeah, sometimes you just get in over your head. Or at least its happened to me. I like to think its happened to most people because it makes me feel better.

It has little to do with it happening(because it is a universal experience), it's about how you handle being in over your head.

# ? Apr 21, 2017 15:30

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Yeah, sure I agree with that.

# ? Apr 21, 2017 16:18

baquerd: Jul 2, 2007; by FactsAreUseless

New Yorp New Yorp posted:

Don't. Just write good unit tests. BDD is awesome in a very narrow set of circumstances and of dubious benefit outside of those circumstances. Despite this client being in the "dubious benefit" category, someone with limited understanding sold them buzzwords.

Strongly disagree. Good component tests are the most important tests. Unit tests are just there as suggestions and guidelines when refactoring, and more importantly to document edge cases that are too annoying/expensive to cover at the component level.

# ? Apr 21, 2017 18:48

Quebec Bagnet: Apr 28, 2009; mess with the honk
you get the bonk; Lipstick Apathy

http://www.audioasylum.com/forums/pcaudio/messages/11/119979.html

quote:

found that a function called memcpy was the culprit, most memory players use memcpy and this is one of the reasons why memory play sounds worse ie digital sounding. Fortunately there is an optimised version of memcpy from http://www.agner.org/optimize/, using this version removes the hard edge produced by memcpy. the other thing I did was to close the file after reading into the buffer.

also most players use malloc to get memory while new is the c++ method and sounds better.

# ? Apr 21, 2017 19:42

RandomBlue: Dec 30, 2012; hay guys!; Biscuit Hider

chmods please posted:

http://www.audioasylum.com/forums/pcaudio/messages/11/119979.html

drat you memcpy and your hard edges!!! :argh:

# ? Apr 21, 2017 22:01

Spatial: Nov 15, 2007

chmods please posted:

http://www.audioasylum.com/forums/pcaudio/messages/11/119979.html

God almighty :newlol:

# ? Apr 21, 2017 22:01

Qwertycoatl: Dec 31, 2008

quote:

Does a while loop sound better than a for loop ? there's something to ponder.

# ? Apr 21, 2017 22:17

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

audio asylum inmate: Did you malloc that fuzzy-rear end sounding poo poo? smh I bet you're not even using a gold-plated motherboard. I prefer the warmer, more authentic sound of new.

# ? Apr 21, 2017 22:20

1337JiveTurkey: Feb 17, 2005

Qwertycoatl posted:

Non-tail recursion so the sound from previous sections of the music don't bleed over to the current one by reusing the stack. :smug:

# ? Apr 21, 2017 22:21

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 07:56

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

quote:

The version in the link is for x64 Intel proceesors

https://rapidshare.com/#myrs_filemanager/file/3363

Apologies for the previous version, I was using while do for the render loop which after a while didn't sound so good so back to while loop which sounded better.

I have updated what to me is the ultimate version as far as sound quality is concerned, it really is very good. No real big changes in the code, just some things I found that made a difference to the sound and then some optimisations.

One of the big finds was
hr = CoInitializeEx(NULL,0x8); //COINIT_SPEED_OVER_MEMORY 0x8

which really brought the sound to another level.

I was reassured that as I optimised for speed the Sound Quality improved.
I was surprised at how big a difference the optimisations made to the sound, you can only do so much with code.

I think this is actually someone doing a clever parody of... something, don't know what tbh

# ? Apr 21, 2017 22:25

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »