I love Visual Studio Code. I love the Windows Subsystem for Linux (WSL). Ever since I had to do Python development, I use the WSL for almost all of my non-.NET work: PHP, Python, Typescript/Node.js. That means running Visual Studio Code in Windows, but running the program in Linux. Up until now, I was missing one important feature: debugging support. Luckily, there’s an extension now. Previously, I had to “debug” by adding console.log statements everywhere. Needless to say, this is
There are many meetups and events about software development in Belgium, but they’re mainly located in and around bigger cities like Brussels, Antwerp and Ghent. This isn’t always practical for people in Bruges. Which is why we’ve started a group that will organize meetups and events in Bruges. Driving 40 minutes to an hour may not seem like a big deal to some. But doing so on a weekday, with a child that needs to be put to bed, makes
This post was written for the Scalyr blog . You can find the original here . Logs come in a variety of formats and are stored in multiple different locations. Getting insights from all of these logs isn’t a trivial task. Microsoft Log Parser is a tool that helps us extract such information easily, using a SQL-like syntax. It supports many different input and output formats. But it also has some limitations because of its age. Introducing Log Parser According
I recently had to provide some numbers on AWS Lambda cold starts. These aren’t readily available in the AWS console. In fact, I couldn’t find a way anywhere online. There are lots of articles about AWS Lambda cold starts, how to avoid them, but none on how to measure them (without code changes). Here’s at least one way you can list the amount and duration of your cold starts. What Is a Cold Start? AWS Lambda functions are (intended to
I’ve had a longtime theory that TODO comments in code don’t get fixed any time soon. To get some numbers on this, I set out to analyze a set of GitHub repositories. You can read how I researched the lifetime of TODO comments in my previous post. In this post, I’ll look at the numbers. I’ll also talk about some aspects lacking in my research and how I could address them in a next round. An Overview As previously mentioned,
I have had a theory for some time that TODO comments in code remain there (almost) forever. They serve to appease the conscience of the developer, but they mostly are forgotten. But I wanted to prove this with numbers. The Plan I needed a large source of code that I could analyze. And the largest source out there is GitHub. So the idea is quite simple: find TODO comments in GitHub repositories use git blame to find out how long
If you’ve been following this blog for some time, you know I develop software mostly using test-driven development AKA TDD. But while this mostly means unit tests, it shouldn’t be limited to only unit tests. At one of my current clients, we use AWS Lambda functions written in TypeScript. These are (usually) relatively small blocks of code that can be invoked by a HTTP call. The function has a very limited scope of what it can be used for, i.e.
This is 50/50 a real post and a service announcement. The short version is that I’ve removed Google Analytics from this site (and redstar.be, my legacy project blog for non-technical people). I’m also using Brave and DuckDuckGo now. Read on for the long version. Google Chrome For some time, I have felt fairly (but not alarmingly) uneasy with the amount of data Google collects by me using Chrome. I’m somewhere in the middle of the whole privacy debate: between “don’t
This may not be new to you, but I recently discovered another cool feature of Git. Rebasing with the autosquash option allows me to keep a clean log with minimal effort. I’ve written about interactive rebasing before. This makes it even easier. Interactive Rebasing You want to do an interactive rebase when you have a series of commits that need be squashed together or when you want to change the order. Let’s say you have the following commits: But then
I recently saw a tweet on my Twitter-feed about failures and how we should also share our failures, not just our successes. Everyone experiences failure, but if we don’t share them, new developers will feel it’s not OK to make mistakes. So here are some of my mistakes and what I learned from them. This is the respective tweet: Be sure to read the rest of the thread. It’s a good and short read. Updating the Production Database Too Early