In a query filtering a boolean field named deactivated I wondered why deactivated <> 1 does not yield the same results as (deactivated IS NULL OR deactivated=0). I found that the MariaDB syntax involving booleans is very crude: deactivated IS NOT true does the correct thing, while the = and <> operators can lead to unexpected results. Not very intuitive.
Yes, I know. 2022 vs. Drupal 7 and HTML mails: yikes. Sometimes you can't decide.
I need to send messages as HTML mails programmatically. I already use mime mail, previewable e-mail templates, and smtp. First of all, I found that it is necessary to configure the "Plain text body" in the templates in order to have e-mails sent out via a transactional e-mail provider. I don't understand why, because it works fine locally on mailhog without (plain text message is automatically created), but anyways. This link https://www.drupal.org/docs/7/modules/mime-mail/theming-html-mail-sent-through-mime-mail describes how to customize the e-mail template: mimemail-message.tpl.php should be copied to the used theme folder. However, the description kind of misses the point in where to exactly place it. It took me a while to find out which theme was exactly used (in my case the seven theme, which is used for the backend). The next hurdle was the mail.css: I couldn't really figure out from where mime mail would pull the CSS from, so I included all CSS needed into the e-mail template (which is necessary anyway, because e-mail programs apparently need that inline). Any change to the template file needs a cache clear to get effective.
I got access to an Azure database via SQL login. However, the login is restricted to the IP addresses of the live servers and I want to access it from my computer at home from varying IP addresses. My approach was to tunnel the connection through ssh exampleserver -L 1433:example.database.windows.net:1433 However, when establishing a connection to 127.0.0.1:1433, I got the error A connection was successfully established with the server, but then an error occurred during the pre-login handshake. I use the MSSQL client of VS Code. The issue was, that the server certificate does not match the connection URL, which had to be 127.0.0.1 due to the tunneling. In order to trick this unwanted validation, I found out the IP of the database server (example.database.windows.net) and set up the tunnel using the IP instead of the domain. Then I added 127.0.0.1 example.database.windows.net to the hosts file and connected with the domain name. This approach worked for me.
I tried to go further and set "trustServerCertificate": true as described here https://github.com/microsoft/vscode-mssql/issues/1806, but that didn't work for me. Editing the settings.json turned out to be tricky, because the password needs to be entered each time before saving. Otherwise, it seems to get erased by VS Code, causing the next login error. Setting the trustServerCertificate option consistently caused login errors.
Postgres is nice and flexible in many ways, but when it comes to converting numbers to a format other than the US-American one, it can be a bit stubborn. For a direct SQL CSV export, I need the numbers in the format 999.999.999,99 instead of the standard 999,999,999.99. I tried to cast the numeric to monetary, which got ignored, even after setting the locale SET LC_MONETARY='de_DE.utf8';. I assume the docker container I'm using for Postgres does not have the German locale installed and I do not want to create such a configuration dependency on the target system of the customer, so that's not a way to go. The generic way to deal with this is the to_char() function, but that comes with decimal and thousands separators which are again hard-wired with the locale. I couldn't find a way to change the separators as it would be possible in Oracle. I ended up with the following ugly workaround:
CREATE OR REPLACE FUNCTION format_bcs_money(input numeric)
RETURNS char AS $$
SELECT REPLACE(REPLACE(REPLACE(to_char(ROUND(input/100, 2), 'FM999G999G990D00'), '.', 'P'), ',', '.'), 'P', ',');
$$
LANGUAGE SQL;
I use Linux (Ubuntu 20) on a X390 Thinkpad. And I have tons of meetings every day, Teams, Zoom, Webex, you name them. All of them have the same problem: They only provide basic functionality on Linux, which does not (really) include to blur the background or if the function is available (Zoom) it creates an insane CPU load. Since I'm too lazy to physically clean up the mess which is shown behind my desk (I'm not looking at it anyway, so what's the point?) I was looking for a geek way to solve the issue. I looked for a way to virtually clean up my room behind my desk. The idea is to create a virtual webcam device blurring the background of the real webcam input, which can be used by any of the conferencing software.
My first approaches included Fakecam (https://snapcraft.io/fakecam) and related scripts. However, they are all dependent on Tensorflow, which requires CUDA, which kind of requires an NVIDIA GPU. My notebook has an Intel graphics card, though, so the whole Tensorflow-CUDA stuff creates a CPU load of over 600%, rendering this approach pretty much useless.
However, I found an alternative here: https://github.com/fangfufu/Linux-Fake-Background-Webcam This approach uses the Mediapipe framework to process the selfie video, which is more efficient if only the CPU is used. The setup of v4l2loopback works as described in the Readme, however, the virtual video device created might not be /dev/video2. In my case it was /dev/video4, which is important when calling fake.py. It needs the virtual device with the -v parameter if it is different from video2. Compared to Fakecam, it has a very handy on-demand feature, which only starts the webcam once a client asks for the output of the fake webcam device. I checked the output using Cheese and found the following settings working for me:
Blur:
python3 fake.py -v /dev/video4 -W 640 -H 480 --no-background --no-foreground --background-blur 30 --background-blur-sigma-frac 5
The aspect ratio implicitly crops the webcam video, such that it doesn't show too much unnecessary background. The no-background and no-foreground settings remove the standard behavior of the script which adds images instead of blurring. The background-blur and -sigma-frac options showed the best background blur effect for me, while still keeping my head from being blurred. Blurring uses roughly 150-250% CPU.
With background instead of blurring:
python3 fake.py -v /dev/video4 -W 640 -H 480 -b background.jpg --no-foreground
The CPU load with a fixed background is roughly 150%. For Teams, the background appears horizontally mirrored. However, it is mirrored again on the client side.