swap in hugo

Author: dormando

.github/workflows/pages.yaml

@@ -0,0 +1,76 @@
+# Sample workflow for building and deploying a Hugo site to GitHub Pages
+name: Deploy Hugo site to Pages
+
+on:
+  # Runs on pushes targeting the default branch
+  push:
+    branches: ["main"]
+
+  # Allows you to run this workflow manually from the Actions tab
+  workflow_dispatch:
+
+# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
+# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+# Default to bash
+defaults:
+  run:
+    shell: bash
+
+jobs:
+  # Build job
+  build:
+    runs-on: ubuntu-latest
+    env:
+      HUGO_VERSION: 0.133.1
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0  # fetch all history for .GitInfo and .Lastmod
+          submodules: recursive
+      - name: Setup Go
+        uses: actions/setup-go@v5
+        with:
+          go-version: '1.22'
+      - name: Setup Pages
+        id: pages
+        uses: actions/configure-pages@v4
+      - name: Setup Hugo
+        run: |
+          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
+          && sudo dpkg -i ${{ runner.temp }}/hugo.deb
+      - name: Build with Hugo
+        env:
+          # For maximum backward compatibility with Hugo modules
+          HUGO_ENVIRONMENT: production
+          HUGO_ENV: production
+        run: |
+          hugo \
+            --gc --minify \
+            --baseURL "${{ steps.pages.outputs.base_url }}/"
+      - name: Upload artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          path: ./public
+
+  # Deployment job
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

archetypes/default.md

@@ -0,0 +1,5 @@
++++
+title = '{{ replace .File.ContentBaseName "-" " " | title }}'
+date = {{ .Date }}
+draft = true
++++

content/_index.md

@@ -0,0 +1,61 @@
+---
+title: 'memcached documentation'
+date: 2024-08-30T16:06:02-07:00
+cascade:
+    type: docs
+---
+
+*Free & open source, high-performance, distributed memory object caching system*, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.
+
+Memcached is an in-memory key-value store for small arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.
+
+*Memcached is simple yet powerful*. Its simple design promotes quick deployment, ease of development, and solves many problems facing large data caches. Its API is available for most popular languages.
+
+See the [memcached.org about page](http://memcached.org/about) for a brief overview.
+
+### How Does It Work?
+
+Memcached is a developer tool, not a "code accelerator", nor is it database middleware. If you're trying to set up an application you have downloaded or purchased to use memcached, read your app's documentation. This wiki and community will not be able to help you.
+
+### What is it Made Up Of?
+
+ * Client software, which is given a list of available memcached servers.
+ * A client-based hashing algorithm, which chooses a server based on the "key".
+ * Server software, which stores values with their keys into an internal hash table.
+ * LRU, which determine when to throw out old data (if out of memory), or reuse memory.
+
+---
+
+## Design Philosophy
+
+### Simple Key/Value Store
+
+The server does not care what your data looks like. Items are made up of a key, an expiration time, optional flags, and raw data. It does not understand data structures; you must upload data that is pre-serialized. Some commands (incr/decr) may operate on the underlying data, but in a simple manner.
+
+### Logic Half in Client, Half in Server
+
+A "memcached implementation" is partially in a client, and partially in a server. Clients understand how to choose which server to read or write to for an item, what to do when it cannot contact a server.
+
+The servers understand how to store and fetch items. They also manage when to evict or reuse memory.
+
+### Servers are Disconnected From Each Other
+
+Memcached servers are unaware of each other. There is no crosstalk, no syncronization, no broadcasting, no replication. Adding servers increases the available memory. Cache invalidation is simplified, as clients delete or overwrite data on the server which owns it directly.
+
+### O(1)
+
+All commands are implemented to be as fast and lock-friendly as possible. This gives allows near-deterministic query speeds for all use cases.
+
+Queries on slow machines should run in well under 1ms. High end servers can serve millions of keys per second in throughput.
+
+### Forgetting is a Feature
+
+Memcached is, by default, a Least Recently Used cache. Items expire after a specified amount of time. Both of these are elegant solutions to many problems; Expire items after a minute to limit stale data being returned, or flush unused data in an effort to retain frequently requested information.
+
+No "pauses" waiting for a garbage collector ensures low latency, and free space is lazily reclaimed.
+
+See [LRU documentation](https://github.com/memcached/memcached/blob/master/doc/new_lru.txt) for more details on the latest algorithm.
+
+### Cache Invalidation
+
+Rather than broadcasting changes to all available hosts, clients directly address the server holding the data to be invalidated.

content/docs/_index.md

@@ -0,0 +1,4 @@
++++
+title = 'Docs'
+date = 2024-08-30T16:06:17-07:00
++++