Writing System Software [video]
youtube.com
youtube.com
1. Code snippets: show small self contained functions from random places inside Redis.
2. Redis Sentinel: the first design, the immediate redesign of v2, and how it is internally implemented.
3. The use of goto in Redis.
4. Redis protocol parsing and zero-copying of objects.
5. The odd Redis persistence model: fork() and fighting the copy-on-write.
6. Redis crash report. Generation and usefulness over the years.
7. Observability inside Redis: latency hooks, LATENCY DOCTOR and MEMORY DOCTOR.
8. Hybrid data structures: Streams macro nodes implementation.
9. RIO: Redis I/O abstraction and OOP in C.
10. Redis Cluster: how the Redis message bus is implemented.
11. Redis Cluster: hash slots tracking and redirections.
If you have any preference and/or other ideas, will be cool to hear.
About this experience itself, good things: shooting a video takes more or less just the time to record. Preparation is just a few minutes, and later post processing is an automatic process... So in 1 hour max everything is done. However I see that the reach of the videos is very low compared to a blog post, which requires more time to write sometimes, at least to have the same amount of info. So it's a tradeoff. Also consuming the video may be a problem for many, for instance for language barriers due to the speaker accent (in my case) and the listener ability to understand English without subtitles. Let's say I want to make 10 episodes and re-evaluate if it's a good idea to change style and do 5 minutes episodes instead.
That's the reason why in my other comment, the data screencast I created was made in addition to a blog post, where the blog post and the video explicitly link to each other as cross-promotion.
That does extend production time significantly though.
I feel like that knowledge needs to be shared around a bit more.
It seems like there are really 2 meta topics: 1: Using C and the OS to maximize performance 2: building distributed systems
As an aside, I noticed several typos sneaked into comments here and there ('command gets replicated to the salves', etc). I'm half considering filing a pull request for them, but feel it might come across as overly pedantic. Would such a PR be appreciated?
5. The odd Redis persistence model: fork() and fighting the copy-on-write.
It's usually easier for a non-native English speaker (at least below ILR[1] Level 3 or CEFR[2] Level B) to understand English spoken by another non-native, because the pace is slower, idioms and expressions are not used so regularly, etc. Your accent is much easier for non-natives than a strong Irish accent, for example. So I wouldn't worry about that too much.
[1] https://en.wikipedia.org/wiki/ILR_scale [2] https://en.wikipedia.org/wiki/Common_European_Framework_of_R...
Same goes for a tendency of many native speakers to indulge in idioms, archaic vocabulary and convoluted syntax just for the heck of it. Non-natives just cut to the chase, which is exactly what you want in a technical discussion.
As a side note, can you share your Terminal color scheme? It's really nice
Interesting stuff, I haven't had to write C++ in a few years, it's nice to have a bit of a refresher.
Some basic lighting (so your face isn't in shadows), a separate directional microphone (even a $40 snowball would help immensely), and potentially some sound baffling in the room would make a real difference to the video quality. Finally, dark colors with low contrasts encode quite poorly on YouTube; some of the code is rather hard to read.
I realize we're watching a software engineer and not an entertainer, but the payoff in the quality of the videos for relatively little effort and investment is remarkably big.
- Noise reduction
- Compressor with "Make-up gain for 0 db after compressing turned off".
- Equalisation with a curve that starts at -6 db at 20Hz, peaks at 6 db at 150 Hz and then curves down to -30 db at 20000 Hz.
- Normalise with Remove DC offset and normalising at -0.1 db (0.0 db sometimes leads to problems for some reason).
- Amplify if you need it (usually I don't)
The logic here is: Noise reduction, to reduce hiss, key clicks, etc, etc., Compressor to squash the low and high amplitudes (turning off making up the gain also forces it to squash in a certain direction... I forget which at the moment, but it's important), Equalise as a kind of nicer low pass filter that gets rid of the noise reduction artefacts and other noises that make it through, Normalise to bring the amplitude back up that was knocked off by the compress (but in a nicer way than amplify would give you). Finally just fine tuning with amplify.
I usually re-encode in FLAC and then mix it back into my video using my video editing software (I use Kdenlive).
The difference in audio quality is unbelievable. You need to fiddle around a bit with the settings for your voice/environment, but I highly recommend giving it a try.
this seems like a very bad idea, this will give you very dull, boomy sound, for most recording setups. It's a bit too much work to type out everything here, but this is not good advice.
Most of the time the best improvements are to be made with getting a decent microphone and set it up properly (doesn't have to cost much more than $100).
I have a daily programming stream on Twitch: https://twitch.tv/nybblesio. I stream from 5am-10am MT Monday to Saturday. (I have to take at least one day off or my brain overheats.)
I also archive all of my streams to my YouTube channel: https://www.youtube.com/channel/UCaV77OIv89qfsnncY5J2zvg
I have several projects running concurrently and I switch between them each week. This week, I'm working in C++17 for Ryu: The Arcade Construction Kit. Next week, I'll be writing ARM AArch64 assembly language on Raspberry Pi 3. I also have an MS-DOS arcade game project written in 100% x86 assembly language. I worked on that last week. All of these projects are curated into playlists on YouTube if you want to check them out.
(is this what it feels like to be old?)
Though it's amusing when people come out of the woodwork and call you a spammer. That happened to me once. It's like... Yeah, but that's what we're all doing here. What's the point otherwise? We all build stuff and we all talk about it.
DHH's blogpost - https://m.signalvnoise.com/on-writing-software-well-aee37807...
https://www.youtube.com/channel/UCdx5Dk3EWTe2i8YDA7bfl6g/vid...
1. It requires subject preparation to avoid going off on a tangent. (in the case of the video above I cheated and use prewritten code, and the video was still 30+min long.)
2. It requires specialized software and hardware that's not free. (good recording software + good mic + good webcam are $50-100 each)
3. It requires good hardware preparation too (e.g. precise placement of the mic and good light for webcam, so I couldn't record at night)
4. It requires time for editing (unless in my case you slap on background audio and call it a day)
I bought a new mic since I was unhappy with the audio quality in that video, and am taking steps to refine video focus.
Studio lighting would solve that and falls into your mentioned price range per item.
DHH wrote about his series in this blog post: https://m.signalvnoise.com/on-writing-software-well-aee37807...
Link to his playlist: https://www.youtube.com/watch?v=H5i1gdwe1Ls&list=PL3m89j0mV0...
The correct playlist is now this: https://www.youtube.com/playlist?list=PL9wALaIpe0Py6E_oHCgTr...