Here you go everyone: https://youtu.be/ICXltEUJ41U?si=gZnpuN8A85UKyjyC

Exactly what you didn’t know you were looking but, in the back of your mind, you really were.

Years (decades) ago it wasn’t uncommon to create self-signed/local CAs for active directory, but it’s really uncommon today since everything is internet facing and we have things like Let’s Encrypt.

It’s so old, the “What’s New” article from Microsoft references Windows Server 2012 which is around when I stopped working on Windows Server. I kinda remember it, and you needing to add the server’s cert to your trusted roots. (I don’t know about Linux, but the concept is the same, I’m sure. I never tried generating certificates, but know all the other client -side stuff. Basically you need a way to fulfill CSRs.)

https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/

What you’d want to do it in Windows is all there, and Microsoft made that pretty easy back then to integrate with all their platforms and services, but I’d caution, do you really want to implement 10+ year old tech?

I don’t know why you’re bringing up Palisade. The OP clearly says Telluride and the text mentions Kia. I have the same car, 2020.

You either have remote start over Kia Connect or key fob. It’s either, not both.

And a Reddit comment goes further:

No 2020 Tellurides in North America had remote start on the key fob from the factory.

https://www.reddit.com/r/KiaTelluride/comments/14737v9/telluride_remote_start/

See also: https://www.kiatelluride.org/threads/2020-telluride-remote-start.1825/ (outside of US has fob)

You can’t remote start with the key (at least on the 2020). It’s remote cellular start that runs on a ~40 second interval or nothing (or third party).

I have a Telluride. I’ve been downgraded to Lite which gives you notifications if you forget to lock your car. But remote start is no longer available.

The way it worked seems to be polling since you could wait around up to a minute for the car to perform a command.

The worst part is the car does not have “local” remote start. I’d have to buy another piece of equipment for that and install it. It’s not available at all on the key fob.

Should be a hyphen instead of period before NAHOM.

Texas?

Yeah, I have my own stuff that lets me do MSSQL, DynamoDB, REST/HATEAOS, regular Hash Maps, and some obscure databases (FilePro).

I throw them in a tree structure and perform depth-first searches for resources. Some of them have stuff for change data capture streaming as well, (eg: SQLNotifications, DynamoDB Stream, WebSockets).

DynamoDB was a rough one to optimize because I have to code to pick the best index. You don’t do that with SQL.

The code on backend is the same as frontend, but a different tree. Frontend queries against REST and a cache layer. Backend queries against anything, REST included.

Double NAT with DMZ.

Those SIP ALGs are more trouble than they are worth. If you are using SIP devices, use a different outbound port on each device (eg: 5060, 5061, 5062).

SSR is a overloaded term.

• There’s SSR to help improve FCP (first contentful paint). This is not really so much an improvement to the client side framework as it is a crutch to workaround the fact that the frameworks are dynamically constructed clientside. But the first paint would just be Root node which is essentially empty. Because React and Vue are so heavily tied to the DOM structure, it expects to be the compositor of the tree, not something written in HTML. For pure HTML to be the compositor, you would need to add some rehydration to React/Vue to take a pre-composed state and reintegrate it into what React expects.

• SSR is also used to dynamically build content that is presented to the user that is not necessarily tied to rendering. This is popular with PHP, where instead of putting a blank table and then having the client fetch content over JS and then populate that table, the server just hands you the precompiled HTML. Not all the data as sent over JS may be useful (eg: only 10% is used after filtering and pagination), so to save transfer size and query latency, it may be the server that gets the always data from the store or cache. There’s less client JS in execution, which may also help in performance.

• Then there’s SSR for the purpose of improving SEO. This relates more to the first point, but maybe the first paint isn’t important. Maybe client-side construction is plenty fast. But because the root is just blank, search engines that don’t perform synchronous JavaScript can’t actually read the content being shown to the user after all the rendering is said and done.

Personally, I’ve moved to Web Components that solves almost all of this. You can author layouts in HTML and anything that you want in your HTML file for SEO is included in the source. I would only use SSR to target the second issue, where you want to save on trips to build dynamic content. It is somewhat wasteful to give clients instructions to fetch and render when the server can do that on the first trip. The issue is rehydrating, or picking up from that state, but that truly depends on how complex your Web Components are. If they are sparse and simple enough, then all states should be able to be expressed over attributes. First paint can be reduced with the template shadow root, but I feel it’s more trouble then it’s worth and has negligible performance gains compared to just doing a prerender JS to register components and the browser will only render synchronously what’s in the viewport anyway. That means time to first paint is not dependent of how big your page is. It’s only dependent on how many elements you want to register before DOMContentLoaded.

From a financial aspect, I’m not about to ditch static CDNs to reinterpret nearly every single request with some server for SSR. The costs are nowhere near the same to try to reinterpret with SSR. You can micro-optimize to death with a SSR to CDN route and then hydrate, but I feel you risk complicating deployments to where you’re so vendor-locked you have extra hoops to jump to make changes. God forbid you want to change frontend systems. At that point the DX pain is too much to justify and wanting to get out is inevitable.

You wrote:

To mitigate problems caused by DRY fundamentalisms, the “write everything twice” (WET) principle was coined.

I’m listing when and how it was coined with the article that coined it. If you have another source to claim it wasn’t in the fashion I’ve described feel free to provide sources to the contrary. I even sources it from the very Wikipedia entry you shared.

WET is a clear guideline

Again, feel free to provide sources to back up your claim.

Your comment sounds like a weak attempt at revisionism.

Again. Feel free to back up your claims with actual sources. The concept of AHA by Kent C Dobbs, of Angular fame says:

There’s another concept that people have referred to as WET programming which stands for “Write Everything Twice.” That’s similarly dogmatic and over prescriptive. Conlin Durbin has defined this as […]

https://kentcdodds.com/blog/aha-programming

He then goes on to link to the article/blog I mentioned where Durbin states:

Instead, I propose WET programming.

And he goes on to explain this new concept of Write Everything Twice.

If you actually interested in discussion about the debate of DRY/WET/AHA, I’m all for it. But don’t misinterpret or try to change what is already well-written.

Also, don’t throw accusations at people who provide you documentation and proof and then contest while providing absolutely none yourself. That doesn’t sound like any earnest interest in discussion.

WET is not what you think it is, or at least not originally. It’s not some alternative to DRY. It didn’t stand for Write Everything Twice. It stands for Write Every Time. It’s supposed to be a negative way to describe code that isn’t DRY. It’s also abbreviated as “Waste Everyone’s Time”.

Much, much, much later somebody tried to reuse the term for “Write Everything Twice” but talking specifically about the benefits of singular, repeated templating because the abstraction needed to refactor code into “Write-Once” can make things harder to understand. In other words, it creates a chain of pre-required knowledge of how the abstraction works well before you can even work with it.

The irony here is that DRY is not really about code duplication. It’s actually about system knowledge (structures and processes) being clear and unambiguous. Or, applied, you, as a person, not having to repeat yourself when it comes to sharing knowledge. It lends to simpler constructs that don’t need much explanation. The example given of Write Everything Twice is actually being DRY, but they don’t realize it.

Bill Venners: What’s the DRY principle?

Dave Thomas: Don’t Repeat Yourself (or DRY) is probably one of the most misunderstood parts of the book.

Bill Venners: How is DRY misunderstood and what is the correct way to understand it?

Dave Thomas: Most people take DRY to mean you shouldn’t duplicate code. That’s not its intention. The idea behind DRY is far grander than that.

DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system’s knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.

https://www.artima.com/articles/orthogonality-and-the-dry-principle

The article/interview explains more about how DRY is meant to work and even talks about the pitfalls of code generators, which the WET article complains about (React).

The misunderstanding since DRY’s coining is probably because, like natural language, we change meanings we with our environment. DRY became a term people use to blast too much abstraction. But noisy abstractions are not DRY. In response we have a new term card AHA (Avoid Hasty Abstractions), which exists as a counter to what people think DRY is.

The TL;DR is DRY is meant to mean your code should be unambiguous, not some sort of mantra to deduplify your code. Apply its original principles, and follow AHA which should be a clearer safeguard to avoid your abstractions not following DRY.

https://attrition.org/archive/www.detonate.net/matrix-orig/