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
No setup at all, just strip-mine the sourcecode for the existing TS client, have it generate curl requests. Run the curls, ask it to create POCOs for the results, and adjust.
@[email protected] wrote a pwsh module for lemmy and can attest to the troubles =D
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.
Completely agree that VS is way more powerful than Rider. It is kept up to date and has excellent tools for new tech like Blazer hot reloads and Maui designer. The debugger is the most powerful way to debug code.
I still use Rider, because I use JetBrains ide's for all my projects and I can run it on Windows Mac and Linux. When I hit a speed bump or want to go fast or try a new feature, i swap to VS :p
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.
Ancient software has been built on layers of undocumented requirements. Even if you could magically find the capacity and budget to refactor it all, you will encounter inconsistent behaviour.
You don't want to be the guy that migrates missile silo software to run on docker.
You will confront business stakeholders with inconsistencies and false assumptions. Ancient software often works like modern ML where the results could be accurate but the method is mysterious. No one wants that.
What people want is for the damn thing to keep on running. That will become increasingly more difficult once the fortran and cobol crowd head into retirement.
Young folks: if you want to be dangerous later, learn how to wrestle with ancient code. Learn refactoring and legacy languages like fortran and cobol. Learn their build systems and hardware. Learn how to interface them with with the 21st century. Because the government is not going to move to nodeJS and Citibank will not adopt dotnet 8 any time soon.
We have used Godot for a application that labels large numbers of documents for ML training data. I've also used it to show my wife the couch she wants to put in our living will absolutely dominate the space and leave no space to have dinner comfortably.
Couldn't find one so yeah ยฏ_(ใ)_/ยฏ. The API is a bit weird tho, so It will take a minute before I get a hang of it. Accepting PR's :P
That sounds like a healthy arrangement! I like this idea of x-func teams that are set up on a temporary basis. We do this often implicitly, but it's good to have an explicit process around it.
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.
My wish for Santa: