I found this good video by Trace Dominguez. He gives a good overview and also mentions a bunch of new studies that are being done https://www.youtube.com/watch?v=dpjGLLbWZJ0
torturedllama
Has there been any messaging about whether this is costing the dev money? Does us using the app mean they'll get a huge invoice at some point?
Also, are other 3rd party apps working still as well?
This truly is the internet of old. Gen Z cower before the might of the old gods
Something I never seem to hear explained: What IS long COVID. Is it damage to lungs, is it a change in the behavior of the immune system, is it something that happens in the cells? Where in the body is it hiding? Is this something we just don't know yet?
It would make sense that eventually you could do both real-time and after-the-fact calculations depending on whether real-time communications is available. Presumably it will depend on the specific application
Mm indeed. Types to the rescue.
Are there any projects/tools that turn the types into Java-style web html documentation? If you need to know something while you're working on a non-typescript project that could be more convenient.
The issue I see a lot in the JS ecosystem is laying out documentation like a reference guide, but then not including all parameters or functions. These types of documentation are very helpful if what you need to know is included, because they have nice friendly explanations and examples. But eventually you will run into a parameter that is mentioned on Stack Overflow, or is in a code snippet in the documentation, but then has no further explanation in the documentation, as if it doesn't exist.
Projects where the README is the only documentation seem to suffer from this problem the most. They give examples of the most common parameters and functions, and then that's it.
In JS this is a big issue because there may be no way to know a parameter even exists, or what values it accepts, unless it is documented.
A lot of documentation in the Java ecosystem has huge auto-generated monstrosities with absolutely no explanations. In Java this is usually not useful because that information can be found in the types. But in JS it would be incredibly useful. Unfortunately it isn't as easy to automatically generate that type of documentation for JS.
Python in my experience has the best of both worlds. It has the friendly explanations and examples. But also has all of the parameters, even if explanations for some are a bit less detailed. And all of that is combined into a single place.
Indeed. It seems this wouldn't be useful for applications where real-time position is needed. You would most likely do the calculation at a later time like in the Miikshi video. It's a little confusing from the article, but the video actually does a good job of explaining this limitation.
I think the most amazing part about this is the video at the bottom of the article: Miikshi: Cosmic Rays (4K). The caption calls it a "charming fictional animated video to explain their muon-based systems". But I cannot emphasize enough how much this undersells it.
It's like a weird charming mashup between Thunderbirds, Muppets and a real muon science team. You really have to just watch it.
If you had trouble understanding what the muon positioning system from the article might be used for or how it works there is a short explanation from Professor Tanaka at the end of the video.
For a Reddit/Lemmy app though I would still prefer images to load in the app itself, because it's more seamless. For now Jerboa handles images and GIFV just like any other link.
RIF let's you configure this, which is nice. For Jerboa I think the default should eventually be to load them in the app itself (RIF calls this "Native").
Edit: Jerboa does already load the OP image in-app when you open the comments. I think that behavior shouldn't change. It's just when you open the image from the news feed that it opens it like a link currently.
When you open a link from Jerboa it should open a mini in-app version of your main browser. If your default browser app is set to Firefox it will say "Powered by Firefox" and if it is Chrome it will say "Running in Chrome". UX wise it is very similar to having a bundled in-app browser. But the rendering is handled by your main browser.
I'm not up-to date with the story behind this, but my understanding is that new apps that want in-app browers should be implemented in this way. This seems to be the modern way of doing it. The reason for it I believe is mostly security. Your main browser app should be up-to-date on security patches and features, and if apps can just piggie back off that then they don't need to worry about shipping and patching their own in-app copy of the browser. Also it respects the user's choice of default browser. So if your default browser is Chrome it will use that for the in-app browser for all apps that work this way (which is quickly becoming most apps).
Another advantage of doing it this way is that when you use the "Open in Firefox" button it seems to just move the tab from one app to the other rather than reloading it, so it happens almost instantly.
His fur is also very luscious. Clearly very well fed indeed.
I hope the mods don't ban him, I heard that well fed foxes aren't well received on some platforms