For "skeptic" read "contrarian". It's probably for the best that the author is spending less time online, given how the Glinner radicalization pipeline destroyed Glinner and various other people.

Two helpful references:

"Radicalisation pipeline:"

* https://en.wikipedia.org/wiki/Alt-right_pipeline

Who is "Glinner":

* https://en.wikipedia.org/wiki/Graham_Linehan

Rationalists and "skeptics" aren't really capable of maintaining a robust club because a) it's hard to find healthy critical thinking in societies that are still addled in a swamp of tribalism from millennia ago, and b) not believing in fables is a weak social pretext. (Hey, let's get together for pints and not believe in $somegroup's ravings.)

The application of rational thought is an educational process. With all the inherent fragility of any educational process.

Also: installing the charging infrastructure. Special docking requirements for the non electric Spirit Of Tasmania were a big problem.

Google supplied me with this original spec: https://incat.com.au/wp-content/uploads/2019/05/Mini-Spec-13...

Same ship, originally specced to carry tens of thousands of liters of oil. No overall displacement number, oddly.

Iran has an active nuclear weapons program which the Israelis keep sabotaging.

Investing a trillion dollars for a revenue of a billion dollars doesn't sound great yet.

Indeed, its the old Uber playbook at nearly two extra orders of magnitude.

It is a large enough number to simply run out of private capital to consume before it turns cash flow positive.

Lots of things sell well if sold at such a loss. I’d take a new Ferrari for $2500 if it was on offer.

Did Uber actually do a lot of capital investment? They don't own the cars, for example.

Uber nakedly broke the law and beat down labor, I'm honestly shocked none of the executives went to prison.

I believe they spent a huge amount of money on incentives to help sign up drivers, and discounts to help attract customers.

Yes, but that's loss leader rather than capital investment. You can't put a customer on the balance sheet and depreciate them. Once you've paid for a free ride, you own nothing tangible.

You say that as if Uber's playbook didn't work. Try this: https://www.google.com/finance/quote/UBER:NYSE

This is spoken like you've never done any reps at all?

There's not much difference in hitting max at 12 and at 25, from anecdotal experience. The study corroborated that as well, even though with small n.

What do you mean by there’s no difference? The difference is in the relative load needed in each example.

Well of course you change the load, but the stimulus is interpreted the same way by the body. I didn't think the question was at that level.

> but the stimulus is interpreted the same way by the body

That may be your intuition, but it’s certainly not everyone’s, hence the studies… Many people will intuit heavier weight = more effective.

It's not my intuition, it's just knowledge about processes in nature.

Almost nothing reacts to changes smaller than an order of magnitude to anything. It's one of the best rules of thumb.

Except that this is something that was well established before, making this study pointless.

Wildly different situation: the DnD thing was simply a tabloid and evangelical moral panic. Not a real thing. Nobody sensible expects those two sources to have anything to do with truth. As far as I'm aware there aren't similar stories from tabletop RPGs at all, that made it to court?

This is an actual court case where if a human had sent the messages they would be facing charges.

There's a reason that ORA have huge credibility in technical publishing, and have for decades: a reliably good product.

That was definitely my experience.

What's specifically bad about Mockito here? Poor defaults for mocks?

You've just built a calculator, and now you want to test it. Well, you have to push buttons on a calculator, so you build a robotic hand. And that hand needs a power source and some intelligence. And you need to photograph and OCR the result from the calculator screen.

This is kinda how we build software right? A little bit of "our logic" (calculation), represented as objects/actors/modules which "do things", but intermingled with million-LoC dependencies like databases and web servers.

After a while it gets frustrating setting up the robot hand and OCR equipment for each test case. Maybe it's just easier to test manually, or skip testing entirely.

At this point you can have an epiphany, and realise you only care about the numbers going in and out of the calculator, not the button pushes and pixels.

Mockito swoops in and prevents you from having that epiphany, by making it easier to keep doing things the stupid way.

Instead isolating the calculation from any IO, you can now write things like: when(finger.pushbutton(1)).then(calculator.setState(1)) when(calculator.setAnswer(3)).then(camera.setOcr(3))

(I've mostly worked in Java, but it seems like other languages typically don't let you intercept calls and responses this way)

I’ll answer: Nothing specific to Mockito, it happens in every language. Tests “solidify” code which makes refactoring hard. And yet, after refactoring, one can be happy to have tests to check whether there is any regression.

Testing is hard. I’ve tried with AI today: No, it is still not capable of handling that kind of (straightforward) task (Using Claude).

They also encourage/enable code that is less testable. If you use mockito to get your fake responses/assertions where you need them, you don't have to think about your class's dependencies to make your code testable and therefore better decomposed. I don't even do TDD, but I still find that thinking about how I'd test a class guides me toward better-factored code.

One alternative to make code with typing styles in the Java way (as opposed to the Typescript or Go way) is to have a whole lot of custom interfaces and then you end up with a whole bunch of:

  doTheThing(foo: Fooable) { ... }

when there's really only one Foo implementation in prod. It leads to (what feels like, to me) more code obfuscation in large projects, than the benefits that come out, at least for me.

So Mockito and friends are a nice alternative to that.

That is just my experience and opinion though, and there are definitely more valid or equally valid alternatives.

I don't think we have to choose. Naturally finding the "right division of labor" is as infinite as finding the "right level of abstraction", but I think the ideal situation is to strive toward code that is easy to test without having to introduce a lot of mocks or without infinite layers of abstraction.

IMO Mockito is fine, the problem I’ve encountered is people taking the easy way out and trying to test something that needs a real integration test with a convoluted series of mocks.

I've found that most of the time that if you need to mock, you probably just need to do an integration test.

I agree. I mostly only use mocks for external service dependencies (apart from primary application database), or library features that are very problematic to use in test. A lot of code simply should not be unit tested - if an integration test can cover the same paths its far better in the long run. Performance can become an issue but it is easier to deal with that than to spend so much time maintaining and debugging mock constructs.

I can’t concur with this enough.

I’ve been on projects where mocking _literally made the project less reliable_ because people ended up “testing” against mocks that didn’t accurately reflect the behavior of the real APIs.

It left us with functionality that wasn’t actually tested and resulted in real bugs and regressions that shipped.

Mocking is one of these weird programmer pop-culture memetic viruses that spread in the early 2000s and achieved complete victory in the 2010s, like Agile and OOP, and now there are entire generations of devs who it’s not that they’re making a bad or a poorly argued choice, it’s that they literally don’t even know there are other ways of thinking about these problems because these ideas have sucked all the oxygen out of the room.

> like Agile and OOP

Ha.

I think there's room to argue "Agile" is a popular bastardisation of what's meant by "agile software development", and with "OOP" we got the lame Java interpretation rather than the sophisticated Smalltalk interpretation. -- Or I might think that these ideas aren't that good if their poor imitations win out over the "proper" ideas.

With mocking.. I'm willing to be curious that there's some good/effective way of doing it. But the idea of "you're just testing that the compiler works" comes to mind.

For OOP, I'd say the issue isn't so much that it's not useful (it is very useful), but rather that it was treated as "common sense, the only way to do it".

Sometimes the right tool for the job is objects, sometimes it's functional, sometimes you do want encapsulation but it's better as structs and using composition over inheritance. When everything looks like a `class Hammer extends Tool`…

Agreed - I like your phrasing of it. There are some good ideas in OOP. I don't know that I'd go as far as to credit OOP for those ideas, but things like polymorphism and encapsulation can be very useful. What I objected to was, as you said, OOP became "the only way to do it". It became a dogma. I was very happy when functional programming started to break through and show that there were other ways that were not only viable, but often better.

Had my fill of both until I could not stand it anymore. So tired of the grifters--agile was sometimes good, but mostly a grift.

Mocking and integration tests are not mutually exclusive. I often use mocks in my integration tests. Some things can be integration tested, some things can't. Sone things you just need to mock.

People using it wrong. It definitely should not be that popular. 95% of times when I see it I consider it a tech debt.

You should be using it in rare cases when you want to verify very complex code that needs to be working with strict requirements (like calling order is specified, or some calls cannot be made during execution of the method).

Usually it is used for pointless unit tests of simple intermediary layers to test if call is delegated correctly to deeper layer. Those tests usually have negative value (they test very little but make any modification much harder).

It allows you to mock the whole universe so it becomes a hammer instead of nicely designed functions, interfaces.

This has the air of a parody spy caper where the various people who have broken in keep tripping over each other.

The source leak is really interesting, though. We don't often get to see game source, and it often has surprises in.

> Will the SECOND GROUP leak the source code? Is the SECOND GROUP telling the truth? Did the SECOND GROUP lie and have access to Ubisoft code this whole time? Was it MongoBleed? Will the FIRST GROUP get pinned for this? Who is this mysterious THIRD GROUP? Is this group related to any of the other groups?

This read to me like the end of a soap opera. Tune in tomorrow to find out!