microblog :3
-i have no twitter and i must post, please subscribe to my atom feed :)
++ i miss twitter honestly +
+From b0d10c062370a7700908faf59b7656882dd0c21a Mon Sep 17 00:00:00 2001
From: m1ka
diff --git a/macroblog/kethel2.html b/macroblog/kethel2.html
index 8e45396b40657c7f68c67996cf7373bef21e421d..643340fb0c48d472d9daeb3022ce93a6b73bab2e 100644
--- a/macroblog/kethel2.html
+++ b/macroblog/kethel2.html
@@ -14,35 +14,39 @@
So, what language is the most portable, has universal support across linux distributions?
ISO/IEC 9899:1999, or The C Programming Language - of course!
- Kethel isn't a perfect SSG by any means; it sometimes just writes garbled data to the output HTML fil
+ Kethel isn't perfect by any means; it sometimes just writes garbled data to the output HTML document
if a template or TSV ends with a newline, is probably vulnerable to several buffer overflow attacks,
- as no bounds checking is implemented at all for the templates, and treats HTML as plain text, with only a
- strncmp "parser". Yet, it still works!
- So, I'd like to explain some design decisions behind Kethel/2, and convince YOU to use less CSS in your website!
+ as no bounds checking is implemented at all, treats HTML as plain text, with only a
+ "parser" which breaks if you change any nearly any formatting in the templates. And yet, it still works!
+ So, I'd like to explain some design decisions behind Kethel/2, for fun and to break-even on the time spent on
+ this.
aggregate, and my "solution" to index page generationAggregate was the 2nd program I wrote for my site, which fills the spot of a 'compiler', if we're following the compiler/linker metaphor. The RSS feed generation for my site before was really iffy (RFC822 and RFC2822 are to blame). - I could definitely have switched to atom feeds instead of RSS in the original kethel, but i had better things to do with my time then + I could have switched to atom feeds instead of RSS in the original kethel, but I had better things to do with my time then refactor all my elixir code. - (this isnt an issue with elixir per se, but moreso that i didnt really wanna debug MY code every time i wanted to make a change - to my site, architecturally kethel1 kinda sucked) + (This isn't an issue with elixir per se, but moreso that I didnt really wanna debug my elixir, wrote as my first and only elixir project)
The general idea with aggregate is that you provide a TSV file, with some free-form data, and aggregate could transform that into an index page,
- but also an atom <entry>, with proper tag uri support. Coming back to the first sentence about the 'compiler' metaphor,
- aggregate does not generate the final html, but only take the TSV and generate a mkpage-compatible 'object page'. Since I've
- only used C in this project, I already had an obj folder for intermediate output, so it was easy to just generate all the indexes, and
- various feed entries, and use mkpage as an ersatz-linker, to generate the final XML/HTML.
+ but also an Atom <entry>, with proper tag uri support. Coming back to the first sentence about the 'compiler' metaphor,
+ aggregate does not generate the final html, but only 'preprocesses' the templates and generates a mkpage-compatible 'object page'.
+
+ Since I've only used C in this project, I already had an obj folder for intermediate output, so it was easy to just generate all the indexes, and
+ various feed entries, and use mkpage as a sort of ersatz-linker, to generate the final XML/HTML.
mkpage all about then?- mkpage is the original program that orchestrated all HTML generation, inspired by PHP's "it's just html!" approach, and - my code editors unwillingness to let me use unclosed tags in a template file. I chose to use simple HTML comments - with some meaning, which I then decode in C. + Mkpage is the original program that orchestrated all HTML generation, inspired by PHP's "it's just html!" approach, and + my code editor's unwillingness to let me use unclosed tags in my template html files. I chose to use simple HTML comments + with some meaning, which I then decode in C. Originally an experiment to only generate my homepage, it's been able to generate a lot of my pages + relatively quickly.
However, it quickly become clear that my linear-time no-seek approach to page generation wasnt really going to scale to, say,
@@ -51,8 +55,9 @@
STAMP is used mostly for atom feed generation, but is generalised to work in most cases where you'd need a timestamp.
- Therefore, aggregate deals with most of the more complex parts of my websites build pipeline. - Aggregate supports a lot more commands, compared to mkpage. + Therefore, aggregate deals with most of the more complex parts of my website's build pipeline. A combination of some hardcoded behaviour (C + lets you get away with way worse software architecture than elixir), and some generalised 'paradigms', has let me create this entire website with only 7 commands. + Aggregate takes care of most of the more complicated commands, listed below.
ANCHOR - generates a reproducible id for any content-item, another issue i was dealing with in kethel2 - Besides some dependency modelling in make, this is all that Kethel2 comes with. I hope that you find some inspiration - in my architectural choices here, and if not, i'll still keep enjoying my sub-halfsecond build times. + Besides some dependency modelling in make, this is all that Kethel2 really needs. The only things I'd maybe want to change (or create, for funsies). +
Merci d'avoir lu!diff --git a/microblog/index.html b/microblog/index.html index 4a179fc3b0f49ea917bfef5dc081732c039e9212..afabaf7fdcbf9c6a894db2a41f0ae2db601a5c2b 100644 --- a/microblog/index.html +++ b/microblog/index.html @@ -9,7 +9,10 @@
i have no twitter and i must post, please subscribe to my atom feed :)
++ i miss twitter honestly +
+