Coder Social home page Coder Social logo

infra's Introduction

Cubing infra

Infrastructure info for projects associated with the following:

Key

  • NC β€” Namecheap1
  • DH β€” DreamHost1
  • GCE β€” Google (Cloud) Compute Engine 1
  • CF β€” Cloudflare1
  • GH β€” GitHub (under github.com/cubing)
  • SW β€” offline support through service worker

Sites & Apps

Site / App Regis-tration DNS Hosting Repo Dev Port Deployment
alg.cubing.net NC DH GH Pages2 cubing/alg.cubing.net N/A In-tree docs folder
cdn.cubing.net NC DH DH + CF cubing/cdn.cubing.net 3336 rsync (cubing_deploy@) + CF API
icons.cubing.net NC DH GH Pages2 cubing/icons N/A GH Actions
js.cubing.net NC DH GH Pages2 cubing/cubing.js 33333 GH Actions
scramble.cubing.net NC DH DH + SW cubing/scramble.cubing.net 3335 rsync (lgarron@)
timer.cubing.net NC DH DH + SW cubing/timer 3334 rsync (lgarron@)
alpha.twizzle.net NC DH DH cubing/cubing.js 33333 rsync (cubing_deploy@)
api.twizzle.net4 NC DH5 GCE + Deno cubing/api.twizzle.net 3337 gcloud compute scp
archive.cubing.net NC DH GH Pages2 cubing/archive.cubing.net N/A In-tree root folder
standards.cubing.net NC DH GH Pages2 cubing/standards N/A In-tree root folder
qqtimer.net NC NC GH Pages cubing/qqTimer N/A In-tree docs folder
cubing.org NC NC GH Pages cubing/cubing.org N/A In-tree root folder
cubing-org.slack.com N/A N/A Slack N/A N/A N/A
scramble-table N/A N/A N/A cubing/scramble-table 3338 N/A

Organizations

GitHub

Certain repos have elevated privileges for maintainers. (TODO: document these.)

npm

Conventions

  • We generally publish code under one of the following licenses:
    • Dedicate to the public domain using the Unliense.
    • MPL: for projects we want to encourage open collaboration for.
    • MIT: for projects with permissive usage.
    • GPL: Do not use for new projects. Use the MPL instead.
  • Makefile conventions: https://github.com/lgarron/Makefile-convention, particularly: make dev and make build
  • Add a CI.yml GitHub Actions workflow to build and run any tests. Do not not use any secrets in testing.
  • JS projects:
    • Language: TypeScript
    • Bundler: esbuild
    • Formatter: biome

Many of these conventions are available in: https://github.com/lgarron/ts-project-template

Footnotes

  1. Currently @lgarron's personal account. ↩ ↩2 ↩3 ↩4

  2. Verified for github.com/cubing (config) ↩ ↩2 ↩3 ↩4 ↩5

  3. Shared ↩ ↩2

  4. Used by: https://twizzle.net/stream ↩

  5. A record: 35.236.43.166 ↩

infra's People

Contributors

lgarron avatar

Watchers

 avatar  avatar

infra's Issues

Stop using Dreamhost

With all due respect to their stability over the last decade, Dreamhost's DNS and HTTPS functionality is β€” let me put this politely β€” garbage. Their support is fairly responsive, but doesn't actually fix the fundamental issues that have taken our sites offline about 10 times over the past year, without any permanent workarounds I can use: https://twitter.com/lgarron/status/1592018042959323137

There are also several other issues, such as:

  • Each deployed site can only be accessed by one user β€” there is no practical way to do access control, despite "unlimited" users and storage.
    • In particular, it's impossible to give a user read-only access, which means that we can't set up a user to access the server for backups without also giving it write access to everything.
  • They only do ACME validation using /.well-known, which affects the hosted files on disk. This feels like an amateur implementation (they control our DNS, and could easily be using that instead!), and has caused troubles for me in the past.
  • I have yet to figure out how to set up proper secure email on Dreamhost. One of the I have set up is being spoofed by spammers to send mail to itself. I need something which properly implements DKIM and MTA-STS.
  • Their panel is slow, and has issues with doing multiple things in parallel (such as opening a bunch of sites in different tabs to change a config in all of them at once… because you have to do it slowly and manually for each individual site).
  • Dreamhost is on the trailing edge of security standards, across the board. They implemented Let's Encrypt certs very late (and badly, as documented above), and dreamhost.com doesn't even use HSTS. Their email interface was unencrypted for the longest time.

This is blocked on:

As an alternative, we need something which can provide the following features:

  • Host several dozen domains, without manual or time-consuming config per site.
  • Good static hosting for most domains, ideally with a low-fuss way to set up node-based servers on other domains. I'm okay with leaving PHP in the dust, so that our org can go all-in on JS (which is much more welcoming to new contributors and potential maintainers).
  • 10 seconds to deploy. I know this sounds fussy, but given the realities of service workers, caching, and CDNs (and limited volunteer time), we often need to test or confirm things in production, sometimes while live debugging with a collaborator or user. We've made great gains in bringing down compile times for all our project, and I don't want it to lost it all to a slower deploy1.

https://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/

10 Seconds

After 1 second, users get impatient and notice that they're waiting for a slow computer to respond. The longer the wait, the more this impatience grows; after about 10 seconds, the average attention span is maxed out. At that point, the user's mind starts wandering and doesn't retain enough information in short-term memory to easily resume the interaction once the computer finally loads the next screen.

> cd ~/Code/git/github.com/cubing/cubing.js
> time make clean deploy-twizzle
[...]
Executed in    9.43 secs      fish           external
[...]

Footnotes

  1. You could argue that it shouldn't be "too easy" to deploy, because that could make it easy to break things. But I would argue that this should be tackled by other means: tests, deploy checks, access controls, staging environments, automated status checks, etc. ↩

Change away from `cubing.github.io` for hosting

We own cubing.net and several other domains, and I would like to avoid any unnecessary dependencies on services. To avoid a hard dependency on GitHub, I'd like to stop using cubing.github.io for any hosting. We've been fairly good about avoiding it, but I'd like to migrate the remaining sites (with a redirect, of course).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.