microsoft.com is back -

edit: it worked once, then died again. So I guess - some resolvers, or FD servers may be working!

FWIW, all of our databases, VMs, AKS clusters, services, jobs etc - are all working fine. Which services are down for you, maybe we can build a list?

Front Door is down for us (as Azure‘s Twitter account confirms)

Sorry - my bad. I literally just connected an old XP VM to the internet to activate it.

Ouch, and login.microsoftonline.com too - i.e. SSO using MS accounts. We'd just rolled that out across most (all?) of our internal systems...

And microsoft.com too - that's gotta hurt

It is interesting to see the differential across different tenants in different geographies:

- on a US tenant I am unable to access login.microsoftonline.com and the login flow stalls on any SSO authentication attempt.

- on a European tenant, probably germany-west, I am able to login and access the Azure portal.

SSO and 365 are working fine for us, but admin portals for Azure/365 are down. Our workloads in Azure don't seem to be impacted.

Guess you have NASSO now (Not A Single Sign On)

It's Safe and Secure!

We are very dependent on Azure and Microsoft Authentication and Microsoft 365 and haven’t had weekly or even monthly issues. I can think of maybe three issues this year.

I had a fun pet project, once. Made it available for free to use. Regular releases, and others in the small community made other similar tools.

The amount of shit I got because it wasn't open source was astounding. Akin to bullying.

It was MY pet project! Literally every week, every release, I'd get negative or downright nasty comments.

I wasn't forcing anyone to use it.. people are just so entitled.

Just my experience..

"Top interior design trends" - title of the login page?

Ah - based on https://kitchengpt.io/room-design

Maybe they're cranking out AI SaaS products to see what sticks. I was going to say low effort, but it's not zero effort and does offer some kind of service. I could have used some AI help for my kitchen design, I hated the process.

The article points out it's technical debt..

No, why? You have to click Approve but then the tweet shows

Huh… all I see is two pictures and text with no links (there’s bbc chrome at the top and bottom)

> Does CrowdStrike do any testing whatsoever? Obviously they didn’t or the incident wouldn’t have happened.

Eh, parts of this article aren't very reasonable. Even if they did a buttload of testing, it only takes one failure in one part of the chain (near the end).

They didn't test something they should have, sure, but obviously they didn't do "no testing whatsoever"

Deploying untested changes isn't "near the end of the chain", and it voids any buttload of testing of something else.

Solution in C#: use named parameters: RaiseInvoice(taxInvoice: false, sendEmail: true)

If you don't have named parameters, you can fall back to variables

  var taxInvoice = false
  var sendEmail = true
  RaiseInvoice(taxInvoice, sendEmail)

It's obvious, but people tend not to do it.

Sadly there is nothing that can tell you that you got those arguments backwards.

Point taken. But you can check the declaration of RaiseInvoice and see if the names match. If you had RaiseInvoice(false, true) then you really wouldn't know.

Totally a matter of taste, but for an equal level of protection and less vertical waste I’d rather just do

    RaiseInvoice(/*taxInvoice*/ false, /*sendEmail*/ true)

Which is far more realistic than defining single-use enums all over the place.

I don't know why more languages don't have named parameters...

Why is defining an enum "unrealistic"? It's at most 4 lines of very simple code to define an enum that replaces a boolean.

Think about cases more complicated than passing a bare literal.

  // Booleans + Named Parameters
  foo(should_scrub=not options.scrubbing_disabled)

  // Single-Use Enum
  import ScrubbingOption, ShouldScrub;
  foo(
    if options.scrubbing == ScrubbingOption::Disabled {
      ShouldScrub::No
    } else {
      ShouldScrub::Yes
    }
  )

If you format the second example more sensibly:

    foo(options.scrubbing == ScrubbingOption::Disabled ? ShouldScrub::No : ShouldScrub::Yes)

it doesn't look much worse at all

I'd actually go further and say that there's no reason I can think of that foo() shouldn't have access to the ScrubbingOption, so just pass that in.

If you have two-option enums and for some reason you transform them into two-option enums that represent essentially the same thing, of course that's going to be unnecessarily complex.

As a general rule, "it's more verbose" isn't much of a concern to me: verbosity is a very poor indication of complexity, and entering code with your keyboard simply isn't the bottleneck for writing code (if it is, you aren't thinking about what you're writing enough).

> If you have two-option enums and for some reason you transform them into two-option enums that represent essentially the same thing, of course that's going to be unnecessarily complex.

"For some reason" being anything so prosaic as they come from different libraries.

If you have two libraries that aren't explicitly made to work with each other and operate on the same problem domain, being explicit about the translation layer between those two libraries is very much a feature, not a bug. That's absolutely a spot where verbosity and named enums will shine.

That doesn't fix readability (is the invoice being raised not a tax invoice? Or are we not taxing the invoice being raised?).

That doesn't fix the possibility of adding a third possibility either (what if we separate non-tax invoices into two types of invoices?).

RaiseInvoice(InvoiceType::Tax, Notifications::Email);

no, way better to make an options object then set the options you want, also works a lot better later when you want more options.

Way better use a bit pattern.

You can't force the caller into using named parameters though. So when it's late at night, you're tired but also think you know better, there's nothing stopping you from doing RaiseInvoice(true, false) when you actually meant the inverse.