构建个人知识库

前言 (Intro)

从 2016 年 8 月开始,我就在实践构建个人知识库,主要为了建立全面而深度的专业知识体系。也想有个备忘录,以备随时查阅。
后来思维导图在我工作生活中起到了重要的作用。截至 2018 年 2 月 28 日,我已经积累了 151 个思维导图,知识库已初见规模,其中有很详细的领域知识,也有几句话的想法。

接下来,将分享我构建个人知识库的经验。
如果你觉得文章太长看着麻烦,那就直接跳到最后一章,直接看本文的思维导图。当然两者是不等价的,文章包含更多细节。

Think in alternatives

本文翻译自 Scott Nonnenberg 的文章 《Think in alternatives》

译前记

当时选择翻译《Think in alternatives》这篇文章,是因为它给了我启发。我觉得这是一个开发者必经的思考成长过程,从「只会一个方法 / The one true way」到「多个看似正确的方案 / Multiple correct solutions」,然后是「协调权衡 / A classic continuum」,然后「增加思考的维度 / A few more axes」来帮助权衡筛选方案,最后是「创新 / Breaking out of the box」。这大概就是所谓的「守破离」的过程吧。

另外作者在最后对于如何与团队讨论决策也有心得,当你尽力考虑过所有方案时,以合适的时间在合适的地点提出来。参与到细节和全局,考虑到人和物,才能做出最正确的决策。

其实这篇翻译在我电脑里躺了一年……一年后再看,没有了当初阅读的欣喜,只觉得是很自然的想法,一切都在于「权衡」这个词。
二次校对和润色后,发现初次的翻译果然很糟糕,现在终于把还能入眼的译文发布出来了。

二零一柒 · 结

前言 (Intro)

2018 ▓▓▓█████████████████ 85%

2018 年已经过去了 15%,写年终总结是不是太晚了……
话说 2017 年定下的年初计划好像一个都没实现……
啊,那年终总结这样就完事了吧?The End

好的开源项目是怎样的?

概览 (Overview)

或者说好的开源项目的维护者应该是怎样的?

我觉得它应该至少包含以下几点:

  • 解决问题
  • 帮助他人
  • 不要重复别人所做的事
  • 承担责任
  • 持续改进
  • 遵循 Semver
  • Contributing Guide
  • Style Guide
  • 版权归属
  • 良好的文档
  • 不要给这个世界增加冗余度

告别 'use-strict'

概览 (Overview)

结论:如果你使用的 node 版本 >= 2.0.0,可以不必再在每个文件头写 'use-strict';,因为 node 已经默认开启 strict 模式。

------- 2018-02-25 updated -------

很抱歉,并不是。截至 node v9.6.1,node 都没有默认开启 strict 模式,详见node 源码
对于 node 来说,执行 node --use_strict 才会生效 implicit strict mode,你可以通过 node --v8-options 找到这个 --use_strict 选项。
但是 --use_strict 不建议你使用,具体原因见下文。

所以下文所说的部分内容,是不对的。
我做了对应的修正,另外下文还是默认以 node 8 为背景叙事,用到 node 9 的地方我会提示的。

结论:
在 node 端,你最好在每个文件头加上 'use-strict',并且不要使用 node --use-strict 选项;
在浏览器端,如果你使用的是 <script type="module">,则默认开启了 strict 模式,否则也还是要加 'use-strict' 的(不过一般有前端工具帮你处理这事)。

------- 2018-02-25 updated end -------

Makefile 的一个陷阱

前言(Intro)

问题是这样的,我写了一个 Makefile,大致内容如下,

1
2
3
4
5
6
7
.PHONY: b c1 c2

b: c1 c2
echo b

c%:
echo $@

然而执行 make b 却只打印出 b
执行 make c1 的结果却是 make: Nothing to be done for 'c1'

为何会无法执行 c1 和 c2?!

Promise 吞掉报错信息的问题

前言(Intro)

当运行下面一段代码,会发生什么?

1
2
3
Promise.resolve().then(function() {
throw new Error('Ouch!');
});

恩,你看不到任何错误信息。
沉默的失败非常可怕。当发生错误时,你无法获知任何当时上下文的信息,仅有的线索只有程序没按正常的流程走。你甚至可能都没有机会察觉到发生了错误。

也许这是一个 Feature,而非 Bug。但我觉得这是一大隐患,所幸有些人也注意到这个问题,并已经在修正了。看看这个提案

在 nodejs 1.x 起,process 加入了两个事件 rejectionHandledunhandledRejection,并且在大部分主流 Promise 库中也实现了这样的特性。为了捕获没有处理的 rejected promise。

CSRF 攻击原理

前言(Intro)

有一个关键的问题:CSRF 攻击主要是利用 cookie 来伪造受害者的身份来发起恶意请求。(本文只讨论基于 cookie 进行身份验证的情况)
可是根据同源策略,不同源的网站之间的请求,是不会带上 cookie 的。那么 CSRF 攻击是怎么成功的呢?

网上的文章,无论中英文都写得不清不楚,仅对如何预防有详细的解释,却鲜有将攻击原理解释清楚的。

本文只讨论 POST 类型的 CSRF 攻击,因为这个攻击手段最为复杂。