BackBlast

This remains true for the moment. But discontent among developers are cracks in the foundation. The building can weather that for a time because it's mighty and huge. But those cracks are the beginning of the eventual end. If not cared for, will hasten its demise.

I pick REST over GQL and such also. GQL has some distinct disadvantages that people seem to gloss over.

Front end architecture seldom is oriented around making efficient queries. My last slot that used it as glorified REST and didn't shrink the number of queries to the backend. It does make more sense if you have a variety of consumers of the data, but meh, after my experience I still wouldn't use GQL.

Higher complexity in the backend. Our GQL backend was schema stitched together microservices. Highly complex, random services would bring the whole thing down, and it was not understood why. The schema stitching happened on every request and seemed very "heavy and slow" to me. Not all of that was the fault of GQL, but, it definitely provided more room to mess things up.

Caching nightmare. Heavier client library. And on and on. Grass is not greener IMHO.

I've gone this route as well. I had good luck with certain SD cards, and earlier versions of the Pi for small things. But I've tried to use them as wireless APs, and they fold under any real use. Wireless firmware hangs requiring a full reboot to fix. Pi4s have given me a ton of trouble, and I've been on the losing side of the SD card roulette and had USB drives fail under load. There is always some kind of IO or sagging voltage problem with a power supply wigging out or I got a bad one.

Moved to using low power thin clients on liquidation for similar pricing, and it's all been a breeze. I get real disk IO. I get a real wireless card which runs an AP night and day better. I get a real USB power budget with a much more trustworthy OEM power supply. Power profile and size is about double, but it's a very worthwhile trade. I like the 1L system profiles and lean to the HPs.

I don't mind ARM in the cloud, but at home I just want real hardware.

It seems to me that you are comparing apples and oranges. If your code has no relevant state or coupling, a pure function. Sure, you can look at it in isolation. You could do the same in a monolith.

I've worked on plenty of monoliths with async style code and have found the stack traces to be plenty helpful. It's never been an issue. At least in JavaScript you retain all relevant scoped data and can dump it all if you like. Debugging gets much more interesting when there are no obvious such errors, yet error conditions are present.

I'm still not seeing any equivalent microservice tooling.

If I'm in Java, JavaScript, or Python and there is a code fault, the system provides me a stack trace of the call structure that lead to the error. If I catch the error I can output more related data as I deem necessary. This comes effectively, out of the box.

How do I do a similar stack trace in microservices to understand the path that led to this state? I've used microservices at a couple of companies and their methods were effectively, look at the request id and trace it through this mass of log files for each microservice we are running. It was terrible and could take hours to compile the same information.

What tooling exists to solve this problem with microservices? Genuinely want to know.

First you need to understand what is actually happening here and who is responsible.

Deadlines are creative fiction. It's nice to hit them, but they are almost always management tools to extract work from engineers. Only sometimes are they intimately connected to actual business needs. Don't get me wrong, they can be a helpful tool, but equally they can be harmful.

Scoping and requirement changes are program management issues. It's useful to push back on obviously bad requirements and scoping. But this requires understanding of the business space and what likely is good and what isn't for the end user. Sometimes you can save program management blunders with the right questions and friction to the desired feature set. But this is more the in the realm of experienced devs correcting management issues (an invaluable skill). Customers certainly can change their minds, and it's often appropriate when figuring what the real needs are. But it does cost additional schedule and money to pivot. Sometimes significant amounts of both when fundamental assumptions are changed. This should be understood by management or they are not doing their jobs.

You experienced some common management issues. Your boss was expressing his frustration to you and that may or may not reflect on you down the line. A lot of people don't own up to or recognize failings.

Engineering issues also can happen, but that typically involves failure to build the thing to spec. Also can involve over engineering or under engineering given the communicated business needs. This happens plenty too.

Unless you're just lazy and not working, that's when delivery time is your fault.

Good management of engineering projects is pretty rare. In twenty years I have only experienced it a couple of times.

As for what you can do, ask your direct manager questions like "I really liked working on this project, how can I be successful here?". This helps align your interests with his and communicate your willingness to pitch in/contribute.

Depends on requirements. Most no code platforms I've seen are VC funded with all the baggage that contains.

If I'm building a system with an intended life span of >=5 years I would avoid a no code platform.

If I'm doing a one off proof of concept test app, it's on the table.

Not able to use it for the whole stack. Some of our stack doesn't run on arm.

Don't have a bare metal machine, just some modest sized virtual machines with 2 cores each.

They have been stable.

I've been using them in production. I've been pleased with the value proposition offered. It helps that, on our workload, arm overperforms relative to published benchmarks while AMD underperforms.

It's not hard to invert the transaction, ask the billing service if an action can be done instead of bill upon completion. Done. This isn't that hard. If your credits won't make it to the end of the month, send out the email warnings to top up - which should be predictable unless there's a large spike hitting the account. If you prefer invoice billing because you never want your services going down, it's trivial to accommodate with this system design.

Sure, big warnings about data loss/services down in the event of zeroing out your credits.

Having such a safety net would really help the thousands of people who sign up for transient reasons. I don't recommend a noob set up an AWS account. I also don't let my kids play on the freeway.

I migrated off AWS in December and closed my account. With the outages, they are likely looking at revenue shortfalls. Outages don't scare me, but their billing practices are already uncomfortable. This may make them prone to be more stingy about bill forgiveness. Bill forgiveness is inherent in the unsafe billing model which makes even having the account open even more of a huge liability.

I'm done.

Lambda has it's own set of complexities and concerns. It's also not a good fit for his use cases.

Now, a containerization service like Fargate would fit his use case better since he is using containers.

However, cloud services come with their own complexities and the principle problem they solve (horizontal scaling) doesn't apply to his sites.

Front end scales marvelously. Distribution is easy and cheap. Learn whatever front end framework you like best and learn to make a fat client that does most to all of the heavy lifting in the client.

Scales wonderfully.

Scaling backend data structures is a difficulty itself and potentially different for every problem.

I would like more information about this. This is the first that I have seen this video mentioned.

Thank you for sharing your experience. Medical science is probably the hardest endeavor we aspire to understand. We could use a lot more humility and diligence on all sides when approaching it.

If you don't use any services specific to the vendor. Then practice your backup and restore routines. You will be able to reasonably move to a new cloud provider, on the off chance you get similarly cancelled.

This is probably the most reasonable risk mitigation you can fairly easily do.

I don't think there exists a vendor that's going to be foolproof. Most users aren't going to any have issues with any of the major providers, including DO, Linode, Vultr, Oracle, AWS, Azure, etc...

My experience with today's cloud arm offerings (gravaton/ampere) is node.js overperforms on arm relative to benchmark scores. Crypto has a definite handicap on arm. I've found that AMD underperforms on node.js. Seems the arm offerings are slanted to integer style workloads.

Other packages and databases have brought me pain to use on arm. And anywhere I encounter pain I just don't migrate.

A robot is impersonal.

Deescalation is a skill that requires understanding human nature, displays of understanding and empathy, and is most frequently done through talking. But also in patience and not forcing issues at times and places likely to result in a violent confrontation.

When you fire a gun, you should 1000% be aware of not just your target but what is behind your target and the potential ramifications of destroying what is behind it.

It is completely reasonable to make them keep in mind all the potential and direct effects of their actions.

I think it would be beneficial for them to find alternative ways of catching a bad guy than busting down doors. It's a completely unnecessary escalation far more often than not.

I agree that the problems are systemic. But behavior is individual. It's quite a reasonable way to fix the systemic issues is to hold every individual accountable for their behavior. There should be investigations in the aftermath to see how much of it was training and the trainers should be similarly sacked/liable, so we can weed out all the garbage in the end.

My career has been the opposite. I grew up on C, C++, then Java. Now I'm on dynamically typed languages and appreciate their advantages and prefer them.

Specs are often over engineered. This is part of the problem. Too much effort in rowing the boat, not enough effort in figuring out the right direction to point it first.

Quasar has all of that. Its strength is the front end. The SSR feature gives you have a place where you can plug in an Express based REST API. There is a large enough community around it to help ensure you don't get stuck.

I looked extensively at various frameworks to see which would make me most productive in starting projects from scratch in my limited development time and this is the one I settled on.

For me, front end is the biggest time sink, so I wanted one that had the best coverage there. Full components suites debugged and working, etc. It really helps that it can target SPA, PWA, mobile (capacitor) as well as SSR.

Disclaimer, these memories are about 3 years old...

> What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine.

Exactly what I said, there would be some code that would run differently in the two environments. I know more now than I did then, but I believe the example was specifically on iOS the app was using JavaScriptCore and the desktop dev tools was using v8.

> I'm not sure I understand, could you provide an example?

> Strange, you're able to catch and debug both JS and native crashes currently. I'm not aware of a past limitation but I could be wrong.

Best as I recall, there was a semi-frequent bug that happened down in our logging system. When it blew up we got a native stack trace instead of JS. My best guess is some kind of handshaking problem between the two layers. Neither used code we wrote and maintained.

Because the whole thing happened inside our error reporting engine, it wouldn't end up in our logs other than a high level apparent failure. It was a mess, and we had limited native experience on the team when it happened. We hired a dev with more native experience, but we still didn't ever figure it out while I was there.

The tool chain always felt like it was a hacked together early beta. To complicate our experience our internal APIs were a mess and unreliable and our React Native codebase wasn't dramatically better. Between our internal problems and all the idiosyncrasies and unintuitive issues in the tool chain it was really miserable.

It wasn't unusual for everyone on the team to spend more than a day simply trying to get the app running again after an update, that is after a dev had completed a 1 to 2 week migration required after the update.

My experience with the tool chain was abysmal. It's been almost 3 years away now for me, so I don't know the current state of things. I hope it has improved.

But every update was a large effort in bringing the app back into compliance with the new changes. The debugging platform used a different interpreter than in app resulting in things that worked in the debugger but not in production. Odd bugs at boundary layers nobody could (easily) decipher. The inability to even catch or do anything with some crashes.

It was the worst experience I ever had with a development tool chain in my entire career.

The only cyclists I actively disliked were those who had stripped their reflectors and then rode around dressed in black at night. Scared me half to death when I finally saw them. That move agitated me quite a bit. Thank goodness I've only run into that once.

Seems to me that it's a very bad idea to disrespect in ways that actively make your own life less safe. Especially on something as fragile as a bicycle. Regardless of the disrespect heaped your way.

Get some plants?

There is no significant tax pool coming from cyclists to build or maintain said infrastructure.

I don't blame them for trying to salvage/use something from what exists, I've been there. I found the behavior of ignoring established traffic law as if it were optional to be dangerous and selfish.

Rolling stops are fine, I have no problem with that. That's a good effort, gives you time to really examine the area. Don't blast through at full speed even if it looks clear. That's a bad unsafe habbit.

There is a significant difference between recreational level exercise and work-every-day-because-you-have-no-other-method that's burning potentially >1000 calories per day and measurably increasing your food bill.