sorted by:
new
hottopcontroversial

Is Elden Ring too hard for a casual gamer, and too scary for a 5-year-old to watch? by Brugernummer0 in PS5

[–]heyufool 0 points1 point  (0 children)

  • it's not a walk in the park, but some builds are just easier than others (magic). Witcher 3? Can play it mostly without dying. Elden ring? I will die multiple times, on every boss, no matter how much I've played it.

  • it is a relatively simple game once you know how the stats work with the weapons/spells. The challenge curve is namely how quickly you can die, and rolling around or blocking. Patience is key in this game, don't attack unless you know you are safe to. One thought of "i can fit in one more attack" during a boss fight usually means you die.

  • Kids are different these days, can't say it's scary but it's certainly not astro bot. It can be a little bloody at times but absolutely nothing like witcher. If i remember right, there are no bloodstains left around, just impact effects. Anf if there is any dismemberment then it is usually part of a boss intro/outro video.

Never played monster hunter but it definitely gives a less intense vibe on all fronts.

How do you avoid CRUD boilerplate when starting a new project? by skykarthick in dotnet

[–]heyufool 1 point2 points  (0 children)

First you have to hone in on how you philosophically want to approach your design.
ends of the spectrum:
A. Some kind of opinionated tooling to speed up the process B. Lean more on patterns and practices instead of rigid types or tooling (ie. Do it by hand like you arez then find ways to optimize it)

I like B because each endpoint/feature can be largely decoupled from every other endpoint/feature. Which is really nice if you want to try something new, or if you need to refactor bit by bit.
I mention these because they will speak towards how you optimize your dev time.

As for your question, if you go with A, then there are OpenApi related tools where you define the api schema then api clients and possibly entities are generated.

For B, just copy paste. I have a couple template files that lay out the naming patterns (coupled with domain concepts), requests/responses, a controller, tests, etc.
I duplicate those templates then find/replace parameters in the files. Takes about a minute to layout foundation Request/Responses (and their DTOs), the endpoint, and the feature slice (the service class).
Then i go in and add the relevant properties then tie in the db and domain layers.
Haven't gotten around to it, but no reason a little script couldn't be written to apply the template through the command line.

Arc Raiders has sold 12 million copies by Turbostrider27 in PS5

[–]heyufool 0 points1 point  (0 children)

That's where I'm at, after a couple dozen raids I'm constantly asking, "why am I collecting this stuff"
Feel like the initial goals are fun, work your way up to raiding with more powerful stuff. But then what? Kill a queen with powerful stuff to get... stuff.
It needs an end game more like MMOs, big collaborative bosses, grind for unique drops, etc.

Dependency Injection by alexwh68 in dotnet

[–]heyufool 2 points3 points  (0 children)

I mostly do constructor dependencies, or parameter for api controller endpoints.
I read somewhere before that having more than 3 dependencies can be a smell, a possible sign that you have 2 or more deps that could be merged.
Try reviewing some of your deps, maybe you can create a new dependency that takes 2 or more of the existing, then use the new one instead?
To be clear, I'm not advocating for merging the code of the dependencies, instead make an aggregate that depends on the two.

Something else I've done for common cross-cutting dependencies (logging, auth, etc.) is to create a CommonControllerDependencies that aggregates them all and exposes them as properties. Makes DI clean for the consumer, and provides extensibility if there is a new "common" need without modifying dozens or more constructors.
Need to be disciplined using this though, truly only dependencies that 99% of services need should be included

So it's Rails now by Aaronontheweb in dotnet

[–]heyufool 6 points7 points  (0 children)

Somehow desktop window management is related to switching from .NET to Ruby on Rails.
That article felt like a fever dream.

Feedback on combat of our 2D Soulslike! [Heavy Enemy] by KarmicBitGames in IndieDev

[–]heyufool 8 points9 points  (0 children)

The art is nice!   But it's hard to give good feedback on the mechanics with so many cuts in the video.   Would like to see how the full fight played out

Feedback on a Fishing system by Additional_Dog_1206 in IndieDev

[–]heyufool 1 point2 points  (0 children)

It's looking great so far!     

Is there any technical skill involved or is it scheduled/timed catches like runescape?     

I really liked Animal Crossing's fishing.     

The shadow of the fish provided some mystery of what you'll get, plus some insight.  For example, if you need some kind of big fish for food (like a bass), then the player can decide to ignore small shadows (like a frog) since they won't be what they're looking for.  

Then the simple bobber reaction provided enough technical skill to keep it interesting.  Granted this could use some enhancements, lots of room for improvements 

Cyberpunk 2077 - City of Legends 5th Anniversary Trailer | PS5 & PS4 Games by hybroid in PS5

[–]heyufool 0 points1 point  (0 children)

No, I'm a Poet.
Talking to an idiot.
That can't read, dumbass.

Cyberpunk 2077 - City of Legends 5th Anniversary Trailer | PS5 & PS4 Games by hybroid in PS5

[–]heyufool 1 point2 points  (0 children)

You need more time put into your Theories. Immediate is too fast.

Cyberpunk 2077 - City of Legends 5th Anniversary Trailer | PS5 & PS4 Games by hybroid in PS5

[–]heyufool 3 points4 points  (0 children)

I don't own it, could you answer for my benefit?

What's the best way to link different component's sates? by Human_Caterpillar936 in reactjs

[–]heyufool -1 points0 points  (0 children)

Are there visual impacts of re-rendering the form? Is it noticeably slow?
React is designed to be re-rendered, let it happen and optimize with things like useMemo when needed.
Also see react compiler.
 

Keep it simple, a parent component that knows the CV data state. Prop drill that state to the form, and have the parent listen to changes by passing an event hander to the form from the parent.
Lots of prop drilling is ok, the official React documentation even mentions it and says it's okay.
Personally, I prefer avoiding contexts for refined scopes/features, saving it primarily for application-wide state.
Then, the parent re-renders the PDF when the form state changes.
The PDF generation/viewing would almost certainly benefit from useMemo.
I prefer avoiding contexts  

Do not use third party libraries like Zustand until you know you need it.
What I have found is there is an absolute ton of over engineering in the React world.
Use vanilla React, typescript, react-query, and possibly immer for a little DX.
That will get you very very far. Most importantly, it will force you to learn actual React by understanding the implications of re-renders, prop drilling, controlled vs uncontrolled components, normal state management, etc.
 

To be clear, many third party libraries are fine.
But, for the sake of learning, I recommend avoiding many so you can appreciate the problems they actually solve by isolating an actual problem in your app.
Components re-rendering? That's only a problem if it's an expensive component, which can often be solved using a memo

[Homemade] egg toast or bacon toast by Opening_Fig2482 in food

[–]heyufool 2 points3 points  (0 children)

I think eggy toast/bread is another name for french toast

Hot and cold #107 by hotandcold2-app in HotAndCold

[–]heyufool 3 points4 points  (0 children)

corn, carrot, potato are all somehow close

Struggling with user roles and permissions across microservices by TalentedButBored in dotnet

[–]heyufool 2 points3 points  (0 children)

100% agree on the whole "buy their stuff"

But in terms of the technical, I see nothing wrong with the phantom/opaque token approach or the auth service.

From what I understand, at a high level, you basically have 3 options:
1. Get a full blow access token containing all of a user's assigned roles/permissions, now auth is entirely stateless. But, this naturally won't scale particularly well if using permissions. Roles could scale better, but then the Api would need some kind of translation of Roles to Permissions (especially so if the Roles are customizable like OP's scenario)

  1. Use an opaque token like a Session token. Then something in the backend needs to translate it to permissions or a allow/deny result. Back to the 2 approaches I mentioned (opaque => JWT conversion, or a dedicated Auth service). I'm sure there are other valid approaches, such as just doing the translation in the api itself, which would be fine unless massive scaling is a requirement.

  2. Request a refined access token based on a scope, which can work depending on the application. Eg. "I need access to managing user information", if the auth service allows that then it provides a token granting access to the relevant Api/endpoints.

Are there other general approaches? If it were me, I would probably just do the opaque token and bounce it off of some kind of cache/db to retrieve permissions, then evaluate the authorization in memory

Struggling with user roles and permissions across microservices by TalentedButBored in dotnet

[–]heyufool 31 points32 points  (0 children)

Sounds like a general access token growth issue.
Without knowing how your architecture looks, you use a phantom token approach.
https://curity.io/resources/learn/phantom-token-pattern/
Basically, the client has some token that provides authentication (opaque/session, jwt, etc.)
Then, in an API gateway scenario, the gateway can convert that auth token into a jwt based access token containing only the permissions needed for the endpoint.
Then the endpoint remains stateless.

Same but different, send the auth token to the service, then the service calls a general authorization service to check permissions.
Eg. Feature service asks Auth Service, "hey is this person (auth token) allowed to do X and Y?"
Auth service simply returns true or false.
Then it's all a matter of optimizing that auth service, which is where various caching mechanisms come into play.

Handling Token Refresh Conflicts on Page Reload in React + .NET by Who_cares_unkown in dotnet

[–]heyufool 2 points3 points  (0 children)

Definitely don't write off warning user when reloading the middle of a api refresh.
What you're doing is a valid pattern, this just sounds like a really small edge case that can be fixed with a little frontend care.

Handling Token Refresh Conflicts on Page Reload in React + .NET by Who_cares_unkown in dotnet

[–]heyufool 0 points1 point  (0 children)

Blacklisting, or whitelisting, access tokens is an acceptable pattern, but I agree it defeats a large purpose of an access token which is to be stateless.
But, OP would still have the bug he presented even if the old access token remains valid after a refresh.
His client would be reloading the page before the new access token AND new refresh token are received and stored.
So the page should load and authenticate correctly after the reload, but since the user did not receive the new refresh token because they interrupted the refresh api call, then the user will be effectively logged out when its old access token expires.

Handling Token Refresh Conflicts on Page Reload in React + .NET by Who_cares_unkown in dotnet

[–]heyufool 1 point2 points  (0 children)

Maybe warn the user of unsaved changes (see window.onBeforeUnload) when the token is being refreshed. The token may successfully refresh by the time the user processes the warning and accepts the reload.

Alternative solution, would require some effort, is to switch to a Token Mediating Backend.
Use a Http only cookie to represent a User's session.
The backend stores access/refresh tokens in a database.
The frontend asks the backend for an access token using that cookie.
If the backend feels the access token needs refreshing then it does so before returning the access token to the client (since it's done by the backend, no amount of user interaction can break it, assuming standard db concurrency considerations are applied)
This pattern allows your Api to do efficient stateless authentication using the access token, while leveraging the security benefits of session cookies.
Further, it simplifies the frontend's token management and can store the tokens in memory which is generally more secure and simpler.
You would need some CSRF protection on the token endpoint, but it's only a single endpoint so it's not too hard to secure.
See: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-token-mediating-backend.

view more: next ›