Software developer stories
en de

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. 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,}implOperation{fn from_string(input: &String)-> Option<Operation>{letregex=Regex::new(r"^\s*(\d+)\s*([+])\s*(\d+)\s*$"). 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. 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. 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. 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”? Continue reading
Older posts