Julio Biason
5 years ago
1 changed files with 98 additions and 0 deletions
@ -0,0 +1,98 @@ |
|||||||
|
+++ |
||||||
|
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) |
Loading…
Reference in new issue