661–670 of 1001 posts
* Jira - over-engineered, unnecessarily complex and utterly slow. * Zoom - worst video conference product __EVER__. Can't say a single good word about it. * AWS admin console - same as jira, at least it's not slow. * VPNs in general annoy me beyond reason too. At this point I use a raspberry pi to connect to the vpn and I use it as an SSH access server (and tunnel respectively).
Microsoft Teams. I am forced to use it (work) and it is missing really basic features that messenger software had in the 1990s like Push-To-Talk, real multi-window (even with the recent "pop-out" functionality), and its UI is all the worst modern trends. You cannot extend it or fix these issues (e.g. plugins, custom CSS styles, etc). Plus it is buggy, I keep not getting calls/messages/etc, and every time my computer…
Tries to be a central repo for all of your business docs.
Chews RAM like it’s its prime directive.
Can’t actually find the centralized doc unless you magically remember the channel or team where it was originally shared.
UX is actively hostile and so inefficient.
I'd say basically half the software I use on a fairly regular basis is usually pretty much garbage. Corsair Link is a clunky, laggy mess. It takes like 10 seconds to open it, every single time, even if it's running in the background. I have yet to use good software for "peripherals". Google home devices are cool when they work, but I've gotten frustrated with them too many times that I barely use them. I could go on.
The Apache big data suite (Hadoop/Spark/Yarn/Hive/HDFS/etc). In several years of big data engineering work, I've believe I've seen only one application that couldn't be refactored into a simple multi-instance framework-free program. People use the big data frameworks as glorified distributed-job management tools, and the resulting systems are more fragile, more complex, more vulnerable to weird version compatibility…
Are there any good articles or blog posts that describe a "multi-instance framework-free" design that would replace a Spark application? I'm having some trouble conceptualizing your suggested alternative, but am very interested in learning.
I have t used it personally, but the documentation is definitely there around distributing work and getting results back from nodes/etc and the community is very helpful.
I would hate to rewrite it but I wish someone would. It has the worst and buggiest UI of anything I've ever used. Everything looks incredibly dated, and while the backend (the useful bit) does what it's supposed to (though very slowly unless you're paying for the big boy license) it's just a horrific place to be.
Coming home from work and working on my own stuff with the tools I like rather than have to use is like a breath of fresh air.
Vivado is also notoriously a bit of a bloated and buggy pig. For hardware simulation, Active HDL is probably the least worst thing that I've used that has all the features. But for just doing simple simulations without all the bells and whistles, GHDL is by far and away the best experience, and it's the free one.
The Apache big data suite (Hadoop/Spark/Yarn/Hive/HDFS/etc). In several years of big data engineering work, I've believe I've seen only one application that couldn't be refactored into a simple multi-instance framework-free program. People use the big data frameworks as glorified distributed-job management tools, and the resulting systems are more fragile, more complex, more vulnerable to weird version compatibility…
Data Engineering team used it at my old work (in concert with Notebooks) and it resulted in some of the worst code I’ve ever seen, and most inappropriate use of resources:
9 node DataBricks cluster to push 200gb of JSON into an ElasticSearch cluster. This process consisted of:
* close to 5 notebooks. * things getting serialised to S3 at every possible opportunity. * a hand-rolled JSON serialisation method that would string-concat all the parts together: “but it only took me 2 minutes to write, what’s the problem?”
* hand rolled logging functions
* zero appropriate dependency management; packages were installed globally, never updated, etc
Nothing inherently about that workflow actually needed spark, which was the most egregious part. The whole thing could have been done in a python app with some job lib/multiprocessing thrown in and run as single container/etc.