B-Con

I think one of the key differences is that math is abstract whereas CS is relatively concrete.

CS examples are often easy to picture and understand the motivation for. You can use tools to visualize or play around with them and test them.

Math gets abstract so fast you have to spend a week of research to even understand the problem statement. The the motivations themselves can be completely unclear until you have a lot of context.

I majored in math (B.S.) and upper level math is completely foreign to me.

A human reader for a popular product is generally a paid actor who reads the script nearly verbatim, not a domain expert, so it has no bearing on the technical quality of the script.

I can see them as a shared fate for a couple reasons:

* the obvious one is Elon - both valuations are largely propped up on belief in Elon. Whenever he falters, his companies that are speculation-based (all of them) will take a hit

* Elon pitched SpaceX as an AI company. Tesla needs better AI because they keep sending signals that they won't be at L5 anytime soon, and Tesla's valuation is still very speculative[0]at least in part due to the race to L5 autonomy. i.e. Tesla will need better AI , and SpaceX is that natural fit (on paper, at least, I'm not sure SpaceX has any useful AI for any use case, let alone self-driving).

[0] Tesla's PE ratio of is still 30x massively out of line with it's actual earnings and ~30x the American automotive industry.

Same.

And since I won with an age, company, and title that is literally me right now... Well, I'm not exactly sure what to do with it information but some internalization is in order.

I'm simply impressed they're releasing at all. This has to be literally the worst 6 month time window in the last 20+ years to launch a new computing device at scale and have to build the vendor contracts and inventory from zero.

Yeah, I imagine Linux support would be more like a supported Linux distro rather than generic Linux support. Something like SteamOS but with kernel anti-cheat and secure boot from the start.

Big question is whether they can make craching the anti-cheat it hard/unpredictable enough that the publishers will trust it. If the publishers release such a platform and someone releases a live distro that can crack it with 3 mouse clicks, that's a lot of wasted effort.

I have no idea how effective the Windows anti-cheat is, but I imagine that Linux tooling in general is going to make it harder to lock a user out of controlling their own machine.

Even though I balked at the Steam Deck prices on the recent inventory restock, as they were up ~30% presumably due to the same hardware shortages, I got one anyway. Prices won't drop anytime soon and if any for-profit organization has earned my loyalty, its Valve.

When I used it I was somewhat incredulous that I could simply exit Steam mode have an actual Linux desktop environment, where I could literally do what I wanted. It was my computer, a proper general purpose computing machine, and it was (willingly* in my control. No sneaky root needed.

People want to do X, so the metric is how much X can be done.

Everyone is over-complicating the explanation. The answer for "why are we fixating on this bad metric" is almost always the same pattern.

Broad audiences need simple metrics to talk about. If the metric itself requires nuance, it's hard to communicate and hard to reason about. It's easier to push the need for nuance from understanding the metric itself down the road to where the metric is applied, which allows everyone to ignore it in immediate conversation.

They added $80 out of a $4.5T market cap, which means redistributing ~1.67% of value from shares outstanding to the new shares.

So being down 1.7% is literally exactly what you'd expect.

I'm with you.

Australia calls December "summer". If climate patterns changed and shifted our weather patterns by a month, we'd shift our season vernacular to match.

Seasons refer to the climate we experience. They're a human experience, not calendar slot.

I've had to spend week and a half battling Gmail daily email account limits sending batches of 500 emails just to notify people in her address book, receiving hundreds of responses. Her memorial was attended by hundreds of people.

I love this story, because I had the same experience. When my dad passed, I had the same 500 email limitation, and had to send out multiple waves of emails through Gmail. He was loved by so many people!

Yawing seems like it must be adventurous, the contagious part not so much.

Even the mention of a yawn can trigger it.

Perhaps we are almost always in a state of needing a yawn, but the trigger is seldom met, and seeing or hearing about it is enough to make our brain go "oh yeah I forgot about that".

Perhaps yawning is actually underdeveloped and an ideal human would yawn at regular intervals without any prompting.

I know this guy from his videos over the years on hiking topics, like how to safely purify water with the minimum fuel and how to pack calorie efficient food.

His videos are incredibly well researched, very in-depth, and absolutely zero fluff. Very much feels like his cycle is to get intrigued by a topic, spend a year deep diving into everything that's published, extrapolate what he can from there, then summarize it in a 1 hr video.

Any time an app has bizarre functionality gap on iOS, I assume it's because of Apple's anti-consumer bullshit app restrictions.

No idea if that's actually what's going on, but Apple thinks of their devices as appliances and hates when apps offer pro-customer features.

I used to have that strip on a t-shirt as a teen.

So if the top 10% is $2m net worth, then what's the 1%? Are we supposed to mentally extrapolate?

I hate when only part of the criteria are provided. Arrives like this need a table. If they don't have it, it calls into question whether they should be writing the article.

This is exactly what I've said for a decade.

When people talk about the 1% they almost always mean the 0.1%>

Preserving more than one lineage and providing a cohesive family name isn't practically easy, and society did not go that direction, and that likely isn't a coincidence.

Discarding names doesn't preserve lineage. If you need a book to trace the names, then the point of using a name for lineage has failed.

The traditional approach is for women to keep their maternal name and discard their paternal name on marriage while men do the opposite

It sounds like this scheme is "men keep one name lineage, women keep another".

Which, IMO, has the practical drawback of not identifying the current family unit. Lineage was important, but so was gathering all folks together into a household. When taxes, religious ceremony, etc. occurred, there was one household name on the roster responsible. This was particularly important in societies where men held certain rights for the household.

What societies?

Keyword being "practically". Just because there is an alternative doesn't mean society will adjust.

And hyphenation isn't a solution, it only works for one generation.

It hails from when family lines were important, and you can practically only have one line reflected in a name. Unsurprisingly, most societies considered the male's name to be the dominate lineage of interest, although that doesn't hold true 100% of the time.

For me, I despise having different abstractions get crossed.

I expect my media app, ie. YouTube, to know what I watch from the media app. YouTube knows about YouTube.

My operating system, ie. Roku, should not know about what's happening inside a given app. ie. Roku does not know about YouTube.

When they start crossing layers, that greatly upsets me.

I have a theory: They realized the right approach is to focus purely on the yes/no of what you choose to consume, rather than trying to optimize the consumption experience itself.

Remember how YouTube and Netflix used to let you rate things on 1-5 stars? That disappeared in favor of a simple up/down vote.

Most services are driven by two metrics: consumption time and paid subscriptions. How much you enjoy consuming something does not directly impact those metrics. The providers realized the real goal is to find the minimum possibly thing you will consume and then serve you everything above that line.

Trying to find the closest match possible was actually the wrong goal, it pushed you to rank things and set standards for yourself. The best thing for them was for you to focus on simple binary decisions rather than curating the best experience.

They are better off having you begrudgingly consume 3 things rather than excited consuming 2.

The algorithmic suggestion model is to find the cutoff line of what you're willing to consume and then surface everything above that line ranked on how likely you are to actually push the consume button, rather than on how much you'll enjoy it. The majority of which (due to the nature of a bell curve) is barely above that line.

See last week's thread on why more parents homeschool.

I just rebuilt my PC and setup Steam on Linux. It was fairly smooth.

I've dual-booted Arch and Windows for about 16 years. I always kept Windows around for gaming, and the occasional "doesn't support Linux" workflow.

For a few years where I didn't game I found myself almost exclusively in Linux. But then I spent the last 5-6 years stuck between the two as my PC use for daily tasks dwindled, I stopped working on side projects, and I started gaming a bit more.

I hated trying to split my time between them. Most of what I used a PC for was the browser, so I could just stay in Windows most of the time. I wanted to use Linux, but rebooting to use a web browser just didn't make sense. As a result I would accidentally go 2-3 months without ever booting Arch. As a result, I had a couple of major updates that didn't go smoothly.

I wanted to use Linux, though. I like having a customized WM, I like having so many useful tools at my disposal, etc. I just like using Linux, in spite of the occasional technical complexity.

In the last couple months I rebuilt my PC and a major requirement was that I get set up to game in Linux as much as possible. I even bought an AMD card to ensure smooth driver support.

I'm so incredibly thankful that Steam has made gaming not just possible, but relatively simple. Installation was simple. My single-player games seem well supported so far. And most importantly, Steam has made it obvious they're committed to this line of support, so this isn't some hero effort that will bit rot in a couple years.

I still have to reboot to play competitive games, due to their anti-cheat requirements, but that's less of a problem, I'll take what I can get.

3. Allows you to assert expectations on it.

I think this is the crux that separates Fowler's mock, spy, and stub: Who places what expectations.

Fowler's mock is about testing behavioral interaction with the test double. In Fowler's example, the mock is given the expectations about what APIs will be used (warehouseMock.expects()) then those expectations are later asserted (warehouseMock.Verify()).

Behavioral interaction encodes some of the implementation detail. It asserts that certain calls must be made, possibly with certain parameters, and possibly in a certain order. The danger is that it is somewhat implementation specific. A refactoring that keeps the input/output stable but achieves the goal through different means must still update the tests, which is generally a red flag.

This is what my original statement referred to, the interaction verification. Generally the expectations are encoded in the mock itself for ergonomics sake, but it's technically possible to do the interaction testing without putting it in the mock. Regardless of exactly where the assertion logic goes, if the test double is testing its interactions then it is a Fowler mock.

(As an example: An anti-pattern I've seen in Python mocks is asserting that every mocked object function call happens. The tests end up being basically a simplified version of the original code and logic flaws in the code can be copied over to the tests because they're basically written as a pseudo stack trace of the test case.)

In contrast, a stub is not asserting any interaction behavior. In fact it asserts nothing and lets the test logic itself assert expectations by calling the API. ie:

3. Allows you to make assertions on that change in state. (e.g. fetch record and assert it has changed)

How is that change asserted?

A Fowler stub would be:

myService = service.New(testDB.New()) myService.write("myKey", 42) assert(myService.read("myKey") == 42)

A Fowler mock would be:

testDB = testDB.New() testDB.Expect(write, "myKey", 42) myService = service.New(testDB) myService.write("myKey", 42) testDB.Verify()

These concepts seem distinct enough to make mock a simple.

Fowler's spy seems to sit half-way between mock and stub: It doesn't assert detailed interaction expectations, but it does check some of the internals. A spy is open-ended, you can write any sort of validation logic, whereas a mock is specifically about how it is used.

I have used spys in Go basically whenever I need to verify side effect behavior that is not attainable via the main API.

By Fowler's definition, nocks are a niche test double and I suspect that what many folks would call a mock are not technically a mock.

Yes, this is absolutely dependent on the design S3 client.

The reality of development is we have to merge different design philosophies into one code base. Things can get messy. 100% agreed.

The approach I advocate for is more for a) organizing the code you do own, and b) designing in a way that you play nice with others who may import your code.

There are different definitions of the term "mock". You described the generic usage where "mock" is a catch-all for "not the real thing", but there are several terms in this space to refer to more precise concepts.

What I've seen:

* "test double" - a catch-all term for "not the real thing". What you called a "mock". But this phrasing is more general so the term "mock" can be used elsewhere.

* "fake" - a simplified implementation, complex enough to mimic real behavior. It probably uses a lot of the real thing under the hood, but with unnecessary testing-related features removed. ie: a real database that only runs in memory.

* "stub" - a very thin shim that only provides look-up style responses. Basically a map of which inputs produce which outputs.

* "mock" - an object that has expectations about how it is to be used. It encodes some test logic itself.

The Go ecosystem seems to prefer avoiding test objects that encode expectations about how they are used and the community uses the term "mock" specifically to refer to that. This is why you hear "don't use mocks in Go". It refers to a specific type of test double.

By these definitions, OP was referring to a "fake". And I agree with OP that there is much benefit to providing canonical test fakes, so long as you don't lock users into only using your test fake because it will fall short of someone's needs at some point.

Unfortunately there's no authoritative source for these terms (that I'm aware of), so there's always arguing about what exactly words mean.

Martin Fowler's definitions are closely aligned with the Go community I'm familiar with: https://martinfowler.com/articles/mocksArentStubs.html

Wikipedia has chosen to cite him as well: https://en.wikipedia.org/wiki/Test_double#General .

My best guess is that software development co-opted the term "mock" from the vocabulary of other fields, and the folks who were into formalities used the term for a more specific definition, but the software dev discipline doesn't follow much formal vocabulary and a healthy portion of devs intuitively use the term "mock" generically. (I myself was in the field for years before I encountered any formal vocabulary on the topic.)

I generally advise to avoid introducing interfaces strictly for testing. Instead, design the data types themselves to be testable and only use interfaces when you expect to need differing implementations. ie, avoid premature abstraction and you get rid of a whole class of problems.

For example, if you only use S3, it is premature abstraction to accept an interface for something that may not be S3. Just accept the S3 client itself as input.

Then the S3 client can be designed to be testable by itself by having the lowest-level dependencies (ie, network calls) stubbed out. For example, it can take a fake implementation that has hard-coded S3 URLs mapped to blobs. Everything that tests code with S3 simply has to pre-populate a list of URLs and blobs they need for the test, which itself can be centralized or distributed as necessary depending on the way the code is organized.

Generally, I/O is great level to use an interface and to stub out. Network, disk, etc. Then if you have good dependency injection practicies, it becomes fairly easy to use real structs in testing and to avoid interfaces purely for testing.

Related reading from the Google style guide, but focused specifically on the transport layer: https://google.github.io/styleguide/go/best-practices.html#u...

If you add a method to an interface, you break every source file that uses a concrete type in place of the interface (ie, passes a struct to a function that takes an interface) unless you also update all the concrete types to implement the new method (or you update them embed the interface, which is yucky).

For a public interface, you have to track down all the clients, which may be infeasible, especially in an open ecosystem.

This is the kind of minor celebrity Internet encounter that delights my day but is impossible to explain to anyone else. :-D