RHSeeger

> Passing state between test dependencies

Actually, I wasn't even thinking about passing state. I was thinking about shared setup steps. I'm perfectly happy for the same steps to run for each test - as long as each test doesn't need to list the steps (when they're setup steps not directly related to the thing being tested)

The question was less about speed and more about not having the same code duplicated over and over across tests. Which is how I read the article talking about it. Allowing one test to "depend" on another makes it clear they use the same setup (presumably with the second test going "a bit further", but not necessarily).

I wouldn't have a problem with something like

    test-1:
        setup:
            do-the-thing
        verification
            assert-the-thing-happened
    test-2
        setup:
            depends-on: test-1 // tells it to run test-1's setup
            do-the-next-thing
        verification
            assert-the-next-thing-happened

The format is awful, but the idea is that most tests are of the form

    GIVEN
       Some initial setup
    WHEN
       I run command
    THEN
       The result of that command is what is expected

And, in that context, the GIVEN frequently contains noise not directly related to understanding what is being tested.

I actually use the GIVEN/WHEN/THEN keywords in my tests, to make them easier to read

I wonder if it would work do design something that was able to say

    test 1: 
       do step 1, assert step 1

    test 2:
       requires: test 1
       do step 2, assert step 2

    test 3:
       requires: test 2
       do step 3, assert step 3

    test 4:
       requires: test 2
       do step 3, assert step 3

If the assertion of each test doesn't change any state, that might make things easier to read. Though, given that I haven't spent much time pondering it, I expect it could have it's own problems.

But it could also do things like skip test 3 if tests 2 or 1 failed - because it knows about the relationship.

I agree, both with your analysis of him and your review of "Tidy first?". We read and discussed it at work, and I enjoyed it a lot.

> In addition, families working the fields used to spend less time working than modern adults do, not more[1]

And they'd spend a lot more time doing all the things we don't need to do anymore. The money I get from work buys a lot of convenient _not_ needing to do a lot of menial labor.

The YAML spec/parse _itself_ does interpolation and logic - incorrectly in some cases. YAML is pretty much never the right solution.

The point at which we decide it's dangerous to the safety, freedom, and happiness of citizens. Every law we have is a balance between "provides good" and "imposes bad" - and we have to adjust where that balance lies on an ongoing basis as things (technology) change.

But don't they just "call" from a different number? Or a random number each time? There's no real verification on the number being called from - its specified _by_ the caller a lot of the time.

So unless the phone company starts banning phone companies that don't enforce correct caller id, it won't do anything.

> Results that arrive after the deadline do not exist

Effectively, make as much money as you can... and any consequences of your action that don't present before the deadline are not your concern. I mean, that's a recipe for "scam people" if I ever saw one, assuming morals aren't a concern (and I don't see why they would be for an AI)

And how is it better than a password + password manager? Literally everything about what is described is worse than a password + manager.

It is relatively easy to pick a password length/composition that's pretty much impossible to guess, too. So the benefit you're list is for the company (that has to deal with people picking bad passwords), not the person using their site.

Heck, the company could easily say that your password needs to be 128 characters long and use multiple types of characters - and tell you to use a password manager (that both generates and fills in that information for yet).

But most password programs do this too, if you install the plugin (which you pretty much need if you want those same programs to do the passkey thing, anyways)

> Once you’re in Apple universe

And there's your blocker. Being limited to only devices from a single vendor is horrible, and a firm no from a lot of people.

> Now we can put on the tinfoil hat and say how this fosters vendor lock

The fact that you call it a tinfoil hat type issue is just insane to me. Literally every person in my household has some apple devices and some other ones (android, windows, etc). And some of them have switched back and forth.

Plus, the "ergonomics" of logging into a website on a random device to check something are awful.

Everything you said is _also_ true if you use a password manager than can interact with the browser (which you're already doing).

Plus, that doesn't have the negatives/limitations of passkeys.

If you store the key in Bitwarden or Keepass, what makes it different from a password?

Is that online activation Steam or is it a third party thing? Steam allows selling games that have external DRM like that. I think they, themselves, don't do it.

That doesn't invalidate your other point.

Can't you download your game off steam and play it forever; and if it can't connect to the service, it will just let you play offline?

Sure, that loses out on the ability to transfer it to a friend, but it's better.

> I have no problem with Sony not offering DRM free versions of games that I can still download and play with the store. But if that goes away -> you must give me a path to local ownership.

I worry about shenanigans where you "buy" the game from a shell company and that shell company "folds" and doesn't uphold it's promises. Same is true for a smaller, but not shell, company. If the non-DRM version isn't already created and held in trust, then it's not trustworthy.

Depends on the context, but both.

Literally everything you said is not true for me

- My phone's screen is nowhere near big enough for me to "glance" at it while driving (to see if my turn is coming up, etc)

- I'm not carrying around a tablet with me - my phone fits in my pocket

- Mounting is _not_ a solved problem. It just... isn't. This is a whole topic on it's own, but mounting a phone in a good position, where it will stay without moving/falling/bugging (especially in 100+ degree heat) and not be in the way of _other_ car things is a pain

- I already have physical buttons (that interact with car play, where needed) for all those things in my car

- Interacting with the screen of my phone while driving is 100% not something I'm proficient with; nor would I want to be. It's not designed for interacting with it while not paying attention to it. CarPlay is

> If AI generated content cannot be copyrighted, it does not follow at all that they can't infringe copyright; there is no deductive step there that I can think of.

I assume the idea is that the fault/blame lies with the human(s) that caused the AI to generate something that violates copyright. Going back to previous comments, the typewriter that generated a document didn't infringe copyright - the person using it did.

The conversation was

> If you have an X that Y

> If you have an X, it won't Y

to which you added

> Your statement is privileged

The fact that it's privileged to have an X is irrelevant to the discussion. The discussion was about whether or not an X will Y. And it started with "If you have an X".

> I have my golden handcuffs too, probably most on HN do

I don't. And I expect I'm not in the minority here. If you're going to throw rocks, you might want to ponder your own privilege before you start tossing accusations.

And yet it directly speaks to the comment it was replying to. It makes the point that RSUs are generally multi-year; so if you're getting them with _any_ frequency, you never get to the point of "the last RSU vests".

> I do not think learning about evolution (and we should credit Wallace too!) had that effect. It created a hierarchy of the fittest, and guess who is at the top? Social Darwinism interpreted it as justifying elaborate hierarchies.

I don't think that's accurate at all. Before Darwin, the thought was "we are special, we were born special, we were CREATED special". Darwin made it clear we weren't created special... we were apes before we were humans. There's nothing _special_ about a human as compared to an ape, other than some time to change.

> Nobody has taken me up on this offer, because I think they know that they aren't going to have the extreme discipline to do the hard thing of understanding "someone" else's code and sign their name to it.

That seems lazy to me. "I'm not willing to see if I can do a better job by using this tool, because I don't want to bother analyzing it's work".

There main problem, at least in my experience, is that there's a direct conflict in it

- There are people that work better from home and get more done there

- There are people that work better in the office, with people around them

Regardless of which you pick, you're going to make one of those groups less productive.

I do agree that some people who want one thing but work better with the other. It's on the manager(s) to figure out which works before; for each individual and for the team.

And both of them are wrong, because they _should_ be trying to figure out what works best for the person; not what worked best for _them_ and forcing it on the person.

> I understand there are sites for whom this causes problems, but I think these are rare and could be optimized not to do unreasonable things.

There are. They're not. They can't (without significant effort)

I keep my new computer glasses at the computer, and the old ones downstairs for "other" uses. Then I keep my new driving glasses in the car, and the old ones downstairs for "other" uses (tv, etc). Basically, I keep the new ones where it matters and accept that my vision will be mediocre in other cases. And also, I'll see 2 of everything because I have double-vision (corrected with the glasses - but "older" ones don't work very well for it).

> battling with AI, trying to get it do what I wanted

I rubber duck with AI a lot, to go over my understand, my plan, etc. I get all the benefits of putting my thoughts to words, plus some feedback.

And sometimes, I let the AI write the code, too. It really depends on if I feel it understands the problem and solution well enough. And it's entirely possible that the answer is no, even if it helped me come up with the solution. But I always review the entire plan it puts forward and review the code it wrote. [1]

I don't "battle" with it, unless I'm experimenting with letting it do ALL The coding. And I've done that. And it sucks. It's downright painful. I don't do that for work.

[1] Unless it's a simple utility I'm doing for myself, like "write me a bookmarklet to find all the code in this page and open up a dialog with it formatted easy to read". Because, if it turns out it got that wrong, I can just change it later; it's for me anyways.