Dynamic Dispatching is a way to make Rust applications behave like you had
polymorphism: You attach a trait (interface) to a structure and call methods
using the trait instead.
I had trouble making it work recently and this explanation -- which is pretty
complete -- got me back in track.
# [Rust Web Development Tutorial: REST API](https://cloudmaker.dev/how-to-create-a-rest-api-in-rust/)
Actix is all in rage for development web applications in Rust: It basically
took almost [every position on web frameworks
benchmark](https://www.techempower.com/benchmarks/) a few months ago and has
only consolidated its position -- not that the things it does are important
for CRUDs.
But the tutorial does the full job, explaining not only Actix, but also how to
plug Diesel, Rust famous ORM, into it.
# [Shlide: a slide deck presentation tool written in pure bash](https://github.com/icyphox/shlide)
Say goodbye to the problems of resolution! Do the hipster thing and instead of
using graphics, do everything in the console.
# [An Open-Source Collection of +200 Algorithmic Flash Cards to Help you Preparing your Algorithm & Data Structure Interview](https://github.com/teivah/algodeck)
While some people work on those "Awesome X", some people actually builds cards
for you to learn about algorithms and related knowledge.
And it's all open source.
# [How to Give a Great Presentation: Timeless Advice from a Legendary Adman, 1981](https://www.brainpickings.org/2012/12/20/writing-that-works-roman/)
Working one a presentation? Thinking on doing some online presentation in
these days of "stay at home"?
On a personal note, I've been doing presentations for over two years already,
and most of the stuff I learnt in the field instead of some technical list.
But I see that small tips like these really do help, specially when you see
people actually paying attention (well, at least, when you're not doing this
online).
# [Writing Runbook Documentation When You’re An SRE](https://www.transposit.com/blog/2020.01.30-writing-runbook-documentation-when-youre-an-sre/)
I worked with Runbooks once and I think they are awesome: "If you find this
problem, do this".
The only "but" I could add to this is that it focused on SRE people, and I do
believe who should write those are the _developers_: they are the ones that
know why a save file operation failed.
Sadly, this is not quite true, 'cause developers tend to ignore errors, or use
some tool that doesn't provide a good view on where things can fail -- or,
worse, can fail without notifying the developer. In this case, the Runbook
should be built with the SRE _and_ developers, so both can learn how the
