You push (or better, merge) to master, and the deployment happens automagically. No further work required. That's the promise of GitHub-Actions (GHA), and probably every other CI service provider.

However, things are not as shiny as they seem at first glance. There are many problems with the approach that GHA and co. use. Some are addressable by more disciplined usage behavior[^1], but others are not.

The first time, I've heard of Raku was maybe a year ago. I was too busy to look into it though. I've done that now and BOY OH BOY, do I like this language.

When you want to cross compile Rust programs, you have two options: You either use cross, or you do it manually. The first approach is easier, but only until you run into problems. I want to talk about the problems and corresponding solutions that you might encounter with the second approach.

Most of the code software engineers write is pretty mundane, which is good. Simple code is easier to read, to maintain, and has less bugs. However, sometimes we write code that feels super cool, and makes us want to show it off to our peers. Well, at least for me that's the case. And this is precisely what this post is about: a cool piece of code, that made me smile, and that I want to share with other people that might appreciate it too.

My first programming language was C++ and for a long time, I was using Visual Studio Express in Windows. When I had to debug something, I would click on the line number to set a breakpoint and press F5. Maybe I'd add some variables to the watch window, and press some F-keys a couple of times. Recently, I switched jobs and I'm now mostly developing firmware in C. Since I switched to using Linux and Vim ~7 years ago, I needed to update my debugging workflow. I actually didn't find a neat tutorial that covers the whole picture, so I figured I could write one myself.

That title is obviously click bait. However, it is also true, at least for me, as I wrote Markdown Note (MDN) because I was not satisfied with any existing solution. It allows you to write notes in Markdown, with any editor you prefer, and display them in the Browser. It also has some bibliographic features.

Jupyter Notebooks are hugely popular. In this post I'll give an introduction into what they are, why I would actually not recommend using them, and what I do instead.

Recenty I've been asked whether I could teach Python to a fellow PhD student and said yes. My plan was not to invest too much time into this, and just assemble a list of resources to read, and a few practice tasks. However, by now two more people have asked whether they could join, so I decided to gather everything in one place and this place is here.

I love playing Pathfinder. And I've tried many different ways to manage my character sheets. You can do it by hand, use an Excel-sheet or use one of the many available programs to do it for you. The problem with the programs is that even if they actually contain everything, you get into trouble if you want to use custom items or house rules. This is obviously no problem if you do it by hand but that is honestly kinda complex and it is very hard to make no mistakes. Lately, I've been writing one in markdown, and thought to myself: "If you could combine the possibilities from markdown and Excel, that would be very nice."

Currently, I am learning Clojure reading the great (and free) book [Clojure for the brave and true]. In chapter 5, the game Peg-Thing is implemented. I thought this would be a good opportunity to compare Python and Clojure. I reimplemented the game in Python two times. First in the 'normal' Python way and a second time in a way that seemed to me like the ideal functional implementation in Python.

A few days ago, I read an article: How to code basic psychological experiments with Python by Mathias Gatti. It advertises PsychoPy, which is a python library to create psychological paradigms, which is really just a fancy name for what is basically a very simple mini game that will usually measure reaction times or the like. In his post, he walks the reader through the code necessary for a very simple paradigm that consist of only 2 screens, the first one says "press any key to continue", and once you do, you are taken to the second screen which says "press [ n ] to continue" and "press [ q ] to exit". It will then measure your reaction time and take you back to the beginning if you press n or exit and save the results to a csv-file if you press q.

In this post I will implement exactly the same paradigm but using PyParadigm, which is a library for paradigm creation that I wrote. The advantage that I want to demonstrate is that it requires much less code to write paradigms with PyParadigm than with PsychoPy, therefore you can work more quickly. Also, less code means less bugs.

What I do at my job is called "Multi Voxel Pattern Analysis" (MVPA). It involves applying classification algorithms to functional MRI (fMRI) data, i.e. recorded brain-activity, to predict some parameter or a behavior. The classification algorithm of choice in most studies is the Support Vector Machine (SVM). The reason for this is that commonly we only have small samples (usually $$10 \leq n \leq 300$$ ) while the number of features tends to be large (all voxels within multiple volumes, which sums up to ~120000 and more potential features) and SVMs are supposedly good at dealing with small samples and large numbers of features. The accuracies we reach are pretty low most of the time. High enough to yield significant p-values, but not in a useful range to do any predictions. Also fMRI images are quite noisy and a lot of times a positive result becomes insignificant when evaluating it with previously unseen data. This generally made me a little suspicious as to how well an SVM can deal with these difficulties.

Recently I was writing the following code:

processing_frame = \
     sl_results[sl_results.c == coi][["subscript", "kappa"]].rename(
        columns={"kappa": "value"})

Another piece of code that might look familiar to the habituated pandas user is:

my_frame[(my_frame.col1 == a) & (my_frame.col2 == b) & (my_frame.col3 < c)]

Typing this kind of stuff is annoying, and it triggers me every time I write something like this. Ideally, this would look more like:

my_frame[col1 == a and col2 == b and col3 < c]

which is not supported by the python syntax. What can be done, however, is the following:

Select("subscript, kappa as value").Where(f"c == {coi}")(sl_results)

There already is a myriad of blog posts on functional programming, with this post, I don't try to give an introduction to it, but I want to highlight, how we can get inspirations from it, to improve our code. This is why the post is called "functionalish" programming, instead of "functional" programming.