It's not a dominant database anywhere on the outside.

However since we now got the tools for running on both, and experience migrating, we might be moving to PostgreSQL at some point in not too distant future. Managed MSSQL in Azure is not cheap.

And "Holy crap, this is not cheap" is why I see plenty of companies transitioning off MSSQL.

Microsoft is heavily investing in Postgres in fact which is why they bought PostGres sharding company, Citus and looking at commit history on PostGres, they have several employees actively working on it. They also contributed DocumentDB which is Mongo over Postgres.

It will take a long time to die and Microsoft will still continue to do little work on the product and stack your money in their vault while giggling.

(What's that? Well, if you ever walk into a place like a gigantic oil refinery, you'll see a bunch of people working there. If you look long enough, you'll notice that each of them have an expensive-looking radio ("walkie talkie") on their hip. Some of those radios may be my fault -- and of those that are, there's an MS SQL database that knows exactly how it was programmed. But I didn't pick it; that's just how the system operates.)

We almost got into bits of the P25 side to help service $giant_government_entity's system, but the GTR 8000 training was complete ass. Mostly what we got out of it was long periods of the dude fretting about the clutch job that his Hyundai was in the shop for and talking on the phone about that, interspersed with a repeated slogan of "I was a Navy man. I don't know what makes sense to you, but I do things by memorizing steps instead of understanding how they work."

Sometimes, he'd get around to mentioning some of those steps.

Much waste, very disappoint.

We all very thoroughly failed the test at the end of that week.

It’s completely dominant in its industry and has no real competition. Pricing starts at $200 a month for the most basic, single user setup and goes up (way up) from there.

And no, it doesn’t work on ARM, at all. I tried.

Very seldom I use something like Postegres, last time was in 2018.

They have all been dotnet ecosystem, but self hosted rather than Azure

I think the latest versions of SQL Server also run on Linux now.

We experienced several of those over the years, and generally it was the test that was wrong, not the code it was testing.

For example, this simplified test hits several of those pitfalls:

    var expected = start.AddMonths(1);
    var actual = start.ToLocal().AddMonths(1).ToUtc();
    Assert(expected == actual);

Always include some randomness in test values.

then it actually is a huge success

because it found a bug you overlooked in both impl. and tests

at least iff we speak about unit tests

The whole concept of allowing a flaky unit test to exist is wild and dangerous to me. It makes a culture of ignoring real failures in what, should be, deterministic code.

So, yes, logging the inputs is extremely important. So is minimizing any IO dependency in your tests.

But then that runs against another important rule, that integration tests should test the entire system, IO included. So, your error handling must always log very clearly the cause of any IO error it finds.

If this isn't a joke, I'd be very interested in the reasoning behind that statement, and whether or not there are some qualifications on when it applies.

so if you generate test data randomly you have a higher chance of "accidentally" running into overlooked edge cases

you could say there is a "adding more random -> cost" ladder like

- no randomness, no cost, nothing gained

- a bit of randomness, very small cost, very rarely beneficial (<- doable in unit tests)

- (limited) prop testing, high cost (test runs multiple times with many random values), decent chance to find incorrect edge cases (<- can be barely doable in unit tests, if limited enough, often feature gates as too expensive)

- (full) prop testing/fuzzing, very very high cost, very high chance incorrect edge cases are found IFF the domain isn't too large (<- a full test run might need days to complete)

people often take flaky test way less serious then they should

I had multiple bigger production issues which had been caught by tests >1 month before they happened in production, but where written off as flaky tests (ironically this was also not related to any random test data but more load/race condition related things which failed when too many tests which created full separate tenants for isolation happened to run at the same time).

And in some CI environments flaky test are too painful, so using "actual" random data isn't viable and a fixed seed has to be used on CI (that is if you can, because too much libs/tools/etc. do not allow that). At least for "merge approval" runs. That many CI systems suck badly the moment you project and team size isn't around the size of a toy project doesn't help either.

So don't do that. That's bad practice. The test has failed for a reason and that needs to be handled.

Some tests can be at the mercy of details that are hard to control, e.g. thread scheduling, thermal-based CPU throttling, or memory pressure from other activity on the system

A test should communicate its reason for testing the subject, and when an input is generated or random, it clearly communicates that this test doesn't care about the specific _value_ of that input, it's focussed on something else.

This has other beneficial effects on test suites, especially as they change over the lifetime of their subjects:

* keeping test data isolated, avoiding coupling across tests * avoiding magic strings * and as mentioned in this thread, any "flakiness" is probably a signal of an edge-case that should be handled deterministically and * it's more fun [1]

[1] https://arxiv.org/pdf/2312.01680

If you test math_add(1,2) and it returns 3, you don't know if the code does `return 3` or `return x+y`.

It seems I might need to revise my view.

  jitter = random(5)
  assertEqual(3 + jitter, math_add(1, 2 + jitter))

Nowadays I think this would be done with fuzzing/constraint tests, where you define "this relation must hold true" in a more structured way so the framework can choose random values, test more at once, and give better failure messages.

Damn, must be why only white hair is growing on my head now.

>Nowadays I think this would be done with fuzzing/constraint tests, where you define "this relation must hold true" in a more structured way so the framework can choose random values, test more at once, and give better failure messages.

So the concept of random is still there but expressed differently ? (= Am I partially right ?)

Here's an example with a python library: https://hypothesis.readthedocs.io/en/latest/tutorial/introdu...

The strategy "st.lists(st.integers())" generates a random list of integers that get passed into the test function.

And also this page says by default tests would be run (up to) 100 times: https://hypothesis.readthedocs.io/en/latest/tutorial/setting...

So I'm thinking... (not tested)

  @given(st.integers(), st.integers())
  def test_math_add(a, b):
      assert a + b == math_add(a, b)

- Test 1 -> set data_1 with value 1

- Test 1 -> `do some magic`

- Test 1 -> assert value 1 + magic = expected value

- Test 2 -> set data_1 with value 2

But this can fail if `do some magic` is slow and Test 2 starts before Test 1 asserts.

So I can either stop parallelism, but in real life parallelism exists, or ensure that each test as random id, just like it would happen in real life.

doing random things to hopefully get a failure is fine if there's an actual purpose to it, but putting random values all over the place in the hopes it reveals a problem in your CI pipeline or something seems like a real weak reason to do it.

Modern phone water resistance is incredible. I've even seen people literally swim with their phones and not even question if it was a bad idea.

The battery compartment had a rubber gasket and some very tight screws.

I suppose the glue-everything approach is partly due to the desire of making a device very thin. There's no room for strong, load-bearing outer case, the internals are load-bearing.

There is a good reason waterproofing claims are specific about the kind of liquid (usually just fresh or salt water, usually without significant movement (i.e. jets, like you get in a shower)).

These devices are mostly sold in enterprise environments (eg field use, factories) and as such get a lot of wear and tear. But they hold up well. They're not ultra rugged but a good compromise. We use tons of them in our factories, we replaced DECT handheld phones with the Xcovers loaded with ms teams. Not an ideal setup (teams for mobile kinda sucks) but at least this way they can easily communicate with people in the offices.

Samsung Galaxy XCover7

  169 x 80.1 x 10.2 mm (6.65 x 3.15 x 0.40 in) 

  150 x 71.9 x 8.8 mm (5.91 x 2.83 x 0.35 in)

The Xcover 4S was 146.2 x 73.3 x 9.7 mm (5.76 x 2.89 x 0.38 in)

Also, these are business rugged models, unlike the iPhone.

I'm not knowledgeable enough to know if IP68 could be achieved in a phone without glue. There's no clamping mechanism for the backs, they're just press-fit with small clips.

A phone needs to handle some rain droplets falling on its screen, anything more than that is a gimmick that's not worth the downsides it comes with.

I submerge my phone as a matter of normal use because I can. I take it into pools and hot tubs, and I clean it in the sink -- I personally wouldn't trade that for a battery door.

Then I won't chance any submersion and I can't think of an accurate way to test it.

Over a decade ago, I replaced a phone screen over a few hours, involving a couple dozen screws. During that, I had to remove the battery. (Replacing only the battery would have been easier.) I'm a layman, and all the screws were Phillips. That's sufficient to be replaceable.

It's not really the old kind of replace-ability, though. The only requirement is that you should be able to change it with commercially available tools.

Most the suburban kids in Houston had wristband attachments to their phones in the pool or would be in a floaty taking stupid pics of each other as kids do. Trying to keep a modern phone dry takes away a lot of utility.

Some like to read in the bathtub. Statistics say women prefer the bathtub more than the shower. Therefore your position is sexist.

(Yes, I'm being an asshat)

I suspect it's a moot point. Makers have every incentive to drive replacement cycles.

I keep my phones for 3-4 years, and the battery life while degraded isn't really an issue.

And that's with recharging it just about every night even if it's not dead.

I had to make the choice of getting another phone (used in great condition, as I do) or pay half the cost I paid to get the battery replaced but also knowing it would still be heaviy used and more likely to fail in other ways because of use.

If labor cost and decreased relaibility weren't factors, swapping the battery would have been the choice.

Now the question is: are there more people like me or more people who need a sealed, hard to repair phone? I don't know but if I did I'd accept keeping the current situation.

While manufacturers do have an incentive to get people to buy new phones, many of them with first party insurance do have an incentive not to pay out as many claims.

It also officially support submersion in seawater as well as cleaning with soapy water. Most glued phones support neither.

1: https://k-tai.watch.impress.co.jp/docs/news/2088291.html

The original claims in this tree is that waterproof phones with removable backs are somehow impossible and glued shut designs are somehow superior. That's a total BS, so I posted a counter example. Torque phones being rugged in addition to being waterproof, unlike iPhones that are just purified-water-proof, has nothing to do with feasibility of one-upping them with removable backs and rubber gaskets.

Which is funny to me, because even with an IP68 phone, I get worried if I even splash a little water on it.

The thing is - if the battery had been destroyed, that could have been replaced...

Literally zero people do what Spurlock did in that film.

I've seen two in my life vomit while walking without missing a step.

They build used car dealerships and strip clubs within walking distance of bases. Sailors blow thousands in an evening at the club, and then drive home in $75k vehicles purchased at predatory interest rates.

Despite significant, potentially life-changing enlistment and re-enlistment bonuses, housing stipends and more - many (or most) enlistees leave the service in debt or near penniless.

The reality is the US operates the world's largest social services apparatus, including the world's largest public healthcare system.

Sweet cherries have no such regulation, and are the ones you consume directly as a fruit - without any additional processing.

It's interesting to me how people are quick to comment about things they know nothing about...

> It's still food, full of flavor and calories

Tart cherries have about 1-2 calories per cherry, and do not taste good without a lot of sugar. That's why they are used in commercial processing, not generally sold as a fruit in grocery stores.

Fruit isn't super dense in calories to begin with because it has so much water, but it's still a meaningful amount, and tart cherries are pretty standard among fruit.

Maybe just quit being needlessly pedantic? Every point you've attempted to raise in this thread has been entirely pointless and equally ridiculous.

This applies to almost all fruit though. But saying people in need don't need any fruit would be a terrible stance. What gives?

People in need don't need single/one calorie tart cherries that are rarely eaten on their own. Consuming tart cherries typically involves processing that is more costly in terms of ingredients and time than simply using the pre-processed versions. Tart cherries are sometimes donated and are rarely destroyed.

Which argument will you come up with next?

You've bounced all over the place in this thread. Just let it rest...

You gave calories as a reason people don't need this fruit.

But that logic would apply to almost fruit.

So I said it would be bad to say people in need don't need fruit, while pointing out that contrast. I'm not accusing you of thinking that, I'm accusing you of using flawed logic.

> People in need don't need single/one calorie tart cherries

There's plenty of calories in a reasonable serving, and again that argument would apply to almost any fruit. It's like complaining about a single blueberry having too few calories.

> are rarely eaten on their own. Consuming tart cherries typically involves processing that is more costly in terms of ingredients and time than simply using the pre-processed versions.

They can cook with them. Lots of things are rarely eaten on their own and need to be processed, costing more ingredients and time than the pre-processed form. This includes flour!

> Tart cherries are sometimes donated and are rarely destroyed.

This is true and has nothing to do with my point.

> Which argument will you come up with next?

If you bring up a new reason to imply that donating tart cherries is unreasonable (even though it does happen!), I might disagree with that reason. Otherwise I have had one single argument and it hasn't changed: Donating tart cherries is a good idea.

I don't know why you're so fixated on whether people eat something directly. That doesn't affect what all2 was saying or what voxl was saying or what anyone else has been saying, but you keep acting like it does.

Yeah yeah yeah I saw that in your other comment.

That's a completely different argument.

The argument you made in this comment is still a bad one.

It's interesting to me how people are quick to move the goalposts...

What was even the point of your snarky comment then?

In the context of someone talking about home cooks using them, and you acting like "People do not eat tart cherries directly." is a counterargument, yes I felt compelled to correct that.

The incorrect thing you were implying had nothing to do with how often they're actually destroyed. So why would that stop me?

"People in need" are not going to spend time and money processing tart cherries into juice concentrate or pie filling... especially when a can of either is cheaper than the raw ingredients to make your own.

Your point is ridiculous, absurd and pedantic beyond any reasonable purpose.

I grow several varieties of sour cherries in my yard, and frequently use them whole and without further processing. Usually I use them in a recipe like this: https://en.wikipedia.org/wiki/Clafoutis. Sometimes I pit them first, sometimes I don't. Sometimes I'll even happily snack on them raw.

No, like most small fruit you aren't going eat them because you are desperate for calories. But they actually aren't any harder to prepare or use than lots of other tasty things that people traditionally grow.

Surplus tart cherry crops are rarely destroyed. In the event of a surplus, they are often exported, diverted to secondary markets, donated, or carried-over into next-season's stock.

One thing people often don't figure or realize is food takes time to grow. It requires long term thinking to make sure supplies are sufficient. Left to their own devices, farmers will often chase after last season's cash crop. That is bad. It's far better for farmers to stick to more predictable growing and for more dedicated incentives to be issued.

I saw first hand farmers tear up a barley fields to plant wheat when the price got high enough.

Farming is a game of speculation. Planting last year's cash crop can be a successful strategy just like buying APPL today will likely yield good returns. Yet, it's a very hard market to predict with a lot of luck involved. Maybe only a few chase the cash crop and you win big. Maybe everyone does and you lose. Maybe there's a natural or political disaster that pumps up your crop.

There was nothing insulting, condensing, or dismissive about my comment. Highly speculative markets, like food, have booms and busts that can swing wildly. That's bad for something like food. The free market does not work with crops.

I'd argue that this should be refined to something like "farmers that speculate heavily struggle in an under-regulated free market".

Financial stability in highly volatile markets depends on appropriate planning, saving, and distribution. I say this from the investment perspective, but I would venture to guess that it also applies to hard goods like food-stuffs.

The nature of farming is speculation. It's inescapable. In a completely free market there's no way to guarantee success. Even with the best planning and saving you can't know what the rest of the market is doing and because of the long tail, you are locked in to harvesting and selling your crop no matter what.

You can speculate and be the farmer that always plants and grows wheat. You'll see booms and busts based on that. You can also switch up what you are growing based on your best guess about demand. Both strategies can be successful.

Funnily, one way to make farming less risky is a futures contract. And, if you know anything about futures commodity trading you know they are some of the most risky forms of trading.