Event Driven Architectures, Shell Scripts, Rust Dynamic Dispatch, Actix and Diesel, CLI Slides, Making Presentations, Runbooks.
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.
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.
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.
Actix is all in rage for development web applications in Rust: It basically took almost every position on web frameworks benchmark 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.
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
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.
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).
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