tytho

I was a heavy macOS Spaces user. Upon a recommendation to use Aerospace from somewhere else here a few months ago, I switched and love it. I considered Yabai, but some features required disabling SIP (System Integrity Protection).

At least with pnpm, you can specify minimumReleaseAgeExclude, temporarily until the time passes. I imagine the other package managers have similar options.

[1] https://pnpm.io/settings#minimumreleaseageexclude

Game development is often a completely different set of skills and maintenance profile compared to enterprise SaaS development. Many single-player games especially indie ones don’t need to worry about multi-year contracts or having to work through many cycles of different developers coming in and out of a project. Having a 1000+ line switch statement seems totally reasonable on a project with a handful of developers that will continue to work on the project.

My understanding is that the switch statement was for npc character conversation text. That seems pretty reasonable, even in enterprise SaaS for something like translations. It might not be as easy to maintain in other circumstances.

I’ve been using Zed [1] for some time now. They are also pretty AI focused so it may only be a matter of time, but so far I’ve been able to disable all of the AI interactions.

[1] https://zed.dev/

Many applications need a way to contact a user (security breach, password reset). If one only has a username and forgets the password, there’s no way to reverify the user.

Fly has a form of auto-scaling. You have to provision the max amount of machines then you configure them to auto-sleep. It's possible that the creator didn't anticipate this much traffic or didn't want to pre-pay for all those sleeping machines.

I can’t speak to the official decisions made by these camps/courses, but from my own experience as an undergrad, I was first introduce to MySQL, and the professors at my university did not teach using migration management tools for bringing a schema in a database up. You were either using a GUI to set up the tables, or running your own cobbled together sql files. For class assignments this was fine. Then I had a professor introduce mongo to me. I was floored by the idea of having my schema live along-side the application code! No more messing around in SQL GUIs! Then of course over time I realized you still need to maintain a schema over time and provide someway to “upgrade” data when your schema evolves, and keep your data consistent. Then I discovered the tools around migrating mongo data are not nearly as mature as the ones you’ll find for SQL databases.

I find mongo alright at producing a short-lived prototype of an application (e.g. school assignments), but the risk of it shipping to production for a long period is too risky for the “benefit”.

They can be, but they both offer PostgreSQL services. The article touches on Supabase’s other offerings, but the comparison is mostly on the database offerings.

The browser EventSource constructor does not have options to pass in your own headers. You can pass an option to have it use the cookies for the domain you’re using. There are libraries that allow you to pass in additional HTTP options, but they essentially reimplement the built-in EventSource object in order to do so. Not terribly difficult, fairly simple spec.

Ah, I titled that wrong. Fixed! Mostly authentication, but authorization is also a topic I’m studying a lot recently. I feel like there’s more resources on that than the questions I have about authentication. I’m currently diving into the Google Zanzibar papers.

You can still use `tsc` to validate the jsdoc types. It will spit out errors when types don’t match.

You can use `tsc` to export the types defined in jsdoc and other projects that import your module will get all the intellisense and type checking as if it had been written in TypeScript.

I won’t speak for others, but I for one can’t stand the amount of extra packages needed to get a TypeScript project working. I need to install adapters for my linter, formatter, test runner, editor, bundler to name a few. Hopefully it all works together with all the other plugins and adapters. With the jsdoc version, I just install the `typescript` package, and I can use that to do the typechecking as well export types to be used by a TypeScript project. Sure it’s a bit more verbose, but I’d take that over tinkering with dependencies and configurations.

There is another way that isn't _as_ kludgy, but still not as nice as the JavaScript proposal:

    computation() |> then(&Map.put(my_map, key, &1))

From personal experience, you don’t ever “just use TypeScript”. You have to install plugins, adapters, parsers for every other tool (linters, formatters, bundlers) to also make them work with TypeScript. Adding TypeScript into the mix increases the number of dependencies (dev or not) dramatically. If you use the jsdoc flavor of TypeScript, you only need to install the one dependency.

Not saying it’s the best reason, but a reason nonetheless.

That's definitely more convenient. I think it could be nice to have an additional test suite not written in the same language as the thing you're testing. It would force you to interact with your program the way the rest of the world would. Rather than relying on mocking, setting up test data, and reaching into the internals of your code, you have to set up your test data through the API. This wouldn't be feasible in most of work I've done in my professional career, but in an ideal world I think it could be beneficial not to rely on internals for testing, at least for some set of tests.

We're seeing some issues possibly related to s3. Uploads working, but downloads seem to fail occasionally.

My input probably isn’t as valuable except as a data point, but the company I work for (around 100 employees) moved all employees over to a 32 hour/4 day work week without a change in salary. No negotiation involved technically, though there were a few employees who have been talking about 4-day work weeks for a long time.

They made this change with a 6-month trial period where we would determine if we would keep it at a later time based on some sort of productivity measurements. Everyone, including the CEO, seemed to agree that trying to measure productivity would yield few meaningful metrics. The consensus at the end was that productivity was either the same or a little less, but we ended up keeping it anyway.

You can pass a ‘withCredentials’ option.

I think that works great! The complaint I’ve heard is that you may need to support multiple ways to authenticate opening up more attack surface.

He was likely using a polyfill. It’s definitely not in the spec and there’s an open discussion about trying to get it added: https://github.com/whatwg/html/issues/2177

You cannot send custom headers when using the built-in EventSource[1] constructor, however you can pass the ‘include’ value to the credentials option. Many polyfills allow custom headers.

However you are correct that if you’re not using JavaScript and connecting directly to the SSE endpoint via something else besides a browser client, nothing is preventing anyone from using custom headers.

[1] https://developer.mozilla.org/en-US/docs/Web/API/EventSource...

I was just helping a family member with this same issue (large amount of “Other” space) and turns out it was some unmounted volumes that had somehow been created. We couldn’t track down what was on them in the time period I had to help, but doing a clean wipe cleared it all up. Not the best answer to the problem.

In general, I agree that sessions should be opaque tokens stored in an http-only, strict same-site policy cookie. I just had a few problems with a couple of the arguments:

3. Could have stale data

The only use case I've seen for storing authorization information in a JWT is for something like OAuth2 scopes, which is different than strict authorization rules. They're more like delegate rules, but you should only treat those as a first line of defense before you do the checks that the authorizing user actually has access to.

Also, it's just as easy to let a redis cache go stale. Seen it more than once with this same security issue.

4. JWT’s are often not encrypted so anyone able to perform a man-in-the-middle attack and sniff the JWT now has your authentication credentials. This is made easier because the MITM attack only needs to be completed on the connection between the server and the client.

If someone can MITM your connection in plaintext, they have your credentials, whether or not you use a JWT. Yes, any information you encode in a JWT is plaintext, so if you put personal information in there, consider it leaked. Am I missing the argument here?

I would also add my (admittedly limited) experience to using CDNs in this way. If you do add the subresource integrity attributes (which a lot of major CDNs don't support because they change the content based on user-agent), you should be prepared for when that check fails, which might mean your site doesn't work. It's certainly more secure than loading malicious scripts, but if you're JavaScript heavy and the CDN loaded library is integral to your site working, then a malicious actor could still do some harm.

Super interesting article that has reflected some conversations at past workplaces with coworkers. I can't seem to find who actually wrote the article. The About and Contact pages are blank, and there's no attribution on the article. This is also the only post for the entire site. I can't find a date for when this was written. Is @wessej the author of the article?

I read part of an early chapter of a book that taught a lot of these concepts in a practical way. The book isn’t out yet, but will be in the next month or so: https://pragprog.com/book/egmicro/practical-microservices

I think the code examples are out of date so don’t worry about downloading those until the book is officially released. This guy has had some great success stories implementing CQRS/Event Sourcing at his place of work in the last year.

I worked on a codebase that used the old "domains" this way, and it was very kludgy. We could get unit tests working, but we essentially mocked calling that 'set' method before the function we were testing used it. We eventually ripped it all out in favor of explicitly passing arguments down the async chain because we found that for some reason those "magic" variables were leaking across requests. Could have been another factor that caused it, but the magic was too much for us.

I believe the extension can be used in conjunction with the app to let the app use the cookies in your browser session, but to be honest, I've only seen others do it, and it was back in the day when Postman was just a "Chrome App" and not a detached application. Maybe that functionality exists in the new Postman app without the chrome extension.

Perhaps someone has already suggested this, but what if npm had some sort of "unpublish block" if any modules depended on yours? Or maybe some sort of notification to the dependent package owners. This doesn't solve the issue of unpublishing dependent free packages, nor does it solve someone taking over and putting malicious code, but it would encourage a more responsible behavior when removing a highly depended upon package.

What I meant to way was that you're not being ranked amongst your peers. Saying that you're "better than 100%" or any other percentage is just a result of the assumption that a really good score is 200.