A single race condition is a tragedy. A million race conditions is eventual consistency.
Okay, I love these features individually. I loved it when moving from java to kotlin. However, I'm conscerned that these features create multiple ways to do things correctly in C#. Having one way to do things, has been for me one of the best features of C#. It makes it easy to read colleagues code accross generations and easy to onboard new guys.
I do hope we see these adopted quickly, but I hope the C# folks dot start shoehorning in new syntactic sugar for no good reason. The language is starting to get a bit arcane.
Dotnet had really been the ecosystem i keep coming back to. It's been so frictionless. It could be experience, but I really never feel like I'm fighting with it. Running plain C might be the only other ecosystem that I would hold as a less frictionless experience. I genuinely don't hold any frustrations with it. I don't have any ideological problems around Microsoft's involvement. The tool lets me solve problems effectively.
The only thing Im missing is a good llvm target for the clr something like what the kotlin native guys enjoy so i can take the ecosystems to new places.
Sure EFcore can be tiresome and LINQ is inefficiënt. But I'm going to be honest here. If you're trying to squeeze performance out of an ORM and you're running up against performance limits of LINQ, maybe not use a time-saving tool as a power tool?
Maybe I'm simping a bit over it, but I'm not seeing alot of positive content about a tool that has only been very productive in my experience. Maybe because all of the dotnet users are too busy solving actual problems for people haha 😂
Oh and newtonsoft... And maybe xUnit and nUnit could make up and figure out a way to be ergonomic AND work well multi-threaded.
Counter point. Sounds like a c-level pet project on steroids. It doesn't sound like anyone is planning a migration. So they are relying on a big bang.
Now... A question for the panel: how would you say big bangs on corporate software projects with actual customers typically go?
What I love most about Krazam is that in every video they make, you see the guy move up the usual tech career ladder xD
I like refit too! It's super nice, but very quickly i realised the API does some weird undocumented stuff and isn't very consistently implemented. I feel more comfortable doing the boilerplate my myself (chatgpt helps) while i figure out the funk.
Can I be the first to say. Thank you sysadmins of the world for your hard work and steady hands in time of crisis.
I know y'all ascended to the next plane of existence during covid, silently meddling in mortal affairs from afar. But we need you more than ever! Please come back! All my api keys are expiring and I don't know how to refresh them!
Vue has had the fastest growing adoption for the last few years according to the Stack overflow and JetBains surveys.
I've had better experiences onboarding young developers onto Vue projects than React. I also feel that Vue skills transfer better to other applications rather than front-end.
The dev availability is different per region. We see that applicants in northern Europe for example is still very Angular leaning, while SE Asia is more Vue. I think React is mostly a West US phenomenon.
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.
I think that would be great! I started working on a Azure Functions bot and started a DI dotnet client that I put on nuget https://github.com/ydinkov/Lemmy.Net
It's super wip right now, but Ill be adding more models, tests and error handling.
I've been trying to setup a working instance using container apps, web apps for containers and ACI, but it remains finicky. Do you know of a bicep or deployment script that does this properly?
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.