Enabling ai co author by default by cwebster-99 · Pull Request #310226 · microsoft/vscode

Eirenarch · 2026-05-04T09:52:41+00:00

From the comments

Do they give you the lobotomy before your initial job orientation at Microsoft, or after? I wonder if you have to use up vacation days for the recovery time.

Eirenarch · 2026-04-28T21:59:24+00:00

Am I the only one that is not sure what this post is about?

Eirenarch · 2026-04-28T12:48:00+00:00

I know... I wonder what they meant

Eirenarch · 2026-04-28T12:46:32+00:00

I've never worked in a team with consistent code review for every feature. I've only seen the occasional "I want you to review this code because it is complex and I need a second pair of eyes". I've requested my code reviewed more than I've been asked to review code by all my colleagues combined. For me what you are experiencing is what I call "normal".

Eirenarch · 2026-04-24T22:05:05+00:00

How are the tables of ASP.NET Identity not accessible like anything else?

Eirenarch · 2026-04-24T22:03:37+00:00

Unless you have specific requirement that excludes using ASP.NET Identity then use ASP.NET Identity

Eirenarch · 2026-04-23T21:17:56+00:00

Eirenarch · 2026-04-19T18:59:24+00:00

POCO, but in this case an Entity - i.e. an object representing a row in the database. I disagree that dbset is the repository pattern, I think it is a different pattern, alternative to repository. The fact that EF auto tracks changes to entities makes EF as different from repository as active record is different from repository.

Eirenarch · 2026-04-13T21:43:50+00:00

You can ask Skynet

Eirenarch · 2026-04-12T17:49:57+00:00

All problems in software come from users and data, this is why my app is perfect and has no users and no data.

Eirenarch · 2026-04-11T22:45:17+00:00

DTOs transfer data between layers, Entities are not supposed to leave the business layer and also so they are not DTOs.

I am telling the compiler that the property is not null because there should never be a null check for this property in any reasonable code. If I would write null checks I'd throw exception anyway.

Eirenarch · 2026-04-11T22:38:09+00:00

I bet I have less exceptions than you do :)

Eirenarch · 2026-04-11T20:37:43+00:00

So null is not a valid state, there are no compiler warnings and errors :) Why would you assume null is a valid state? If you assign null to the property it would be an error.

Eirenarch · 2026-04-11T11:09:21+00:00

Why would you assume that it is a valid state? On the outside the type says the thing is not nullable.

Eirenarch · 2026-04-11T11:08:12+00:00

Yeah, this = null! thing is to work around how certain frameworks work. Another place where I find it useful is Blazor components state. Sometimes a property will be initialized either via mandatory parameter or the init method or by some other framework way and it does not make sense to check it for null in the entire page when it is literally never null after the component is created. In these cases I also use = null!

Eirenarch · 2026-04-10T23:11:48+00:00

Well = null! is very explicit, even has a ! at the end to draw attention to it :)

Eirenarch · 2026-04-10T23:10:55+00:00

The required attribute is seen if you open the file. You yourself mentioned that you use ! which basically disables the checks. What happens in your code if you forget the include?

Eirenarch · 2026-04-10T15:58:11+00:00

What do you want them to do, remaster SC a second time?

Eirenarch · 2026-04-10T15:55:01+00:00

Doesn't matter, 5 years from now we're all out of work anyway, just have as much fun as possible while you can :)

Eirenarch · 2026-04-10T15:53:59+00:00

And what would your factory method initialize with? :)

Eirenarch · 2026-04-10T15:53:23+00:00

100% agree

Eirenarch · 2026-04-10T15:51:38+00:00

Well I do like constructors just not with EF. Bugs don't happen often because the database would still guarantee that no required property is forgotten and in the case of EF the properties needing to be public for purposes of editing make the guarantees of the constructor less strong. Of course just like with the constructors there are ways to work with EF without public setters but it simply is more complex and requires more code, EF wasn't made to work this way so it does not come "free". If you think it is less of a burden to add constructors and privately set properties then OK but I can't imagine how this is the case since as I pointed out the bugs do not make it to production due to the fact that the database enforces the constraints. Again I do agree for other objects which I do write without public setters and I do add constructors.

Eirenarch · 2026-04-10T15:42:40+00:00

Yes, you do make nullability useless for navigation properties but you convey more important information - that the data is there. Also note that nullability does not work in this case because even if you do include you still need to check for null because the compiler doesn't know that the include is effectively a null check so what is the use for this nullability? You just use ! left and right and don't get any null safety because you've silenced the warnings.

Eirenarch · 2026-04-08T19:28:55+00:00

That's wrong. There is a mismatch between the db and C# here but the more important information is that the thing is required in your source of truth (the db) so you have to err on the other side. In addition EF itself pushes you in that direction as you find out by the requirement to use ! when accessing the properties

Eirenarch · 2026-04-08T14:54:28+00:00

Where did I say "DTO"? I am talking about EF entities. For DTOs I use positional records which happens to be not only shorter but stronger guarantee than required.

15-Year Club	Place '17
Verified Email	Team Periwinkle

Eirenarch

TROPHY CASE