HOW TO MANAGE DOCKER SECRETS
The product that is produced by most software developer teams is a docker image. How can be sure that we are not leaking secrets in docker images? If we include them as building arguments for sure they are going to be stored in the own image. Is there any way to avoid having them inside the docker image? Introduction Suppose you have a docker image that requires a secret, you do not want to include it in the image, but you need during the process of building the image. In other words, you cannot pass the secrets as environment variables because you need during the construction of the image, not when running a container based on that image.
SOFTWARE ENGINEER, PROGRAMMER OR WIZARD
Introduction I have been named many things (with respect to my profession) some of them were not actually correct. Should I correct people? Should I be worried about this? Naming They say that naming something creates it. Does being called a Software Engineer increases our work level? Does it give more respect profession-wise? As our discipline evolves, we have had many names from programmers, to software developers, software engineers, or even wizards!
CODE REVIEWS OR UNDERSTANDING THE CODE
How would you do a code review? Only by reading the code changes or do you thing you need to actually run the code, and what is more important, fully understand the modifications? A tale of two code review cultures Let’s compare the two following environments: Slow but safe team Imagine a team were reviews are done by several members. There is a focus on the detail, PRs are slow to be merged as they are improved several times before the final merge.
DON'T WORK MORE THAN ENOUGH
Sometimes we push ourselves to the max. maybe because it is there are some deadlines when we are not going to be able to release the new version, maybe it is because our life outside work is not good enough or maybe because we are excited to be working in such a company/technology/team. However, our mental health is going to be damaged by overworking. The question is not how much, but when we are going to get burned out by overworking.
BIKE SHEDING IN MERGE REVIEWS
Focusing on the important things is a crucial matter. When trying to solve a problem, sometimes we subconsciously focus on the easy part, the known part, the part we know we can tackle, and forget about the other parts. The hard parts. Prelude Humans are falible, we know that we are not as rational, impartial and intelligent as we like. We are full of flaws. Bike sheding There were the best minds in engineering. Their mission was to build a nuclear power plant. They had 12 months to do it. That power plant would have to had (among other things) a bike shed. The engineers used 80% of their time designing the bike shed instead of designing the hard parts: the actual nuclear power plant.
GIT HISTORY IN PRS
Suppose you have a big feature, and you are creating a pull-request with all your changes. How do you organize the changes? Only one commit? One per sub-feature or sub-fix? How do you make that division? Or maybe you could organize the commits in a way that is helpful for reviewers… But how? This post try to show different approaches I have found during my years in the workforce. Alternative 1: hard semver In this model of work, the PRs do not matter, the git history does not matter, only the versions matter. i.e. the history of the commits is not examined at all. The version of the project is what is important, no PR reverts are made, only forward modifications.
OPEN SOURCE DEPENDENCIES IN SOFTWARE PROJECTS
Most of the foundations of current commercial software projects are open source. But what happens when an open source project becomens unmaintained? Dependencies, dependencies everywhere! Most software projects have a miriad of depedendencies. Why? Because we (as software engineers) are not going to reinvent the wheel. Having your software depend on a well-tested, maintained, and supported is a bliss. It saves you time, and work very easily: you only have to be aware of two things:
FOSDEM 2023
Past week I assisted the FOSSDEM 2023 conference in Brussels. It was two days of talks of different topics like programming languages, containers, security, etc. It was a blast! I am these days watching the videos of the talks I could not see in person My advice for future FOSDEMs Travel Pack light. Do not bring a suitcase, bring a 40L backpack with a couple of change of clothes. Brussels is a city packed with shops, so in the case you need some clothes, go to some store and buy them. Fly to and depart from Brussels Airport. Use the train to Bussels Midi (Brussels Central Station), that zone is in the center of the city and is well-communicated by transport. I brought my laptop with me and it is useful if the room is full and even then you want to assist to the talk. Leave for the airport Sunday evening, or even better, on Monday. FOSDEM campus FOSDEM is held in the ULB. Buy a T-Shirt and pick-up a map and the schedule for the conference. Select the rooms you want to stay. Select backup rooms in case it is full. I stayed in the golang room, because is a language I would like to improve. There are food-trucks in the campus, but my advice is to go to a close restaurant and eat proper food there. Is FOSDEM worth it? Being that Brussels is only a short plane trip away from where I am based from (Madrid), it is convenient.
DOCKERFILE STAGES MUST HAVE A COMMAND
In multi-stage Dockerfile, you have to be careful for what stages you run. Want to avoid having misteriously exit 0 errors in containers? Add a CMD at the end of the Dockerfile stage with some dummy command like CMD ["/bin/bash", "echo", "Command for stage X"] Any stage that has no command will exit without informing the user of what happened. This could cause some mysterious errors if you are getting up all containers and not overwritting the command of the ones that have none.
USE THE BUILDER STAGE PATTERN IN DOCKERFILES
Most of the time, some libraries that we install in a docker image are only used for the construction of our executables. Could we just not include in our final docker image? Docker images should be minimal As we saw in our previous post, docker images should be minimal for several reasons, but the aim is to reduce the cost of the transference of the docker image. The builder pattern By having a stage build the required files, we can create a slimmer docker image by using multi-stage builds. We can see a golang example that follows this pattern: