-
How big should a Lambda function be?
One of the core engineering principles within PostNL is the use of AWS serverless. It brings many benefits like scalability and cost savings, but it also brings new challenges to the table. For Lambda functions one of these challenges is the size of a function: is it best to use many, small Lambda functions or is it better to have a few, large ones? This blog post will give you an (opinionated) view on this topic based on the experience of one of the development teams within PostNL. Hopefully, the given considerations can help you in how you approach using Lambda functions.
-
Thinking as an hacker: JWT JKU exploit
Don’t forget to put on your black hoodie, it’s time to hack! I recently did a presentation about looking at code from the perspective of a hacker and I thought it would be interesting to also share here. In my opinion developers can write better and more secure code when they put of their developer cap and put on the black hoodie of a hacker (metaphorically of course). To illustrate what I mean, I’ll be taking a look at a technique that most developers probably know: JWT.
-
Documenting Serverless (with C4)
What is more difficult than asking a developer to write tests for their code? It is writing documentation for it, because good code and clear tests should already be enough documentation. This might be true for monoliths or microservices, but not for serverless. With serverless the pieces of code are even smaller and logic is partially moved to infrastructure. In this post I’ll be giving my answer for the question: how do you get people to see the importance of documentation in a serverless landscape? The examples will be with AWS and its Lambda’s, but this could be applied to every serverless solution.
-
Kotlin learnings from Kotlin Dev Day 2022
On May 19th I visited the Kotlin Dev Day 2022, which is a yearly conference about Kotlin in the Netherlands. I recently started using Kotlin for my new job, so I was really curious about all the talks. Also, I never went to a conference, so I looked forward to it. In the end it was a really fun day and in this post I’ll share my biggest learnings of that day.
-
Why not to use unit tests (and use integration tests instead)
During the last few years, when I worked on different projects, I always ended up in the inevitable discussion: how should we test the code? Often I heard that unit tests are a must and they should cover most of the code and its flows. Maybe afterwards integration tests can be added, but they are complex to make, slow to set up and slow to run. So instead of setings those up, let’s write more unit tests instead. I think unit tests still serve their purpose, but there’s a lot of downsides to them in comparison to integration tests. I think unit tests are overrated and integration tests should be preferred. Of course there’s also E2E tests to test multiple services in a single test, but in this post I’ll stay within the boundaries of testing a single service and look at unit tests versus integration tests.
-
Kotlin deconstructed: threads and coroutines
Single threading is fun, but if you want go faster you’ll have to go with multiple threads. I already looked at this for Python and found out things aren’t that simple, you can read it here. This time I’ll be taking a look at Kotlin. Kotlin can be seen as an improved version of Java, which is also the case for multithreading. Kotlin introduces something totally new for asynchronous and non-blocking programming: coroutines. In this post I’ll be taking a look at the performance of coroutines in comparison to multithreading and of course the good, old single thread. I won’t be diving into the inner working of coroutines, this might be something for next time. The full source code can be found here. Ready, set, go!
-
Python Multithreading and Multiprocessing
During technical interviews for a job I have often been asked what multithreading is. I could often explain what it does, but explaining how it works was a different piece of cake. When doing Python I even found out there’s besides multithreading also multiprocessing, now I was completely lost. It took me some time to understand what made them different and also how and when to apply them. Still there’s much more to learn about it, but right now I think I understand the basics of it.
-
Thanks Docker
I was just minding my daily programming and all of a sudden the VPN I use for work didn’t work anymore. After a lot of rabbit-holing I found out that it was something which seemd completely unrelated: Docker. I’ll take you with my journey on finding out how I got there, hopefully it’s interesting and you can learn something from as I did.
-
How to handle things that suck
In IT (and life) it’s inevitable that you’ll encounter things that suck. This might be a process within the company, another person in the organization or it might even be the squeeky chair you sit on. So things sometimes suck and the easiest thing to do is complain, but this doesn’t solve the issue. But what else can you do? I often try to tackle them in three steps: change it, if that doesn’t work accept it and if that doesn’t work leave. I’m not a self help guru and I don’t want to go that way, but this method works for me. So maybe it also work for other people. In this post I’ll dive more into what the steps mean and how I apply them.
-
A random error message
I’ve been using Visual Studio Code for quite a while as an editor, but recently I got some random error message when I opened it from the command line. It wasn’t a clear error message and VSCode didn’t act weird, so I just ignored it for a while. But after some time it starting annoying me that I didn’t know why the error was there, I had to find out. In this post I’ll take you on my journey of finding out what the cause is of a random error message. Spoiler alert: it turned out to be a bit of a rabbit hole, so I didn’t get quite tot he bottom of it. Still I did find out a lot about the cause and learned a lot on the way.
-
Testing in Python
Testing is something which the more I program, the more I appreciate and learn about. Consequently this also leads to more discussions with teammates and other developers about what the best way is to write tests. I think having tests is almost always better than having no tests, even if they are just simple unit tests for only the happy flow. This still means you can write good tests and you can write better tests.
-
Kubectl cheatsheet
Recently I made a start with Kubernetes and I found out there’s a lot of commands available through the
kubectlCLI. It took me some time to search through the available commands and flags to find the ones that helped me. I combined them in a cheatsheet, so this saves me (and maybe you) also some time in searching through the manual. -
To GitOps or not?
GitOps is something which I’ve heard of, but I didn’t fully understand the added value. Similar with DevOps being more than Dev and Ops being in one team, there is more to GitOps than listening to a Git repo for deployments. Before I dived into GitOps I didn’t fully understand how it worked and what the advantages are over a single CI/CD pipeline. In this blog I’ll be tackling my questions about GitOps and find out whether it will be the new standard for CD.
-
LINECTF2021 Atelier: python-gadgets
Recently I did the LINECTF2021, which had the pwn challenge Atelier. During the challenge I had an idea where to go with the exploit, but didn’t manage to find it during the CTF. After the CTF I looked at two write-ups and played around with them. How these exploits worked were really interesting to me as a Python developer and thus I decided to write this post about it. First I’ll give some background information about another exploit type, ROP chains. This at first doesn’t seem that relevant, since the challenge was written in Python, where such an exploit is not possible. But later on it becomes clear why this type of exploit is still relevant.
-
One layer deeper
Although I have not been a programmer for a long time, I have found out being to go ‘one layer deeper’ when programming helped me a lot. Being able to do this, really made the difference for me in whether I was able to find an issue and solve it. Looking around I can clearly see that people who are able to do this, are the ones who really understand how things work and leverage this power to do cool things. In this post I’m going to talk a bit more about what I mean with ‘going one layer deeper’ and give five tools of my toolbet which help me to do this.
-
HTTP1 Request Smuggling
With more and more techniques being built on top of others, it’s getting more difficult for a developer to understand what is actually happening when he writes some code. On top of this the DevOps movement is progressing, where a developer is also supposed to know something about the infrastructure the code runs on. I think for a developer knowing how things work under the hood is not always necessary, but it helps choose better solutions and decreases the amount of mistakes made.
-
Shells
Every day that I program I use the shell and I think most of the developers use it daily. Still often it’s not something which is talked about during education or conferences. This is kind of weird, because from my experience a shell is something that can boost your productivity by a lot. For me the shell is something which I slowly gain knowledge on and acts as a Swiss Army Knife to get many things done on my computer. In this post I’m going to show some of the things which boosts my daily productivity by using a shell.
-
Piping and redirecting in shell
Almost daily I have used
<,>and|in my Linux shell to get things working, but I never understood exactly what they did. By diving into them I have learned how they work and also learned some new tricks with them. -
Book review: The Unicorn Project
The last time I did a book review was probably some time ago, I guess in highschool, but it might be fun to do another one. Although I still enjoy reading literature like George Orwells 1986, I also read books related to IT. The Unicorn Project is in its core also an IT book. The thing which makes this book interesting, is that it’s not a book with only pure theory. The book actually contains a story via which it tries to teach you things, which made me really enjoy this book. Although The Unicorn Project has a precessor called ‘The Phoenix Project’, the first one named is more relevent for me. The Phoenix Project is written from the perspective of IT operations within a big organization, while The Unicorn Project is from the perspective of developers. Still, the Phoenix Project is interesting to read and even as a developer there are things you can learn from it.