Remove page, category functionality as it is now provided by `tree.kummerlaender.eu`

20 files changed, 0 insertions, 631 deletions

diff --git a/pages/projects/binary_mapping.md b/pages/projects/binary_mapping.md
deleted file mode 100644
index 91acae5..0000000
--- a/pages/projects/binary_mapping.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# BinaryMapping
-
-…is a collection of C++ templates which may be used to map binary structures into tuples and various other structures.
-
-These structures can then be traversed using integrated containers and iterators. This is useful for many kinds of data serialization tasks.
-
-A explanation of an earlier version of this template library can be found on this [blog]. The source code is available via both [Github] and [cgit].
-
-## Current features
-
-* Support for any kind of flat structure that can be expressed using integral types and arbitrarily sized byte-arrays
-* Support for serialization in either big or little endianess
-* Offers Container and Iterator templates for fast traversal of collections of tuples or other structures
-* Support for developing custom types to be used in the Container and Iterator templates
-* Support for nesting structures inside each other
-* BitField template offers bit-level access to ByteField byte-arrays
-* Doesn't require any external libraries besides the GNU library's `endian.h`
-* Header only library because of heavy usage of template metaprogramming
-* Unit Tests based on GoogleTest
-* MIT license
-
-## Usage example
-
-```cpp
-BinaryMapping::Container<
-    BinaryMapping::Tuple<
-        BinaryMapping::LittleEndian,
-        std::uint32_t,
-        std::int16_t,
-        BinaryMapping::ByteField<3>,
-        std::uint8_t
-    >
-> container(10);
-
-for ( auto&& tuple : container ) {
-    tuple.set<0>(UINT32_MAX);
-    tuple.set<1>(INT16_MAX);
-    tuple.set<2>({1, 2, 3});
-    tuple.set<3>(42);
-}
-
-std::uint32_t test = container.at(5).get<0>();
-```
-
-The code listed above defines a container of a tuple consisting of a `std::uint32_t`, `std::int16_t`, 3-byte and `std::uint8_t` field with little endianess, instantiates a buffer containing ten instances of this tuple, iterates through all 10 elements, gives them values, transparently converts to the correct endianess and extracts the value of the first field of the fifth tuple contained in the buffer. In short: BinaryMapping is a library that abstracts endianess aware serializing of binary structures into structures, containers and iterators. If you are interested in further details of the usage of all features provided by BinaryMapping don't hesitate to check out the [documentation].
-
-[blog]: /article/mapping_binary_structures_as_tuples_using_template_metaprogramming
-[Github]: https://github.com/KnairdA/BinaryMapping/
-[cgit]: http://code.kummerlaender.eu/BinaryMapping/
-[documentation]: https://github.com/KnairdA/BinaryMapping/blob/master/docs/
diff --git a/pages/projects/build_xslt.md b/pages/projects/build_xslt.md
deleted file mode 100644
index 83ce4e6..0000000
--- a/pages/projects/build_xslt.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# BuildXSLT
-
-…is a simple XSLT build system for InputXSLT based applications.
-
-It aims to provide a foundation for building more complex applications such as a fully fledged [static site generator] by enabling users to define _XML Makefiles_ instead of manually calling single [InputXSLT] transformations.
-
-The source code of _BuildXSLT_ is available on both my [Github] profile and [cgit].
-
-## Current features
-
-* processing tasks contained within _XML Makefiles_
-* generating single transformations
-* generating chained transformations
-* using external modules such as [StaticXSLT]
-* using files or embedded XML-trees as transformation input
-
-## Usage example
-
-While _BuildXSLT_ offers enough flexibility for all kinds of different XSLT based generation tasks it was specifically built to cater for the requirements of the [static site generator] this site is built with. As such its module definition file and the _XML Makefile_ used to call it makes for the best demonstration of what one can do with _BuildXSLT_:
-
-```xsl
-<transformation mode="chain">
-    <link>src/steps/list.xsl</link>
-    <link>src/steps/plan.xsl</link>
-    <link>src/steps/process.xsl</link>
-    <link>src/steps/summarize.xsl</link>
-</transformation>
-```
-
-```xsl
-<task type="module">
-	<input mode="embedded">
-		<datasource>
-			<meta>
-				<source>source</source>
-				<target>target</target>
-			</meta>
-		</datasource>
-	</input>
-	<definition mode="file">[StaticXSLT.xml]</definition>
-</task>
-```
-
-[InputXSLT]: /page/input_xslt/
-[static site generator]: /page/static_xslt/
-[StaticXSLT]: /page/static_xslt/
-[Github]: https://github.com/KnairdA/BuildXSLT/
-[cgit]: http://code.kummerlaender.eu/BuildXSLT/
diff --git a/pages/projects/change.md b/pages/projects/change.md
deleted file mode 100644
index 7c30e6a..0000000
--- a/pages/projects/change.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# change
-
-…transparent filesystem change tracking using function interposition.
-
-This project consists of a library `libChangeLog` and a matching wrapper bash script named `change`. If one opens any application using `change` it automatically tracks common system calls used for manipulating filesystem contents and provides the user with a short summary including _diffs_ where appropriate.
-
-	> change mv test example
-	renamed 'test' to 'example'
-	> change vim example
-	--- /home/common/projects/dev/change/example
-	+++ /home/common/projects/dev/change/example	2016-02-13 21:43:15.719355382 +0100
-	@@ -1,3 +1,5 @@
-	 1
-	+
-	 2
-	+
-	 3
-	> change rm example
-	removed 'example'
-
-`change` aims to be a utility that can be dropped in front of any non-suid (function interposition via `LD_PRELOAD` is thankfully not allowed for suid-executables) application and generate a summary that will explain the actual happenings of a terminal session. While this is not very useful for simple, self-explanatory commands such as `mv $this $to_that` it is certainly helpful whenever files are changed by interactive applications that do not provide their own directly visible logging such as text editors. Such an application is in turn useful for e.g. documenting shell sessions.
-
-`change` is written in Bash while the library it preloads is implemented in C++. Both are available via [Github] and [cgit].
-
-## Filtering
-
-Due to its nature of interposing low level system calls such as `write` and `unlink` the library by default exposes lots of the internal write logic of the wrapped application. For instance it reports _vim_ creating a file called `4913` to verify the target directory's writability as well as the creation of various temporary backup files. While this is certainly interesting for debugging purposes it hinders the library's goal of providing a higher level summary consisting primarily of the actions the user explicity performed such as the changed file contents.
-
-To solve this problem one may provide a list of regular expressions to be matched against the file paths via the `CHANGE_LOG_IGNORE_PATTERN_PATH` environment variable.
-
-For example the following ruleset intructs the library to restrict the output `change vim $file` to a _diff_ of all files changed by the wrapped application:
-
-	# vim's way of verifying that it is able to create a file
-	[0-9]+
-	# temporary backup file during write
-	[^~]*~
-	# log and backup files
-	.*\.viminfo
-	.*\.sw[px]
-
-If the library is used via `change` it will automatically try to load a ruleset matching the wrapped applications name. Currently the respository packages such definitions for _vim_, _gvim_ and _neovim_.
-
-[Github]: https://github.com/KnairdA/change/
-[cgit]: http://code.kummerlaender.eu/change/
diff --git a/pages/projects/codepoint_iterator.md b/pages/projects/codepoint_iterator.md
deleted file mode 100644
index 4ba929c..0000000
--- a/pages/projects/codepoint_iterator.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# CodepointIterator
-
-…is a `std::iterator` derived class implementing the `std::bidirectional_iterator_tag` which iterates through unicode codepoints in a UTF8-encoded string.
-
-The source code is available on both my [Github] profile and [cgit].
-
-For readers versed in German a [blog article] describing the implementation in a more detailed manner is available.
-
-## Current features
-
-* Bidirectional iteration through unicode codepoints
-* The class itself does not rely on any external libraries
-* Dereferencing an instance of the iterator yields the codepoint as `char32_t`
-* Unit Tests based on GoogleTest
-
-## Usage example
-
-While all features of this class are demonstrated by Google-Test based [Unit-Tests] we can see a basic `UTF8::CodepointIterator` usage example in the following code snippet. The [example text] is written in Old Norse runes.
-
-
-```cpp
-std::string test(u8"ᛖᚴ ᚷᛖᛏ ᛖᛏᛁ ᚧ ᚷᛚᛖᚱ ᛘᚾ ᚦᛖᛋᛋ ᚨᚧ ᚡᛖ ᚱᚧᚨ ᛋᚨᚱ");
-
-for ( UTF8::CodepointIterator iter(test.cbegin());
-	  iter != test.cend();
-	  ++iter ) {
-	std::wcout << static_cast<wchar_t>(*iter);
-}
-```
-
-[Github]: https://github.com/KnairdA/CodepointIterator
-[cgit]: http://code.kummerlaender.eu/CodepointIterator/
-[Unit-Tests]: https://github.com/KnairdA/CodepointIterator/blob/master/test.cc
-[example text]: http://www.columbia.edu/~fdc/utf8/
-[blog article]: /article/notizen_zu_cpp_und_unicode
diff --git a/pages/projects/const_list.md b/pages/projects/const_list.md
deleted file mode 100644
index efd60a0..0000000
--- a/pages/projects/const_list.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# ConstList
-
-…is a experimental compile-time functional-style list library written in C++.
-
-The MIT licensed implementation may be found on [Github] or [cgit].
-
-It was written as a experiment in how far one could take the optional compile-time executability offered by `constexpr` specifically and the C++ template metaprogramming facilities in general. While basic _Cons_ structures and appropriate accessor functions turned out to be quite straight forward to implement, the current problem is the absence of workable arbitrary value comparison in a templated context if one doesn't want to be limited to values that can be used as template parameters such as integers. This means that it is currently impossible to e.g. filter a list using `foldr`.
-
-Note that these restrictions were overcome in my [second attempt] at this problem which follows the concept of viewing types as values and templates as functions.
-
-## Current features
-
-- `Cons` class template for representing constant list structures at compile time
-- `make` method template for easily constructing `Cons` structures
-- list constructors such as `make` and `concatenate`
-- basic list accessors such as `size`, `head`, `tail`, `nth` and `take`
-- higher order list operators such as `foldr`, `foldl` and `map`
-- higher order list queries such as `any`, `all`, `none` and `count`
-- special purpose methods such as `reverse`
-- test cases for all of the above
-- MIT license
-
-## Usage example
-
-```cpp
-const int sum{
-	ConstList::foldr(
-		ConstList::make(1, 2, 3, 4, 5),
-		[](const int& x, const int& y) {
-			return x + y;
-		},
-		0
-	)
-}; // => 15
-```
-
-[Github]: https://github.com/KnairdA/ConstList/
-[cgit]: http://code.kummerlaender.eu/ConstList/
-[second attempt]: /page/type_as_value/
diff --git a/pages/projects/dotfiles.md b/pages/projects/dotfiles.md
deleted file mode 100644
index 1c93a84..0000000
--- a/pages/projects/dotfiles.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Dotfiles
-
-…is a collection of the configuration files for my essential toolset.
-
-I manage my dotfiles using git and symlink them to their appropriate directories using [GNU stow]. The repository itself is available via [Github] or [cgit].
-
-My toolset currently consists of the following applications:
-
-* fully encrypted [ArchLinux] installation with the [grsec] kernel
-* [i3wm] for window management
-* [vim] as my text editor of choice
-* [pentadactyl] for turning Firefox into a fully keyboard driven browser
-* [fish] as my default shell
-* [urxvt] as terminal emulator
-* [conky] for displaying system information in [i3bar]
-* [rofi] as program launcher
-* [twmn] for displaying notifications
-* [zathura] for displaying documents
-
-[GNU stow]: https://www.gnu.org/software/stow/
-[Github]: https://github.com/KnairdA/dotfiles
-[cgit]: http://code.kummerlaender.eu/Dotfiles/
-[ArchLinux]: https://archlinux.org
-[grsec]: https://grsecurity.net
-[i3wm]: http://i3wm.org
-[vim]: http://vim.org
-[pentadactyl]: http://5digits.org/pentadactyl/
-[fish]: http://fishshell.com/
-[urxvt]: http://software.schmorp.de/pkg/rxvt-unicode.html
-[conky]: http://conky.sourceforge.net/
-[i3bar]: http://i3wm.org/docs/i3bar-protocol.html
-[twmn]: https://github.com/sboli/twmn
-[rofi]: https://davedavenport.github.io/rofi/
-[zathura]: https://pwmt.org/projects/zathura/
diff --git a/pages/projects/graph_storage.md b/pages/projects/graph_storage.md
deleted file mode 100644
index 353e3ce..0000000
--- a/pages/projects/graph_storage.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# GraphStorage
-
-…is a Graph storage and query library based on Google LevelDB and written in C++.
-
-It currently supports integer indexed nodes with properties and directed edges with types. The integer IDs are serialized _by hand_, values are serialized using protocol buffers. Everything is stored in a single sorted [LevelDB] database.
-
-Queries are possible trough a iterator like interface that handles single level queries quite fast. Additionally changes to edges can be monitored using a subscription mechanism.
-
-The library is in development and while not intended for any kind of production usage the source code is available via both [Github] and [cgit].
-
-[Github]: https://github.com/KnairdA/GraphStorage/
-[cgit]: http://code.kummerlaender.eu/GraphStorage/
-[LevelDB]: https://code.google.com/p/leveldb/
diff --git a/pages/projects/input_xslt.md b/pages/projects/input_xslt.md
deleted file mode 100644
index b270aac..0000000
--- a/pages/projects/input_xslt.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# InputXSLT
-
-…is a Apache Xalan based XSLT extension enabling access to external commands, the filesystem and calling further transformations from inside a transformation.
-
-It is used as the base for the static site generation system used to generate the whole website you are currently viewing and is available under the terms of the _Apache License_ via [Github] or [cgit].
-
-## Why?
-
-Contrary to popular opinion I actually like XSLT as a content transformation language and have built - amongst other things - most of my website projects on top of it. While I used the XSLT based [Symphony CMS] for most of these endeavours, the intention behind InputXSLT was to develop XSLT extensions enabling the development of static site generators using XSLT as both a template and application language. The fact that you are currently reading this page proves that this is indeed possible.
-
-## Overview
-
-The following table summarizes all the external functions provided by InputXSLT. They are available under the `InputXSLT` namespace after including `function.inputxslt.application` into the stylesheet element. 
-
-Function           Description
------------------- --------------------------------------------------------------------------------------------------------------
-`read-file`        Reading plain text files as text and XML files as node trees
-`read-directory`   Traversing filesystem directories
-`external-command` Executing external commands including support for providing the input stream and capturing the output stream
-`write-file`       Committing plain text or node trees to the filesystem
-`generate`         Calling transformations including support for capturing the result or committing it directly to the filesystem
-
-The `ixslt` XSLT frontent provided by InputXSLT also implements a custom include entity resolver alongside to an easy to use interface for implementing further custom extension functions.
-
-## Tradeoffs and compromises
-
-All external functions offered by InputXSLT can be accessed using the XPath expression evaluation subsystems of the XSLT language. While in some cases XSL extension elements would have been the primary choice limitations in the C++ implementation of the Apache Xalan XSLT library made the usage of external functions the path of least resistance. In practice external functions like the one used to call other transformations are wrapped inside utility templates and as such may be used as if they where implemented as extension elements. All other functions like the ones used to access the filesystem fit better within a XPath-expression context and are as such implemented in the most fitting way.
-
-[Github]: https://github.com/KnairdA/InputXSLT
-[cgit]: http://code.kummerlaender.eu/InputXSLT
-[Symphony CMS]: http://getsymphony.com
diff --git a/pages/projects/justify.md b/pages/projects/justify.md
deleted file mode 100644
index bb12cfb..0000000
--- a/pages/projects/justify.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# justify
-
-...is a single purpose program for block justification of UTF-8 encoded monospace text.
-
-Textual input is read from _STDIN_ and written to _STDOUT_ in its justified form. The default output width of 60 characters may be customized via `--length`. Optionally an offset of leading spaces may be defined using `--offset`.
-
-i.e. `echo "$the_paragraph_above" | justify --length 40` results in:
-
-	Textual input  is  read from _STDIN_ and
-	written  to  _STDOUT_  in  its justified
-	form.  The  default output  width  of 60
-	characters    may   be    customized via
-	`--length`.  Optionally   an   offset of
-	leading   spaces  may  be  defined using
-	`--offset`.
-
-The MIT licensed source code is available on both [Github] and [cgit].
-
-[Github]: https://github.com/KnairdA/justify/
-[cgit]: https://code.kummerlaender.eu/justify/
diff --git a/pages/projects/kv.md b/pages/projects/kv.md
deleted file mode 100644
index b6fa527..0000000
--- a/pages/projects/kv.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# kv
-
-…is a simple CLI-accessible key value store written in Chicken-Scheme and using CSV as a backend.
-
-While this sort of program may be useful for storing some commonly required data in a easily accessible fashion its primary purpose for me is to be used as a _Chicken-Scheme_ tryout _platform_.
-
-The MIT licensed source code may be found on [Github] or [cgit].
-
-## Usage example
-
-Command                       Description
------------------------------ ----------------------------------------------------
-`kv [show]`                   List all stores
-`kv [show] test`              List all keys of store _test_
-`kv [show] test dummy`        Print value of key _dummy_ in store _test_
-`kv all`                      List all keys and values of all stores
-`kv all test`                 List all keys and values of store _test_
-`kv all test dummy`           Display key and value of key _dummy_ in store _test_
-`kv write test dummy example` Write value _example_ to key _dummy_ in store _test_
-`kv delete test dummy`        Delete key _dummy_ of store _test_
-`kv rename test dummy dummy2` Rename key _dummy_ of store _test_ to _dummy2_
-
-[Github]: https://github.com/KnairdA/kv/
-[cgit]: http://code.kummerlaender.eu/kv/
diff --git a/pages/projects/math_reference_sheets.md b/pages/projects/math_reference_sheets.md
deleted file mode 100644
index 3e65090..0000000
--- a/pages/projects/math_reference_sheets.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Mathematikzusammenfassungen
-
-…zentrale Definitionen, Theoreme und Lemmata in kompaktem Format zur Unterstützung meiner Prüfungsvorbereitungen.
-
-Diese Zusammenfassungen schließen große Teile dessen ein, was ich für die Prüfungen zu den _Analysis I&II_ sowie _Lineare Algebra I&II_ Vorlesungen wiederholt habe, welche ich im Rahmen meines Mathematikstudiums am KIT besucht habe.
-
-Das resultierende PDF der in _LaTeX_ gesetzten und auf [Github] sowie [cgit] verfügbaren Quellen der [Analysis] bzw. [Lineare Algebra] Kurzzusammenfassung steht zum Download bereit.
-
-## Generierung
-
-	pdflatex -jobname=analysis zusammenfassung.tex
-	pdflatex -jobname=lineare_algebra zusammenfassung.tex
-
-[Github]: https://github.com/KnairdA/math_reference_sheets/
-[cgit]: https://code.kummerlaender.eu/math_reference_sheets/
-[Analysis]: https://static.kummerlaender.eu/media/ana12_zusammenfassung.pdf
-[Lineare Algebra]: https://static.kummerlaender.eu/media/la12_zusammenfassung.pdf
diff --git a/pages/projects/meta_term.md b/pages/projects/meta_term.md
deleted file mode 100644
index 36cd8c0..0000000
--- a/pages/projects/meta_term.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# MetaTerm
-
-…is a vim-like mode based user interface enabling running multiple terminal applications at the same time while preserving the sequence of execution.
-
-_MetaTerm_ is implemented in _QML_ and uses [QMLTermWidget] as its embedded terminal emulator.
-
-Its source code is available on both [Github] and [cgit].
-
-## Usage
-
-_MetaTerm_ starts in insert mode which means that one can simply start typing a command and trigger its execution by pressing _enter_.
-
-The list of running and killed terminal instances is navigable using _vim-like_ keybindings, i.e. using `j` and `k`. Additionally one can jump to the top using `g` and to the bottom using `G`. Navigation is also accessible in command mode via `:next`, `:prev` and `:jump <INDEX>`.
-
-Insert mode may be entered manually using `i` and exited using `Shift+ESC`. The currently selected terminal instance is killable via `d`. Command mode is entered whenever one presses `:` in normal mode.
-
-A list of all running processes and their respective index is exposed via `:ls`.
-
-Settings may be explored and changed using `:set` in command mode, e.g. the window background is changeable via `:set window background <COLOR>`.
-
-Furthermore _MetaTerm_'s command mode exposes a JavaScript prompt through `:exec <COMMAND>`.
-
-## Screenshot
-
-![MetaTerm in action](https://static.kummerlaender.eu/media/metaterm_1.png)
-
-[Github]: https://github.com/KnairdA/MetaTerm/
-[cgit]: http://code.kummerlaender.eu/MetaTerm/
-[QMLTermWidget]: https://github.com/Swordfish90/QMLTermWidget/
diff --git a/pages/projects/scribble.md b/pages/projects/scribble.md
deleted file mode 100644
index acd729d..0000000
--- a/pages/projects/scribble.md
+++ /dev/null
@@ -1,8 +0,0 @@
-# Scribble
-
-…is a multi-client scribble board using HTML5-Canvas as drawing and socket.io as communication technology.
-
-I developed this application together with [Thomas Heidrich] and as such the source code is available on his [Github] profile.
-
-[Thomas Heidrich]: http://gnuheidix.de/
-[Github]: https://github.com/gnuheidix/pubsub-scribble
diff --git a/pages/projects/simple_parser.md b/pages/projects/simple_parser.md
deleted file mode 100644
index 0f3f320..0000000
--- a/pages/projects/simple_parser.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# SimpleParser
-
-…is a simple parser for resolving mathematical terms.
-
-The term is parsed by generating a binary expression tree using the [Shunting-Yard] algorithm. The implementation itself does not use any external libraries and relies fully on the features provided by the C++ language and the standard library.
-
-This application marks the first steps in C++ I took a couple of years back and is available on [Github] or [cgit].
-
-## Current features
-
-* Calculating terms with basic operators while respecting the priority of each operator
-* Support for parentheses
-* Support for alphabetic constants
-* Export of the expression tree as [Graphviz] `dot` for visualization
-
-## Visualization
-
-The ability to export the internal binary expression tree resulting from the parsed term as [Graphviz] `dot` is useful for both visualization and debugging purposes. In the following image you can see the depiction of the tree resulting from the arbitrarily chosen term `2.5*(2+3-(3/2+1*(21+11+(5*2))))`:
-
-![Visualization of the parsed tree using Graphviz](https://static.kummerlaender.eu/media/parser_tree.png)
-
-[Graphviz]: http://www.graphviz.org/
-[Github]: https://github.com/KnairdA/SimpleParser/
-[cgit]: http://code.kummerlaender.eu/SimpleParser/
-[Shunting-Yard]: http://en.wikipedia.org/wiki/Shunting-yard_algorithm
diff --git a/pages/projects/spam_question_filter.md b/pages/projects/spam_question_filter.md
deleted file mode 100644
index 45ddd46..0000000
--- a/pages/projects/spam_question_filter.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Spam Question Filter
-
-…is simple event filter for Symphony CMS to prevent spam by asking the user to calculate a easy math question.
-
-I wrote this [Symphony CMS] extension during the development of a new website for a [local musical society] as I was not satisfied with the solutions available for spam prevention in the [Symphony CMS] context.
-
-The source code is available via [Github] or [cgit] for your convenience.
-
-[Symphony CMS]: http://www.getsymphony.com/
-[Github]: https://github.com/KnairdA/spamquestionfilter
-[cgit]: http://code.kummerlaender.eu/spamquestionfilter/
-[local musical society]: http://mv-mahlspueren.de
diff --git a/pages/projects/static_xslt.md b/pages/projects/static_xslt.md
deleted file mode 100644
index b15a9f4..0000000
--- a/pages/projects/static_xslt.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# StaticXSLT
-
-…is the XSLT based static site generation framework especially developed to generate this website.
-
-Its MIT licensed source code is available on both [Github] and [cgit].
-
-The implementation of a pure[^1] XSLT solution to the problem of static site generation required the development of a collection of external functions enabling access to the filesystem, external applications and other transformations from inside XSLT. These external functions are not part of this project and were developed separately as [InputXSLT]. Additionally a basic XSLT build system was developed to make _StaticXSLT_ usable for different projects which is available as [BuildXSLT].
-
-The prime example of how this framework may be used in practice is the implementation of [this website]. 
-
-## Overview
-
-The implementation of the static site generator is contained within the `src/steps` directory of the linked repository and consists of four XSL transformations that all form a link in the generation chain module executed by [BuildXSLT].
-
-These transformations traverse the given source directory, plan tasks[^2] to be executed, process those tasks and summarize the result for the user.
-
-```
-common:~# ixslt --input make.xml --transformation ../BuildXSLT/build.xsl
-Tasks processed:  19
-Tasks successful: 19
-▶ Generation successful.
-common:~#
-```
-
-The first of these transformations `list.xsl` traverses and lists a `source` directory containing various _levels_ depicting the different stages of the actual static site generation process as a base for all further processing.
-
-Based on the results of the `list.xsl` transformation the next transformation `plan.xsl` schedules a number of different tasks to be processed by `process.xsl`. Examples for these tasks are cleaning a `target` directory, linking files and folders and of course generating transformation stylesheets contained within the various _levels_ of the `source` tree.
-
-After the various tasks are processed by `process.xsl` the results of all tasks are summarized by `summarize.xsl` to provide the user with a easy to read plain-text output.
-
-## Levels
-
-A _level_ is simply a folder within a given `source` directory which may in turn contain a arbitrary number of transformations and source documents inside subfolders. All transformations within these _levels_ are processed by the _StaticXSLT_ transformation chain which handles datasource dependency resolution and preserves the correct result path context. _Levels_ are processed according to their alphabetic order. Subfolders of _level_ directories that do not contain any XSLT stylesheets and non-stylesheet files are automatically symlinked to their appropriate target directory.
-
-## Data Source and target resolution
-
-Every transformation contained in one of the _levels_ contains a `meta` variable defining the required data sources and target paths. This information is read during task processing by the `process.xsl` transformation and used to provide each transformation with the data sources it requires and write the output to the path it desires. This definition of requirements and targets directly inside each transformation is an essential part of how this static site generation concept works.
-
-The system currently provides a couple of different data source reading modes such as `full` for reading a complete XML file as input, `iterate` for iterating the second-level elements of a given XML source and `expression` for evaluating a arbitrary XPath expression against a given XML file. Target modes include `plain` for writing a the result into a given file at the appropriate target level and `xpath` for evaluating a XPath expression to generate the target path. This XPath evaluation functionality in combination with the `iterate` data source mode is especially helpful in situations where one wants to generate multiple output files from a single transformation such as when generating article pages or the pages of the article stream.
-
-## Differentiation and limitations
-
-This approach to static site generation is novel in the manner that it is the only publicly available XSLT based solution to this problem domain that I am aware of, which uses XSLT as both the application and template language. I extended XSLT with [InputXSLT] and developed this static site generation in the attempt of producing something as flexible as [Symphony CMS] that generates static output.
-
-The current implementation of the concept described on this page is limited in the sense that it doesn't support incremental regeneration but generates the whole website from scratch on each run. While this problem should also be solvable in pure XSLT, I currently do not plan on solving it as it is fast enough for my current use cases and largely depends on the speed of the used Markdown processor and syntax highlighter anyway.
-
-[^1]: Pure as in all templates, data source aggregation and the generation logic itself is implemented in XSLT. Tasks like e.g. syntax highlighting and Markdown processing are still handled by external programs called from within XSLT.
-[^2]: Tasks include cleaning directories, generating transformations and symlinking directories and files into the target directory
-
-[Github]: https://github.com/KnairdA/StaticXSLT/
-[cgit]: http://code.kummerlaender.eu/StaticXSLT/
-[BuildXSLT]: /page/build_xslt/
-[InputXSLT]: /page/input_xslt/
-[this website]: /page/this_website/
-[Symphony CMS]: http://getsymphony.com
diff --git a/pages/projects/telebot.md b/pages/projects/telebot.md
deleted file mode 100644
index 3f2d2f8..0000000
--- a/pages/projects/telebot.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Telebot
-
-…is a basic Chicken Scheme module to ease the development of Bots interfacing with the Telegram Bot API.
-
-In this context _basic_ means that the module currently consists of barely more than raw HTTP API calls hidden behind analogously named functions and JSON deserialization provided by the _http-client_ respectively _medea_ eggs.
-
-The maintanance of these API wrappers is simplified by an appropriate _Scheme_ macro that reduces the implementation of new API methods to basically slightly rewriting the [documentation].
-
-_Telebot_ is available under the terms of the MIT license on [Github] and [cgit].
-
-## Documentation
-
-All _basic_ API wrappers are named the same as their method name and require the bot's token as their first argument. Further parameters are expected as named key value pairs. Note that the library currently only verifies that all required parameters are supplied at all while type verification is left to _Telegram's_ server side logic.
-
-```lisp
-(sendMessage token
-             chat_id: chat_id
-             text:    text)
-```
-
-All API wrappers return the raw deserialized JSON results as to not limit the options for further parsing unnecessarily.
-
-The only non-API wrapper provided by this library is `pollUpdates` which enables passing updates acquired via long polling of `getUpdates` to an arbitrary function as follows:
-
-```lisp
-(pollUpdates token
-             (lambda (u)
-               (begin (print-message u)
-                      (echo-message  u))))
-```
-
-[documentation]: https://core.telegram.org/bots/api
-[Github]: https://github.com/KnairdA/telebot/
-[cgit]: https://code.kummerlaender.eu/Telebot/
diff --git a/pages/projects/this_website.md b/pages/projects/this_website.md
deleted file mode 100644
index 4e252d5..0000000
--- a/pages/projects/this_website.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# blog.kummerlaender.eu
-
-…is the set of XSLT transformations used to generate this website.
-
-Its MIT licensed source code is available both [Github] and [cgit].
-
-This implementation of XSLT based solution to the problem of static site generation depends on a collection of different projects such as [InputXSLT] which adds additonal functionality to XSLT through external functions, [BuildXSLT] which implements a basic XSLT build system and [StaticXSLT] which implements a generic static site generation framework as a module for the build system.
-
-## Overview
-
-The first level `00_content` contains the actual content source of the blog to be generated. This includes articles and pages formatted in Markdown and meta-data such as the page title, public URL and primary author in `meta.xml`. It is notable that this first level doesn't contain any actual transformations and as such only provides a way to store the input to _levels_ further down the processing pipeline.
-
-The second level `01_data` reads the contents of the `00_content` level and generates data sources for articles, pages and tags. These data sources contain e.g. the augmented contents of articles already converted from Markdown into _XHTML_ and separated into title, data and content areas.
-
-The third level `02_meta` further augments and groups these data sources. For example articles are grouped by year, tags and categories are resolved and augmented with article data provided by the previous level and articles are paginated in preparation for generating the primary article stream.
-
-Last but not least the fourth level `99_content` takes all the data sources generated in lower _levels_ and generates the actual website pages.
-
-[Github]: https://github.com/KnairdA/blog.kummerlaender.eu/
-[cgit]: http://code.kummerlaender.eu/blog.kummerlaender.eu/
-[module]: /page/static_xslt/
-[BuildXSLT]: /page/build_xslt/
-[InputXSLT]: /page/input_xslt/
-[StaticXSLT]: /page/static_xslt/