登录 注册

【共同探讨】移动块 / 反链 / 快速无压记录 / 标签

本贴最后更新于 1182 天前，其中的信息可能已经天翻地覆

1、【bug】把一个被引用的块拖动到另一个文件里，虽然引用关系还在，但是反链里手动刷新看不到结果，需要重启

2、用剪切粘贴的方式来跨文件移动块是最方便的，但是引用关系会丢失，分屏拖动的方式有点不方便，而且这种拖动对多个块的情形不太友好，需要一个个拖动

3、「把内容从反链区移到正文」是 Conor 式的双链笔记流程中非常重要的一步，虽然思源可以靠浮窗编辑反链的内容，但是因为 2 的原因让这一步不是很方便

roam research 作者 Conor 预设的双链使用流程大概是这样，这是 daily notes 中的记录：

image.png

在 logseq/资料 这个页面中，可以直接从反链里把这一坨内容全部拖到正文里慢慢组织：

image.png

思源的列表块在侧栏反链里只展示段落块，配合不了这个工作流。靠 SQL 呈现的反链对于列表块也会有类型重复。所以标题块比列表块适合这个场景，但是如果想把反链的标题块移到正文里，会遇到两个问题，首先是 2 里提到的批量剪切会导致引用关系丢失，其次是对标题块做的一些单独处理在浮窗里好像失效了，在我这里不能把浮窗里的标题块转换成文档，可能是 bug。

因为上面这些原因，思源不能完全复刻大纲双链笔记那种流畅无压的 daily notes 记录流程，如果要改进，也要配合软件架构，所以我也不好说具体可以怎么改进

4、因为反链的可操作性跟大纲型的软件存在较大差距，想要快速无压记录的话就会想到在 daily notes 里用井号标签。

改进标签的用户声音一直都有，现在也有了 #2431 文档块支持标签的计划，但是我感觉光把标签看做标签是没法彻底改进标签的。标签的问题和反链的问题其实是同一个问题，即加了标签的内容的展示形式不好，而且标签面板和反链面板一样缺乏可操作性。前面举的反链不方便的例子全都可以直接照搬到标签上，比如加了标签的列表块在标签面板里完全无法展示下级，加了标签的标题块在标签面板里用浮窗移动块有问题。

这些问题会让将来的标签变成一个只能用来标记文档块的东西，就像印象笔记那样，这其实也没什么毛病，但是如果反链和标签的呈现形式和可操作性得不到优化，想在思源内部做到快速无压记录就需要使用者本人有足够的方法论支撑，这样一来普通用户的体验很难比得上能直接使用 daily notes 无压力畅快输入的大纲双链笔记。Conor 式的 daily notes 流程虽然未必适合所有人、也遭受过一些舆论上的妖魔化，但是它实际用起来确实是很舒服很上瘾的，而且这种工作流目前来看其实是最适合小白专注记录的。

根据思源目前的形态，主要的使用方式可能是这两种：小白用户只用到文件树 + 编辑器，高阶用户自己设计一套工作流，这两种方式其实都有很高的心智门槛，文件树带来的心智压力并不小，也就是说即使是小白用法一样不够轻松。无压记录的工作流真的需要功能上的支撑，围绕 daily notes 流程的功能（反链和标签的呈现方式和可操作性）如果不加以优化，可能小白用户的使用体验还追不上 bear，想追上大纲双链笔记就更难了。

当然快速无压记录也只是笔记应用的一个方面，别的方面还是可以差异化竞争的。但就算不考虑 daily notes 流程，这些功能其实也该优化一下，daily notes 流程只是提供一个思考的切入点。

没什么具体建议，仅探讨。

  • 思源笔记

    思源笔记是一款隐私优先的个人知识管理系统，支持完全离线使用，同时也支持端到端加密同步。

    融合块、大纲和双向链接，重构你的思维。

    22341 引用 • 89398 回帖 • 1 关注
9 引用
第二次漫游：双链、xanadu 与渐进学习 • dammy
我的 dailynote 流程（适合思源笔记软件 / 欢迎讨论） • Rayalizing
【Achuan-2】我的 dailynote 流程 • Achuan-2
【Achuan-2】我的 dailynote 流程（旧） 【笔记方法分享】conor 的写作工作流 | 块引用的作用 「日记」功能的改进建议 【笔记方法分享】conor 的写作工作流 | 块引用的作用 实践中对双链和写作的一些思考 实践中对双链和写作的一些思考
3 操作
deerain 在 2021-08-28 00:15:45 更新了该帖
deerain 在 2021-08-11 17:30:23 更新了该帖
deerain 在 2021-08-11 17:21:30 更新了该帖
3 感谢
4 关注
13 收藏
4 赞同
9 引用
3 操作
49 回帖
14
12
7
5
4
4
2
8.1k 1.7k 869 1.6k 188 63 3.6k

相关帖子

优质回帖
  • deerain • • 5
    订阅者 支持者 勇士 作者

    好问题。尽管不易察觉，但这两种方式有极其巨大的区别。

    假设今天我逛了一下 logseq 论坛，看到有人说新版本通过修改 :ui/show-empty-bullets? 变量可以显示或隐藏内容为空的 bullets，于是我想把这个配置方法在笔记软件里记录下来。

    然后我打开 logseq 做记录，步骤如下：

    1. 打开或转到 logseq 这个软件，如果当前页面不是 daily notes 就再按一下快捷键跳转到 daily notes 页面

    2. 在 daily notes 的第一行写下：

      - [[logseq/配置]]
  - `:ui/show-empty-bullets?` 变量：显示或隐藏内容为空的 bullets

    3. 记录结束。去做别的事。

    如果使用 typora，步骤如下：

    1. 为了最快捷地打开 logseq - 配置.md 这个文件，当然是要好好利用各种搜索型效率软件了，于是我在 utools 里搜索 logseq 配置，结果发现我并没有这个文件

      • 这个时候第 1 个差别就已经体现出来了，在 logseq 里，我永远不用回忆 logseq/配置 这个页面是不是已经存在，直接在 daily notes 的第一行开写就行了

    2. 搜索未果，我开始考虑换个关键词搜索，万一我以前创建的文件名叫 logseq - config.md 呢？换了几个关键词搜索，发现我以前真的没做过这方面的记录

      • 第 2 个差别出现了，在 logseq 里，我不需要考虑自己之前是不是已经用别的名字创建过 logseq/config ，这种文件，我只需要直接在第一行写下 - [[logseq/配置]] 就行了，别的什么都不用考虑

      • 第 3 个差别：就算我以前已经有了 logseq/config 这个 page，那也不需要管它，因为 logseq/配置 和 logseq/config 这两个页面一定会在 logseq 这个父页面下共同展示，我可以在将来合并它们

    3. 既然以前没有对应的 md 文件，那我就创建它吧。创建一个新的 md 文件虽然人人都会，但是我在创建的时候就需要给它在文件系统上安排一个具体的位置，我是把它放在 软件使用 文件夹下还是放在 知识管理 文件夹下？

      • 第 4 个差别：在 logseq 里没有烦人的新建文件流程，就算我根本不对 md 文件分类，新建文件这个步骤还是烦人

    4. 终于新建好了 logseq - 配置.md 这个文件，但是我忘了刚才想记录的是什么

      • 第 5 个差别：用 logseq 记录，到达路径很短，心智负担为零；用 typora 记录，到达路径很长，心智负担巨大

    5. 查看系统剪贴板，回想起了要记录的东西，开始记录

    6. 记录完毕，我开始了每日固定的读文献时间。30 分钟之后，我有一条突发的阅读心得想快速记录下来，于是我唤出了 utools，再次重走上面的曲折心路历程。

      • 第 6 个差别：如果是用 logseq 记录，我只需要再次在 daily notes 页面的第一行写下：

        - [[文献/文献名]]
  - 这个思路真是妙啊
- [[logseq/配置]]
  - `:ui/show-empty-bullets?` 变量：显示或隐藏内容为空的 bullets

    所以，这两种方式看似差不多，实际上是天壤之别。笔记的核心首先是记录，而 Conor 流程把使用者在记录时的心智负担降到了接近于 0 的水平，这种流畅无压的记录方式能极大促进一个人记录更多的东西。

    我这里说的还仅仅是记录阶段，后面的阶段差距更大。

  • deerain • • 1 • 1 赞同
    订阅者 支持者 勇士 作者

    按照大纲双链笔记的流程，一开始在日记文件里写下「判断标准」这部分内容的时候，就应该当场立即用某种方式把它传递给「SOP」这个文档，这个传递方式就是双链：

    # 2021-07-03.sy

- [[SOP]]
  - 几个好课题的判断标准
    - balabala
    - kalakala
    - xxxxx

    将来集中整理 SOP 这个文档的时候，从反链里可以直接把 - [[SOP]] 和它下方的所有列表项拖进正文然后慢慢整理，这种流程比一开始不加双链事后再去 SOP 这个文档里引用要稳妥得多。

    在思源里实践不了这个流程是因为打开 SOP 这个文档的时候，看到的反链只有以下信息：

    ▼ 2021-07-03.sy
  ¶ SOP

    这个反链只显示了一个段落块，- [[SOP]] 下级的内容全都没有直接展示。如果反链面板优化一下展示方式和可操作性，就可以实践上面说到的流程了。所以问题依然是功能需要优化。

  • deerain • • 1 • 1 赞同
    订阅者 支持者 勇士 作者

    我们讨论的是"究竟选择那种方式会比较好?" 是完全无压力但后续整理麻烦的 Dailynote 还是选择稍微有点压力但是后续整理会轻松点的方法? 我也不知道, 这个心智压力若是实在想完全没有, 那就选择 DN, 若是想方便之后整理还是接受点心智压力就选其他方法, 感觉这个比较随人, 但我已经习惯了开 portal 了

    这段总结得很到位，在认清两种方式的差异之后，剩下的就是个人选择。不过这个选择大多数人不需要纠结，因为不用 remnote 这个软件就实践不了 remnote 的方法，我真正担心的是这两种方式都离思源比较远。

    但 DN 中已有很多内容的时候, conor 也会使用 zoom in 来消除其他文本的干扰的对吧?(这里我不咋清楚, 所以打了个问号)

    这个不需要，新的想法永远写在第一行就好了。

49 回帖
【共同探讨】移动块 / 反链 / 快速无压记录 / 标签

欢迎来到这里！

我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。

注册 关于
请输入回帖内容 ...
  • fangly •
    订阅者 先知

    image.png

    这地方只显示第一级列表项，还是把该列表项所有内容都显示出来，我觉得是不是还要再考虑下，按图片中这种做法的话，在实际场景下，每个列表项的内容都非常多，这样一展开上下文，整个反链面板就爆炸了，而且这样可读性也不高，把父项和子项连在一起看着会很奇怪。

    我觉得，像这个图片中，只显示第一级的 1 就好，子结点上的 11 不要附上去

    图片中的这个设计，基本等价于 Issue #2762 · siyuan-note/siyuan 中葫芦笔记的实现方式，并不是最好的设计，会有比较大的反链面板不可用的风险。按照 roam research 和 logseq 的做法的话是只显示第一级的 1。

    顺带问一下，既然修改了上下文按钮的功能，那么 1.3.6 的反链面板在没有按上下文按钮的时候呈现的内容，是 1.3.5 时按了按钮还是没按按钮时呈现的内容呢，个人希望是前者，像我现在每天第一次打开反链面板的第一件事就是点击上下文按钮，因为不开的话，在侧栏的反链面板每一项显示的内容确实有点太少了

    2 操作
    fangly 在 2021-09-25 00:28:22 更新了该回帖
    fangly 在 2021-09-25 00:10:13 更新了该回帖
  • 其他回帖
  • fangly • • 1
    订阅者 先知

    大佬您在 Issue #2762 · siyuan-note/siyuan 中对于传递型双链和关联型双链的一些描述好像有点不太准确。您觉得两者的区别在于有无上级节点，但我觉得两者本质区别在于该节点除了双链锚文本之外有没有其他非双链的内容，如果是单独的双链锚文本即 - [[bar]]，就是传递型双链，如果有其他内容比如 - 3-[[bar]] 就是关联型双链，因为事实上，我觉得传递型双链完全也可以有上级结点，比如我的 daily note 里有一个顶级节点是学习，然后下面是关于学习的内容，我在这个顶级节点之下再进行内容传递，关联型双链完全也可以没有上级结点，如同我前面发的方法 1 一样。

    我在 roam research 中看了一下，比如有一个页面是这样的：

    image.png

    这个[[Roam meetup]]上面也没有上级节点，查看它的反链，可以看到也是折叠了，没有展现子列表：

    image.png

    而像这个，有上级节点：

    image.png

    它的反链中还是展现了子列表：

    image.png

    所以，roam research 的具体实现中与您在 Issue #2762 · siyuan-note/siyuan 所描述的原则有矛盾，他们并不是按照有无上级节点的原则展现双链的

    所以，事实上，对于关联型双链，思源之前的(1.3.4 之前)的展现内容和 roam research 的展现内容是一样的，只需要把块标从段落块换成列表项就好，不需要展现子级内容

    因此，按照 roam research 进行设计的话，应该是这样：

    • 该节点的内容除了块引用之外还有其他内容的话，不展现子列表，或者在反链面板中默认折叠，也就是说和 1.3.4 之前的版本差不多，只是把块标从段落块换成列表项就好
    • 该节点的内容只有一个块引用，没有其他内容时，展现子列表，也就是按照 1.3.6 的方法

    @88250 D 大，您可以看一下，我觉得按照 roam research 的方案来设计更加科学一点，您现在的设计是按照 logseq 做的，个人认为还是有不少差距的。从我的体验以及我所观察到的 roam research 用户的使用方式来说，在单个笔记库内，关联型双链在数量上远多于传递型双链，因为在正文中会有大量的关联型双链，现在改版之后，对于关联型双链的体验还不如改版前的。

    2 回复
    8 操作
    fangly 在 2021-09-25 17:47:38 更新了该回帖
    fangly 在 2021-09-25 16:20:32 更新了该回帖
    fangly 在 2021-09-25 16:17:21 更新了该回帖
    fangly 在 2021-09-25 15:44:39 更新了该回帖 fangly 在 2021-09-25 15:36:35 更新了该回帖 fangly 在 2021-09-25 15:31:30 更新了该回帖 fangly 在 2021-09-25 15:23:13 更新了该回帖 fangly 在 2021-09-25 15:22:08 更新了该回帖
  • fangly • • 1 赞同
    订阅者 先知

    我觉得反链展现的标准应是：是否展现了充足的上下文。而是否是在“传递”我觉得不太重要。我在一个节点中如果除了双链锚文本外还有其他内容，这些其他内容就相当于上下文，给我足够的信息判断我在这里进行引用是在干什么。而如果一个节点中只有双链锚文本，这样就缺乏上下文，我不知道我在这里引用它是在干什么，所以才需要展现子列表。上下文的目的是让用户知道我为什么引用了当前文档，从而判断这个反链项目是否需要进一步仔细查看。

    对于 - [[闪电网络]] 文章4（需要重读） 这个，上下文信息已经足够，文章标题的信息量已经很大了，不展开子列表我也已经清楚我这里为什么引用[[闪电网络]]，如果我觉得我需要再看一下这篇文章的内容，我只需要展开节点就好，如果我觉得这篇文章目前不需要再仔细看了，我就直接忽略它就好，目光直接移动到紧贴着的下一个反链项目。而此时如果默认展开了该文章的子列表，如果我子列表的第一级节点就有几十个，此时就占满了反链面板，不方便我看下一个反链项目，此时展开子列表我觉得没什么意义，属于冗余信息，文章标题的信息量已经足够了，子列表对信息量的提升非常有限，并且对反链面板造成了一定的“污染”。对我来说，我几乎所有网上摘录的 input 内容都是按这种形式组织的，就是 daily note 的第一级节点中会包含标题和一个双链锚文本，所以如果把我现在的笔记迁移到 logseq 中的话，我有不少文档的反链面板被严重“污染”，完全不可用。

    我觉得还是 roam research 的方式比较适合点。

    所以 logseq 虽然在功能上会让它展示下级，但实际使用中因为用户一般不会在这里再写一个子节点，所以大多数时候是没什么影响的

    在我的体验中，我是经常会写子节点的，我一般的列表达到五六层是常有的事，在第二三层进行关联型双链也经常做。再比如你所举的 - [[闪电网络]] 文章4（需要重读） 这个例子，这下面肯定会有非常长的列表，一级节点可能会有几十个，这究竟是传递型双链还是关联型双链，我觉得不好说，在我的笔记系统中，倾向于当做关联型双链，这里面的内容我不会直接移动到 闪电网络 这个文档中的，只是为了说明这个文章和闪电网络这个主题相关。其实我觉得区分关联型双链和传递型双链没什么必要，反正都是链接嘛，而且其他大纲型双链笔记也没有针对两者的特性进行区分处理：logseq、葫芦笔记是全部一视同仁认为需要子列表来丰富上下文信息；remnote、roamedit 是全部一视同仁认为不需要子列表来丰富上下文信息；roam research 是根据该节点本身的上下文是否充足来判断是否需要子列表来丰富上下文信息，我觉得这是比较中和、比较合理的方式。

    2 回复
    4 操作
    fangly 在 2021-09-25 21:58:52 更新了该回帖
    fangly 在 2021-09-25 21:53:25 更新了该回帖
    fangly 在 2021-09-25 21:47:07 更新了该回帖
    fangly 在 2021-09-25 21:34:23 更新了该回帖
  • fangly • • 1
    订阅者 先知

    我想探讨一个问题：

    假设这样一个场景，我目前正在研究共识协议优化与闪电网络等主题，某一天，我看到了一篇关于 PBFT 协议的共识协议优化的文章，之后看了一篇关于闪电网络的文章，然后又看了一篇关于 PoW 协议的共识协议优化文章，最后又看了一篇关于闪电网络的文章

    方法 1

    这时候，我的 daily note 可以是这样的，不把双链锚文本单独作为一个父结点，而是在父结点后贴上双链，同样能达到传递的功能，并且对同一篇文章可以一次传递到多个文档，这里称为方法 1，如图：

    image.png

    这是闪电网络这个文档的反链面板，目前的形态不错，足够使用：

    image.png

    方法 2

    也可以是这样的，按照典型传递型双链的方法组织，锚文本单独作为父结点，我所理解的形态是这样的：

    image.png

    这是闪电网络这个文档的反链面板：

    image.png

    这时候这个反链面板就存在问题了，我们和 logseq 中的反链面板进行对比：

    image.png

    可以看到，思源中是显示锚文本列表项下的列表块，这样一坨的列表块，实际上等价于只显示第一个列表项，也就是只有第一篇文章的内容，而第二篇文章是看不到的

    此时就面临一个决策，思源现在的反链面板对列表的展示是否需要进一步修改，也就是说需不需要进一步把列表块拆分成列表项，展示该列表块的所有的第一级列表项，完全变成类似 logseq、roam research 那样？

    如果不修改，保持现在的情况，对于习惯于方法 1 的用户（比如我）来说，是有利的，对于习惯于方法 2 的用户来说会不利，信息量少了一些

    而如果修改的话，对于习惯于方法 2 的用户来说会有利，而对于习惯于方法 1 的用户来说，可能会导致反链面板不可用，因为对于一篇文章，我的笔记可能非常长，第一级内容就有很多很多，导致下面这种情况，占据了整个面板：

    image.png

    虽然目前的形态对我来说是有利的，但我觉得还是要讨论清楚，不然如果以后修改的话，我的反链面板会变得不可用，我得立刻修改我的 daily note 形式

    总结一下，两个问题：

    • 方法 1 和方法 2 是否都可行，还是说哪种方法会有问题
    • 思源现在的反链面板对列表的展示是否需要进一步修改，也就是说需不需要进一步把列表块拆分成列表项，展示该列表块的所有的第一级列表项，完全变成类似 logseq、roam research 那样
      • 个人倾向于展现形式保持现状(1.3.5)，对于使用方法 1 的用户来说，完美，没问题，对于使用方法 2 的用户来说，信息量少了一些，但还是具有可用性；但如果修改了，对于使用方法 1 的用户来说可能会带来灾难性的影响
    2 回复
    3 操作
    fangly 在 2021-09-24 19:04:49 更新了该回帖
    fangly 在 2021-09-24 17:13:26 更新了该回帖
    fangly 在 2021-09-24 17:09:45 更新了该回帖
  • 查看全部回帖
deerain
还好我技压全场
回帖
241
 帖子
56
 积分
10101

近期热议

推荐标签 标签

  • OnlyOffice
    4 引用 • 2 关注
  • Logseq

    Logseq 是一个隐私优先、开源的知识库工具。

    Logseq is a joyful, open-source outliner that works on top of local plain-text Markdown and Org-mode files. Use it to write, organize and share your thoughts, keep your to-do list, and build your own digital garden.

    6 引用 • 63 回帖
  • SSL

    SSL（Secure Sockets Layer 安全套接层），及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS 与 SSL 在传输层对网络连接进行加密。

    70 引用 • 193 回帖 • 431 关注
  • etcd

    etcd 是一个分布式、高可用的 key-value 数据存储，专门用于在分布式系统中保存关键数据。

    5 引用 • 26 回帖 • 529 关注
  • SEO

    发布对别人有帮助的原创内容是最好的 SEO 方式。

    35 引用 • 200 回帖 • 22 关注
  • FreeMarker

    FreeMarker 是一款好用且功能强大的 Java 模版引擎。

    23 引用 • 20 回帖 • 462 关注
  • 互联网

    互联网（Internet），又称网际网络，或音译因特网、英特网。互联网始于 1969 年美国的阿帕网，是网络与网络之间所串连成的庞大网络，这些网络以一组通用的协议相连，形成逻辑上的单一巨大国际网络。

    98 引用 • 344 回帖
  • Sandbox

    如果帖子标签含有 Sandbox ，则该帖子会被视为“测试帖”，主要用于测试社区功能，排查 bug 等，该标签下内容不定期进行清理。

    407 引用 • 1246 回帖 • 582 关注
  • JVM

    JVM（Java Virtual Machine）Java 虚拟机是一个微型操作系统，有自己的硬件构架体系，还有相应的指令系统。能够识别 Java 独特的 .class 文件（字节码），能够将这些文件中的信息读取出来，使得 Java 程序只需要生成 Java 虚拟机上的字节码后就能在不同操作系统平台上进行运行。

    180 引用 • 120 回帖
  • Java

    Java 是一种可以撰写跨平台应用软件的面向对象的程序设计语言，是由 Sun Microsystems 公司于 1995 年 5 月推出的。Java 技术具有卓越的通用性、高效性、平台移植性和安全性。

    3187 引用 • 8213 回帖
  • 禅道

    禅道是一款国产的开源项目管理软件，她的核心管理思想基于敏捷方法 scrum，内置了产品管理和项目管理，同时又根据国内研发现状补充了测试管理、计划管理、发布管理、文档管理、事务管理等功能，在一个软件中就可以将软件研发中的需求、任务、bug、用例、计划、发布等要素有序的跟踪管理起来，完整地覆盖了项目管理的核心流程。

    6 引用 • 15 回帖 • 113 关注
  • Vditor

    Vditor 是一款浏览器端的 Markdown 编辑器，支持所见即所得、即时渲染（类似 Typora）和分屏预览模式。它使用 TypeScript 实现，支持原生 JavaScript、Vue、React 和 Angular。

    351 引用 • 1814 回帖
  • Lute

    Lute 是一款结构化的 Markdown 引擎，支持 Go 和 JavaScript。

    25 引用 • 191 回帖 • 16 关注
  • GitLab

    GitLab 是利用 Ruby 一个开源的版本管理系统，实现一个自托管的 Git 项目仓库，可通过 Web 界面操作公开或私有项目。

    46 引用 • 72 回帖
  • 代码片段

    代码片段分为 CSS 与 JS 两种代码，添加在 [设置 - 外观 - 代码片段] 中，这些代码会在思源笔记加载时自动执行，用于改善笔记的样式或功能。

    用户在该标签下分享代码片段时需在帖子标题前添加 [css] 或 [js] 用于区分代码片段类型。

    69 引用 • 373 回帖
  • Angular

    Angular 是 AngularJS 的新版本。

    26 引用 • 66 回帖 • 536 关注
  • Kubernetes

    Kubernetes 是 Google 开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。

    110 引用 • 54 回帖
  • ActiveMQ

    ActiveMQ 是 Apache 旗下的一款开源消息总线系统，它完整实现了 JMS 规范，是一个企业级的消息中间件。

    19 引用 • 13 回帖 • 672 关注
  • Sphinx

    Sphinx 是一个基于 SQL 的全文检索引擎，可以结合 MySQL、PostgreSQL 做全文搜索，它可以提供比数据库本身更专业的搜索功能，使得应用程序更容易实现专业化的全文检索。

    1 引用 • 210 关注
  • PWA

    PWA（Progressive Web App）是 Google 在 2015 年提出、2016 年 6 月开始推广的项目。它结合了一系列现代 Web 技术，在网页应用中实现和原生应用相近的用户体验。

    14 引用 • 69 回帖 • 154 关注
  • Hibernate

    Hibernate 是一个开放源代码的对象关系映射框架，它对 JDBC 进行了非常轻量级的对象封装，使得 Java 程序员可以随心所欲的使用对象编程思维来操纵数据库。

    39 引用 • 103 回帖 • 709 关注
  • Rust

    Rust 是一门赋予每个人构建可靠且高效软件能力的语言。Rust 由 Mozilla 开发，最早发布于 2014 年 9 月。

    58 引用 • 22 回帖 • 1 关注
  • 书籍

    宋真宗赵恒曾经说过：“书中自有黄金屋，书中自有颜如玉。”

    77 引用 • 390 回帖
  • App

    App（应用程序，Application 的缩写）一般指手机软件。

    91 引用 • 384 回帖
  • Swift

    Swift 是苹果于 2014 年 WWDC（苹果开发者大会）发布的开发语言，可与 Objective-C 共同运行于 Mac OS 和 iOS 平台，用于搭建基于苹果平台的应用程序。

    36 引用 • 37 回帖 • 529 关注
  • 30Seconds

    📙 前端知识精选集，包含 HTML、CSS、JavaScript、React、Node、安全等方面，每天仅需 30 秒。

    • 精选常见面试题，帮助您准备下一次面试
    • 精选常见交互，帮助您拥有简洁酷炫的站点
    • 精选有用的 React 片段，帮助你获取最佳实践
    • 精选常见代码集，帮助您提高打码效率
    • 整理前端界的最新资讯，邀您一同探索新世界
    488 引用 • 384 回帖 • 8 关注
  • 电影

    这是一个不能说的秘密。

    120 引用 • 599 回帖

最新标签