fix: small typos

cloud/content/posts/FizzBuzz.md

@@ -1,10 +1,10 @@
 ---
 title: "FizzBuzz, the simplest, more efficient way to test a developer"
-date: 2022-05-16T22:49:13+02:00
+date: 2024-05-16T22:49:13+02:00
 draft: false
 ---
 
-When I got out of my engineering school, I passed a lot of interviews in the hope of getting a developer job. My experiences being limited to having done a few internships, I was fearing the part of the interview where I would have had to get up and resolve some complex algorithm exercice on a white board, or even just answer a few technical questions. I was wrong.
+When I got out of my engineering school, I passed a lot of interviews in the hope of getting a developer job. My experiences being limited to having done a few internships, I was fearing the part of the interview where I would have had to get up and resolve some complex algorithm exercise on a white board, or even just answer a few technical questions. I was wrong.
 
 **Not a single interview tested me on my development skills.**
 
@@ -20,11 +20,11 @@ That's when the <strong>FizzBuzz</strong> test comes into play.
 
 The idea behind FizzBuzz is straight-forward. You need to count out loud numbers starting at 1 until you reach 100. But, if the number is a multiple of 3, you have to say the word "Fizz" instead. In the same way, if the number is a multiple of 5, you have to say the word "Buzz". Now you might be thinking: "Then what am I supposed to do when it is a multiple of both 3 and 5?". Well, you would simply have to say "FizzBuzz". <em>Roll credits</em>.
 
-By reading this simple test, you might wonder why this should be used, as it appears that even an intern could solve it quite easily. Well, that's what I thought too, until I ran accros [Jeff Atwood's post on this subject](https://blog.codinghorror.com/why-cant-programmers-program/), stating that he was surprised how this problem actually gave a lot of troubles to candidates, even senior ones.
+By reading this simple test, you might wonder why this should be used, as it appears that even an intern could solve it quite easily. Well, that's what I thought too, until I ran across [Jeff Atwood's post on this subject](https://blog.codinghorror.com/why-cant-programmers-program/), stating that he was surprised how this problem actually gave a lot of troubles to candidates, even senior ones.
 
 <strong>So let's try to solve it together!</strong>
 
-<em>In most technical interviews and as such for this exercice, you are free to use any programming language you feel most confortable with, or even write using [pseudocode](https://en.wikipedia.org/wiki/Pseudocode). For this post, I'm gonna use Python.</em>
+<em>In most technical interviews and as such for this exercise, you are free to use any programming language you feel most comfortable with, or even write using [pseudocode](https://en.wikipedia.org/wiki/Pseudocode). For this post, I'm gonna use Python.</em>
 
 First things first, let's create a simple loop that prints all numbers from 1 to 100.
 
@@ -79,7 +79,7 @@ for i in range(1, 101):
     print(result or i)
 ```
 
-It's already much clearer! Not only did we shrink the number of lines by half, our `if` checks are now cristal clear and don't let any rooms for misinterpretation. Plus, we can easily change the value of any of the numbers if we need to without having to look for all its occurrences. Last but not least, if we ever need to add yet another condition for multiples of 7, we'll simply have to add two new lines without changing the rest of the code!
+It's already much clearer! Not only did we shrink the number of lines by half, our `if` checks are now crystal clear and don't let any rooms for misinterpretation. Plus, we can easily change the value of any of the numbers if we need to without having to look for all its occurrences. Last but not least, if we ever need to add yet another condition for multiples of 7, we'll simply have to add two new lines without changing the rest of the code!
 
 We can finally see how this simple FizzBuzz test is so interesting. We were able to test one's ability to use simple algorithmic principles, but also to check his way of thinking when being confronted to a problem, and if he is able to produce a code that takes care of its future.
 

cloud/content/posts/Postman pre-request script, never worry about refreshing your access token.md

@@ -1,6 +1,6 @@
 ---
 title: "Postman pre-request script, never worry about refreshing your access token"
-date: 2022-05-16T22:49:13+02:00
+date: 2023-05-16T22:49:13+02:00
 draft: false
 ---
 
@@ -54,7 +54,7 @@ pm.sendRequest({
             }
         ]
     }
-}, (err, res) => {
+}, (err, res) => {
     pm.collectionVariables.set("access_token", res.json().access_token)
 });
 ```

cloud/content/posts/The Rubber Duck Debugging.md

@@ -4,9 +4,9 @@ date: 2022-05-16T22:49:13+02:00
 draft: false
 ---
 
-<strong>Programmation is a painful art.</strong> You are a real architect and you mission is to design, build, decorate and maintain an application, much like how you would do for a house.
+<strong>Programming is a painful art.</strong> You are a real architect and you mission is to design, build, decorate and maintain an application, much like how you would do for a house.
 
-One difficulty emerges though: <strong>you have to communicate information with a machine through programming languages to make everything work.</strong> Surely you don't talk to your furnitures to place them into your house, right? <em>Right?</em>
+One difficulty emerges though: <strong>you have to communicate information with a machine through programming languages to make everything work.</strong> Surely you don't talk to your furniture to place them into your house, right? <em>Right?</em>
 
 This little difference is crucial, as you sometimes will encounter an issue that you have no idea why it is there. Truly you developed this thing so perfectly that it should not fail. But here we are, a bug is there and you don't know why.
 
@@ -28,11 +28,11 @@ Once you get your hands on one and place it on your desk, the only thing left is
 
 I'd rather tell about it right now so you don't end up shocked when confronted with the truth, but the duck will not respond to you. Hearth-breaking, I know. However, <strong>he is the perfect listener and his patience is way above any other human being</strong> unlike your co-workers. Moreover, the duck will never judge your mistakes. He is kind and comprehensive.
 
-And the more you will explain to him your troubles, the more you'll realise what was wrong all along in your code. Indeed, trying to explain properly to the duck what you are trying to do will expose a tiny inconsistency between what you did and what you are trying to achieve. Slowly but surely, you will soon enough be able to pinpoint the exact line of code that was causing all your troubles and fix it like the pro you are.
+And the more you will explain to him your troubles, the more you'll realize what was wrong all along in your code. Indeed, trying to explain properly to the duck what you are trying to do will expose a tiny inconsistency between what you did and what you are trying to achieve. Slowly but surely, you will soon enough be able to pinpoint the exact line of code that was causing all your troubles and fix it like the pro you are.
 
-And that's why the duck is so useful. Not only did you let your coworkers work in peace, this exercice forces you to take a step back at your code so that you can explain it to someone who has no clue of what's going on.
+And that's why the duck is so useful. Not only did you let your coworkers work in peace, this exercise forces you to take a step back at your code so that you can explain it to someone who has no clue of what's going on.
 
-This effort to put words on the expected behaviour and what you were able to achieve for now will highlight any potential mistakes you might have made during the development, things that can't be seen when you spent eight hours looking at your code non-stop.
+This effort to put words on the expected behavior and what you were able to achieve for now will highlight any potential mistakes you might have made during the development, things that can't be seen when you spent eight hours looking at your code non-stop.
 
 > In describing what the code is supposed to do and observing what it actually does, any incongruity between these two becomes apparent. <cite> [Stephen J. Baker](https://www.sjbaker.org/humor/cardboard_dog.html)</cite>