Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "rpc"
Developer came to our area to rant a bit about a problem he was having with Xamarin. A particular android device was receiving a java runtime error trying to de-serialize data from a WCF contract. What he found was not to use WCF and use WebAPI (or a simple REST service that sent back/forth JSON).
When he proposed changing the service (since the data transport didn’t really matter, he could plug the assembly into a WebAPI project in less than an hour), the dev manager shot down the idea pointing him to our service standard that explicitly stated no WebAPI (it’s in bold letters).
I showed him the date on the “standard”, which was 5 years ago. We have versioning on our sharepoint server, so I also him my proposal notes on the change request document (almost two years before that) stating we should stop using WCF in favor of REST based web standards. Dev manager at the time had wrote in his comment “Will never use REST. Enterprise developers prefer RPC.”
He just about fell over laughing when I showed him this gif.2
I miss old times rants...So i guess, here it goes mine:
Tomorrow is the day of the first demo to our client of a "forward-looking project" which is totally fucked up, because our "Technical Quality Assurance" - basically a developer from the '90-s, who gained the position by "he is a good guy from my last company where we worked together on sum old legacy project...".
He fucked up our marvellous, loose coupling, publish/subscribe microservice architecture, which was meant to replace an old, un-maintainable enormous monolitch app. Basically we have to replace some old-ass db stored functions.
Everyone was on our side, even the sysadmins were on our side, and he just walked in the conversation, and said: No, i don't like it, 'cause it's not clear how it would even work... Make it an RPC without loose coupling with the good-old common lib pattern, which made it now (it's the 4th 2 week/sprint, and it is a dependency hell). I could go on day and night about his "awesome ideas", and all the lovely e-mails and pull request comments... But back to business
So tomorrow is the demo. The client side project manager accidentally invited EVERYONE to this, even fucking CIO, legal department, all the designers... so yeah... pretty nice couple of swallowed company...
Today was a day, when my lead colleague just simply stayed home, to be more productive, our companys project manager had to work on other prjects, and can't help, and all the 3 other prject members were thinking it is important to interrupt me frequently...
I have to install our projects which is not even had a heart beat... not even on developer machines. Ok it is not a reeeeaaally big thing, but it is 6 MS from which 2 not even building because of tight coupling fucktard bitch..., But ok, i mean, i do my best, and make it work for the first time ever... I worked like 10 ours, just on the first fucking app to build, and deploy, run on the server, connect to db and rabbit mq... 10 FUCKING HOURS!!! (sorry, i mean) and it all was about 1, i mean ONE FUCKING LINE!
Let me explain: spring boot amqp with SSL was never tested before this time. I searched everything i could tought about, what could cause "Connection reset"... Yeah... not so helpful error message... I even have to "hack" into the demo server to test the keystore-truststore at localhost... and all the fucking configs, user names, urls, everything was correct... But one fucking line was missing...
EXCEPT ONE FUCKING LINE:
spring.rabbitmq.ssl.enabled=false # Whether to enable SSL support.
This little bitch took me 6 hours to figure out...so please guys, learn from my fault and check the spring boot appendix for default application properties, if everything is correct, but it is not working...
And of course, if you want SSL then ENABLE it...
BTW i really miss those old rants from angry devs, and i hope someone will smile on my fucking torture5
Im getting tired of this fucking scrum team.
First of all let me introduce our backend team which takes 3 weeks to add one fucking column to database and in the end turns out they fucked up RabbitMQ RPC implementation so the column is not syncing with our app at all so now we have to wait 2 extra weeks until that will be working. Best part is that backend fucker who fucked up doesnt even feel like hes blocking a feature and would rather sit for extra few days and do nothing until he gets reassigned his pile of shit back to him than clean up his own shit.
Then we have business analytic who doesnt know how to define tasks properly so I have to record each grooming meeting so I would know what to fucking implement because he doesnt even bother to take proper notes. Which results in not fully defined tasks, which results in unexpected behaviours and MR's stuck in limbo for weeks.
Also lets not forget QA guy who doesnt even bother writing scenarios, I as an app dev have to write them myself just to be sure that fucker will test everything thoroughly.
Then we have fucking devs from consultancy agency who apparently have 6 years of experience (I have barely 2) and these fuckers are spamming me daily with the most basic questions. After each grooming they rush to assign themselves tasks which are not even defined properly yet and not even in this sprint, but fuckers are lazy so thy want to reserve easier tasks for themselves. Pathetic.
At least I have a decent senior on my team, but sometimes he patronizes me so much that I start asking me what I am doing in this team.
Fuck this shit, I asked for a 43% raise and if Im not getting it in 2-3 weeks im outta here. Fuckers.5
Spent a lot of time designing a proper HTTP (dare I even say RESTful) API for our - what is until now a closed system, using a little-known/badly-supported message-over-websocket protocol to do RPC-style communications - supposedly enterprise-grade product.
I make the API spec go through several rounds of review with the rest of the dev team and customers/partners alike. After a few iterations, everybody agrees that the spec will meet the necessary requirements.
I start implementing according to spec. Because this is the first time we're actually building proper HTTP handling into the product, but we of course have to make it work at least somewhat with the RPC-style codebase, it's mostly foundational work. But still, I manage to get some initial endpoints fully implemented and working as per the spec we agreed. The first PR is created, reviews are positive, the direction is clear and what's there already works.
At this point in time, I leave on my honeymoon for two weeks. Naturally, I assume that the remaining endpoints will be completed following the outlines/example of the endpoints which I built. When I come back, the team mentions that the implementation is completed and I believe all is well.
The feature is deployed selectively to some alpha customers to start validation testing before the big rollout. It's been like that for a good month, until a few days ago when I get a question related to a PoC integration which they can't seem to get to work.
I start investigating and notice that the API hasn't been implemented according to the previously agreed upon spec at all. Not only did the team manage to implement the missing functionality in strange and some even broken ways, they also managed to refactor my previously working endpoints into being non-compliant.
Now, I'm a flexible guy. It's not because something isn't done exactly as I've imagined it that it's automatically bad. However, I know from experience that designing a good/clear/future-proof API is a tricky exercise. I've put a lot of time and effort into deliberate design decisions that made up the spec that we all reviewed repeatedly and agreed upon. The current implementation might also be fine, but I now have to go over each endpoint again and reason about whether the implementation still fulfills the requirements (both soft and hard) that we set out to meet.
I'm met with resistance, pushback and disbelief from product management and dev co-workers alike when I raise the concern that the API might actually not be production-ready (while I'm frantically rewriting my integration tests and figuring out how the actual implementation works in comparison to what was spec'ed).
Oh, and did I mention that product management wants to release this by end-of-week?!7
If your computer is slow, check the running process and confirm that non is doing >1000 poorly batched RPCs just to render a window.4
I'm working on a laptop in the shop and Explorer crashes. I try restarting it, and get RPC endpoint call errors. On reboot, I get this.
Russian roulette but 3 will probably crash instead of 1.13
Dear API vendor,
Please get off your arse and learn about REST, OpenAPI, JSON Schema, XSD and basic documentation so that I don't have to guess how to use your shitty, inconsistent, RPC over HTTP service.
I love software. Seriously, I love it. /s
Transmission is given a bad torrent (which, given that it's a torrent service, you'd expect it handles quite robustly) and completely fucks up. Like, really badly. It doesn't respond to RPC anymore, systemd has to resort to sending it a SIGKILL to get it off the process tree, and the web interface.. yeah. Nothing.
It doesn't log by default, so fine I'll add that to the systemd unit and restart it with debugging options enabled.
# systemctl daemon-reload && systemctl daemon-reexec
Turns out that /var/log/transmission.log can't be written to by my Transmission user. Well shit. Change that to /home/condor/transmission.log.
# systemctl daemon-reload && systemctl daemon-reexec
# systemctl restart transmission-daemon
*blood starts to reach its boiling point*
Still logs in the wrong fucking location. Systemd, I told you to log over there. I did everything I could to make you steaming pile of shit reload that fucking config. What's the fucking problem!?
*about 15 minutes of fighting systemd*
Finally! It spits out a log in the right location! Thank you Transmission and systemd for finally doing your fucking jobs. So a bad torrent it is, hmm...
*removes torrent from .config/transmission/torrents*
Transmission: *still fucking shits itself on that ostensibly removed torrent*
That's it. BEGONE!!!
Oh and don't get me started on the fact that apparently a service needs some 400MB of memory. Channeling your inner Chrome Transmission?10
A course at university made us program a chat server and client with Java RPC (in the days where there was no such thing as stack overflow), without ever teaching us anything about coding.
The grading was based on unit tests executed on a Server the university provided.
The server was down or overloaded most of the time and one could only try to deploy at most 3 times...
There were heuristics in place to find duplicate solutions.
... I have to say, that course took me from "hello world" to developer within a couple of months. Thanks assholes!! :D1
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)!14
I've ranted about this before, but here we go again:
I was racking my brains trying to figure out how one could possibly implement plugins easily in Go.
I had a look at using RPC, which requires far to much boilerplate to be realistic. I looked at using Lua, but there doesn't seem to be a straight forward way of using it. I was even about to go with using WASM (yes, WASM). But then I came across Yaegi ("Yet another elegant Go interpreter", you heard right: "interpreter"), Yaegi is also very easy to use.
There are a few issues (including some I haven't solved yet), including flexibility (multiple types of plugins), module support, etc. Fortunately, Traefik just released their plugin system which is based on Yaegi (same company), and I got to learn a few tricks from them.
Here's how module loading works: The developer vendors their dependencies and pushes them to a repo. The user downloads the repo as a zip and saves it to the plugins folder. I hash the zip, unzip it to a cache, and set the the GOPATH for the interpreter to be that extracted folder. I then load the module (which is defined by a config file in the folder), and save it for later. This is the relatively easy part.
The hard part is allowing for different types of plugins. It looks easy, but Go has a strict typing system, makes things complicated. I'm in the process of solving this problem, and so far it should go like this: Check that the plugin fits an arbitrary interface, and if it does, we're good the go. I will just have to apply the returned plugin to that interface. I don't like this method for a few reasons, but hopefully with generics it will become a bit more clean.1
To be a Java (or other business popular language) developer
* Java 6, 8 and features up to 14
* SQL + nosql
* Logging eg log4j2,
* Searching eg elastic stack
* Framework (at least 1, but hey, knowing 1 is lame..)
* Networking or at least base http knowledge
* Tomcat, jboss or other shit
* Aws, heroku, GCE or other SAAS/paas
* Rest, RPC, soap
* Business Hello World example
* Hexagonal Architecture
* 12 app factor
* Security, oauth2
* Eureka or consul as service Discovery
* Config server
* Hazel cast
* Endless story ...
Then we can start hello word app2
Yeah, we *COULD* do AWS for the home (and homebrew as well) RPC program server... or I could get a Raspberry Pi 3B+ for the house. I mean... it'd be cheaper and easier to access.
(Low-res screenshot warning, too.)3
Okay I got a genius/exceptionally stupid idea.
Some of you may know Xi. If not, it's an, in development, text editor backend, written in Rust.
It does all the heavy lifting and communicates changes with the Frontend over an rpc-api, typically on stdin/stdout.
Now, why don't we do this, but for other kinds of applications, that have been reinvented a million times, because a feature is missing or the ui has been shit.
Cross-Platform backends for file-managers, web browsers, password managers, media players,...2
This is true I swear... I once worked on part of a project "optimization" that required, running a job on sidekiq in the background that spawns multiple threaded RPC calls on RabbitMQ (and be I/O blocking) till the jobs are done (or failed) so that it updates the status of the master object (that has the associated objects processed) and sends an email to the ops manager (just a summary email)... instead of using database locks... or dropping the email requirement...
I did it without arguing because I've already quit the job a while ago...
For a side project I identified the need for RPC (originally over Websocket but can be extended to WebRTC/DTLS) that supports
- JSON-serializable values
- MessagePorts (including shortcut detection for ports that are passed back on a different route)
- async functions
I have ideas for all of these and this is an exciting prospective library, but it's also major scope bloat that will prevent me from ever finishing the project that depends on it.
Would you be interested in such a library if it ever got built?4
At last, I'm doing some unknown stuff. We are using Terraform, to create our load balancers and them, kops to deploy our stateless services inside K8 clusters and Jaeger to trace requests end to end (and being able to test/debug our services).
Next step will be using gRPC for our RPC API.