github.fetch().fork() | |
.then(@chicoxyzzy) | |
.then(@blia) | |
.then(@ekozhura) | |
.then(@RReverser) | |
.then(@terrysahaidak) | |
.then(@ALF-er); |
Reposted from Qiita
For almost a year now, I've been using this "flux" architecture to organize my React applications and to work on other people's projects, and its popularity has grown quite a lot, to the point where it shows up on job listings for React and a lot of people get confused about what it is.
There are a billion explainations on the internet, so I'll skip explaining the parts. Instead, let's cut to the chase -- the main parts I hate about flux are the Dispatcher and the Store's own updating mechanism.
If you use a setup similar to the examples in facebook/flux, and you use flux.Dispatcher, you probably have this kind of flow:
Minimal example: transcode from MP3 to WMA:
ffmpeg -i input.mp3 output.wma
You can get the list of supported formats with:
ffmpeg -formats
Convert WAV to MP3, mix down to mono (use 1 audio channel), set bit rate to 64 kbps and sample rate to 22050 Hz:
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
""" | |
Usage: | |
Make sure that redis is running on localhost (or adjust the url) | |
Install uvicorn or some other asgi server https://asgi.readthedocs.io/en/latest/implementations.html | |
pip install -u uvicorn | |
Install dependencies |