Posts

This is the time for me to start looking for a new position. The first thing to do when you start this process, is to update your CV and resume. Although a lot of people (including myself until recently) think that these are two identical documents, in reality they are not. Resume is a short (max 3 pages) concise summary of your experience and achievements that show how you fit the future position. HR people screen tons of documents everyday, and they want to know if a person fits the position from the first glance. In CV, you describe your experience in details, mentioning all the projects that you have participated in, your contributions, what technologies have been used, etc. Moreover, if you have an academic experience, you list there all your publications and academic achievements. As a result, your CV could be quite long especially if you have huge experience, a lot of publications or both. Thus, if you have been chosen the interviewers may understand your experience in details.

Still, both these documents may share the same sections like education and working experience. In order to follow the DRY (don’t repeat yourself) principle and unify the style of my CV and resume, this time I have made them using the same LaTeX template called moderncv. In this article, I explain how I maintain these two documents together and list the modifications that I have made.

Until recently, I used tmux occasionally, only if I had to run some experiments on a remote server and later see the results of the execution. Basically, I used it only as a mean to execute commands in the background. If I needed to run several commands on a remote server parallelly, I used to open several terminals, connect each of them to the remote host and then switch between them.

Recently, I started working with a remote server through ssh more often and the routine, I used to, became very operation consuming. So, to improve my effectiveness, I spend several hours reading articles, watching videos and trainings how to use tmux. This article combines the knowledge I have acquired. It is also a crib for me if I forget something in the future.

Several weeks ago during a compilation process, I noticed that my laptop became very hot under my palms. At first, I did not pay any attention to this, however, when it became uncomfortable to work I started to worry. My first thought was that the laptop got dusted and cannot remove the heat effectively. But then I noticed that I did not hear the fan noise when the load on the CPU increases, and I decided that my cooler is either broken or blocked. I was almost about to start disassembling my laptop, but luckily I decided to check the temperature using Linux utilities. There I found out that, despite I feel the laptop being hot, the sensor [thinkpad-isa-0000 -> temp1] showed that the CPU temperature was normal (showing all the time the temperature of 45°C). This looked suspicious, and I checked other sensors measurements and found out that the [coretemp-isa-0000] sensors showed more correct temperature values, which in addition reacted on load increase. In this article, I want to describe, how I forced my system to react also on the values from these additional sensors and cooled down my laptop.

Currently besides all other activities, I am developing a habit of programming following Test Driven Development (TDD) methodology. This is a perfect time because I continue to explore Rust, a new programming language to me. Moreover, this language encourages you to cultivate this best practice by providing great documentation and well-thought ecosystem.

In our programs, we often face with exceptional situations (e.g., lack of space when you try to write a file, or absence of a resource), and we need to handle them. If you follow the TDD approach, you need to ensure that these exceptional situations are also properly covered in your tests. Id est, you have to develop tests that reproduce these exceptional situations and make sure that your code detect and handle them correctly. In this post, I want to discuss how to test exceptional situations in Rust.