Vertigo

There are relatively few technologies that I adamently refuse to work with in the IT industry.

1. Perl. Fucking hate it. Yes, you *can* write maintainable code with it; and some libraries are surprisingly pleasant to use. Emphasis on "some". That leaves *most* in the category of "out of the question." I simply refuse to work a job where I know ahead of time I'll be using Perl.

Apr 21, 2020 at 4:37pmWeb
Show threadVertigoApr 21, 2020
2. Javascript in general, and Node.js in particular. Fucking hate it. It was a significant contributor to my burn-out when I worked at Rackspace.
Show threadVertigoApr 21, 2020
3. **ANYTHING** involving the use of MQTT. Full #*@#%^ing stop. MQTT solves **NO NEW PROBLEMS**, and only serves to create new problems. I'm screamed about this enough here already.
Show threadVertigoApr 21, 2020
4. Related to 3, **ANYTHING** involving Google IoT Core. Just about unusable for technical support on field-deployed units. Worse, a unit will be happily processing telemetry from field units, until it stops. YOU HAVE NO INSIGHT AS TO WHY. Only demonstrably correct work-around so far is to just restart the fucking software on the IoT device. NOTE: I'm *NOT* talking about reconnecting to the MQTT server. I'm talking about dropping the process dead with a sigkill and rerunning it.
Show threadVertigoApr 21, 2020
Ooh, what's that? You want support to figure out what's happening that's causing IoT core to suddenly disconnect your sorry ass? Pay up, bub; that's an additional several hundred dollar a month support contract, because we know our shit is so broken, the only way we can legitimately cover support load overhead is to charge your sorry ass for it.
Show threadVertigoApr 21, 2020
For the record, I petitioned my company on several things at once when we were first commissioning this new backend software stack:
Show threadVertigoApr 21, 2020

1) DO NOT tie our services hard to Google's APIs.
2) DO NOT rely on MQTT. There's no reason whatsoever to not use plain, simple, well-understood HTTPS.
3) DO NOT rely on cloud services. Take it from someone who worked at a cloud provider: JUST SAY NO. Self-host your infrastructure. We don't have the scale to justify cloud services yet.
4) Use the savings from (3) above to hire more local talent.

I was shot down on every ... single ... point.

Every fucking one of them.

Now we're suffering.

Show threadVertigoApr 21, 2020

Meanwhile, the previous incarnation of our backend infrastructure, you know the one that I willingly admit is thoroughly broken because *I* designed it and *I* had no idea WTF I was doing building it out? Guess what?

It's been supporting our legacy customers for about two years now, with **NO** **OVERSIGHT** on my part. None. I logged into our V3 core API server last week to find out why a customer's dashboard wasn't working. That's it. First V3 support request in 2 years.

Show threadVertigoApr 21, 2020
Don't talk to me about cloud *ANYTHING*. If I hear "MQT" come out of your mouth, I won't even let you fucking finish the sentence. We're done. It's over. Fuck off. You're dead to me.
Show threadVertigoApr 21, 2020
I'm tired of not being listened to. I'm tired of wasting my life away on problems that, if you'd just fucking LISTENED to me in the first place, would be a solvABLE problem. But, nope, you're stuck with an insoluable and sticky sitation now. But, of course, it's my problem. Until it isn't. I just have to write one letter of resignation. That's all it takes. Yeah, I'm a quitter. Because my life means more to me than your product portfolio.
Show threadVertigoApr 21, 2020
If it weren't for the fact that I basically wouldn't be hirable elsewhere, I'd've left this shit a long time ago.
Show threadXerz 💗Apr 21, 2020
@vertigo 
Show threadVertigoApr 21, 2020

Oh, I almost forgot:

5) PULL data, do not push data. Far more reliable, far more flexible, and vastly more bandwidth efficient, especially since compression of bulk data is so much more efficient than piece-meal bits of information.

Show threadFalkreon, when the walls fellApr 21, 2020

@vertigo I've run into some cases where pull data was *less* efficient, just because that means you need to poll sometimes, and missing one poll cycle could cause some polls that were previously spaced out over time to come in all at once when the problem is resolved.

take masto for instance. pull federation would be a mess because you can't necessarily hold one connection open per post source at the same time. so you'll poll or flap.

everything else I'm with you 100%.

Show threadVertigoApr 21, 2020
@falkreon Correct; polling is exactly how I expect things to work in this situation. Major BBS networks operated this way for decades without significant issues; in fact, it evolved that way precisely because of the pressures put on the network by large long-distance tolls and noisy communications channels. To this day, deep-space probes are polled for data, for similar reasons.
Show threadVertigoApr 21, 2020

@falkreon The only sacrifice is loss of real-time response; however, when we came up with the original project vision document, we had worked on a solution to this issue that would have worked well for us. Meanwhile, we're now looking at ways of reducing our network utilization because of the excessive overheads pushing data is causing.

Honestly, that's the least of our worries right now. Right now, I need to figure out why MQTT is damn broken, b/c without that, push vs pull is irrelevant. :(

Show threadFalkreon, when the walls fellApr 21, 2020

@vertigo spacecraft use store-and-forward which looks like push to the spacecraft and pull to mission control.

Early bbs's didn't have to deal with single user instances. I have no problems with rss-like systems where ordinary users pull data. Do the same thing with microservers and scaling problems start to appear.

Show threadRysiekúr (old account)Apr 21, 2020

@vertigo this thread is gold. Thank you. I feel your frustration and join you in it.

#SysadminsAnonymous #HealIT

Show threadDoc Edward Morbius ❌​Apr 21, 2020

@rysiek Long live alt.sysadmin.recovery a/k/a Scary Devil Monastary.

http://www.faqs.org/faqs/sysadmin-recovery/

@vertigo

Aalt.sysadmin.recovery FAQ v1.799999999999999998...

Aalt.sysadmin.recovery FAQ v1.799999999999999998...

Show threadDevin PraterApr 21, 2020
@vertigo @jookia What about Github? I really do like Github Pages for my blog.
Show threadJookiaApr 21, 2020
@devinprater @vertigo I think this is more addressed to people and businesses that are building infrastructure or websites like Github and not end-users.
Show threadDevin PraterApr 21, 2020
@jookia @vertigo Oh, I see. Yeah, businesses should have things as in-house, running locally, as possible. Businesses relying on the cloud seems... unsteady.
Show thread"You do you" is Eu-gen-ics.Apr 21, 2020
@vertigo Reading up on MQTT now. Good grief. I feel for ya.
Show threadTinyCalciferApr 21, 2020
@vertigo Perl and PHP both suffer from the issue that a great many people writing code in them are not developers. Which means that there's a LOT of crap out there in those languages. I don't blame you for noping out.