bichiliad

“Meth” is methamphetamine, not methylphenidate. Ritalin isn’t the same thing as Meth. Not sure about how Ritalin vs Adderall act different on dopamine.

I think a system that makes it this easy to shoot yourself in the foot is probably not a great system. Documentation is important, and I'm glad it's clear and obvious, but humans make mistakes. You'd hope that the mistakes have less dire consequences.

Fuck that, I'm sorry to hear it.

out of curiosity, what was your prior car?

Bit of a shameless plug, but I wrote about how Etsy migrated to TypeScript a few years back. I agree with the author generally: TS strict mode is the way to go, and you may find yourself regretting the alternative, even if it sounds appealing. It takes a lot of work, but most of the effort ended up being:

1. writing types for the big, central libraries that everyone uses (and make them "smart enough" to infer as much as possible).

2. teaching everyone at the company a brand new language without them hating it, and without their team losing (much) velocity.

https://codeascraft.com/2021/11/08/etsys-journey-to-typescri...

I think that assumes a lot about what people do in the winter. I do most of my running in the winter because the summers are too hot to run, for instance.

This site gets better and better. Beyond even the mapping of genres, the write-ups for each genre are gold. Read the one for "Noise" if you're looking for somewhere fun to start.

The fact that this exists has rekindled my hope for new, mass-manufactured 35mm cameras. There are plenty of good used ones around, but repairs can be so expensive (if you can find someone willing to service your camera).

I'm reading "The Creative Act" by Rick Rubin. It's been such a wonderful perspective shift on what it means to be creative, and it includes a ton of lovely insights on the process of being creative itself. I can't recommend it enough.

https://www.penguinrandomhouse.com/books/717356/the-creative...

I'm working on an app called ScreenHint. It lets you take a screenshot of a bit of your screen, which then floats there above your other windows until you dismiss it. It's essentially a clone of the sadly-abandoned Snappy, if you're familiar with it. There are a lot of things I wish it could do still, but I'm worried that I'm missing some ease-of-use and polish items still. The app is free and is currently on the mac app store, but I haven't really done much to promote it yet.

https://www.screenhint.com/

You can find a ton of much worse examples than the US, but the US is just vastly far behind Europe (i.e. Spain, to which OP was comparing the US to).

Plus, it's worth mentioning that while Tokyo has a lot of mixed-traffic streets, the streets are small, have very low speed limits, and have strong restrictions on the size and type of car that can actually be within the city. It's less like you're walking in traffic and more like the car is intruding on a pedestrian space.

I live in NYC, and there are a whole lot of layers to this onion. I'm advocating for safety improvements on a local road that people get hurt and killed on pretty regularly[1]. The DOT has a well-designed change that they've been working on for over two years, complete with community outreach. The change has broad community support, and every single elected official in the area is behind it, from the city council to the state assembly.

However, there are a few wealthy people against the change who can file lawsuits, pressure the community board, and donate to the mayor's office. That seems to have been enough to get the mayor to overturn his own DOT's plan[2]. The change itself isn't even a large-scale capital redesign of the street; it's entirely a plan using temporary repainting, movable barriers, and signal changes. It's exhausting living here.

Edit: If you live in New York and want to voice your support for the aforementioned road redesign, you can do so at https://www.safemcguinness.com

[1]:https://www.thecity.nyc/2023/6/13/23759703/keep-mcguinness-m... [2]:https://nyc.streetsblog.org/2023/07/05/mayor-yields-to-oppos...

I'm treating them as one and the same here. My point is more that it's not endemic of public transit itself, but the way it's implemented (and supported and funded).

> Public transportation is also not an option due to how inconvenient it is due to how infrequently it would run, and the cost of missed or missing buses/trains, which again, run infrequently due to lack of density of people.

I think it depends on where you are, but useful public transit is very possible in most places. Low frequency is the result of poor planning, not a requirement of public transit.

I came here to say the exact same thing. My professor wasn't a bad professor per se, but I found Strang's lectures to be much more easy to understand.

I thought it was a riff on Block List by RXKNephew, to be honest.

I think the Tulip Mania, if that's what you're referring to, was a speculation bubble, whereas a recession is widespread by definition.

I had to run some long speaker cable around my living room, and this guide really made it so much easier to keep things neat. I'm glad to see it reposted again.

Very excited to see an Elektron post on here!

There's always a lot, but a few things really helped me this past year (all less than $200):

- I got one of those Stagg kettles[0]. I make a lot of pour-overs, and a nice kettle neck gave me a lot more control than I expected. Coffee tastes the same, but making it is more fun.

- Not Boring's "Habits" app is fantastic[1]. I've been trying to nail down a meditation practice, and this finally did the trick for me. It helps me stay on task without making me feel guilty for it. I've been meditating consistently every day for a few months now.

- I got a copy of "Salt Fat Acid Heat" and read the whole thing[2]. It's made me a lot more competent at cooking than I was, and now other cookbooks make more sense and are less daunting.

[0]:https://fellowproducts.com/products/stagg-ekg-electric-pour-... [1]:https://www.andy.works/product/habits [2]:https://www.saltfatacidheat.com/

Solar leases are the problematic ones (where you pay a percent of the energy you generated). It sounds like a good deal, but the rates increase yearly and the compounded cost doesn't end up being worth it. The author was cash-flow positive on a fixed-rate lease immediately and it doesn't come with a contract with a 3rd-party provider, although I guess that depends on how much sunlight you have.

If you're curious about learning more about PSR as it was intended to be implemented, I can't recommend Justin Roczniak's writing (and podcasting) around it. He wrote essentially the same article for the New York Times not too long ago[0], and his longer-form podcast discussion is even better if you have the time[1].

In his telling (and I'm paraphrasing heavily here), PSR — as it was originally designed — was meant to get everything on precise scheduling (surprise), thereby allowing you to better predict when and where you'd need workers well in advance. That would let you better optimize not just your trains but also your workforce. If you have a schedule, you can make optimizations that keep train cars from sitting around, and your workers reap the benefits of a fixed schedule (time off, less on-call time, things like that).

In practice, getting things to run on a schedule often meant capital costs that a of these companies balked at, like upgrades to rail yards and track maintenance to keep things running on schedule. The only real part of P.S.R. that ended up getting adopted, as this article points out, is the optimization part. But without the capital investments, you don't get a precise schedule, nor do you get any of its implied benefits.

Optimizations ended up meaning things like pulling more cars with fewer trains. I don't think the article mentions this in explicit terms, but these longer trains are often a few miles long. This length means the trains don't fit in rail yards, nor do they fit in the sidings that allow Amtrak trains to pass them (which in turn keeps Amtrak trains from running on time). Since trains don't fit in the yards, they have to leave as soon as possible, and since there's no fixed scheduling, "as soon as possible" ends up meaning any time at all with little notice, meaning engineers are on call almost all the time. Plus, when you have a train that's almost 3 miles long, they're more likely to derail on curves, and staff have to walk literal miles to fix problems along the train.

There's a whole lot more to this than I can repeat off-hand on a Friday afternoon, but this issue isn't going to go away. The rail industry is untenable, and given how scared everyone is of a rail strike, it also isn't going away any time soon.

[0]: https://www.nytimes.com/2022/10/09/opinion/business-economic... [1]:https://www.youtube.com/watch?v=69A_UCdikE8

To clarify a bit here, "unintended" meaning the amount of people, not that people left at all. They had to start incentivizing people to stay, they talked about attrition frequently, etc.

When there were layoffs at Etsy back in 2017, one of the unintended consequences were that a lot more people quit voluntarily afterwards. Attrition was a lot higher than expected. I have to believe that the people who remain are not all going to want to stay at the company that Twitter is becoming, whether it be for lack of institutional knowledge, peer support, or just because they liked their coworkers and are sad to see them go. This is a sample size of one, of course, but the layoffs at Etsy were a whole lot smaller than these ones were rumored to be.

This is a good question. I had a hard time drawing a line between perfect type contracts and dealing with JavaScript's idiosyncrasies. There is a lot of behavior in JS that is very hard to produce strong, reliable types for. If someone overwrites a prototype somewhere, your types are probably incorrect no matter what you do. Add in the fact that TS types can't really be accessed at runtime (mostly) and it makes type guarantees even harder to enforce with 100% accuracy.

It helps to think of TS types as a guarantee of behavior and an encoding of intention, and of TS itself as a really smart linter. As long as you use my function according to these types, it'll behave as expected. If it doesn't, that's my problem and I'll fix it. If I say my function returns a string, you can use my function's return types as a string with the confidence that that's how I expected it to be used. TS will make sure that everything agrees with my type assertion, which removes the need for checking the types of parameters in tests, for example.

> How is it not a problem for you that you make a change in a .ts file and then you are immediately in a world of uncertainty: Is the typecheck already complete? No clear progress on this.

You're right in saying that having a clean and understandable development environment has a lot of complicated moving parts! Dropping the ball on any one of them means having a bad developer experience.

Since I've said this on other comments, I'm not going to dwell on the fact that this behavior isn't something Webpack itself solves. However, if you make a change in a .ts file, two things typically happen in a dev server:

1. Your code is retranspiled and rebundled, usually using partial recompilation. 2. Your IDE sends these updates to the TS language server that powers your IDE's TypeScript support. That server uses the same typechecking logic as the TypeScript compiler, so it's a good source of truth for surfacing type errors in the files open in your IDE.

Depending on your dev environment, one of a few things might happen next: 1. Your dev server might hot reload the changes in your browser once the build is finished. 2. Your dev server might also block reloading if a type error is found. 3. Your dev server might even show you that error in your browser so that you know what's going on.

Next.js currently does all three of those things, which makes for a really nice developer experience. You don't really have to keep an eye on another terminal — everything shows up in your browser. They even render a little loading icon to let you know when a rebuild is taking place.

Next.js uses Webpack internally, but Webpack isn't the reason for this nice developer experience; it's just a core part of it, and is only responsible for bundling and rebuilding.

I love talking about this stuff, for what it's worth, so feel free to ask more questions. I helped Etsy adopt both Webpack and TypeScript when I worked there, so I have a good chunk of experience in the area.

I don't think that's an integrated feature of Webpack, though. It is a feature of TypeScript's own compiler (`tsc`), but that's about it. Nothing about Webpack supports typechecking (or TypeScript) natively.

Another thing worth pointing out is that pretty much every editor that ha a TypeScript plugin uses TypeScript's language server to power it. The language server and the compiler are contained within the same binary (or at least they were) and use the same typechecking logic. So if you see an error in your IDE, you can be pretty confident that it'll be there when you build your code, and vice versa.

Thank you for ts-loader!

Running the typechecker independently of the bundler is really common in TypeScript. Typechecking takes time, and blocking on it to transpile and bundle your JS doesn't really add any benefit. Most build systems run the checker in parallel because it cuts down on build time. Plus, Webpack doesn't really do transpiling or typechecking for you — your loaders do. Webpack's loaders can't really check your types because, without doing a lot of extra magic, they operate on one file at a time. If you use Babel with Webpack, for example, Babel just strips out your TypeScript annotations and calls it a day.

All that aside, it seems like Turbopack was literally developed with Webpack's maintainer, who claims it to be a "rust-powered successor to webpack" (his signature is quite literally on the homepage[0]).

[0]:https://turbo.build/pack