Koodihommia

I describe how I build the Zynthian Raspberry Pi OS synthesizer from a kit in a previous blog post . It sits mostly idle connected to my sound card, so I decided to make it a bit more useful while it is idling. The first goal was to make it play Radio Helsinki, one of my most played online radio stations. That's simple enough; I just created a systemd service which connects to the stream using mplayer. Note that I'm using jackaudio as an audio "sink." The synthesizer is thus perfectly playable, even if I am listening to something else meanwhile. I get soon bored listening to only one channel. The next step is then to add Spotify. There is a pre-made debian package called raspotify , but alas, the bundled librespot Spotify client does not work with the jackaudio backend. I decided that the most comfortable choice is to compile librespot in the Raspberry Pi and then create a systemd service (after all, that is pretty much all raspotify does). The Spotify client service

At the moment, I'm working in an organization where almost 80% of the Slack messages are direct messages. We have a low threshold on contacting others - in private. While it is obviously good to share information the method is not the best. I don't need to enumerate the drawbacks of DMs compared to messages sent to public channels. The most obvious ones to me are the increase of tribal knowledge and the further reduction of us into separate silos (devs, marketing, sales, etc...). We recognize that most of the DMs are casual conversation. Yet, these contain information gold nuggets and ideas which should be shared with everyone. We have a couple of ways how we are to stop direct messaging If someone DMs you, actively move the conversation to a suitable public channel. No need to be polite in this. Use more threads in public channels (yes, this is a bit controversial) Have channels for hobbies and chit-chat

Here is a conceptual monopipeline for building and deploying a React native app to the app stores in Bitrise. The described pipeline serves us well, and I discuss the benefits and tradeoffs in the afterword. Setting up .env and release method The first step is for the CI machinery to overwrite or add relevant environment variables based on the branch/tag. You can already at this point determine if this pipeline will release the app to the stores or just run through the build. Run linters and tests, check test coverage For TS/JS, these can be just npm scripts in the Bitrise npm step. For native code, you can use the predefined steps or run some Gradle tasks. Prefer one-liners: avoid writing complicated initialization commands. npm run lint, npm run test:coverage... Set release versions You could simply use the git tag here for the version. You could also use automatic semver and tools such as commitizen to version the build. For private builds, X.Y.BUILD_NUMBER is enough. There is a Bit

We often debate with my friends on the topic of saving money. For one couple I know, they have made being frugal their dearest hobby. They have made hunting for offers an art form, and the tiny amount of money they spend on essentials beggars belief. I truly admire their commitment, but I often pull my trump card and tell them that they most likely will buy the more expensive house of the two excellent options at one point in their lives. All that effort is nullified by a single choice made later on. It is hard to intuitively say what is expensive. I like making arbitrary financial comparisons between two things. One of my favorites is what I call the terrace bias. Let's say you want a terrace. It costs 4000e. It will bring joy in the summer evenings, have some BBQ and bask in the sun. For the money, you could also reserve a nice restaurant for two every two weeks for 2 years. Or even better, you could always choose the most expensive ice cream for the rest of your life. Or buy the

 I have to confess, I'm a lousy solderer, my hands tremble, and I'm often too anxious to get the job done and leave bad joints. To make the job easier, I used on my latest project some external flux (sigh... I know, should have used it always).  A 1 to 4 MIDI splitter. Soldering pen on the left I decided to try out a flux pen. It seemed to be less messy than rosin. I was unsure would it be as effective, though. Well, it was pretty good. It is easy to apply, and I could smear it on the PCB rather accurately. After administering the stuff, I learned that one must be relatively quick to do the actual soldering; it seems to vaporize quickly and lose some effectiveness.

In my ongoing quest to understand more how GNU Linux works under the hood, I took upon myself a courageous assignment to figure out what a simple go program does from a kernel's point of view - which syscalls are called and what data is passed down there Here is the program So a simple hello world, which prints out the famous words and creates an empty file. To figure out which syscalls are triggered, I decided to use trace-cmd package. It is a frontend to ftrace which helps for example in filtering out the syscalls related to a single binary or a PID. After some intense googling, watching a couple of youtube videos , and fiddling around, I ran this command. sudo trace-cmd record -p function_graph --max-graph-depth 3 -e syscalls -g do_syscall_64 -F ./gohello It records a list of kernel functions practically in the order they are called with max depth and some filtering. It shows only syscalls and not, for example, system interrupts that clutter the output and are not in this exer

Every so often, I get fooled by the scary-looking rising memory graphs on my puny minimum sized VM running on Digital Ocean. The same thing seems to happen to my colleagues and I have to go into this discussion on memory usage on virtual machines and on work laptops. I'm not an expert on the topic but I have gathered here a couple of things to demystify the issue. The first question I ask myself or a fellow developer is: what do you mean by running out of memory? You are most likely talking about memory pressure, right? What are the symptoms? Is it just a gut feeling or is there some verifiable performance degradation? After that, we could talk about a few seemingly counter-intuitive topics The "raw" memory usage should be high. Especially on a busy VM, it is good that frequently used files are mapped to memory. The OS does not know when it is out of memory. The Linux kernel allocates memory until it can't. You probably should have swap on Before one goes digging into