The reason for leaving in the password.trim() would be one of the few things that I would ever document with a comment.

This is true, but…

Moore’s Law can be thought of as an observation about the exponential growth of technology power per $ over time. So yeah, not Moore’s Law, but something like it that ordinary people can see evolving right in front of their eyes.

So a $40 Raspberry Pi today runs benchmarks 4.76 times faster than a multimillion dollar Cray supercomputer from 1978. Is that Moore’s Law? No, but the bang/$ curve probably looks similar to it over those 30 years.

You can see a similar curve when you look at data transmission speed and volume per $ over the same time span.

And then for storage. Going from 5 1/4" floppy disks, or effing cassette drives, back on the earliest home computers. Or the round tapes we used to cart around when I started working in the 80’s which had a capacity of around 64KB. To micro SD cards with multi-terabyte capacity today.

Same curve.

Does anybody care whether the storage is a tape, or a platter, or 8 platters, or circuitry? Not for this purpose.

The implication of, “That’s not Moore’s Law”, is that the observation isn’t valid. Which is BS. Everyone understands that that the true wonderment is how your Bang/$ goes up exponentially over time.

Even if you’re technical you have to understand that this factor drives the applications.

Why aren’t we all still walking around with Sony Walkmans? Because small, cheap hard drives enabled the iPod. Why aren’t we all still walking around with iPods? Because cheap data volume and speed enabled streaming services.

While none of this involves counting transistors per inch on a chip, it’s actually more important/interesting than Moore’s Law. Because it speaks to how to the power of the technology available for everyday uses is exploding over time.

Old school Unix guy here…vi,awk and sed are all that you need.

You might want to think about it a bit more before putting it to work. The comment with the streams example is far, far better.

Back in the 70’s and 80’s there were “Travesty Generators”. You pushed some text into them and they developed linguistic rules based on probabilities determined by the text. Then you could have them generate brand new text randomly created by applying the linguistic rules developed from the source text.

Surprisingly, they would generate “brand new” words that weren’t in the original text, but were real words. And the output matched stylistically to the input text. So you put in Shakespeare and you got out something that sounded like Shakespeare. You get the idea.

I built one and tried running some TS Eliot through it, because stuff is, IMHO, close to gibberish to begin with. The results were disappointing. Basically because it couldn’t get any more gibberishy that the source.

I strongly suspect that the same would happen with Trump’s gibberish. There used to be a bunch of Travesty Generators online, and you could probably try one out to see.

I wonder how depressed Giorgio Tsoukalos’s dog is???

I’m not sure if traffic is “convenience” at this point. At least where I live, it’s a nearly essential piece of functionality.

In fact, for local driving it’s often the only reason to use a map app. I already know how to get to most of the places I want to go, I just need to know the best route to avoid traffic now.

You mean “flavour”, right? Another small but important difference.

I think it’s a bit more than that. I think that the idea is that you simplify the problem so that the rubber duck could understand it. Or at least reformulate it in order to communicate it clearly.

It’s the simplification, reformulation or reorganisation that helps to get the breakthrough.

Just thinking out loud isn’t quite the same thing.

It goes really well with YAGNI. Also DRY without YAGNI is a recipe for premature over-architecting.

This is also one of the main benefits of TDD. There was a really good video that I can’t find again of a demonstration of how TDD leads you to different solutions than you thought you use when you started. Because you code exclusively for one single requirement at a time, adding or changing just enough code to meet each new requirement without breaking the earlier tests. The design then evolves.

I’ve always heard of your “post-architecture” referred to as “evolutionary design”.

COBOL is not hard to learn. But it takes years to develop the muscles in your fingers to the point where you can write a subroutine in a single session.

My first experience with this food was in Halifax decades ago. The Halifax Donair is a unique thing.

And it’s definitely Donair, not Doner.

Technically, he would have three drives and only two drives of data. So he could move 1/3 of the data off each of the two drives onto the third and then start off with RAID 5 across the remaining 1/3 of each drive.

Deal with the ethernet port issue by purchasing a 5 port ethernet switch. Maybe the rest of your issues go away?

As a Canadian driving around the UK I always found these signs strange. When passing one we would raise our fists in the air and shout, “End road work…end road work everywhere!!!”.

It amused us.

For me Bazzera Magica and Baratza Vario grinder some time back. Better coffee than most cafes.

I looked and Python has the library support for the GPIO and to do background threading to poll pins. My preference would be to go with a JVM language like Kotlin, but then I’m a programmer. Python, from the little that I’ve mucked about with it is really just one step in complexity from scripting. Maybe even easier, because some things in shell scripts are super difficult to do.

Maybe then you need to move one stop up from scripting into something closer to actually programming. I’d be surprised if Python doesn’t have the library support on a Pi for dealing with both serial and GPIO I/O.

the end stop in external to the serial communication

Does this mean that you have some kind of other signals or pin-outs? If so, this is starting to sound like a great project for a Raspberry Pi, because the GPIO pin array can handle that.