接触ob以来的一些心得体会

2021-11-10

截止到今天,深度接触obsidian应该有三四天了,这几天中,我一直都在了解学习其中的门道以及用法,到今天算是稍微有点小心得,同时也隐隐预感到,ob将是我未来使用的笔记工具了,至于用了两年的Typora,恐怕要退居二线,作为一个打开markdown预览的一个工具了。

现在稍微有了一点点心得,特此记录一波:

  • ob的所有配置,主题以及插件,全部都在工作目录中的.obsidian目录下,因此不同电脑之间想要备份配置之类的,其实只需要将整个工作目录同步即可,所有的配置也都将是共享的。
  • 如果你是从typora迁移过来,而且原来已经积累了相当体量的笔记了,那么初接触ob的时候,我不建议你直接使用ob打开你原来的笔记根目录,因为这两者还是有一定的小差别的,更建议的做法是先创建一个ob的根目录,然后以此为库,先体验一阵儿ob的编辑以及特性,等到真的体验成熟了,下定决心了,再慢慢将原来typora中的笔记迁移到ob不迟。
  • 主题我使用typora中已经用惯了的Vue主题:Obsidian-Typora-Vue-Theme
  • 目前我的笔记目录结构如下:
    • Obsidian:笔记根目录,所有内容在此之下。
      • dayday:每天的笔记,全部存放于此,可在插件插件中自定义。
      • obsidian:目前在学习ob,所以创建这个目录存放学习笔记。
      • zob-config:一些配置类的,放在此目录下。
        • template:模板内容,统一放在此目录下。
      • zob-source:一些附件,源文件放这里。
        • images:图片统一放到这里。
          已经通过坚果云监听了此目录,从而得以将内容和配置在办公电脑和家里的电脑之间同步起来。
  • 关于图片目前还没有比较好的方案。目前来看,以前typora中使用的绝对路径目前在ob应该是无法兼容了。就算通过file://能够兼容,但是通过脚本一次性解决之后,以后新增的图片也不能是这种格式,因此后边可能会放弃绝对路径的方案。
    • 目前看配置了绝对路径还可以,ob编辑过的文件,直接用typora打开图片也不会有问题,注意需要ob中配置里指定内部链接类型为插入基于当前笔记的相对路径。否则其他的两种类型在typora中打开都会让图片无法渲染,这种配置方案没有毛病,但有一个问题,那就是文件的位置不能再进行移动,移动之后相对路径的关系发生变化,从而无法渲染图片。写到这里,再一次感觉到,自己的思想尽管已经慢慢朝双链这种笔记方法转变,但是骨子里,还是那种以目录树管理笔记的思想,现在还不知道两者到底哪种更适合自己。我对去除目录层级唯一的担忧就是:一个目录下有几百个文件的时候,会不会更加难于管理,更加难于找到自己想要找的内容。

另外附上自己之前使用typora时的一些最佳实践笔记:
Typora–可能是最好用的本地Markdown工具
使用Typora+坚果云(github)打造免费的个人云笔记

2021-11-11

  • ob最大的优势在于它的自由,以及插件体系的丰富与强大,但自古以来的阴阳道理告诉我们,优势很多时候,也会是劣势。因此使用ob的首要金句就是:一定要克制地用ob,尤其是插件体系。所以我在想,像typora这样的简单纯粹,丝滑够用的,也是一种不错的思想,至少能一直专注于文字,而非折腾,说到底,一款笔记软件的核心目的还是写作,所以像ob这种插件体系非常灵活的,要务必告诫自己,克制折腾,专注创作。
  • 当然在初期体验使用过程中,还是鼓励多折腾,只有折腾之后,才能找到真正属于自己的美好定制。正所谓,历尽千帆,跨越山海,返璞归真,认真写作。

未完待续。。。

欢迎大家一起交流。。。

4 个赞

所见即所得已经开始内测了,距离完全放弃 Typora 指日可待(狗头

1 个赞

我也期待着ob的所见即所得更加成熟,就能彻底脱离typora了

1 个赞

[[2021-11-16]]

  • 克制大多数应该是建立在折腾之后,而非一开始的坚持保守。正如处在青少年的处子,你告诉他千万不能纵放自己的欲望一样,是绝对没有任何威慑力的,必须得他自己经过一些体验,获得一些自己的体悟之后,方能体会到,克制的魅力。

  • 是的,我还一直处在折腾插件过程中,还有很多优秀的插件等待我去发掘,如果在初体验时我不把这些优秀的插件发掘,那么在以后笔记全部迁移之后的日子里,则更不太可能有这样的精力折腾了。

  • 我以为插件是容易折腾的,但双链是需要一定方法论的。而对双链我一直没有太刻意地去学习,只片片段段的在别人视频中看到别人的应用方法,到今天,似乎模模糊糊中有了一些体会。先说之前使用Typora的写作思路,在ob这里则是完全行不通了的,以往的笔记利用目录层级作为分类依据对内容进行分门别类,下边的各个知识点,单文件,我则都是通过123这样明确的数字标识来进行排序,一旦全局的笔记都通过这样的命名安排之后,那么文档自动检索链接的能力也就丧失了,这是第一点体会到的(今天在群里又了解到了aliases的功能,通过给笔记添加别名,应该能完美解决如上我的顾虑,应该可以通过创建文件模板,新建文件时自动添加metadata)。

  • 另一方面,关于双链的使用,应该有两种思路,一种是正向的,一种是反向的,这也正对应着侧边栏功能区的入链和出链。以前使用typora时,在学习一个新的知识点编写笔记时,可能会根据该知识点的情况分出来几个文件夹,如下:

    • 1,资料汇总
    • 2,架构概念
    • 3,安装部署
    • 4,问题记录

    这种纯目录式写作思路,给日后笔记的二次学习利用,带来了不小的考验,大多数时候,我也正是需要查找某个知识点的时候,依靠着记忆一层一层找下去,才找到自己想要的信息,而现在随着笔记越来越多之后,这种单靠大脑记忆来检索的方式越来越难,从而使得记录的诸多笔记变成了多年都不会再看第二次的无用信息了。
    现在,在ob当中,应该多多利用好双链标签这两个特性来解决这一困境。这里单独写一下双链的一些个人体会,我想,应该有两种思路来完成一个知识点的记录:

    • 第一种,记录一个知识点,可以先新建一个大目录,然后在大目录里建立一个类似索引的文件,接下来所有的内容都在这个文件里记录,一定注意严格利用二级目录对各知识点进行归类约束,每个大类知识点都用二级目录分割,当我们写完这篇笔记之后,可以利用note-refactor-obsidian重构插件,一键将该笔记基于二级目录裁切(注意裁切之前调整文件存放目录,当然,裁切之后将裁切的文件移动到索引文件同目录也可以,索引中的外链引用地址会自动更新),如此,便完成了一篇笔记基于单个索引链接多个知识点模块儿的效果。如此单个单个知识点再往上层大分类汇聚,就形成了万千溪水汇聚到河流,万千河流汇聚成江海的效果了。
    • 第二种,按照以往写作的思路正常分文件编写知识点,编写之后,我们可以在每个知识点的侧边栏里边,看到系统自动识别到的潜在链接,这个功能太好了,如果这个潜在链接就是你想要链接的内容,那么可以直接点击链接该文件,从而实现知识点与笔记双链的目的,这种时候还可以借助于**obsidian-folder-note-plugin**插件给目录创建一个黄页信息。

2021-11-27

  • 今天重看b站即凉关于ob的视频,有了一些新的小体会,看到作者基本上都是利用索引页面将所有的细碎知识进行索引管理,这样的方式能够简化笔记的目录层级,强化笔记与类别的关联。
    • 所以我原来笔记的目录层级,应该费除掉,进而通过链接层级进行管理,但是每一层都要手动维护链接,仿佛有点累,这块儿应该能找到更加自动化的做法。

      比如我的目录层级如下

      运维观止
        web
          nginx
      	php
        日志
          filebeat
      	logstash
      
    • 在typora中的做法是每一层都创建为目录,然后在最后一层小知识点下边创建文件编写各类知识点。

    • 现在的做法应该是弱化掉web这层目录,甚至nginx这层目录,全部通过链接的方式替代,比如目录层级变成如下样子:

      索引页面
        运维观止 
        web 
        nginx 
        php
      运维观止
        ...
      
    • 所有的实体笔记内容在下边运维观止目录下散乱堆放,然后都通过索引页面进行逐级维护管理,nginx为最底层的分类,链接具体的知识点分类,web再链接NGINX和PHP的分类,同理运维观止再链接web和日志两个分类,这样就实现了通过索引页面,将原有的目录层级替换掉的效果。

3 个赞

用ob就是为了让笔记不再像印象笔记那样受限于文件夹,比如我今天和女友看了一部电影,写下一篇心得。这篇笔记我可以链接到「我的日记」,链接到「我和女友的交往史」, 链接到「我看过的电影」,链接到电影中「我喜欢的某个角色」,链接到「电影的导演、演员」,这些括号中的项目将来都可以用dataview以数据库的方式显示。换句话说,我只写了一篇笔记,但我同时完成了多个数据库中的一部分。文件夹则可以拿来自动适配笔记模板或样式,这些是插件能协助你做到的。

是这样的,的确应该弱化目录层级,然后再花一些时间把笔记的关系维护起来,这是ob比起以往使用的笔记的最大不同。

索引好,欢迎加入索引流大军

读了你在论文发的文章,感觉你进展超级超级快,一个多月肉眼可见的进化。现在都不敢评论,不知道昨天的你,当下的我,是否已经被今天的你甩的很远了。

看你的经历和感觉感触良多,很多内容不谋而和。

关于方法,殊途同归就不说了。关于链接的维护,我写过一个小脚本,可以把库内所有的相对路径修复正确,需要的话可以取用。功能是把目标文件名正确,但路径错误的链接修改成正确的相对路径链接。

我主要用索引,一个总的索引把所有笔记关联起来。

我的目录是扁平化的,每个小类都是一个目录,目录全部放在一个二级文件夹里。


我的所有笔记都在二级目录下,例如2 兴趣爱好/-t3-autohotkey相关索引/t3 1c 2 211223_044133 数组值与字符串比较.md

得到如此评价,实在受宠若惊。
感慨ob优秀,英雄所见略同。
脚本暂时不用了,我这边目前笔记逐个迁移,已经按照索引的思路在迁移了。

目录扁平化的问题我迁移过程中已经这么做了,只不过并没有将所有文章所有到一起,我的笔记大概会有两千篇,如果全部索引在一起,不知道会不会难于管理。
您可以多分享下你这个总的索引的实际体验使用效果如何。

我有一个总MOC,里面有各子MOC的链接。总
MOC手动维护。

按类别,给笔记分了大类,每个大类分了编码,子类也分了细分编码,我猜和你以前用过的编码逻辑是相似的。

子MOC,大部分内容是自动生成的。

现在管理起来很方便,很舒服。

1 个赞

弄得很好,可以看出也是精心设计了

森大现在笔记量多少?多学科放同一个库吗
晒一个关系图谱看看 :blush:

以前的笔记不整理 ,分散于为知、OneNote中,未来全放ob一个库里了。(日记类,网页剪藏各自放独立库中)
目前1000多,未来会以每天10左右的速度增加。

这个是跨了几个学科?ob当记事库还是数据库用?

字母和数字我都会编码的,一级大类两个字符,从a1开始,是知识类。纯数字,暂时都是笔记类。

数字加字母36个,最简一级大类36乘36,只用了极少一部分。我只会让大家看到看到极少的一部分,例如数字1和字母t开头的。数字1开头代表笔记本,记事用的。数字t开头是信息技术相关。


这就是森大常挂嘴边的中图分类法编的码?
多学科同库,确实需要科学分类

我现在ob只有二三十来条笔记,已经觉得凌乱,好多八竿子打不着的东西,等之后正式开用ob,得重新建库,只放医学和易学的,不胡乱塞东西,哪怕是弱干扰都排除掉,想做一个wiki型的个人数据库,以后检索用
MOC也想了想,怎么用合适,可能跟你们的稍有不同,等从pdf搬运一部分笔记去,再做个工作流display来解说下吧,不过别太指望重度拖延症,一时半会儿做不出来