"Why does the search take so long?" maybe because it searches through2 dbs with 20 tables with 5.000.000 objects on an 6 year old server with hdds and apparently there is no budget for a new server, but there is money for an 40.000€ art piece.

Client asks for website and budget very low and wants a form with dB. Think WordPress site is a solution. Build site.
Deliver site.
Client's IT team unable to deploy on server. They blame me for bad "code".
I have to go to their office and help them deploy on local machine using WAMP.
2 days and 100s of calls later, website installed on test server. Works fine.
All is well

Last year the rewrite of an ancient system (VB6/mainframe COBOL) was started. Instead of moving to modern architecture management decided to rewrite the app's functionality into our last gen WinForms client/server arch. I set up a meeting to present alternatives and plead for some level of modernization. After presenting and asking management to plan for five to ten years in the future instead of just this year's budget my director said, "In five to ten years I'll be retired on a beach in Tahiti and this will be your problem to solve." It was the last straw and I left the company shortly after. Last week I found out the director was force retired out of the company. I sent her a congratulations slip and a cocktail umbrella with "Tahiti" written on it.

TL;DR: Fuck Wordpress and their shitty “editor”.

Client told me the Wordpress editor was unusual slow on their site. I inspected the network traffic, while fiddling around in the admin pages. What I found was an even worse nightmare than expected. Somehow the fucktard of an “engineer” decided to implement the spell check module, to parse all other text areas on the page - even the fucking image sources. The result is a browser sending a GET request to fetch the images from the server every time an author triggers a keyup-event. Disabled the spell check and everything was back to budget-ineffective-feces-Wordpress normal.

I am so mad, I have no words for how fucking much I hate ever having to work or pass work to other incompetent developers or teams, what a fucking waste of time and resources.

After handing off the frontend - for the client to find some team, that would do it in the short time and budget he needs (multiple developers, more fast, much good), he found a team that seemed to be alright for the job and seemed alright to me too, now maybe a month or two later, the client contacts me, that they fucked something up and if I could talk to them.

The email I then received from them seriously made me speechles, mad and sad, all at same time, I spent multiple upon multiple hours, getting a very good readable documentation up (markdown with TOC, properly rendered headers, bulletpoints, all that shit), with all files, all services used, all credentials, even converted all ssh keys into putty ppk format, in case the developers are using windows and are too dumb to do it themselves, nginx configs, it had seriously everything, even too much to list.

They somehow managed to fuck up the entire server, while attempting to "add ssh keys themselves", EVEN FUCKING THOUGH I have included all the keys they need, all the hosting credentials, everything, yet they decided to fuck with shit themselves and completely annihilate the server in the process (HOW?!), so not even the webserver works anymore.

I am fucking speechless, I made it so fucking easy to gather all info and files they need, all properly put into well named folders, along the documentation in an archive and they somehow managed to nuke the fucking server, while attempting to add ssh keys?!

If you don't know how to config a server, then don't fucking touch it and just use everything, that got served to you on a fucking silver platter.

---

I'll just instantly answer the most annoying comment, that somebody could come up with: "why didn't you do it yourself?"

Because in a perfect world, a fully managed team, can do much more than a single developer can, especially in the same timeframe and from what I heard of said client, atleast they did something in terms of developing the system. (which surprises me, considering it's the same people that nuked a server, while trying to add ssh keys)

(long post is long)
This one is for the .net folks. After evaluating the technology top to bottom and even reimplementing several examples I commonly use for smoke testing new technology, I'm just going to call it:

Blazor is the next Silverlight.

It's just beyond the pale in terms of being architecturally flawed, and yet they're rushing it out as hard as possible to coincide with the .Net 5 rebranding silo extravaganza. We are officially entering round 3 of "sacrifice .Net on the altar of enterprise comfort." Get excited.

Since we've arrived here, I can only assume the Asp.net Ajax fiasco is far enough in the past that a new generation of devs doesn't recall its inherent catastrophic weaknesses. The architecture was this:

1. Create a component as a "WebUserControl"
2. Any time a bound DOM operation occurs from user interaction, send a payload back to the server
3. The server runs the code to process the event; it spits back more HTML

Some client-side js then dutifully updates the UI by unceremoniously stuffing the markup into an element's innerHTML property like so much sausage.

If you understand that, you've adequately understood how Blazor works. There's some optimization like signalR WebSockets for update streaming (the first and only time most blazor devs will ever use WebSockets, I even see developers claiming that they're "using SignalR, Idserver4, gRPC, etc." because the template seeds it for them. The hubris.), but that's the gist. The astute viewer will have noticed a few things here, including the disconnect between repaints, inability to blend update operations and transitions, and the potential for absolutely obliterative, connection-volatile, abusive transactional logic flying back and forth to the server. It's the bring out your dead approach to seeing how much of your IT budget is dedicated to paying for bandwidth and CPU time.

Blazor goes a step further in the server-side render scenario and sends every DOM event it binds to the server for processing. These include millisecond-scale events like scroll, which, at least according to GitHub issues, devs are quickly realizing requires debouncing, though they aren't quite sure how to accomplish that. Since this immediately becomes an issue with tickets saying things like, "scroll event crater server, Ugg need help! You said Blazorclub good. Ugg believe, Ugg wants reparations!" the team chooses a great answer to many problems for the wrong reasons:

gRPC

For those who aren't familiar, gRPC has a substantial amount of compression primarily courtesy of a rather excellent binary format developed by Google. Who needs the Quickie Mart, or indeed a sound markup delivery and view strategy when you can compress the shit out of the payload and ignore the problem. (Shhh, I hear you back there, no spoilers. What will happen when even that compression ceases to cut it, indeed). One might look at all this inductive-reasoning-as-development and ask themselves, "butwai?!" The reason is that the server-side story is just a way to buy time to flesh out the even more fundamentally broken browser-side story. To explain that, we need a little perspective.

The relationship between Microsoft and it's enterprise customers is your typical mutually abusive co-dependent relationship. Microsoft goes through phases of tacit disinterest, where it virtually ignores them. And rightly so, the enterprise customers tend to be weaksauce, mono-platform, mono-language types who come to work, collect a paycheck, and go home. They want to suckle on the teat of the vendor that enables them to get a plug and play experience for delivering their internal systems.

And that's fine. But it's also dull; it's the spouse that lets themselves go, it's the girlfriend in the distracted boyfriend meme. Those aren't the people who keep your platform relevant and competitive. For Microsoft, that crowd has always been the exploratory end of the developer community: alt.net, and more recently, the dotnet core community (StackOverflow 2020's most loved platform, for the haters). Alt.net seeded every competitive advantage the dotnet ecosystem has, and dotnet core capitalized on. Like DI? You're welcome. Are you enjoying MVC? Your gratitude is understood. Cool serializers, gRPC/protobuff, 1st class APIs, metadata-driven clients, code generation, micro ORMs, etc., etc., et al. Dear enterpriseur, you are fucking welcome.

Anyways, b2blazor. So, the front end (Blazor WebAssembly) story begins with the average enterprise FOMO. When enterprises get FOMO, they start to Karen/Kevin super hard, slinging around money, privilege, premiere support tickets, etc. until Microsoft, the distracted boyfriend, eventually turns back and says, "sorry babe, wut was that?" You know, shit like managers unironically looking at cloud reps and demanding to know if "you can handle our load!" Meanwhile, any actual engineer hides under the table facepalming and trying not to die from embarrassment.

My foolishness of giving into an almost impossible dream seems to be finally setting in.

So the client, who is also my relative is launching an hotel. He wanted a website for the hotel with booking facility. The budget was plenty for that requirement and I was okay. In my calculations 20% of the proposed budget seemed fair to charge.

Few months in, it turns out he now wants a hotel booking platform where other hotels can also be listed. The reasoning was he wants to avoid the commissions charged by popular booking sites and also feature his own hotel in the booking platform that was about to be build.

I was skeptical about his intentions and my skills in developing it. I was also concerned whether he understood the responsibilities and overhead costs of running such a platform. He talked like it'll be fine. I calculated my billing to about 50% of the budget. I left the other 50% intentionally because I knew it would need for keeping up the site.

Time goes by, i am now 90% into completion of the new requirement.

Few weeks ago, i had informed about server pricing and I quoted a starting price of $15 per month. He seemed quite shocked. His reaction shocked me too and I got concerned whether I would even get rest of the payment ( already got 10% of proposed budget ) as advance.

Just few days ago, he now has a new requirement. He wants to show the hotel pricing from the booking site in Google Maps search. I tried to understand him that those are Ads and I was pretty sure price of running those ads are beyond his budget and probably negate any savings he is trying to make by competing popular booking platforms. Signing up for Hotel Ads as a booking platform is quite challenging. I don't think it'll happen.

I am now concerned he might bail on the project, so I have not informed yet. I just hope I get paid for the work I done and I'll inform then. :P

Anyways, the journey of it's development was quite insightful and challenging experience. I fell in love with a language I knew existed but never really bothered about and a framework whose only thing I knew was that it's name sounded cool to say.

I guess you could say that my speciality is cloud at scale. I’d say it chose me more than I chose it.
Looking back on it though, I think what I like about my speciality is the unique challenges it brings.
Every speciality has its own set of challenges, like tight resource limits in embedded, or client-server synchronisation in native/mobile.

The challenge of cloud at scale is throughput. Designing systems that can support 100K users making a bazillion requests a second, or a data pipeline firing events that you need to process in near real time without dropping a single one.
The real challenge of course is doing all this within a sensible budget. We have virtually infinite compute but we dont have infinite dollars to spend on it.

Its a fun problem to solve.