1,200 karma · joined October 26, 2013
One thing vanilla JS does have going for it though is performance. I profiled a script of mine and rewrote all the bottlenecks using native JS and it's undoubtedly faster.
I highly recommend anyone struggling to utilize it to write wrapper scripts around it so you only need to figure out things once. Here are some things I've done with it by that approach:
* Extracting any embedded subtitle files from MKVs. Nice if I want to search them or make changes.
* Back when GIFs were more popular, I converted any that were over 3MB to video to save space. If the output wasn't small enough, it would do a second pass with different settings to get it more compact. Not needed that much these days.
* "Barcodes" for videos, that is, it takes every second converted to a vertical sliver and combined you get an overview of how the average color of the film changes through its duration.
* A tool for creating video excerpts that lets me specify a start time and end time in more flexible timestamp formatting, and other things like a simple parameter for the output width.[1] It also allowed specifying a target filesize and did the math so the right bitrate would be chosen. I even include metadata so I know which original file it was made from and the parameters specified.
* Thumbnail previews. A lot of file sharing sites will include a file that includes some timestamped screenshots in a grid with encoding information at the top. This is good for movies so you see a high-level overview. The best part about doing this myself is that I could make it highly configurable, like choosing exactly how many images I want, the interval, whether I want timestamps, etc.
Note, for some of these, I also needed ImageMagick.
Also, when compiled with the right flags and libraries, FFmpeg has some really neat features: things like embedding subtitles, stabilizing video, hiding logos, etc. I recommend looking into the filters.
Thank you for all the manpower that goes into the project!
[0]: Two other ones that are also powerful are ImageMagick and Pandoc.
[1]: I initially wrote this in Bash, but later converted the code to Python to better handle command line arguments and allow things like using config files.
Also, asking people their impressions can be helpful in the human aspect of the research, but quantitatively you need some sort of metric you can evaluate their experience on. For example, you'd assign a task and see how well people did comparing the two modes, while also making sure the difference is statistically significant (meaning it wasn't just as likely to be chance).
This is just the beginning of where good study design starts. You'd also do things like assigning the modes themselves randomly, so to go back to the audiophile example, I might notice if it's always x and then y, but not if it's scrambled. You'd could go further and try to stratify the groups, so for example making sure one group isn't all elderly people and the other young. It goes on and on...
So while the scientific method is nice, especially for introducing science in educational contexts, the methodology and rationale behind research is much more deliberate and involved. By all means they can try out things themselves, but no, they will not "get better information than any study".
Secondly, regardless of where your site is hosted, you're also bound by the registrar's laws/restrictions (especially for ccTLDs), which doesn't make sense for something that is purely a routing mechanism that translates a name to an IP. It'd be fine if domain names were plentiful, but domain hacks[0] also make people use TLDs without regard to considering their territory or any implications.
The whole .org fiasco only proved further that this model with ICANN and for-profit registrars isn't tenable and a horrible fit for an open distributed internet. All these perverse incentives and political fuckery should not exist for something that is an essential part of a worldwide utility.
I'd love if HNers could share any promising alternatives to our current DNS system.
See also, ghost kanji: https://www.japantimes.co.jp/life/2018/10/29/language/ghost-...
Early Japanese on computers also used half-width kana but now it's all properly fullwidth.
Don't mistake technical limitations for choice.
> Chrome first checks the HTML lang attribute and if it's not present it checks the Content-Language HTTP header. Then it gets a prediction from cld3.
> His career soon took a detour because semiconductors, he recalls, just seemed too easy. He switched to researching optical circuits, did his Ph.D. thesis on integrated optics...
1. Try getting the Wikidata "official website" property
2. Then any link inside of a {{url}} template or |website= in an infobox
3. And if you really want to try to get something to resolve to, the first site wrapped in {{official website}}
If you need code to reference: https://en.wikipedia.org/wiki/User:Opencooper/domainRedirect...
[0]: https://en.wikipedia.org/wiki/User:Opencooper/domainRedirect
[0] Think things like Creative Commons or public domain. The license has to allow derivatives and commercial use for anyone, not just Wikipedia.
[1] So exceptions would be for dead people or things that we are very unlikely to get new pictures of. Doesn't apply when you could try getting a license or if there is an existing free image.
[0]: And if you don't have money, you cannot access the commissary nor even make a simple phone call.
And not sure why you've decided to zero in on murder rates, as if everyone in prison is a convicted murderer. I also don't see how your family is relevant, as you can't extrapolate from that.
[0]: https://en.wikipedia.org/wiki/Prison%E2%80%93industrial_comp...
[1]: "African Americans are incarcerated at more than 5 times the rate of whites." (https://www.naacp.org/criminal-justice-fact-sheet/)
There are Chinese-based alternatives to Wikipedia that are much more popular: https://en.wikipedia.org/wiki/Internet_in_China#Online_encyc....
[0]: Here's the paper: https://journals.sagepub.com/doi/abs/10.1177/205157071454056...
[0]: Because I was interested in typing characters while not actually knowing the kanji. The Tagaini Jisho app (https://www.tagaini.net/) was indispensable because it lets you search on multiple parameters including partial FC # and simpler methods like SKIP codes (http://nihongo.monash.edu/SKIP.html). The only characters I couldn't transcribe with this method were those printed so small that the individual strokes were difficult to make out.
The crux of the issue is that kanji don't have an inherent "natural" ordering that a user would expect. Sorting by their character code doesn't mean anything to a Japanese person. But, what if we made our own standard of what entails a "natural order". There's nothing about A–Z that makes the alphabet obligated to be in that order (and not something like based on sound or shape) other than it being the convention that developed. Even hiragana can have different orderings (AIUEO vs IROHA [0])
One proposed method would be to do it how the dictionaries do it: first sort by major radical, [1] and then by stroke count. This is something most Japanese learn when learning how to write characters anyway (of course ambiguities would arise when the radical is shared and the stroke count is the same, but we could just choose a third arbitrary factor; we'd also have to decide on a specific written form as stroke count can differ depending on whether it is handwritten or the font).
We could then teach our approach to schoolchildren and it would just become accepted over time like other things they learn. But wait you say, it's more natural for them to sort on pronunciation. However, if I gave you a list of polygon names and told you to sort by the number of sides they had, you'd be perfectly capable of doing it despite that not being alphabetical. Things are less "unnatural" if you grew up learning them and your brain doesn't experience dissonance.
Anyway, just my hot take.
[0]: https://en.wikipedia.org/wiki/Iroha
[1]: https://en.wikipedia.org/wiki/Radical_(Chinese_characters)
As for the latter, you'd have to perhaps feed Google Scholar the right incantations or ask someone with knowledge. As far as I know, video codecs already have a huge bag of tricks they use (for example the B-frames borrowed in this post). Even then, the key points in this codec were that firstly it's meant for use at very low bitrates, where existing codecs break down, and then secondly it's a vocoder, so it's converting audio to an intermediate form and resynthesizing it. That kind of lossiness is acceptable for audio, but I'm not sure how it would work acceptably for video.
It was one of the premier sources for propaganda during a certain country's recent election. It has been used to coordinate protests. It's been used to break national news. You can get minute-by-minute updates of events from it. Let's not pretend that one of the world's most-used communication platforms doesn't play a huge role in modern discourse.
[0]: https://english.columbia.edu/events/undead-texts-grand-narra...