Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "fragile design"
Fuck you whoever designed this shitty database!
Why the fuck do you mix up underscores and hyphens? Plus MSSQL is a little fragile boy, he doesn’t like hyphens that much and you have to add brackets fucking everywhere, so FUCK YOU.
Fucking learn to design things or go fuck your fist while sitting on a banana tree, seriously.3
Pretty late for week 86, but I just remembered my first paid freelancing web dev work.
While not my worst experience, it was a pretty horrible task given to me...
I was helping someone implement a new design on a pretty outdated (visually and technically) PHP site.
I was getting paid crap. The guy wouldn’t even let me look at the HTML, let alone touch it, so definitely no PHP work, either...
Literally the only code I was allowed to write was CSS. So, I’m supposed to be restyling, but I can’t change the structure at all, or even ADD CSS SELECTORS.
Fine, I’ll just make your site fragile as fuck by using nested relative selectors.
#main:nth-child(3) > div > div > div > button
As if that wasn’t bad enough, there were some pages...I shit you not...that had A DOZEN LEVELS OF NESTED TABLES.
WHY. DEAR GOD WHY.
For a simple checkout page.
So, on some pages I was literally trying to access elements through relative selectors, nested within levels and levels of tables. FFS
Needless to say, I did not work for him for long. Even if I wanted to deal with that crap, my time is much more valuable than what I was being paid.
I hate the elasticsearch backup api.
From beginning to end it's an painful experience.
I try to explain it, but I don't think I will be able to cover it all.
The core concept is:
- repository (storage for snapshots)
- snapshots (actual backup)
The first design flaw is that every backup in an repository is incremental. ES creates an incremental filesystem tree.
Some reasons why this is a bad idea:
- deletion of (older) backups is slow, as newer backups need to be checked for integrity
- you simply have to trust ES that it does the right thing (given the bugs it has... It seems like a very bad idea TM)
- you have no possibility of verification of snapshots
Workaround... Create many repositories as each new repository forces an full backup.........
The second thing: ES scales. Many nodes / es instances form a cluster.
Usually backup APIs incorporate these in their design. ES does not.
If an index spans 12 nodes and u use an network storage, yes: a maximum of 12 nodes will open an eg NFS connection and start backuping.
It might sound not so bad with 12 nodes and one index...
But it get's pretty bad with 100s of indexes and several dozen nodes...
And there is no real limiting in ES. You can plug a few holes, but all in all, when you don't plan carefully your backups, you'll get a pretty f*cked up network congestion.
So traffic shaping must be manually added. Yay...
The last thing is the API itself.
It's a... very fragile thing.
Especially in older ES releases, the documentation is like handing you a flex instead of toilet paper for a wipe.
Documentation != API != Reality.
Especially the fault handling left me more than once speechless...
gives you a state PARTIAL
gives you a state SUCCESS
Why? The first one is blocking and refers to the backup status itself. The second one shouldn't be blocking and refers to the backup operation.
And yes. The backup operation state is SUCCESS, while the backup state might be PARTIAL (hence no full backup was made, there were errors).
So we have now an additional API that we query that then wraps the API of elasticsearch. With all these shiny scary workarounds like polling, since some APIs are blocking which might lead to a gateway timeout...
Gateway timeout? Yes. Since some operations can run a LONG (multiple hours) time and you don't want to have a ton of open connections hogging resources... You let the loadbalancer kill it. Most operations simply run in ES in the background, while the connection was killed.
So much joy and fun, isn't it?
Now add the latest SMR scandal and a few faulty (as in SMR instead of CMD) hdds in a hundred terabyte ZFS pool and you'll get my frustration level.
PS: The cluster has several dozen terabyte and a lot od nodes. If you have good advice, you're welcome - but please think carefully about this fact.
I might have accidentially vaporized people sending me links with solutions that don't work on large scale TM.2
"We need to refactor THIS section of the Frontend because BE wants to implement THAT - we will agree the new structure, and we will migrate the previous structure"
- refactoring the app 4 times a year because reasons