HamsterRage

I think that a good starting place to explain the concept to people would be to describe a Travesty Generator. I remember playing with one of those back in the 1980's. If you fed it a snippet of Shakespeare, what it churned out sounded remarkably like Shakespeare, even if it created brand "new" words.

The results were goofy, but fun because it still almost made sense.

The most disappointing source text I ever put in was TS Eliot. The output was just about as much rubbish as the original text.

Paywalled

Bring on the feather!!!

I think it boils down to where you define the extension functions and how that impacts coupling.

At some level you want to divorce the repository storage of the data from your domain object. Let's say that the repository changes, and "name" is no longer just "name", but now "firstName" and "lastName". The body of your application doesn't care, or need to know that the repository has changed, as it will still just deal with a name, whatever that is.

So something has to put "firstName" and "lastName" together into a "name", and it needs to be consistent with how the application has always received it. Is it "Fred Smith", "Fred, Smith" or "F. Smith"? And who "owns" that logic?

From a coupling perspective, you don't want the application logic to know anything about the repository or the internal structure of the DTO. On the other hand, you don't want the repository service layer to know about how the data is going to be used.

Let's say that you have two different applications that used the "name" field, but in different ways somehow. So the conversion from the two "name" fields into one might be different for each application. Yes, you could argue that recombining them back exactly the way the repository service originally delivered "name" would be transparent to the client applications, but what if the change to the repository was driven by one of those applications needing split data?

That's usually why you put your adapters in some neutral place, associated with the client application but yet somewhat outside of it.

You could use extension functions to provide the adapter, but you need to make sure that they're not co-mingled with you application code. Otherwise you've just reestablished the coupling between the repository and the application that you where trying to avoid.

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.

Keep in mind that it has been decades since I last used Kermit, but I'm pretty sure the use case it was originally designed for was...

Connect to a serial port, which had a modem attached. Talk to the modem and get it to dial a number. Presumably, the remote end answered and the port attached to its modem would issue a login prompt. Negotiate the login and then issue a bunch of commands to change directories and then launch Kermit on the remote system. After that Kermit to Kermit communications took over until you terminated the session. Finally, log off the remote system and hang up the modem.

All of this stuff could be done via scripts. I seem to remember that it would actually wait for a response, and then parse the response in the script. I don't remember ever doing polling loops.

If you're on a *nix box of some type, it's totally possible to open up a serial port for manual I/O even in something like a bash script. Even if you have to reverse telnet to a terminal server.

Kermit on top of FTP can work really well. Kermit has its own communication and transfer protocol, IIRC, but updates in the 1990's allowed it to be used with TCP/IP and FTP. So you can write a script to log into a remote system, run some commands and then initiate a file transfer. The scripting allows you to wait for responses and act on them.

Yes, $15 CAD/day to "roam like home". I have an Orange eSIM that I can keep alive if I use it at least once every 6 months - with a local french number that stays mine. It costs me about $40 CAD for a 30 day - 20GB top up. My wife uses Nomad for data only, we both don't need local numbers, and it generally costs $12 CAD for 5 GB 2 week top-up.

So I figure about $60-70 CAD for 3 weeks travel virtually anywhere in Europe. Calls and SMS included (for one) without long distance charges. Compared to $630 for "roam like home" for two people from a Canadian carrier - doesn't matter which one as far as I can tell.

We both recently got new phones to be able to use eSIMs.

And the physical SIMs stay active. So my elderly parents can call my Canadian number if there's an emergency and it will ring through.

In fact, on our last trip to Rome, when we used a credit card at the hotel, it was refused and then seconds later I got a text from the bank asking for confirmation on my Canadian number. I had no choice but to text "Yes" back, and that single text activated roaming for the day and cost me $15.

Most people aren't going to need to top up more than 30-40km worth of charge every night anyways. So that's probably only a couple hours on 15amp.

An small InstantPot does the trick just as well, and you can use it for other stuff as well.