joshfee

I've been using NodeRED + zigbee2mqtt/zwavejs for my locally controlled home automation to great effect. I expose all my devices to Google Home as a convenient frontend, but all the actual devices are mine and locally controlled so I can replace Google at any point. I tried home assistant years ago, but aside from the wealth of plugins I didn't find its approach particularly convincing. I have on occasion used it simply as a bridge between node red and HA plugins before though which is nice for niche devices or integrations

I see both sides of this argument and am really not sure which side I land on. But I wonder if this fits into things like driving, where hey - done recklessly this is dangerous to yourself and others around you, so we require some level of targeted education (e.g. a license). Then if you choose to be reckless anyway its a bit easier to say "it was your own fault".

I bet you credit providers would even front the cost of such a course, since at the end of the day they're still likely to make that money back no matter what.

I think the part that I struggle with is the hard reality that we are largely _not_ teaching people these practical skills in our education system and then expecting them to not get screwed.

Isn't that true for any scenario previously unencountered, whether it is a digital simulation or a human? We can't optimize for the best possible outcome in reality (since we can't predict the future), but we can optimize for making the best decisions given our knowledge of the world (even if it is imperfect).

In other words it is a gradient from "my current prediction" to "best prediction given my imperfect knowledge" to "best prediction with perfect knowledge", and you can improve the outcome by shrinking the gap between 1&2 or shrinking the gap between 2&3 (or both)

It is great being able to generate a much larger universe of possibilities than what they can gather from real world data collection, but I'd be curious to learn how they check that the generated data is a superset of the possibility-space seen in the real world (e.g. confirm that their models closely match what is seen in the real world too)

It is actually one of the few cases where I don't actually really care about independent upgradability. In my experience I find that I pretty much always upgrade my CPU and my RAM in tandem. New CPU architectures sometimes force it (e.g. need DDR5 instead of DDR4), and as long as you don't severely undersize your initial RAM choice I find that I run out of CPU headroom before I run out of RAM headroom.

So if there's performance gains to be had by co-locating RAM with the CPU in a single package, it makes sense to me to do so

But you are also only a camera without LIDAR or RADAR, and you apparently navigated that situation successfully...

How you define "external stuff" matters though. As soon as your function is calling another function, your test can be argued to be an "integration test", as you're now implicitly also testing the logic of the other function.

Alternatively you mock _everything_ and then your "unit test" ends up just being a tautological test asserting that "the code I wrote executes in the way I wrote it". (Not to mention that every time you mock something you are also implicitly asserting what the expected behavior of that thing is).

The only truly reliable tests are E2E tests, but they are too expensive to cover all possible permutations as there are just too many.

This is the catch 22 with testing, and we're always forced to make pragmatic choices about where to draw our boundaries to maximize the value (i.e. actual bugs caught) of them.

The problem with enforcing "freedom of speech" on private parties is that it essentially the same as infringing the speech of that private party.

The only issue I have is when companies can play both sides and in one breath claim they're neutral for the purpose of section 230 protection, and then in the next breath take part in censorship because it's better for business.

Pick a lane, either lane, but you shouldn't get it both ways

Forget about reading articles even... the supreme court decision itself is not long, is written in understandable language, and breaks down point by point the things that they had to consider, why they had to consider them, and the outcome of that consideration.

The case law around editorial control is at odds with most platforms' section 230 protection, which makes the fact that TikTok argued that its algorithm _is_ speech pretty different from how most platforms have argued to date (in order to preserve their section 230 protections)

The whole premise of this article is non-performance reasons to love rust

Returning control to the caller only really needs to be explicit if you're doing it in an arbitrary spot in the middle of the function because if you're at the end there's nothing to do _other than_ return control. For instance in other languages you don't need to explicitly say "go to the next iteration" at the end of a for loop, and if you want to do it before the end of the loop body you can `continue`. If "flow control should always be explicit", then should we be writing `continue` at the end of our loop blocks?

I think the other part of it is that it is just part of a cohesive language design where everything is an expression, including things like if's, matches, etc that would be control flow statements in other languages.. It would be a little weird to say that functions are the only thing that have different semantics.