Graphene is in a class of its own compared to both of these though and there's frankly no reason to bother unless you're trying to improve those ecosystems.

In case others, like me, weren't aware.

I'm quite enthusiastic about Graphene's OEM partnership,though.

Re: the FuriLabs phone, yeah, it's rough - but it's definitely usable for early adopters who want to contribute and help build.

All support channels are now AI and refuse to help and redirect me to self service. There is _no_ self service path for Azure account recovery if you lose your 2FA token.

It's infuriating. I lost access to a bunch of hobby projects I had hosted on DevOps. Microsoft will never see a dime from me.

Heh. I learned this hard way when trying to set up multiple monitors with different refresh rates

This is different, and everyone pretending it is not, is being intentionally ignorant or genuinely ignorant, neither good. I did not give so much to the public internet for the benefit of commercial AI models, simple as that. This breaks the relationship I had with the public internet, and like many others I will change my behaviour online to suit.

Maybe my tune will change once there's a commercial collapse and the only remaining models are open source, free for all to use. But even then it would be begrudgingly, my thoughts parading as some model's abilities doesn't sit right.

This captures perfectly what I was trying to say. Thanks

To make another example, even though my reddit history is public (or was until recently because I didn't have a choice) I would still feel uneasy if I realized someone deliberately snooped through all of it. And I would be SUUUUPER uncomfortable if someone did that with my Discord history.

It's not against the rules or anything, I just think it's rude.

Making the content queryable by a database engine is merely a technical optimisation of the efficiency with which that content may be consumed. The same outcome could have been accomplished by capturing a screenshot of every web page on the internet, or by copying and pasting the said content laboriously by an imaginary army of Mechanical Turks.

A private network may, of course, operate under an entirely different access model and social contract.

It's two clicks to get to that page from this page. Say the wrong thing here and some troll will go through it and find something you said years ago that contradicts something you're saying today. If the mere thought of that bothers you, I don't know what to tell you other than to warn you of the possibility.

Like Picard said - if you're going to be damned, be damned for who you really are.

But iif you perfected it then it would also be the thing that actually kills software development. Because if I told you your whole job is now writing tests, you’d find another job.

Their job is to make sure that the business people and the devs sort it out without coming to blows. When they do work like this it's generally as a template to be copied, not the entire project.

But the only people who write code as bad as QA folks do are the DevOps people.

The paradox of SDETs is: QA makes less than dev, no matter what flavor. If you're good at poking holes in developer logic, and you can code yourself, there's a 40-60% raise for you if you can switch into security consulting, which takes the same foundational skills and some reading.

So there are at least two brain drains for "good coder in test", and we aren't even the most lucrative one.

I deleted it after realizing that the article actually does address this. But I'm still relieved that I'm not the only one with the dillema.

> which if you miss, just means you may end up with a failed CI build to fix…

Honestly as a developer if I miss this up until CI, that's on me. The important part is that these issues are still visible during the local development, even if as warnings, and that the developer knows (maybe after making that mistake once or twice :-)) that they can't just be ignored because they will fail down the road.

Yeah I agree. This has got me thinking a bit more actually about how to optimise build configurations much more deliberately. Dev loop builds vs “normal” (local) builds vs production builds.

I got into the habit of turning on TreatWarningsAsErrors in greenfield .NET projects, trying to be a disciplined developer… But often these warnings can be a distraction during fast iterations… I think I may change my policy…

Your comment shows a hefty amount of ignorance. Repositories wrap Entity Framework because Entity Framework's DbContext & Co are notoriously complicated to mock and stub.

Once you wrap EF stuff with a repository that implements an interface, that problem vanishes and all your code suddenly is unit testable.

But I admit my tone missed the mark. It may have been much harder to do in the past, or maybe I'm missing some nuance.

But also at this point why not just have your DbContext directly implement an interface that you can mock? Surely that must be more straightforward than adding an entire abstraction layer, that you have to extend with each new usage scenario, and without sacrificing implicit transactionality.

No, you don't. At best in-memory databases represent a test double that you can use in integration tests.

If you need to write unit tests, EF leaves you no better option than to add repositories to abstract out everything and anything involving DbContext.

  public class Repository<TEntity> : IRepository<TEntity> where TEntity : class
  {
      public async Task Add(TEntity entity)
      {
          _context.Add(entity);
          await _context.SaveChangesAsync();
      }
  }