tomphoolery

> However, in this situation it may make more sense to disable biometric authentication.

In Face ID, there's a setting that requires direct eye contact in order to open your phone. Highly recommend enabling this when feeling insecure about someone forcing you to open your phone (if it's not already on by default) because it means somebody forcing you to open your phone with Face ID can be easily defeated by simply closing your eyes. I tried this a number of times during the BLM protests, and I/nobody else could get my phone to unlock unless my eyes were open and looking right at it. So with Face ID, I think it's actually way more secure to have biometric authentication turned on, using this setting. The thumbprint stuff might be a good idea to avoid though.

(WARNING: This will make your phone pretty much impossible to unlock with your face if you're inebriated on anything. Ask me how I know. xD You should probably disable it after the protest.)

Most people who make a living as a musician these days do so by being a "renaissance man" of sorts, where they make their money doing a multitude of different things. This includes playing live, but some other examples live sound, stage tech, lighting, promoting/booking events, instrument trade shows, and composing music. You can think of this as being "T-Shaped" in the software industry, except the difference is in the music industry, you need to be "T-Shaped" just to survive, not simply to excel. The "long part of the T" is what you generally want to do most of the time, and it's usually how people identify their job when asked. But really, most of us do a combination of many different things to get by, almost none of these jobs pay enough or are regular enough to do it on their own.

This was, and still is, a HUGE shift in the way I live my life after moving careers from software development into music composition...

Even as a film scorer, who has jobs that last for a long time and include many personal conversations with the film makers, you're not guaranteed to get back-to-back gigs, so when you're done with one score, what's next? It's not like there's always someone handing you jobs if you're doing this by yourself. But that's my preferred angle, because the jobs do last longer and there's a more regular (and higher) payout. It just takes a lot of back and forth with the people making the film, in order to get the vibes just right.

> SWC was one of the earlier Rust builders, which then became absorbed into Vercel and turned into Turbopack (is my understanding)

SWC and Turbopack aren't related in the sense that one is the "successor" of the other. They both do different things, and compliment each other. SWC is more lower-level, it's a compiler for JS (and other web tools) that converts your syntax into something any browser can understand. Turbopack is a bundler, it takes that compiled code and minifies/concatenates it together in various ways so it can be distributed to a browser efficiently. I believe Turbopack does in fact use SWC (if you're using Next that is) to do the "dirty" work of compiling TypeScript code into JavaScript quickly, but its main feature is the use of the Turbo engine to cache function calls at a very low level. From what I read, Turbopack's potential to make building JS apps incredibly efficient should be a really neat thing to work with in the future!

> I was also similarly disappointed with the quality of Supabase’s auth offering considering all the praise I consistently see for Supabase on HN.

Around the time you were trying it out, there were some issues with Supabase clients not authenticating properly in SSR environments like Next.js or Remix. I think those have been solved with the introduction of the `@supabase/ssr` library, and continuing to use a middleware for refreshing the session upon each request. This latter option was always available, but wasn't in the example, so I think a lot of folks didn't implement the auth middleware and thus didn't ever refresh their stored access token.

> The fact that those boundaries are crossed means that anyone who is in competition with Automattic might have any and all ecosystems that Matt has any control over leveraged against them if they upset Matt or Automattic in any way.

There was never a boundary in the first place if it's the same guy doing both things. WordPress has always had this veneer of "community-driven", which is what they hide behind when people get their sites exploited, but Automattic really holds all the keys here. Just because Matt replies with an `@wordpress.org` email vs. an `@wordpress.com` email doesn't mean he's a different person all of a sudden.

This went from "hey you guys shouldn't use WP Engine because it's not Real WordPress" to "WP Engine is violating trademarks and isn't welcome in the WordPress community anymore" really f'in quick!

As someone who's made a few Electron apps in the past, I can say that it has a lot more to do with what you're putting into the app itself than the runtime shell you're working with. It's not impossible to make an Electron app that's very efficient, to the point where people probably wouldn't realize it uses Electron unless they opened the app itself and poked through the source code. That said, due to Electron being a layer above the actual application stuff that's doing the "real" work, it's a lot harder to sniff out performance problems and especially to reproduce them on all platforms. So I wouldn't call this "bad application logic", I would say that it probably has more to do with using older (and deprecated) APIs to handle certain things like resizing the window, which could be replaced with better ones if the devs at Slack were able to easily see that this was causing problems for people. Unfortunately, Electron does make that a bit harder to do.

Basically...I'd say this has more to do with the fact that Slack's development team doesn't get enough control over their applications in order to make things like this happen faster.

can we do this for react native? asking for a friend...

What developers _should_ be doing is disabling such animations if `prefer-reduced-motion` is set in your browser. This way, both people who have trouble seeing stuff when there's too many complex color animations as well as people who "just don't want to deal with all that mess" can specify what they want to see, and the code can change based on their preferences.

Unfortunately, I believe for "custom jobs" like this you'd need to explicitly state that you don't want it to occur because it won't happen by default, unlike some other stuff that's more standard in the browser.

Finale was my first notation program, and while I switched to Sibelius out of necessity during college, I never really liked it. Will definitely check out Dorico, heard good things!

Is anyone else sick of the "European Parliament" deciding the rules for the rest of the Internet? I know I sound like a dumbass American here, but I feel like there's gotta be a way for the EU to get what they want without bothering everyone else in the world constantly...

The issue is that they keep enacting laws that have good intentions, but are written poorly and without any sort of experience in the technical realm. This results in the laws' implementation being filled with weird loopholes that you can use to get around the extra work while still maintaining the legality, but completely missing the intention of the law in the first place. It just seems like a massive waste of time to me.