alanplotko / alanplotko.github.io Goto Github PK

• Sidebar should collapse on mobile.
• Tags should be larger and less rounded. Can be moved to the top as well in the post header.

Pagespeed results are at 100%, but there are a few recommendations elsewhere that can reduce number of requests or request size. Cloudflare caching, however, already takes care of things.

Minifying files and using Cloudflare-hosted resources:

• Webfont 1.6.26
• jQuery 3.2.1
• Minify Google fonts (https://fonts.googleapis.com/css?family=Roboto:300,500)

Example: https://umami.is/ self-hosted on Heroku or Vercel.

See GitHub docs for implementation details.

Right now, there are too many conflicting styles sitting atop one another to override CSS in the right direction. The theme should prioritize responsiveness across devices and accessibility. The two styles that make up the theme can be consolidated to one that is fully built on bootstrap after applying the reboot stylesheet. This will also make the dark theme more feasible to build out by using the darkmode.js script and HTML dark class to swap out just the bootstrap component colors on click.

• Build up from bootstrap theme to replace current blog theme. Set default for 1 rem to 16px.
• Move from skeleton CSS framework to reboot style and simple centering for front page.
  • After some testing, fixed purgecss to address the front page and blog separately in 76ba2c8. Skeleton css framework works fine as is, but can also consider normalize css + centering using absolute position and translate + default font sizes.

Switch from Foundation to Materialize CSS and refactor current CSS.

Reviewing the Options

Comments

• utterance.es
• Commento
• Staticman

Likes

• applause-button-server

Self-hosting

• Heroku
• Google Sheets in combination with any self-hosted or externally hosted API to do reads/writes
  • Can be combined with cron job to build regularly to retrieve latest comments into _data/ and rebuild the site

External Hosting

• For likes and comments: Webmentions
  • Consider self-hosting on Heroku? 10k row limit on free Postgres tier.
• Can use CSS to appear as a clap, but externally host counts via likebtn
• For comments: Remarkbox
• Cloudflare Workers / KV storage
  • Can use for applause button server and invoking staticman comments?

Brainstorming

Heroku allows running a free web dyno for 1000 hours a month if the account is verified. Given 31 days * 24 hours = 744 hours in a month at most, you can run 24/7 with pinging services like New Relic to keep the dyno from sleeping. That still leaves enough for one-off dynos on the side if needed.

There aren't many options that handle both likes and comments in one dyno, so either:

1. Extend likes into an existing node option, e.g. Staticman is basically just running a bunch of routes, and more can be added for counting likes and then deployed altogether on a dyno.
2. Separate likes and comments into Heroku and something else.

Approach

Let's go with option 2.

Staticman can be hosted with Heroku and is the most lightweight to embed into the Jekyll blog (it's static!). Testing can be done with create sample data files with comments. Staticman can also be deployed via netlify as a serverless function.

The Cloudflare KV store offering is sufficient to track likes and caching can be implemented at edge. The like counter is a simple increment, following Medium system of up to 50 points per user. The browser's local storage can track capacity up to 50 point allotment.

Use reading time plugin that includes improved WPM calculations by filtering out exceptions to the total word count like code blocks. The pluralize filter can help with the output as well.

Note: Make sure the sitemap generates correctly and that it does not conflict with the home page.

Show all non-forked, owned GitHub repositories on the projects page. All GitHub repositories run off http://dev.alanplotko.com, so the home site would show a listing of all repositories as cards (potentially via using GitHub Repositories API with jQuery/JavaScript/Ajax).
`
GitHub API URL: https://api.github.com/users/USERNAME/repos

• Custom domain + SSL limitations on Heroku don't exist in Vercel
• Option in Vercel to make Staticman serverless.

PurgeCSS will remove any unused styles and can be added to the gulpfile.

Cors headers should be set to appropriate domains for production.

Services

• Cloudflare (Caching, headers/cookies)
• Service Workers (Local)
• GitHub Pages (Hosting)
• Comments (via GitHub)
• Postgres DBs (for storing aggregate clap data, individual data kept to local storage)
• Analytics (for understanding how visitors engage with the site)

Show table of contents in post if floating table of contents does not fit.

Add SEO plugin to generate necessary meta tags for posts.

Background

PWA service worker at sw.js has been configured to bypass Cloudflare caching. Alternatively, caching can be allowed with query strings (e.g. ?v={{ site.time | date: '%s' }}) or file hashes via the gulp build, e.g. example.<hash>.js to ensure Cloudflare sees the updates. gulp-hash and gulp-hash-references could work.

Current Scenario

I use cdnjs for external assets (stylesheets and scripts), as it is hosted with Cloudflare too. This can help consolidate requests to the same zone while getting internal assets.

Caching currently follows:

1. On disk cache.
2. On service worker cache, including HTML files, with stale while revalidate. If a new sw.js comes in with new hashes, it will serve next time around. The sw.js script is not cached.
3. If the service worker needs to fetch latest, or if not installed (first-time visit), then it will go to Cloudflare for the asset. Cloudflare has all but the HTML cached, so HTML will always be latest, but the rest have 8 days before expiring.

Brainstorming

• Caching of 8 days can be updated to respect query strings instead, so that the cache is updated on build.
• Consider letting Cloudflare cache all HTML content, but then it will need to identify changes, e.g. API call to Cloudflare in GitHub Actions workflow to purge HTML files.
• sw.js will not be cached on Cloudflare, so that it will be fetched every time. If an HTML file changes, the service-worker will reflect it on next fetch. HTML files reference assets with query strings, so changes will in turn prompt latest from Cloudflare.
• The service worker also caches these assets, so the caching strategy will need to work alongside Cloudflare.

Automate taking backups using mongodump.