Koodihommia

In a previous blog post, I took a look at how to enumerate all the syscalls and even their arguments using tools such as  eBPF . That left me pondering and craving to learn more about how memory is mapped and what do simple variables look like in the memory. What is behind all those memory addresses you can see in the stack traces? I do have an intuitive sense of that. Sure, I have seen blog posts and talks about the topic, taken a look at heap dumps in a hunt for memory leaks but I wonder does it make any sense to look at the memory in a language/runtime agnostic manner. Probably not, but hey, could be exciting. To find out, I created a simple program that simply prints out the contents of a few variables  I try to make the outputs depend on the runtime environment to avoid any unexpected compiler optimizations. I want to make sure the memory will be allocated at runtime. I run the code in my trusty Digitalocean VM with "no hang-up" and attach the GNU Project debugger (GDB) ...

 I built a simple MIDI looper with the Teensy 3.2 development board  It's a simple device. It has two MIDI inputs, one serving as a THRU port, mostly for forwarding sync messages to the connected device. The other input port is for connecting the instrument. The output port binds the loop for sending and receiving notes. The first version soldered to a stripboard. The left and center MIDI connectors are the inputs connected to the Teensy (header pins visible) through  an optocoupler circuit Teensy is the perfect fit for this kind of project, mostly due to its tiny dimensions. It works with the same development setup as Arduino, and virtually all libraries that work with Arduino work with Teensy. It even includes a MIDI library, which came in handy. The code is trivial; the gist is that we read the input tempo, start and stop messages from the THRU port and merge the tempo message with incoming note data. The note data quantizes to the nearest 8th sync message. Up to date...

Besides the object geometry information, IFC files may contain properties for the IFC objects. The properties can be, for example, some predefined dimension information such as an object volume or a choice of material. Some of the properties are predefined in the IFC standards, but custom ones can be added. IFC files can be massive and resource-intensive to process, so in some cases, it helps to separate the object properties from the geometry data. IfcOpenShell  is a toolset for processing IFC files. It is written mostly in C++ but also provides a Python interface. To read an IFC file >>> ifc_file = ifcopenshell.open("model.ifc") Fetch all objects of type IfcSlab >>> slab = ifc_file.by_type("IfcSlab")[1] Get the list of properties >>> slab.IsDefinedBy (#145075=IfcRelDefinesByType('2_fok0__fAcBZmMlQcYwie',#1,$,$,(#27,#59),#145074), #145140=IfcRelDefinesByProperties('3U2LyORgXC2f_hWf6I16C1',#1,$,$,(#27,#59),#145141), #145142...

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