gofwrath

This misses the point entirely. A miracle is something that was not treatable by a modern medical professional, and then was. The miracle (or recovery) then would be reviewed by an independent group and deemed sufficiently inexplicable.

Recently tried copilot for about a month or so. After the initial, “wow neat” couple days I general became annoyed with the suggestions. They are either sort of right, kind of right, or right. However in the time to read and determine I could have already produced the correct result.

I have it turned off at this point.

In the same vein of simplifying PGP, I wrote this little app a while ago:

https://prettyeasyprivacy.xyz

Basically a simple GUI on top of PGP. No CLI headache and is completely independent of OS. Encrypted sources follow PGP protocol so are completely backward compatible with CLI tools. Also supports both text and file encryption/decryption.

PGP impl uses proton's openPgp.js

Perhaps it's time for a "hot take" filter on top of a twitter feed. Instead of sentiment analysis, benchmark and rank on originality. I wonder if such a project exists.

If I were at Twitter and received this email, I would be providing code and commits focused on business impact. Saliency is scoped to something, and without explanation that 'something' is likely the business. The context is engineering at twitter, not programming. In other words, not silly one liners that are not immediately obvious but instead business critical code that moved the needle -- however bland.

For a raw ground up experience you could start with W3 schools.

If you wanted to learn via video and you want html/css/js, search 'vanilla javascript website.'

Currently "vanilla javascript" usually means a native browser website free of npm/node/ecosystem.

To serve a plan old site like this: google, "how to serve a static website", as that is what you are creating here.

Want a DB or persistence? Now you need an api. After creating your static site, now you need an api on a server somewhere. Any tutorial on creating an api (in whichever language you like) will probably work.

Now you have options, 1) run a startic web server for your website (this can be done for free via github pages btw) and run another server for your api

2) run two one single server with two different applications-- your api and you static web server (now you need a reverse proxy)

3) run a single server/api that both serves you static website and handles communications.

Easiest/fastest: get a static site (html/images/css/js) made and up on github pages

For some sort of api, whip up an expressJs app with a node server to handle both serving your static site communication needs.