礼拜五, 四月二十四日

今天主要的开发挑战在于如何在我的Markdown渲染项目中"加载"和管理自定义模块.

设计

之前, 我用一个 JSON 文件去定义所用的自定义模块的名字和它们之间的依赖关系. 时间就像一头野驴. JSON文件的内容变得有些混乱和不可持续发展. 之前的命名设计也在实践中让我感到不那么理想.

我之前一直用"app"的名字去定义它们的文件的相对位置. 比如说, 自定义应用"foo_bar_hello_world"的".js"文件应该是位于"/src/foo/bar/hello/world.js". 经过一些实践, 我觉得这个设计确实有一些改进空间.

第一, 用应用的名字里的部分生成的文件夹的名字的含义不太好记. 时间一长我就不记得之前命名的直觉了. 然后我也希望能在名字中正常使用下划线. 最后, Git (最起码在VsCode的侧边栏中) 只会显示最后的文件名 (world.js), 不是特别方便于我定位和回忆这个 app 的内容和位置.

所以我决定还是用"temporal locality focused"的规则命名, 并且只用 app 名字中的前两个部分来定义相对路径. 比如说, 现在 "y2026_m04_foo_bar" 应该会存在于 "/src/y2026/m04/foo_bar.js". 我感觉这确实对于我来说更自然一些.

礼拜二, 四月二十一日

今天主要是学习了关于Transmission Control Protocol和Address Resolution Protocol的内容.

我很高兴看到前些日子孵化出的四只加拿大鹅幼雏成功渡过了这两天的降温.

礼拜日, 四月十九日

今天主要的思考的问题在于调整"mdtome"项目中在"runtime"自定义页面中"Hyper Text Markup Language"组成部分的设计. 之前, 为了不把各个部分分散在各个文件之中, 我选择了把"HTML"用一个字符串列表的形式储存在"JavaScript Object Notation"文件里. 我感觉确实有一些不太自然, 而且我也没有办法利用"Integrated Development Environment"的"format"或者检查功能.

我今天重新调整了设计, 还是把一些"HTML"的自定义片段存在了另外的文件里. 修改的过程还是比较令人欣慰的. 我很感激"Rust"里对于"Option"的"ok_or"和"Result"的"ok"设计. 它们给开发提供了不少的便利.

在重新设计的过程中我遇到的主要问题还是在于"URL Segment"的处理. 因为目前同一串"URL segments"可能会代表".html"或者"index.html", 旧的设计需要改动一下.

礼拜五, 四月十七日

今天主要思考的问题是关于"输出"目录的文件标记. 在我的"mdtome"项目里, 我用一个树状数据结构去记录, 在网站生产的阶段, 哪些在"输出"目录下的文件是有效的. 在我重新设计"网站封装"结构的过程中, 相较于之前的在"链接"节点网页将两层目录导航合并成一个, 我决定这次把这个节点网页分成两部分, 一部分在上一层"树"中以".html"的形式存在, 一部分在下一层"树"中以"index"的形式存在.

不过, 这个变化会破坏之前的"标记"逻辑. 之前, "标记"逻辑会连接"URL的片段"并在末尾加上"index.html". 但是现在, 我也需要标记那些"封装"节点的".html"文件. 这意味着我需要调整对于最后一个"URL片段"的处理逻辑.

添加追踪"URL片段"的深度或者检查某个"URL片段"是不是最后一个可能会需要我去调整我的另一个"prefix tree"的实现代码, 也需要我加上一些只会用一次的"if". 我最终决定还是加一个"前一个URL片段"的变量, 延后一下之前的"for循环"逻辑, 然后特殊处理最后一个片段. 这应该能解决这个问题.