So Much To Know...

I once spent an inordinate amount of time with a friend of mine, who I consider to be a master of recording & sound engineering.  He has been at it for decades, paid his dues, and worked with some greats.  He executes his craft with the utmost care and caring... (something I have come to realize is what separates the true pros from the learned hacks). Anyway, I remember watching him in do his thing in the studio as I assumed the role of a quiet observer.  Despite his obvious adeptness and ingenuity, he would always play the part of the  Absent-Minded Professor, as opposed to the James Bond smooth-operator type.  I think it was partly a schtick to make people feel more at ease, but there was a genuineness and willingness to be vulnerable, as though allowing himself to be human probably made the job less fatiguing.   I distinctly remember my favorite phrase of his.  On a couple of occasions, while turning knobs and fixing some problem, in a wonderous voice he would declare, "so much to know..." 

It's stuck with me because it's true about so many things, no matter how much of a master of your craft you are - there is always more to know.  So much more.  I've worked in IT and done various software development for about 30 years now, and yet that's been the theme for me lately - as I try to wrap my head around newer (to me) concepts such as containerization, full stack application development, and more.  I should have started learning these things about 10 years ago, so I have to play catch up.  But it's enough to make me feel old. 

Anyway, follow along as I may post some perspectives on (but not limited to) the following concepts, as I learn them:

• React/Mongoose/MongoDB
• Python/Flask/PyMongo
• Docker
• Kubernetes Clusters, K3S for high availability scalability, management thereof
• Tying all this together: MicroSaaS development and deployment

RANT TIME: Why do replies to a message I sent go to my spam folder?

Despite what one would think/hope, sending a message to a given address does not inherently give Google a high confidence that a reply from this address is expected (and, for example, that it should bypass spam checks). I have confirmed with Google's tech support that there is no way to automatically have this happen. The user can do the following:

1. Add the address to your contacts list in Gmail.

2. Check spam folder for replies, and mark it as "not spam" if something ends up there, which should influence the fate of future replies received. I can also approve an address at the domain level, i.e. if it is a big vendor or similar. I've had to do this with several of our Chinese vendors. I regularly ask engineering and purchasing to give me a list of the supplies we deal with, so I can approve them as a preventative measure.

For what it's worth, all of the false positive instances of reply -> spam we have experienced have involved the sender's email server having a problem. In the most recent case, it appears that the sender IP address appears on at least two internet blacklists. Since that is beyond my control, but we are trying to do business with these people, I can only add the domain to the approved senders list so that future replies from them should bypass the checks. However, if another company with a problematic email server replies to one of us, their message could very well still end up being marked spam.

Since Google can't help us, I am trying to figure out some kind of human process to defend against this, but to getting to a 0% false positive rate looks kind of ugly.  One idea I had is to make a script that is invoked when a user sends a message, and somehow adds the recipient address  to their contacts and/or some sort of approved sender list. 

Has anyone done this?

Windows 10: Get rid of Microsoft Teams Auto Startup (from a script)

Situation:

You have installed Microsoft Office on your computer.  Whenever you logon to the computer, you see a Microsoft Teams splash that asks you to login, which you have to close every time if you choose not to login.

Possible remedy:

You can go into task manager, click the "Startup" tab, click Microsoft Teams, right-click and disable.  However, this doesn't work permanently as it will come back if you update or reinstall Office.  Also, other users who login to the computer will still get the Microsoft Teams thingy loading automatically at startup.

"Real" fix:

Add this to a user logon script, such as your domain logon script*:

REM Delete Microsoft Teams Auto startup reg key 

reg delete HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v "com.squirrel.Teams.Teams" /f

That second bit is all supposed to be on one line.

*if you don't have a domain logon script, you can just put this in a .bat file and stick into 

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Now every time someone logs in, the Teams startup will be automatically removed, so that will be the last time they see it.

Scammers can bypass your Google Workspace Safety Checks

A major source of headache for system administrators these days, and has been for some time, is the uptick in phishing messages that fake the sender address so it appears to be from someone within your organization. If you are like me, this is one of the things that keeps you awake at night. Organizations using Google Workspace can take advantage of a safety feature that purports to prevent this from reaching users. You can access its settings from within the admin console under Apps->Gmail->Settings->Safety.

Unfortunately, there are still a ton of legit e-mail servers that don't authenticate, so that safety feature is not going to be very helpful.  However you can enable the checks that detect someone trying to send a message with an employee's e-mail address, your domain (or a variation on it) or even an employee's name.  These are very common attacks, and such checks regularly prevent nefarious messages from reaching our end users.  

The problem is, due to a poorly-planned filter architecture on Google's part, this whole mechanism can be bypassed, allowing a spoofed message to end up in a spam queue that is managed by an end-user.  

Google Workspace Filter Architecture places spam filters and queues ahead of "safety features" such as spoof checks.

As you can see in the diagram above, the spoof checks are effectively circumvented when they are sent to a group.  A moderator will see the message in the group's spam queue, AKA "Pending messages".  If they approve the message, it will then go through the safety checks, but by then the group manager has already seen it, and may act on it.

Cordova-plugin-ble-central without BACKGROUND_LOCATION permission

Happy New Year.

I have been developing a Cordova app on Android that uses Bluetooth Low Energy (BLE).  To accomplish this, I have been using Don Coleman's cordova-plugin-ble-central.  This is a neat plugin with a pretty simple API that lets you do serial communications over BLE. It is compatible with both Android AND iOS.  It's installable with NPM, but I recommend you get it directly from his Github.  The one on NPM seems to be broken on newer Android devices.  The issue  is that Google now requires ACCESS_FINE_LOCATION permission if you are using bluetooth, and the one on NPM is older and hasn't been updated to request this permission.  But that's not really what this post is about.

My app is essentially a remote control for a light.   All I am trying to do is communicate over bluetooth when the app is in the foreground.  However, the Don Coleman plugin demands the BACKGROUND_LOCATION permission (presumably this would be required if I was trying to continue to send/receive data notifications while the app is in the background).  The problem is that this permission comes with some fairly hefty declaration requirements if you are trying to get your app into the Play Store.  For example, you have to make a video demonstrating the feature in your app that makes use of this functionality.  As I stated earlier, I have no such feature so it will be impossible for me to get my app to pass review.  

The only solution I could see was to fork Don's plugin and remove the BACKGROUND_LOCATION permission.  So far it seems to work.  If you have a similar problem, perhaps you can benefit from this version of the plugin as well.  A couple of things:

1. In case it doesn't go without saying, if your app is in the background, you will not be able to do Bluetooth communication using this version of the plugin.
2. I have only made changes to the Android side. I don't know if the iOS side still somehow requests BACKGROUND_LOCATION permission.  If it does, I will ultimately need to address that as well since my app is going to be available for both platforms.

So here it is: High Tech Harmony's cordova-plugin-ble-central without BACKGROUND_LOCATION

To use it, go to your Cordova build folder of your project and do the following:

(only if you have Don's plugin already)
cordova plugin remove cordova-plugin-ble-central 

cordova plugin add https://github.com/HighTechHarmony/cordova-plugin-ble-central

cordova clean android

cordova build android

Read this if your DJI Spark is "Hopping" (erratic behavior)

My DJI drone has had this issue with my DJI Spark where, when I try to take off, it will  sort of hover, but then "hop" up and down.  It heads toward the ground and then seems to recover.  When it is heading toward the ground, the obstacle avoidance alert is going off.

Searching the internet, I found forums littered with a gazillion about "Fly Away" issues. I do NOT consider this is a FLYAWAY issue.  It seems like there are so many issues that are blanket described as "Fly Away", and while I suppose it is possible you could lose your drone as a result of this, it is most likely just going to hit the ground straight below, worst case.  I can technically fly it around, but it is fighting me the whole time.  The obstacle avoidance alert is intermittently on and off. The drone will ascend okay, but it descends VERY slowly (which is kind of scary if you get any sort of real altitude).  Also, at random it will just start heading vertically downward even though I didn't command it to.  Again the obstacle avoidance sensor beeping when the problem is occurring. Sadly I was not able to get this anomaly on video for a better description.

This issue cropped up seemingly out of nowhere. One day it flew fine, I put it away, next season I took it out, and it flew like crap.  I could occasionally get a problem-free flight out of it, but I never had any real confidence in it.  So for the last 2 years, I have been basically not flying my DJI Spark drone, due to this weird behavior.

After months of pondering (and letting my warranty lapse), I contacted DJI.  I described the issue and they recommended I send it in  to DJI for paid repair.  On the repair estimate, it said that the drone had crashed:

"After carrying out the damage assessment, we found that the unit has physical impact damage, unfortunately the damage that is not caused by product malfunction is Non- warranty repair; We'll either repair it or replace it with a product that's new or equivalent to new in both performance and reliability after payment has been received. For more information, please visit (http://www.dji.com/service/policy) - DJI North America"

The bit about impact damage was BS. I am the only one who has ever flown this thing, and I baby it.  The most I have ever done is buzzed a wall.  It has never impacted anything.  My guess is this is what they write on anything that gets shipped to them that doesn't fall under "warranty repair".  But I had no other viable options so I told them just to go ahead.

Weeks and $150 + shipping later, I got my drone back with a slip saying they replaced the vision system.  And lo, it did fly correctly... For a few (gentle!) test flights.  Then one day I took it out to fly and it started doing the hopping thing again.  I tore my hair out, ready to scrap this noisy money pit.  One last time I refocused my Google search terms to include "hopping", and that's when I hit the jackpot.  I found a handful of postings on DJI's forum of people who seemed to have the exact same problem. While there were a ton of the usual unhelpful responses (i.e. "Get rid of it! Sell it to me!"), I saw a couple of postings saying that the issue was solved by replacing the props. At first I just wrote this off.  Why would props make any sort of difference as to how the craft would fly (other than, maybe, FLY or NOT FLY)?  Okay maybe "FLY but be LOUD"...  But this post got my attention.  after a while, I realized I had the following options:

1. Throw away drone?
2. Buy a full set of genuine DJI props, and then throw away drone after proving it makes no difference.

So I did the latter.

And it worked.

WTF?!?!?

So naturally I now have some new questions.  How the hell is this behavior really caused?  One idea I had is that excess prop vibration somehow causes the obstacle avoidance sensor to falsely trip. 

Then there is the issue of the earlier "repair".  This was obviously the problem all along. It seems that DJI was more than happy to take my money to "fix" the craft, when the only issue was the props.  Think about it, there must be thousands of people who have experienced this problem, and I'm sure DJI customer service has enough data to recognize this as being a prop issue right off.  But either they didn't, or they chose not to tell me.  I would give them the benefit of the doubt, but then they did tell me they found "crash damage".

Anyway, lesson learned.  If your unit is out of warranty, think twice before sending it in to DJI for repair.  The only guarantee appears to be that you will pay them a hefty repair fee.

Defuddling JamKazam Vol. 2: Don't believe everything you read

I feel that one of the most important things to get out of the way are the truths of many, many claims and misnomers that are floating around on social media - no doubt a common issue with very rapid adoption of a complex tool.  We'll do this Snopes.com style.  Here are some, in no particular order:

Claim: "You Can't Use WiFi with JamKazam"
Status: Partly true
Explanation:
Well, you CAN use WiFi.  But it's better if you use an ethernet cable.  For starters, the nature of WiFi is that it tends to deliver packets via different physical transmission paths, which causes them to arrive in the wrong order.  On the other side, these packets have to be queuing them into a buffer (temporary holding tank for data), and reassembled into a contiguous stream.  Then they are released for you to hear. Ethernet cables require less of this action to be required, so JamKazam uses a smaller buffer, and therefore you end up with lower latency.  Now consider that most people have total shit WiFi setups at their homes, and using WiFi becomes an even worse choice.  Bottom line is, use an ethernet cable.

Claim: "You need the best internet plan available"
Status: Very unlikely
Explanation:
JamKazam is, contrary to what seems to be a rampant believe, not very bandwidth intensive.  It is the equivalent of a video conference call.  If someone is using solid audio gear, and having problems with latency or "choppiness" (which is a very vague description), it is most likely their computer or networking gear that is at fault.  It is very likely that the computer or router is on the edge of what it can handle in terms of load.

Claim: (Windows user) "You need to download ASIO4ALL"
Status: Very unlikely
Explanation:
Your audio interface hopefully has a native ASIO driver available from the manufacturer's website. This is what you should use.  If they don't, you can try ASIO4ALL, which is a third-party, lower latency wrapper for Windows' standard (high latency) WDM drivers. In some cases it works, but in most cases it doesn't seem to work very well.  It is definitely a second choice.

Claim: "A Chromebook is a viable cheap laptop option"
Status: False
Explanation:
While a Chromebook is, in fact, a laptop, Even if the processor power was enough, it does not run Windows or MacOS, which as of this writing are the only supported operating systems.  Chromebooks run ChromeOS, so, no go. If you are looking for the cheapest machine you can buy new that still has enough power, it's probably going to be a mini desktop computer, like the Intel NUC (bring your own monitor/keyboard/mouse).

Claim: "You need USB 3 (aka USB 3.1) ports"
Status: False
Explanation:
USB 2.0 max throughput = 480 Mbps
Even if you run 192KHz @ 24 bits < 10 Mbps
The latency of USB 3 is not improved over USB 2.0.
Even if you are using a 100 Mbps USB Network Adapter, JamKazam will not come close to saturating your connection.

Claim: "You need a (quad-core Intel Core i7 or other crazy CPU) if you want JamKazam to work as well as it can."
Status: False
Explanation:
You do need a real bit of processor power.  Practically speaking, I'd say, minimum dual core Core i3. Preferably a quad core Core i5 or better.  But to be fair, the amount of peak processor power you actually need for JK varies with how you are using it.  I've actually tested it with a Core 2 Duo from 2011, and it was "enough processor power to have a jam session".  Just barely.  As you add musicians, and use features like the video stream or Jam Tracks, that is when you will exceed your processor power, and when that happens, the result is NOT pretty.  Basically it's a sea of loud sparks and crackles in yours and everyone else's headphones.

Claim: "Turn off your video, it adds latency"
Status: Partially True
Explanation:
The video can have no impact, or a lot of impact, depending on a lot of factors.  The specific claim that it adds latency seems to be a little bit of a generalization, as though latency is the only evil one experiences on JK.  In fact, what it really does is add a ton more data that JamKazam has to coordinate which, if you or anyone in the session is on the edge, will very definitely result in a variety of problems - latency being only one.  Playing with the video on is more fun, but it's best to assume it is going to be a luxury and not a guarantee.  If everyone is getting good results, then congrats and enjoy - but it seems to vary with each session and the participants.

More parts coming soon!