Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "fuck cabling"
-
Built a C#/.NET application with support for a serial device. Tested it on systems A, B, C initially, all Windows system, same .NET version, same targeting, same build tool version, same initial connection configuration etc, etc.
Testing - works on A and C, B nopes.
...
OK, let's check the source, is there something about B that makes it impossible to execute that bit? - No, there is not, you checked that already, stop poking around, it definitively should work on B.
...
OK, maybe admin privileges, there is I/O involved, didn't need that on A and C, but who knows - nope, doesn't work on B.
...
OK, maybe something wrong with the connection settings? First try at reinstalling driver - but no, it doesn't work on B.
...
OK let's try with another device - more/less devices on B. Other USB ports. No. Still does not work on B.
...
OK, this is stupid, but, is the cabling alright? It is, of course it is, stupid - but it still does not work on B.
...
OK, at that point I'm just gonna ask a colleague, GrumpySoftwareDev whether he has any clue why it doesn't work on B. GrumpySoftwareDev knows nothing, but discovers that one of his applications doesn't work on Windows 10. You know nothing, Jon Snow, but it doesn't work on B.
...
OK, now I'm just going to ask another colleague TheLastOfHisKind who handed B down to me somewhat bluntly if he ever experienced problems when working with B and its serial configuration. TheLastOfHisKind tells me he does not and kindly offers me some input on the situation. Still no progress to get it working on B but he hinted he might have fucked up B's driver. I already reinstalled the driver but didn't reboot, which comes after reinstall.
...
OK, I'm just gonna remove and re-install the driver, then restart. Hu! Now the UI is gone but another serial device reacted on a general call. Not fully working on B but we're getting there.
...
OK, I don't know, I'm getting frustrated, let's borrow another system D - which has roughly the same configuration as B - from my colleague StrongCurrentGuy. StrongCurrentGuy borrows me his system and cautions me not to break it. I install the driver, plug the device and copy the application from B. It just works on D. Not on B though.
...
OK, you know what. I'm done. For shits and giggles I'm gonna remove that driver again, reinstall it and restart, maybe it'll magically work afterwar- WHAT THE HELL, I JUST OPENED IT AFTER RESTARTING, IT JUST WORKS - ON B!
... seriously, what the fuck. But yeah, at least it works now.4 -
This weeks question fits me well, as I am still unsure about the full details of how the fuck this all came together and was about to just rant about it anyway.
Ever since this companies network equipment and cabling has been updated, a lot of vital tools went down and bug out every now and then, at seemingly random times.
The codebase is a horrible mess to begin with and random things execute at random times and at random places spread all over different resources that get random hooks from random physical values etc.
Turns out (or at least what it so far seems like) all of them somehow sync their clock and other variables based on how many (valid-?) requests it gets per measured time and similar oddities, so when the network equipment got updated, that meant that multiple processes now could reach each other much faster and therefore threw off thousands of values and internal clocks.
There's a total of like 600 systems that are all "separate" from each other but all need to communicate in-sync for the production chain to properly work. Thankfully I didn't sign anything yet, so might actually just redirect them to somebody else, I am not ready to age 20 years, even for the amount that would pay.1