Initial import.
This commit is contained in:
commit
41a42c7a59
|
|
@ -0,0 +1,2 @@
|
|||
__pycache__
|
||||
output
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
PY?=python3
|
||||
PELICAN?=pelican
|
||||
PELICANOPTS=
|
||||
|
||||
BASEDIR=$(CURDIR)
|
||||
INPUTDIR=$(BASEDIR)/content
|
||||
OUTPUTDIR=$(BASEDIR)/output
|
||||
CONFFILE=$(BASEDIR)/pelicanconf.py
|
||||
PUBLISHCONF=$(BASEDIR)/publishconf.py
|
||||
|
||||
|
||||
DEBUG ?= 0
|
||||
ifeq ($(DEBUG), 1)
|
||||
PELICANOPTS += -D
|
||||
endif
|
||||
|
||||
RELATIVE ?= 0
|
||||
ifeq ($(RELATIVE), 1)
|
||||
PELICANOPTS += --relative-urls
|
||||
endif
|
||||
|
||||
help:
|
||||
@echo 'Makefile for a pelican Web site '
|
||||
@echo ' '
|
||||
@echo 'Usage: '
|
||||
@echo ' make html (re)generate the web site '
|
||||
@echo ' make clean remove the generated files '
|
||||
@echo ' make regenerate regenerate files upon modification '
|
||||
@echo ' make publish generate using production settings '
|
||||
@echo ' make serve [PORT=8000] serve site at http://localhost:8000'
|
||||
@echo ' make serve-global [SERVER=0.0.0.0] serve (as root) to $(SERVER):80 '
|
||||
@echo ' make devserver [PORT=8000] serve and regenerate together '
|
||||
@echo ' make ssh_upload upload the web site via SSH '
|
||||
@echo ' make rsync_upload upload the web site via rsync+ssh '
|
||||
@echo ' '
|
||||
@echo 'Set the DEBUG variable to 1 to enable debugging, e.g. make DEBUG=1 html '
|
||||
@echo 'Set the RELATIVE variable to 1 to enable relative urls '
|
||||
@echo ' '
|
||||
|
||||
html:
|
||||
$(PELICAN) $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS)
|
||||
|
||||
clean:
|
||||
[ ! -d $(OUTPUTDIR) ] || rm -rf $(OUTPUTDIR)
|
||||
|
||||
regenerate:
|
||||
$(PELICAN) -r $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS)
|
||||
|
||||
serve:
|
||||
ifdef PORT
|
||||
$(PELICAN) -l $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS) -p $(PORT)
|
||||
else
|
||||
$(PELICAN) -l $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS)
|
||||
endif
|
||||
|
||||
serve-global:
|
||||
ifdef SERVER
|
||||
$(PELICAN) -l $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS) -p $(PORT) -b $(SERVER)
|
||||
else
|
||||
$(PELICAN) -l $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS) -p $(PORT) -b 0.0.0.0
|
||||
endif
|
||||
|
||||
|
||||
devserver:
|
||||
ifdef PORT
|
||||
$(PELICAN) -lr $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS) -p $(PORT)
|
||||
else
|
||||
$(PELICAN) -lr $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS)
|
||||
endif
|
||||
|
||||
publish:
|
||||
$(PELICAN) $(INPUTDIR) -o $(OUTPUTDIR) -s $(PUBLISHCONF) $(PELICANOPTS)
|
||||
|
||||
|
||||
.PHONY: html help clean regenerate serve serve-global devserver stopserver publish
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 326 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 326 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 112 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
|
|
@ -0,0 +1,4 @@
|
|||
Title: About
|
||||
Slug: about
|
||||
|
||||
This notebook covers a project to build my own knowledge management system.
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
Title: Bullet Journal Notes
|
||||
|
||||
[](/files/i/bullet_scan.jpg)
|
||||
|
||||
The original notes from my bullet journal that I took on my exocortex
|
||||
are found on page 109-110 of that journal; page 108 is journal entries
|
||||
for 2021-02-08 and 2021-02-16; page 111 starts with 2021-02-17. The
|
||||
first entry in the mercurial logs for the first pass I started last
|
||||
year was 2021-02-14.
|
||||
|
||||
* Goal
|
||||
- Collect artifacts + notes → current knowledge
|
||||
- Daily writeups
|
||||
* Ex.
|
||||
- Gemlog
|
||||
- notes.org
|
||||
- books/*.org
|
||||
- PDF docs
|
||||
* SCM is a red herring
|
||||
* Evernote
|
||||
- notes/folders
|
||||
- clipper
|
||||
- tags
|
||||
- everything searchable
|
||||
- synced (may be red herring)
|
||||
* Quiver
|
||||
- cell types
|
||||
* Jupyter notebooks
|
||||
- code
|
||||
- markdown
|
||||
* swolfram
|
||||
- [archive](https://writings.stephenwolfram.com/2019/02/seeking-the-productive-life-some-details-of-my-personal-infrastructure/)
|
||||
* Solution
|
||||
- Minimal viable metadata
|
||||
- Data
|
||||
- Tags
|
||||
- Artifact link
|
||||
- Central artifact repo
|
||||
- Hash/link
|
||||
- Node type (article, notes, ...)
|
||||
- Type: Node = Folder|Page|Artifact
|
||||
- How to create a searchable index?
|
||||
- Retain old copies
|
||||
- Index header
|
||||
- Date retrieved
|
||||
- Doc ID
|
||||
- Source
|
||||
* Artifact header
|
||||
- Needs to support history
|
||||
- Doc ID
|
||||
- Date retrieved / stored
|
||||
- Artifact date
|
||||
- Source
|
||||
- Artifact type
|
||||
- Tags
|
||||
- Category
|
||||
- Blobs
|
||||
- Format
|
||||
- Blob ID
|
||||
* Central artifact repository
|
||||
- Metadata index
|
||||
- Blob store
|
||||
- Upload interface
|
||||
* Elements of an exocortex
|
||||
- Artifacts
|
||||
- Artifact repository
|
||||
- Notes
|
||||
- Structure
|
||||
- UI
|
||||
- Query
|
||||
- Exploratory
|
||||
- Presentation
|
||||
- Update
|
||||
- Locality
|
||||
- Totality
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
Title: Historical Notes
|
||||
Slug: index
|
||||
|
||||
These pages track the origins of the exocortex.
|
||||
|
||||
* [Original bullet journal notes](/historical/bullet_notes)
|
||||
* [On exocortices](/historical/on_exocortices)
|
||||
|
|
@ -0,0 +1,299 @@
|
|||
Title: On Exocortices
|
||||
|
||||
*This is from a gemlog post written on 2021-02-10.*
|
||||
|
||||
This is a rough draft on some thoughts about exocortices that has been
|
||||
simmering in the back of my mind lately. The catalyst for writing it
|
||||
was reading Stephen Wolfram's (with all caveats that come with reading
|
||||
his posts) entry "Seeking the Productive Life: Some Details of My
|
||||
Personal Infrastructure".
|
||||
|
||||
This is a rough draft on some thoughts about exocortices that has been
|
||||
simmering in the back of my mind lately. The catalyst for writing it
|
||||
was reading Stephen Wolfram's (with all caveats that come with reading
|
||||
his posts) entry "Seeking the Productive Life: Some Details of My
|
||||
Personal Infrastructure".
|
||||
|
||||
## Background
|
||||
|
||||
An exocortex is "a hypothetical artificial information-processing
|
||||
system that would augment a brain's biological cognitive processes." I
|
||||
have made many attempts at building my own, including
|
||||
|
||||
* A web-based wiki (including my own custom solution, gitit,
|
||||
MediaWiki, and others.
|
||||
* Org-mode based notes, including my current notes/notes.org system
|
||||
(with subdirectories for other things such as book notes)
|
||||
* Evernote / Notion
|
||||
* The Quiver MacOS app
|
||||
* Experimenting in building custom exocortex software (e.g. kortex)
|
||||
* A daily weblog (e.g. the old ai6ua.net site) and gemlog to summarize
|
||||
important knowledge gained that day.
|
||||
|
||||
Each of these has their own shortcomings that don't quite match up
|
||||
with my expectations or desires. An exocortex must be a personalized
|
||||
system adapted to its user to maximise knowledge capture.
|
||||
|
||||
Succinctly put, the goal of an
|
||||
[exocortex](https://en.wiktionary.org/wiki/exocortex) is to collect
|
||||
artifacts and notes (including daily notes), organize them, and allow
|
||||
for written summaries of current snapshots of my knowledge. Put
|
||||
another way, "artifacts + notes + graph structure = exocortex". Note
|
||||
that a folder hierarchy is a tree, which is a form of directed
|
||||
graph. Symlinks inside a folder act as edges to notes outside of that
|
||||
folder, refining the graph structure.
|
||||
|
||||
This writeup is an attempt at characterising and exploring the
|
||||
exocortex problem space to capture my goals, serve as a foundation for
|
||||
the construction of such a system, and, through discussion of the
|
||||
problem space, tease out the structure of the problem to discover a
|
||||
closer approximation to the idealized reality of an exocortex system.
|
||||
|
||||
## The elements of exocortices
|
||||
|
||||
The elements of an exocortex, briefly touched on above and expanded
|
||||
below, include
|
||||
|
||||
* artifacts,
|
||||
* the artifact repository,
|
||||
* notes,
|
||||
* structure,
|
||||
* a query interface,
|
||||
* an exploratory interface,
|
||||
* a presentation interface,
|
||||
* an update interface,
|
||||
* locality, and
|
||||
* totality.
|
||||
|
||||
### Artifacts
|
||||
|
||||
An artifact is any object that is not a textual writeup by me that
|
||||
should be referenceable as part of the exocortex. A copy of a paper
|
||||
from ArXiV might serve as an artifact. Importantly, artifacts must be
|
||||
locally-available. They serve as a snapshot of some source of
|
||||
knowledge, and should not be subject to link decay, future pay-walling
|
||||
(or loss of access to a pay-walled system), or loss of
|
||||
connectivity. An artifact should be timestamped: when was it captured?
|
||||
When was the artifact created upstream? An artifact must also have
|
||||
some associated upstream information --- how did it come to be in the
|
||||
repository?
|
||||
|
||||
### The artifact repository
|
||||
|
||||
An artifact may be relevant to more than one field of interest;
|
||||
accordingly, all artifacts should exist in a central repository. This
|
||||
repository should support artifact histories (e.g. collecting updates
|
||||
to artifacts, where the history is important in capturing a historical
|
||||
view of knowledge), multiple formats (a book may exist in PDF, EPUB,
|
||||
or other formats), and a mechanism for exploring, finding, and
|
||||
updating docs. The repository must capture relevant metadata about
|
||||
each artifact.
|
||||
|
||||
### Notes
|
||||
|
||||
A note is a written summary of a certain field. It should be in some
|
||||
rich-text format that supports linking as well as basic
|
||||
formatting. The ideal text format appears to be the org-mode format
|
||||
given its rich formatting and ability to transition fluidly between
|
||||
outline and full document; however, this may not be the final, most
|
||||
effective format. A note is the distillation of artifacts into an
|
||||
understandable form, providing avenues to discover specifics that may
|
||||
need to be held in working memory only briefly.
|
||||
|
||||
### Structure
|
||||
|
||||
A structured format allows for fast and efficient knowledge
|
||||
lookups. It grants the researcher a starting place with a set of rules
|
||||
governing where and how things may be found. It imposes order over
|
||||
chaos such that relevant kernels of knowledge may be retrieved and
|
||||
examined in an expedient manner. The metaphor that humans seem to
|
||||
adapt to the most readily is a graph structure, particularly those
|
||||
that are generally hierarchical in nature.
|
||||
|
||||
### A query interface
|
||||
|
||||
The exocortex and the artifact repository both require a query
|
||||
interface; they may be part of the same UI. A query UI allows a
|
||||
researcher to pose questions of the exocortex, directly looking for
|
||||
specific knowledge.
|
||||
|
||||
The four interfaces (query, exploration, presentation, and update) may
|
||||
all be facets of the same interface, and they may benefit from a
|
||||
cohesive and unified interface; however, it is important that all of
|
||||
these use cases are considered and supported.
|
||||
|
||||
### An exploratory interface
|
||||
|
||||
The exploratory interface allows a researcher to meander through the
|
||||
knowledge store, exploring topics and potentially identifying new
|
||||
areas to push the knowledge sphere out further.
|
||||
|
||||
### A presentation interface
|
||||
|
||||
The presentation interface allows a set of notes to be shared with
|
||||
others; it should be possible to include some or all artifacts
|
||||
associated with these notes. For example, it may not be appropriate to
|
||||
share a copy of a book with the presentation, but it may be
|
||||
appropriate to share a copy of some of the supporting papers.
|
||||
|
||||
### An update interface
|
||||
|
||||
The update interface is where knowledge is added to the exocortex,
|
||||
whether through capturing an artifact or writing notes.
|
||||
|
||||
### Locality
|
||||
|
||||
An exocortex must be localized to the user, with the full repository
|
||||
available offline. Quick input or scratch pad notes might be
|
||||
available, but realistically, the cost of cloud storage and the
|
||||
transfer sizes mean that having the full exocortex available is
|
||||
unlikely. Instead, a hybrid model allowing quick captures of knowledge
|
||||
available remotely combined with a full exocortex on a local system
|
||||
presents the probably best solution.
|
||||
|
||||
### Totality
|
||||
|
||||
An exocortex represents the sum of the user's knowledge. There aren't
|
||||
separate exocortices for different areas. Everything I know should go
|
||||
into my exocortex.
|
||||
|
||||
## Exploring the problem space
|
||||
|
||||
In order to map out the structure of an exocortex, it's useful to
|
||||
review what has worked and what hasn't. Each alternative presented
|
||||
will consider what worked and what didn't to clarify what an effective
|
||||
exocortex looks like.
|
||||
|
||||
### Git-backed wikis and plaintext folders
|
||||
|
||||
At a high-level, wikis like Gitit and folders of plain-text (including
|
||||
org-mode) data are roughly equivalent; the differences lie primarily
|
||||
in how they are presented. Neither approach works well for indexing or
|
||||
organizing artifacts, and while some approaches like a scanner that
|
||||
adds notes to a SQLite database (for improved search performance).
|
||||
|
||||
Using a folder of org-mode notes is probably one of the better
|
||||
note-taking interfaces that I have found; however, there is no notion
|
||||
of an artifact repository without considerable manual work.
|
||||
|
||||
The main downsides to this approach are the lack of good query and
|
||||
exploration UIs, along with the lack of a useful artifact
|
||||
repository. The upsides are good updates and presentation interfaces.
|
||||
|
||||
### Evernote and Notion
|
||||
|
||||
Evernote (and also notion) provide a unified, searchable interface
|
||||
across multiple machines. Evernote in particular has a usable artifact
|
||||
repository, although information about upstream sources isn't
|
||||
available, nor are metadata about the object or the idea of multiple
|
||||
formats and history.
|
||||
|
||||
Evernote is a paid service, and neither is particularly extensible to
|
||||
a user's needs. Exploring the exocortex is difficult, as there's no
|
||||
notion of an entry point. Presenting nodes is met with some success,
|
||||
albeit limited.
|
||||
|
||||
### Quiver
|
||||
|
||||
Quiver is an excellent note-taking application; however, it is
|
||||
MacOS-only. It does have some ability to import web pages, but in
|
||||
general it lacks any idea of an artifact repository. The ability to
|
||||
intersperse different cell types is good.
|
||||
|
||||
### Jupyter notebooks
|
||||
|
||||
Jupyter notebooks provide an excellent interface for interspersing
|
||||
computational ideas with prose; there is no notion of an artifact
|
||||
repository, however. Linking notebooks isn't supported, and there is
|
||||
no overall structure besides manual hyperlinking and a directory
|
||||
structure.
|
||||
|
||||
## The artifact repository
|
||||
|
||||
The artifact repository is one of the two pillars of the exocortex; it
|
||||
stores the "first hand" sources of knowledge.
|
||||
|
||||
### The central index
|
||||
|
||||
The first part of an artifact repository is a central index that
|
||||
provides
|
||||
|
||||
* references and linking to artifacts,
|
||||
* a "blob" store that contains the artifacts, and
|
||||
* some management interface that allows adding and editing metadata as
|
||||
well as adding artifacts.
|
||||
|
||||
An artifact entry in the index contains, at a minimm,
|
||||
|
||||
* An artifact identifier
|
||||
* Authorship information
|
||||
|
||||
The artifact identifier is used to associate all related artifacts
|
||||
(e.g. previous revisions, different formats, etc.)
|
||||
|
||||
### Artifacts
|
||||
|
||||
An artifact consists of multiple components:
|
||||
|
||||
* A primary metadata entry that organizes artifacts
|
||||
* Pointers to artifact "blobs"
|
||||
* A historical record of changed blobs
|
||||
|
||||
The metadata header for an artifact should contain, at a minimum,
|
||||
fields for
|
||||
|
||||
* Artifact identifier
|
||||
* A list of revisions
|
||||
|
||||
Each artifact can have zero or more blobs associated. For example, a
|
||||
physical book reference might not have a blob associated; an ebook
|
||||
might have multiple blobs corresponding to different formats; and a
|
||||
webpage snapshot may have mulitple blobs representing revisions to the
|
||||
page.
|
||||
|
||||
A blob header stores
|
||||
|
||||
* The artifact identifier
|
||||
* The date retrieved or stored
|
||||
* The date of the artifact itself
|
||||
* The source
|
||||
* Blob type information (e.g. a MIME type)
|
||||
* A list of categories
|
||||
* A list of tags
|
||||
|
||||
The headers should probably be stored in a database of some kind;
|
||||
SQLite is a good example for the first iteration. Blobs themselves
|
||||
will need to be stored on disk, probably in a format related to a hash
|
||||
of the blob contents, such as in a content-addressable store (CAS).
|
||||
|
||||
## The exocortex
|
||||
|
||||
The exocortex consists of a graph database that links notes. At a
|
||||
broad level, it should probably start with a root node that points to
|
||||
broad fields. The update interface should allow manipulation of nodes
|
||||
as graph nodes in addition to allowing for adding and editing notes. A
|
||||
node might be thought of as "type node = Note | ArtifactLink". That
|
||||
is, a note can link to other notes or to artifacts. A proper node
|
||||
title is the sum of the paths. For example, consider the following
|
||||
structure linked below:
|
||||
|
||||
[](/files/i/on_exocortices_graph.jpg)
|
||||
|
||||
Different possibilities for naming note3 include:
|
||||
|
||||
* root->note2->note3
|
||||
* root=>note2=>note3
|
||||
* root/note2/note3
|
||||
|
||||
Personally, I prefer the arrow notation with equal sign. Each note can
|
||||
be shortened to a partial path; e.g. "note2=>note3". The title for
|
||||
each note can be stored in a metadata entry.
|
||||
|
||||
|
||||
## Next steps
|
||||
|
||||
A first step is to start constructing an artifact repository. Once
|
||||
this is in place, a suitable graph database (for example,
|
||||
[cayley](https://github.com/cayleygraph/cayley)) should be identified,
|
||||
and an exocortex core developed. User interfaces will necessarily be
|
||||
developed alongside these systems.
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
Title: Pages
|
||||
|
||||
* [Historical context](/historical/)
|
||||
* [Design docs](/specs/)
|
||||
|
|
@ -0,0 +1,238 @@
|
|||
Title: Functional Spec for the Exocortex
|
||||
Tags: specs
|
||||
|
||||
kExocortex is a tool for capturing and retaining knowledge, making it
|
||||
searchable.
|
||||
|
||||
This is the initial top-level draft to sort out the high-level vision.
|
||||
|
||||
## Summary
|
||||
|
||||
The more you learn, the harder it is to recall specific things. Fortunately,
|
||||
computers are generally pretty good at remembering things. kExocortex is
|
||||
my attempt at building a knowledge graph for long-term memory.
|
||||
|
||||
In addition to having functionality like notetaking systems like
|
||||
[Dendron](https://dendron.so), I'd like to keep track of what I call artifacts.
|
||||
An artifact is a source of some knowledge; it might be a PDF copy of a book, an
|
||||
image, or a URL.
|
||||
|
||||
In a perfect world, I would have a local copy of everything with a remote backup.
|
||||
The remote backup lets me restore the exocortex in the event of data loss.
|
||||
|
||||
## Usage sketches
|
||||
|
||||
### Research mode
|
||||
|
||||
If I am researching a topic, I have a top-level node that contains all the
|
||||
research I'm working on. I can link artifacts to a note, including URLs. One of
|
||||
the reasons it makes sense to attach a URL to a document is that I can reuse
|
||||
them, as well as go back and search URLs based on tags or categories. It would
|
||||
make sense to tag any artifacts with relevant tags from the note once it is saved.
|
||||
|
||||
For example, let's say that I am research graphing databases. In Dendron, this
|
||||
note lives under `comp.database.graph`. I might find this O'Reilly book on
|
||||
[Neo4J](https://go.neo4j.com/rs/710-RRC-335/images/Neo4j_Graph_Algorithms.pdf)
|
||||
that discusses graph algorithms. I might link it here, and I might link it
|
||||
under a Neo4J-specific node. I would store the PDF in an artifact repository,
|
||||
adding relevant tags (such as "graph-database", "neo4j", "oreilly") and
|
||||
categorize it under books, PDFs, comp/database/graph/neo4j.
|
||||
|
||||
Going forward, if I want to revisit the book, I don't have to find it online
|
||||
again. It's easily accessible from the artifact repository.
|
||||
|
||||
The user interface for the knowledge graph should show a list of associated
|
||||
artifacts.
|
||||
|
||||
Nodes are also timestamped; I am leaning towards keep track of every time a
|
||||
page was edited (but probably not the edits). If I know I was researching
|
||||
graph databases last week, and I log the URLs I was reading as artifacts,
|
||||
I have a better history of what I was reading.
|
||||
|
||||
### Reading from a mobile device
|
||||
|
||||
Sometimes I'm on my iPad or phone, and I want to save the link I'm reading. I
|
||||
should be able to stash documents, URLs, etc, in the artifact repository. This
|
||||
implies a remote endpoint that I can enter a URL and a tag, and have that
|
||||
entered into the artifact repository later.
|
||||
|
||||
### Cataloging artifacts
|
||||
|
||||
If I've entered a bunch of artifacts, I should be able to see a list of ones
|
||||
that need categorizing or that aren't attached to a node.
|
||||
|
||||
### Autotagging
|
||||
|
||||
The interface should search the text of a note to identify any tags. This
|
||||
brings up an important feature: notes consist of cells, and each cell has a
|
||||
type. The primary use case is to support markdown formatting and code blocks,
|
||||
while not touching the code blocks during autotagging. For example,
|
||||
|
||||
```
|
||||
---
|
||||
node: today.2022.02.21
|
||||
---
|
||||
|
||||
I figured out how to get Cayley running in production.
|
||||
|
||||
\```
|
||||
cayleyd --some flag --other flag
|
||||
\```
|
||||
```
|
||||
|
||||
The exocortex would see Cayley, identify that as a node, and add the tags for
|
||||
that node to this one. It might see production and add that as a tag, e.g. for
|
||||
ops-related stuff.
|
||||
|
||||
### Fast capture
|
||||
|
||||
I should be able to enter a quick note, which would go under a daily node tree.
|
||||
Something like `quick.2022-02-27.1534`.
|
||||
|
||||
This would get autotagged. Quick notes might also get a metadata tag indicating
|
||||
whether I went back and integrated them into the rest of the knowledge graph.
|
||||
|
||||
One way I could use this might be to text or email a note, or to have a quick
|
||||
capture program on my computer.
|
||||
|
||||
|
||||
|
||||
## Requirements & Assumptions
|
||||
|
||||
What should it do? What assumptions are being made about it? What's
|
||||
considered "in scope" and what won't the project try to do?
|
||||
|
||||
Does it need to be compatible with any existing solutions or systems?
|
||||
|
||||
If it's a daemon, how are you going to manage it?
|
||||
|
||||
What are the dependencies that are assumed to be available?
|
||||
|
||||
## System Design
|
||||
|
||||
### Major components
|
||||
|
||||
The system has two logical components: the artifact repository and the
|
||||
knowledge graph.
|
||||
|
||||
#### Artifact repository
|
||||
|
||||
There should be, at a minimum, a local artifact repository. It will have its
|
||||
own tooling and UI for interaction, as well as being linked to the knowledge
|
||||
graph.
|
||||
|
||||
Previous prototypes stored artifact metadata in SQLite, and the contents of the
|
||||
artifacts in a blob store. The blob store is a content-addressable system for
|
||||
retrieving arbitrary data. A remote option might use an S3-equivalent like
|
||||
Minio.
|
||||
|
||||
#### Knowledge graph
|
||||
|
||||
The knowledge graph stores nodes. The current model stores the graph in SQLite,
|
||||
using an external file sync (e.g. syncthing) to sync the databases across
|
||||
machines.
|
||||
|
||||
### Data model
|
||||
|
||||
Previous prototypes used separate SQLite databases for the artifact repository
|
||||
and the knowledge graph.
|
||||
|
||||
#### Single SQLite database
|
||||
|
||||
The concern with a single SQLite database is that it would be accessed by two
|
||||
different systems, causing potential locking issues.
|
||||
|
||||
This could be solved by a single unified backend server; this is the preferred
|
||||
approach.
|
||||
|
||||
#### Split SQLite databases
|
||||
|
||||
The original prototype split the databases for performance reasons. However,
|
||||
this was based on any empirical evidence.
|
||||
|
||||
The major downside to this is that tags and categories are not shared between
|
||||
the artifact repository and the knowledge graph. Categories might make sense
|
||||
for splitting; e.g. an artifact category might be 'PDF' while a node might have
|
||||
the category 'Research'. However, tags should be shared between both systems.
|
||||
|
||||
#### PostgreSQL database
|
||||
|
||||
Another option is to to use postgres. This brings a heavy ops cost, while
|
||||
enabling a variety of replication and backup strategies.
|
||||
|
||||
### Architectural overview
|
||||
|
||||
[](/files/i/exo-arch.jpg)
|
||||
|
||||
There is a backend server, `exod`, that will have a gRPC endpoint for
|
||||
communicating with frontends. The approach allows for a reverse-proxy front end
|
||||
on a public server over Tailscale for remote devices. It also maintains a local
|
||||
blob store, the database, and a connection to a remote minio server for backing
|
||||
up blobs and retrieving missing blobs.
|
||||
|
||||
If a standard HTTP API is needed, it can be added in later. One potential use
|
||||
for this is for retrieving blobs (e.g. GET /artifacts/blob/id/...).
|
||||
|
||||
## Supportability
|
||||
|
||||
### Failure scenarios
|
||||
|
||||
#### Data corruption
|
||||
|
||||
If the data is corrupted locally, a local import from the remote end would
|
||||
restore it. Alternatively, it may be restored from local backups.
|
||||
|
||||
If the data is corrupted remotely, a local export to the remote end would
|
||||
restore it.
|
||||
|
||||
### Platform support
|
||||
|
||||
The main program would ideally run on Linux primarily, but I'd like to be able
|
||||
to use it on my Windows desktop too.
|
||||
|
||||
### Packaging and deployment
|
||||
|
||||
## Security
|
||||
|
||||
The gRPC endpoint should be authenticated. The system is intended to operate
|
||||
over localhost or a local network, so the use of TLS is probably untenable.
|
||||
[minica](https://github.com/jsha/minica) is an option, but then key rotation
|
||||
needs to be built in.
|
||||
|
||||
A possible workaround is to only enable authentication (HTTP basic auth will
|
||||
suffice) on the reverse proxy, which will also have TLS.
|
||||
|
||||
## Project Dependencies
|
||||
|
||||
The software should rely on no external sources, except for the software
|
||||
packages that it uses. This can be mitigated with vendoring.
|
||||
|
||||
## Open Issues
|
||||
|
||||
* If I track each time a page was edited, does it make sense to roll this up?
|
||||
e.g. I don't track edits to the second, but maybe to the hour or day.
|
||||
|
||||
|
||||
## Milestones
|
||||
|
||||
1. Specifications
|
||||
a. Write up spec for the artifact repository data structures.
|
||||
b. Write up a spec for the knowledge graph data structures.
|
||||
2. Core systems
|
||||
a. Build the artifact repository server.
|
||||
b. Build the backend for the knowledge graph.
|
||||
c. Build rough CLI interfaces to both.
|
||||
3. Build the user interfaces.
|
||||
a. Simple note taking.
|
||||
b. Artifact upload and searching by tag, content type, title.
|
||||
|
||||
## Review History
|
||||
|
||||
This may not be applicable, but it's usually nice to have someone else
|
||||
sanity check this.
|
||||
|
||||
Keep a table of who reviewed the doc and when, for in-person reviews. Consider
|
||||
having at least 1 in-person review.
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
Title: Design docs
|
||||
Tags: specs
|
||||
|
||||
* [Top-level functional spec](/specs/functional.html)
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
Title: 20220223
|
||||
Slug: 20220223
|
||||
Date: 2022-02-23 22:22 PST
|
||||
Modified: 2022-02-23 22:25 PST
|
||||
Category:
|
||||
Tags: journal
|
||||
Authors: kyle
|
||||
Summary: Design work on blobs.
|
||||
|
||||
I finished writing out the basic blob database and structure types. The
|
||||
blob was a structure like
|
||||
|
||||
```
|
||||
type Blob struct {
|
||||
ID string
|
||||
Header *Header
|
||||
ContentType string
|
||||
Contents []byte
|
||||
}
|
||||
```
|
||||
|
||||
I decided to make it an `io.Reader` to make it better handle large files;
|
||||
rather than load them entirely into memory, we can do a straight buffer.
|
||||
|
||||
```
|
||||
type Blob struct {
|
||||
ID string
|
||||
Header *Header
|
||||
ContentType string
|
||||
r io.Reader
|
||||
}
|
||||
```
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
#!/bin/sh
|
||||
|
||||
set -eu
|
||||
|
||||
imgdir="content/files/i"
|
||||
|
||||
for img in $@
|
||||
do
|
||||
imgbase="$(basename $img)"
|
||||
imgpath="${imgdir}/${imgbase}"
|
||||
cp $img $imgdir
|
||||
convert -resize 800x600 "$imgpath" "${imgdir}/t/${imgbase}"
|
||||
done
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
|
||||
Version 2, December 2004
|
||||
|
||||
Copyright (C) 2004 Sam Hocevar <sam@hocevar.net>
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim or modified
|
||||
copies of this license document, and changing it is allowed as long
|
||||
as the name is changed.
|
||||
|
||||
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
|
||||
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
|
||||
0. You just DO WHAT THE FUCK YOU WANT TO.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
Monospace
|
||||
==========
|
||||
|
||||
Theme adapted from [Monospace for Wordpress](http://wordpress.org/themes/monospace)
|
||||
Here is a screenshot for your viewing pleasure:
|
||||
|
||||
|
||||
|
||||
If you are using Markdown, you need to include the following option in your settings file to enable syntax highlighting.
|
||||
|
||||
MD_EXTENSIONS = ['codehilite(css_class=codehilite code)']
|
||||
|
||||
Also, you might want to include the `DESCRIPTION` option (it appears in the left sidebar):
|
||||
|
||||
DESCRIPTION = 'My blog and stuff ...'
|
||||
|
||||
Nice and simple,
|
||||
Enjoy!
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
body {
|
||||
margin: 0;
|
||||
padding: 20px 0;
|
||||
text-align: center;
|
||||
font-family: Monospace;
|
||||
color: #222;
|
||||
}
|
||||
|
||||
a,a:visited {
|
||||
text-decoration: none;
|
||||
color: #222;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
a:hover {
|
||||
color: #fff;
|
||||
background-color: #111;
|
||||
}
|
||||
|
||||
h1 {
|
||||
text-transform: uppercase;
|
||||
line-height: 1.2;
|
||||
padding: 0 0 15px;
|
||||
margin: 0 0 15px;
|
||||
}
|
||||
|
||||
#wrap {
|
||||
margin: 0 auto;
|
||||
text-align: left;
|
||||
font-size: 13px;
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
#container {
|
||||
max-width: 1000px;
|
||||
}
|
||||
|
||||
#sidebar {
|
||||
overflow: hidden;
|
||||
text-align: right;
|
||||
height: auto;
|
||||
padding: 0 5px 0 0;
|
||||
border-right: 1px dotted #c8c8c8;
|
||||
}
|
||||
|
||||
#sidebar h1 {
|
||||
border-bottom: 1px dotted #c8c8c8;
|
||||
}
|
||||
|
||||
#sidebar .description {
|
||||
display: block;
|
||||
width: 100%;
|
||||
height: auto;
|
||||
margin: 0 0 10px;
|
||||
}
|
||||
|
||||
.entry {
|
||||
font-size: 14px;
|
||||
line-height: 20px;
|
||||
width: 700px;
|
||||
}
|
||||
|
||||
.entry img {
|
||||
display: block;
|
||||
border: 1px solid #bdbdbd!important;
|
||||
}
|
||||
|
||||
.entry a img:hover {
|
||||
background-color: transparent;
|
||||
border: 1px solid #e5e5e5!important;
|
||||
}
|
||||
|
||||
#footer {
|
||||
text-align: center;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
#footer div {
|
||||
margin: 30px 0 0;
|
||||
padding: 30px 0 0;
|
||||
border-top: 1px dotted #c8c8c8;
|
||||
}
|
||||
|
||||
#page-title {
|
||||
position: relative;
|
||||
top: 8px;
|
||||
}
|
||||
|
|
@ -0,0 +1,69 @@
|
|||
/**
|
||||
* Theme Name: Monospace
|
||||
* Theme URI: http://vinicius.soylocoporti.org.br/monospace-wordpress-theme
|
||||
* Description: A clean, extra-light, easy, objective, image free and 80 columns monospaced content theme. Made for code, manuals and e-mail publishing. Good for programming blogs, planets and posting by mail.
|
||||
* Author: Vinicius Massuchetto
|
||||
* Author URI: http://vinicius.soylocoporti.org.br
|
||||
* Version: 1.91
|
||||
* Tags: white, blue, two-columns, fixed-width, threaded-comments, translation-ready
|
||||
* License: GNU General Public License v2.0
|
||||
* License URI: http://www.gnu.org/licenses/gpl-2.0.html
|
||||
*/
|
||||
|
||||
@import url("pygment.css");
|
||||
|
||||
body { margin:0px; padding:20px 0px; text-align:center; font-family:Monospace; color:#222; }
|
||||
a, a:visited { text-decoration:none; color:#222; font-weight: bold; }
|
||||
a:hover { color:#FFF; background-color:#111 }
|
||||
h1, h2, h3, h4, h5, h6, h7 { margin:0px; text-transform:uppercase; line-height: 1.2; }
|
||||
h4, h5, h6 { font-size:14px; }
|
||||
h1 { padding:0px 0px 15px; margin:0px 0px 15px 0px; }
|
||||
blockquote { font-style:italic; background:#eee; margin:20px; padding:5px 10px; }
|
||||
blockquote cite { display:block; padding:10px 20px 0 0; text-align:right; }
|
||||
input, textarea { padding:5px; border:1px solid #8A8A8A; background:#EAEAEA; }
|
||||
input:hover, textarea:hover, blockquote:hover { background:#E5E5E5; }
|
||||
|
||||
#wrap { margin:0px auto; text-align:left; font-size: 13px; line-height: 1.4; }
|
||||
#container { max-width: 1000px; }
|
||||
#sidebar { overflow:hidden; text-align:right; height:auto; padding:0px 5px 0px 0px; border-right:1px dotted #C8C8C8; }
|
||||
#sidebar li { list-style-type:none; }
|
||||
#sidebar > li { margin:20px 0px; }
|
||||
#sidebar h1 { border-bottom:1px dotted #C8C8C8; }
|
||||
#sidebar .description { display:block; width:100%; height:auto; margin:0px 0px 10px 0px; }
|
||||
|
||||
ul.sub-menu, ul.children { margin:0px 10px 0px 0px; }
|
||||
|
||||
.post { padding:0px 0px 20px 0px; border-bottom:1px dotted #C8C8C8; }
|
||||
.meta { margin:10px; padding:15px; background:#EAEAEA; clear:both; }
|
||||
.meta span { display:block; clear:left; }
|
||||
.thumbnail { margin:0px; padding:0px; }
|
||||
.thumbnail img { float:right; }
|
||||
|
||||
.entry { font-size: 14px; line-height: 20px; width: 700px; }
|
||||
.entry h2, h3, h4, h5 { margin:30px 0px 10px 0px; }
|
||||
.entry img { display:block; border:1px solid #BDBDBD !important; }
|
||||
.entry img.wp-smiley { border:0px !important; }
|
||||
.entry a img:hover { background-color:transparent; border:1px solid #E5E5E5 !important; }
|
||||
.entry .aligncenter, div.aligncenter { margin:10px auto; }
|
||||
.entry .alignleft { float: left; margin:10px 15px 10px 0px; }
|
||||
.entry .alignright { float: right; margin:10px 0px 10px 15px; }
|
||||
.entry .alignnone { margin:10px 0px; }
|
||||
.entry p.attachment img { margin:0px auto; }
|
||||
.entry code { font-weight: bold; }
|
||||
.sticky { border-bottom:3px dotted #C8C8C8; }
|
||||
|
||||
.literal-block { background-color: #ddd; padding: 6px 12px 6px 12px; }
|
||||
|
||||
.related { margin:20px 0px 0px 0px; }
|
||||
.nav { margin:30px 0px; text-align:center; }
|
||||
|
||||
#footer { text-align:center; clear:both; }
|
||||
#footer div { margin:30px 0px 0px 0px; padding:30px 0px 0px 0px; border-top:1px dotted #C8C8C8; }
|
||||
#footer li { list-style-type:none; }
|
||||
#footer .widget_tag_cloud h2 { display:none; }
|
||||
|
||||
/* LWM EDITS */
|
||||
#page-title{
|
||||
position : relative;
|
||||
top : 8px;
|
||||
}
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
.highlight code,.highlight pre{color:#fdce93;background-color:#3f3f3f;padding:10px;}.highlight .hll{background-color:#222}.highlight .c{color:#7f9f7f}.highlight .err{color:#e37170;background-color:#3d3535}.highlight .g{color:#7f9f7f}.highlight .k{color:#f0dfaf}.highlight .l{color:#ccc}.highlight .n{color:#dcdccc}.highlight .o{color:#f0efd0}.highlight .x{color:#ccc}.highlight .p{color:#41706f}.highlight .cm{color:#7f9f7f}.highlight .cp{color:#7f9f7f}.highlight .c1{color:#7f9f7f}.highlight .cs{color:#cd0000;font-weight:bold}.highlight .gd{color:#cd0000}.highlight .ge{color:#ccc;font-style:italic}.highlight .gr{color:red}.highlight .gh{color:#dcdccc;font-weight:bold}.highlight .gi{color:#00cd00}.highlight .go{color:gray}.highlight .gp{color:#dcdccc;font-weight:bold}.highlight .gs{color:#ccc;font-weight:bold}.highlight .gu{color:purple;font-weight:bold}.highlight .gt{color:#0040D0}.highlight .kc{color:#dca3a3}.highlight .kd{color:#ffff86}.highlight .kn{color:#dfaf8f;font-weight:bold}.highlight .kp{color:#cdcf99}.highlight .kr{color:#cdcd00}.highlight .kt{color:#00cd00}.highlight .ld{color:#cc9393}.highlight .m{color:#8cd0d3}.highlight .s{color:#cc9393}.highlight .na{color:#9ac39f}.highlight .nb{color:#efef8f}.highlight .nc{color:#efef8f}.highlight .no{color:#ccc}.highlight .nd{color:#ccc}.highlight .ni{color:#c28182}.highlight .ne{color:#c3bf9f;font-weight:bold}.highlight .nf{color:#efef8f}.highlight .nl{color:#ccc}.highlight .nn{color:#8fbede}.highlight .nx{color:#ccc}.highlight .py{color:#ccc}.highlight .nt{color:#9ac39f}.highlight .nv{color:#dcdccc}.highlight .ow{color:#f0efd0}.highlight .w{color:#ccc}.highlight .mf{color:#8cd0d3}.highlight .mh{color:#8cd0d3}.highlight .mi{color:#8cd0d3}.highlight .mo{color:#8cd0d3}.highlight .sb{color:#cc9393}.highlight .sc{color:#cc9393}.highlight .sd{color:#cc9393}.highlight .s2{color:#cc9393}.highlight .se{color:#cc9393}.highlight .sh{color:#cc9393}.highlight .si{color:#cc9393}.highlight .sx{color:#cc9393}.highlight .sr{color:#cc9393}.highlight .s1{color:#cc9393}.highlight .ss{color:#cc9393}.highlight .bp{color:#efef8f}.highlight .vc{color:#efef8f}.highlight .vg{color:#dcdccc}.highlight .vi{color:#ffffc7}.highlight .il{color:#8cd0d3}
|
||||
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
{% extends "base.html" %}
|
||||
{% block content %}
|
||||
<section id="content" class="body">
|
||||
<h1>Archives for {{ SITENAME }}</h1>
|
||||
|
||||
<ul>
|
||||
{% for article in dates %}
|
||||
<li>{{ article.date|strftime('%A, %Y %B %-d') }}: <a href='{{ SITEURL }}/{{ article.url }}'>{{ article.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
</section>
|
||||
{% endblock %}
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
{% extends "base.html" %}
|
||||
{% block title %}{{ super() }} : {{ article.title }}{% endblock %}
|
||||
{% block content %}
|
||||
<article class="h-entry">
|
||||
<header>
|
||||
<h1><a href="{{ SITEURL }}" id="site-title"> {#{{ SITENAME }}#} {% if SITESUBTITLE %} <strong>{{ SITESUBTITLE }}</strong>{% endif %}</a> {#:#}
|
||||
<a class="u-url p-name" href="{{ SITEURL }}/{{ article.url }}" id="page-title">{{ article.title }}</a></h1>
|
||||
{% if not HIDE_DATE %}<time class="dt-published" datetime="{{ article.date.isoformat() }}">{{ article.locale_date }}</time>{% endif %}
|
||||
</header>
|
||||
<div class="e-content">
|
||||
{{ article.content }}
|
||||
</div>
|
||||
{% if article.tags %}
|
||||
<hr />
|
||||
<div>
|
||||
Tags:
|
||||
{% for tag in article.tags %}
|
||||
<span itemprop="keywords">
|
||||
<a href="{{ SITEURL }}/{{ tag.url }}" rel="tag">{{ tag }}</a>{% if not loop.last %}, {% endif %}
|
||||
</span>
|
||||
{% endfor %}
|
||||
</div>
|
||||
{% endif %}
|
||||
<div style="display:none" class="h-card">
|
||||
<img class="u-photo" src="/files/images/me.jpg" alt="A photo of the author." />
|
||||
<p class="p-name">Kyle Isom</p>
|
||||
</div>
|
||||
|
||||
<p class
|
||||
</article>
|
||||
{% endblock %}
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
{% extends "index.html" %}
|
||||
{% block title %}{{ SITENAME }} - {{ author }}{% endblock %}
|
||||
|
|
@ -0,0 +1,425 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<title>{% block title %}{{ SITENAME }}{%endblock%}</title>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width,initial-scale=1" />
|
||||
<link href="{{ SITEURL }}/{{ FEED_ATOM }}" type="application/atom+xml" rel="alternate" title="{{ SITENAME }} ATOM Feed" />
|
||||
<link href="{{ SITEURL }}/{{ FEED_RSS }}" type="application/atom+xml" rel="alternate" title="{{ SITENAME }} RSS Feed" />
|
||||
<style>
|
||||
body {
|
||||
margin: 0;
|
||||
padding: 20px 0;
|
||||
text-align: center;
|
||||
font-family: Monospace;
|
||||
color: #222;
|
||||
}
|
||||
|
||||
a,a:visited {
|
||||
text-decoration: none;
|
||||
color: #222;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
a:hover {
|
||||
color: #fff;
|
||||
background-color: #111;
|
||||
}
|
||||
|
||||
h1 {
|
||||
text-transform: uppercase;
|
||||
line-height: 1.2;
|
||||
padding: 0 0 15px;
|
||||
margin: 0 0 15px;
|
||||
}
|
||||
|
||||
#wrap {
|
||||
margin: 0 auto;
|
||||
text-align: left;
|
||||
font-size: 13px;
|
||||
line-height: 1.4;
|
||||
}
|
||||
|
||||
#container {
|
||||
max-width: 1000px;
|
||||
}
|
||||
|
||||
#sidebar {
|
||||
overflow: hidden;
|
||||
text-align: right;
|
||||
height: auto;
|
||||
padding: 0 5px 0 0;
|
||||
border-right: 1px dotted #c8c8c8;
|
||||
}
|
||||
|
||||
#sidebar h1 {
|
||||
border-bottom: 1px dotted #c8c8c8;
|
||||
}
|
||||
|
||||
#sidebar .description {
|
||||
display: block;
|
||||
width: 100%;
|
||||
height: auto;
|
||||
margin: 0 0 10px;
|
||||
}
|
||||
|
||||
.entry {
|
||||
font-size: 14px;
|
||||
line-height: 20px;
|
||||
width: 700px;
|
||||
}
|
||||
|
||||
.entry img {
|
||||
display: block;
|
||||
border: 1px solid #bdbdbd!important;
|
||||
max-width: 600;
|
||||
}
|
||||
|
||||
.entry a img:hover {
|
||||
background-color: transparent;
|
||||
border: 1px solid #e5e5e5!important;
|
||||
}
|
||||
|
||||
#footer {
|
||||
text-align: center;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
#footer div {
|
||||
margin: 30px 0 0;
|
||||
padding: 30px 0 0;
|
||||
border-top: 1px dotted #c8c8c8;
|
||||
}
|
||||
|
||||
#page-title {
|
||||
position: relative;
|
||||
top: 8px;
|
||||
}
|
||||
|
||||
.highlight code,
|
||||
.highlight pre {
|
||||
color: #fdce93;
|
||||
background-color: #3f3f3f;
|
||||
padding: 10px;
|
||||
}
|
||||
|
||||
.highlight .hll {
|
||||
background-color: #222
|
||||
}
|
||||
|
||||
.highlight .c {
|
||||
color: #7f9f7f
|
||||
}
|
||||
|
||||
.highlight .err {
|
||||
color: #e37170;
|
||||
background-color: #3d3535
|
||||
}
|
||||
|
||||
.highlight .g {
|
||||
color: #7f9f7f
|
||||
}
|
||||
|
||||
.highlight .k {
|
||||
color: #f0dfaf
|
||||
}
|
||||
|
||||
.highlight .l {
|
||||
color: #ccc
|
||||
}
|
||||
|
||||
.highlight .n {
|
||||
color: #dcdccc
|
||||
}
|
||||
|
||||
.highlight .o {
|
||||
color: #f0efd0
|
||||
}
|
||||
|
||||
.highlight .x {
|
||||
color: #ccc
|
||||
}
|
||||
|
||||
.highlight .p {
|
||||
color: #41706f
|
||||
}
|
||||
|
||||
.highlight .cm {
|
||||
color: #7f9f7f
|
||||
}
|
||||
|
||||
.highlight .cp {
|
||||
color: #7f9f7f
|
||||
}
|
||||
|
||||
.highlight .c1 {
|
||||
color: #7f9f7f
|
||||
}
|
||||
|
||||
.highlight .cs {
|
||||
color: #cd0000;
|
||||
font-weight: bold
|
||||
}
|
||||
|
||||
.highlight .gd {
|
||||
color: #cd0000
|
||||
}
|
||||
|
||||
.highlight .ge {
|
||||
color: #ccc;
|
||||
font-style: italic
|
||||
}
|
||||
|
||||
.highlight .gr {
|
||||
color: red
|
||||
}
|
||||
|
||||
.highlight .gh {
|
||||
color: #dcdccc;
|
||||
font-weight: bold
|
||||
}
|
||||
|
||||
.highlight .gi {
|
||||
color: #00cd00
|
||||
}
|
||||
|
||||
.highlight .go {
|
||||
color: gray
|
||||
}
|
||||
|
||||
.highlight .gp {
|
||||
color: #dcdccc;
|
||||
font-weight: bold
|
||||
}
|
||||
|
||||
.highlight .gs {
|
||||
color: #ccc;
|
||||
font-weight: bold
|
||||
}
|
||||
|
||||
.highlight .gu {
|
||||
color: purple;
|
||||
font-weight: bold
|
||||
}
|
||||
|
||||
.highlight .gt {
|
||||
color: #0040D0
|
||||
}
|
||||
|
||||
.highlight .kc {
|
||||
color: #dca3a3
|
||||
}
|
||||
|
||||
.highlight .kd {
|
||||
color: #ffff86
|
||||
}
|
||||
|
||||
.highlight .kn {
|
||||
color: #dfaf8f;
|
||||
font-weight: bold
|
||||
}
|
||||
|
||||
.highlight .kp {
|
||||
color: #cdcf99
|
||||
}
|
||||
|
||||
.highlight .kr {
|
||||
color: #cdcd00
|
||||
}
|
||||
|
||||
.highlight .kt {
|
||||
color: #00cd00
|
||||
}
|
||||
|
||||
.highlight .ld {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .m {
|
||||
color: #8cd0d3
|
||||
}
|
||||
|
||||
.highlight .s {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .na {
|
||||
color: #9ac39f
|
||||
}
|
||||
|
||||
.highlight .nb {
|
||||
color: #efef8f
|
||||
}
|
||||
|
||||
.highlight .nc {
|
||||
color: #efef8f
|
||||
}
|
||||
|
||||
.highlight .no {
|
||||
color: #ccc
|
||||
}
|
||||
|
||||
.highlight .nd {
|
||||
color: #ccc
|
||||
}
|
||||
|
||||
.highlight .ni {
|
||||
color: #c28182
|
||||
}
|
||||
|
||||
.highlight .ne {
|
||||
color: #c3bf9f;
|
||||
font-weight: bold
|
||||
}
|
||||
|
||||
.highlight .nf {
|
||||
color: #efef8f
|
||||
}
|
||||
|
||||
.highlight .nl {
|
||||
color: #ccc
|
||||
}
|
||||
|
||||
.highlight .nn {
|
||||
color: #8fbede
|
||||
}
|
||||
|
||||
.highlight .nx {
|
||||
color: #ccc
|
||||
}
|
||||
|
||||
.highlight .py {
|
||||
color: #ccc
|
||||
}
|
||||
|
||||
.highlight .nt {
|
||||
color: #9ac39f
|
||||
}
|
||||
|
||||
.highlight .nv {
|
||||
color: #dcdccc
|
||||
}
|
||||
|
||||
.highlight .ow {
|
||||
color: #f0efd0
|
||||
}
|
||||
|
||||
.highlight .w {
|
||||
color: #ccc
|
||||
}
|
||||
|
||||
.highlight .mf {
|
||||
color: #8cd0d3
|
||||
}
|
||||
|
||||
.highlight .mh {
|
||||
color: #8cd0d3
|
||||
}
|
||||
|
||||
.highlight .mi {
|
||||
color: #8cd0d3
|
||||
}
|
||||
|
||||
.highlight .mo {
|
||||
color: #8cd0d3
|
||||
}
|
||||
|
||||
.highlight .sb {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .sc {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .sd {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .s2 {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .se {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .sh {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .si {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .sx {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .sr {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .s1 {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .ss {
|
||||
color: #cc9393
|
||||
}
|
||||
|
||||
.highlight .bp {
|
||||
color: #efef8f
|
||||
}
|
||||
|
||||
.highlight .vc {
|
||||
color: #efef8f
|
||||
}
|
||||
|
||||
.highlight .vg {
|
||||
color: #dcdccc
|
||||
}
|
||||
|
||||
.highlight .vi {
|
||||
color: #ffffc7
|
||||
}
|
||||
|
||||
.highlight .il {
|
||||
color: #8cd0d3
|
||||
}
|
||||
</style>
|
||||
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<div id="wrap" style="width:900px">
|
||||
<div id="container" style="width:600px">
|
||||
<div id="sidebar">
|
||||
<h1><a href="{{ SITEURL }} " title="title">{{ SITENAME }}</a></h1>
|
||||
<span class="description">{{ DESCRIPTION }} </span>
|
||||
<a href="/">Home</a> |
|
||||
<a href="/about.html">About</a> |
|
||||
<a href="/specs/">Specs</a>|
|
||||
<a href="/archives.html">Archives</a> |
|
||||
<a href="/tags.html">Tags</a> |
|
||||
<a href="/ls.html">Pages</a> |
|
||||
<span class="feed">Feeds: <a href="/index.rss">RSS</a> | <a href="/index.atom">Atom</a></span>
|
||||
</div>
|
||||
|
||||
<hr /><br />
|
||||
|
||||
<div class="entry">
|
||||
{% block content %}
|
||||
{% endblock %}
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div id="footer">
|
||||
<div id="credits">
|
||||
<span>Adapted from <a href="http://wordpress.org/themes/monospace">Monospace</a> || Created with <a href="">Pelican</a></span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
{% extends "base.html" %}
|
||||
{% block content %}
|
||||
<ul>
|
||||
{% for category, articles in categories %}
|
||||
<li><a href="{{ SITEURL }}/{{ category.url }}">{{ category }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endblock %}
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
{% extends "base.html" %}
|
||||
{% block title %}{{ SITENAME }} - {{ category }}{% endblock %}
|
||||
{% block content %}
|
||||
<h1>{{ category }}</h1>
|
||||
<ul>
|
||||
{% for article in articles %}
|
||||
<li><a href="{{ SITEURL }}"/{{ article.url }}">{{ article.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endblock %}
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
{% extends "base.html" %}
|
||||
{% block content_title %}{% endblock %}
|
||||
{% block content %}
|
||||
<h3>wntrmute :: exocortex</h3>
|
||||
|
||||
<p>This is a project to build an exocortex. It is a dump from my current
|
||||
system into a format suitable for public sharing.</p>
|
||||
|
||||
{% if articles %}
|
||||
<h3>Recent posts</h3>
|
||||
<ul>
|
||||
{% for article in dates|filter_journal %}
|
||||
<li>{{ article.date|strftime('%Y-%m-%d') }}: <a href='{{ SITEURL }}/{{ article.url }}'>{{ article.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
|
||||
<h3>Recent journal entries</h3>
|
||||
<p>Journal entries are writeups of stuff that happened over the course
|
||||
of a day; the current day's entry might be updated over the course of
|
||||
the day.</p>
|
||||
<ul>
|
||||
{% for article in dates|select_journal(limit=3) %}
|
||||
<li>{{ article.date|strftime('%Y-%m-%d') }}: <a href='{{ SITEURL }}/{{ article.url }}'>{{ article.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endif %}
|
||||
|
||||
<h3>Select pages</h3>
|
||||
<ul>
|
||||
<li><a href="/specs/functional.html">Functional spec</a></li>
|
||||
</ul>
|
||||
|
||||
{% endblock content %}
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
{% extends "base.html" %}
|
||||
{% block title %}{{ page.title }}{% endblock %}
|
||||
{% block content %}
|
||||
<header>
|
||||
<h1><a href="{{ SITEURL }}" id="site-title">{# {{ SITENAME }} #} {% if SITESUBTITLE %} <strong>{{ SITESUBTITLE }}</strong>{% endif %}</a> {#:#}
|
||||
<a href="{{ SITEURL }}/{{ page.url }}" id="page-title">{{ page.title }}</a></h1>
|
||||
</header>
|
||||
<article>
|
||||
{{ page.content }}
|
||||
</article>
|
||||
{% endblock %}
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
{% if DEFAULT_PAGINATION %}
|
||||
<p class="paginator">
|
||||
{% if articles_page.has_previous() %}
|
||||
{% if articles_page.previous_page_number() == 1 %}
|
||||
<a href="{{ SITEURL }}/{{ page_name }}.html">«</a>
|
||||
{% else %}
|
||||
<a href="{{ SITEURL }}/{{ page_name }}{{ articles_page.previous_page_number() }}.html">«</a>
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
Page {{ articles_page.number }} / {{ articles_paginator.num_pages }}
|
||||
{% if articles_page.has_next() %}
|
||||
<a href="{{ SITEURL }}/{{ page_name }}{{ articles_page.next_page_number() }}.html">»</a>
|
||||
{% endif %}
|
||||
</p>
|
||||
{% endif %}
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
{% extends "index.html" %}
|
||||
<!-- tag.html -->
|
||||
{% block title %}{{ SITENAME }} - {{ tag }}{% endblock %}
|
||||
{% block content %}
|
||||
<ul>
|
||||
{% for article in articles %}
|
||||
<li><a href = "{{ SITEURL }}/{{ article.url }}">{{ article.title }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endblock %}
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
<!-- taglist.html -->
|
||||
{% if article.tags %}<p>tags: {% for tag in article.tags %}<a href="{{ SITEURL }}/{{ tag.url }}">{{ tag }}</a>{% endfor %}</p>{% endif %}
|
||||
{% if PDF_PROCESSOR %}<p><a href="{{ SITEURL }}/pdf/{{ article.slug }}.pdf">get the pdf</a></p>{% endif %}
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
{% extends "base.html" %}
|
||||
{% block content %}
|
||||
<!-- tags.html -->
|
||||
<ul>
|
||||
{% for tag, articles in tags|sort %}
|
||||
<li><a href="{{ SITEURL }}/{{ tag.url }}">{{ tag }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endblock %}
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
{% if article.translations %}
|
||||
Translations:
|
||||
{% for translation in article.translations %}
|
||||
<a href="{{ SITEURL }}/{{ translation.url }}">{{ translation.lang }}</a>
|
||||
{% endfor %}
|
||||
{% endif %}
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
[build]
|
||||
command = "make publish"
|
||||
publish = "output"
|
||||
|
||||
[[headers]]
|
||||
for = "/*"
|
||||
[headers.values]
|
||||
X-Frame-Options = "SAMEORIGIN"
|
||||
X-Content-Type-Options = "nosniff"
|
||||
Referrer-Policy = "strict-origin-when-cross-origin"
|
||||
Content-Security-Policy = "default-src: 'none'; img-src: https:"
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
#!/usr/bin/env python
|
||||
# -*- coding: utf-8 -*- #
|
||||
from __future__ import unicode_literals
|
||||
|
||||
SITEURL = 'https://exon.wntrmute.net'
|
||||
AUTHOR = u'kyle'
|
||||
SITENAME = u'Exocortex Notes'
|
||||
DESCRIPTION = 'Development log and information about the wntrmute exocortex'
|
||||
THEME = 'monospace'
|
||||
TIMEZONE = 'America/Los_Angeles'
|
||||
DEFAULT_LANG = u'en'
|
||||
|
||||
DATE_FORMAT = '%F'
|
||||
|
||||
PATH = 'content'
|
||||
STATIC_PATHS = ['files']
|
||||
EXTRA_PATH_METADATA = { }
|
||||
|
||||
PLUGIN_PATHS = ['plugins']
|
||||
PLUGINS = ['pagehier']
|
||||
|
||||
#ARTICLE_URL = 'blog/{date:%Y}/{date:%m}/{date:%d}/{slug}/'
|
||||
#ARTICLE_SAVE_AS = 'blog/{date:%Y}/{date:%m}/{date:%d}/{slug}/index.html'
|
||||
PAGE_URL = '{slug}.html'
|
||||
PAGE_SAVE_AS = '{slug}.html'
|
||||
SLUGIFY_SOURCE = 'basename'
|
||||
|
||||
def select_journal(articles, limit=5):
|
||||
return [article for article in articles if 'journal' in article.tags][:limit]
|
||||
|
||||
def filter_journal(articles, limit=5):
|
||||
return [article for article in articles if 'journal' not in article.tags][:limit]
|
||||
|
||||
JINJA_FILTERS = {
|
||||
'select_journal': select_journal,
|
||||
'filter_journal': filter_journal,
|
||||
}
|
||||
|
||||
# Blogroll (('name',' http://example.net/'))
|
||||
LINKS = ();
|
||||
DEFAULT_PAGINATION = 10
|
||||
|
||||
|
||||
# These are used in development; publishconf will override them.
|
||||
RELATIVE_URLS = True
|
||||
LOAD_CONTENT_CACHE = False
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
Page Hierarchy
|
||||
==============
|
||||
*Author: Ahmad Khayyat (<akhayyat@gmail.com>)*
|
||||
|
||||
A [Pelican][1] plugin that creates a URL hierarchy for pages that
|
||||
matches the filesystem hierarchy of their sources.
|
||||
|
||||
For example, to have the following filesystem structure of page
|
||||
sources result in the URLs listed next to each file,
|
||||
|
||||
```text
|
||||
└── content/pages/ # PAGE_DIR
|
||||
├── about.md # URL: pages/about/
|
||||
├── projects.md # URL: pages/projects/
|
||||
├── projects/ # (directory)
|
||||
│ ├── p1.md # URL: pages/projects/p1/
|
||||
│ ├── p2.md # URL: pages/projects/p2/
|
||||
│ └── p2/ # (directory)
|
||||
│ └── features.md # URL: pages/projects/p2/features/
|
||||
└── contact.md # URL: pages/contact/
|
||||
```
|
||||
|
||||
you can use this plugin with the following Pelican settings:
|
||||
|
||||
```python
|
||||
# pelicanconf.py
|
||||
PAGE_URL = '{slug}/'
|
||||
PAGE_SAVE_AS = '{slug}/index.html'
|
||||
SLUGIFY_SOURCE = 'basename'
|
||||
```
|
||||
|
||||
When generating the `url` and `save_as` attributes, the plugin
|
||||
prefixes the page's `slug` by its relative path. Although the initial
|
||||
`slug` is generated from the page's `title` by default, it can be
|
||||
generated from the source file basename by setting the
|
||||
`SLUGIFY_SOURCE` setting to `'basename'`, as shown in the settings
|
||||
snippet above. The `slug` can also be set using [`PATH_METADATA`][2].
|
||||
|
||||
This plugin is compatible with [Pelican translations][3].
|
||||
|
||||
Parent and Children Pages
|
||||
-------------------------
|
||||
This plugin also adds three attributes to each page object:
|
||||
|
||||
- `parent`: the immediate parent page. `None` if the page is
|
||||
top-level. If a translated page has no parent, the default-language
|
||||
parent is used.
|
||||
|
||||
- `parents`: a list of all ancestor pages, starting from the top-level
|
||||
ancestor.
|
||||
|
||||
- `children`: a list of all immediate child pages, in no specific
|
||||
order.
|
||||
|
||||
These attributes can be used to generate breadcrumbs or nested
|
||||
navigation menus. For example, this is a template excerpt for
|
||||
breadcrumbs:
|
||||
|
||||
```html
|
||||
<ul class="breadcrumb">
|
||||
<li><a href="{{ SITEURL }}/" title="{{ SITENAME }}">
|
||||
<i class="fa fa-home fa-lg"></i>
|
||||
</a></li>
|
||||
{% for parent in page.parents %}
|
||||
<li><a href="{{ SITEURL }}/{{ parent.url }}">{{ parent.title }}</a></li>
|
||||
{% endfor %}
|
||||
<li class="active">{{ page.title }}</li>
|
||||
</ul>
|
||||
|
||||
```
|
||||
|
||||
|
||||
[1]: http://getpelican.com/
|
||||
[2]: http://docs.getpelican.com/en/latest/settings.html#path-metadata
|
||||
[3]: http://docs.getpelican.com/en/latest/settings.html#translations
|
||||
|
|
@ -0,0 +1 @@
|
|||
from .page_hierarchy import *
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
from pelican import signals, contents
|
||||
import os.path
|
||||
from copy import copy
|
||||
from itertools import chain
|
||||
|
||||
'''
|
||||
This plugin creates a URL hierarchy for pages that matches the
|
||||
directory hierarchy of their sources.
|
||||
'''
|
||||
|
||||
class UnexpectedException(Exception): pass
|
||||
|
||||
def get_path(page, settings):
|
||||
''' Return the dirname relative to PAGE_PATHS prefix. '''
|
||||
path = os.path.split(page.get_relative_source_path())[0] + '/'
|
||||
path = path.replace( os.path.sep, '/' )
|
||||
# Try to lstrip the longest prefix first
|
||||
for prefix in sorted(settings['PAGE_PATHS'], key=len, reverse=True):
|
||||
if not prefix.endswith('/'): prefix += '/'
|
||||
if path.startswith(prefix):
|
||||
return path[len(prefix):-1]
|
||||
raise UnexpectedException('Page outside of PAGE_PATHS ?!?')
|
||||
|
||||
def in_default_lang(page):
|
||||
# page.in_default_lang property is undocumented (=unstable) interface
|
||||
return page.lang == page.settings['DEFAULT_LANG']
|
||||
|
||||
def override_metadata(content_object):
|
||||
if type(content_object) is not contents.Page:
|
||||
return
|
||||
page = content_object
|
||||
path = get_path(page, page.settings)
|
||||
|
||||
def _override_value(page, key):
|
||||
metadata = copy(page.metadata)
|
||||
# We override the slug to include the path up to the filename
|
||||
metadata['slug'] = os.path.join(path, page.slug)
|
||||
# We have to account for non-default language and format either,
|
||||
# e.g., PAGE_SAVE_AS or PAGE_LANG_SAVE_AS
|
||||
infix = '' if in_default_lang(page) else 'LANG_'
|
||||
return page.settings['PAGE_' + infix + key.upper()].format(**metadata)
|
||||
|
||||
for key in ('save_as', 'url'):
|
||||
if not hasattr(page, 'override_' + key):
|
||||
setattr(page, 'override_' + key, _override_value(page, key))
|
||||
|
||||
def set_relationships(generator):
|
||||
def _all_pages():
|
||||
return chain(generator.pages, generator.translations)
|
||||
|
||||
# initialize parents and children lists
|
||||
for page in _all_pages():
|
||||
page.parent = None
|
||||
page.parents = []
|
||||
page.children = []
|
||||
|
||||
# set immediate parents and children
|
||||
for page in _all_pages():
|
||||
# Parent of /a/b/ is /a/, parent of /a/b.html is /a/
|
||||
parent_url = os.path.dirname(page.url[:-1])
|
||||
if parent_url: parent_url += '/'
|
||||
for page2 in _all_pages():
|
||||
if page2.url == parent_url and page2 != page:
|
||||
page.parent = page2
|
||||
page2.children.append(page)
|
||||
# If no parent found, try the parent of the default language page
|
||||
if not page.parent and not in_default_lang(page):
|
||||
for page2 in generator.pages:
|
||||
if (page.slug == page2.slug and
|
||||
os.path.dirname(page.source_path) ==
|
||||
os.path.dirname(page2.source_path)):
|
||||
# Only set the parent but not the children, obviously
|
||||
page.parent = page2.parent
|
||||
|
||||
# set all parents (ancestors)
|
||||
for page in _all_pages():
|
||||
p = page
|
||||
while p.parent:
|
||||
page.parents.insert(0, p.parent)
|
||||
p = p.parent
|
||||
|
||||
|
||||
def register():
|
||||
signals.content_object_init.connect(override_metadata)
|
||||
signals.page_generator_finalized.connect(set_relationships)
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
#!/usr/bin/env python
|
||||
# -*coding: utf-8 -*#
|
||||
from __future__ import unicode_literals
|
||||
|
||||
# This file is only used if you use `make publish` or
|
||||
# explicitly specify it as your config file.
|
||||
|
||||
import os
|
||||
import sys
|
||||
sys.path.append(os.curdir)
|
||||
from pelicanconf import *
|
||||
|
||||
RELATIVE_URLS = False
|
||||
FEED_DOMAIN = SITEURL
|
||||
FEED_ATOM = "index.atom"
|
||||
FEED_RSS = "index.rss"
|
||||
DELETE_OUTPUT_DIRECTORY = True
|
||||
FEED_USE_SUMMARY = False
|
||||
RSS_FEED_SUMMARY_ONLY = False
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
pelican >= 3.7.1
|
||||
markdown >= 3.0.0
|
||||
invoke
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
|
||||
import os
|
||||
import shutil
|
||||
import sys
|
||||
import datetime
|
||||
|
||||
from invoke import task
|
||||
from invoke.util import cd
|
||||
from pelican.server import ComplexHTTPRequestHandler, RootedHTTPServer
|
||||
|
||||
CONFIG = {
|
||||
# Local path configuration (can be absolute or relative to tasks.py)
|
||||
'deploy_path': 'output',
|
||||
# Remote server configuration
|
||||
'production': 'kyle@ai6ua.net:22',
|
||||
'dest_path': 'sites/ai6ua',
|
||||
# Port for `serve`
|
||||
'port': 8000,
|
||||
}
|
||||
|
||||
@task
|
||||
def clean(c):
|
||||
"""Remove generated files"""
|
||||
if os.path.isdir(CONFIG['deploy_path']):
|
||||
shutil.rmtree(CONFIG['deploy_path'])
|
||||
os.makedirs(CONFIG['deploy_path'])
|
||||
|
||||
@task
|
||||
def build(c):
|
||||
"""Build local version of site"""
|
||||
c.run('pelican -s pelicanconf.py')
|
||||
|
||||
@task
|
||||
def rebuild(c):
|
||||
"""`build` with the delete switch"""
|
||||
c.run('pelican -d -s pelicanconf.py')
|
||||
|
||||
@task
|
||||
def regenerate(c):
|
||||
"""Automatically regenerate site upon file modification"""
|
||||
c.run('pelican -r -s pelicanconf.py')
|
||||
|
||||
@task
|
||||
def serve(c):
|
||||
"""Serve site at http://localhost:8000/"""
|
||||
|
||||
class AddressReuseTCPServer(RootedHTTPServer):
|
||||
allow_reuse_address = True
|
||||
|
||||
server = AddressReuseTCPServer(
|
||||
CONFIG['deploy_path'],
|
||||
('', CONFIG['port']),
|
||||
ComplexHTTPRequestHandler)
|
||||
|
||||
sys.stderr.write('Serving on port {port} ...\n'.format(**CONFIG))
|
||||
server.serve_forever()
|
||||
|
||||
@task
|
||||
def reserve(c):
|
||||
"""`build`, then `serve`"""
|
||||
build(c)
|
||||
serve(c)
|
||||
|
||||
@task
|
||||
def preview(c):
|
||||
"""Build production version of site"""
|
||||
c.run('pelican -s publishconf.py')
|
||||
|
||||
|
||||
@task
|
||||
def publish(c):
|
||||
"""Publish to production via rsync"""
|
||||
c.run('pelican -s publishconf.py')
|
||||
c.run(
|
||||
'rsync --delete --exclude ".DS_Store" -pthrvz -c '
|
||||
'{} {production}:{dest_path}'.format(
|
||||
CONFIG['deploy_path'].rstrip('/') + '/',
|
||||
**CONFIG))
|
||||
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
#!/bin/bash
|
||||
|
||||
set -eux
|
||||
|
||||
TODAY="$(date +'%Y%m%d')"
|
||||
DATETIME="$(date +'%F %H:%M')"
|
||||
POSTPATH="content/posts/${TODAY}.md"
|
||||
PUBDATE="$(date +'%F %H:%M %Z')"
|
||||
TITLE="$@"
|
||||
if [ -z "$TITLE" ]
|
||||
then
|
||||
TITLE="${TODAY}"
|
||||
SLUG="${TITLE}"
|
||||
else
|
||||
TITLE="$@"
|
||||
SLUG="$(echo ${TITLE}|tr [A-Z] [a-z]|tr ' ' '-')"
|
||||
fi
|
||||
|
||||
if [ ! -e "${POSTPATH}" ]
|
||||
then
|
||||
cat <<EOF > ${POSTPATH}
|
||||
Title: ${TITLE}
|
||||
Slug: ${SLUG}
|
||||
Date: $(date +'%F')
|
||||
Modified: $(date +'%F')
|
||||
Category:
|
||||
Tags:
|
||||
Authors: kyle
|
||||
Summary:
|
||||
EOF
|
||||
else
|
||||
sed -i -e "s/Modified: .*$/Modified: ${PUBDATE}/" $POSTPATH
|
||||
fi
|
||||
|
||||
|
||||
#EDITOR="$(command -v em)"
|
||||
|
||||
EDITOR="${EDITOR:-gvim}"
|
||||
$EDITOR $POSTPATH
|
||||
Loading…
Reference in New Issue