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

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

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,

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

The snowflake VM I run my experiments on has a serious flaw. I can't remember what I have installed there. It is embarrassing as some essential services to me run there. As an enterprisey developer, my attention draws naturally towards IaC solutions for this particular memory issue. The code of the experimentations is in git, so why not the infra. Some would say it is a major overkill since we are talking literally about one domain running on the puniest DigitalOcean droplet. I say I have a weekend to spare on silly stuff. The easiest choice is to write some Terraform. Yet come to think of it, is it still an obvious pick in 2022? I've never written anything too complex with it but having heard so much backlash against Terraform language, is it time for something new? The answer turns out to be a yes. The IaC solution for me in 2022 is Pulumi. It has a catchy name, a base for a good dad joke for a Finn. Besides that, Pulumi has some attractive qualities to it. It is declarative

A recent programming puzzle from Wunderdog caught my interest for one simple reason: it had the word wave file in it. Music and audio-related technology is something close to my heart. Besides, I have not had a DIY project related to music in a while, so why not look into it. The conundrum is straightforward. A wave file contains morse code, and one must decode it to dash and dot letters. The choice of technology is free. A pragmatic developer would look into some popular audio processing library - in my case, something written in go - and write a simple program. I had something different in mind, though. I've recently read The Art of PostgreSQL book and done some exercises in more advanced Postgres features. Why not apply the lessons learned in morse code parsing? The outcome is Endeavour , a no-frills Python wrapper + some exotic SQL window functions. It is neither fast nor pretty, but it proves that analyzing waveform files with SQLite is possible.

If you ask a random Finnish web developer to detail the projects they have worked on, I bet YLE (Finnish public broadcasting company) comes up. If you further ask to rank the projects, it would likely score high. The devs I've talked to and the Yle talks I've listened to have convinced me that taking a gig in Yle is indeed one of the most remarkable things to do in Finland. I'm not sure, but I think a US developer might not see working for the PBS as their career highlight. As a taxpayer, especially working in IT, it is fantastic that Finnish talent works on major, often publicly funded, megaprojects. The digital services are made well, robustly, and rate among the world's best. The developers enjoy working in such places because that all-knowing mentor colleague is sitting next to you. There are few Twitters or other desirable "web-scale" projects available locally. Not incidentally, this means that the barrier of entry is high to get these jobs. The Finnish