1. 15 Nov, 2021 1 commit
  2. 23 Aug, 2021 1 commit
  3. 26 Jul, 2021 1 commit
  4. 19 Jun, 2021 1 commit
  5. 13 Mar, 2021 1 commit
  6. 11 Mar, 2021 6 commits
  7. 06 Jan, 2021 9 commits
  8. 05 Jan, 2021 4 commits
    • doshitan's avatar
      Add .smallcaps CSS utility class · 238227b5
      doshitan authored
    • doshitan's avatar
      Allow word wrapping in links globally · 07f6475f
      doshitan authored
    • doshitan's avatar
      Refine dark mode for code elements · 1de80803
      doshitan authored
      Give code elements a different background color, setting them off from
      regular text. Maybe one day I'll be able to structure documents such
      that it's not required, but that's not today, things feel more clear and
      readable with some explicit delineation. The print styles carry on
      without a background color for ink-saving.
      As a part of this, switch all code blocks to be content wide instead of
      full width by default. It's not perfect, particularly for code blocks
      with line numbers enabled, but I don't tend to use those, so punting on
      that for now.
      Use zenburn for dark code theme.
    • doshitan's avatar
      Basic dark mode · bf4edf40
      doshitan authored
  9. 18 Dec, 2020 2 commits
    • doshitan's avatar
      Don't version search data to avoid updating every HTML page when any content changes · d6ae84d3
      doshitan authored
      The search index will change when any content changes and the client
      side search JS references the index file URL. So if we hash the index
      file, that changes the hash of the JS that references the new name,
      which in turn, changes the JS `script` tag for all HTML pages, which
      means we have to upload new versions of every HTML page when content
      anywhere on the site changes.
      Not that big of a deal, but I'd rather deploys not have to upload and
      invalidate every page on the site when unrelated stuff changes.
      So instead use a stable address for the search index URL and have it be
      a resource that we ask the browser to always revalidate (like for the
      HTML content itself) instead of allowing a long cache lifetime.
    • doshitan's avatar
      Minor page updates/formatting fixes · 1edebfd5
      doshitan authored
  10. 13 Dec, 2020 1 commit
  11. 07 Dec, 2020 2 commits
  12. 06 Dec, 2020 10 commits
    • doshitan's avatar
      Update to terraform 0.13 (as step to 0.14) · 766bc5f2
      doshitan authored
    • doshitan's avatar
      Update CloudFront Security Policy to TLSv1.2_2019 · 0495517f
      doshitan authored
      Drops support for the last few `TLS_RSA_*` ciphers, specifically:
      - TLS_RSA_WITH_AES_128_GCM_SHA256
      - TLS_RSA_WITH_AES_256_GCM_SHA384
      - TLS_RSA_WITH_AES_128_CBC_SHA256
      Which at this point in history, should not impact many systems.
    • doshitan's avatar
      files.doshitan.com infra · 13de3726
      doshitan authored
    • doshitan's avatar
      Allow Let's Encrypt to issue certs for doshitan.com · 911ca226
      doshitan authored
      And move CAA block towards the top of DNS stuff.
    • doshitan's avatar
      Minor terraform formatting tweaks · 684d2f36
      doshitan authored
    • doshitan's avatar
    • doshitan's avatar
      Switch CloudFront Lambda to origin-response · 6c8c3bde
      doshitan authored
      Actually been running this configuration for a year or so, but never
      committed it.
      `viewer-response` Lambdas are invoked for every response from CloudFront
      -> user, so the response after processing by the Lambda is not stored in
      CloudFront. Good for highly dynamic stuff. But also means the Lambda
      gets invoked on *every* response from CloudFront, which can add
      latency (and monetary cost).
      `origin-response` Lambdas are invoked for every response from the origin
      -> CloudFront, so the output *is* cached in CloudFront. This means the
      cost of the Lambda is only paid when CloudFront needs to reach back to
      the origin for a resource. But it also means if there are changes made
      the Lambda, will need to invalidate everything in CloudFront in order to
      pick up the changes uniformly.
      Since the current deploy process invalidates updated paths in
      CloudFront, we can set the cache control header for files that are not
      versioned by name, e.g., the HTML pages, to have a long cache lifetime
      in CloudFront (`s-maxage`), while ensuring browsers/users also check
      they are getting the latest content (`max-age=0,must-revalidate`)
      CloudFront has. Goal being to help CloudFront have to check with the
      origin as little as possible, should serve from it's cache immediately.
    • doshitan's avatar
    • doshitan's avatar
      Version assets in the correct order · 84880a34
      doshitan authored
    • doshitan's avatar
      flake-ify nix setup · acf3de1a
      doshitan authored
      Nix flakes are still experimental, but why not experiment.
  13. 15 Oct, 2020 1 commit