Journal : 2024-05-14

This morning, post office then shopping with Mari. I did the minimum that seemed necessary on Bergi's 'Unified Landscape' post, but when I pinged him he'd told me he'd already posted it. Not to worry, I'm very encouraged that he's been looking at similar things to me.

Progress on #Postcraft! Last night I got the pipeline as far as rendering the individual entry HTML. I did get rather quick & dirty with it, but that's fine for now. I've already got a huge todo list, mostly refactorings that will be straightforward. Now I just want to keep the momentum up, get the whole thing working end-to-end, make it nice later.

TODO The how-to guide needs tips, s:ShowMessage etc

    trm:pipe (:s1 :s2 :s2 :s4 :s5 :s6 :s7 :log1 :s8 :s9 :s10 :s11 :s12 :s13 :s14 :s15 :s16) .
...
:s7 a :PostcraftPrep .

:log1 a :ShowMessage .

:s8 a :MarkdownToHTML .

Oops!

s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.s2.

Check that pipe.

TODO it'd be nice to give the context etc objects names, but it's something around Prototype,

   context.constructor.name = 'Context'
   ->
   TypeError: Cannot assign to read only property 'name' of function 'function Object() { [native code] }'

not obvious, https://stackoverflow.com/questions/17169335/how-do-i-specify-constructor-name-on-a-custom-object

That was a little annoying. I tried s:Unfork where it needed to go (after s:DirWalker etc) and it didn't work. After a lot of circular fiddling, it now works. I have no idea why it didn't before.

Ok, that Front Page.

How much to do in the pipeline, how much to hardcode in the template? (nunjucks is ok with that)

I could use another s:DirWalker to get the list of raw entry filenames, pass that to s:Template to render the front page. I might need to add a s:Sort service to get the entries in the right order (GitHub #Copilot suggested that, it's a good one).

Or... carry over what I've already got/can get from the earlier s:DirWalker. That's probably the way to go.

Oops. It goes into an infinite loop when I add a subdir to the source dir. s:DirWalker needs a test, fix recursion. Leave that for now. What there is in the context after s:Unfork is:

  "filepaths": [
    "2024-05-03_one.md",
    "2024-05-03_two.md"
  ],

Hmm. It's a bit clunky, I'll have to remap those to the raw content HTML files. But it's not terrible, it can take the info from a single source, the bits of context derived from manifest.ttl.

Plan

Postcraft

Remember I need to take down the old server

This was TODO but now #RELOCATE : paths for entry pages/fix errors in PostCraftPrep - can refactor to simplify? check s:ConfigMap

  • add s:Unfork, template & save the front page
  • (part of above) make a start on figuring out filter/order of posts
  • make individual entry pages presentable
  • make the front page presentable

probably not today

  • upload to server

  • make everything work

  • Hello World (again) post

  • Transmissions/Postcraft overview post

  • pinned posts

  • Atom feed

FOAF-Archive

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

Kaggle-Preferences

  • get set up, run the demo

#RELOCATE transmissions topology - multiple lists, series/parallel

support-it@blackview.it

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

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.

Journal : 2024-05-14