Rabbit and most databases have their own failover strategy. Putting it all on k8s is fine for a toy app but idk why anyone would deploy a real system like that.
Captured the requests in a flash client used in a 6 hour defensive driving class to skip to the last page. Got my certificate. My friend did the same thing and the company reached out trying to figure out why they were getting all of these database errors...
The list is long. If you're familiar with c++ take a look at C#. Go and Java are safe bets as well. Beyond that there are a million backend languages out there.
I'm curious what things you're trying to do that requires you to overload xunit classes? We use xunit for everything and haven't found any gaps so far.
Because the API is a REST API and you don't want your frontend to have to make 100 calls to render a screen. Each frontend may be a completely different app so they all need the data in their own format. And each team may control their app so you don't want all of the teams roadblocked by the API team.
You're going to think you have it figured out and then they and you are going to get sick. I'm 3 months in and the lack of sleep is tough. Hobbies are on hold. Just try not to think about it too much and focus on taking care of your kiddo, your SO and your job. There might be enough energy to do most of that.
When I see a job posting with no salary all I think is what are they scared of? Must be low. A 4 hour project for a senior? For DevOps? I could spend those 4 hours pinging people in my network and probably have interviews scheduled.
How does returning it to the river solve the problem of their isn't enough groundwater? That water goes back into the ocean where it's stuck if it never rains.
If it's a catastrophe I don't know why the government should have to buy everyone out. The insurance companies should just stop insuring the crops and let the market sort it out.
It probably makes a huge difference how the irrigation is applied. Flooding land with water or digging trenches and running water to crops is a lot less efficient than drip emitters on each plant. Obviously doesn't work for stuff like alfalfa but they shouldn't be growing that anyway...
In the U.S. that's called at will in most states. They can fire you for no reason as long as it's not one of the limited reason protected by the federal government. It doesn't matter how long you've worked there.
The way I have described it is in the movie The Dark Knight they build the machine that uses phones to build something like sonar to see in environments. The way that is depicted in the movie is how I visualize things. I can navigate rooms or areas but I only see this vague representation of objects similar to how it's depicted in the movie. I have no problem with abstract concepts as a software engineer. But I can't visualize a face for example. It's a vague representation in my mind.
The point of "points" is nobody can estimate how long a task will take and it gets worse the larger it is. So it's better to have reference tasks of a certain size and complexity that you do know how long they took and compare to those to get a general idea. You could use hours in that context but it's trying to make you think is terms of size and complexity not hours.
Having been down the route of repos for every service I would always choose monorepo in the future. I could see separate repos for libraries. There is just too much overhead trying to manage multiple repos. With a single repo it's possible to build a package that represents all of your software vs being forced to version everything. Tasks almost always touch multiple services unless you are so big you have a team per service.
With .net core references are much cleaner. There isn't a reference to every file it's handled automatically. The whole csproj hell you're talking about is gone now.