I've caught the efficiency bug.

I recently started a minimum wage job to get my life back in order after a failed 2 year project (post mortem: next time bring more cash for a longer runway)

I've noticed this thing I do at every job, where I see inefficiency and I think "how can I use technology to automate myself out of this job?"

My first ever application was in C++ for college (a BASIC interpreter) and it's been so long I've since forgotten the language.

But after a while every language starts to look like every other language, and you start to wonder if maybe the reason you never seriously went anywhere as a programmer was because you never really were cut out for it.

Code monkey, sure. Programmer? Dunno, maybe I just suffer from imposter syndrome.

So a few years back I worked at a retail chain. Nothing as big as walmart, but they have well over 10k store locations. They had two IBM handscanners per store, old grungy ugly things, and one of these machines would inevitably be broken, lost or in need of upgrade/replacement about once a year, per location. District manager, who I hit it off with, and made a point of building report with, told me they were paying something like $1500 a piece.

After a programming dry spell, I picked up 'coding' with MIT app inventor. Built a 'mostly complete' inventory management app over the course of a month, and waited for the right time.

The day of a big store audit, (and the day before a multi-regional meeting), I made sure I was in-store at the same time as my district manager, so he could 'stumble upon' me working, scanning in and pricing items into the app.

Naturally he asked about it, and I had the numbers, the print outs, and the app itself to show him. He seemed impressed by what amounted to a code monkeys 'non-code' solution for a problem they had.

Long story short, he does what I expected, runs it by the other regionals and middle executives at the meeting, and six months later they had invested in a full blown in house app, cutting IBM out of the mix I presume.

From what I understand they now use the app throughout the entire store chain.

So if you work at IBM, sorry, that contract you lost for handscanners at 10k+ stores? Yeah that was my fault (and MIT app inventor).

They say software is 'eating the world' but it really goes to show, for a lot of 'almost coders' and 'code monkeys' half our problem is dealing with setup and platform boilerplate. I think in the future that a lot of jobs are either going to be created or destroyed thanks to better 'low code' solutions, and it seems to be a big potential future market.

In the mean while I've realized, while working on side projects, that maybe I can do this after all, and taken up Kotlin. I want to do a couple of apps for efficiency and store tracking at my current employer to see if I'm capable and not just an mit app-inventor codemonkey after all.

I'm hoping, by demonstrating what I can do, I can use that as a springboard into an internal programming position at my current gig (which seems to be a company thats moving towards a more tech oriented approach to efficiency and management). Also watching money walk out the door due to inefficiency kinda pisses me off, and the thought of fixing those issues sounds really interesting. At the end of the day I just like learning new technologies, and maybe this is all just an excuse to pick up something new after spending so long on less serious work.

I still have a ways to go, but the prospect of working on B2B, and being able to offer technological solutions to common and recurring business needs excites the hell out of me..as cringy and over-repeated as that may sound.

So the CEO tells me our new release needs to be compliant with new guidelines. I say sure, I draft up a few small changes and send them to my PM. He calls an impromptu meeting with the UI team and I explain my changes. They don't like them. They then proceed to draft and redesign a new UI based on these new requirements, I tell them that they are overthinking everything and remind them of the rules of KISS. 45 minutes of me silently waiting and an entire 4x8 whiteboard of designs, I tell them this is an entire redesign and that we will never make our end of the year deadline. PM goes silent for a minute, then responds "yeah I guess your right, let's just implement your original changes"

I have come to realize that my stress comes from how inefficient my clients use their tech.

I have to stop caring. Is it up? Is it running? Good. That should be where my investment ends.

I shouldn't fear a heart attack or stroke because of some clients' inefficiency.

IT'S JUST SO DAMN HARD.

Oh man. When I look for a job after I'm done with school, I need to watch out for those "pay-per-line" bullshit contracts. More lines? Everyone can do that, but it will cause inefficiency just for the money. I could make a fucking Python Hello World program have 100 needed lines if I wanted to, but why would I? More lines = more typing ≠ more work.

I wanna go back to the age where a C program was considered secure and isolated based on its system interface rathe than its speed. I want a future where safety does not imply inefficiency. I hate spectre and I hate that an abstraction as simple and robust as assembly is so leaky that just by exposing it you've pretty much forfeited all your secrets.
And I especially hate that we chose to solve this by locking down everything rather than inventing an abstraction that's a similarly good compile target but better represents CPUs and therefore does not leak.

If you've ever tried using Go plugins raise your hand.
If you've ever tried doing plugins in Go, raise your hand.
If you think that the following rant will be interesting, raise your hand.
If you raised your hand, press [Read More]:

This is a tale of pain and sorrow, the sorrow of discovering that what could be a wonderful feature is woefully incomplete, and won't be for a very long time...

Go plugins are a cool feature: dynamically load pre-compiled code, and interact with it in a useful and relatively performant way (e.g. for dynamically extending the capabilities of your program). So far it sounds great, I know right?

Now let me list off some issues (in order of me remembering them):
1. You can't unload them (due to some bs about dlopen), so you need to restart the application...
2. They bundle the stdlib like a regular Go binary, despite the fact that they're meant to be dynamic!
3. #2 wouldn't be so bad if they didn't also require identical versions of all dependencies in both binaries (meaning you'd need to vendor the dependencies, and also hope you are using the right Go version).
4. You need to use -trimpath or everything dies...

All in all, they are broken and no one is rushing to fix it (literally, the Go team said they aren't really supporting it currently...).

So what other options are there for making plugins in Go?

There's the Hashicorp method of using RPC, where you have two separate applications one the plugin, one the plugin server, and they communicate over RPC. I don't like it. Why? Because it feels like a hack, it's not really efficient and it carries a fear of a limitation that I don't like...

Then we come to a somewhat more clever approach: using Lua (or any other scripting language), it's well known, it's what everyone uses (at least in games...). But, it simply is too hard to use, all the Go Lua VMs I could find were simply too hard to set up...

Now we come to the most creative option I've seen yet: WASM. Now you ask "WASM!? But that's a web thing, how are you gonna make that work?" Indeed, my son, it is a web thing, but that doesn't mean I can't use it! Someone made a WASM VM for Go, and the pros are that you can use any WASM supporting language (i.e. any/all of them). Problem inefficient, PITA to use, and also suffers from the same issues that were preventing me from using Lua.

Enter Yaegi, a Go interpreter created by the same guys who made (and named) Traefik. Yes, you heard me right, an INTERPRETER (i.e. like python) so while it's not super performant (and possibly suffering from large inefficiency issues), it's very easy to set up, and it means that my plugins can still be written in Go (yay)! However, don't think this method doesn't have its own issues, there's still the problem of effectively abstracting different types of plugins without requiring too much boilerplate (a hard problem that I'm actively working on, commits coming soon). However, this still feels to be the best option.

As you can see, doing plugins in Go is a very hard problem. In the coming weeks (hopefully), I'm going to (attempt to at least) benchmark all the different options, as well as publish a library that should help make using Yaegi based plugins easier. All of this stuff will go (see what I did there 😉) in a nice blog post that better explains the issues and solutions. But until then I have some coding to do...

Have a good night(/day)!

When someone starts to send you message, a single fricking word at a time :/

Never use a device to debug if you also use that device for devrant...

I'm interning at a mech eng company. Our products have many possible permutations that customers can choose from a spec sheet.

The backend for us mechanical designers is equivalent to copying and pasting the same code (with slight changes) into a massive switch statement depending on the program's options. So many near duplicate drawings. Each with individual settings that need to be tweaked and linked to other new duplicates every time a new order comes in.

As a programmer it drives me absolute bonkers! I've talked to them about automating it but "we've just always done it this way, so it probably won't change". Well, as soon as I'm done grinding this current project, I'm hoping to put together a practical demo to change their minds.

Am I the only one that who is forced to implement some funcionality that I know that wont work only to prove to the client that actually wont work as I predicted?

And then implement how I suggested at the begining?

The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.
-Bill Gates

Vertical pressure leaf filter? More like a vertical pain in the neck! Why in the world would anyone think it's a good idea to arrange filter leaves in a vertical orientation? It's like they're begging for inefficiency! And don't even get me started on the maintenance nightmare that comes with trying to clean those things out. You practically need a ladder just to reach them!

Then there's the horizontal pressure leaf filter. Oh, joy! Because arranging those filter leaves horizontally makes all the difference, right? Wrong! It's just another headache waiting to happen. Sure, it might save a bit of space, but at what cost? I'll tell you: constant clogging, uneven flow distribution, and a whole lot of frustration.

And don't even get me started on the molten sulphur filter. Molten sulphur! Do they not realize how dangerous that stuff is? And yet, they expect us to trust some flimsy filter to keep us safe? No thank you! I'd rather take my chances swimming in a pool of lava.

Filter elements? Oh, great! Because we really needed another thing to keep track of in our already cluttered warehouses. And good luck trying to find the right one when you need it. It's like searching for a needle in a haystack, except the needle costs thousands of dollars and could potentially shut down your entire operation if you pick the wrong one.

Pulse jet candle filter? What is this, a science fiction movie? Just because it sounds fancy doesn't mean it actually works! And don't even get me started on the polishing and bag filter. If I wanted to spend all day polishing things, I'd become a shoe shiner, not an engineer!

And as for self-cleaning filters and strainers, don't even get me started! They claim to be self-cleaning, but what they really mean is that they'll clog up and break down just like every other filter out there. It's a scam, I tell you!

Oil field filtration equipment? Yeah, because nothing says "reliable" like trusting your livelihood to a piece of machinery that's constantly exposed to the elements and covered in God-knows-what.

And basket filters and strainers? They're like the ugly stepchild of the filtration world. Nobody wants to deal with them, but we're stuck with them anyway because apparently, we can't have nice things.

Process filtration and equipment? More like process frustration and equipment that's one step away from falling apart at any moment. And don't even get me started on 'Y', 'T', and conical strainers. What even are those? And why do we need so many different types? It's like they're trying to confuse us on purpose!

And finally, the auto backwash filter. Because apparently, we're too lazy to clean our own filters now. What's next? Auto-eating forks and self-driving shoes? Give me a break!

In conclusion, filtration equipment is the bane of my existence. So thanks, but no thanks, to all these so-called "innovations." I'll stick to my good old-fashioned cheesecloth, thank you very much!