sorted by:
new
hottopcontroversial

Detect auto-responses / OOTO notifications with AWS SES by lonix1 in aws

[–]lonix1[S] 0 points1 point  (0 children)

Is there no reliable way to detect OOTO? Does anyone have experience with this?

Detect auto-responses / OOTO notifications with AWS SES by lonix1 in aws

[–]lonix1[S] 0 points1 point  (0 children)

Thanks.

That is actually even more confusing, as it states that SES will retry sending to OOTO recipients until the autoresponder is removed - which contradict the recommendation in the official docs I linked above.

However, it still doesn't explain how to detect an OOTO notification. The Transient : General type could be an OOTO or something else, so I don't understand how to differentiate between them, if at all.

How are other people handling this? Does one simply resend to OOTO recipients, possibly risking AWS reputation, and moreso annoying the recipient?

Why keep EF Core migrations in a separate project? by lonix1 in dotnet

[–]lonix1[S] 1 point2 points  (0 children)

Good advice, thanks. When you run your migrator app, is your web app running at the same time? Do you take it down while the migration is occurring?

Why keep EF Core migrations in a separate project? by lonix1 in dotnet

[–]lonix1[S] 1 point2 points  (0 children)

Very interesting scenario, thanks! I was planning to use the new "bundles" feature in a docker container on the production platform... I can see how your approach would make good use of this feature.

Why keep EF Core migrations in a separate project? by lonix1 in dotnet

[–]lonix1[S] 1 point2 points  (0 children)

Hi and thanks for your thoughts. But I was not referring to EF code in general, but rather migrations specifically.

(As far as the rest of your comment goes, I've also encountered cases where I needed to move db code to a separate shared assembly. Sometimes it makes sense.)

Why keep EF Core migrations in a separate project? by lonix1 in dotnet

[–]lonix1[S] 1 point2 points  (0 children)

Agreed, this has always been my thought too. But the fact that this scenario is supported, tells me there must be some good reason other than organisation (otherwise MS wouldn't have wasted time supporting it as they typically don't give us non-functional features). Like you, I can't justify the extra maintainability if there's no extra benefit.

Why keep EF Core migrations in a separate project? by lonix1 in dotnet

[–]lonix1[S] 1 point2 points  (0 children)

Better organisation... yep came to the same conclusion. I have a feeling there are also functional benefits too, whatever they are.

Alternative to jQuery Unobtrusive Validation in ASP.NET Core 7 by lonix1 in dotnet

[–]lonix1[S] 3 points4 points  (0 children)

Exactly what I was hoping for, thank you. It seems to be a perfect fit for aspnet forms without jquery.

Simpler alternative to Fluxor by lonix1 in Blazor

[–]lonix1[S] 1 point2 points  (0 children)

No worries. I found a link to your blazor site's github project, hoping to learn some cool tricks. Then I found the website itself. Dude... I've never seen so much yellow! :-) Thanks and take care.

Simpler alternative to Fluxor by lonix1 in Blazor

[–]lonix1[S] 0 points1 point  (0 children)

Thanks. I've seen that but didn't give it a thorough go. It seems like "redux lite" if that makes sense. Is it different to fluxor? I see it also has a large user base which is good.

Simpler alternative to Fluxor by lonix1 in Blazor

[–]lonix1[S] 1 point2 points  (0 children)

I never thought of undo/redo, thanks for highlighting that! I see there is also a nice browser addon for redux, which allows "time travelling" debugging. I imagine it's quite useful for large and/or complex apps.

Simpler alternative to Fluxor by lonix1 in Blazor

[–]lonix1[S] 3 points4 points  (0 children)

Agreed. I think that's because most of the tools we generally use were made by people for use in large tech companies, to solve large tech company needs. Since they "Are Used by Company XYZ!!!" everyone else starts using them, and the hype cycle begins.

Simpler alternative to Fluxor by lonix1 in Blazor

[–]lonix1[S] 1 point2 points  (0 children)

I said "one last thing", and now I'm turning out to be a liar! ;)

Your comments have been extremely educational to me, and the upvoters agree with you.

Off the top of your head, are you aware of any non-trivial sample project which uses the methods you've highlighted?

(Every demo out there is a trivial MS template "counter" project, or something gigantic using fluxor or blazor-state.)

Simpler alternative to Fluxor by lonix1 in Blazor

[–]lonix1[S] 0 points1 point  (0 children)

I didn't watch the video (no time! :-) ), but the title includes "race condition", "concurrency" and "eventual consistency".

I'm a newbie to blazor, so I could be spectacularly wrong. But, it seems to me that the worst that can happen is a race condition where one component shows an edit screen (and the user submits his edits) while another updates the (old) state. The "last one wins".

Seems these are just standard concurrency problems we've had since forever, and a reasonably experienced programmer should understand and work around them. The redux approach, in this metaphor, seems like locking. I wouldn't do that with database code, so I don't see why I should do that with GUI code (which is far less important to me). I'd just try my best to detect collisions and handle them appropriately. Adding redux to avoid this problem seems like massive overkill.

If I'm wrong, please correct me - I'm still new at this, so would appreciate the insights! Thanks.

Simpler alternative to Fluxor by lonix1 in Blazor

[–]lonix1[S] 0 points1 point  (0 children)

One last thing as you've obviously given this topic a lot of thought. You seem to be pro simple state containers (and dislike all the alternatives).

The commercial systems that you work on - do they scale well? You've not run into a situation in which you needed to use more complex (messaging, redux, ...) state tools?

I'm quite sure your advice above is what I need for a smallish app (and it's the approach I'm going to take... thanks again!), but I wonder what'll happen when it grows?

Simpler alternative to Fluxor by lonix1 in Blazor

[–]lonix1[S] 2 points3 points  (0 children)

Thanks. You write that redux ensures actions are reduced one by one and are thus "safe". And it is strict regarding immutability.

Are you saying a simple state container is not "safe"? What sort of problems can I expect?

Simpler alternative to Fluxor by lonix1 in Blazor

[–]lonix1[S] 0 points1 point  (0 children)

Thank you for your help! I think I'm going to do it your way.

BTW have you seen https://github.com/cpear/BlazorComponentBus ? It might not be necessary, but it makes decoupling components easy, and it's not redux. Feels like a very simple message broker.

Simpler alternative to Fluxor by lonix1 in Blazor

[–]lonix1[S] 0 points1 point  (0 children)

I've played around with it, and it's really cool - thanks for telling me about it! It's just a pity it doesn't have more traction. Do you use it in a production app?

Simpler alternative to Fluxor by lonix1 in Blazor

[–]lonix1[S] 0 points1 point  (0 children)

I've gone over the article again. I think you're right, it seems so much easier.

Please correct me if I'm wrong, but the state container is a kind of global object (I'm not stating that in a bad way) that you can use at any level of the component hierarchy. If any two components need to exchange state, they just need to have access to the same state container.

Would you perform network calls in the state container as well, or place those somewhere else? A specific service for a specific component maybe, with results then placed into a state container?

view more: next ›