前言 (Intro)

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

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

本文翻译自 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

前言 (Intro)

时光荏苒，岁月如梭。

前言 (Intro)

任何一个开发者或者团队，都应该有一套自己的开发约定。

我参考了 airbnb 的 eslint-config-airbnb，并根据自己的编程经验配置了一个 eslint-config-adoyle-style。
实践了很长一段时间，今天总结一下如何写一个可扩展的，兼容多场景的 eslint 配置文件。

概览 (Overview)

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

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

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

概览 (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 -------

前言(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？！

前言(Intro)

当运行下面一段代码，会发生什么？

1
2
3

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

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

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

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

前言(Intro)

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

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

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