The source content for blog.juliobiason.me
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

99 lines
4.2 KiB

+++
title = "Links for 2020-04-30"
date = 2020-04-30
[taxonomies]
links = ["links", "events", "event source", "shell", "scripts", "rust",
"dynamic dispatch", "actix", "diesel", "slides", "presentations", "runbook"]
+++
Event Driven Architectures, Shell Scripts, Rust Dynamic Dispatch, Actix and
Diesel, CLI Slides, Making Presentations, Runbooks.
<!-- more -->
# [Event Driven Architecture](https://pradeeploganathan.com/architecture/event-driven-architecture/)
A long explanation on what Event Driven Architectures are.
Honestly, it is one of my favourite patterns, 'cause it allows high decoupling
of data. You have one thing creating events and you can have a lot of things
consuming those events: You can save them directly to the database; you can
make them go through a summing service, so you have the data read ready; and
so on.
# [Writing Safe Shell Scripts](https://sipb.mit.edu/doc/safe-shell/)
I've seen a couple of tips like these floating around, so I picked one.
Shell scripts are a hell of lifesaver, giving the initial states for a way to
automate stuff. But doing it right is a bit hard, and starting it in the safe
way can save your bacon in the long run -- or, at least, till you find a more
suitable tool.
# [Rust Dynamic Dispatching deep-dive](https://medium.com/digitalfrontiers/rust-dynamic-dispatching-deep-dive-236a5896e49b)
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
application work and where it can fail.
---
This post was built with the help of
* [clonejo](https://social.troll.academy/@clonejo)
* [HN Tooter](https://mastodon.social/@hntooter)
* [newsbot](https://mastodon.social/@newsbot)