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.
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.
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.
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.
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.