Test Equipment Anonymous (TEA) : Discussion and Group Therapy Thread

[dl6lr]

I suspect the two layers are sandwiched as one layer has all the markings on them, so they cannot be rubbed off.

[bd139]

And they say software engineers build things in an idiotic quixotic way.

Well, they do - but they aren't the only perpetrators.

We just try the hardest to do it badly!

[tggzzz]

And they say software engineers build things in an idiotic quixotic way.

Well, they do - but they aren't the only perpetrators.

We just try the hardest to do it badly!

The acronyms SNAFU and FUBAR are from WW2, and clearly predate software. Nonetheless, software and software weenies do tend to take everything to extremes.

Once software becomes mature, biohacking will take over that particular mantle.

[bd139]

And they say software engineers build things in an idiotic quixotic way.

Well, they do - but they aren't the only perpetrators.

We just try the hardest to do it badly!

The acronyms SNAFU and FUBAR are from WW2, and clearly predate software. Nonetheless, software and software weenies do tend to take everything to extremes.

Once software becomes mature, biohacking will take over that particular mantle.

I can't wait to see people queuing up in Currys because they ended up with an extra nose instead of extra fingers.

[tggzzz]

We just try the hardest to do it badly!

The acronyms SNAFU and FUBAR are from WW2, and clearly predate software. Nonetheless, software and software weenies do tend to take everything to extremes.

Once software becomes mature, biohacking will take over that particular mantle.

I can't wait to see people queuing up in Currys because they ended up with an extra nose instead of extra fingers.

Or, "If you want the antidote before it does you damage, send bitcoins to..."

I'll give it 50 years until that happens. The only question is when the 50 years started (past tense)

[bd139]

The acronyms SNAFU and FUBAR are from WW2, and clearly predate software. Nonetheless, software and software weenies do tend to take everything to extremes.

Once software becomes mature, biohacking will take over that particular mantle.

I can't wait to see people queuing up in Currys because they ended up with an extra nose instead of extra fingers.

Or, "If you want the antidote before it does you damage, send bitcoins to..."

I'll give it 50 years until that happens. The only question is when the 50 years started (past tense)

My eldest was producing antibiotic resistant E. Coli the other day at university so I suspect she'll have something to do with it

[Robert]

I've done that. The biotech instrument comany sent me on some lab courses.
You use a virus to intoduce the the relevant strand of DNA into the eColi. Mine worked. Normally you ony do it for a antibiotic that isn't used on humans and a strain of eColi that isn't virulent.
You then use the eColi to multiply other DNA by growing it on a nutrient gel that contains the antibiotic. This stops unwanted bacteria growing on the gel.

I also know about some other stuff

[Robert]

Talking of software, what is the collective view of using Python for controlling hardware for commercial products?

[tggzzz]

Talking of software, what is the collective view of using Python for controlling hardware for commercial products?

Objectives? Constraints?

[ch_scr]

Talking of software, what is the collective view of using Python for controlling hardware for commercial products?

Are you talking about controlling "commercial products" like a Keithley multimeter by Python, or "building a partially hardware product, which software side is python" ? For test automation, python can do good work in my experience. It's basically Python or Labview anyway, in that field. Also all the hobbyists use python for that stuff.

[tggzzz]

Talking of software, what is the collective view of using Python for controlling hardware for commercial products?

Are you talking about controlling "commercial products" like a Keithley multimeter by Python, or "building a partially hardware product, which software side is python" ? For test automation, python can do good work in my experience. It's basically Python or Labview anyway, in that field. Also all the hobbyists use python for that stuff.

30 years ago both HP and Tek had the good taste to embed a headless Smalltalk in their instruments.

[Robert]

Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

[tggzzz]

Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

What is the expected benefit of using Python rather than another language?

Development speed? Scriptability? Field upgrades with extra functionality? What are the alternative ways of realising the benefits?

Don't fall into the trap of creating a domain specific language when a domain specific library is sufficient!

[bd139]

Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

I'm on the fence with that if I'm honest. Python can be used to make reliable software but it's not designed to. There are a number of language constraints which make it a difficult proposition in some cases. For example the dynamic/duck typed nature of the language has a bunch of foot guns. Also depending on what sort of deadline/latency guarantees you have, it might punch you in the face. If you require any concurrency or threading, it's probably worth looking elsewhere because there are still locking issues across the board. Also python packaging and dependency management is a shit show. It's one of those things that will require some maintenance down the line, not fire and forget. But it'll get you to the destination.

Depending on the architecture of the CPU, Go is worth a look at as well. That has proper concurrency primitives (based on Hoare's CSP paper with some extra bits), is properly statically typed and is memory safe, packaging is a joy, it cross compiles and it farts out one statically linked binary you can copy to the target machine and just run it.

I've got both in production under heavy load. Python has been stable but slow and difficult to maintain. Go has been stable, fast and not difficult to maintain. They can solve the same problem domain.

I would categorically never use: Ruby, C, Rust, C++, Java or C# for that sort of environment. Bad tradeoffs of time to market and footguns.

90% of the problem is what monkeys you have and what they can do though.

[bd139]

Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

What is the expected benefit of using Python rather than another language?

Development speed? Scriptability? Field upgrades with extra functionality? What are the alternative ways of realising the benefits?

Don't fall into the trap of creating a domain specific language when a domain specific library is sufficient!

Good questions.

Throw a Kepner-Tregoe decision model at it.

https://www.decision-making-confidence. ... aking.html

[tggzzz]

I would categorically never use: Ruby, C, Rust, C++, Java or C# for that sort of environment. Bad tradeoffs of time to market and footguns.

90% of the problem is what monkeys you have and what they can do though.

That latter point is always a valuable contribution to a decision. But it does favour the status quo rather than jumping to something better. The "something betters" do exist, but they are rare and seem to occur about once a decade. Good taste and experience is a precondition for spotting them.

As for the other points...

Ruby is the triumphant (and unwitting) reinvention of Smalltalk.
C/C++ - 'nuff said.
C# is the witting and not triumphant reinvention of Java.

Don't forget the benefits of having solid well-thought out impenetrable interfaces. Interfaces that "leak abstractions" are a long term route to damnation and degradation in many senses of the words.

Don't fall into the trap of "we don't know what will be required here, so we'll punt the decisions down the line by leaving things scriptable" . Or worse: making life easier/simpler by having a scrotty scripting language, which will inevitably become a cancerous mass.

[25 CPS]

I just packed it in for the evening in sheer frustration.

The stereo receiver I'm using on the bench has switches for A and B pairs of speakers so I thought it would be convenient to have a set of pigtails brought out to an easy access location instead of having to go behind the receiver to connect speakers under test.

So, I bought a banana plug connector wall plate - which claimed to be a GE but probably made by a company that has nothing to do with General Electric except for a license to use their name and logo - and an electrical box, and assembled it tonight then connected it to B speaker outputs on the stereo receiver.





So far, so good, right? Right up until connecting something else.



You have to be kidding me.

Whoever made this decided to break from the 3/4 inch spacing standard that has been used practically forever which means anything with a dual banana connector doesn't fit which rules out plugging in dual banana to alligator clip test leads or speaker wires terminated in a dual banana connector.

That is supremely annoying. I'm going to have to find a wall plate with correct spacing or use panel mount connectors and a piece of sheet metal or plastic to make a replacement front for that box.

[Cerebus]

Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

Python itself and the libraries that are an integral part run at a rate of acquiring CVE vulnerabilities of around one per month. Haul in any other python packages and you're looking at more. Which is another way of saying that managing the risks of a python deployment in the field are high.

Anyone who's used python commercially, and has an ounce of sense, will tell you the same story: managing updates and dependencies in the data centre is a pain in the arse. Doing it in the field is not something I would relish having to do; which is a very understated way of saying that I would be running the other way fast.

Python is fine for isolated fiddling. I use it to drive test gear, on the bench, where the stuff built is virtually throwaway. I also use it to drive my own systems configuration, during which time it is always supervised. I don't use it for anything mission critical, and when I have (there's a Telco out there that does mission critical core network automation on python code that I co-authored) it's surrounded with build pipelines that make sure they get exactly the right version of every identified dependency from a secure repository, and test cases that make up as much (possibly more) code than the job in hand.

When working seriously with python I always have the feeling that I'm working with a fragile, shifting, unstable pile of stuff that's just waiting to bite me in the arse at the first opportunity.

If you do end up having to use it, don't let anybody who identifies as a "python programmer" loose on it, use programmers who can also program in python. The python fanboys are some of the worst coders out there*.

*Example: one "python programmer" I was working with had a task that required counting the number of objects that had some particular characteristic. Instead of just running a simple loop iterating over the collection and adding one to a counter for each applicable object found and spitting that out as the count at the end of the loop, he ran the loop, inserted every applicable object into a "set" object, and then took the cardinality of the set as the result at the end of the loop. Changing it to a simple counter only made the loop run about 20 times faster. God save me from 'clever' programmers.

[Cerebus]

Whoever made this decided to break from the 3/4 inch spacing standard that has been used practically forever which means anything with a dual banana connector doesn't fit which rules out plugging in dual banana to alligator clip test leads or speaker wires terminated in a dual banana connector.

Taking the perpetrator outside and giving them 100 lashes with the probe set from an old Tek logic analyser wouldn't be an excessively harsh punishment.

[Robert]

Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

I'm on the fence with that if I'm honest. Python can be used to make reliable software but it's not designed to. There are a number of language constraints which make it a difficult proposition in some cases. For example the dynamic/duck typed nature of the language has a bunch of foot guns. Also depending on what sort of deadline/latency guarantees you have, it might punch you in the face. If you require any concurrency or threading, it's probably worth looking elsewhere because there are still locking issues across the board. Also python packaging and dependency management is a shit show. It's one of those things that will require some maintenance down the line, not fire and forget. But it'll get you to the destination.

Depending on the architecture of the CPU, Go is worth a look at as well. That has proper concurrency primitives (based on Hoare's CSP paper with some extra bits), is properly statically typed and is memory safe, packaging is a joy, it cross compiles and it farts out one statically linked binary you can copy to the target machine and just run it.

I've got both in production under heavy load. Python has been stable but slow and difficult to maintain. Go has been stable, fast and not difficult to maintain. They can solve the same problem domain.

I would categorically never use: Ruby, C, Rust, C++, Java or C# for that sort of environment. Bad tradeoffs of time to market and footguns.

90% of the problem is what monkeys you have and what they can do though.

The 90% is the problem. Basically non software monkeys. Some of them think using ChatGPT to generate a starting point for code is a great idea
I'm no programmer, bar a bit of Pic Basic Pro 3, but have had to sort out the messes in the past. It's the combination of a open source interpreted language and lots of 3rd party libaries (and copied code) by non programming professionals that wories me.

[tggzzz]

The 90% is the problem. Basically non software monkeys. Some of them think using ChatGPT to generate a starting point for code is a great idea
I'm no programmer, bar a bit of Pic Basic Pro 3, but have had to sort out the messes in the past. It's the combination of a open source interpreted language and lots of 3rd party libaries (and copied code) by non programming professionals that wories me.

So PEBCAK will be a problem. Solution: don't let any form of keyboard alter the application's operation.

Make very very sure the contract's Ts&Cs limit your liability to anything that ChatGPT (or worse) cannot change. Background: I once wrote a contract to develop an X, included a clause stating the deliverable would not be suitable for X, drew attention to the clause in the covering letter. The client was happy to sign because they knew why the clause was there.

Plus the security mess pointed out by cerebus.

Plus "whitespace has semantic meaning" which could be fun when inserting ChatGPT snippets into existing code.

Overall: whoooooosh, with a small dot receding into the distance as fast as possible.

[bd139]

Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

Python itself and the libraries that are an integral part run at a rate of acquiring CVE vulnerabilities of around one per month. Haul in any other python packages and you're looking at more. Which is another way of saying that managing the risks of a python deployment in the field are high.

Anyone who's used python commercially, and has an ounce of sense, will tell you the same story: managing updates and dependencies in the data centre is a pain in the arse. Doing it in the field is not something I would relish having to do; which is a very understated way of saying that I would be running the other way fast.

This is one reason I use Go. Most of the stuff I need is in the standard library so you don't have to import god knows what from god knows where off the Internet to run your stack. The core product and standard library is run by a team of people, mostly ex Bell Labs, at Google who actually have a decent security posture and mostly know what they are doing (bar that toolchain telemetry thing which with some credit they decided not to proceed with).

Python is fine for isolated fiddling. I use it to drive test gear, on the bench, where the stuff built is virtually throwaway. I also use it to drive my own systems configuration, during which time it is always supervised. I don't use it for anything mission critical, and when I have (there's a Telco out there that does mission critical core network automation on python code that I co-authored) it's surrounded with build pipelines that make sure they get exactly the right version of every identified dependency from a secure repository, and test cases that make up as much (possibly more) code than the job in hand.

When working seriously with python I always have the feeling that I'm working with a fragile, shifting, unstable pile of stuff that's just waiting to bite me in the arse at the first opportunity.

Clearly have never encountered nodejs in any quantity then.

If you do end up having to use it, don't let anybody who identifies as a "python programmer" loose on it, use programmers who can also program in python. The python fanboys are some of the worst coders out there*.

Definitely never encountered nodejs in any quantity then!

*Example: one "python programmer" I was working with had a task that required counting the number of objects that had some particular characteristic. Instead of just running a simple loop iterating over the collection and adding one to a counter for each applicable object found and spitting that out as the count at the end of the loop, he ran the loop, inserted every applicable object into a "set" object, and then took the cardinality of the set as the result at the end of the loop. Changing it to a simple counter only made the loop run about 20 times faster. God save me from 'clever' programmers.

I actually had someone do exactly that in C# last week which caused an incident because the process blew the pod's memory limit. Argh.

You can write:

Code: Select all

var count = lazyCollection.Select(s=>s.Attribute == "value").Count()

But no they wrote:

Code: Select all

var output = new List<Item>();
foreach (var item in lazyCollection.ToList()) {
    if (item.Attribute == "value") {
        output.Add(item);
    }
}
var count = output.Count;

lazyCollection is an enumerable list that isn't actually materialised until you hit .Count() or try and iterate it. And if you add the .Select() to it, it'll actually filter in the upstream API provider by adding a parameter to it. Instead it sucked about 100,000 objects down and materialised them in RAM, then created another list in it. If that wasn't bad enough it went and hit the API again to get another value slightly later and then merged them in RAM on the client. This of course passed all test cases because the test cases tested it once. It also worked on the cray-like developer laptops of course.

On that I think we should give software monkeys crap laptops and make them suffer. 8Gb of RAM max.

[Robert]

Thanks for the Python opinions.
Just wanted to check I wasn't whinging without reason.

[mnementh]

Here; watch this over your morning cuppa.

mnem

[ch_scr]

I just packed it in for the evening in sheer frustration.

The stereo receiver I'm using on the bench has switches for A and B pairs of speakers so I thought it would be convenient to have a set of pigtails brought out to an easy access location instead of having to go behind the receiver to connect speakers under test.

So, I bought a banana plug connector wall plate - which claimed to be a GE but probably made by a company that has nothing to do with General Electric except for a license to use their name and logo - and an electrical box, and assembled it tonight then connected it to B speaker outputs on the stereo receiver.





So far, so good, right? Right up until connecting something else.



You have to be kidding me.

Whoever made this decided to break from the 3/4 inch spacing standard that has been used practically forever which means anything with a dual banana connector doesn't fit which rules out plugging in dual banana to alligator clip test leads or speaker wires terminated in a dual banana connector.

That is supremely annoying. I'm going to have to find a wall plate with correct spacing or use panel mount connectors and a piece of sheet metal or plastic to make a replacement front for that box.

Since Mnem seems to be asleep at the wheel here, I'm going to say it: That is a prime example for "things to be fixed with 3d printing"!