DEV Community: Christian Baer

Band Audition during a pandemic

Christian Baer — Mon, 04 Oct 2021 14:57:17 +0000

Problem

As many many people we as a band faced issues with the Corona pandemic. Since this is a hobby project for all of us and we did not even had a gig yet, the problem is much smaller for us than for professional or semi professional bands. But still, we faced the situation, that we could no longer meet in our rehearsal room and make music together, which we usually quite enjoy. Also we were on track on getting our first songs together for playing small gigs on stage in 2020.

We are a band of 5 people with 3 of us working in IT, so we pretty early set out to find a solution to our problem.

Disclaimer

We briefly discussed, meeting anyway, as we were pretty sure, no one would be prosecuting us. Everyone was kind of relieved, that no one really wanted to opt for this path. This proved to be the first "Corona character test" for all of us, I guess.

Solution

What we wanted

An easy to use solution for all of us (vocals, guitar, guitar, drums, bass) to make music together online.

The solution had to be easy to use, because (as said earlier) we are 3 out of 5 working in IT and driving around giving IT support and installing everything was out of the question. Everybody had to be able to do the setup with minimal to no help.

First ideas

Skype
discord
...

All of these platforms match the easy-to-use criteria, but are not good for playing together and there is a simple reason: latency.

Latency

Playing together means, that everybody has to listen to everybody else. Even the drummer! So if the signal needs 300ms to travel from dummer to everybody else, everybody reacts to that and it then needs another 300ms to travel back to the drummer, rehearsing is not going to work.
So, latency is a key factor in music.
But the major platforms for online communication use 'high' latency for a reason. This way, background noises, feedback, echo and stuff like that can be filtered much easier and synchronizing all participants gets possible. Also ~300ms is fine for meetings and 1:1 talks. Just not for music.

There had to be another way. We couldn't probably be the first ones looking into this.

Possible Softwares

We weren't. There are plenty of softwares, that promise you online distributed rehearsal, instrument teaching, recording and jamming. A few that pop up early in any online search are Ninjam (complex), JamKazam (closed source), Bandlab (commercial), eJamming (register first on website), Jamulus (FOSS, but seemed very basic)

Our Hardware

Since we already talked about latency, let's not forget, that the internet is not the only thing to add latency. Computer Hardware does too. It's not 300ms, but a few ms here and there add up and you are out of sync.
Our bassist had a setup using a Scarlett Focusrite 2i2 and somehow managed to get this with ALSA

So our Journey began :-)

Mid March

After having a look over various possible solutions (and grabbing our gear from our rehearsal room) we opted for JamKazam. JamKazam has a central server, that the people behind JamKazam fully own. Which was fine for us, as we got the idea, that this was not easy and better left to people who know their stuff.
Features:

Configure Audio input with gear latency measurement
Text chat
Audio chat
- nice for communication between songs
Video Chat
- Seeing each other is nice!
Set volume and balance for each participating musician
- really handy to have distribute instruments to left and right
- adjust volume of everybody to your needs (tune out singer 😉)
Insert audio track file
- This would be the key killer feature, but we didn't know that at first

It seemed to offer all we needed and was easy enough to use. If only that was the whole truth.

To test JamKazam the 3 IT guys registered, and tried to start a session. Keep in mind, this was the beginning of the restrictions and it seemed musicians from all over the world were trying to find solutions and lots of them tried to start a session with the very same tool. With some frustration we gave up and met again a week later to try again. This time it kind worked for us 3. Latency was around 40 to 60ms. We could work with that!

Our drummer did not even get to register through the Client software, as no connection to the server could be established. We figured, through various screen sharing session via Skype and even VNC, that his router was configured very strictly. Not necessarily a bad thing, but he lost his admin password. So we had to start without him.

April

Being short of a drummer, we were glad about the audio track, as all our songs are well written down using GuitarPro. Exporting the drum tracks as wav file was easy and so rehearsal could start.

If it wasn't for latency again 🙈. This time from our singer. His situation at that point was a WiFi bridge and a rather shitty ISP. So latency was between 300 and 1200ms. We kind of tuned him out...

It was not much, but we still had some hope, that this would all be over soon.

May

It was not over soon...

To solve at least the WiFi bridge problem, we bought a long CAT-6 network cable. This had to go through the garden into the main house. He lives in a the renovated garage, so they even dug up the ground and buried the cable. So latency was better. Still not perfect, but better most of the times.
We were still lacking a drummer, but we could not do anything about that.

June

Not much rehearsing going on. We had more important things to do. Hard to believe, but getting married was more important for on of our guitarists (groom) and the bassist (best man).

July through September/October

Since we live and rehearse in Berlin, we got to see each other again over the summer on our rehearsal room. We once again had a drummer!

November

Covid struck again. The anticipated 2nd wave was there and we were once again at home. One major thing improved compared to spring:
Our drummer did reset his router and was able to register.

Unfortunately, connecting his e-drum set to a computer proved to be a challenge. So we were back with JamKazam, no drummer and a slightly lacking vocalist. But even that improved, as he switched ISPs.

Unfortunately, JamKazam got worse with every update and updates came weekly.

Some of us had to reconfigure the audio setup each week and the chat microfon of our guitarist and bassist was not usable anymore.

Nevertheless we carried on, using discord in parallel for chatting.

Lesson learned: Mute your discord mic, or your band colleagues will hear your "unplugged" sound next to your real sound, with some latency.

December

Drummer finally joins, JamKazam gets worse

JamKazam still did not get much better, but our drummer geared up and was able to join us in our weekly sessions. We had live drums. Oh the glory and joy. Ask his neighbours. Turns out, even an e-drum can make too much noise.

Now that we finally felt, we had a more or less stable solution at hand, an announcement from JamKazam came in. Beginning in 2021 they will start charging money for using JamKazam. We looked at the plans they offered. Between the 4 plans free, silver ($4.99/month and person), gold ($9.99/month and person) and platinum ($19.99/month and person) the gold option would have been the one to continue the way we rehearsed through the year.

As I said, we are 3 people working in IT and two of us are software developers. So paying for software is fine. As long as it is worth it. Since not all of us got through the pandemic without losing jobs/income we even would be able to distribute the 50$ among the others. Paying for a service is really not the problem. Paying 50$ for a service that got worse every time on the other hand, was not in our interest.

The Search for another tool

So it was time to revisit the list of alternatives. If only we had saved that list somewhere. So back to zero and search the internet once again.

Online search was faster this time, because we had a better idea of what we were looking for and the tool of our choosing was Jamulus.

Features and perks:

Configure Audio input
- more basic than JamKazam, but still good enough
Set volume and balance for each participating musician
Overall Latency measurement
- ping to server
- overall latency
Multiple open servers available
Text chat
Configure buffer size
- So you can decide what is more important quality or speed.
FOSS (GPL 2.0)
- Repo

Audio chat is a missing feature, but since we had to work around that before, it wasn't a big issue. Also uploading a wav file and playing it to everyone does not work, but our drummer has joined the online party so, this was also not a big issue.

Testing on a public server

Public servers are public. So anyone can join. For a quick test this was fine, as there are empty servers out there, if you are lucky. Along the way some people joined, but we quickly muted them and as soon as they got, that we were not trying to jam with strangers on the internet, we could try this out.

Unfortunately the connection of our bassist was so bad, Jamulus seemed to be unusable. The issue was already visible with JamKazam, but got worse with Jamulus. Best guess: Jamulus server did more compression because of slow internet connection.

Private server and a faster connection

Switching ISPs did the trick again. Ping and bandwith improved massively for our bassist and we had our last rehearsal with JamKazam on 29th of December. After that we had to have a new solution.

So we decided against one of us hosting this at home, configuring port forwarding, sharing his current IP address with the band, and everybody connecting after copying the address in the to Jamulus client. It should be easy to use 😉. Only other solution was to rent a server. Since renting real hardware in some data center is expensive (we were kind of on a 50$/€ budget), we decided to try out a vServer, which are very cheap compared to bare metal servers. Having a budget of 50€ meant we could choose from a variety of providers and basically all plans. To not jeopardize the mission by being cheap, we opted for a 4 core vServer with 8GB RAM from 1&1/ionos for 16€/month. Turns out, these are some Intel Xeon Gold 5120 CPUs working there and it is of course a vmware machine.

Installing Jamulus

Installing Jamulus is actually pretty easy, if you are familiar with linux and/or docker. You can install this directly to the system or just start up a docker container. Since starting up a docker container is fairly easy, I tested this. It also comes with a nice docker-compose file. The result was a little bit astonishing. Connecting to my server was easy enough after configuring the 1&1 firewall to open port 22124 and there it said overall latency 60ms with 25ms on my behalf (network plus hardware latency). Not bad!
Reading through the documentation of how to run your own server and the Linux how-to page, I decided to opt for a low-latency-kernel. Result: 50ms! Down 10ms.

First real band rehearsal with Jamulus and private server

Although the Jamulus wiki clearly states "Close every application, that deals with sound or internet!", we met at discord and Jamulus and started playing. Worked like a charm.

The vServer is vastly oversized. I had htop open the whole time and the load average did not even make it over 0.5 and not even 600MB RAM were used. So we might scale down to half the size, which will reduce costs by half.

Lessons learned

Jamming, rehearsing event teaching instruments is possible.
Good internet connection is a must have
Quality gear makes your life easier
Do not give up!
It is still much more fun in person

One assert per test - What is that about?

Christian Baer — Wed, 16 May 2018 15:23:25 +0000

A colleague outside my team asked me and other colleagues to review a merge request. Although we try to hone our reviewing skills, it doesn't happen all too often that we invite colleagues outside of our specific teams to review. This was one of the cases and I appreciated the opportunity to give my two cents.

I was in the middle of my review when the colleague came by and asked for a first impression. I had looked briefly into the sources so my answer was brief as well: "I don't like your unit tests". When he inquired further why I didn't like them my answer was "Because they are shit." I know it sounds harsh - I am not a mean person, but I'm blunt and tend to exaggerate. Thankfully my colleague knows that and we agreed to talk again when I've had enough time to figure out why I didn't like the tests.

I sat down and took some time to figure out what bothered me and I want to share it with you.

More Than One Assert Per Test

One thing that was clear to me when I looked at the code, was the use of more that one assert per unit test. I'm not a fan of rules without reason so I had to have a closer look to make sure that it wasn't gut feeling. This is a broadly discussed topic, but I want to add my two cents.

One reason that seems to come up every time the internet discusses this topic is:

You won't see if there is something wrong with the second assert if the first one fails.

See here

Although the argument is true, I find it to be weak and tend not to use it. I don't consider it a problem.
I have a different gripe with it, and I've drawn two examples that I want to share with you to illustrate.
For privacy and brevity I simplified the tests, but let the essence intact.

public void testIfRegistryGetsValuesCorrectly() {
  Registry a = new Registry();
  // Imagine some setup code here.
  // originally there was a before-each method

  assertThat(a.getEntryByKey("RandOMstRIng"), equals(a.getEntryByKey("randomstring")));
  assertThat(a.getEntryByKey("   rand   oms.tri ng"), equals(a.getEntryByKey("randomstring")));
  assertThat(a.getEntryByKey("randomst37ring"), equals(a.getEntryByKey("randomstring")));
}

The test works fine and meets the requirements. Cut out all non-characters of the key and make it lowercase before you ask for the value. Everything seems fine.
The problem becomes clear when you touch the tested method and break the 'testIfRegistryGetsValuesCorrectly' test.

As a developer working on the implementation, you're not going to find out what doesn't work any more. At least not at first sight.
You will understand that the test broke, this is what the name tells you.

I suggested refactoring the test to the below code.

public void testIfRegistryIgnoresCases() {
  Registry a = new Registry();
  // Imagine some setup code here.
  // originally there was a before-each method

  assertThat(a.getEntryByKey("RandOMstRIng"), equals(a.getEntryByKey("randomstring")));
}

public void testIfRegistryIgnoresNonCharacters() {
  Registry a = new Registry();
  // Imagine some setup code here.
  // originally there was a before-each method

  assertThat(a.getEntryByKey(" 3  ra8nd   oms.tri ng"), equals(a.getEntryByKey("randomstring")));
}

With these changes in place, you will understand the problematic behavior with a quick glance.
Dots are now allowed? You know what to do:

You broke one well defined test
You fix the test according to new requirements
You rename the test

Explicit Naming

Before continuing I'd like to present a second example to illustrate. Mind you: I simplified the tests, but let the essence intact.

public void testConstructorOneWorksCorrectly() {
  SpecialObjectClass a = new SpecialObjectClass("someID", "attribute1", "attribute2");

  assertThat(a.getID(), equals("someID"));
  assertThat(a.getFirstAttribute(), equals("attribute1"));
  assertThat(a.getSecondAttribute(), equals("attribute2"));

}

public void testConstructorTwoWorksCorrectly() {
  SpecialObjectClass a = new SpecialObjectClass("someID", "attribute1:attribute2");

  assertThat(a.getID(), equals("someID"));
  assertThat(a.getFirstAttribute(), equals("attribute1"));
  assertThat(a.getSecondAttribute(), equals("attribute2"));
}

public void testConstructorTwoWorksCorrectlyWithoutSecondParameter() {
  SpecialObjectClass b = new SpecialObjectClass("someID", "attribute1");

  assertThat(b.getID(), equals("someID"));
  assertThat(b.getFirstAttribute(), equals("attribute1"));
  assertThat(b.getSecondAttribute(), equals("attribute1"));

}

The problem with the above example is similar, but not as obvious. The complex logic lies in the second and optional third parameter. The ID parameter ("someID") is trivial and distracts more than it helps in each of the test cases. If something breaks in the handling of the ID parameter the three unit tests will break for the same reason.

I have two problems with that:

It violates the idea behind a unit test, which is to test single isolated units
It confuses the poor developer changing the tested code in the future. (Who could also be the author itself after a couple of months)

I suggested to refactor to the following form:

public void testConstructorSetsID() {
  SpecialObjectClass a = new SpecialObjectClass("someID", "attribute1", "attribute2");

  assertThat(a.getID(), equals("someID"));
}

public void testConstructorSetsBothAttributes() {
  SpecialObjectClass a = new SpecialObjectClass("someID", "attribute1", "attribute2");

  assertThat(a.getFirstAttribute(), equals("attribute1"));
  assertThat(a.getSecondAttribute(), equals("attribute2"));
}

public void testConstructorTwoSplitsAttributesAtTheColon() {
  SpecialObjectClass a = new SpecialObjectClass("someID", "attribute1:attribute2");

  assertThat(a.getFirstAttribute(), equals("attribute1"));
  assertThat(a.getSecondAttribute(), equals("attribute2"));
}

public void testConstructorTwoSetsSecondAttributeSameValueAsTheFirstIfNotGiven() {
  SpecialObjectClass b = new SpecialObjectClass("someID", "attribute1");

  assertThat(b.getFirstAttribute(), equals("attribute1"));
  assertThat(b.getSecondAttribute(), equals("attribute1"));

}

My naming here may not be perfect, but it gets the point across. And as you may have noticed, the one word that was present in all the unit tests is now gone: "Correctly"

This was my small epiphany.
As a word, "Correctly" should never be part of a test case's name. It does not provide any information at all.

Having found out my two gripes with the tests, I came up with a pattern for myself:

test case with multiple assertions -> look out for this dangerous word ("Correctly") and change test case accordingly
dangerous word in the title -> look at the assertions to figure out what this test does and change the name

That was my learning of the day: There are words that should not be part of any test case's name, and it's: "Correctly".

There might be more. Look out for them!

P.S.: The colleague that I spoke of in this article, was asked to proofread the article. Besides helping a lot with proper English, he also added a thought of his own. "As developers we often think about naming, and sometimes we seem to miss the most obvious points - or we tend to become lazy."

Cooking: A Perfect Hobby for Programmers

Christian Baer — Mon, 25 Dec 2017 10:23:44 +0000

Everybody needs a hobby. It takes your mind off of work and can help you develop your creativity or just relax to get creative again. Side projects are fine, but then again it is programming and this is what you are doing all day anyway. Here are some reasons why I think cooking is a great hobby for programmers.

The most important reason is not specific to programmers:

You get food!

The basic idea of cooking is, to make/prepare your own food, which is a very fine thing. Of course, there are the days when we just want to eat and order something delivered to our homes, have some takeaway or eat that microwave stuff. That is ok, but nothing beats self-prepared food. You know exactly what you put in and will enjoy the meal because you put effort into it. It just tastes a little bit better.
Let us move on to the more programmer specific reasons:

A recipe is an algorithm.

Follow it and you will get exactly what the author intended. Make a mistake and it might be edible (just a little bit burned) or you can throw that whole thing away (you used salt instead of sugar). Didn’t we all forget those semicolons at the beginning? Didn’t we all at some point wrote something like if (i = 1) and wondered for hours why the code did not work as the textbook said? We all got past that and learned to avoid those mistakes. You will eventually learn to cut your vegetables all beforehand and not ‘on the fly’. Which takes me to the next reason:

There is so much you can learn.

Part of being a programmer/software developer is the continuously learning. This is one of the reasons why I like being a programmer. I learn something new every day and I can utilize my knowledge. The same thing happens when you cook. You look at different recipes and learn from them. If you find some good books (or web pages) where there is an explanation not only about the what to do but also on why you are doing this, you can learn all the more. You get to understand why a little bit of citric acid let your apples stay fresh and keeps them from getting brown. As you begin to understand more and more you can go on to the experimenting. This would be the next very good reason:

You can tinker around with recipes.

As I mentioned earlier, recipes are algorithms. So why not change them and see what happens. This is best done alone. When you are cooking for your family holiday dinner, (much like fixing bugs in the live environment) you better stick to the plan! In other scenarios experimenting is great. Again, at the start, it is much like when you started coding. Start with some small improvements. You got no lemons in the house but limes? See what happens, when you switch it! The recipe states an amount of sugar? Go for the dark honey and see what it does!
My last point:

You are able to share your findings.

It is not like there is a GitHub for cooking, but there are other sites. Go into the comments of recipes and share your small changes. Share your traditional family recipes with the world (you know, the famous cookies from grandma, the world needs to know) and get feedback.

I think the idea is why cooking is a great hobby is clear. You prepare your own food, you can follow algorithms, get creative over time and share your experiences. Basically, everything programmers like without touching a keyboard.

Don't let programmers alone

Christian Baer — Wed, 04 Oct 2017 16:25:00 +0000

Recently I discovered a small piece of code that looked like this:

function isElementSpecial(htmlElementToBeChecked) {
  var result
  if(document.querySelector(htmlElementToBeChecked).classList.contains('special')) {
    result = true
  } else {
    result = false
  }
  return result
}

I cringed.
My first thought after my initial shock was: 'What on earth was this developer thinking while writing this?' I had to look at this a couple of times to make sure that the above code really only does one thing. Checking that an HTML element has the class special.
Since I had no time to investigate the how and why this code came to life, I did what every programmer would have done and quickly condensed the code to its essential core.

function isElementSpecial(htmlElementToBeChecked) {
  return document.querySelector(htmlElementToBeChecked).classList.contains('special')
}

Since I know whom amongst my colleagues did write this code, I was tempted to ask him straight away why he was writing a simple check in such a complicated manner. Luckily he had already gone home. So I had some minutes to think about what went wrong.
Some facts

The code is from our front-end test system
The responsible colleague is a senior programmer with some experience in that field
He built our testing framework on top of CasperJS by himself
He has his hands full with keeping our front-end tests stable

Look at point 3. He built this by himself!
There was no one to review, question or criticize his code.
In my opinion, this could have been prevented by someone reviewing his changes in regular and short intervals.
We as programmers build complex (and often large) systems. Having a complete in-depth knowledge of all lines of code is impossible, even if one single person wrote them all. Consequently, it is only natural to forget about that one line or method you wanted to refactor or rewrite. Also, there is a higher risk of getting attached to your code. Why this is a bad idea is excellently explained here.
There are only two methods known to me to reduce all of this. The first one is pair programming and the second one is code reviews. If for whatever reason pair programming is not an option (e.g. distributed team), that leaves only code review.
There are many good 'manuals' for the dos and don'ts of good code reviews (e.g. This).
At my workplace, we do team code review, although most of our code is done while pairing. Every morning we ask ourselves 'do we have something to show the team' and then the projector is turned on and we have a good half an hour of looking at code diffs and asking questions. This often enough reveals useless comments, ambiguous variable/method names and other code styling issues. We also have a general idea of the code that our team produces and our bus factor is increased drastically.
In short: Do code reviews and do them often. There is a high chance of making your code understandable, increasing the bus factor and reducing the attachment to the code.

Hi, I'm Christian

Christian Baer — Thu, 30 Mar 2017 09:17:03 +0000

I have been coding for about 10 years.

You can find me on GitHub as donut87

I live in Berlin.

I mostly program in these languages: Java.

I am currently learning more about Clean Code.

Nice to meet you.