Koodihommia

I bought or technically leased a Canyon Precede:ON 7 (2022) electric bike last fall. This post is about my experiences with it after riding for about 2000 km this winter. The season was a bit colder than usual, and we had more snow than in years, so I properly put the bike through its paces. I've been cycling for almost 20 years. I've never owned a car nor used public transport regularly. I pedal all distances below 30km in all seasons. Besides commuting, I've mountain biked and raced BMX, and I still actively ride my road bike during the spring and summer months. I've owned a handful of bikes and kept them until their frames failed. Buying new bikes or gear has not been a major part of my hobby, and frankly, I'm quite sceptical about the benefits of updating bikes or gear frequently. I've never owned an E-bike before, but I've rented one a couple of times. The bike arrived in a hilariously large box. I suppose there's no need to worry about damage durin

Django-allauth got SAMLv2 support last August. It has been and continues to be an exceptionally complete package for all authentication-related things. SAML in 2024? Sure, it is OAuth or something more modern you would usually want, but as we all know, we only sometimes have that choice. In this post, I will explore how to integrate customer users into a SaaS product using SAML. The official documentation covers the installation part. It also has an example of configuring it in the settings file. Alternatively, the settings can be stored in the DB. Often, SAML is used to integrate all users (and roles) from specific organizations. So, if a customer, say, Acme, wants to start using our SaaS product, all their user information often uses the same integration. In this case, Acme wants to use SAML. Let's slap the configuration to the DB. Here is a screenshot of an example config, viewed through the Django admin. Their identity provider could be anything, and I have filled in the setti

It was a year of wrapping up a major project I've been working on for several years. Nothing is, of course, ever truly finished in software, so "fully released" is maybe a better choice of words. In 2023, I was also part of starting a new, presumably soon-to-be megaproject. This led to me switching jobs. See this tweet My new employer is an early-stage startup. I have never been on one, so I wanted to know what that is like. We are a close-knit team, quite different from the 100+ member projects I began my career with. Before fully committing to the new one, I juggled two jobs for six months. I was a (primarily) mobile developer by day and transformed into a web developer by night (actually, I did most of the coding on weekends). My first assignment was related to setting up the frontend, which I ended up doing with NextJS + Tailwind + shadcn/ui combo.  My working days have changed dramatically. Earlier in the year, I worked on a reasonably stable and mature organization

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