When I have some downtime, I tend to “reassess my life” lol. And my primary pain point in my nerd dev life has been my abusive requirements of my ever-failing browsers.

So far my best solution was terrible: use firefox for everything i can possibly use it for to support FOSS and get privacy, use ublock origin everywhere, use chrome for dev for performance, then switch to use firefox for dev when sick of problems (solved, nothing, ff has all kinds of problems too), use chrome for personal stuff that needs creditcards since FF is borked, use ff profiles – broken, use chrome profiles – broken, be told by FF that i can’t open or refresh tabs until i restart due to behind the scenes updates (this really broke my ability to justify FF), completely swear off chrome bc i don’t want big brother watching my every keystroke, have ff or chrome spew tabs everywhere on the wrong i3 desktops, go mad fixing them all…. nearly die from the stress of virtual memory hell as multiple browsers and dozens of profiles and thousands of tabs bring my machine to full lockup… BAD BAD BAD.

Brave solved it all.

It’s another chromium variant. This is excellent because it is FOSS and also enhanced beyond the things that Google has left broken in vanilla chromium. There are several chromium enhancements out there that are a huge step forward from FF or Chrome. Vivaldi is another fun one I played with. But let’s go over how Brave is leveling me up:

• Wonderfully done multiple profiles, clearly marked with toolbar icon and color
• Profile sync across machines with a simple set of “sync code” words
• Profile reuse in Visual Studio Code javascript debugger (see wiki)
• Chromium extensions support
• Ad blockers built in, with opt-in to see ads and make money (no thanks tho)
• Tor built in to private windows
• One browser that does it all, saving me from gobs and gobs of memory allocations and CPU hogging trying to run multiple browsers
• And that juicy chromium blink and V8 javascript engine speed

P.S. I LOVE you Mozilla but you need a complete rewrite in asm/C/C++ to keep up with Chromium’s performance… and STOP with the crippling freeze-on-background-updates. Please keep trying.

I was happy with Google Domains, but like everything good that they do, they killed it. Without asking for confirmation, they pushed the entirety of their DNS registrations to SquareSpace. World class, Google. It forced me to search a bit and discover that even the little guys can get Cloudflare protection, wholesale. Damn I love them.

The domain transfer process takes work, here’s a rundown of tasks:

• At google domains, turn off autorenewal and unlock your domain
• At cloudflare domains, add your site, extracting in the existing DNS records; it’s messy but helpful; strip out the bad ones
• At google domains, under DNS, click the non-obvious “custom DNS servers” material-view “tab” (gross)
  • change all the DNS servers from google to cloudflare (see cloudflare instructions)
  • turn off DNSSEC by removing all records
• Start the transfer process at cloudflare; it will make you wait until it can actually pull the updated name server changes
• Once cloudflare sees the name changes, it will allow you to select the “Free” plan and finish setup; but that does not mean the site has been transferred yet
• On cloudflare, continue the transfer, pasting in a transfer code you copied from google
• Once you think everything is in place, it still won’t work until you change SSL mode from “Flexible” (WTF is that!) to Full (strict), so it properly uses my Lets Encrypt certificates.
• Also… EVENTUALLY… you will receive confirmation email from google. Click through that and finally, google and cloudflare will confirm the transfer.

The good news is, even though the process typically requires extension of the renewal by another year (unless the last renewal was very recent), it is an extension (you don’t lose renewal time).

I bought a sweet DJI FPV drone and I’m getting certified for commercial operation. It was more work than I expected – until you consider that you are basically the pilot of an aircraft. Better know the rules of our National airspace – now with 1000 acronyms! Don’t worry, got you covered on my wiki. Soon you will be reading these crazy charts…

CORS is dumb. CORS is here to stay. CORS has a bit of usefulness. As my daughter opined recently, cry me a river, build a bridge, and get over it.

After spending days on it, I now have a five minute fix for CORS in a dev environment where the frontend is split from the backend during development.

GIVEN:

• a server that serves up your RESTful API using backend data
• that same server, serving up your nicely bundled front end, after you bake it for prod
• https in prod, and http in dev
• a modern front end development environment that maximizes your local web development speed while also bundling it tight for prod ( 💕 Vite 💕 )

You may have been sailing along with that sweet setup for a while now. But then one day, CORS arrives in your neighborhood. Perhaps you realize your Node front end can now use native fetch(), how nice (at first). Or your browser just got updated and all of a sudden it’s very unhappy serving your JWT tokens. Any way you get there, you will probably hit CORS issues. They tell you you are a bad person for trying to reach your backend from your frontend. Bad dev!

The problem is that is actually now blocked as a cross-site request. This blockage is now ubiquitous. How else can you still get to your favorite awful monster sites if they are sideloading dozens of malware ads? Why should megasite be responsible for the ads they serve? Let the browser block them! We need to protect the sheeple!! But i digress…

To fix your CORS issues, quickly, you simply add proxying to your Vite environment. The proxy takes all your backend calls, sends them off, and when they return, gently stuffs all the weird painful CORS headers you need in the response to keep your frontend from having a seizure.

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  server: {
    // For back end calls, make sure to use the API prefix.
    // Our vite dev environment will proxy those calls to the back end,
    // and return them to us, with fetch's xss concerns disabled via CORS:
    //    front -> proxy -> back -> proxy -> (ADD CORS) -> front
    proxy: {
      '/api': {
        'target': 'http://backend:8080',
        changeOrigin: true,
      },
    },
    port: 8008,
  },
})

Beautiful. In addition to that, if you can just slightly touch your server side cookie header to make it fit the CORS rulebook, you can get all that cross-site protection in prod, and never deal with a CORS issue in local dev again:

if (dev_environment) {
    cookie_header += " SameSite=Lax;";
  } else {
    cookie_header += " Secure; SameSite=Strict;";
  }

The internet has officially crossed over from a source of generally good information to a floating island landfill of outdated plastic shrapnel.

Just trying to find “today’s” best-practice for simply fetching data in a React app turns into an exhausting ritual of filtering for hours. Thank goodness for subreddit and stack overflow ratings metadata, and this answer in particular, and tools like npmtrends.

No one can ever say that software development is boring…