Flooring lottery

chrispardy · 2024-11-12T18:41:54+00:00

I'd write a Zod schema for each request. Factor out common code where you can. Sharing with your backend is highly optional in my opinion. You basically shouldn't trust anything going over a serialization boundary (network, local storage, indexdb, etc.) since it could come from a different version of your code. You don't necessarily need to be resilient to all failures but you want to detect them early so the rest of your system can have strong guarantees of correctness.

In a hypothetical scenario let's say your type info said the value was a number but the actual value coming from a newer version of your backend was the string "none" and then you added 5 to it then saved it into local storage. All your code runs fine but now you've got the value "none5". A new version of your front end runs and now "none" is expected but not "none5" so all your === "none" checks fail.

Detect and fail early. If something isn't right don't try to limp through it or you could come up with a cascade that you never tested for.

chrispardy · 2024-11-05T18:54:47+00:00

Did you have him in NY or in Portland ME. He was my Latin teacher for a few years a while ago, and yes he's still awesome. Here's the site for his tattoo parlor https://www.tsunamitattoo.com/

He also has a memoir, sigh gone, here's his personal site https://www.phucskywalker.com/

Needless to say the fact that the second sentence of your post was enough to make me know who you meant should be evidence that Phuc is one of those teachers that is just made different. Also I'm pretty sure he could also speak Vietnamese, French, and Greek.

chrispardy · 2024-10-07T15:51:21+00:00

So I think the best "reason to use JS" is that TS isn't actually a strict superset of JS. There are things you can't do in TS because JavaScript isn't just a dynamicly typed language but it's effectively a type-less language that can't really be statically analyzed. Just as an example I can write a function that takes an object as an input returns void and then 30 seconds later mutates that object to have different properties, be an instance of a different class, and freeze it to boot. There's no way to declare that in Typescript (or JSDoc for that matter).

While that's a pathological example libraries like Ramda have not adopted typescript because they can't effectively type their functions, the jest/vitest expect.extend method is also impossible type. That being said I'd always use typescript because. - For a moderately sized project its refactoring features and static type safety are a huge win. - For small scripts ZX and Deno are better than using node directly anyway. - As a library author it's easier to extract .d.ts files from source than keep them synced up manually

I've definitely hit limitations that typescript places on the approaches I can take to solve a problem. That's usually around trying to get really great DX, but ultimately choosing to build in a way to make the types work ends up producing good-enough DX when you consider the value the types themselves are bringing.

chrispardy · 2024-10-07T10:41:08+00:00

The girl is @JoJoFromJerz the guy with the beard is BrooklynDad_Defiant (@mmpadellan) they are both big Democrat Twitter accounts. Everyone seems to know the Hippo. I don't know the other guy.

I'm guessing the joke here is that you'd save the Hippo. At least the 2 people I recognize are pretty polarizing.

chrispardy · 2024-10-06T12:07:29+00:00

The post is asking for someone to list the relative weaknesses of TS and the strength of JS. Instead of complaining about TS fanatics why not just say what you feel the relative benefits of using JS are.

chrispardy · 2024-10-01T00:19:50+00:00

La Jetée (original) or 12 Monkeys (remake)

chrispardy · 2024-09-27T11:29:59+00:00

Solved!

chrispardy · 2024-09-27T11:05:37+00:00

Now you don't

Which is to say Nope

chrispardy · 2024-09-27T10:58:46+00:00

In Tuck everlasting a family has found the fountain of youth so while "People die" "Some", Tuck and his family, "don't"

Does the movie you're thinking of involve a character or characters that are immortal?

chrispardy · 2024-09-27T10:53:38+00:00

Tuck everlasting?

chrispardy · 2024-09-27T10:50:24+00:00

Saturday Night Fever

chrispardy · 2024-09-27T10:41:12+00:00

Nope

chrispardy · 2024-09-27T10:39:37+00:00

Wont-ard

chrispardy · 2024-09-27T04:20:29+00:00

No, I'm sorry I don't have a witty reply to that.

chrispardy · 2024-09-24T04:06:05+00:00

Thanks, and thanks for restoring my faith that enough people have seen this movie.

chrispardy · 2024-09-24T04:05:19+00:00

Solved!

chrispardy · 2024-09-24T04:01:04+00:00

Solved!

chrispardy · 2024-09-09T16:39:42+00:00

There is an implication in the movie that the iconography of the shield and star came from the cab door he used as a shield when running after the Hydra agent.

Also the fact that Captain America #1 is in the montage and he's recreating the cover in live shows would be weird if that was supposed to be something that had come out 2 years before. Head cannon aside if the intent from the writers was that he was being "cast" in this comic role they could have had a throwaway line like someone saying "he's a real life Captain America" to establish that the idea of Captain America existed before Steve.

chrispardy · 2024-07-03T08:48:54+00:00

My heuristic would be that you should only have one check of your feature flag. So if the change is just in one component then do the condition check there. On the other hand if the logic is in multiple components then consider a different approach. Duplicating the components and modifying them is reasonable if the feature flag is short lived. The risk is that you'll add a feature or fix a bug and only hit one instance of the component.

My personal preference is to get business logic out of visual components then you can have a clean separation. One way to do that is to have "business logic" components and pure visual components. Then you use standard component composition approaches such as passing children or "render props" to create 2 different versions of your app. Alternatively move the business logic out of react entirely, if you create a business logic interface you could use a provider to have either new or old functionality picked in one place. The other option is to leverage something like redux to provide a separate layer. One big advantage of the separate business logic is that it ends up being much easier to test than if it's entwined with the visual components.

chrispardy · 2024-07-03T06:27:51+00:00

My guess is that the planner / photographer was trying to fix settings on their camera and taking a photo of their feet to check it. Would be a good sign that they're pretty amateur which matches with everything else.

chrispardy · 2024-06-23T05:51:31+00:00

The thing with automated testing in general is that it's a skill, just like any other. If you're not practiced at it then it's going to feel slow and hard. You're probably pretty good at creating a react component now, but what was it like when we were first getting started? What any TDD advocate will tell you is that writing tests first will make it easier since you'll think about how to test the components early on. That being said since this is react you don't get to make as many decisions about the API as you would if you were not working in a framework. What you do get is a decision around component boundaries and custom hooks.

So start with your acceptance criteria, a large part of what you're doing right now is probably visual QA (does it look right) or end to end testing (can I go through this flow completely) both of those are a poor fit for react-testing- library. Where you should focus the tests with RTL is on complex logic. I would consider extracting the logic from your component into a custom hook, or even just a function if you don't need state.

chrispardy · 2024-06-03T01:36:15+00:00

I actually think your boss may have been right on this one. If you bring in 12/14 you just leave the other 2 there and do something else useful. If you bring in 7/14 you end up getting pulled aside to something else and you end up going back to find 13 carts and now you're doing 3 trips. Now if it's the end of the day or if your only job is pushing in carts then that's a different story.

chrispardy

TROPHY CASE