Man, I have to agree. Your write up reflect my experience with Azure Functions in a mid-large sized application way more than the post. Fantastic
The way I managed to get an intuition about the language is just building classic boardgames. Checkers, chess, diplomacy and go are great exercise to start working with lists and dimensions, declaring multiple predicates and have them interact with each other. Changing the state of the program and using the traces to branch out decisions. Remember to keep track of your interpreter. Different interpreters act in surprising ways. The order of operations of SWI is different than Tau.
After that, the honest truth is that Prolog isn't widely used enough to have a 'modern standard approach'. The best way is to treat it like any other embedded subsystem: light and concise scripts embedded in a grown-up language.
I use milkman
We use them. They have been incredibly helpful. The concept has spread to our product team making product decisions!
This script will rotate a MeshInstance2D node clockwise on the screen:
extends MeshInstance2D
var rotation_speed: float = 1.0
func _process(delta: float) -> void:
rotate(delta * rotation_speed)
- Create a new scene
- add a MeshInstance2d
- set it's Mesh parameter on the right to new BoxMesh
- scale it and put it in the middle of the screen
- add this script to it
- press play
If you've figured out to do the above correctly, you will see a box spinning clockwise on your screen.
Now figure out how spin it counter-clockwise
After that see if you can figure out how to move it to the left. Then see if you can move it back and forth.
Congratulations! You've started :D
What are some things you're trying to accomplish? C# looks very different in the cloud, as a website, in a game engine or on a mobile app.
Procrastination is like getting into the pool for the first time in the morning. Gradual exposure to the cold water is the most painful way to go. The fastest way to get going is to jump in!
I totally understand. It sounds like you've been put in a frightening spot. These transitions really hard enough to do for established managers that have worked at a company for a while, let alone for a fresh hire. It sounds to me like you are doing all the right things: putting tasks into systems and managing expectations.
A growing organization is used to moving fast and when you reach a certain size, you start spinning wheels. Very rarely do companies stay ahead of the curve and setup systems before they hit that wall. You are in the unfortunate position of having to slam the breaks.
Often a company needs an outsider influence to be able to do that. The old guard is used to going fast and haven't developed the tools to go far yet. To me, it sounds like you are doing exactly that. Accept that there will be friction. The new company will work for different personalities. The people that take you from 5-50 are going to be completely different that take you from 50-500. You will lose people in this transition and all you can do is keep a steady course and communicate realistic expectations to stakeholders.
Something that helped me a ton during a turbulent time was implementing patrols. Now, I was lucky to be granted a lot of freedom to implement process changes. But it did really help us to minimize all the small tasks and distractions that kept coming up. Regardless of what tools you use, those little in-betweeners are by far the cause of most overhead. They never really take less than an hour to complete and they are constantly taking an engineer out of the working memory for a complicated task. Also, people love doing them, because you get a small accomplishment every few hours. It's much more difficult to sit with a long project for weeks without much progress, but it's easy to pickup low-hanging fruit. You're doing well to eliminate those.
When it comes to a billion client requests, a bit of requirement engineering goes a long way. Go through the requests and try to understand the root of the problem they are trying to solve. Propose a projects around solving that problem and eliminate all the chatter while your team can focus. If the requirements for that project change too much, then that means the chatter is even more wasteful and needs to be eliminated. A smart business will recognize this.
As for expectations. Yeah, it sounds like it's up to you te set expectations for you and your team. Stakeholders don't have preset expectations and often look at you to set the standard. You want to bring clarity to the table. You want to have the difficult conversation about responsibility and accountability. Again, none of that has much to do with databases and virtual machines.
Access Control
Whenever possible, I've run projects to have zero downtime deployments. Multiple stateless instances behind a load balancer. Deploy one instance at a time, run a health check and move traffic to the fresh instances. Most cloud providers often have these out of the box. Database migrations are run well in advance. New functionality is hidden behind feature flags.
Zero downtime is nice, but the real benefit is that you force the teams to really think about deployments as migrations to accomplish this policy.
Your instrumentation and alerting need to be top-shelf you need to automate deployments fully, which means you can fully automate rollbacks.
The downside is that you have to build everything twice, deployments are slower and there is a significant descaffolding.
But that's a small price to pay not to be on call outside of business hours to deploy.
Our approach is by no means the best or even applicable for most organisations, but it goes like this:
There is no such thing as a miscellaneous task. Each hour spent on work should be accounted for towards business goals. If you are fixing bugs, you link the bugs to bug reports or features that describe how the system should behave. The same goes for testing tasks. If you are doing ops, it's either reactive or proactive. Reactive ops are linked to issues and incident reports. Proactive ops are linked to new releases or experiments. If you are doing R&D, link it to a new initiative. If you are doing process automation or dev QOL improvements, have a continuos initiative to account for that work. As a business stakeholder, I need to be able to see where the hours of my 2 dozen devs are going. Are we spending our time on bugs, QOL, KTLO or Features? If I see that half the logged hours are set under 'Miscellaneous', I can't really have that conversation.
Always ask yourself: "What problem am I actually trying to solve".
It can't be that you have a task, no matter how small, that can't be accounted towards any existing business goals.
Azure Artifacts has been great for private stuff. Have you tried Github packages yet? Works well enough for public packages. I don't know what your use case is, but what prevents you from using nuget.org?