|
|
|
|
|
<!doctype html>
|
|
|
|
|
|
<html>
|
|
|
|
|
|
<head>
|
|
|
|
|
|
<meta charset=utf-8>
|
|
|
|
|
|
<meta name=generator content="Pelican 4.9.1">
|
|
|
|
|
|
<meta name=author content="LEdoian">
|
|
|
|
|
|
<meta name=description content="My personal webpage">
|
|
|
|
|
|
<meta name=referrer content=no-referrer>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<link rel=stylesheet href="./theme/css/theme.css">
|
|
|
|
|
|
|
|
|
|
|
|
<title>About this blog – LEdoian's Blog</title>
|
|
|
|
|
|
</head>
|
|
|
|
|
|
<body>
|
|
|
|
|
|
|
|
|
|
|
|
<header>
|
|
|
|
|
|
<h1>LEdoian's Blog</h1>
|
|
|
|
|
|
</header>
|
|
|
|
|
|
|
|
|
|
|
|
<div id=main>
|
|
|
|
|
|
<nav>
|
|
|
|
|
|
<div>
|
|
|
|
|
|
<!-- Main navigation -->
|
|
|
|
|
|
<!-- TODO! -->
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div>
|
|
|
|
|
|
<h2>Categories</h2>
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li><a href="./category/talks.html">talks</a></li>
|
|
|
|
|
|
<li><a href="./category/technology.html">technology</a></li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
<h2>Tags</h2>
|
|
|
|
|
|
<ul>
|
|
|
|
|
|
<li><a href="./tag/meta.html">meta</a></li>
|
|
|
|
|
|
<li><a href="./tag/infrastructure.html">infrastructure</a></li>
|
|
|
|
|
|
<li><a href="./tag/smrst.html">smršť</a></li>
|
|
|
|
|
|
<li><a href="./tag/trains.html">trains</a></li>
|
|
|
|
|
|
<li><a href="./tag/software-engineering.html">software-engineering</a></li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div>
|
|
|
|
|
|
<h2>Stalk me also at</h2>
|
|
|
|
|
|
TODO!
|
|
|
|
|
|
|
|
|
|
|
|
<h2>I stalk</h2>
|
|
|
|
|
|
TODO!
|
|
|
|
|
|
</nav>
|
|
|
|
|
|
|
|
|
|
|
|
<main>
|
|
|
|
|
|
<div>
|
|
|
|
|
|
<h1>About this blog</h1>
|
|
|
|
|
|
<p>This is my blog and this article describes its setup and other details about my
|
|
|
|
|
|
intentions. The actual <a class="reference internal" href="#the-setup">setup</a> is probably the most
|
|
|
|
|
|
interesting tech-wise.</p>
|
|
|
|
|
|
<div class="section" id="what-is-this">
|
|
|
|
|
|
<h2>What is this?</h2>
|
|
|
|
|
|
<p>My own space on the internet where I can post whatever and link others to it.
|
|
|
|
|
|
It might end up containing rants, guides, ideas, or maybe nothing at all in the
|
|
|
|
|
|
end. Only the future will tell.</p>
|
|
|
|
|
|
<p>The blog might even serve as my personal web page/introduction. Maybe. Maybe not…</p>
|
|
|
|
|
|
<p>The main motivation is to have low-effort way to post random stuff. Which leads
|
|
|
|
|
|
to my requirements for this thing.</p>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="section" id="requirements">
|
|
|
|
|
|
<h2>Requirements</h2>
|
|
|
|
|
|
<p>(The requirements are a bit too idealistic, so not all of them were satisfied…)</p>
|
|
|
|
|
|
<ul class="simple">
|
|
|
|
|
|
<li>low-effort, me-friendly, low-maintenance – I don't want to have to learn too
|
|
|
|
|
|
many new technologies to use this. This includes the required technologies:
|
|
|
|
|
|
Python, Markdown/reStructuredText, Jinja2, git, …</li>
|
|
|
|
|
|
<li>Technical and math content ~~friendly~~ compatible – I expect that to appear
|
|
|
|
|
|
here.</li>
|
|
|
|
|
|
<li>Static site – for security, coolness factor and control. Also static on the
|
|
|
|
|
|
front-end, because I don't like JavaScript and/or running untrusted code on
|
|
|
|
|
|
my machine (even when in a sandbox). The SSG should likely be aimed at
|
|
|
|
|
|
creating blogs, not documentation. Also, self-contained, as in not depending
|
|
|
|
|
|
on third-party sites.</li>
|
|
|
|
|
|
<li>No moving parts in the infrastructure (or as few as possible) – if it works
|
|
|
|
|
|
on my machine, it should just get mirrored to the public site with as few
|
|
|
|
|
|
modifications as possible.</li>
|
|
|
|
|
|
<li>Transparent – I should be able to understand it, maybe others could also use
|
|
|
|
|
|
it as a resource or take inspiration. (At one point, this deployment itself
|
|
|
|
|
|
started being interesting, so if I can share the background as well as the
|
|
|
|
|
|
final webpage, it would be cool.)</li>
|
|
|
|
|
|
<li>Followable – I know you internet guys like to ~~stalk~~ follow people :-)</li>
|
|
|
|
|
|
<li>Aligned with my values: minimalist, simple, extensible/hackable, FLOSS</li>
|
|
|
|
|
|
<li>If the platform could distinguish translations and do strikethroughs, it would
|
|
|
|
|
|
be nice, but that is not a hard requirement.</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
<p>There are several features of conventional blogs that I consider to be a
|
|
|
|
|
|
non-goals or even anti-goals. Mostly it is about interactivity – I don't aim
|
|
|
|
|
|
for having any kind of comments here, or really anything that would require
|
|
|
|
|
|
JavaScript or complex HTML/CSS. And appearance goes past me as well, I instead
|
|
|
|
|
|
try to let the browser decide how to display this page – more on that <a class="reference internal" href="#design-considerations">below</a>.</p>
|
|
|
|
|
|
<p>The workflow I wanted to achieve is something like: Write the content, git it,
|
|
|
|
|
|
build it (locally, no CI/CD), push it, done. Single write, single push, very
|
|
|
|
|
|
simple.</p>
|
|
|
|
|
|
<p>And I managed to achieve something like that, via learning (too much?) about
|
|
|
|
|
|
git.</p>
|
|
|
|
|
|
<!-- TODO: fix the worktree bug already! -->
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="section" id="the-setup">
|
|
|
|
|
|
<h2>The setup</h2>
|
|
|
|
|
|
<p>Naturally for a sysadmin/netadmin, the setup consists of 7 ~~ISO/OSI~~ layers:</p>
|
|
|
|
|
|
<ol class="arabic simple">
|
|
|
|
|
|
<li><strong>Physical layer</strong>: cheap Hetzner VPS. Not physical, but whatever.</li>
|
|
|
|
|
|
<li><strong>Network layer</strong>: Nginx</li>
|
|
|
|
|
|
<li><strong>Persistence layer</strong>: <a class="reference external" href="https://gitea.ledoian.cz/LEdoian/blog">this git repo</a>. I will elaborate below why can
|
|
|
|
|
|
you see this both rendered here and in the source form in Forgejo.</li>
|
|
|
|
|
|
<li><strong>Content layer</strong>: Markdown or reStructuredText files.</li>
|
|
|
|
|
|
<li><strong>Business logic layer</strong>: <a class="reference external" href="https://getpelican.com">Pelican</a>. It's rather
|
|
|
|
|
|
popular and written in Python, I didn't look further.</li>
|
|
|
|
|
|
<li><strong>Presentation layer</strong>: I hacked my own theme, because I didn't like any in
|
|
|
|
|
|
the <a class="reference external" href="https://github.com/getpelican/pelican-themes">pelican-themes repo</a>.
|
|
|
|
|
|
I was a bit inspired by the layout of <a class="reference external" href="https://eev.ee/blog">eevee's blog</a>, but I wanted a dark theme. And as you can see, I
|
|
|
|
|
|
can't do quality frontend, so it ended up horrible… :-D</li>
|
|
|
|
|
|
<li><strong>Stalking layer</strong>: Pelican's built-in RSS and Atom feed generators. Not
|
|
|
|
|
|
linked from anywhere at the moment, but <a class="reference external" href="https://gitea.ledoian.cz/LEdoian/blog/src/branch/blog/output/feeds">the repo will tell you</a> what
|
|
|
|
|
|
hides under the <tt class="docutils literal">/feeds/</tt> path. Or you can utilize the repo (for personal
|
|
|
|
|
|
use – the content's license is not decided at the moment)…</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<p>Most of this is straightforward, the fancy part is my repo. The repo contains
|
|
|
|
|
|
both source and rendered content, so that I can point Nginx right at a checkout
|
|
|
|
|
|
and have Git solve both persistence and deployment without additional moving
|
|
|
|
|
|
parts.</p>
|
|
|
|
|
|
<p>There are two tricks in the configuration of Git repositories: pushing to a
|
|
|
|
|
|
checked out repo is enabled by configuring <tt class="docutils literal">receive.denyCurrentBranch =
|
|
|
|
|
|
updateInstead</tt> in the target repository (which is just a normal repo, not a
|
|
|
|
|
|
bare one), and then I just told my source repositories <a class="footnote-reference" href="#multiple-src" id="footnote-reference-1">[1]</a> to use
|
|
|
|
|
|
two push targets for the remote (the first line <em>replaces</em> the original push
|
|
|
|
|
|
address for some reason):</p>
|
|
|
|
|
|
<pre class="literal-block">
|
|
|
|
|
|
git remote set-url --add --push blog_remote gitea@gitea.ledoian.cz:LEdoian/blog.git
|
|
|
|
|
|
git remote set-url --add --push blog_remote blog_user@blog.ledoian.cz:blog_dir
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
<p>The blog user is just a user with SSH access via authorized keys, no special
|
|
|
|
|
|
sauce there. Nginx is then pointed to serve <tt class="docutils literal">~blog_user/blog_dir/output/</tt> at
|
|
|
|
|
|
<tt class="docutils literal">blog.ledoian.cz</tt>. (The <tt class="docutils literal"><span class="pre">git-remote(1)</span></tt> manpage requires me to have both
|
|
|
|
|
|
repositories in sync, but as long as I configure all my repositories this way,
|
|
|
|
|
|
I should be safe, and I think I could get away with my blog checkout getting
|
|
|
|
|
|
behind accidentally.)</p>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="section" id="my-workflow-and-lots-of-drafts">
|
|
|
|
|
|
<h2>My workflow and lots of drafts</h2>
|
|
|
|
|
|
<p>It's Git so it's only natural for me to use various branches and repositories
|
|
|
|
|
|
even for a dumb blog. There are in fact 4 stages an article may go through <a class="footnote-reference" href="#skipping-stages" id="footnote-reference-2">[2]</a>:</p>
|
|
|
|
|
|
<ol class="arabic">
|
|
|
|
|
|
<li><p class="first">A private draft: lives on a branch <tt class="docutils literal">priv/something</tt>, may contain private
|
|
|
|
|
|
infos (like when I would just copy-paste from terminal without redaction)
|
|
|
|
|
|
and this branch will probably never be merged to the main repo. Nothing
|
|
|
|
|
|
about these branches is guaranteed.</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
<li><p class="first">A public WIP draft: uses a branch called <tt class="docutils literal">pub/something</tt> which is pushed
|
|
|
|
|
|
to Forgejo (and in fact also to the blog itself, but that is just an
|
|
|
|
|
|
implementation detail). The draft is either does not build or is very
|
|
|
|
|
|
incomplete and I expect to add stuff in a way that could break the build, so
|
|
|
|
|
|
I put it on a separate branch. The branch will be probably merged to the
|
|
|
|
|
|
main branch (called <tt class="docutils literal">blog</tt>) when it is ready.</p>
|
|
|
|
|
|
<p>The <tt class="docutils literal">pub/…</tt> branches can be created either manually or by cherry-picking
|
|
|
|
|
|
from the respective <tt class="docutils literal">priv/…</tt> branch, but that will likely not be
|
|
|
|
|
|
distinguishable. (I am too lazy to keep the references even in the commit
|
|
|
|
|
|
logs.)</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
<li><p class="first">When a draft is almost ready (or the content has simple syntax), it gets
|
|
|
|
|
|
placed on the <tt class="docutils literal">blog</tt> branch. The only thing that designates it as a draft
|
|
|
|
|
|
is <tt class="docutils literal">status: draft</tt> in the frontmatter, which means that the article will
|
|
|
|
|
|
get rendered and put somewhere on the public blog, but not reachable from
|
|
|
|
|
|
the title page ("unlisted").</p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
<li><p class="first">Of course, eventually (and hopefully) the article gets published for
|
|
|
|
|
|
everyone to see. At that point, it is complete (or at least that is what I
|
|
|
|
|
|
thought when marking it as published). Possibly it might be updated in the
|
|
|
|
|
|
future, but no such update is anticipated at the moment of publishing. <a class="footnote-reference" href="#update-this" id="footnote-reference-3">[3]</a></p>
|
|
|
|
|
|
</li>
|
|
|
|
|
|
</ol>
|
|
|
|
|
|
<p>I use Git to synchronize my private branches among machines, so there are
|
|
|
|
|
|
actually two "server-side" repositories (private and public one) and thus two
|
|
|
|
|
|
remotes. <a class="footnote-reference" href="#private-branches-wish" id="footnote-reference-4">[4]</a></p>
|
|
|
|
|
|
<p>As for the actual workflow, for the main branch it usually consists of: writing
|
|
|
|
|
|
content, committing it, building the web, checking it locally, committing the
|
|
|
|
|
|
built blog and pushing it. Sometimes I do the commits together, but I always
|
|
|
|
|
|
separate the rendering/building commits from the content-creating ones, so that
|
|
|
|
|
|
I can handle those differently if needed (i.e. there is no point in
|
|
|
|
|
|
cherry-picking the built content, I can generate it). <a class="footnote-reference" href="#git-purists" id="footnote-reference-5">[5]</a></p>
|
|
|
|
|
|
<p>For other branches I use some applicable subset of the steps above, probably.</p>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="section" id="design-considerations">
|
|
|
|
|
|
<h2>Design considerations</h2>
|
|
|
|
|
|
<p>The appearance of the blog is maybe not nice. That is for two reasons: I don't
|
|
|
|
|
|
have the right idea about how to make it much better and I want to have a
|
|
|
|
|
|
rather simple CSS for the web. The latter wish is because I tend to tweak
|
|
|
|
|
|
appearance of sites I visit using my own styles, so I would like you to be able
|
|
|
|
|
|
to do the same.</p>
|
|
|
|
|
|
<p>And for the former reason, if you have any ideas / improvements (including user
|
|
|
|
|
|
styles), hit me at <a class="reference external" href="mailto:blog@pokemon.ledoian.cz">blog@pokemon.ledoian.cz</a> :-)</p>
|
|
|
|
|
|
<p>My overall idea is a dark-by-default <a class="footnote-reference" href="#light-theme" id="footnote-reference-6">[6]</a> minimalist page with a single menu on the
|
|
|
|
|
|
right containig all the relevant links. The page should not dictate too much
|
|
|
|
|
|
but rather let the user agent decide the rendering (<a class="reference external" href="https://html.spec.whatwg.org/multipage/rendering.html#rendering">it does anyway…</a>).</p>
|
|
|
|
|
|
<p>I want my blog to render similarly in Gecko-, WebKit- and Blink-based browsers
|
|
|
|
|
|
(e.g. Firefox, Badwolf, Qutebrowser). Others should be usable.
|
|
|
|
|
|
Browser-/engine-specific styles are not welcome – let's keep it simple. And no
|
|
|
|
|
|
JavaScript…</p>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="section" id="work-in-progress-todos">
|
|
|
|
|
|
<h2>Work in progress / TODOs</h2>
|
|
|
|
|
|
<p>This thing is at the moment very barebones, which is sufficient for the main
|
|
|
|
|
|
purpose. However, I would like to have some features here, one day, hopefully:</p>
|
|
|
|
|
|
<ul class="simple">
|
|
|
|
|
|
<li>Dates in the article headers (and maybe more improvements of the theme, see
|
|
|
|
|
|
above)</li>
|
|
|
|
|
|
<li>Stable category and tag names and a page with a description of them. As of
|
|
|
|
|
|
now I haven't really invented a system of sorting my content, which leads to
|
|
|
|
|
|
a mess… Please don't rely on categories having any particular name / URL for
|
|
|
|
|
|
now.</li>
|
|
|
|
|
|
<li>Link the RSS feeds from somewhere</li>
|
|
|
|
|
|
<li>Personal info with links to my other profiles</li>
|
|
|
|
|
|
<li>Some linking to the Fediverse and using it for comments (since there will be
|
|
|
|
|
|
no comments here)</li>
|
|
|
|
|
|
<li>Sensible translations, maybe (if I/someone ever get to write the same content
|
|
|
|
|
|
again in a different language…)</li>
|
|
|
|
|
|
<li>Improve the list of talks I've given (create some kind of sensible table maybe?)</li>
|
|
|
|
|
|
<li>Decide on a licence for the content (If you want to utilize something here
|
|
|
|
|
|
before I do that, please ask me, I think we can find a way :-))</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
<p>If you are so upset with this blog (or maybe bored) that you want to improve
|
|
|
|
|
|
it, send me patches / ideas. I don't expect anyone to do that, though :-D (And
|
|
|
|
|
|
I do not promise you that I will use the patch, even if it matches all my
|
|
|
|
|
|
opinions above. I also have some gut feelings about what I like…)</p>
|
|
|
|
|
|
<p>Also, tell me if you hate something else about my page. I want to at least know
|
|
|
|
|
|
whom I upset :-D (but I will probably also think about your gripes and whether
|
|
|
|
|
|
I can and should try to avoid them…)</p>
|
|
|
|
|
|
<hr class="docutils" />
|
|
|
|
|
|
<table class="docutils footnote" frame="void" id="multiple-src" rules="none">
|
|
|
|
|
|
<colgroup><col class="label" /><col /></colgroup>
|
|
|
|
|
|
<tbody valign="top">
|
|
|
|
|
|
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-1">[1]</a></td><td>I also use multiple machines on which I can write stuff.</td></tr>
|
|
|
|
|
|
</tbody>
|
|
|
|
|
|
</table>
|
|
|
|
|
|
<table class="docutils footnote" frame="void" id="skipping-stages" rules="none">
|
|
|
|
|
|
<colgroup><col class="label" /><col /></colgroup>
|
|
|
|
|
|
<tbody valign="top">
|
|
|
|
|
|
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-2">[2]</a></td><td><p class="first">I am lazy and chaotic (good), so the stages are optional
|
|
|
|
|
|
and non-linear, and sometimes involve paper. This article is a prime
|
|
|
|
|
|
example: parts of it were on two different private branches, but at the end
|
|
|
|
|
|
I wrote it from scratch directly on the main branch. And the requirements
|
|
|
|
|
|
were written on a paper originally.</p>
|
|
|
|
|
|
<p class="last">Nevertheless, the general idea still holds and may inspire others, so it
|
|
|
|
|
|
makes sense to keep this part in the article. (Also, this footnote might not
|
|
|
|
|
|
make sense before reading the definition of the stages, but I didn't find a
|
|
|
|
|
|
better place to put it…)</p>
|
|
|
|
|
|
</td></tr>
|
|
|
|
|
|
</tbody>
|
|
|
|
|
|
</table>
|
|
|
|
|
|
<table class="docutils footnote" frame="void" id="update-this" rules="none">
|
|
|
|
|
|
<colgroup><col class="label" /><col /></colgroup>
|
|
|
|
|
|
<tbody valign="top">
|
|
|
|
|
|
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-3">[3]</a></td><td>Well, given this article contains some future plans, I
|
|
|
|
|
|
actually anticipate update of this one, but maybe not in the near future. So
|
|
|
|
|
|
the outline is not really correct, but I make the rules :-) (There
|
|
|
|
|
|
were some build breaks on the main branch, too :-D)</td></tr>
|
|
|
|
|
|
</tbody>
|
|
|
|
|
|
</table>
|
|
|
|
|
|
<table class="docutils footnote" frame="void" id="private-branches-wish" rules="none">
|
|
|
|
|
|
<colgroup><col class="label" /><col /></colgroup>
|
|
|
|
|
|
<tbody valign="top">
|
|
|
|
|
|
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-4">[4]</a></td><td>I would love if my Forgejo could have "private
|
|
|
|
|
|
branches", but I understand that the overhead for doing this is not nice,
|
|
|
|
|
|
since it would need to be able to decide for any object, whether it is
|
|
|
|
|
|
public or not (you can do <tt class="docutils literal">git fetch <remote> <span class="pre"><object-hash></span></tt>) and somehow
|
|
|
|
|
|
keep track even with rebases, merges, force-pushes, many branches, … Having
|
|
|
|
|
|
a separate private repository is not a big problem in comparison.</td></tr>
|
|
|
|
|
|
</tbody>
|
|
|
|
|
|
</table>
|
|
|
|
|
|
<table class="docutils footnote" frame="void" id="git-purists" rules="none">
|
|
|
|
|
|
<colgroup><col class="label" /><col /></colgroup>
|
|
|
|
|
|
<tbody valign="top">
|
|
|
|
|
|
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-5">[5]</a></td><td>Git purists might want to tell me that committing build
|
|
|
|
|
|
artifacts is not good practice. I know and I explicitly don't care in case
|
|
|
|
|
|
of this repo, because here I prioritise my own comfort of being able to
|
|
|
|
|
|
check everything locally and then be reasonably sure the deployed version
|
|
|
|
|
|
will also work, all this with only a single push somewhere. Of course, one
|
|
|
|
|
|
could argue that with that there is no reason to create two commits, but it
|
|
|
|
|
|
does not really bother me to run something like <tt class="docutils literal">git commit <span class="pre">-m"render"</span>
|
|
|
|
|
|
output/</tt> when I am sure it works, and this keeps readable diffs separate
|
|
|
|
|
|
from the non-readable ones (i.e. the changes in generated HTML).</td></tr>
|
|
|
|
|
|
</tbody>
|
|
|
|
|
|
</table>
|
|
|
|
|
|
<table class="docutils footnote" frame="void" id="light-theme" rules="none">
|
|
|
|
|
|
<colgroup><col class="label" /><col /></colgroup>
|
|
|
|
|
|
<tbody valign="top">
|
|
|
|
|
|
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-6">[6]</a></td><td>Having the page be dark-by-default is my preference, but I
|
|
|
|
|
|
respect that others may prefer light sites. However, I have not yet
|
|
|
|
|
|
determined what colors should be used (probably still cyan / blue / maybe
|
|
|
|
|
|
purple-ish, but I don't know what shade) nor understood how to use
|
|
|
|
|
|
<tt class="docutils literal"><span class="pre">@media(prefers-color-scheme)</span></tt> in a maintainable and simple way (in the
|
|
|
|
|
|
context of my theme). So naturally, this is postponed to the future…</td></tr>
|
|
|
|
|
|
</tbody>
|
|
|
|
|
|
</table>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</main>
|
|
|
|
|
|
</div> <!-- #main -->
|
|
|
|
|
|
|
|
|
|
|
|
<footer>
|
|
|
|
|
|
<hr>
|
|
|
|
|
|
Written using Pelican 4.9.1 by LEdoian.
|
|
|
|
|
|
</footer>
|
|
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
|
|
</html>
|
