Journal : 2024-05-13

The 90:90 rule : the first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. (I was about to type a different version, but GitHub #Copilot suggested that, it's a good one).

I've been rather blocked by #Postcraft, it is a major priority for me to have a blogging¹ system in place. So I'll go quick & dirty now to get something up and running, refactor later.

In the Postcraft transmission, I've got Phase 1 working, from markdown to raw HTML (the notion of phases is useful, I'll use that).

s:ConfigMap pulls in the configuration from manifest.ttl, it's at the context.sourceDir etc level for Phase 1, but because Phase 2, I've got that going into a sub-object entryContentToPage, so after Phase 1 the context includes:

{
   "entryContentToPage": {
    "sourceDir": "public/post-content-cache",
    "targetDir": "public/blog",
    "templateFilename": "layouts/mediocre/post-page_template.njk"
  },

  "contentBlocks": {
    "link": "public/post-content-cache/2024-05-03_two.html",
    "title": " TEST TWO",
    "created": "2024-05-03",
    "updated": "2024-05-13",
    "content": "<h4>TEST TWO</h4>\n<p>here is the content of the second post</p>\n"
  },

  "filepath": "/home/danny/HKMS/postcraft/danny.ayers.name/public/post-content-cache/2024-05-03_two.html",

  "rootDir": "/home/danny/HKMS/postcraft/danny.ayers.name",
  "filename": "2024-05-03_two.md",

}

The value of contentBlocks.link I guess should be the full URL of the page. But before I sort that out, wherever that is assigned is where I need to get the target filepath for the entry page. Also the Slug (with my own conventions).

s:Template has signature (Good Word!) :

• Input
• context.templateFilename or if not present,
• context.template
• context.contentBlocks - {title, body...} or whatever
• Output
• context.content - the templated content

Ok, quick & dirty, I'll make an s:EntryContentToPagePrep hardcoded service to do the remapping.

Ok, nearly working. The link URL that gets templated isn't quite right : https://danny.ayers.name/blog/2024-05-03_one.html.html.html - oops!

Plan

• Bergi 'Unified Landscape'
• prep phone for return

Postcraft

NEXT - paths for entry pages/fix errors in PostCraftPrep - can refactor to simplify? check s:ConfigMap

Kaggle-Preferences

• get set up, run the demo

FOAF-Archive

• Placeholders + a:manifest for FOAF-Archive
• FOAF video

#RELOCATE transmissions topology - multiple lists, series/parallel

support-it@blackview.it

Progress on Postcraft! I believe I've got s:Unfork working. I made a s:Fork to test it in isolation with a little test application. Fork/Unfork aren't very good names, something a like Multicast might be better. Leave that for the Great Refactoring, which I'm do some time after #Postcraft is up and running.

It's funny, while I was trying to figure that out, the thought of providing something like a GOTO service crossed my mind. There is a natural progression from pipeline to flowchart-shaped structures, to a little language (with Turtle syntax!). But I have to invoke YAGNI here. It will be interesting to see what other steps in that direction I have to take, but the goal right now is to make it easy to get things done. And get them done.

Oops...I forgot I need to do generate the final entry pages next, before Unforking.

#RELOCATE pc:ContentGroup might be better as a more general trm:Group

to add s:Unfork after the entry content generation phase, then

Yesterday I said : Ok, for TODOs, I'll have a top-level todo/index.md file, plus monthly files like todo/2024-05.md. Then have Plan blocks in this journal for daily bits.

What I've got dangling, I'm not sure how best to manage. It would be good to have a Where I'm At Status somewhere. And a Requirements. And a convention for flagging doc chacteristics in terms of changeability.

Note to #RELOCATE, re. #GTD : I need to be clearer in demarcating my planning activity and the actual work. I'm revising too much when I hit the code. I need clear plans written down before I start, no matter how long they take. Then code faster.

context.entryContentToPage = { sourceDir: sourceDir, targetDir: targetDir, templateFilename: templateFilename

Plan

Bergi 'Unified Landscape'

Phone Return!!!

Postcraft

• [*] s:Unfork - write a little test application

• [*] write a little test application t:transmission

• visualization : like http://localhost/farelo/src/TurtleEditor/

Fork is more like multicast - rename?

Kaggle-Preferences

• get set up, run the demo

FOAF-Archive

• Placeholders + a:manifest for FOAF-Archive
• FOAF video

Unfork

Ok, the Topology question. Postcraft is quite a good example on which to be thinking about this.

• Phase One : Markdown -> HTML at raw entry level, then raw entries -> final entry pages
• Phase Two : raw entries -> front page etc.

Phase One forks into multiple processing paths, one for each markdown file. To avoid uneccessary complications, it makes sense to make sure Phase One has completed before starting Phase Two. So,

I believe how I've got s:DirWalker means that order is maintained subsequently, even though each path runs independently (parallelism for efficiency isn't something I need to think about now).

• three semi-independent pipelines defined in transmission.ttl : markdown -> HTML rawEntries; rawEntries -> entries; rawEntries -> front page
• one 'continuous', with an Unfork or some such to bring the control flow down to one path
• one more blocky, with ContentGroups being set up from manifest.ttl in ConfigMap at the start

All three approaches could be supported, but for now I should just pick the one that seems most suitable for the current task. Considerations :

• keeping it simple, with sensible defaults
• keeping concerns separate :
  • transmission.ttl = topology
  • services.ttl = details of individual service configurations together they define the application
  • manifest.ttl = application instance configuration

I need some fresh air.