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 - "debugger is the bug"
-
What's the worst bug? Schrödinger's bug, one that only appears when the debugger is not attached, and your test instruments are disabled.12
-
The problem with working on a debugger for a living is that you can end up debugging a debugger debugging a debugger that is remotely debugging a debugger which is debugging a program...
...only to find out there's a bug in the first debugger and you need to debug it.4 -
writing library code is hard.
there are sooo many details that go into writing good libraries:
designing intuitive and powerful apis
deciding good api option defaults, disallowing or warning for illegal operations
knowing when to throw, knowing when to warn/log
handling edge cases
having good code coverage with tests that doesn't suck shit, while ensuring thry don't take a hundred years to run
making the code easy to read, to maintain, robust
and also not vulnerable, which is probably the most overlooked quality.
"too many classes, too little classes"
the functions do too much it's hard to follow them
or the functions are so well abstracted, that every function has 1 line of code, resulting in code that is even harder to understand or debug (have fun drowning in those immense stack traces)
don't forget to be disciplined about the documentation.
most of these things are
deeply affected by the ecosystem, the tools of the language you're writing this in:
like 5 years ago I hated coding in nodejs, because I didn't know about linters, and now we have tools like eslint or babel, so it's more passable now
but now dealing with webpack/babel configs and plugins can literally obliterate your asshole.
some languages don't even have a stable line by line debugger (hard pass for me)
then there's also the several phases of the project:
you first conceive the idea, the api, and try to implement it, write some md's of usage examples.
as you do that, you iterate on the api, you notice that it could better, so you redesign it. once, twice, thrice.
so at that point you're spending days, weeks on this side project, and your boss is like "what the fuck are you doing right now?"
then, you reach fuckinnnnng 0.1.0, with a "frozen" api, put it on github with a shitton of badges like the badge whore you are.
then you drop it on forums, and slack communities and irc, and what do you get?
half of the community wants to ban you for doing self promotion
the other half thinks either
a) your library api is shitty
b) has no real need for it
c) "why reinvent the wheel bruh"
that's one scenario,
the other scenario is the project starts to get traction.
people start to star it and shit.
but now you have one peoblem you didn't have before: humans.
all sorts of shit:
people treating you like shit as if they were premium users.
people posting majestically written issues with titles like "people help, me no work, here" with bodies like "HAAAAAAAAAALP".
and if you have the blessing to work in the current js ecosystem, issues like "this doesn't work with esm, unpkg, cdnjs, babel, webpack, parcel, buble, A BROWSER".
with some occasional lunatic complaining about IE 4 having a very weird, obscure bug.
not the best prospect either.3 -
today I experienced real-time bug fixing and deployment..
The phone was attached to the debugger, the client is using the app, me catching the logs.
Client: oh here is wrong behavior.
Me: *tapping on keyboard, then* ok try now please..
😅2 -
Finally fixing a 16 hour bug that was harassing my thoughts is a very good feeling.
Sleep is the ultimate debugging debugger.1 -
Took me 6+ full days.
The feature does not work. Repro is unknown, so only prod is experiencing the issue.. Which rules out the debugger option. Sometimes there's an entry seen in logs: "java.lang.StringIndexOutOfBoundsException". Nothing more - just that. No stack, no class, no nothing. Is it my code that's buggy? Is it some config? Integration? Unexpected response...? A bug in a lib? Is dimm faulty ir maybe server's shared libs are off?
Turns out I used a closing parentheses instead a closing curly bracket in an error message that's supposed to be interpolated...
String message = "{some-business-rule-related-error-message-key)";
took me 6+ full days... But I found it. Took the rest of that Friday off to walk in a park and enjoy my life :)9 -
Today I found a critical bug to our software and wrote a fix and tested it locally.
Common sense would dictate that especially when it is critical you test said fix on a real release and not with a debugger attached and running onna different device altogether.
I was denied this request because the afflicted machines engineer would not be able to finish the machine before the factory acceptence test.
I stood there with glassed over eyes for a second and then to no avail tried to explain that without this fix he wouldnt even pass the internal acceptance test......12 -
Debugging JS,
*uses chrome devtools*, breakpoints work, everything loads, can work on fixing bug
*uses firefox devtools*, takes more time than IE to show up, the UI doesn't show up, can cry in the corner.
Why is firefox debugger so bad :/6 -
Textbook definition of insanity is debugging in Spyder
While True:
Do:
#Comment out code
Run
If not BUG:
Comment back in
Else:
Print('Congratulations. You found it. Just kidding. It's not THIS line. It's just the combination of lines')
Does anyone have a suggestion for a good python debugger that allows jumping to statements, etc.?2 -
I’m an idiot. Stackoverflow issue that I documented to a T. Javascript. So I put requirement of not having jquery or framework.
Get a comment about do I know it is working? My answer, debugging. They respond back with a question about debugging and some details I totally didn’t read.
Well, that was the bug. Chrome debugger was showing a message I didn’t understand. So they answered my problem perfectly.
But before realizing he answered my issue, I blew up. Of course I know what is going on. The debugger is showing me....did you even run my example?
I almost felt like giving up as a developer. Here is this awesome guy, solving my issue, and some dumbass like me has to be frustrated. Now he won’t respond to take a bounty he so awesomely deserves.
I’m still a dev. I just don’t feel so professional anymore... -
when the website is so huge and a bug is causing every to be delayed a minute before loading, the debugger isn't showing anything, and the project lead's best solution is to throw more RAM at it
-
Magento Debugging Horror!
Changing lots of things in magento with no problem. Continuing development for quite sometime. Suddenly decide to clear cache to see affect of a change on a template in frontent. Suddenly magento crashes! There's no error message. No exception log. No log in any file anywhere on the disk. All that happens is that magento suddenly returns you to the home page!
Reverting all the changes to the template. Clear the cache. Nope! Still the same! Why? Because the problem has happened somewhere in your code. Magento just didn't face it, because it was using an older version of your code. How? Because magento 2 even caches code! Not the php opcache. Don't get me wrong. It has it's own cache for code, in a folder called generated. Now that you cleared all the caches including this folder, you just realized that, somewhere something is wrong. But there is no way for you to know where as there is absolutely no exception logged anywhere!
So you debug the code, from index.php, down to the deepest levels of hell. In a normal php code, once the exception happens, you should see the control jumps to an exception handler, there, you can see the exception object and its call stack in your debugger. But that's not the case with magento.
Your debugger suddenly jumps to a function named:
write_close();
That's all. No exception object. No call stack. No way to figure out why it failed. So you decide to debug into each and every step to figure out where it crashes. The way magento renders response to each request is that, it calls a plugin, which calls a plugin loop, which calls another plugin, which calls a list of plugins, which calls a plugin loop, which calls another plugin.....
And if in each step, just by accident, instead of step through, you use the step over command of your debugger, the crash happens suddenly and you end up with the same freaking write_close() function with no idea what went wrong and where the error happened! You spend a whole day, to figure out, that this is actually a bug in core of magento, they simply introduced after your recent update of magento core to the latest STABLE version!!! It was not your mistake. They ruined their own code for the thousandth of time. You just didn't notice it, because as I said, you didn't clear the `generated` folder, therefore using an older version of everything!
Now that after spending 7 hours figuring out what has failed with absolutely no standard way of debugging and within a spaghetti of GOTO commands (Magento calls them plugin), why not report it to github? So you report it with a pull request. This also takes 1 hour of your time. Just to next day get informed that your pull request is rejected because another person already fixed the bug and made the same pull request. It was just not on the latest stable version yet!
So you decide to avoid updating magento as much as possible. Because you know that the next Stable version will make your life and career unstable. But then the customer complains that the Admin Panel is warning him of using old Magento version which might pose SECURITY THREATS! -
I miss bug hunting... Baking new features is far less fun than debugging all sorts of weird issues across all the layers of the setup. Devops has its charm, but still I find myself looking for problems more often than tinkering with devtools.
I wish there was a "debugger" role in my company.7 -
Whenever there's an annoying bug that refuses to go no matter what I do, I just go to sleep. Sleep is the best debugger.
-
On the one hand, I'm done with all of the major bugs in a piece we're getting ready to launch this month.
On the other hand, there's one lingering bug that only appears when I've got Query Monitor running, because WooCommerce throws a false positive "table does not exist" error, which it tries to backtrace through **39** layers of functions, eating all of the memory.
Turning off Query Monitor fixes this, but means I basically have to flip it off before the primary function of the software and flip it back on afterward.
Currently considering the best way to put off the WooCommerce activation for a point where there isn't so much going on...