There are equations for ideal screen size for different viewing distances: TV Size to Distance Calculator and Science - RTINGS.com
Though I’d take it with a grain of salt. Mainly because the chart suggests we should have a 100" TV …
I’m quite pleased with the 50" TCL/Roku TV I bought a few years ago. It’s got apps for any streaming service I’ve wanted and even plays files off a USB stick easily.
Ignore the smart portions of TVs. They all suck, and are a privacy nightmare. Even if they don’t suck right now, they will. The apps are not updated, or will stop being updated, and will become unusable or unstably slow, well before the screen stops being servicable. Stick with an external streaming device, which are better maintained and easier and cheaper to upgrade when the hardware becomes obsolete (or something new comes along…).
I’ll echo the “ignore the smart portions of TVs”. We have several smart TVs and we use a sum total of 0 of the “smart” features. Mostly, we attach Roku products to each one to consume our media (which is 100% streamed). I don’t see a reason to pay a premium for the top-of-the-line smart TV in order to get one with adequate performance when I can just attach something (computer, Roku, dozens of other potential devices) to an HDMI port and get all that performance or more attached to what is, at that point, a “dumb” TV.
My in-laws spent a lot of money to get a “decent” smart TV because they don’t have a Roku and don’t want to be bothered with “extras”, but just 2 years later the performance is simply awful (nothing seems to have changed… not sure why performance is so bad). But what they spent on the difference to get a better “Smart” could have bought 3 or more Roku products.
All that said, I might be on the outs with Roku. I had to turn off DNS logging on my PiHole setup because each Roku constantly tries to report back a constant stream of telemetry, even when not in-use.
If you can build a media server box of your own, or run one with free software, this is the way to go. Anything commercial will increasingly be trying to phone home with all the information it can gather, just like the smart TVs themselves.
I realise this isn’t an answer for everyone but I think it’s worth mentioning simply because the people selling you the commercial stuff will not.
We have a Toshiba Fire TV as well as an Insignia Fire TV, since we have Amazon Prime so use the video options a lot, as well as Netflix and Disney+. Those and a variety of other apps all work fine. Also, apps have been updating, as Tubi recently had a complete change which messed with the organization of their content, though not really for the better. Plus, they were only $400ish for 50+ inch screens.
So our experience with smart TV’s has been fine.
Before I left on vacation, I carefully sorted out the cables required, and put them on my desk.
They patiently awaited my return.
In other news, the aftermarket Apple Watch charger Walgreens sells is garbage. It works, but doesn’t keep my battery pack awake, so it turns off after 15 minutes or so. This is not desirable behavior, if you wish to have a charged watch when you wake up.
I occasionally worked with a developer who would do things like this. I get it – Git never quite clicks for some developers – but part of me wishes I hadn’t volunteered myself to fix this.
(But I’m going to, because it’s a project I like.)
Or maybe I can hire that cat…
This is why my employer tells new developers “If you have preferred methods of source code management, please don’t use them until you understand our setup, which is quite unlike anything you know.”
Work’s system completely discards two ideas that just about everything else uses:
My employer tells new employees “if you have ideas about source code control, they’re wrong. “. We’re a monorepo, and we have our own tools for everything. So whatever you’ve done before, it’s different. Vastly different from most places, and pretty different from a few other places that do thing similarly – because they all have their own internal tools, and they all work differently. No branches took some getting used to, particularly since I came from a place where the same third-party library would be in use in mulitple places, with different versions. You don’t have the luxury of dealing with library changes by ignoring them. (We have a way of doing branches, sort of, so you can do a stack of related diffs – here’s my class, here’s some code, here’s come tests, more code, etc, but when they’re commited, they’re just a bunch of diffs, and that they’re all landed together isn’t guaranteed.) This is pretty much the only thing that works at serious scale, and just about everyone working at those scales does it, but everyone has their own specialized practices and internal lools. (Even their own version control systems, in some cases.)
Reading some of this I’m glad that at my workplace all of the newer projects are using git (mostly as part of Azure DevOps) and the most exotic thing we do is a “squash merge” of feature branches after a pull request.
I understand precisely nothing in these techy posts!
I recognise most of the words, but hardly any of them seem to mean what they should, and the sentences they create may as well be in Sanskrit or Swahili for all the sense I can make of them.
The technology that makes my life easier is things like the wheel, electricity, and a (mostly) waterproof house. Oh, and the internal combustion engine, I suppose.
My current project does this, and It upsets me – my normal way of working says that if there’s more than one commit in a feature, each has its own purpose and its own explanatory commit message and contains only the code related to that purpose; and by the time we get to merging a feature any fixups from refactoring/QA have already been squashed into the relevant commit. Features then have a merge commit, so that all the commits for that feature are obvious in the history. That grooming process is the best way I know of to create a useful history which will help future developers (myself included) when reviewing why things were done that way in the past.
But there’s a reason for the blanket squashing in my current project that I simply don’t have a better solution to. The overriding mandate is that each issue is (ultimately) fixed with a single commit so that everyone (both us for multiple versions of the repository, and clients who may have a more limited understanding of git) has the ability to apply any given fix with a single cherry-pick.
I didn’t see a way to do things the way I’d prefer without imposing complications, so I conceded.
It sounds like our feature branches are generally smaller than yours might be.
We have documentation accompanying each feature which should tell the story of any given set of changes rather than relying on commit messages or pull request descriptions.
It’s then nice to have each feature distilled down to a single commit on develop. It makes it very easy to go from User Story ID to a single commit or PR in the history.
I’m not saying we haven’t had issues with that approach but it’s worked reasonably well for what we do.
I hate commit squashing. I appreciate it as the customer or user of a third party library, where I know “this bug is fixed by hash deadbeef”, but for stuff I work in, it drives me nuts. Not only is it screwed up with shocking regularity, but it hides the history of code. Why did they change from a heapqueue to a list? why this other change that seems odd? There were commit messages about that, but they got squashed.
Rewriting history feels like a betrayal of the idea of a version control system.
It’s too late to change it, but I’d be much happier if there were instead some way of batching up a bunch of commits and saying “these all go together as one thing with this message”, while leaving the actual commits intact for people who wanted to see them.
Beyond Compare V5 has a darkmode finally 
I had not realized there was a new version until I was downloading it for my new work laptop.
Beyond Compare is one of my favorite tools.
It’s a diff tool for those who don’t know it. And those who don’t know what a diff tool is, probably don’t need it. It can compare whole directory trees which is very useful if you messed up your document storage by making copies all over the place which is the most likely use-case for a non-techie person.
For the command line cowboys there are obviously different tools… I know. But sometimes I really like my “klicki-bunti” software (colorful and clickable)
I just opened a picture on my phone, zoomed into the label on a package in the picture, and the phone offered to track the package for me. It do so, correctly. this is not even a picture of the package – it’s a picture of five or six packages on the floor, which the person sending them out sent me. (and presumably the other people they’re sending packages to. I’ll sned 'em a note saying “I can read those names and addresses…” ) I did this because the email they sent has the wrong tracking number in it.
This is all slightly creepy. Pretty cool, but still creepy.
