This blog is about programming and other technological things. Written by someone developing software for fun and professionally for longer than I want to admit and in more programming languages that I can remember
When implementing tags for Texted2, I had a list of tags being:
let tags: Vec<(&str, u32)>; // Tag name, number of posts containing this tag
And I need to sort it by the second item of the tuple, the tag count.
Some years ago, I create a blog application in D and called Texted. The idea that time was to learn D using a project. This time, to learn Rust, I created a new version of that same blog application, but faster and improved.
I present you, texted2!
A very important part of any software are the unit tests, after all, they help us verifying that the cases that are in our heads are indeed correctly implemented and also that whoever is the next lucky fellow changing our code in the future (it might be ourselves!) will feel confident that their change won't break the application.
Rust implements tests in the same file that you are implementing your functions. I will first show one example and later explain how it works.
First, let's see a piece of code I used in a tool to generate posts for my newly rewritten blog system Texted2
So, you created your awesome server-side application and you are ready to start using. However, you want it to start automatically with your server and restart if it crashes. Also, you're happy to have a system that uses System D
So, how do we do that?
(Spoiler alert: It's super easy)
In a C++ project I am currently working, we are using CMake/Conan for dependency resolution and planning to use flatbuffer to serialise some messages. When searching for documentation, I noticed that flatbuffers documentation is not the best one and that the integration with CMake is even harder to find, therefore, I decided to write a recipe on how to integrate it to reduce the misery of other developers around.
First, let me explain quickly how it works.
How to be a great software engineer?
Someone asked me this question today and I didn’t have an answer. After thinking for a while, I came up with a list of what I try to do myself.
Disclaimer: I don't think I am a great engineer, but I would love to have listened to that myself when I started my career, over 20 years ago.
I will divide this in parts, non-technical and technical
Has it happened to you guys as well?
There is always those quite obvious things such as "don't be a jerk". Those are not the ones I will be talking now.
I want to talk about what I learned in those many years reviewing code and getting my code reviewed.
Whoever wrote the code you are reviewing thought hard about that code. Hardly someone just writes carelessly some code, so if something is not clear, instead of saying the implementation is wrong or not ideal, try to understand and ask questions to clarify why it was done the way it was.
Two of the best features when using an IDE are auto completing and debugging. Fortunately, we can have both with VSCode.
Go to rust website and follow the install procedure
Then use nightly channel to get the latest version of the toolchain.
# Install nightly toolchain
$ rustup toolchain install nightly
# Set nightly toolchain as default
$ rustup default nightly
This is that kind of code that we don't write all the time, so let's remember the different ways to load and create libraries on Linux
There are 3 ways a library can be used by an application
We are going to show all the forms in this article
This blog is about programming and other technological things. Written by someone developing software for fun and professionally for longer than I want to admit and in more programming languages that I can remember