First time poster here. Please be nice :)

My biggest workaround is one that's being currently deployed to 40 truck drivers (trucking company here), preventing printers being out of usage while on the road. We also have to use HP ePrint to wirelessly print documents, but that's another story for another time I guess :)

CEO asked us to install wifi printers in our 40-ish trucks which has wifi on board. However he's always picking one of the cheapest options possible, so we got consumer grade printers (Laserjet 1002w). Those printers often disconnects without getting back on the truck wifi network EVER. I have to get physically in the truck, wire the printer via USB onto my laptop and reconfigure Wifi on it with the HP Windows tool. This means lots of printer downtime, which always happens when the drivers are three timezones away from our office

Then I thought: "What if I could sniff what HP sends via USB while I (re)configure the printer, and replay whats being sent later? Our trucks all have an Android tablet with a USB type-A connector with host capability, so I could write a small app that replays the config when plugged in by the user.

Three days of hacking around later, I have a working app. By chance, HP printers (or at least those models we have) uses HTTP POST via USB, so I could easily replay the request.

Edit: the end result is that truck drivers just plug the printer to their tablet, press "reconfigure" in a home made Android app, printer is reconnected to the truck and they're good to go. They don't have access to the network nor know enough to debug themselves anyways

So I have that custom-made wifi router I've built. And it uses a USB wifi adapter with AC (wifi5) capability - the fastest one I could find in AliExpress.

I set it up a while ago - the internet access works fine, although speeds are somewhat sluggish. But hey, what to expect from a cheapo on Ali! Not to mention it's USB, not a PCIe...

A few days ago I ran a few speedtest.net tests with my actual AC router and the one I've built. Results were so different I wanted to cry :( some pathetic 23Mbps with my custom router :(

This evening I had some time on my hands and finally decided to have an umpteenth look.

nmcli d wifi
this is what caught my eye first. The RATE column listed my custom router as 54Mbps, whereas the actual router had 195Mbps.

I have reviewed the hostapd configuration sooo many times - this time nothing caught my eye as well.

Googling did not give anything obvious as well.

What do we do next? Yes, that's right - enable debug and read the logs.

> VHT (IEEE 802.11ac) with WPA/WPA2 requires CCMP/GCMP to be enabled, disabling VHT capabilities

This is one of the lines at the top of the log. Waaaaiiitttt.. VHT is something I definitely want with ac -- why does it disable that??? Sounds like a configuration fuckup rather than the HW limitation! And config fuckups CAN be fixed!

Turns out, an innocently looking
`wpa_pairwise=TKIP`
change into
`wpa_pairwise=TKIP CCMP`

made a world of a difference!

:wq
!hostapd
connect to the hostapd hotspot and run that iperf3 test again, and... Oh my. Oh boi! My pants fell off -- the speed increased >3x times!

A quick speedtest.net test deems my custom router's download speeds hardly any worse than the speeds obtained using my LInksys!!

The moral of the story: no matter how innocent some configurations look, they might make a huge difference. And RTFL [read the fucking logs]

In the pic -- left - my actual router, right - my custom-built router with a USB wifi adapter. Not too shabby!

I'm thinking of tattooing "reload the fucking debug-config you giant moron" on both of my arms and giving away all my long-sleeved shirts to charity to help me become a better programmer.

Stupid pipeline bullshit.

Yeah i get it, it speeds up development/deployment time, but debugging this shit with secret variables/generated config and only viewable inside kubernetes after everything has been entered into the helm charts through Key Vaults in the pipeline just to see the docker image fail with "no such file found" or similar errors...

This means, a new commit, a new commit message, waiting for the docker build and push to finish, waiting for the release pipeline to trigger, a new helm chart release, waiting for kubernetes deployment and taking a look at the logs...

And another error which shouldn't happen.

Docker, fixes "it runs on my machine"
Kubernetes, fixes "it runs on my docker image"
Helm, fixes "it runs in my kubernetes cluster"

Why is this stuff always so unnecessarily hard to debug?!

I sure hope the devs appreciate my struggle with this... well guess what, they won't.

Anyways, weekend is near and my last day in this company is only four months away.

Long time no see devRant. This rant is dedicated to an MQTT implementation we use. Mosquitto, mqtt.js - FUCK YOU.

I spent the last fucking 30+ hours trying to find why the bloody fuck the stupid server / client won't connect to the shitty mqtt broker. From changing all possible config, enabling & disabling specific code nothing abso-fucking-lutely works.

But then it will randomly decide to connect to the fucking broker, not causing any issues at all. And each fucking day when I wake up again and think to myself: oh today I can actually leave when it is still somewhat bright outside - NOPE. Because guess what? The fucking shitty abomination doesn't work anymore.

I just love these types of problems that are almost impossible to debug because the only logs you get is: "SERVER disconnected". It's impossible to get a proper reason out of this shit show, it's just turned into randomly guessing what the error could be (and especially where it could be).

And each time I got it to work, tested it and let the testing team know that they can start testing it will just stab me in the back and be like "fuck you, I'm not working any more". Luckily it's not like the deadline is next week... otherwise work is great, trust me.

Spent an hour trying to optimize some code but none of the stuff I was trying (rearranging/overlapping DMA transfers with other stuff for some ye olde concurrency) seemed to be doing anything.

Aaand obviously the stupid thing was set to autobuild Debug config on save but I was testing Release config. Sigh.

How I know I need coffee?

(1) fire up "npm run webpack-dev"
(2) Debug webpack config settings for 30 minutes wondering why it can't rebuild scripts
(3) Realize you ran it on the ~/projects/me/release folder and not ~/project/me/dev-latest folder.

When I need to talk to another office in my company about how one of their codebases works the weirdest thing happens. I end up on a call after local business hours with people who don't write code and thus cannot help me.

I show them the error I'm getting trying to run their shit and I get a high level buzzword filled spiel about the project that makes no actual sense. They use these technical words like federated and dynamic but they don't make sense in the contexts they're using them. And they don't answer my goddamn questions.

It turned out their debug config file was gitignored.

Okay so.

I have a docker instance with 2 running apps. Normally one of them is just a proxy to the other one, so a http req to app0 is redirected to app1 and the same with response.

This works perfectly on bare machine, i can just rewrite the ip in the config file and it works. Now my boss decided that yeah docker is absolutely needed for this software so i have to containerize it.

Thing is docker seems to break local ips? I cant use localhost/, nor assigned ip. Is there a way i can debug this, or what should i look up??? Im lost, this is devops afaik and im far from devops.

SSL cert problems

realize new pem file has a different name so now after going down a debug rabbit hole I'm updating the places that used the old file name with the new file name

i guess could've just changed the file name, but at this point im committed (might as well leave the file name alone so i can hope to be less confused next year if the new file's name changes again) and just hoping i can fix the fucking config

i just want shit to work

Bit of a stupid oopsie I had today that someone might appreciate.

We’re working on a microservice project in Spring Boot, running in a docker swarm. Past few days I get a Spring Cloud config server going in separate stack, create an overlay network, and get CI deployments to use the right profiles etc. It’s looking great, and the first component is working spectacularly.

Now just to do the other 6. Move config files to the Git repo, tweak CI, all the other faffing and hoohas; and deploy. Health checks keep failing, the containers are murdering themselves and resurrecting ad infinitum. They’re doing this so quickly that by the time I get the container ID to exec in and curl health, it’s no longer running. Cue frustration, increased caffeine and nicotine consumption; my sanity is slipping.

No errors in the logs, because from experience the Cloud Config errors ar at debug level. Whhhyyyy?? Some time later (way longer than it should have been) I realize I had never actually included the Spring Cloud Config starter. Boot 101, get your starter!
Since config client is just additional setup in properties.yml, there’s no issue of the dep isn’t there, it just doesn’t try to get the config.

The containers are still unhealthy, I can hear them screaming. But now at least it’s about something else...