I have just dumped code into a Chrome console and saved a cert while in a pinch. It’s not best practices of course, but when you need something fast for one-time use, it’s nice to have something immediately available.

You could make your own webpage that works in the browser (no backend) and make a cert. I haven’t published anything publicly because you really shouldn’t dump private keys in unknown websites, but nothing is stopping you from making your own.

That’s what NodeJS and Deno are.

The point of the browser support means it runs on modern Web technologies and doesn’t need external binaries (eg: OpenSSL). It can literally run on any JS, even a browser.

Just going to mention my zero-dependency ACME (Let’s Encrypt) library: https://github.com/clshortfuse/acmejs

It runs on Chrome, Safari, FireFox, Deno, and NodeJS.

I use it to spin up my wildcard and HTTP certificates. I’ve personally automated it by having the certificate upload to S3 buckets and AWS Certificates. I wrote a helper for Name.com for DNS validation. For HTTP validation, I use HTTP PUT.

Don’t use JSON for the response unless you include the response header to specify it’s application/json. You’re better off with regular plaintext unless the request header Accept asked for JSON and you respond with the right header.

That also means you can send a response based on what the request asked for.

403 Forbidden (not Unauthorized) is usually enough most of the time. Most of those errors are not meant for consumption by an application because it’s rare for 4xx codes to have a contract. They tend to go to a log and output for human readers later, so I’d lean on text as default.

I just recently started working with ImGui. Rewrite compiled game engines to add support for HDR into games that never supported it? Sure, easy. I can mod most games in an hour if not minutes.

Make the UI respond like any modern flexible-width UI in the past 15 years? It’s still taking me days. All of the ImGui documentation is hidden behind closed GitHub issues. Like, the expected user experience is to bash your head against something for hours, then submit your very specific issue and wait for the author to tell you what to do if you’re lucky, or link to another issue that vaguely resembles your issue.

I know some projects, WhatWG for one, follow the convention of, if something is unclear in the documentation, the issue does not get closed until that documentation gets updated so there’s no longer any ambiguity or lack of clarity.

My open-source, zero dependency JS library for requesting and generating certs with dns01: https://github.com/clshortfuse/acmejs

I only coded for name.com but it is compatible with anything really. Also can run in the browser, which could be useful in a pinch.

Either do a left join and repeat all the post values for every tag or do two round-trip queries and manually join them in code.

JSON_ARRAYAGG. You’ll get the object all tidied up by database in one trip with no need to manipulate on the receiving client.

I recently tried MariaDB for a project and it was kinda neat, having only really messed with DynamoDB and 2012 era MsSQL. All the modern SQL languages support it, though MariaDB and MySQL don’t exactly follow the spec.

I didn’t really care about this thread until I read this comment.

Your dad is right. On desktop, navigation is on the left. On tablet, you shrink it to a rail. On mobile it should be a dismissible nav drawer.

The top menus, especially the flyover(on mouse hover), are bad for accessibility because they convert a non-committal action (hover) to a context changing one (focus). It’s a uniquely web-only invention and thankfully falling out of usage. (Unless you mean menubar/toolbar. Those are fine but extremely rare on Web.)

I don’t code much C++, but then I’d lose alignment with: x = *p; and I feel that would bug me.

I’m looking at Google Style Guide for my next project and it says either is fine, just don’t declare more than one per line.

You don’t need Typescript, you need an linter (eslint).

=== is your basic equality like most languages. == will implicitly cast type.

The breakdown is here: https://262.ecma-international.org/5.1/#sec-11.9.3

Modern JS says to never use == unless you’re comparing against null or undefined.

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 just recently worked on fixed point 8.8 and basically the way fractional values work, you take an integer and say that integer is then divided by another one. So you represent the number in question with two numbers not one. 0.3 can be presented in a number of ways, like 30 % 10, or 6 % 20.

The problem is the way 0.1 is represented and 0.2 represented don’t jive when you add them, so the compiler makes a fractional representation of 0.3 based on how 0.1 and 0.2 were expressed that just comes out weird.

That’s also why 0.3 + 0.3 is fine. When you wrote 0.3, the compiler/runtime already knew how to express 0.3 without rounding errors.

You can use Dev Tools to see a page’s full accessibility tree:

Chrome: https://developer.chrome.com/blog/full-accessibility-tree/#full-accessibility-tree-in-devtools

Firefox: https://firefox-source-docs.mozilla.org/devtools-user/accessibility_inspector/#features-of-the-accessibility-panel

I haven’t really looked for anything that will present that to you as an Add-On/Extension but it’s theoretically possible.

We’re kinda getting it back with the Accessibility tree

In theory, if the page is compiled right, you can read everything right from there. You could also interact with it.

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.

I’ve been writing my own render framework and component library for about a year now.

One thing I enjoy most about it is that the types are automatically inferred. There’s a lot of Typescript wrangling going on, and it gets really deep into what TS is capable of and barely capable of (polymorphic this, dynamic return types based on input, Class type reconstruction, mixins that influence both static and instance properties, event listeners based on event name, typed property watchers based on property name).

It’s all written in JavaScript with “JSDocs”. It’s not really JSDocs because there’s a lot of recursion that’s not possible with regular JSDocs. It’s TS type information slipped into JSDoc comments.

Ridiculously complex core Class

But that is to setup the ability to tap into inferred types. The actual code that’s written (eg: components) is fully typed check with little or no type declaration.

Declarative-style component with almost no explicit typing

The reality is, no complex piece of code should be written without some form of type checking. TS isn’t perfect and if there were something better, I’d move. Alliances are stupid. There are problems with some things that have not been, and likely will never be, fixed. But what type-checkers should do best is infer types dynamically.

The result means all my code today just runs in the browser. I don’t have to wrangle builders or compilers (bye Webpack!). At most, I use just esbuild to minify, though it’s an optional step, not a mandatory one. If I want to mess around on Codepen with my library, I can refer to a git commit directly and load the file. I don’t need npm to package and release. (CodePen Sample)

Starfield has a bunch of AS3 and Flash files. I’ve been hacking it all week.

And, uh, I use vanilla JavaScript with Typescript checking via JSDocs.

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.