近期以来，日常想法的一些摘抄：
2022-05-23
- 最近接触了
flomo这个应用，用来记录灵感、想法的，在使用的过程中，又一次地了解到卡片盒笔记法，但我打算用obsidian来实践卡片盒笔记法的原则。
- 我认为：
- 大脑中的思想，是由一个个的零碎的想法所构成的。无论知识、书籍是多么的系统、多么的有条理，但是某一时间段内你的大脑本身却是一个接一个的想法。基于这个现实，所以我记录知识，也用一个个的小卡片，就理所应当了。它模拟了你的大脑的真实状态。而不是你所看到的整理好的那种有条理的、层级的、系统化的知识网络。真实地认识你的大脑，是构建知识体系的前提。
- 我打算：
- 用你自己的话来写，哪怕写得很烂。
- 每个记录足够简单、单一。
- 每个记录添加之后，需要花时间去连接（编辑卡片相关的标签、引用的别的卡片、数据来源以及卡片本身在笔记中的位置），连接的重要性甚至大于内容本身。连接的多了，你会发现，很多是重复的想法，重复的情绪。在连接的过程中，自然而然优化内容和结构。
- obsidian 的 zk 插件能够自动创建一个卡片，很方便，文件名就是
{{时间戳}}{{关键词}}，关键词只是为了方便我搜索，不强制要求。 - 默认的卡片都在
daily/目录下面，但是只是为了防止同一目录下卡片太多而变得不方便查看，所以才出现了分层目录来解决这个问题。不是为了分层而分层，而是为了把一组相同的卡片放到合适的位置而已。具体如何分层不设规则，自由组合即可。因为逻辑上，所有卡片都是同一层次的（具有唯一时间戳）。
- zk 原则适合记录什么？
- 输出类的不适合，比如长文章用于发布的。
- 其他的没有限制，你的想法，你的情绪，都可以记。对自己宽容一点，不要设定那么多条条框框，先记下来，后面总会优化为合适的结构。
- 可能会有两种内容类型：
- 一种是纯内容的，这种内容一定要简单、单一。
- 一种是纯索引的，这种就是各个卡片的合集，体现出一种结构，可能是文章的雏形。
2021-09-18
- 自从转向
obsidian以来，我好像再没折腾过关于知识笔记管理软件之类的事情了，因为 obsidian 完全满足了我个人的需求。我从一开始尝试使用就已经完全习惯 obsidian 的方式，没有一点不适，而其他的工具或多或少都有一些难以回避的问题。当然这全都是我个人的主观看法，切勿代入。 - 最后，相关想法可能以后还会继续更新下去，我觉得更好的工具肯定会不断出现的，到时候又是新的颠覆了。
2021-08-13
明显不卡，而且显而易见地不卡，同样是本地 markdown，logseq 就卡死，体验一点也不流畅，而 obsidian 一点也不卡。
本地文件，甚至更加简单，简洁，好像只是在本地文档的基础之上，加了点 [[ 语法，最小化影响原文件，同时，左边的文件目录给人安全感。文件就在这，很明显，结构也很清晰。不像 remnote 那样，你根本不知道数据在哪？是啥样？也不想 RoamEdit 那样，基于浏览器的 indexdb，搞得同步有各种问题。
与 foam 相比，foam 受限于 vscode 界面本身。而 obsidian 是自己做的客户端，直接可以插入 视频、音频和 iframe，简直不要太简单，简直不要太好用
默认就是基于本地的，也不需要账号，建一个文件夹，直接用 obsidian 打开就好了，所有项目相关配置数据都在文件夹的 .obsidian，你的文件完全没有更改。编辑和预览分开，我可以接受，因为已经见到太多所见即所得的软件，各种显示bug，不如直接让我编辑源文件得了，想看预览的时候分屏看不也挺方便。
真没想到，这个一直没尝试过的，下意识觉得功能不够的软件，竟然最能满足我的需求。我的需求很简单，就是在原有的 md 的基础上，加上一点双链的功能就好了。其他的功能真的无所谓。
obisdian 又将我带回了纯文本的世界，见识过那么多「魔法」软件之后，最终还是觉得纯文本是最好的。
感觉真不错，正好简洁够用，刚刚好，
- 比如由我来决定是否显示反向链接，
- 比如链接页面可以直接悬停显示内容
- 比如预览模式可以直接当成浏览器一样阅读，点击链接 + ctrl可以打开新页面。
- 比如甚至快捷键也很符合系统，默认 alt + ←/→ 键就是导航，与系统操作模式完全一致。
- 比如同步面板，可以实时编辑和预览。
- 比如移动引用的图片，会自动更新文档中引用，并且图片引用文本本身并不变化，仍然是基本的 md 语法。比如这个图片在imgs 目录下，但引用时，最终的结果仍然只是文件名，这太爽了。
- 功能UI设计真的好，简洁清晰
- 有文件的链接和无文件的链接区分颜色，这一点太赞了。真是每个功能都戳到我心里去了。
- 支持列编辑，而且操作简单易懂，不像别的工具，搞个复杂的快捷键。
- （2021年8月14日 16:51:16）插入图片时提示出来的列表在顺序显示在前面是刚加入库的图片，这个太舒服了。而且插入图片支持搜索名称，太方便了。
- 列选择的时候，如果有多行内容，会自动略过多行的内容，太赞了。各种细节。
- …
说下一些缺点，或者说值得加强一点的点
需要缩进折叠功能，不然文章很长的话就不方便编辑了。(卧艹，看了文档之后发现是支持折叠的，并且编辑模式和预览模式都支持，太好了。)这个也不是非要不可，可以通过引用子页面的方式编辑啊。现在已经是块时代了，而不是原来的文章时代了。
2021-08-12
- 关于 Logseq
- 使用 RoamEdit 总是因为它那个数据同步的问题而烦恼，折腾了很多次，一会能用，一会不能用，最后还是没弄好。而这个至少省心，所有的数据都是可读性比较好的 md 文件，这样，至少要比我自己 git + md 管理更有条理。
- 尽管可能会有性能问题，但是，我本身的文本量其实没有多少；其次， Logseq 所使用的数据格式都是很清晰明了的，并且代码也是开源的，所有的东西都在你面前，你能把控（如果想的话）。最后，我看有人说，可以只打开某个目录，从而提高性能，到那一天再说吧。
- 这个输入体验挺好的，至少比 RoamEdit 好。
- 。。。果然，东西一多，就开始卡了。无语了。没有一个工具是省心的。
- 再说说目前这几个工具的缺点吧
- Logseq：内容一多就开始卡了。是真的卡，无论哪步都很卡。
- RoamEdit：数据丢失很严重，数据库无法同步，也弄不清楚同步机制
- RemNote：不知道如何同步数据，而且特别耗CPU，最近又出现问题，把我最近记录的数据都丢了。一直耗这么高的CPU代码绝对有问题。
- Foam：基于 vscode，界面、功能都受限制。
2021-08-11
- RoamEdit：发现支持直接粘贴复制的图片，好感度 +1
- 我好像发现精简版客户端的一个问题：不支持代码高亮显示，不支持直接插入代码
- 刚刚困惑于 RE 中不能像 RemNote 一样搜索的问题，后来发现，这两者是不同的使用方式。RE 中适合直接
[[来提示引用。 - 我刚刚发现，RoamEdit 也是支持类似 RemNote
::语法的属性描述的，真是太好了。
2021-07-28
- 虽然不一定用 md + git 写 note，但至少得有一个 codebase 项目吧。这个项目可以和其他项目一样，都用 phpstorm 管理和书写。
- 不行，我的想法总是在蔓延，那干脆就两个都要吧，既做 wiki，又做 git + md，长时间做一下看看到底哪个好。
- 两个都是全量数据，主要是语法和目录组织形式不同。
- md 的主要问题是图床问题，能够跨设备查看图片，并且引用的是本地磁盘上的图片。目前的图片/音乐/视频已经决定全部放在
OneDrive里面了。然后在 vscode 中写的时候直接默认是基于OneDrive的根目录的文件相对地址。需要修改一下 vscode 默认的预览操作，在预览之前，自动在所有文件链接前面加上OneDrive地址前缀。 - 以上只是解决了图床的问题，还有链接引用的问题，合理组织文件目录词条的问题。能够快速找到想要的东西，让记录的内容真正为我所用，产生价值。
- git + md 的形式的最大优点就是适合纯文本，纯数据，适合本地编辑，一键打包。
- 现在又觉得全局的 wiki 目录下写词条是很不错的建议了，要不就狠狠心，自己开发一个解析工具吧，要想好看，就自动把 md 转成 html。
- 用纯文本的目的就是为了极致的纯文本，是一种极客精神的体现，是一种追求极致的体验。
- …
- 觉得真的是我想的太多了，记笔记这事纠结这么多真没有意义，就简单记一下就很好了。就按照主题分目录记录就好了，就够用了。真没必要去纠结那么多。
2021-07-22
- 我现在是这样理解知识和概念的，在人的大脑世界中，每个单独的概念都有一个位置，这个位置是一个不断分叉的树形位置，这是每个概念的位置，在大脑中，每个概念只有一个位置。如果有多个位置就是其冲突。这个位置是该概念的主属性决定的。包括我的这一段想法，应该处于 日记-2021/07/22-{占位}，这样的位置上面。
- 有的概念即使实际可以处于两个位置上，但在你的大脑中，只能有一个位置。这是由你的大脑决定的。知识是没有局限性的，但你的大脑内的知识有。概念其他的联系，全部通过关联、引用、属性等方式去处理，它的位置一旦确定，基本就不可能再变了。
- 每个概念都应该有一个名字，没有名字的，只能通过一段话来描述的，或者一个图表来说明的，都无法构成概念。就比如当前这段话，如果不给它命个名，那么它不是一个概念，它只能是 日记-2021/07/22-{占位}里的一条记录，不具备独立性，所以你没必要去记忆它。如果有一日会引用到这句话，必定会把它写在某个概念下面，作为描述。
- 现在已经有了 wiki 系统，wiki 的特性就是每个词条都是一个概念或名词，很好的帮我们解决了组织内容、搜索内容和关联内容的问题。
- 在 wiki 的基础上，我觉得可以用类似 roam 的工具，把所有的概念，通过树形的方式组织起来，把大脑中的知识结构具象化。因为这类工具可以折叠起来，所以要比传统的笔记软件、wiki页面或excel来写更好一些。这个构建的过程就是构建大脑的知识体系的外在表现。可能一开始只是一些简单同类物品名词的堆砌，逐渐的会深入到抽象名词辨析、思考和归类。
- 可以考虑用 remnote？
- 我们对很多的东西的认识都太肤浅，嗯，没有经过深入思考的东西，是这样的。所以往往被表面所展现出来的东西所影响。
- 就记录个概念，我想那么多干嘛，就用 vscode 的 md 格式来记录就够了。我甚至有个想法，是不是可以把所有的东西通过大纲的形式全部记录到一个一个文档里面去呢？然后通过坚果云同步文档即可。
2021-07-16
- 今天突然又想用回 mweb，在那一刻体验感觉确实挺好，但明显不灵活，还是割舍不了 vscode 啊。vscode 更加偏向于写代码、写项目式，而 mweb 更偏向于已经写好的文章，基本不会再改，可以预览，发布到博客。我觉得工作文档还是得用 vscode 来写，至于要发布的文章，可以用 mweb，写完发布就不管了，不要想太多，就是一个博客文章管理器，博客发布器。而其他的知识类的沉淀最终都是用 wiki。
2021-06-27
突然产生了灵感，还是要做一个在线笔记系统，通过编程的方式处理自己的笔记。
- 我产生的上面这样的想法，主要目的是为了让笔记记录的方式更加精准地控制，实现更加优雅地记录，更加优雅的利用，形成自己的知识体系。这其实是自己探索适合自己的构建知识网络的方式，想想也是一件很有意义的事情。
- 集记录和发布于一体。
- 因为是程序处理，所以支持随时一键全量导出备份。不用担心数据丢失的问题。
- 就编辑体验来说，肯定是无法超过 vscode 的，不可能达到 vscode 这么丝滑的，以及各种编辑扩展随手可得的体验的。
- 所以想了想，还是有必要做这样的事么？本质上都是控制信息，难道文件式的控制真的不可以么？
- 每个文件的路径是唯一的。
- 文件内容可见即可得，更加感性，简洁和快速，基于文本行的处理器真的不行么，像我个人的这种数据量，真的有必要使用数据库么？
- 文件，体现的是一种实用的态度，做事的态度，直指重点的态度。
- 从文本数据处理的角度来说，不存在段落，换行的区别，全部都是按照行来读取的。逐行读入文本数据，逐行进行处理，有的格式解析还需要构建一个特殊的数据结构才能处理。而二进制的数据是按位或字节来处理的。
2021-05-01
git + md 的形式的主要优点就在于 本地存储 + 多设备手动同步，缺点在于需要使用文件组织的方式，对于复杂的需求，需要确定文件目录层级命名用途的规则，而且一旦决定，基本上不可更改，还有一个就是预览不太方便，图片插入都不是很方便。
而 wiki，其实我一直使用它主要是因为 wiki 的理念，而不是这款web端笔记本身有多好。
一般来说，客户端的体验最好，可是我至今没有做出客户端过，而 web 端的笔记倒是做过，只是编辑体验太差了。至今仍然没有一个可以本地部署的，功能完善的全平台的笔记软件。现有的产品或多或少都会有一些问题。
等等，我只是记录一个笔记，为什么会联想到这些多无关的事情？笔记工具没有一个好用的，是真的难受。
我的最核心的需求应该是：本地部署的服务端（采用数据库存储 + API 提供），可以是 web 端或客户端，在基本的笔记记录和管理上，操作体验要好，基本功能要有。伪需求：协作。其实基于 web 的应该是最佳的选择，现在 electron 可以让 js 代码全平台通用。技术栈要求其实已经非常高了，①后端api设计 ②前端交互设计
对我来说，最大的难点是前端的功能实现，比如块。基本思想，前端的任何显示最终都是 html+css 呈现，js 是用来控制。
现在好多笔记应用真的就太原始了，还是 roam research 或 roamedit 这类比较好一些，更加符合人性。但是它们也都挺难用的，不灵活。目录这东西根本就不应该主动去关心。像白纸一样记录是最合适不过的了，记完之后能自动对内容进行格式化、形式化、然后自动处理标签、目录、索引、特征这些乱七八糟的任务。我们现在的笔记软件真的太原始了。也许就是因为我们人类头脑太简单，设计不了复杂的工具吧。
现在，我又开始倾向于 wiki 了。数据本地存储 + 预览其实很方便 + 基于 php + mysql 自己熟悉的技术栈 + 通过域名访问，唯一不好的地方可能就是编辑起来不太灵活。
- 对于任何概念，使用该概念作为页面标题，就很简单易行。知识与知识之间的联系直接就是页面的链接。
- 作为书籍之类的系列章节（没有主概念），可以通过子页来实现，子页依附于主概念而存在。
- ‘’’分类’’’作为标签的形式，分类页可以直接列出相关的概念
- ‘’’引用’’’和参考链接，表示知识的来源
- 以上四点完美构成一个知识体系工具。
- 其他的优点：
- 支持图文、网页 css
- 支持扩展，懂一点 php 代码就很容易实现自己想要的功能，目前已经有很多丰富的扩展了。
- 可以导出为xml格式作为备份存储。
- wiki 的缺点：
- 是的，它没有代码编辑器或其他各类软件那样，编辑即可得的编辑体验。
- 现在在编辑上还有一个疑问，什么时候该用自定义的命名空间呢？从我的使用体验上，使用命名空间
- 好处：
- 可以一眼看出知识的归属，而原本都是在主命名空间下的。
- 坏处：
- 需要思考这个知识属于哪个命名空间，原来的那种全局标题作为主概念的思想被弱化了
- 引用如果不刻意隐藏，显示的链接文本会附带命名空间名称，感觉很累赘
- 目前 wikipedia 的命名空间都是作为功能上的区分的，内容上的区分好像没有用命名空间。wikipedia 那么大的知识库都不用区分，那我一个人又有什么必要去区分呢。只有当记录的内容属于不同功能时，才应该区分。
- 我在使用 wiki 时，首先脑中会有一个如何使用的初步想法，就按照这个想法去实践，然后在实践中获得了更加深刻的认识，再调整完善之前的想法，使之更加符合实际情况。最后形成稳定的观念和实践的习惯，互相促进，就能一直做下去了。实践 + 总结调整 + 再实践 + 再总结调整！
- 好处：
2021-04-17
逛知乎看到的关于整理代码笔记的想法：
我在C盘的目录下有个文件夹叫CodeBase
我的主要语言是C, C++, Java，Kotlin, Python, C#
所以我又建了6个文件夹。
然后我会在每个文件夹下上传代码。
比如，关于Type的语法，我会写个ExampleCode 主要用于说明一个features该如何使用。
比如is关键字判断是否是某个Type.
as关键字判断是否为nulltype，是就返回右边的值。
从我入门编程的第一天起，师傅就教我一句话，Never trust your brain, just write it down to your CodeBase.
我觉得每一个Learner都要有自己的CodeBase, CodeBase不是存放开源库的地方，CodeBase是存放真正重要的代码的地方。
另外对于编程语言的features，比如C++而言，它的features实在太多了，你不可能把cppreference抄> 到你的CodeBase.
你最好copy一些你觉得好的features到你的CodeBase.
另外写CodeBase的时候，最好将源代码抽象为伪代码，伪代码才能表现逻辑，我之前说过
2021-04-15
- 我一打开 vscode，一打开之前写的 note 目录，一种属于程序员的熟悉感就充盈其中，一度又使我在 wiki 和 md 之间进行动摇。md 首先本来就是一种通用的格式，用于书写的文字，就是因为摒弃了大部分不实用的标记，最大化写作效率。vscode 天然支持代码。md 唯一的不合适就是链接和图片嵌入。但是想想，这些也都是可以解决的。图片可以通过 @语法导入，链接可以通过插件来自动识别。作为程序员，我喜欢原始码，作为普通用户，我喜欢美化的样式。md 比较原始，但也适合你去写插件去解析，最终产生自己想要的，而 wiki 已经自带了很多功能，直接用就可以了。在 md 里面，最基本的还是要用目录的形式去分类，这是最大的问题所在，如果不用目录区分，那么一个目录就下就会有大量的文件，这会让人感到很不习惯。分类代表固化，不灵活，而 wiki 是自由链接。
- md 更加简单，wiki 需要搭建环境，md 也可以一键生成博客文章进行发布，wiki 则不可以。md 其实也可以像 wiki 那样沉淀知识，不断积累，有 git 存在，任意的编辑都可以被保存。
- md 最大的缺点就是图片和相对链接的体验不太好，这是属于体验的问题，对于感性的我来说，多次因为这个原因而中途放弃。但如果专注于知识和代码，这些都不是问题了。
- md 更原始，容易批处理，导出转换为各种格式供外部程序使用。
- 如果已经决定使用 md，那么如何使用。已有的记录要不要迁移过来。每次迁移我真的受够了。到底什么是知识，我以前记录的哪些到底还有没有用，是否值得搬来搬去？一想到要迁移我就心累。
2021-04-10
- 用了onenote，格式有点蛋疼，还不如网页版的各种笔记没有的好。格式很容易就乱了。
- 现在看看我的wiki，也不是没有可取之处，至少每种显示效果和对应的代码是固定的，而onenote就很难控制。
- 我想了想，还是不要折腾这个来记录了罢。就用 wiki 吧，虽然它写起来繁琐，但是规范啊，稳定啊，数据本地啊，易于扩展啊。
- onenote只适合最简单的需求，而且不是从其他地方迁移过来的。
- 用来才发现，roamedit也不适合记录，果然还是wiki用的时间最长，最适合我。roamedit的用途以后再挖掘吧，反正已经买了终身会员，不差这两天。
- 我觉得onenote挺适合记录突然的灵感的，因为跨平台，因为启动很快，同步也很快。想到就打开，打开就记，记完就关闭，就是这么简单的应用。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 jaytp@qq.com