Koodihommia

TODOs, FIXMEs, issue links, and hacks are terms in a codebase that get the blood boiling for some, but I am almost always glad when I see them nowadays. The terms have saved me from ghost chases more times than I want to know. My thoughts on the matter are best explained by this little tale. Let's imagine a dev team tasked with figuring out a way to transport a wolf, goat, and cabbage across a river. They have been contracted by a client expert in transport systems After a discussion with the domain specialists, the developers conclude that renting a boat for the river crossing is the way to go since it is the most cost-effective.  The transportation design is abstracted with an open-source library. Perfect! Such an easy job, right? Provided, of course, that the library API is decent. It turns out the library, although simple, could be better. It is imperative, stateful, and cumbersome—very outdated stuff. There are fortunately, only three public functions, init , load and moveToN...

Writing React Native code from nine to five for almost three years has led me to face some truly baffling bugs. So much so that I decided to write this memo that hopefully gives me a good chuckle in a decade or two. Do not interpret this list as a criticism against any mentioned libraries but rather an enumeration of funny remarks. I have uncovered plenty of others, but there is something about top-three lists, isn't there? 1. Serving static HTML So you want to render a static file from the device file system on Android? Not so fast - literally! There is a race condition in the RN WebView native implementation, so you must set the URL after the first render. https://github.com/react-native-webview/react-native-webview/issues/656#issuecomment-551312436 PS. there was also a bug where you must unmount the WebView on Android before back navigation! In our codebase, there are three variables suffixed with "hack" in the WebView wrapping file only 🥇 2. Transition animations Wou...

Almost half of any Finnish generation goes through a shared experience: the conscript army. An integral part of that experience is learning military slang, a set way people in the army talk. The stories told with said jargon often spread outside of the barracks. It is not uncommon to hear strangers bonding together over beers reminiscing and feeling nostalgic about freezing cold nights spent in tents. There is a similar phenomenon detectable among us coders. To be part of the coder tribe, there is at least one type of story that one must master. That is - of course - ranting about legacy codebases. "Can you believe how much of a mess the previous coders left? Hear, hear!" There is no better way to onboard a new team member than to blame some previous B-team for all the murky parts of the system at hand. This can be seen as harmless, a subject for a good  meme . Rarely do we hold real grudges against "the legacy folk" and can be the best of friends in a social gather...

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...

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

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...

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