Page 2 of 51

Automatically switch node versions between projects

April 6, 2022 / jeroen / 0 Comments

At my day job we work with Node 12 for our projects, but I wanted to check out NuxtJS 3, which requires version 14 or 16. Once I updated npm, I found out me old projects no longer worked properly. Reinstalling node_modules didn’t solve the problem, and besided, I didn’t want to saddle up my colleagues with version incompatibilities I couldn’t detect myself. So, I looked into finding a solution. And found one!

With n you can switch easily between Node versions. To install:

npm install -g n
echo "export N_PREFIX=/home/jeroen/.local/n" >> ~/.bashrc
echo "export PATH=$N_PREFIX/bin:$PATH" >> ~/.bashrc

Don’t install it as root, that will make it much more annoying to work with.

Now it is easy to change between versions:

n 16
node -v
>> v16.13.1

n 14
node -v
>> v14.18.2

But still, you would have to remember which version is used in which project. That’s not fun at all, so that’s what avn was made for. I guess I’m not the only one who is annoyed by such things.

To install avn:

npm install -g avn avn-nvm avn-n
avn setup

That last command adds a line to ~/.bash_profile, which is ignored in my setup, so I had to move that line to ~/.bashrc :

echo '[[ -s "$HOME/.avn/bin/avn.sh" ]] && source "$HOME/.avn/bin/avn.sh" # load avn' >> ~/.bashrc

Now add a .node-version file to the root of your project (or in my case the root of all the projects of my boss):

echo "12.22.8" >> ~/projects/.node-version

I also did the same for my own project (with version 16), and now when I switch to any child folder of ~/projects I see this:

Mission accomplished!

Troubleshoot

While installing this to Macos, I ran into a bit of trouble:

If found this solution for it:

n 10.13.0 # Install node version 10.13.0 by n
rm -R ~/.avn
nvm exec 10.13.0 npm install -g avn avn-nvm avn-n  # Use installed version to install the packages
nvm exec 10.13.0 avn setup

This only works with already installed node versions. When I went to a directory with a node version that isn’t installed yet, I got this:

My current solution is to just install that version manually with n:

n 16.11.1

Mission accomplished again!

Rapidly firing myself in the foot with C pointers

October 25, 2021 / Rowan Rodrik

Now that I am dedicated to becoming a somewhat decent C programmer, I need to master pointers. Last week, I leveled up in my pointer usage by debugging a particularly nasty segfault. It took the help of gdb (the GNU Project Debugger) for me to notice that my segfault was accompanied by very weird values for some increment counters, while the pointer involved was a char* pointer, not a pointer to an int.

GDB

First, some notes on the GNU Project Debugger: it’s excellent! And … it’s easy to use. I have no idea why looong ago, when as a budding programmer I was trying to use it, I had so much trouble using it that it stuck into my memory as a very tough tool to use. Well, this is not the same brain anymore, so time to get rid of all these printf() statements everywhere (that I wouldn’t dare use in a programming language that I do have some fluency in, mind you!) [lines of shame: L45, L100, L101, L119 ].

With the help of gdb xjot-to-xml (and then, from within GDB, run < my-test-file.xjot), I noticed that some of the ints I used to track byte, line and column positiion had ridiculously high values for the input line, especially since I was pretty sure that my program crashed already on the first character.

In GDB, such things are easy to find out: you can very simply set a breakpoint anywhere:

break 109
run < tests/element-with-inline-content.xjot

Starting program: /home/bigsmoke/git/xjot/xjot-to-xml < tests/element-with-inline-content.xml
a
b

Breakpoint 1, _xjot_to_xml_with_buf (in_fd=537542260, out_fd=1852140901, buf=0x6c652d746f6f723c, buf_size=1024)
    at xjot_to_xml.c:109
109                 byte = ((char*)buf)[0];

From there, after hitting the breakpoint, I can check the content of the variable n that holds the number of bytes read by read() into buf.

print n

$1 = 130

So, the read() function had read 130 bytes into the buffer. Which makes sense, because element-with-inline-content.xjot was 128 characters, and the buffer, at 1024 bytes, is more than sufficient to hold it all.

But, then line_no and col_no variables:

(gdb) print line_no
$2 = 1702129263
(gdb) print col_no
$4 = 1092645999

It took me a while to realize that this must have been due to a buffer overrun. Finally, I noticed that I was feeding the address of the buf pointer to read() instead of the value of the pointer.

(I only just managed to fix it before Wiebe, out of curiosity to my C learning project, glanced at my code and immediately spotted the bug.)

The value of pointers

C is a typed language, but that doesn't mean that you cannot still very easily shoot yourself in the foot with types, and, this being C, it means that it's easiest to shoot yourself in the foot with the difference between pointers and non-pointers.

I initialized my buffer as a plain char array of size XJOT_TO_XML_BUFFER_SIZE_IN_BYTES. Then, the address of that array is passed to the _xjot_to_xml_with_buf() function. This function expects a buf parameter of type void*. (void* pointers can point to addresses of any type; I picked this “type”, because read() wants its buffer argument to be of that type.)

What went wrong is that I then took the address of void* buf, which is already a pointer. That is to say: the value of buf is the address of buffer which I passed to _xjot_to_xml_with_buf() from xjot_to_xml().

When I then took the address of the void* buf variable itself, and passed it to read(), read() started overwriting the memory in the stack starting at that address, thus garbling the values of line_no and col_no in the process.

The take-home message is: pointers are extremely useful, once you develop an intuition of what they're pointing at. Until that time, you must keep shooting yourself in the foot, because errors are, as Huberman says, the thing that triggers neuroplasticity.

WW challenge 1: learning better C by working on XJot

October 24, 2021 / Rowan Rodrik

Since the beginning of this month (October 2021), I become officially jobless, after 6 years at YTEC. That’s not so much of a problem for a software developer in 2021—especially one in the Dutch IT industry, where there has been an enormous shortage of skilled developers for years. However… I don’t (yet) want a new job as a software developer, because: in the programming food pyramid, I’m a mere scripter. That is, the language in which I’m most proficient are all very high-level languages: Python, PHP, XSLT, Bash, JavaScript, Ruby, C# (in order of decreasing (recency of) experience. I have never mastered a so-called systems language: C, C++, Rust.

Now, because of the circumstances in which YTEC and I decided to terminate the contract, I am entitled to government support until I find a new job. During my last job, I’ve learned a lot, but almost all I learned made me even more high-level and business-leaning than I already was. I’ve turned into some sort of automation & integration consultant / business analyst / project manager. And, yes, I’ve sharpened some of my code organization, automated testing skills as well. Plus I now know how to do proper monitoring. All very nice and dandy. But, what I’m still missing are ① hardcore, more low-level technical skills, as well as ② front-end, more UX-oriented skills. Only with some of those skills under my belt will I be able to do the jobs I really want to do—jobs that involve ① code that has to actually work efficient on the hardware level—i.e., code that doesn’t eat up all the hardware resources and suck your battery (or your “green” power net) empty; and I’m interested in making (website) application actually pleasant (and accessible!) to use.

If I start applying for something resembling my previous job, I will surely find something soon enough. However, first I am to capture these new skills, if I also wish to continue to grow my skill-level, my self-respect, as well as my earning (and thus tax paying) potential. Hence, the WW challenge. WW is the abbreviation for Wet Werkeloosheid, a type of welfare that Dutchies such as myself get when they temporarily are without job, provided that you were either ⓐ fired or ⓑ went away in “mutual understanding” (as I was). If ⓒ you simply quit, you don’t have the right to WW (but there are other fallbacks in the welfare state of the NL).

Anyways, every month, I have to provide the UWV—the governmental organization overseeing people in the WW—with evidence of my job-seeking activities. Since I decided that I want to deepen my knowledge instead of jumping right back into the pool of IT minions, I will set myself challenges that require the new skills I desire.

My first goal is to become more comfortable with the C programming language. I have some experience with C, but my skill level is rudimentary at best. My most recent attempt to become more fluent in C was that I participated in the 2020 Advent of Code challenge. I didn’t finish that attempt, because, really, I’m a bread programmer. Meaning: before or after a 8+-hour day at the office, I have very little desire to spend my free time doing even more programming. To stay sane (and steer clear of burnout), that time is much-needed for non-digital activities in social space, in nature, and by inhabiting my physical body.

So now I do have time and energy to learn some new skills that really require sustained focus over longer periods of time to acquire. On the systems programming language level, besides C, I’m also interested in familiarizing myself with C++ and Rust. And it is a well-known facts that C knowledge transfers very well to these two languages.

Okay, instead of doing silly Christmas puzzles, this time I’ve resumed my practice by writing an actual program in C that is useful to me: xjot-to-xml. It will be a utility to convert XJot documents to regular XML. XJot is an abbreviated notation for XML, to make it more pleasant to author XML documents—especially articles and books.

MQTT benchmark of HiveMQ, VerneMQ, Mosquitto and FlashMQ

August 23, 2021 / halfgaar

Watch this demoscene style benchmark of HiveMQ, VerneMQ, Mosquitto and FlashMQ:

Breaking amplifier fault current with relays and MOSFETs

July 24, 2021 / halfgaar

FlashMQ version 0.8.0

June 13, 2021 / halfgaar

Just released FlashMQ version 0.8.0, a multi-threaded (multi-core) lightweight MQTT server. The latest new feature is a native authentication plugin interface for easy implementation of custom authentication and authorization.

Gitlab ‘Your password expired. Please access GitLab from a web browser to update your password.’

June 3, 2021 / halfgaar

I just fixed a very obscure error in Gitlab of ‘Your password expired. Please access GitLab from a web browser to update your password.’ This error would appear during SSH operations, and in various log files in /var/log/gitlab. Also XHR requests to the server got that response.

Nowhere in the GUI was it visible that anything expired. It’s about a gitlab that linked to a Windows Active Directory.

It turned out that in Postgres table ‘users’, of hundreds of users, 5 had ‘password_expires_at’ set to somewhere in 2014. I guess in a recent update they started checking that field.

To fix it, I did:

sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -h /var/opt/gitlab/postgresql -d gitlabhq_production
update users set password_expires_at = null where password_expires_at is not null;

Introducing MQTT server FlashMQ version 0.5.0

March 20, 2021 / halfgaar

Introducing my the MQTT server that I’ve been working on, FlashMQ. I’m starting with test version 0.5.0. It’s ready for some testing and benchmarks, and of course development will continue.

Disable roaming profile for one user on a Samba domain controller

March 10, 2021 / halfgaar

Sometimes you want to mix users with and without a roaming profile. As found here, you can use Samba’s pdbedit to set the “Profile Path” to empty:

pdbedit -p= leo

Then view the results with:

pdbedit -L -v leo

I logged off the user, performed that change, renamed the directory on the server just in case, and then logged on again. It worked like a charm.

Exhaling on YouTube

June 18, 2020 / Rowan Rodrik

I’ve created a YouTube channel separate from my private account and branded it “BigSmoke”. The channel’s purpose is to breathe some fresh air into some online discussions that I follow(ed). Actually, the content is the sort of content that I used to want to put more of on BigSmoke, but which I now found to be better suited for long-form discussions than for laying down my views from some ivory tower.

The first three puffs of fresh air feature my brother Jorrit:

In the first puff, recorded shortly after he (and me too for the nth time) quit caffeine. The cue for me to want to do that podcast (and stop putting off this creative endeavor indefinitely) was when he told me that quitting caffeine took a heavier toll on his body and mind than did quitting smoking and drinking at the same time a few months earlier. I though that that was a great story to put into perspective that yes, caffeine really is a serious, addictive drug that can interfere not just with your dreams but actually with your dreaming!

Production-wise, the worst part of this first podcast is that my face is tiny, because I used Google Meet and neglected to install a browser extension to undo its limited layout support or to even just click my own face when I was talking.
The 2nd puff of fresh air centered around meaning. Without the caffeine in my system, I was having more trouble than usual to find the meaning in my “mostly for money” job that’s really doing nothing to make the world a better, more beautiful place. Also, my self-discipline had declined to a long-time, leaving too little time and energy around work-work for more creative meaningful endeavors (such as doing podcasts).

There was a bit of a production problem with my 2nd puff of fresh air. The one published is a re-iteration of the same discussion we had some days before that but for which I recorded an empty audio stream of my docking station’s unconnected microphone input instead of the audio stream of the laptop port in which my microphone was actually plugged in. At least I did find Jitsi, which allowed easier side-to-side video frames.
In the 3rd puff of fresh air, we zoom in on some topics that we brushed past in the 2nd without really touching. I talk about my pain and shame of being mostly just another cooperating cog in the machine that is wreaking planetary-scale havoc and that is grinding ecosystems all over the world out of existence. Jorrit’s focus is on the harm that’s done to human happiness by our culture (and also the “away with us” culture of which I’m sometimes a part). We try to make our visions on self-discipline collide, but we end up finding more agreement than we expect. Most of our disagreement turns out to be superficially bound to societal structures which we both would rather see transformed than preserved in their current sickly form.

We switched back to Google Meet for this 3rd recorded conversation, because the free Jitsi server we used was performing shakily that day.

BigSmoke