> 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.
I had a comment in this file for a very long time but the project lead was something of a Professional so he removed it. The comment was "# MULTIPASS!"
> 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!
always great to see devs sh1t on other devs under the premise of "this isn't right!!!" when in reality it's just affecting their bottom line. money makes the world go round!
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.
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.
Ugh...the tax shit in the US is so annoying. At least your e-commerce system is meant for a single kind of transaction, I worked on a more multi-purpose system (that was also open-sourced! https://github.com/workarea-commerce/workarea) that handled everything from physical items to buy online pickup in store to digital items to subscriptions. It was a LOT of work getting that tax system in order! We usually recommended our clients work with a company like Avalara or TaxJar (which is now just Stripe) so they wouldn't need to take on the burden of taxes, but a lot of folks didn't and just used our stuff. It got confusing lol...
> The team has a history of over promising and underdelivering (or scamming - depending on your perspective).
Their attitude of not communicating anything and basically inventing stuff the R1 can do without actually having the engineering to back it up is what is "scamming" to me. Over-promising and under-delivering is one thing, but lying about what something can do and then going back to the engineering team to "just make it happen" is what I am reading between the lines here.
This is awesome for folks who don't use their own custom status bar! Personally, I use SketchyBar and Yabai for window management. SketchyBar is shown almost all the time, but the status bar is set to hide unless I have my cursor at the top of my monitor. I like this because it's a good combo of having my "status bar items" all compacted on the right, with the useful information I want on the status bar at all times...such as battery level, current weather, volume, the date/time, as well as the focused window.
For those who don't want to install a custom status bar, this seems like it would solve similar problems of the status bar getting way too big with all these programs running in the background.
After years of watching spyware make a ton of money on their platform, Microsoft took a page out of Apple's book and created their own spyware for Windows.
As someone who used Go since before v1, I can say that Go's approach to dependency management was basically "we don't want to touch it until we know we have the right idea". At the time, dependency management solutions were pretty primitive to what we have today...there was no caching, and if the central server where you got your dependencies was down, you were shit out of luck. So this was really not a bad decision for the language maintainers if they wanted to keep their sanity and not subject their user base to "legacy on arrival" software. By depending on URLs and using a `$GOPATH`, this problem was solved from a localized perspective...as a developer, I could vendor in packages, not check them into Git, and compile the program. It worked.
However, the biggest problem with depending on packages in Go back then was that it was difficult to communicate to other people on your project the exact version of the dependency that you wanted them to install. For projects in which you were the only developer, this wasn't an issue...but as soon as you started to use Go in a team setting, it became a real blocker toward getting your work done. Go developers needed _some_ way to communicate what version of each package they wanted to install, and a bunch of solutions popped up to help with that. But they were all still bound by the `$GOPATH` constraint and such.
Although it took a lot longer than many predicted, I'm still pretty happy with how Go approached dependency management at the end of the day. Generally, all I have to do is import a dependency from a known URL and my editor/Go modules will take care of the installation work. This is way better than the JS world, in which if I want to just sketch something out I have to actually install the dependencies I need otherwise TypeScript will yell at me. With Go, it all seems to happen automatically.
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.)