依然思考笔记体系

思考和构建中,在这里做一些记录(思考的过程),期望监督(Flag 别倒)和建议。

一些要点

  • 先做起来,而不是等工具齐备
  • 没有绝对完美的工具
  • 没有长久可靠的工具,除非自己写
  • 如果选择平台,则应记住,没有永久可靠的插件
  • 数据应该在自己手上
  • 数据应该具有平台无关性

一些想法

  • markdown 是个不错的格式,并且能够满足我的需求
  • 对于思维导图有需求
  • 双向链接有用,但不是重点
  • 知识是网状结构,是相互联系的,依然认为 Wiki 的形式是最好的
  • 想存放代码片段,所以希望这方面友好

一些软件

Zettlr

  • :heart:好看
  • :heart:文件引用,格式管理强大
  • :blue_heart:似乎不支持思维导图?!
  • :blue_heart:虽然实时渲染,但是好像又不那么舒服
  • :heart:专业书写工具,所以这个工具应该能够长时间存在
  • :heart:基于文件夹和 markdown ,平台依赖度较低

Tiddlywiki

  • :heart:双向链接,块引用,Wiki 的优势
  • :blue_heart:挺容易炸的,炸了也挺麻烦的
  • :blue_heart:很多东西的支持靠插件实现,长久可靠性不好说

Joplin

  • 基本满足需求
  • :heart:可导出结构干净的 markdown 文件
  • :blue_heart:界面差点意思
  • :heart:有 API,倒是可以自己扩展(但懒
  • :heart:同步之类问题上都比较成熟
  • :heart:有附件管理
  • :blue_heart:但附件管理没有引用标识……

Hugo/Hexo

  • :blue_heart:添加笔记不是很方便
  • :blue_heart:笔记量大的话,搜索也是个问题
  • :blue_heart:大概率我得自己去写主题
  • :heart:好消息是可定制,而且我肯定有能力定制

Typora

  • :heart:好看
  • :heart:好用
  • :blue_heart:对笔记的组织能力较弱
  • :blue_heart:元数据的管理较弱
  • :blue_heart:没有标签功能(毕竟不是专业笔记软件
  • :blue_heart:不太方便搜索笔记

VS Code

  • 基本同上
  • :blue_heart:不知道怎么的,写代码我很喜欢他的界面,但是做笔记我觉得累
  • :heart:搜索蛮强的

目前

先用 Joplin,把内容往里面整理,添加元数据,大不了后期导出,反正格式比较整齐,大概写个脚本就能折腾进其他平台

分类

总体原则——先收集,再整理,所以首先两个大类别,或者说两个笔记本:

然后下层分类遵循:分类说明方向,标签描述细节 的原则。分类不宜过多,要区分明确,不产生可以属于这个也可以属于那个的情况。

  • Inbox
    • 网页摘抄:存放所有从浏览器摘抄过来的内容,有时间再向笔记中进行整理
    • 代码片段:复制的,新写的,暂时顾不上打标签和进一步描述的代码
    • 待办事项:这里用一篇列表笔记就可以;不过还有一些处于想法状态的东西,可以都放入这个分类
  • Notes
    • 技术: 所有技术相关的笔记,具体再用标签细分
    • 生活: 生活上面要记录的事情。不过目前看似乎没啥,但这个肯定是要跟技术分开的
    • 工作: 一些项目的进度追踪信息。不过现在一般会放在项目文档里,目前看这个分类也可能长草

分类这里还在思考,不一定是最终方案。一个不确定的问题是:要不要加入归档分类,作为一种对笔记部分深度整理后的结果。

单条笔记

一些同类型的东西可以放入同一篇笔记,比如 Linux 命令,而不是某一个功能的命令一片笔记。毕竟我用到的命令也不多,一篇大概可以容纳。

如果在这个基础上内容更多,则在一片笔记内用标题分类;再容纳不下才是分笔记。

(这时候就觉得分块管理笔记更让人舒适了

需要什么( 依然思考笔记体系 - #43,来自 dms

乱花渐欲迷人眼,先做一次需求回归,明确我需要什么

  • 数据管理: 一些文字数据,需要管理,基础需求只此而已,所以即便它们只是文件,只用系统工具,也是可以的。
  • 便于阅读: markdown 现在得到的支持还是比较普遍的,QuickLook 可以直接预览。
    • 脑图支持: 我一般是用 mermaid,这方面希望尽可能得到支持。
    • 代码片段: 这部分打算作为一个备份式存在,但如何及时更新还没考虑好。不过希望能有方便的折叠功能,和复制功能。专业的事情果然还是应该交给专业的工具,如果笔记中需要包含代码片段,就会引入很多麻烦,当然如果真的转向基于文件的管理方式倒是……
  • 日程支持: 这个需求并不强烈,一般来说用清单甚至用列表都可以满足,也会去尝试组织模式。现在并不介意操作上稍微复杂一点,但希望一个方法可以使用的长久一点。比如子弹笔记这种“方法”,是可以用上一辈子的。

然后,

  • 双向链接: 看起来很美好,但是必须有合适的阅读工具才会舒爽,即便语义明确,纯文本阅读时的多文档翻查体验也并不好,即存在平台依赖
  • 笔记引用: 主要是对笔记块/笔记片段的引用,这会很方便,比如把代码片段组织进一片笔记。但是纯文本可读性会更差
  • 元数据: 虽然重要的是笔记内容本身,但如 @pessoa 所说,笔记价值也未必具有长久性,日后可能会当日记看待(回忆价值),而作为回忆时,能看一眼何时创建也是很幸福的。
  • 标签: 作为一种分类上的补充,我觉得用标签是很合理的。然后也是搜索优化,贴上一段代码,必须辅助相应的描述,这才是可被检索的,标签是对常用搜索关键词的一种强制补充,当然,标签的可被检索,可被管理是比较有必要的,不然可能会在不同笔记中添加两个意思相同,而写法不同的标签。

暂时的决定 ( 依然思考笔记体系 - #50,来自 dms

差不多决定了,用 Obisidian (还不会拼写……

  • :heart::heart:基于文件这是最让人感到踏实的。
  • :heart::heart:可以在文件的基础上套其他工具,比如 git ,数据安全大幅度提升
    • Git 这种工具就不用担心它的长久性,这玩意儿要是没了支持,会有一万个程序员冲出来继续支持的
  • :heart::heart:数据管理方面获得更高的统一
    • 代码片段可以以文件的形式塞进去,同时也可以引入其他管理方式
    • 日程如果愿意也可以在里面尝试组织模式
  • :blue_heart:元数据是个问题,但不是大问题,也许用插件,也许写个脚本
  • :blue_heart:摘抄不方便,但事实上我摘抄的需求是非常非常低的
  • :blue_heart:手机端……其实需求不高,也属于 Inbox 需求

感谢

感谢所有参与讨论的人,尤其感谢 @DavidJoy @pessoa 的工具推荐

非常喜欢这个帖子的讨论气氛,始于需求,归于需求,我很开心。

附录

  • 发现一个 Joplin 的工具( Joplin Utils ),可以用来删除无引用的附件,不过受到今天数据丢失的影响,还得再测试一下才能讲效果如何。
  • Obsidian 添加创建和更新数据用 Update time on edit plugin 这个插件就好了,时间格式可以自定义,字段可以自定义
  • 对手帐的简单的讨论: 依然思考笔记体系 - #56,来自 dms
2 Likes

我用typora(0.9.77)+微云同步盘

笔记软件

之前使用的是onedrive+OneNote
因为我最开始写笔记其实是没什么思路的,很多都是临时记一下,然后抽时间统一整理笔记。
OneNote这个软件很符合我的要求,。但是onedrive同步实在是不行,手机App同步非常慢,有时候还得上梯子(我也不知道为什么)。

我现在使用的是为知笔记+docker私有化部署,临时的一些笔记会记录在苹果的备忘录中。
主要是我自己组了Nas,希望笔记能存在自己能看到的地方。同时全套设备转到了苹果全家桶。

关于笔记的一些想法

  • 把碎片化的知识和统一化的知识分开
  • 定时整理自己碎片化的笔记
  • 前期决定好使用的软件/平台,换平台成本太高
  • 功能丰富的笔记软件不一定适合你,根据需求选择合适的软件

用了各种笔记都不满意,最多还想自己写。

以后准备一条一条写的方式记下知识的片段,自动到数据库,这样可以api调用

也可以算是备选,其实日常写 markdown 我都是用它。基于目录进行管理的话,已经可以对比各种笔记软件了。

列一下我觉得作为笔记软件它的不足:

  • :blue_heart:搜索还是个问题
  • :blue_heart:元数据管理比较弱,比如标签,创建/修改日期啥的
  • :blue_heart:笔记间链接(引用)不方便

太慢了,我这种习惯性 Ctrl+S 的会觉得十分难受,而且特定情况(某些字符的文件名不支持)下它还出错……

然后针对你列的这些想法说说我的观点:

  • 碎片化和统一化的知识,可以分两个笔记本,或者两个分类(后面打算思考分类规划中),碎片化属于 Inbox(收集器)
  • 定时整理,这一点非常认同 × 666
  • 我会优先关注数据的可迁移性,有些平台体验不差,但数据不是自己的,就 pass。markdown 的可迁移性还是很高的,甚至在一定程度上通用
  • 现在对大而全无感,甚至有些回避;更偏爱精准解决需求的小工具(但不是屁点需求就单独一个工具)

我弄了个 node.js 的服务器,用来他提交自己瞬时的想法,然后标注时间写入 txt,一个月一个文本,高兴了再整理,就觉得很舒适

Jupyter Lab

  • 不依赖图床,图片存储以 Base64 字符串存放到 ipynb 后缀 的 json 文件中。
  • 安装 draw.io 插件,图表同样以字符串存放到 ipynb 文本文件中。在一定程度上可代替思维导图。
  • 好看,通过浏览器访问(全平台),看起来像是在浏览器中的一个 IDE,多标签页,上下左右任意分割。性能要求不是很高,可运行在树莓派中,电脑远程访问。
  • 安装 nbviewr 后,就可以用浏览器访问渲染后的笔记本(不能编辑),有文件夹层级,这个只用来展示。
  • vim, emacs 快捷输入。默认的 vim 不是很好用,安装 vim 扩展插件后,功能十分强大。
  • 左侧显示笔记内容的大纲。
  • 基于文件夹,支持 markdown 导出 md, rst, pdf, html, tex。
  • 开源,插件多。
  • Github 上点开就能看渲染后的文档。https://nbviewer.org/ 可以渲染 github 上的 jupyter 笔记,google 提供的 jupyter colab.research.google.com,还有其他在线 jupyter notebook
  • 笔记内容分块,修改方便,渲染也方便。
  • 执行 python 代码,保留代码输出到笔记中,导出 html, pdf 后效果也还可以。
  • 可以新建终端,对于控制 Linux 很方便。
  • PPT 功能,没用过,不评价。

笔记文件整理我用 4 位 16 进制数做为笔记本的前缀,不乱。除 windows 的资源管理器外的其他资源管理器几乎都是 16 进制排序。

笔记的备份用其他软件,我用微力同步。

1 Like

都有点心动了。

  • :blue_heart:“图片存储以 Base64 字符串存放”这个方法遇到大图还是很尴尬的,我更倾向于对图片文件的引用
  • :blue_heart:“开源,插件多”我个人并不认为是优势,这种服务还得考虑长期支持度,很多个人开发的插件可能后期就没有更新维护了。
  • :heart:“笔记内容分块”,这个超喜欢!

typora + 坚果云 + picgo

图片不想分离出去,因为我笔记中图片比较少,而且如果用,那就肯定是比较重要的图片了。

Typora 肯定是备选方案,只是前面说的一些缺点……

好消息是用 Joplin 也可以用 Typora 做外部编辑器

这就很赞赞!我整理分类的时候做了大量移动操作(把旧笔记移入 Inbox),然后 Joplin 在同步时提示安全问题,然后在我没有进一步确认的情况下……笔记全没了,本地和同步目标上都没了……

虽然,不重要,反正我进行了多地备份,今天为了测试,还导出了一份。


数据恢复了,但是还是有点害怕,因为备份的两个网盘其中一个居然一直没有备份上去数据(

这个确实让人心动,不知道支持双链吗,感觉记录的东西比较杂乱,有双链还是很方便的。

picgo有一个很纠结的问题,想来笔记的图片都很重要,那么,是不是还得开通cos之类的比较稳妥?

双链的实现有个取巧的方式,前提是所有的笔记文件名整理有序,且不变动。
由于笔记是在 Web 端,所以用 a 标签就能实现,用相对路径,还能用 # 定位到某标题。
理论上 a 标签还能用来管理附件,点击就能下载,这么做最大的问题是附件管理,又是属于文件管理方面的事,我也没有好的方式去整理得很整齐。

全文搜索,用最高端的方式,新建一个终端,然后用“grep”命令。 :smiley:

一般来说笔记中的图片不会很多吧,和笔记放在一起,扔网盘就好了。我用了一个 NAS(伪,其实是一个上网本)来做文件管理,本地笔记同步到 NAS(Webdav),然后 NAS 再将这些内容备份到两个网盘。手机也通过 webdav 和 NAS 上面进行同步。这样我的笔记应该存在于五个地方,所以今天的数据丢失一点都不慌。(还在想着进一步增强

我用 GoodSync 进行文件同步,目前感觉良好。

如果图片文件真的多到网盘放不下,该考虑一下这是否属于一般的笔记范畴了,或者参考设计师资源库的管理方法?!我自己的经验,这么多图片,即便在本地都难以快速检索,更别说数据同步了。真就本地搭建 NAS 是最实际的。

我明白了,你的这种方式就相当于脱离picgo之类的,直接图片本地存储,然后通过webdav整个本地笔记文件全部备份或者同步,那么另外的设备,当然也就是本地调用图片了,对吧。不过这样的话,也如同我上面说的,通过picgo来传图片,总感觉怪怪的。

是的。不奇怪,因为在 Joplin 里面这些文件(图片)作为附件纳入了管理


再换一个角度,比如用 Typora,那么要同步的笔记就是一些 md 文件,图片同样是文件,同样是笔记的一部分,只是格式不同,所以放在一起同步也是合理的。

既然是笔记应用,为啥没有 RR、Obsidian 或 logseq 的姓名 :joy:

关于 Joplin 的备份:得益于 Joplin 的插件系统,已经有自动定期本地备份插件了,如 JackGruber/joplin-plugin-backup。如果担心数据在同步过程中丢失,可以用这类插件作为补充。

关于 Joplin 的同步:如果不太放心,可以「帮助」 - 「打开/关闭开发者工具」,然后用 Ctrl+S 或者点击主界面「同步按钮」手动触发同步,再观察以 Synchronizer 开头的同步信息。不过我自己使用的时候,如果长时间不重启一下 Joplin,有一定概率会导致同步卡死,应该还是有些问题。

对他们不了解,而且感觉自己也没有去了解的欲望……(大概真的老了

一方面,前面提到了插件持久化的问题(就当杞人忧天吧,也许插件还没咕,我的笔记就咕了,但是强迫症啊)。

另一方面,我打算写一个保存历史笔记备份的功能啥的,反正简单粗暴的话,好像不费事。(还在想象中,不着急