I understand that they couldn't use the Escape key, and so having an alternative makes sense, but I'm not sure as a user how I would ever discover the behavior of pressing "shift" three times.
It's incredibly painful to do this with a large library, as they've stopped supporting the desktop uploader. It's all drag-and-drop uploads, so it's not easy to keep it in sync with a folder of music.
Also the playback experience is painful and uploaded files are poorly supported across devices like Google Home, where it constantly wants to do playlists or mix in other music. I'm not sure Google Home even supported playback of uploads, though I abandoned the service shortly after the Play apps went away.
I used to use iTunes Match. It'll change more than just metadata, I've had instances where album tracks were swapped out for their clean versions. I've dropped it in favor of a self hosted version I can ensure won't muck with my music.
Another Navidrome user here, hosted on a $5 Linode Nano. I have rclone set up to mount an S3 bucket with the music files. Scanning them is a bit slow, but otherwise I've had no issues.
I highly recommend Symphonium as an Android client. It is receiving constant updates, highly polished, has an offline mode, Android Auto support, and so much more.
The title is misleading. This article argues that you should not use a UUID for a _session cookie or access token_, which was never the intended purpose of a UUID.
I had a similar response when reading "React adapter allows you to access signals directly inside your components and will automatically subscribe to them."
I don't believe this is worth it. The implementation is fairly dangerous and fragile as you point out, all in order to simplify something fairly clean/reacty such as `const value = useSignalValue(signal)` into `signal.value`.
> We also require every access to any stack variable to do math to figure out where on the stack it's arguments are.
In the article, it appears to be the opposite. Previously this math was required (`[ai] = 2 + parameter_count - i - 1`), but by reversing the arguments in the stack it's now always a constant offset, and they prevent indexing out of the passed arguments in the frame by ensuring there's at least as many arguments as formal parameters by stuffing the call with extra `undefined`s:
> But what happens if we reverse the arguments? Now the offset can be simply calculated as [ai] = 2 + i. We don’t need to know how many arguments are in the stack, but if we can guarantee that we'll always have at least the parameter count of arguments in the stack, then we can always use this scheme to calculate the offset.
While this looks useful, if `Foo` is an part of my application state I'm not too crazy about shipping that over to Facebook if I wanted to use this feature.
I do. I simply don't have any reason to doubt that he's being truthful when he says he read a certain book. Given that he clearly enjoys reading, I find it hard to believe that he has any reason to be dishonest in listing his favorite books.
Unless I'm missing some of the problems you're trying to solve, this seems like an extremely over engineered solution to the problem of code duplication (like validation) and boiler-plate communication code. For the former, if you're using a node backend, you can pretty trivially reuse the same code between client and server side. The later doesn't really seem like a big enough issue on its own to really warrant an architecture that requires a back-end with per-tab mirroring - you can usually encapsulate the 'cumbersome AJAX calls' with a straight forward API (or GraphQL query if that floats your boat).
This approach also forgoes many of the nice side-effects of having a clear slide-server boundary like avoiding leaking implementation details into your front-end code. Also, a simple REST API can be reused across platforms, so when you want a native experience on Android, iOS, etc you wont have to replicate this architecture or the underlying logic on each of those platforms.
Interesting to contrast this to what OS X(certainly Mavericks, maybe others) does. If you restart and opt to re-open previously open windows, they will open with screenshots of their previous states - only when you click on one will it dim the window and admit to you that it's not loaded yet. Personally, I find this a little irritating, giving the illusion that it's ready when it isn't. I find facebooks approach a little better, it doesn't pretend to be usable, but guides your eyes to the right part of the screen.
Ah, this is me being misleading, I didn't mean the styling of the document was important(well, until it gets sent to publication, where I am sure you're right about the interns), I really meant the ability and tools to edit/review/track changes and highlight/annotate sections they want changed.
I wouldn't be surprised if a lot of writers were less technically savvy, happiest writing in Word, or simply wouldn't know how to write in any other format. It makes sense from the publishers point of view to pick one format and stick with it, so they have a consistent editing style and ability, and only have to deal with converting one format into a final publication.
I do feel that this is one of those cases where you should be able to write in the way you feel best for you, and if the publisher insist on having the final document in a word format, it should be straightforward to convert your chosen representation to theirs. It's hard to say without knowing precisely how the publisher expects the file to be formatted, but if it's fairly straightforward, there are libraries that will write to doc files for you, or there are open formats that MS Word already knows how to convert into .doc files that you could target instead.
On Android I've been using Symfonium which is fantastic. https://play.google.com/store/apps/details?id=app.symfonik.m...