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
-
I get a call: "Hey the site is down. Fix it!"
Worked on my workstation, not on my phone => DNS issue.
Local cache: "All OK"
ISP's DNS: "No record"
Google DNS: "Server error"
MXToolbox: "All OK"
CloudFlare DNS: "Domain? What domain?"
After a day of fucking around with configs and wanting to strangle the customer support guy, I just started pressing buttons, until suddenly, it worked. Turns out I'd accidentally enabled DNSSEC on a domain, that wasn't configured for it.
Lesson learned: There is no official DNS error code for "DNSSEC failed somewhere upstream". If you're lucky, you might get something useful out of the authoritative server, but apparently not on Mondays.8 -
WordPress related, get ready for some disgust.
So today early in the morning my boss forwarded me an email from a client, it was about a bug, and asked me if I can have a look at it and fix it.
"Yaay, WordPress!" I thought and opened the page containing the mentioned bug. She wrote that in the italian version of the page, users can select dates in the calendar, which should be disabled, like in the german version.
So yeah, I opened the code. Everything in the function looked perfect. Really. And the Data was also correctly set in the backend of WP.
The function was only 3 lines of code:
- Get the german post ID of the current post (german or italian) by its ID (using a Polylang function)
- Get an Advanced Custom Fields field by name and from a post with the ID from before
- json_encode its content and echo it to a JS var for initialization and later use in some AngularJS.
No fucking missing semicolon, it was fucking perfect like a sunset with your soulmate.
So I tried to find the bug with my personal way of debugging:
"Shitstream Debugging"
When a creek suddenly is full of water mixed with shit, walk upstream through the turds until you reach clear water. This is where the bug is.
=> So I first looked at the HTML source: Turds.
=> Then the ACF field content: Still turds.
=> Then the ID of the german post: Shit stain and turds (var_dump: null)
=> Please god at least $post->ID? Nope, fart smell and turds.
=> Nothing more to check: Clear fucking water and the flowery smell of 99 devVirgins
So it replaced $post->IT with get_the_ID() and it worked like a charm.
Afterwards I feel stupid, but $post->IT worked all the times before...
Conclusion:
FUCK YOU WORDPRESS YOU UGLY PIECE OF HUMAN-CENTIPEDE-PROCESSED-DOGFART.
Thanks for your patience.
Only one beer was sucked dry during the writing of this fucking rant.2 -
I wish my clients would stop reporting "bugs" in my app that are legitimate results calculated from crap feed to it by their upstream systems.
Just because my app is easy to use it's the first place that they find out that their ecosystem is fundamentally broken.
GIGO, people.1 -
Submitting a pull request seems a good way to end the week. That's what I love about (some) projects on GitHub; instead of just ranting about bugs or out-of-sync documentation, you can fix the problem and send a pull request upstream. :-)2
-
I used to think that I had matured. That I should stop letting my emotions get the better of me. Turns out there's only so much one can bottle up before it snaps.
Allow me to introduce you folks to this wonderful piece of software: PaddleOCR (https://github.com/PaddlePaddle/...). At this time I'll gladly take any free OCR library that isn't Tesseract. I saw the thing, thought: "Heh. 3 lines quick start. Cool.", and the accuracy is decent. I thought it was a treasure trove that I could shill to other people. That was before I found out how shit of a package it is.
First test, I found out that logging is enabled by default. Sure, logging is good. But I was already rocking my own logger, and I wanted it to shut the fuck up about its log because it was noise to the stuffs I actually wanted to log. Could not intercept its logging events, and somehow just importing it set the global logging level from INFO to DEBUG. Maybe it's Python's quirk, who knows. Check the source code, ah, the constructors gaves `show_log` arg to control logging. The fuck? Why? Why not let the user opt into your logs? Why is the logging on by default?
But sure, it's just logging. Surely, no big deal. SURELY, it's got decent documentation that is easily searchable. Oh, oh sweet summer child, there ain't. Docs are just some loosely bundled together Markdowns chucked into /doc. Hey, docs at least. Surely, surely there's something somewhere about all the args to the OCRer constructor somewhere. NOPE! Turns out, all the args, you gotta reference its `--help` switch on the command line. And like all "good" software from academia, unless you're part of academia, it's obtuse as fuck. Fine, fuck it, back to /doc, and it took me 10 minutes of rummaging to find the correct Markdown file that describes the params. And good-fucking-luck to you trying to translate all them command line args into Python constructor params.
"But PTH, you're overreacting!". No, fuck you, I'm not. Guess whose code broke today because of a 4th number version bump. Yes, you are reading correctly: My code broke, because of a 4th number version bump, from 2.6.0.1, to 2.6.0.2, introducing a breaking change. Why? Because apparently, upstream decided to nest the OCR result in another layer. Fuck knows why. They did change the doc. Guess what they didn't do. PROVIDING, A DAMN, RELEASE NOTE. Checked their repo, checked their tags, nothing marking any releases from the 3rd number. All releases goes straight to PyPI, quietly, silently, like a moron. And bless you if you tell me "Well you should have reviewed the docs". If you do that for your project, for all of your dependencies, my condolences.
Could I just fix it? Yes. Without ranting? Yes. But for fuck sake if you're writing software for a wide audience you're kinda expected to be even more sane in your software's structure and release conventions. Not this. And note: The people writing this, aren't random people without coding expertise. But man they feel like they are.5 -
Spent last 2 days trying to get an upstream data file loaded. I've now concluded it's just corrupted during transfer beyond repair... But I got to practice lots of Linux commands trying to figure out what the issue was and fix it (xml parser was throwing some error about nulls originally)
vi, grep, head, tail, sed, tr, wc, nohup, gzip, gunzip, input output redirection -
Note to self: *ALWAYS* pull updates from upstream before starting to add or fix stuff in a GitHub project. Or any other collaborative project for that matter.
Now, it's time to slap myself for forgetting... -
https://i.imgflip.com/2i02zy.jpg
git branch -r
origin/204/match-dsteem-on-sign-transaction
origin/305-support-hive-legacy-api
origin/307-call-async
origin/72-http-socket-support
origin/HEAD -> origin/dev
origin/appbase-http
origin/chore/fix-ws
origin/default-server
but
git push --follow-tags https://github.com/lopudesigns/... --set-upstream origin dev
fatal: refs/remotes/origin/HEAD cannot be resolved to branch.
wut -
So I'm assigned once again to fix a new someone else created and that seems to be the case whenever there's an issue...
Boss just assigns it to whoever is most likely to be able to investigate it... which is basically me. Other than the little time I can use to develop stuff, I'm usually cleaning up other people's messes.
And these other people are to busy working on new crap to properly explain how their existing code/processes/changes works.
And well the fact that anything breaks in production (that's not due to upstream one off issues) whoever does not think he needs to take responsibility for it.
So everyone else and especially me has to spend time understanding the shit they wrote and fixing it for them.
How do I tell my boss this nicely that we need clearly definitely ownership and whenever a component blows up in prod, the guy that wrote the code fixes it no matter what? Thereby incentivizing him to not write shit code in the first place and be more proactive in making sure it doesn't in the first place since he knows otherwise he's doing overtime to fix it?
Is it just me or is there really no such thing as a dev job where something doesn't blow up due to poorly tested and designed code every other day?3
Top Tags
Weekly Rant
View