Skip to main content

Posts

GH auto-rebase complaint

GitHub, you serve us well, but please allow me a tiny complaint about the rebase flow. First, some context. In a trunk-based, linear history rebase development workflow (aka tl;dr), we do primarily smallish PRs. The project has two active developers, and we consistently accomplish a handful of PRs daily. The review takes priority. Usually, an initial review is ready, and related fixes are implemented in less than an hour. Unfortunately, our CI is slow, and we typically don't have its status available once the human part of the review is complete. GH has added the auto-merge (or auto-rebase) feature. It presumably works best in merge flows and is only nearly as good for the linear history rebase workflow. Unfortunately, we can't set multiple PRs to auto-rebase and expect GitHub to handle it automagically. Our branch protection rules require that source branches must be up-to-date before rebasing to main. Once any PR is rebased, the following ones are not up to date with the targ
Recent posts

Wundernut vol. 12 coding challenge

Stable diffusion magic created with DreamStudio This autumn, the Wunderdog Wundernut programming puzzle includes figuring out why the repository has a sand-colored PNG and which Harry Potter character to submit on a form. My submission to the previous puzzle was not very high-brow. I'm not saying my solution to the new one is more elegant, but at least I think I used a proper (read boring) tool. On the upside, I got to learn a new cipher type (affine) and use an OCR library for the first time ever! https://github.com/jjylik/wd-notrot13

Calling fork in a go program

I recently read the popular post about Redis architecture . It had a chapter about forking - the process of how they create a disk backup of the in-memory database contents. The chapter addresses some same system programming topics as the linux-insides book I've been glancing over recently. As the article points out, the POSIX fork system call creates a duplicate of the calling process but does not copy the memory pages. If the parent or any child process access a memory page, it points to the read-only shared memory until the process changes any values of that page. The calling process then gets a writable copy of the accessed memory pages (copy-on-write). DALL·E 2 did not know how to draw a go gopher but close enough! Only single-threaded applications support fork , but I still decided to try it out on a go app. Go runtime does not support fork due to go programs being multithreaded and other reasons I don't even try to understand. There is a ForkExec call in the standa

radiohelsinki-to-spotify summer project

I haven't soldered, reset any ESP32 chips, nor tinkered with breadboards this summer (yet). Instead, I wrote something spartan for my personal use. A simple tool to create Spotify playlists from Radio Helsinki programs. There is not too much to write home or blog about. I keep doing these small projects to keep the golang-fu up. I spent the most time researching stuff around what I needed to do, for example, how to create session cookies in go with the plain old standard library. If you want to create Spotify playlists from Radio Helsinki programs, visit this scary-looking URL  https://radiohelsinki-to-spotify.apps.jompanakumpana.fi/ Repo:  https://github.com/jjylik/radiohelsinki-to-spotify

I'm not a passionate developer

A family friend of mine is an airlane pilot. A dream job for most, right? As a child, I certainly thought so. Now that I can have grown-up talks with him, I have discovered a more accurate description of his profession. He says that the truth about the job is that it is boring. To me, that is not that surprising. Airplanes are cool and all, but when you are in the middle of the Atlantic sitting next to the colleague you have been talking to past five years, how stimulating can that be? When he says the job is boring, it is not a bad kind of boring. It is a very specific boring. The "boring" you would want as a passenger. Uneventful.  Yet, he loves his job. According to him, an experienced pilot is most pleased when each and every tiny thing in the flight plan - goes according to plan. Passengers in the cabin of an expert pilot sit in the comfort of not even noticing who is flying. As someone employed in a field where being boring is not exactly in high demand, this sounds pro

I used to clean computers from viruses

Back in 2005-2006, when my friends were playing WoW, I got hooked on something much weirder. Some contemporaries may remember those as the start of their MMORPG careers. For me, those were the heydays of (anti) malware. It all started as I installed the first antivirus software on our family PC, and oh boy did it find a lot of stuff. Perhaps it was that incident that triggered my fascination with viruses and malware. It cannot be overstated how bad the malware situation was back then. Every home PC had some adware/spyware installed. XP was riddled with holes. Virus scanners were falling behind the latest threats. I began to read everything I could find about viruses. I lurked obsessively in Wilders' security forums and SANS internet storm center, which were the hubs for security-related news back in the day. Unsurprisingly, corporate security was not my focus point as a 15-year-old. I was solely interested in malware. Can't really remember was there something specific about it,

I'm often wrong

Developers should read Ralph Waldo Emerson. By read, I mean listen to a 30-minute podcast and claim expertise. Emerson says being too opinionated is harmful. The cliche in tech is that the view from the window of kosher technologies shifts quickly. The result is that I've been mostly wrong about any given technical issue in my career. I'm not saying this to be unpretentious but rather a fact.  Given I'm wrong and write poor code at a given moment is not to be interpreted that something is left permanently broken. The great thing about having loose opinions is that I'm always open to implementing a better solution. It may still ultimately be sub-par but better than the original. Ralph Waldo Emerson says that we should not imitate others. That may not end up as a quote in a programming book, though. No one likes a genius, and a clever thinker can be an insult in a coding context. Seeing something you have seen thousands of times in your editor is usually desirable. Widen