When choosing one of several A/B test options, a hypothesis test is not needed to validate the choice.

    import pandas as pd


    purchases = pd.read_csv("purchases.csv")

    (
        purchases.loc[
            lambda x: x["amount"] < 10 * x.groupby("country")["amount"].transform("median")
        ]
        .eval("total=amount-discount")
        .groupby("country")["total"]
        .sum()
    )

    (
        purchases.loc[
            lambda x: x["amount"] < 10 * x.groupby("country")["amount"].transform("median")
        ]
        .assign(total=lambda df: df["amount"] - df["discount"])
        .groupby("country")["total"]
        .sum()
        .reset_index()  # to produce a DataFrame result
    )

purchases[amount <= median(amount)*10][, .(total = sum(amount - discount)), by = .(country)][order(country)]

```

- no quotes needed - no loc needed - only 1 groupby needed

Does anyone know why they care about this structure? Naively, there are 36^7 (minus edge cases) combinations available, which will always be sufficient.

In addition, all-numbers-plates, I believe, are reserved by California exempt plates (emergency vehicles, police), and vanity plates are absolutely a thing, much more likely to start and/or end on a letter, so that's why you see numbers at the beginning and end. Like you can kinda see “6EIC023” and say “oh yeah my car looks like an ad for Geico” but because the start and end are numbers it doesn't occur to most people.

That’s the primary way you can differentiate them at a glance from the DP (Disabled Person) plates.

Just a little odd fact; I know you meant the more standard plates.

I may be wrong, but that’s what get when I see them.

This is not a shock. After moving here, I find that CA's highly-touted "car culture" is pretty retrograde compared to other major metro areas.

Writeup about some of the ideas that went into it:

https://www.marginalia.nu/log/a_112_slop_ideas/

> log, plank, stick, crafting table, wooden pickaxe, cobblestone, stone pickaxe, iron ore, furnace, iron ingot, iron pickaxe and diamond

I had a former boss who strongly pushed my team to use the repository pattern for a microservice. The team wanted to try it out since it was new to us and, like the other commenters are saying, it worked but we never actually needed it. So it just sat there as another layer of abstraction, more code, more tests, and nothing benefited from it.

Anecdotally, the project was stopped after nine months because it took too long. The decision to use the repository pattern wasn't the straw that broke the camel's back, but I think using patterns that were more complicated than the usecase required was at the heart of it.

I am either now learning that the Repository pattern is something different than what I understand it to be, or there is misunderstanding here.

I cannot understand how (basically) tucking away database access code in a repository can lead to complicated code, long development times, and the entire project failing.

One thing to note -- you stated in another comment that the repository pattern is just for database access, but this isn't really true. You can use the repository pattern for any type of service that requires fetching data from some other location or multiple locations -- whether that's a database, another HTTP API, a plain old file system, a gRPC server, an ftp server, a message queue, an email service... whatever.

This has been hugely helpful for me as one of the things my company does is aggregate data from a lot of other APIs (whois records, stuff of that nature). Multiple times we've had to switch providers due to contract issues or because we found something better/cheaper. Being able to swap out implementations was incredibly helpful because the business logic layer and its unit tests didn't need to be touched at all.

Before I started my current role, we had been using kafka for message queues. There was a huge initiative to switch over to rabbit and it was extremely painful ripping out all the kafka stuff and replacing it with rabbit stuff and it took forever and we still have issues with how the switch was executed to this day, years later. If we'd been using the repository pattern, the switch would've been a piece of cake.

Could I get you started? Or could you point me to a place to get myself started? I primarily code in Python and I've found dependency injection, by which I mean giving a function all the inputs it needs to calculate via parameters, is a principle worth designing projects around.

    class C:
        def __init__(self):
            self.foo = ConcreteFoo()

   class C:
        def __init__(self, foo: SupportsFoo):
            self.foo = foo