nidomiro

Software developer stories

Rust-04: More operators and loops

In the last post we improved the simple program to be extendable with other operators. In this post we will implement more operators and a loop.

Let’s start with the simple task: adding more operators. To support more operators we have to change two parts of the calculator, the parsing and the evaluation. First let’s look into changing the parser. For this we simply add the new operators (-*/) to the regex inside Operation::from_string. The resulting regex will look like this: ^\s*(\d+)\s*([+\-*/])\s*(\d+)\s*$. Now the parser accepts the new operators; first part done.

Continue reading

Rust-03: Improving the simple program

In the last post we created a simple program that would accept an input like 5+5 and calculates the result. In this post we will improve this program.

To prepare for adding more operators we need to improve the input-parsing. Currently, we just split the input-string at the plus-sign. If we want to know the operator, we have to choose another approach.

In this case I chose regex:

#[derive(Debug)]
struct Operation {
    left: i32,
    operator: char,
    right: i32,
}

impl Operation {
    fn from_string(input: &String) -> Option<Operation> {
        let regex = Regex::new(r"^\s*(\d+)\s*([+])\s*(\d+)\s*$").unwrap();

        regex.captures(&input).map(|capture| Operation {
            left: (&capture[1]).parse().unwrap(),
            operator: (&capture[2]).parse().unwrap(),
            right: (&capture[3]).parse().unwrap(),
        })
    }
}

As you can see we have a new thing called struct in the code. If you are coming from a language like Java or Typescript, a struct can be seen as a class without any methods. This struct is called Operation and as the name suggests it holds an operation. The fields left and right are both typed as an i32 or in other words a “signed 32-bit integer”. The field operator is a char since we only use one character for an operator. In rust strings and chars are utf-8, therefore a char can contain one unicode codepoint, not just a byte.

Continue reading

Rust-02: The beginning

At first, I didn’t like Rust. Managing memory myself is something I don’t want to do. After a first look at Rust and setting it aside for a few weeks, it appeared back on my radar. I thought: “This time I’m looking deeper into it”. So I started by reading the Rust Book; and I’m still reading it and find new concepts that are really clever.

One of the first things I discovered is that I do not need to manage memory myself. The majority of the management will be done by the Rust compiler; I just have to follow some Rules. These Rules, called “Ownership”, are a bit confusing to start with, but make more sense, the more you think about them, and the more you use them. In combination with the strict differentiation between mutable and immutable structures, you can write code that is easy to read, easy to think about and resource efficient - a combination, I thought never possible.

Continue reading

Rust-01: Why am I learning Rust?

This is a good question, a very good question. Why am I learning Rust?

To begin with, I programmed in a lot of languages so far: C++, Python, Swift, Java, Kotlin and TypeScript to name a few. All languages have some features I missed when programming in other languages.

Currently, my favorite languages are Kotlin and TypeScript; with Kotlin having the lead. These languages are expressive, and really nice to write. I can express my thoughts in code without having to convert them too much in order to make the compiler happy.

Continue reading

More secure DinD in GitLab CI

If you are reading this article you probably already know how to use DinD (DockerInDocker) in GitLab CI. The default way is to set privileged=true in your Runner-config.

This little flag makes everything work; but at the cost of security. There are many articles regarding this topic, eg. this one. The baseline is, if you run a container privileged, and the container uses the root-user inside, you can lose the whole server.

Continue reading

More secure deployments via ssh

If we deploy an application automatically we have to grant the CI (Continuous Integration) access to the server. Common practice is to do that via a GitLab Runner or an ssh account on the server.

Personally I would not recommend using a GitLab Runner for deployments, because you have to maintain it. Another potential issue is, that you normally register runners for your whole GitLab instance or groups. That results in a scenario in which everyone can use that runner and accidentally (or not) destroy, for example, your production server. To avoid that you have to register the GitLab Runner in the Project it belongs to only. But even then your production server can be misused as a build worker and therefore create performance issues.

Continue reading

Handling server configurations

Intro

During my work as a programmer I often encountered that configuration and infrastructure files only lived on the servers they belog to. If they had a copy in git, the states would always divert over time. One reason for this diverting is that you actively have to put the changed files in git, after you finished your work. It’s simply a thing you can forget.

What do I mean by “infrastructure files”? For me infrastructure files are files, that you need to configure the server itself, e.g. nginx-config, docker-compose.yml, … .

Continue reading
Older posts