That laser at the end should have been Java Technology™ ;
You point it at anything, and end up with a huge dumpster fire... Sounds like Java to me
That laser at the end should have been Java Technology™ ;
You point it at anything, and end up with a huge dumpster fire... Sounds like Java to me
In C# I'm generally using Verify for these happyflow tests - So instead of explitly testing every individual property, you just do Verify(state);
and compare the entire state against a json saved state.
A little bit for the same reason of "testing fatigue" - having to manually rewrite assertions of a lot of tests is getting annoying. With that approach you just do a merge compare between results, accept them, and you're done
It's a bit of a vague question, generally an API is backend - and you're kinda asking "should I make a frontend for this?" - hard to tell without context...
If you just want a "semi-developer-ish" frontend, you could look into just making an OpenAPI spec for it, and using something like Swagger as a frontend. Then at least you have some kind of GUI
Problem Details for HTTP APIs - I have to work and integrate with a lot of different APIs and different kinda implementations of error handling. Everyone seems to be inventing their own flavor of returning errors.
My life would be so much easier if everyone just used some 'global unified' way to returning errors, all in the same way
Well you need to try and catch when getting the file anyways, it's probably very rare but imagine a scenario of:
Or the file could exist, but you don't have permissions to actually open it.
So a bunch of languages / already have their own "try open file"
I agree with @remotelove@lemmy.ca - since you "don't know where to start“ - just start simple. Maybe lemmy will be fine for now.
Otherwise, to at least pitch some alternative: you can Google for a vbulletin host. A lot of hosting providers offer a "managed vbulletin" solution. Meaning you don't have to get a bare metal machine and don't have to be bothered with installing all the software yourself.
I don't know if there are free solutions, but with a quick Google, it doesn't seem like it's more than a couple $ a month for a small server
What are you building, it depends a bit on your usecase
Otherwise c# Blazor compiles to WASM
Whatever you do, don’t use G2A and other similar CD key reseller websites
For indie games, sure, I always just buy those legit.
But some EA / Ubisoft game; I rather pay $5 on G2A than risk accidentally downloading a malware infected crack
Where does it end though? It's a bit like infinite craft - but instead of combining resources you'd have to find an inverse for every emoji
It's a bit weird how that actually works though...
"Which of these pictures are traffic lights?"
I'd hope with all the self-driving-(ish) cars coming out, any AI like that should be able to identify a traffic light, right?
If it's a public repo, revoke the key (on your own/company repo it might not matter so much)
Then
git reset head~1
git push - f
It's probably not 'that much of a leap' as you imagine. If you're looking at Git tutorials, they're usually covering all kinda complex scenarios of how to 'properly use Git'. But a lot of people barely care about 'properly using Git' and they just kinda use it as a substitute for SVN... You create branches, you merge them back and forth, and that's about it.
Like if you want to contribute to an open source project, all you have to do is create a fork (your own branch in SVN terms) - commit some stuff to it, and create a pull request (request to have your changes merged) back to the original branch.
git pull
is justsvn update
- getting someone elses commitsNot saying there aren't more complex features in git, or that learning git properly isn't worth it, just saying, I don't think you have to see it as a 'giant conceptual leap' that's preventing you from jumping back into programming. Easiest approach just to get started would be probably to just download a GUI like Sourcetree or Fork, and you just kinda pretend you're still using SVN - approach wise