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 - "hell of dependencies"
-
You know what?
Young cocky React devs can suck my old fuckin LAMP and Objective-C balls.
Got a new freelance job and got brought in to triage a React Native iOS/Android app. Lead dev's first comment to me is: "Bro, have you ever used React Native".
To which I had to reply to save my honor publicly, "No, but I have like 8 years with Objective-C and 3 years with Swift, and 3 years with Node, so I maybe I'll still be able help. Sometimes it just helps to have a fresh set of eyes."
"Well, nobody but me can work on this code."
And that, as it turned out was almost true.
After going back and forth with our PM and this dev I finally get his code base.
"Just run "npm install" he says".
Like no fuckin shit junior... lets see if that will actually work.
Node 14... nope whole project dies.
Node 12 LTS... nope whole project dies.
Install all of react native globally because fuck it, try again... still dies.
Node 10 LTS... project installs but still won't run or build complaining about some conflict with React Native libraries and Cocoa pods.
Go back to my PM... "Um, this project won't work on any version of Node newer than about 5 years old... and even if it did it still won't build, and even if it would build it still runs like shit. And even if we fix all of that Apple might still tell us to fuck off because it's React Native.
Spend like a week in npm and node hell just trying to fucking hand install enough dependencies to unfuck this turds project.
All the while the original dev is still trying TO FIX HIS OWN FUCKING CODE while also being a cocky ass the entire time. Now, I can appreciate a cocky dev... I was horrendously cocky in my younger days and have only gotten marginally better with age. But if you're gonna be cocky, you also have to be good at it. And this guy was not.
Lo, we're not done. OG Dev comes down with "Corona Virus"... I put this in quotes because the dude ends up drawing out his "virus" for over 4 months before finally putting us in touch with "another dev team he sometimes uses".
Next, me and my PM get on a MS Teams call with this Indian house. No problems there, I've worked with the Indians before... but... these are guys are not good. They're talking about how they've already built the iOS build... but then I ask them what they did to sort out the ReactNative/Cocoa Pods conflict and they have no idea what I'm talking about.
Why?
Well, one of these suckers sends a link to some repo and I find out why. When he sends the link it exposes his email...
This Indian dude's emails was our-devs-name@gmail.com...
We'd been played.
Company sued the shit out of the OG dev and the Indian company he was selling off his work to.
I rewrote the app in Swift.
So, lets review... the React dev fucked up his own project so bad even he couldn't fix it... had to get a team of Indians to help who also couldn't fix it... was still a dickhead to me when I couldn't fix it... and in the end it was all so broken we had to just do a rewrite.
None of you get npm. None of you get React. None of you get that doing the web the way Mark Zucherberg does it just makes you a choad locked into that ecosystem. None of you can fix your own damn projects when one of the 6,000 dependency developers pushes breaking changes. None of you ever even bother with "npm audit fix" because if security was a concern you'd be using a server side language for fucking server side programming like a grown up.
So, next time a senior dev with 20 years exp. gets brought in to help triage a project that you yourself fucked up... Remember that the new thing you know and think makes you cool? It's not new and it's not cool. It's just JavaScript on the server so you script kiddies never have to learn anything but JavaScript... which makes you inarguably worse programmers.
And, MF, I was literally writing javascript while you were sucking your mommas titties so just chill... this shit ain't new and I've got a dozen of my own Node daemons running right now... difference is?
Mine are still working.34 -
Linux sucks.
Now now, chill. I'm using it as my main OS for a few years now. I know what I'm talking and this title is a bit click-baity, but this just has to go out there:
1. It's usable as a Windows replacement just fine - FALSE. XFCE4 is years old and buggy as hell especially on multi-monitor set-up, Gnome3 gets stuck more often than my Windows 98 machine used to, KDE is like a rich kid on meth. Plug in Bluetooth headphones? Well no, sorry, you have to research that online, since you'll probably need to install some packages for it to work. Did I say "work"? Well no, because after more research you realize that Debian on Gnome3 on gdm3 launches pulseaudio on its own, so you have 2 instances of pulseaudio, and one of them is stealing your headphones sometimes and you either have no sound or shitty sound. How do I know that you ask? The same way I know everything else - every time you try to do something new on any Linux, it involves a ton of research. Exciting research, don't get me wrong, but at this point it looks more like a toy than a reliable desktop computer operating system.
2. And why am I using pulseaudio? Why not alsa? years ago people were discussing on forums that pulseaudio is old and dead, yet here we are with new LTS release of Ubuntu still shining with Pulseaudio. How about several different service management systems being deprecated by new ones, each having different configurations and calling methods? Apparently systemd is old and lame now. It's a mix of 10 year old software that works badly, with a 5 year old replacement that works worse, somehow trying to live under the same roof. Does it work? Ask my headphones who sound like a fucking dial-up modem.
3. Let's talk about displays, shall we? xorg is old and deprecated, right? We got Wayland that's mostly stable. Don't know what that is? That's just basic knowledge for Linux. And when you try to install network-manager, it also tries to install Mir toolkits. Because why the fuck not install 3 display managers when you want a network manager, of which one is old and dying, one is young and stupid, and another is an infant that died of cancer?
4. Want to integrate with Google Drive? Yeah, there's a tool that mounts the drive as a local directory. Yeah only for Ubuntu. Want it on Debian? You need to compile it. Oh wait, it's on Ocaml, because fuck mainstream languages, we're hipsters. How do you compile Ocaml? Well you need to have Ocaml on your system, dummy. How do you do that? Well you need to compile Ocaml. Ok, how do I do that? Well, git clone, download and install some dependencies, configure, make... oh sorry, you're using libssl1.0.2g when you need libssl1.0.1f, nope, sorry, won't work. Want to install libssl1.0.1f? Why? You already have the "g", stupid! Want to remove libssl1.0.2g? Bye-bye literally everything that you have on your PC. But at least you got the "f". Does it work now? Well no, because you need libssl1.0.2g for another dependency to work.
And all I ever wanted was to get a fucking document from google drive (not nudes, I promise).
5. Want to watch a movie? Let me tear that screen in half and make the bottom half late by a couple of frames, because who needs vertical sync, right? Oh you do? Well install the native drivers maybe. Oh you have? Welcome to eternal Boot to Recovery mode, motherfucka!
---------------------------------
Yeah, most of the times things work just fine. But the reason I know what those things are and how they work is not curiosity. The reason that I know the inner workings of Linux much better than the inner workings of Windows, is because in those few years that I've been using it full time, it has caused me 10 times more headache than I have ever experienced with other systems. And it's not the usual annoyances like "OMG it rebooted when I didn't ask it to", but more like "Oh, it won't work and I need 2 days to find out why" kind of stuff, because even if you experience the same thing again, it's always caused by some new shit and the old solution won't work any more.
I still love it, and will continue to use it. I don't know why really. Maybe because I'm not afraid of fucking it up any more? Maybe because I can do what I want in it and recovering will be easier than on Windows?
It's a toy for me, after all these years. And I also use it for professional reasons.
But whenever someone presents it as a better alternative to Windows, I just want to puke.51 -
LONG RANT AHEAD!
In my workplace (dev company) I am the only dev using Linux on my workstation. I joined project XX, a senior dev onboarded me. Downloaded the code, built the source, launched the app,.. BAM - an exception in catalina.out. ORM framework failed to map something.
mvn clean && mvn install
same thing happens again. I address this incident to sr dev and response is "well.... it works on my machine and has worked for all other devs. It must be your environment issue. Prolly linux is to blame?" So I spend another hour trying to dig up the bug. Narrowed it down to a single datamodel with ORM mapping annotation looking somewhat off. Fixed it.
mvn clean && mvn install
the app now works perfectly. Apparently this bug has been in the codebase for years and Windows used to mask it somehow w/o throwing an exception. God knows what undefined behaviour was happening in the background...
Months fly by and I'm invited to join another project. Sounds really cool! I get accesses, checkout the code, build it (after crossing the hell of VPNs on Linux). Run component 1/4 -- all goocy. run component 2,3/4 -- looks perfect. Run component 4/4 -- BAM: LinkageError. Turns out there is something wrong with OSGi dependencies as ClassLoader attempts to load the same class twice, from 2 different sources. Coworkers with Windows and MACs have never seen this kind of exception and lead dev replies with "I think you should use a normal environment for work rather than playing with your Linux". Wtf... It's java. Every env is "normal env" for JVM! I do some digging. One day passes by.. second one.. third.. the weekend.. The next Friday comes and I still haven't succeeded to launch component #4. Eventually I give up (since I cannot charge a client for a week I spent trying to set up my env) and walk away from that project. Ever since this LinkageError was always in my mind, for some reason I could not let it go. It was driving me CRAZY! So half a year passes by and one of the project devs gets a new MB pro. 2 days later I get a PM: "umm.. were you the one who used to get LinkageError while starting component #4 up?". You guys have NO IDEA how happy his message made me. I mean... I was frickin HIGH: all smiling, singing, even dancing behind my desk!! Apparently the guy had the same problem I did. Except he was familiar with the project quite well. It took 3 more days for him to figure out what was wrong and fix it. And it indeed was an error in the project -- not my "abnormal Linux env"! And again for some hell knows what reason Windows was masking a mistake in the codebase and not popping an error where it must have popped. Linux on the other hand found the error and crashed the app immediatelly so the product would not be shipped with God knows what bugs...
I do not mean to bring up a flame war or smth, but It's obvious I've kind of saved 2 projects from "undefined magical behaviour" by just using Linux. I guess what I really wanted to say is that no matter how good dev you are, whether you are a sr, lead or chief dev, if your coworker (let it be another sr or a jr dev) says he gets an error and YOU cannot figure out what the heck is wrong, you should not blame the dev or an environment w/o knowing it for a fact. If something is not working - figure out the WHATs and WHYs first. Analyze, compare data to other envs,... Not only you will help a new guy to join your team but also you'll learn something new. And in some cases something crucial, e.g. a serious messup in the codebase.11 -
I have been a mobile developer working with Android for about 6 years now. In that time, I have endured countless annoyances in the Android development space. I will endure them no more.
My complaints are:
1. Ridiculous build times. In what universe is it acceptable for us to wait 30 seconds for a build to complete. Yes, I've done all the optimisations mentioned on this page and then some. Don't even mention hot reload as it doesn't work fast enough or just does not work at all. Also, buying better hardware should not be a requirement to build a simple Android app, Xcode builds in 2 seconds with a 8GB Macbook Air. A Macbook Air!
2. IDE. Android Studio is a memory hog even if you throw 32GB of RAM at it. The visual editors are janky as hell. If you use Eclipse, you may as well just chop off your fingers right now because you will have no use for them after you try and build an app from afresh. I mean, just look at some of the posts in this subreddit where the common response is to invalidate caches and restart. That should only be used as a last resort, but it's thrown about like as if it solves everything. Truth be told, it's Gradle's fault. Gradle is so annoying I've dedicated the next point to it.
3. Gradle. I am convinced that Gradle causes 50% of an Android developer's pain. From the build times to the integration into various IDEs to its insane package management system. Why do I need to manually exclude dependencies from other dependencies, the build tool should just handle it for me. C'mon it's 2019. Gradle is so bad that it requires approx 54GB of RAM to work out that I have removed a dependency from the list of dependencies. Also I cannot work out what properties I need to put in what block.
4. API. Android API is over-bloated and hellish. How do I schedule a recurring notification? Oh use an AlarmManager. Yes you heard right, an AlarmManager... Not a NotificationManager because that would be too easy. Also has anyone ever tried running a long running task? Or done an asynchronous task? Or dealt with closing/opening a keyboard? Or handling clicks from a RecyclerView? Yes, I know Android Jetpack aims to solve these issues but over the years I have become so jaded by things that have meant to solve other broken things, that there isn't much hope for Jetpack in my mind 😤
5. API 2. A non-insignificant number of Android users are still on Jelly Bean or KitKat! That means we, as developers, have to support some of your shitty API decisions (Fragments, Activities, ListView) from all the way back then!
6. Not reactive enough. Android has support for Databinding recently but this kind of stuff should have been introduced from the very start. Look at React or Flutter as to how easy it is to make shit happen without any effort.
7. Layouts. What the actual hell is going on here. MDPI, XHDPI, XXHDPI, mipmap, drawable. Fuck it, just chuck it all in the drawable folder. Seriously, Android should handle this for me. If I am designing for a larger screen then it should be responsive. I don't want to deal with 50 different layouts spread over 6 different folders.
8. Permission system. Why was this not included from the very start? Rogue apps have abused this and abused your user's privacy and security. Yet you ban us and not them from the Play Store. What's going on? We need answers.
9. In Android, building an app took me 3 months and I had a lot of work left to do but I got so sick of Android dev I dropped it in favour of Flutter. I built the same app in Flutter and it took me around a month and I completed it all.
10. XML.
If you're a new dev, for the love of all that is good in this world, do NOT get into Android development. Start with Flutter or even iOS. On Flutter and build times are insanely fast and the hot reload is under 500ms constantly. It's a breath of fresh air and will save you a lot of headaches AND it builds for iOS flawlessly.
To the people who build Android, advocate it and work on it, sorry to swear, but fuck you! You have created a mess that we have to work with on a day-to-day basis only for us to get banned from the app store! You have sold us a lie that Android development is amazing with all the sweet treat names and conferences that look bubbly and fun. You have allowed to get it so bad that we can't target an API higher than 18 because some Android users are still using devices that support that!
End this misery. End our pain. End our suffering. Throw this abomination away like you do with some of your other projects and migrate your efforts over to Flutter. Please!
#NoToGoogleIO #AndroidSummitBoycott #FlutterDev #ReactNative16 -
I feel like the web frontend landscape has gone to hell...
It used to be a priority to develop lean front end applications that load fast and work the same on most devices. If resources are required you try to share them. I have always liked the way this was solved using CDN.
Proper workflow: include some small libs you might need, script your interactions, test site, deliver.
And now our friends of the Javascript community have discovered the nuclear science called npm... It started off as this great benefit allowing frontenders to complete entire projects in the language they know and love but I feel like it has grown into an abomination that produces bulky applications with more boilerplate configuration than actual active code...
Surely I can't be the only one who is completely fed up with the direction this is going? Is anyone else looking for a lean way of developing javascript again using only a couple of small libs instead of those monstrous frameworks.
I have even considered to develop a library that makes it easy to develop with CDN (and dependencies) in mind but I don't even know if it will be worth it as more and more people tend to move away from it.
I'm sad10 -
Well I FUCKING FINALLY managed to build a program that makes my dad's printer print automatically.
Have ranted about this on my previous rant.
My recent approach was actually overengineered all over the top. I was using pyautogui to simulate the mouse that would call the settings window on Windows, which would print a nozzle test (the translation for "Düsentestmuster" according to google?). The more I worked with it, the more I would have had to care about edge cases when calling the settings and god knows what else...😖
So I left the idea.
What I came up with was a python script with some copy-pasted code of an example from the win32print api that printed an image that I specified, so it would use all inks. Somehow it works perfectly...
After that I used the win32api. ShellExecute() with ghostscript to print a PDF for the PGBK ink.
Finally a batch script to run this python script on the task scheduler. No converted .exe as dependencies and whatnot let it all go to hell.😒
It's not quite what I had originally anticipated as a solution but IT FINALLY FUCKING WORKS!!
...😪 It took way longer than expected and although I somehow couldn't manage to print all on 1 paper, I'm still satisfied that it really works.
That's all, had to vent my frustration and share this personal success.12 -
Many people here rant about the dependency hell (rightly so). I'm doing systems programming for quite some time now and it changed my view on what I consider a dependency.
When you build an application you usually have a system you target and some libraries you use that you consider dependencies.
So the system is basically also a dependency (which is abstracted away in the best case by a framework).
What many people forget are standard libraries and runtimes. Things like strlen, memcpy and so on are not available on many smaller systems but you can provide implementations of them easily. Things like malloc are much harder to provide. On some system there is no heap where you could dynamically allocate from so you have to add some static memory to your application and mimic malloc allocating chunks from this static memory. Sometimes you have a heap but you need to acquire the rights to use it first. malloc doesn't provide an interface for this. It just takes it. So you have to acquire the rights and bring them magically to malloc without the actual application code noticing. So even using only the C standard library or the POSIX API can be a hard to satisfy dependency on some systems. Things like the C++ standard library or the Go runtime are often completely unavailable or only rudimentary.
For those of you aiming to write highly portable embedded applications please keep in mind:
- anything except the bare language features is a dependency
- require small and highly abstracted interfaces, e.g. instead of malloc require a pointer and a size to be given to you application instead of your application taking it
- document your ABI well because that's what many people are porting against (and it makes it easier to interface with other languages)2 -
Compiling software on Linux:
Python interpreter? Easy peasy, just some dependencies here and there. Make does a good job.
Linux kernel? Piece of cake, 20 years of development will be freshly served on your machine after one hour compiling (I have a pretty powerful computer).
Tensorflow? Fuck this shit I am outta.
What is your story with self-built software? Which piece of code has the most terrible dependency hell?5 -
Why the hell is JS so terrible, and why do so many people resort to using is as a back end. So many packages, so many outdated dependencies. My coworkers and friends have heard me rant about my constant frustration with this terrible setup.
I understand the need for dynamic html but why have we bastardized this language to the extent we have.
Keep your projects up to date, it saves people a lot of trouble in the future.8 -
FUCKING HATE VUE 3
It's pointless, it's not an incremented version of Vue 2, it's basically a completely different framework, probably one nice to start a project with... But migrating from an existing Vue 2 project to Vue 3...
What the hell were they thinking!
first, setup() with all the logic and functions in it DOESNT MAKE ANY SENSE to me!
second, your old DEPENDENCIES NO LONGER WORK!.. good luck finding replacements for EVERYTHING, and do the necessary adjustments to work with the LASAGNA CODE YOUR PROJECT HAS BECOME!!
PS: the update/upgrade PR has almost 300 changed files!!!!19 -
I don't consider myself a guru in JavaScript (hell I studied theoretical chemistry), but I do hate much of the rationalization behind building a Jenga stack of libraries, frameworks, dependencies... for building everything web related.
Many of the problems I see people solving with these giant stacks could be easily solved understanding how websites work (html, css, js and how interact with each other) with no dependencies giving smaller (for end users at least) and more maintainable code (in the sense it would not require updating dependencies that may be discontinued...)
I do imagine situations where these are ideal... Since there are not absolutes and developing is very context sensitive, but man if I have js article fatigue for ridiculous scenarios.2 -
The whole fucking npm i fucking hate it.
Most of my worthless time i'm doing backend jobs. But when i wanted to make a simple web frontend from my app with vue - hell has begun.
The first week was "wonderful" but after that... i needed to update dependencies.
I don't wanna describe my frustration when everything was throwing a whole avalanche of errors
I hate npm i really hate npm3 -
Dependency hell is the largest problem in Linux.
On Windows, I just download an executeable (.exe) file, and it just works like a charm! But Linux sometimes needs me to install dependencies.
At one point, I nearly broke my operating system while trying to solve dependencies. I noticed that some existing applications refused to start due to some GLIBC error gore. I thought to myself "that thing ain't gonna boot the next time", so I had to restore the /usr/lib/x86_64-linux-gnu/ folder from a backup.
And then there is a new level of lunacy called "conflicting dependencies". I never had such an error on Windows. But when I wanted to try out both vsftpd and proFTPd on Linux, I get this error, whereas on Windows, I simply download an .exe file and it WORKS! Even on Android OS, I simply install an APK file of Amaze File Manager or Primitive FTPd or both and it WORKS! Both in under a minute. But on Linux, I get this crap. Sure, Linux has many benefits, but if one can't simply install a program without encountering cryptic errors that take half a day to troubleshoot and could cause new whack-a-mole-style errors, Linux's poor market share is no surprise.
Someone asked "Why not create portable applications" on Unix/Linux StackExchange. Portable applications can not just be copied on flash drives and to other computers, but allow easily installing multiple versions on a system. A web developer might do so to test compatibility with older browsers. Here is an answer to that question:
> The major argument [for shared libraries] is security, that if there is a vulnerability in a commonly-used library, then only that library has to be updated […] you don't have to have 4 different versions of a library installed
I just want my software to work! Period. I don't mind having multiple versions of libraries, I simply want it to WORK! To hell with "good reasons" for why it doesn't, and then being surprised why Linux has a poor market share. Want to boost Linux market share? SOLVE THIS DAMN ISSUE!.
Understand that the average computer user wants stuff to work out of the box, like it does in Windows.52 -
I really hate it when I work on a user story consisting only of a cryptic title: "Implement feature X".
Esp. when I missed planning during a holiday and can only wonder who in their right mind would have given it 3 points.
Why thank you.
Sometimes, just pulling the acceptance criteria out of somebody's nose takes days. It doesn't get better once I realize that not all external dependencies have been properly resolved. It's worse if there are other departments involved, as then you get into politics.
Me: "We are dependent on team X to deliver Y before we should have even planned this ticket. I'm amazed that our team was even able to estimate this ticket as I would have only raised a question mark during estimation meeting. We could have thrown dices during estimation as the number would have been as meaningful and I'd have more time to actually figure out what we should be doing."
Dev lead / PO: "I understand. But let's just do <crazy workaround that will be live until hell freezes over> temporarily."
It's borderline insane how much a chaotic work flow is branded as agile. Let's call it scrum but let's get rid of all the meaningful artefacts that make it scrum.1 -
When the CTO/CEO of your "startup" is always AFK and it takes weeks to get anything approved by them (or even secure a meeting with them) and they have almost-exclusive access to production and the admin account for all third party services.
Want to create a new messaging channel? Too bad! What about a new repository for that cool idea you had, or that new microservice you're expected to build. Expect to be blocked for at least a week.
When they also hold themselves solely responsible for security and operations, they've built their own proprietary framework that handles all the authentication, database models and microservice communications.
Speaking of which, there's more than six microservices per developer!
Oh there's a bug or limitation in the framework? Too bad. It's a black box that nobody else in the company can touch. Good luck with the two week lead time on getting anything changed there. Oh and there's no dedicated issue tracker. Have you heard of email?
When the systems and processes in place were designed for "consistency" and "scalability" in mind you can be certain that everything is consistently broken at scale. Each microservice offers:
1. Anemic & non-idempotent CRUD APIs (Can't believe it's not a Database Table™) because the consumer should do all the work.
2. Race Conditions, because transactions are "not portable" (but not to worry, all the code is written as if it were running single threaded on a single machine).
3. Fault Intolerance, just a single failure in a chain of layered microservice calls will leave the requested operation in a partially applied and corrupted state. Ger ready for manual intervention.
4. Completely Redundant Documentation, our web documentation is automatically generated and is always of the form //[FieldName] of the [ObjectName].
5. Happy Path Support, only the intended use cases and fields work, we added a bunch of others because YouAreGoingToNeedIt™ but it won't work when you do need it. The only record of this happy path is the code itself.
Consider this, you're been building a new microservice, you've carefully followed all the unwritten highly specific technical implementation standards enforced by the CTO/CEO (that your aware of). You've decided to write some unit tests, well um.. didn't you know? There's nothing scalable and consistent about running the system locally! That's not built-in to the framework. So just use curl to test your service whilst it is deployed or connected to the development environment. Then you can open a PR and once it has been approved it will be included in the next full deployment (at least a week later).
Most new 'services' feel like the are about one to five days of writing straightforward code followed by weeks to months of integration hell, testing and blocked dependencies.
When confronted/advised about these issues the response from the CTO/CEO
varies:
(A) "yes but it's an edge case, the cloud is highly available and reliable, our software doesn't crash frequently".
(B) "yes, that's why I'm thinking about adding [idempotency] to the framework to address that when I'm not so busy" two weeks go by...
(C) "yes, but we are still doing better than all of our competitors".
(D) "oh, but you can just [highly specific sequence of undocumented steps, that probably won't work when you try it].
(E) "yes, let's setup a meeting to go through this in more detail" *doesn't show up to the meeting*.
(F) "oh, but our customers are really happy with our level of [Documentation]".
Sometimes it can feel like a bit of a cult, as all of the project managers (and some of the developers) see the CTO/CEO as a sort of 'programming god' because they are never blocked on anything they work on, they're able to bypass all the limitations and obstacles they've placed in front of the 'ordinary' developers.
There's been several instances where the CTO/CEO will suddenly make widespread changes to the codebase (to enforce some 'standard') without having to go through the same review process as everybody else, these changes will usually break something like the automatic build process or something in the dev environment and its up to the developers to pick up the pieces. I think developers find it intimidating to identify issues in the CTO/CEO's code because it's implicitly defined due to their status as the "gold standard".
It's certainly frustrating but I hope this story serves as a bit of a foil to those who wish they had a more technical CTO/CEO in their organisation. Does anybody else have a similar experience or is this situation an absolute one of a kind?2 -
It was in old days when I was working in java and windows systems.
Java and different log4j versions across dependencies caused system not working only on production server.
Turned out some of libraries got log4j embedded and conflicted with other log4j.
It worked in all computers except production one.
Actually that was my main reason to switch my career to python after that dependency hell.
Another one was windows server 2008 tcp connection limit set to 200 or something.
We needed to change registry to get our servers working. After this case we finally managed to convince people to switch to linux.
Anyway any non standard error when you got multiple layers communicate with each other is hard, practice make it easier to solve those problems as your success moment comes faster.4 -
So,
Im coming from PHP. I feel comfy around PHP.
I needed for other project GO lang (there is no library for what I need to do in PHP, and it's low level thing anyway)
I need dependency that is in form of modules.
Okay, so importing it (just writing import "github.com/blah/blah/v3/blah" as suggested in docs did not work. something something, not found)
Some googling later, I created go.mod file.
And all the hell broke lose. So I am trying to fix that using random stack overflow, IDE highlights entire project on red, go complains it can't find "./" while it looks for it in gopath not project files and claims it's remote repository.
Among other WTFnessness after adding go.mod it suddenly stopped fetching ANY dependencies (including stuff like github.com/pkg/errors ), so, that's fun...
I added go.mod before 9 AM.
It's 13 and Im still wrestling with this
I fail to connect the dots why go lang get's so much praise for it's apparently awesome or something package managment... I find "composer install", and have pretty much guarantee it will work, much easier to wrap my head around.
[edit]
forgot to mention that Im literally starting to learn go. Just cherry on top5 -
This was initially a reply to a rant about politics ruining the industry. Most of it is subjective, but this is how I see the situation.
It's not gonna ruin the industry. It's gonna corrupt it completely and fatally, and it will continue developing as a toxic sticky goo of selfishness and a mandatory lack of security until it chokes itself.
Because if something can get corrupted, it will get corrupted. The only way for us as a species to make IT into a worthy industry is to screw it up countless times over the course of a hundred years until it's as stable and reliable as it can possibly be and there are as many paradigms and individually reasonable standards as there can possibly be.
Look around, see the ridiculus amount of stupid javascript frameworks, most of which is just shitcode upon vulnerabilities upon untested dependencies. Does this look to you like an uncorrupted industry?
The entire tech is rotting from the hundreds of thousands of lines of proprietary firmware and drivers through the overgrown startup scene to fucking Node.js, and how technologies created just a few decades ago are unacceptable from a security standpoint. Check your drivers and firmware if you can, I bet you can't even see the build dates of most firmware you run. You can't even know if it was built after any vulnerability regarding that specific microcontroller or whatever.
Would something like this work in chemical engineering? Hell no! This is how fucking garage meth labs work, not factories or research labs. You don't fucking sell people things without mandatory independent testing. That's how a proper industry works. Not today's IT.
Of course it's gonna go down in flames. Greed had corrupted the industry, and there's nothing to be done about it now but working as much as we can, because the faster we move the sooner we'll get stuck and the sooner we can start over on a more reasonable foundation.
Or rely on layers of abstraction and expect our code to be compilable on anything the future holds for us.2 -
I've never even heard of this before.
Notes: these are two different ASP.Net projects. I didn't choose VB, the project was already existing.
A conversation between me and a senior:
Senior: (other module) still needs to develop (something you wrote)
Me: they should just use my code, it's compete and tested.
Senior: They should, but yours is in visual basic and they wrote their project in c#
Me: Ah, no problem, I will distribute it as a DLL for him.
Senior: No, I don't want to add dependencies
Me: ????
Senior: They will need to convert it to c# and add the classes
I stopped responding
Man............ what the hell5 -
Today I spent hours trying to figure out how the hell to add a Material-UI tooltip onto the ClearIndicator for a react-select multi-select component to warn the user that it would clear _all_ of their selections. Followed the examples in the react-select docs on how to make use of replaceable components, but all of their examples used a different library for the tooltip component, and there was no way I was going to bring in _another_ library that was going to add even more dependencies to the application.
In the end, my problem was that all of the examples were with components that could carry a ref and the component _I_ was targeting was a <path> element, which apparently can’t.
Solution? Add a div between the tooltip and the component I was replacing.
*facepalm* -
Symfony's book tutorials starts out way too invasive. For example:
Their CLI has a specific command for you to clone the book project's repository. This command won't run unless you have all their dependencies installed (including docker and yarn). In the end a good old fashioned git clone does the trick.
Next, before even writing a single loc, the book urges you to create a symfonycloud account and give them your credit card number.
Seriously what the hell.
Should I mail you a drop of my blood as well so you can check out my ancestry while I'm at it?3 -
Lesson of the day: First read installation tutorials for software on linux completely before doimg esch step without knowing the rest...
-
Why the fuck does Windows still not have a fcking decent package manager?
I hear you "but but but, there is Chocolatey, it's great, try it!". Well yeah if you only want binaries.
But I do need to, you know, develop and compile things, and without includes, code, and a reliable way to produce working binaries from that, it's useless.
Guess who needs to download dependencies one by one, compile them one by one?
Don't get me started on broken MinGW, or the "recommended" way of doing a bat script to have proper includes (what the hell, that's the entire purpose of env variables), or the fact that there is NO convention on where to install things.1 -
I'm so confused by our architecture and development process in general
We planned what features are to be implemented (e.g. what endpoints should do what), but there are parts of tasks which depend on others, and I'm not sure what classes to build or when to start a task given that related ones are being done by other developers, I have absolutely no idea what I'm doing
I could maybe do all of this alone my way if it was just me, but when I ask in planning about how we should go about implementing shit together, I just get backlash from this senior developer telling me we shouldn't waste time discussing implementation details in planning
Like, what the fuck do you want me to fucking do, just implement all the dependencies of what I'm doing from zero, without reusing any of the code other devs are doing that touches on the same parts?
Fucking hell, man, this is the third sprint where I'm confused like this
Maybe I'm just too dumb to be a developer after all lol5 -
So, i'm trying to get linkr (a pretty cool short link service) to work in a docker container since 4 hours now to host it on my server. There is no official container because it needs a working database connection and stuff during installation which can only be done via console and (for whatever reason I couldn't find out yet) need to be done while building the container. The problem is, I can't connect it to the database while building the container so there is no database during installation to create tables and stuff and the build will fail. ARGH.
Why the hell would you do this????? Theyre actually saying in their readme there is no dockerfile because the config options are specific to your configuration...?!?!
The thing is entirely written in python, so reading and parsing configfiles on the fly should not really be a problem.
Of course I could ssh into the container and run the installation script but that's not the point.
Docker is not about being lazy.
It's about portability.
Maybe I don't want to bloat my server with your 39579372639 npm dependencies? Or I don't want to install a freakin apache, because I have every other site on nginx and therefore wouldn't work with apache.
AAAAAAAARRRRRRGGHHGGGGG
in the end, I'm probably going to modify the thing to install tables when running the container and giving the first user admin rights instead of prompting to enter credentials for a new admin user.
And yet I didn't even speak python. -
It makes my blood boil when my colleagues (who have been here for ages) know that maintaining dependencies in code is important but don't even action it because they give the excuse of having no time or the pressure of finishing it on time.
It angers me that I'm now in .dll hell and they don't even consider the time or push a valid case to fix the issue. It also frustrates me as I've realised that they have grown complacent/indifferent, not even attempting to change it.1 -
My work product: Or why I learned to get twitchy around Java...
I maintain a Java based test system, that tests a raster image processor. The client is a Java swing project that contains CORBA bindings to the internal API of the raster image processor. It also has custom written UI elements and duplicated functionality that became available in later versions of Java, but because some of the third party tools we use don't work with later versions of Java for some reason, it's not possible to upgrade Java to gain things as simple as recursive directory deletion, yes the version of Java we have to use does not support something as simple as that and custom code had to be written to support it.
Because of the requirement to build the API bindings along with the client the whole application must be built with the raster image processor build chain, which is a heavily customised jam build system. So an ant task calls out to execute a jam task and jam does about 90% of the heavy lifting.
In addition to the Java code there's code for interpreting PostScript files, as these can be used to alter the behaviour of the raster image processor during testing.
As if that weren't enough, there's a beanshell interface to allow users to script the test system, but none of the users know Java well enough to feel confident writing interpreted Java scripts (and that's too close to JavaScript for my comfort). I once tried swapping this out for the Rhino JavaScript interpreter and got all the verbal support in the world but no developer time to design an API that'd work for all the departments.
The server isn't much better though. It's a tomcat based application that was written by someone who had never built a tomcat application before, or any web application for that matter and uses raw SQL strings instead of an orm, it doesn't use MVC in any way, and insane amount of functionality is dumped into the jsp files.
It too interacts with a raster image processor to create difference masks of the output, running PostScript as needed. It spawns off multiple threads and can spend days processing hundreds of gigabytes of image output (depending on the size of the tests).
We're stuck on Tomcat seven because we can't upgrade beyond Java 6, which brings a whole manner of security issues, but that eager little Java updated will break the tool chain if it gets its way.
Between these two components we have the Java RMI server (sometimes) working to help generate image data on the client side before all images are pulled across a UNC network path onto the server that processes test jobs (in PDF format), by reading into the xref table of said PDF, finding the embedded image data (for our server consumed test files are just flate encoded TIFF files wrapped around just enough PDF to make them valid) and uses a tool to create a difference mask of two images.
This tool is very error prone, it can't difference images of different sizes, colour spaces, orientations or pixel depths, but it's the best we have.
The tool is installed in both the client and server if the client can generate images it'll query from the server which ones it needs to and if it can't the server will use the tool itself.
Our shells have custom profiles for linking to a whole manner of third party tools and libraries, including a link to visual studio 2005 (more indirectly related build dependencies), the whole profile has to ensure that absolutely no operating system pollution gets into the shell, most of our apps are installed in our home directories and we have to ensure our paths are correct for every single application we add.
And... Fucking and!
Most of the tools are stored as source bundles in a version control system... Not got or mercurial, not perforce or svn, not even CVS... They use a custom built version control system that is built on top of RCS, it keeps a central database of locked files (using soft and hard locks along with write protecting the files in the file system) to ensure users can't get merge conflicts by preventing other users from writing to the files at all.
Branching is heavy weight and can take the best part of a day to create a new branch and populate the history.
Gathering the tools alone to build the Dev environment to build my project takes the best part of a week.
What should be a joy come hardware refresh year becomes a curse ("Well fuck, now I loose a week spending it setting up the Dev environment on ANOTHER machine").
Needless to say, I enjoy NOT working with Java. A lot of this isn't Javas fault, but there's a lot of things that Java (specifically the Java 6 version we're stuck on) does not make easy.
This is why I prefer to build my web apps in python or node, hell, I'd even take Lua... Just... Compiling web pages into executable Java classes, why? I mean I understand the implementation of how this happens, but why did my predecessor have to choose this? Why?2 -
Use Maven, they said... it's better, they said... you don't have to manage dependencies yourself, they said...
...only now I've spent three days in hell trying to figure out why Maven keeps insisting on sticking INCOMPATIBLE JARs in my WAR that causes a breakage when deployed. No matter what I do it still sticks stuff in the WAR that shouldn't be there!
Like, I'm not a lazy cunt, I can manage my own dependencies! I know what's supposed to be there, oh, and by the way, everything fucking works when I build with Ant instead and I'm in full control of what winds up in the WAR.
So, basically, instead of the "hassle" of having to download JARs myself, I've now got the hassle of dealing with Maven trying to be more clever than me.
I know which I'd rather have, especially right now. ARGH!
You know, any time someone says "this is an industry-standard and that's why you should use it" my first thought is "hmm, which of these buildings is tallest and will ensure a quick death when I inevitably jump off of it?" MOST ESPECIALLY when the company just decides X is what everyone is going to switch to, regardless of what they're using now and regardless of how many YEARS it's been that way and working perfectly. Nope, doesn't matter, just get onboard the freight train, and if your productivity takes a hit, if you start missing deadlines dealing with shit you didn't have to deal with when using the "worse" tools, well, I guess that doesn't fucking matter, does it?!
And that's not even talking about the fact that the Maven build takes almost four minutes, which is just about 4x as long as the Ant build it replaced, each and every fucking time I make a change.
Look, I'm sure there are solutions and I'm sure I'll find them next week because I always do... and I'm sure there's some tweaking we can do to improve the performance... and it's not like this is my first go-round with Maven, though it's probably the most complex project I've ever tried to do with it... by my fucking dear god this is a nightmare, and it's not a nightmare of my choosing.
I'm disgusted, tired and defeated, three things I never get when it comes to technology. Congratulations Maven, you're on the verge of breaking someone who doesn't get broken. Another day like the last three and I'm not gonna need Stackoverflow, I'm gonna need a bus schedule so I can figure out exactly when to step off the fucking sidewalk!10 -
I had a pretty good year! I've gone from being a totally unknown passionate web dev to a respected full stack dev. This will be a bit lengthy rant...
Best:
- Got my first full time employment dev role at a company after being self-taught for 8+ years at the start of the year. Finally got someone to take the risk of hiring someone who's "untested" and only done small and odd jobs professionally. This kickstarted my career, super grateful for that!
- Started my own programming consulting company.
- Gained enough confidence to apply to other jobs, snatched a few consulting jobs, nailed the interviews even though I never practiced any leet code.
- Currently work as a 99% remote dev (only meet up in person during the initialization of some projects.) I never thought working remotely could actually work this well. I am able to stay productive and actually focus on the work instead of living up to the 9-5 standard. If I want to go for a walk to think I can do that, I can be as social and asocial as I want. I like to sleep in and work during the night with a cup of tea in the dark and it's not an issue! I really like the freedom and I feel like I've never been more productive.
- Ended up with very happy customers and now got a steady amount of jobs rolling in and contracts are being extended.
- I learned a lot, specialized in graph databases, no more db modelling hell. Loving it!
- Got a job where I can use my favorite tools and actually create something from scratch which includes a lot of different fields. I am really happy I can use all my skills and learn new things along the way, like data analysis, databricks, hadoop, data ingesting, centralised auth like promerium and centralised logging.
- I also learned how important softskills are, I've learned to understand my clients needs and how to both communicate both as a developer and an entrepeneur.
Worst:
- First job had a manager which just gave me the specifications solo project and didn't check in or meet me for 8 weeks with vague specifications. Turns out the manager was super biased on how to write code and wanted to micromanage every aspect while still being totally absent. They got mad that I had used AJAX for requests as that was a "waste of time".
- I learned the harsh reality of working as a contractor in the US from a foreign country. Worked on an "indefinite" contract, suddenly got a 2 day notification to sum up my work (not related to my performance) after being there for 7+ months.
- I really don't like the current industry standard when it comes to developing websites (I mostly work in node.js), I like working with static websites (with static website generators like what the Svelte.js driver) and use a REST API for dynamic content. When working on the backend there's a library for everything and I've wasted so many hours this year to fix bugs and create workarounds related to dependencies. You need to dive into a rabbit hole for every tool and do something which may work or break something later. I've had so many issues with CICD and deployment to the cloud. There's a library for everything but there's so many that it's impossible to learn about the edge cases of everything. Doesn't help that everything is abstracted away, which works 90% of the time but I use 15 times the time to debug things when a bug appears. I work against a black box which may or may not have an up to date documentation and it's so complex that it will require you to yell incantations from the F#$K
era and sacrifice a goat for it to work properly.
- Learned that a lot of companies call their complex services "microservices". Ah yes, the microservice with 20 endpoints which all do completely unrelated tasks? -
So I upgraded the dependencies to the latest version - and it’s all gone to hell. Of course it has...
-
When they decided to deprecate the old app that went back to early DOS, they decided to use VB.NET because they'd used some VBA and were familiar with it. Except they had a vague idea that C# was faster and decided to write the OpenGL code in that. Also they had some C++ code and decided to write more of it, accessed by the main program via COM.
I come in and the decision is made to integrate some third-party libs via a C++/CLI layer. On one hand screw COM, but on the other we're now using two non-standard MS C++ extensions. Then we decide we need scripting, so throw in some IronPython.
I'm the build engineer for all this, by the way. No fancy package managers since almost all the third-party dependencies are C++; a few of them are open source with our own hacks layered on top of the regular code, a few are proprietary. When I first started here you couldn't build on a fresh SVN checkout (ugh) without repeatedly building the program, copying DLLs manually, building again, ad nauseum. I finally got sick of being called in to do this process and announced that I was fixing it, which took a solid week of staring at failed compiler output.
Every so often someone wants to update that damn COM library and has to sacrifice a goat to figure out how the hell you get it to accept a new method. Maybe one day I'll do a whole rant just based on COM. -
Dear Diary,
Today is October 31st, ‘Halloween’ according to ancient pagan tradition. I can’t help but wonder if those pagans of yore felt as I do now in their attempts to yoke unruly bands of spirits. I sit wearily at my desk in painful and tiresome reckoning with those new hellcats we call node dependencies. Many an hour I have toiled, maestro of a cacophonous orchestra akin to that tucked in later pages of Bulgakov’s magnum opus, pleading with the band to follow my wand. And to no avail. In the wee hours of the morn I can scarcely tell who is conducting who. My sleep laden eyes blink on each execution of yarn install, my fingers knowingly re-execute with an up-arrow enter when that instruction is returned with gnarled, gruesome errors. And I ask again: “who is conducting who?!“. Will this great devil of machinery eventually meet me with an error so fearsome that I myself lay asunder? It is a battle, make no mistake. It is the “trial of a thousand years”! And who shall come out victorious I know not, but rest shall not come until I either lay myself down into the jaws of dependency hell or emerge victorious.
Dear Diary,
Today is November 1st. Compiled on the first try, no additional changes FML1 -
Either my experience with Linux got better or this OS improved a fuckton over the last years. About 3 or 4 years ago installed Ubuntu on my laptop just to try out something different. My experience:
- Reinstalled Ubuntu three times due to me fucking up something.
- Wine, with as little as it could run back then, could not be installed with proprietary nvidia drivers.
- I could not use LibreOffice because of some word bulshit which was needed for school.
- Managing dependencies was a literal hell for me (Different versions installed which resulted in conflicts)
And now:
- Wine 3.0 is about to be released
- Can run most games of today. (Fallout 4, Wolfenstein II, Overwatch)
- I can say that I could do 95% or even more on it. (Which is mostly due to me getting more experienced) -
Bought fucking nvidia gpu to test speed of some fucking machine learning models that generate speech.
6 hours wasted already for installing fucking dependencies
cuda, fucking tensorflow gpu, bezel and other shit
Fucking resetting password to download deb with cudnn,
really ??????? fucking emails are not delivered to my fucking mailbox
After mass click of send email and multiple account ban and unban I figured out I should login to nvidia website and then allow access to fucking developer every time I want to log in there - fuck shit
Uninstalling everything now looking for fucking compatible versions between software.
10 years in this business still fucking installation of dependencies is most difficult part
Fucking corporate business and their shitty installation instructions to fuck up peoples lives and switch them to the cloud.
Same was with fucking kubernetes
Fucking software dependency hell
It’s worse then ever before.
Fuck ....3 -
figured maybe you can specify dependencies specifically to be used in main.rs (as a standalone executable) or lib.rs (as a library)
since for some reason there's dev-dependencies which specifies they will only be used in tests or whatever
well rust actually doesn't compile code that wasn't ever called / would be run (and nags you about code you have but didn't use anywhere). this means binaries are smaller and all that. i've known about this but seemingly the AI insists nobody needs to specify dependency differences between main.rs and lib.rs because of this quirk of rust compiling
ok well then why the hell is there a dev dependencies and a normal dependencies then?
well no good reason.
- "intentionality" -- how about the clarity of intentionality between being an executable or a library?! no? guess not
- build optimization, because traversing usability graphs can be taxing especially in big projects. ok. again still applies to executable vs library problem
- "community and ecosystem practices". really? we've always done it this way? shove it 🙄😩. you try to innovative and then willfully inherit the problems you solved of other languages... because that's how we've always done it. lame
double standards. so annoying -
I’m too dumb to learn frontend frameworks.
I’m a backend developer, not the greatest but I get the work done. I can understand different programming languages even if I don’t write in them, you just understand basic principles and know what’s going on.
I can do some work in HTML, CSS and some JS.
But what the hell is with those popular frontend frameworks. I thought I pretty much understand how it works, so started doing some crap on my own, some pretty responsive navbar with dropdowns to start. Nevermind a million of npm packages to just start working and some weird errors in website source (“JavaScript is not enabled”, I spent few hours trying to fix it, but it’s just there, everything is working fine even with this message there). I have pretty navbar, nice, time to add dropdown.
Nope, not working. Maybe classic css solution?
Nope.
Ok, time to Google. What do I find? A million of npm dependencies that provide dropdowns, for some you need to pay, wtf.
But I want to write one on my own.
Found few tutorials that wasn’t even remotely helpful, it’s like with the online recipes, “when I was growing up on the farm…” and then something that it’s not working.
Finally found some nice looking tutorial, was following that and then.. it ended. It was maybe half of the solution, dude forgot about some components and just left.
I quit, I’m going back to writing jsp, my brain is too smooth for frontend frameworks2 -
I swear I touched some weird and complex programming shit in over a decade of programming.
I interfaced myself through C# to C++ Firmware, I wrote Rfid antennas calibration and reading software with a crappy framework called OctaneSDK (seems easy until you have to know how radio signal math and ins and outs work to configure antennas for good performance), I wrote full blown, full stack enterprise web portals and applications.with most weird ass dbs since the era of JDBC, ODBC up to managed data access and entity framework, cloud documental databases and everything.
Please, please, please, PLEASE I BEG YOU, anyone, I don't even have the enough life force to pour into this, explain me why the hell Jest is still a thing in javascript testing.
I read on the site:
"Jest is a delightful JavaScript Testing Framework with a focus on simplicity."
Using jest doesn't feel any delightful and I can't see any spark of focus and simplicity in it.
I tried to configure it in an angular project and it's a clustefuck of your worst nightmares put togheter.
The amount of errors and problems and configurations I had to put up felt like setting up a clunky version of a rube goldberg's machine.
I had to uninstall karma/jasmine, creating config files floating around, configure project files and tell trough them to jest that he has to do path transformations because he can't read his own test files by itself and can't even read file dependencies and now it has a ton of errors importing dependencies.
Sure, it's focused on simplicity.
Moreover, the test are utter trash.
Hey launch this method and verify it's been launched 1 time.
Hey check if the page title is "x"
God, I hate js with passion since years, but every shit for js I put my hands on I always hope it will rehab its reputation to me, instead every fucking time it's worse than before. -
Guys, please be mindful of your dependencies. I just ran "npm install" and whole hell broke loose.
Imagine having to install 3.6GB of VS2017 C++ junk, just to make the damn node-sass compile.
Obviously the module needs to build on my machine, but one would expect that a nodejs module would not depend on msbuild. Funny how nature does that... -
!rant
*reworks complete solution then publishes it to Azure*
"Okay, now let's debug"
*calls function, no response*
*directly opens function in browser*
Function host is not running.
Fuck.
*opens Insights*
System.BadImageFormatException
(additionally, it states that it couldnt load my main project or one of it's dependencies)
Shit, never even heard of that exception.
DDG: yo you're fucked, here, have 3 proper results
SO: lul thats some known bug Azure Functions havent fixed till now
Github: Yeah got a lot of open issues ok that, they just aint any help lmao
Me, a naive person: "okay lets try randomly changing some dependency versions, might help"
It didn't.
Now my question: how do I escape Dependency Hell?1 -
Ever feel like you're in a labyrinth, but instead of a Minotaur, you're being chased by DLL dependency hell?
I've lost more sleep trying to untangle this spaghetti than I care to admit.
Let's make dependencies a breeze, not a brain-twisting puzzle. Seriously, my debugger cries every time it steps into that abyss.3 -
Duck whoever thought using jruby was a good idea! fuck this codebase, outdated dependencies hell and fuck most of the ruby gems documentation
-
Dear TYPO3, choke on my massive dick! Been working with it for a week now. It would be more pleasant to pleasure myself rectally with a 20cm cactus than working with this piece of shit! Why the fuck would you think that we need typoscript? Why the fuck are you using numbers as variables? I don't get why this abnormality is still allowed to exist. And fuck people that publish tools and extensions that are used by everyone just to drop support on the next LTS. And, oh look, I just have to add these four extensions that are from the same person and are dependencies for each other to my composer. Oh WTF, why is nothing working anymore? AND WHY THE HELL IS THIS FUCKING ERROR MESSAGE AS COMMUNICATIVE AS MY STUPID EX GIRLFRIEND?
-
So on my new position I get to work on Spark jobs. Never had to work with the infamous big data technologies. I never thought this would get SO frustrating for all the wrong reasons.
I'm currently trying to introduce integration tests for some Spark job I wrote. This isn't trivial though, as the data comes from several HBase tables. Mocking everything simply isn't feasible. So why not use the integrated HBaseTestingUtility? With it you can start a mini cluster that runs all nessecary services in the scope of your test.
Sounds great, eh? WRONG. Firstly the used mapr dependencies get in the way. The baked in configuration tries to automatically authenticate with your local cluster through Kerberos. Of course this doesn't work. And of course there is no way to reconfigure this as it happens IN A FUCKING STATIC BLOCK. AHHHH.
Ok. So after calming down I "simply" had to exclude all mapr dependencies and replace them with vanilla ones. After two days of dependency hell it FINALLY works!
...or does it? Well now we need test data. For that we got a map reduce algorithm that can import dumps. Sounds again, great, eh? WROOOONNNG.
The fucking map reduce mini cluster can't start, as it tries to write a symlink. Now take a wild guess what the sys admin here blocked. Yepp. TWO DAYS OF WORK RENDERED USELESS, BECAUSE OF SOME FUCKING SECURITY SETTING.
This is fine.