Blog | Phodal - A Growth Engineerhttp://www.phodal.com/blog/2021-12-05T11:56:37.940216+00:00BlogQuake 一个开源的知识管理元框架2021-12-05T11:56:16+00:002021-12-05T11:56:37.940216+00:00Phodal Huanghttp://www.phodal.com/blog/author/root/http://www.phodal.com/blog/quake/本文使用 Quake Web 应用编写,虽然只有基本的 Command + S 来保存标题 + 内容的功能。这个简单粗糙的页面,让我想起了多年前构建 Phodit 的场景,`it works` 作为开始就足够了。
来, 先上链接 GitHub: <https: github.com="" phodal="" quake="">
# 缘由
半个月前,我在准备一个材料,好不容易从我的博客、Todo、Notes 里找到了一些相关的素材。我使用了不同的工具来管理知识,Microsoft To Do 管理 idea、[Phodit](https://www.phodit.com/) + [Phodal.com](https://www.phodal.com/) 发布文章、Apple Notes 记录笔记等等,知识被分散在各个工具中。不利于我进行洞见,寻找灵感,与此同时,还缺乏书写和记录的方式。
于是,我需要一个新的工具来融合到我的知识体系里,它应该是:
* 开源的。可以自由扩展。
* 分布式 + 本地化的。可以离线使用,方便于出差旅途中使用。
* 版本化的。可以自由查看变更历史。
* 开放的。可以自由与其它工具组合。如 Vim、VSCode 等。
* 易于扩展。可以结合习惯用的工具。诸如于,基于 DSL 的编辑-发布分离的类 Web 模式,用于展示。如 MxGraph、Mermaid、Ledge Framework 等
所以,就有了:<https: github.com="" phodal="" quake="">
# Quake:知识管理元框架
Quake 的目标是构建面向**极客**的知识管理元框架,它可以:
* 自由的文本内容管理。Todo 清单、文章管理、书评、笔记等。
* 构建知识网络体系。定制化 markdown 链接
* 抓住稍纵即逝的灵感。支持快速启动(CLI、TUI)与全局搜索
* 自由的呈现画布。DSL 与自由画板
简单来说,通过 Markdown 来记录数据,Git 来进行版本化,Terminal 来快速编辑,Web + Web Components 提供定制能力。
## Quake 设计理念 1:数据代码化
Quake 延续了 Ledge Framework 中非常成功地思想:文档代码化 + Markdown 图表化 + Git,来提供对于数据的管理。尽管我们没有在 Quake 中引入数据库,但是依旧可以提供如下所功能:
1. 数据迁移。
2. 历史状态。设计一个拥有历史状态的内容是一件麻烦的事情。
3. 数据查询与更新。
4. ……
只是呢,现在的这些功能只能支持基本的开发。对于扩展来说,依旧是有问题的,未来需要提供简化版的 SQL,以提供更好的数据处理。而除了 SQL 之外,另外一种简单的方式,就是提供脚本语言的支持。
## Quake 设计理念 2:自由定制
设计一个能支持不同数据模型的知识管理系统痛苦了,需要大量地前期工作。因此,我们先构建了一个可以自定义数据格式的元数据引擎。让每个人都可以自定义的数据格式,并能为这些数据自定义视图,就能简化大量的工作。
### 自定义数据类型
在 Quake 里,通过 YAML 来定义数据格式,也可以从导出的数据后生成(通过 `quake cmd -i “quake.sync”` ):
```yaml
- type: notes
display: ""
fields:
- title: Title
- description: String
- category: String
- created_date: Date
- updated_date: Date
- author: String
actions: ~
```
生成对应的 markdown 文件,形如:`0001-time-support.md` 即 id + title 的形式,对文件再进行编辑:
```javascript
---
title: time support
author:
content:
created_date: 2021-11-24 19:14:10
updated_date: 2021-11-24 19:14:10
---
ahaha
```
考虑到生态兼容的问题,所以在 Quake 里直接采用了 Jekyll 的 Front Matter 语法来定义数据。我们对于文件的编辑操作,即内容和相关的内容信息,都是直接基于这个 markdown 文件的。
### 自定义显示组件
进行中。
现有的 Web 部分架构是基于 Web Component 构建的,以提供自定义的数据操作能力。如通过下述的代码,可以构建我们的编辑器,并进行对应的交互:
```javascript
const editor = document.createElement('quake-editor');
editor.setAttribute('id', entry.id);
editor.setAttribute('title', entry.title);
editor.setAttribute('value', entry.content);
editor.addEventListener("onSave", function (event) {
update_entry(params.type, params.id, {
title: event.detail.title,
content: event.detail.value.replaceAll("\\\n", "\n")
})
});
return editor
```
对于不同的内容来说,也是类似的,只需要创建好对应的组件,处理相应的结果即可。通过这种方式,构建出常用的各种数据类型,并让所有的开发者都可以自定义。
# 如何使用 Quake
现阶段,Quake 面向的群体主要是极客、软件工程师,又或者是具备一定 IT 基础的软件开发人员。毕竟,我们还没有 GUI,还需要一系列的应用封装工作。不过,GUI 从架构上来说太重了,构建一个基于本地 Web + Terminal 的 MVP 版本反而更加容易,还能验证自由度的可行性。
## 安装 Quake
Quake 的安装在现阶段,还是比较麻烦的,还只能在 CLI 下进行(所以,我们面向开发者,我还有得选吗?):
1. 安装 Quake。
1. 有 Rust 环境的话,可以直接 `cargo install quake`
2. 没有 Rust 环境的话,可以从 [Quake Release](https://github.com/phodal/quake/releases) 页面下载。
2. 安装搜索引擎(可选的)
1. macOS 用户,可以直接 `brew install meilisearch`
2. 其它操作系统的用户,建议访问官方进行:<https: github.com="" meilisearch="">
3. 引入 Web 页面。可以从 [Quake Release](https://github.com/phodal/quake/releases) 页面下载 web.zip,并解压到某个目录。
随后,到相应的文档目录,执行 \`quake init\`,就可以得到一个初始化的环境了。执行 `quake server` ,就可以进入 Web 页面使用了。
## Quake Importer
回到文章的开头,首先我们要解决的是数据迁移的问题。所以,上周末,我的主要工作是在数据迁移上,将不同的数据源转化为 Markdown。如在 [Quake Importer](https://github.com/phodal/quake/tree/master/quake_importer) 中,有下述相关数据源的文档:
1. Django CMS 的相关文章
2. Apple Notes(备忘录)的相关备忘
3. Microsoft To do 的相关待办事项
从我的数据来看,我大概有 888 篇的文章,99 个 Todo,还有 302 篇的备忘。当然了,我还有一部分抓取的资料存储在 Microsoft OneNote 上,这部分在后续需要进一步完善了。
## Quake Cmd
在导出相关数据,便可以通过 `quake cmd -i “quake.sync”` 命令同步生成定义不同内容类型的定义文件。
随后,可以直接创建新的内容,只需要通过 `quake cmd -i “blog.add: Quake 一个知识管理元框架”` 来快速创建新的 `blog` 内容。Quake 优先通过 Terminal 实现了基本的 CRUD 功能,如此一来,我们不需要缓慢地启动笔记工具,才能完成一个快速的想法。我们可以利用大量地再成的基于 Terminal 编辑器,如 Vim,快速完成记录。
在保存之后,我们将更新生成对应的 `csv` 数据索引文件,以面向 Terminal 提供快速的接口能力。
## Quake Server
当我们需要寻找灵感时,便可以通过 `quake server` 启动我们的 Web 服务,在上面搜索、索引知识、管理知识等。基于本地的 Markdown + Meili 搜索引擎,我们能构建最好的本地体验。Quake 的 Web UI 界面是基于一个个的 Web Component 构建的,这就意味着,在我们提供 CRUD API 的基础上,你可以结合我们提供的组件能力,自由地构建你的 Web UI。通过在 Quake 的配置文件 `.quake.yaml` 中修改 `server_location` 参数,就能使用自己开发的页面了。在这时,Quake 只是作为一个 Markdown 的 CRUD API。
最后,因为所有的数据是围绕于 markdown + yaml 的,所以,我们可以结合 Git 进行版本化管理。(PS:这部分功能还没设计)
## 下一步
在完成了 MVP (最小可行产品)版本之后,依旧还有一系列的工作要做:
* Terminal UI。已经有小伙伴工作在上面。
* 定制 Markdown 语法。用于支持诸如于双链、文本图表化、脑图
* 全局 GUI 入口。从全局搜索支持,类似于 Spotlight Search
* Web 应用设计。现在的版本非常粗糙,缺乏各种功能。
* 更好的知识管理。
你可以在 Quake 的 [Story](https://github.com/phodal/quake/tree/master/_fixtures/story) 中看到更多的相关内容。
如果你也有兴趣,欢迎加入我们。</https:></https:></https:>如何去管理你的知识管理?2020-04-20T12:36:33+00:002020-04-20T09:37:32.016532+00:00Phodal Huanghttp://www.phodal.com/blog/author/root/http://www.phodal.com/blog/how-to-manage-knowledge/人的智商不够、又或者是脑容量不足以容纳这么多的知识。所以,对于个人来说,我们工作的时候,依赖于文档、笔记、文章,来帮我们回忆起这些知识;对于组织来说,知识传递是需要知识管理的一个关键因素。
一年前,在那篇《个人知识管理的思考》中,我反思了自己在知识管理方面的不足,如:
- 没有归档
- 没有输出时,相关的资料就如石沉大海
- 缺乏系统性地梳理
自那之后,我尝试构建了不同的开源项目来做知识管理:
- inception。将流程可视化为工具,用于辅助实施软件开发的以系列实践。
- powermd。将 markdown 转化为各式各样的工具,如思维导图、checklist、todo 应用等等。
- ledge。一个结合 inception 和 powermd 的 DevOps 知识平台,基准化软件开发流程及对应的标准化实践,并设计一系列的工具来辅助进行实施。
## 知识图谱
期间我接触了 ”知识图谱“ 和 ”知识管理“ 两个领域的相关概念,收获也算还行。
> 知识图谱(Knowledge Graph),在图书情报界称为知识域可视化或知识领域映射地图,是显示知识发展进程与结构关系的一系列各种不同的图形,用可视化技术描述知识资源及其载体,挖掘、分析、构建、绘制和显示知识及它们之间的相互联系。
简单来说,假设我们要为 “后端” 建设一个知识图谱,那么在今天最简单的方式就是:找一个技能图谱,完善相关的内容。一个比较好的例子,就是我之前做的 Growth,又或者是 Sherlock 这样的可视化知识图谱:
但是呢,怎么做是个问题。在《知识图谱:方法、实践与应用》一书中,提到了知识图谱的技术流程。
1. 知识来源。
2. 知识表示与 schema 工程。
3. 知识抽取。
4. 知识融合。
5. 知识图谱补全与推理。
6. 知识检索和知识分析。
考虑到原书是几个博士、教授写的,不那么落地,我来重新解释一下:
1. 制定知识图谱策略。从那些地方获取知识图谱数据,获取哪些数据,用怎样的方式进行加工。如人工众包
2. 设计数据结构模型。根据知识类型的不同,设计他们的模型,及其表示关系。
3. 编写应用进行知识转换。按任务分为概念抽取、实体识别、关系抽取等。
4. 融合不同数据源。
5. 补全、完善知识图谱。
6. 展现知识图谱。如语义检索和智能问答。
## 知识管理
> 知识管理包括一系列企业内部定义、创建、传播、采用新的知识和经验的战略和实践。这些知识和经验包括认知,可以是个人知识,以及组织中商业流程或实践。
从步骤上来说,对于企业来说步骤一般是:
1. 认知
2. 规划
3. 试点
4. 推广和支持
5. 制度化
对于个人来说,比较简单:
- 记录。记录下现有的知识
- 整理。按自己的需要重构
- 可视化。呈现现有步骤的过程
- 优化 。寻找可优化的空间
## 知识图谱 + 知识管理
ledge 便是结合两种体系规划出来的,从 ledge 的构建步骤来看,可以分成这么几步:
1. 从一张简单的 DevOps 图谱开始。Ledge 是来自于书上构建的图谱
2. 总结先前的经验和教训
3. 获取社区相关的知识和智慧。就是搜索嘛
4. 保留下知识
5. 提取最佳实践
6. 抽象行为模式
7. 改进文档的访问
8. 重复 2 ~ 8
9. 形成洞见,创新
对应的一些建议:
1. 买书,买书,买书。绝大部份的书都是一份索引好的图谱,只需要抽象一下即可使用。
2. 通过社区和网络把人们连接起来。邀请更多的人来共建。
## So ?
让我们看看啊 ledge 会不会更加受欢迎。Ledge:一个开源的『DevOps + 研发效能』知识平台2020-03-30T11:49:36+00:002020-03-30T11:51:40.350903+00:00Phodal Huanghttp://www.phodal.com/blog/author/root/http://www.phodal.com/blog/ledge-a-devops-effective-knowledge-platform/过去的一个月里,因为种种不可告人的原因,我开始建设一个 DevOps 知识平台。因为,现有的笔记系统都太 TM 难用了。所以,我要写一个,我要造一个轮子。在这一个轮子里,它可以通过 markdown 编写内容,并渲染出各种绚丽的效果。哦,不对,这部分的内容偏题了。
在这个知识平台里, 它包含了这么一些内容:
- **DevOps 工具元素周期表**。帮助您进行数字化时代的 DevOps 工具选型。
- **DevOps 设计工具**。帮助您设计组织内的 DevOps 流程,涵盖了流程、人、工具、制品等等。
- **案例学习**。从社区的知识库中,我们总结了传统企业走向 DevOps 的经验,并浓缩到易于使用的内容和材料中。
- **最佳实践**。我们从海量的 DevOps 内容中,提炼出了一系列的最佳实践,以更好地帮助企业进行 DevOps 实践。
- **模式与原则**。基于我们的实践,我们提炼了位于它背后的模式与原则,帮助个人和组织更好地了解 DevOps 文化。
- **操作手册**。只凭实践与原则,无法让中小型 IT 团队进行 DevOps 转型,所以我们准备了详实的操作手册,以帮助您一步步前进。
- **度量**。KPI - 度量、度量 - KPI、KPI - 度量,帮助您更好地度量 DevOps 转型情况。
- **报告**。我们尝试从丰富地 DevOps 报告中,提炼出有用的实践和工具。
- **Mobile DevOps**。我们相信移动应用的 DevOps 改进,才是大多数公司的挑战。
- **工具**。工具,工具,工具是最好的生产力,工具比人的记忆力更加可靠。
起先,我是想做一些 DevOps 工具,比如说适合于中国国情的『DevOps 元素周期表』。顺带一说,这个工具不是我首创的,我只是用更好的架构实现了一遍。。如此一来,对于大部分开发人员来说,它们就可以从这个表中,组合出适合于自己组织的分子(毕竟周期表上都是原子)。几天之后,我就有了这个工具,根据整个研发体系的每一个过程,你可以从中挑选出适合你的要素。
为了凑满上面的元素,我不得不找一个又一个大公司的案例,看看他们到底是用什么技术栈。所以,我七拼八凑得差不多了,顺便一想,既然我有这么多大公司的案例,为什么不抽象一下这些案例呢。
于是,我们从互联网的各个地方(来源见内容中标明的出处),帮你抽取了各大公司的案例:
- 腾讯
- 小米
- 招商银行
- 美团
- ……
在这些案例,背后往往包含、隐藏了各种各样的价值取向。所以,进一步地,我想去提取这些模式,所以就包含了:
- 流畅度模式
- 度量体系设计
- 学习型组织构建
- ……
画完这些大包之后,随后,我们就可以进入 DevOps 的设计和实施阶段。我们要找到那些最好的实践:编程、团队、文化、能力、测试等等。
太多,不写。
当然了,为了在组织中实施 DevOps,我们还需要一本操作手册,来帮助你一步步构建 DevOps 体系。
从度量,到实践,到工程化,再到流程打通,顺势而来,一步下实践。
光有手册是不行的,我们还把各种各样的工具做了上去,除了工具的名称,还包含:
- 工具的准备事项
- 工具的操作步骤
- 工具的示例
- 该工具的在线工具使用
还有更多的功能在开发中。
也欢迎加入我们的开发队伍,更多的案例将帮助每个人更好地成长。
GitHub:https://github.com/phodal/ledge/
在线使用:https://devops.phodal.com/个人知识管理的思考2019-07-29T12:34:29+00:002019-07-29T04:36:02.507263+00:00Phodal Huanghttp://www.phodal.com/blog/author/root/http://www.phodal.com/blog/thinking-in-personal-knowledge-manage/最近,我困扰于『知识管理』——其实一开始,我并不知道我需要的是它。在我打算买几本 Kindle 电子书,以消磨一下时间的时候,我发现了『知识管理』相关话题的电子书。我这才意识到,**我迫切需要一些新的工具来管理知识。**
一来,我接触的东西太多了,以致于忘记的速度太快了(反正比两分钟长)——而写一篇博客的时间太长了,打开一个网页两三分钟,我可能就会关闭它了。
二来,我所在的公司正在变成一家『大公司』。过去的扁平、透明也在逐渐的减弱,作为一个普通员工,我所能访问的资料也越来越有限。
不过,这些都不重要,重要的是让沉淀变得更多,变得更加高效。毕竟,随着年纪的增长,越来越多的时间被各种杂事占用了。当你一个人的时候,你有充足的时间来干你喜欢的事;当生活变成两个人的时候,你得陪另一半做喜欢做的事;当以后变成三个人的时候,你就有更多事情了。所以,在时间变得更加有限之前,我们所能做的事情变成了:高效。
当然了,所谓的低效是相对的。如果过了这么多年,我还是保持一样的知识管理效率,那么说明它是的低效——即有待提升。
## 现有的知识管理体系
在日常的学习和工作中,我们有不同的方式来摄取方方面面的知识,也应用于不同的领域。它并不局限于日常的技术工作,还有与软技能相关的知识,还有其它方方面面的内容。
为了优化这些知识吸收的过程,我们需要这么几步:
1. **记录**。记录现有的知识体系
2. **可视化**。呈现再有步骤的过程
3. **度量**。记录每个步骤所花的时间
4. **优化** 。寻找可优化的空间
作为一个刚入门知识管理领域的人,我只能先**记录**相关的步骤,再寻找可视化及度量的方式。
### 内容管理
对于写作来说,在确认了主题/目标之后,往往是分为这么几步进行的:
1. 收集资料。来源往往是 Google 搜索的相关博客、书籍等等。
2. 提炼资料。寻找文章、书籍的一些关键点。
3. 整理体系。根据需要整理第一步的内容。
4. 消化存档。嗯,就是一个手工活,或是变成文章,或只是一堆草稿。
而在真正实现的过程中,我感觉有两步并不是那么理想,即**收集资料**和**编写内容**。(PS:至于能不能优化是另外一件事)
- **收集资料**。随着时间的变化 ,我收集资料发生了一些改变。过去,在写作的时候,我只会留下一个链接 ,现在多了一个留言,甚至有可能会有专门的引用部分。这样一来,未来在回过头来看这些资料的时候,能找到一些思路。
- **编写内容**。在写作的过程中,我们消化了相关的内容,并提出了自己的一些新的看法。但是,并非所有的时候,都有必要去写一篇文章。有些内容,我们只需要用代码的方式来展示,诸如于 ``gist``,再配合一些注释就可以了。而有些内容,则只需要一个大纲就可以了,诸如之前的 New Project Checklists。
顺带一提,在我进行信息提炼的时候,使用最多的工具是,笔 + 纸 / Wacom Bamboo Slate(电子笔记本),主要是我的 iPad 太小,而 iPad Pro 又太贵了。当我们使用电脑的时候,由于习惯的原因,使用往往是线性的思维。而我们的思路往往都是非线性的。
### 阅读
尽管我阅读了很多的书,但是我在这方面的产出相当的少。而据我所知,一种颇为有效的方式是:
- **思维导图**。采用**思维导图**的方式来构建出这本书的内容。就我个人而言,这种方式失去了读书的乐趣,目的性太强,所以去不会采用
于是乎,我采用的仍然是很传统的方式:
- **记录笔记**。我一般看书的时候,会偶尔做一些笔记。只是这些笔记,缺少一个承载的地方。
- **书评**。最近,最近好像已经不怎么写相关的书评。大概是因为写这么一个书评,它所花费的时间比较多,有种投入产出比不划算的感觉。因为这本书是在我书架上存在的内容,我想要的时候都可以随时拿到。但是,当我的书在杭州,而人在上海,就会变成一种新的挑战。
但是,由于我看书比较随性,往往什么都没有做,这一点倒是有一些改进空间。我往往觉得大致能把目录记下来,下次就可以方便地阅读这本书了。反正,书放我的书架上不会跑。
### 知识图谱
对于知识的索引与图谱构建,大抵是我在过去最有收获的部分之一。即整理某一领域相关的知识,诸如于读书路线、学习路线、技能图谱。
往后,在学习的时候,就可以有针对性地查缺补漏。又或者是,为刚进入这个行业的新人提供一些建议。
### 编码
在我们工作中用得最多的就是,对于将知识放在代码中,每个项目都有多种多样的方式:
- **README**。
- **注释**。
- **提交信息**。
- **架构决策记录**。
- **架构图**。诸如于 C4 模型
对于大部分的内容来说,要实施起来并不困难。但是,如何在代码中体现业务逻辑呢?又或者是通过代码来生成业务逻辑?比如,通过注解生成 URL 跳转相关的路径?
而如果是业务相关的知识,则可能有不同的形式来实现:
- **测试用例**。
- **用户旅程**。
- **用户地图**。
设计初期,我们会拥有一个初步用户旅程。而完成项目的时候,用户旅程可能会发生一些变化,我们应该采用、开发工具去优化这个过程。它可以通过 URL 来记录页面,而后通过 DSL 来转换成旅程地图。
### 工作流程
在经历了一个又一个项目之后,我对项目的生命周期有了更好的理解。而项目的生命周期,也相当于是工作流程。对于流程来说,规范是一个很扯淡的东西——没有人想去看文档。在编码中,我们可以通过一些 hook 来规范工作,如:
- pre-commit
- pre-push
- lint
而对于非编码性工作来说,其应对的最好方式是:**开发流程的工具**。它并非是一个固化的流程,但是它拥有所的工具。这也是我正在尝试去做的东西之一。年初做的 New Project Checklists, 以及正在实施的升级版本:应用周期管理,都是一些新的尝试。
## 可改进方向
除了上面提到的一些点的相关优化,是否还能尝试更多的东西?
### 优化收集?
如上所说,我在收集的这一维度,还有一点改进的空间:
- **记录、标记内容**。诸如于,我会时常关注 GitHub Trending,又或者是收藏一些 GitHub 上的项目,但是我并没有很好地工具来管理它们。对于这样简单的一个工具,我可能得想办法自己动手制作一个,说简单也简单,说难也不难。
- **重启 RSS 订阅?**。不过,这也是我当前存在的一个疑惑。过去, 我能使用 RSS 工具来管理资源,它的前提是互联网是开放的。而今,通过 RSS 已经很难找到一些优质的博客——除了我的博客,哈哈。
尽管它会花费一定的时间,但是将来在使用的时候,可能会节省更多的空间。唯一的问题是,还得做个工具。
### 寻找非线性输出方式?
线性的内容对于来说,问题不大,因此非线性内容就成为一个关注的点。只是呢,我并没有一点儿头绪。不过,一些有趣的方向可以是:
- **图片**。画图更浪费时间,哈哈。
- **照片**。比如拍照的时候,进行文字识别,不过对应的识别 API 意味着额外的支出。可能 Tag 是一个更好的选择吧,haha。
- **思绪导图**。现有的思维导图工具,都是线性的,又或者是本地使用的。而我又不想把数据放置在别人的数据库上,万一数据被删了呢。
所以,还可以自制一个简单的工具,加上额外的扩展方式,才是我所需要的内容。
### 集中式管理?
集中管理,意味着:
1. 标准化的输出方式。
2. 可 API 访问的平台。
3. 集成内容中心。
出于搜索的需要,我们
- GitHub 上的项目
- 社区的技术文章
也因此,我们并不一定能做这样的时间,但是可以尝试结合**标签来关联网络**
### 模板化?
TBC。(我并不喜欢模板化)
## 相关工具
如下是我日常使用的知识管理工具:
- 笔记。以前我用的是 Evernote,但是它收费,我便改成了 Microsoft OneNote。我仍然也没用好它。
- 看板。对于一些开源项目来说,我会使用 Trello,GitHub Projects 来管理。
- Todo App。我习惯使用 Wunderlist,因为我已经习惯了。不过,我最近正在切换到 Microsoft To-Do,因为自 Wunderlist 被微软收购之后,To-Do 才是未来。
- Calender 工具。还没有。作为一个普通的开发者,我并没有那么忙,偶尔有一些就用手机自带的。
- Markdown + Git + ADR。ADR 是一个架构决策工具,我用它来管理开源项目中的 IDEA
- GitHub issues。用来管理新的 Ideas,见: [https://github.com/phodal/ideas/issues](https://github.com/phodal/ideas/issues)
不过,我并不习惯于使用看板这样的工具,对于我来说,它太重了——总有一种回到工作的感觉。而 Todo 应用则在点一下,完成一下的时候,有那种相当爽快的感觉。其它工具推荐:
- RSS。Feedly。不过,话说现今国内活跃的博客越来越少了。我博客的 RSS 是( [https://www.phodal.com/blog/feeds/rss/](https://www.phodal.com/blog/feeds/rss/) ),欢迎订阅。
- 番茄钟。我用了一段时间,发现对我没啥用,我是那种多动的人。
因为,我还没有那么忙,所以大部分的时候,我还是处于佛系的状态。
## 结论
你有什么与众不同的方式,能分享一下吗?