“就因为手里拿着书，我觉得自己变得成熟、严肃了。”
“拥有某一本书——你自己挑选的书——就是定义你自己。”
“我去逛书店就像病人去看医生、少年犯去收容所。”
“写作的时候不是废寝忘食不过日子。恰恰相反，我敢建议别人写作，是因为写作就像是一个人生活的房子增添了一个房间。人要有生活，也要思考生活，那也是热情生活的一种方式。”
......

书店对于某些爱书的人来说，是一个精神上的圣地，一个现实中的避难所。但书中很多作者对实体书店的没落，归咎于网络书店和电子书的崛起，颇有微辞。对此，我是不太认同的，我觉得网络书店和电子书是线下纸质书店的有力补充，而不是对立。

我喜欢读电子书，有两方面原因：一是无需背着一本书到处跑，打开电子设备就能继续；二是，电子书 APP 都有学习时长，读的多，越有成就感，而成就感又促使我读更多。对于我这种普通人来说，由此带来的正向激励简直太赞了。

当然，那种拿一支笔在书上写写画画，还是纸质书体验最好。我认为纸质书依然会继续下去，不会消亡，因为总有一拨人深爱着它们，就像书中的那些作者一般。

年度目标完成的怎么样了，下半场又开始了...

三人行，必有我师。昨天上午的半年总结，认真观察其他同事编写的 keynote ，有很多亮点值得学习借鉴，准备在下一个 keynote 中就用上。自我提升就是这样，路漫漫，一点一滴积累。

• word 截图板式，缩略图
• 偏差分析将问题放大，提升到二级标题（让人重视），再将原因按列表展示（体现自己的深入思考）
• 工作成果贴图样式：散开
• 整体架构图、流程图：定位并明确自己的工作再整体中的位置
• …

太诱人了…😭😭😭

将 Markdown 格式的文章 copy 到微信公众号里面，涉及到代码片段的地方，总是各种格式问题，快整疯了...

一定是我没有找到技巧，那个 best practice 到底是啥呢？

回头我再试试其他的转换工具。

人生啊...

为啥有了各类编辑器之后，还有 Markdown 的生存空间？因为对于普通文字工作者（比如写博客，微信公众号）来说，Markdown 比 Office 套件，Html 要简单的多，语法不多，上手快。当然，像画图这种稍微复杂的功能，一般人我估计也不用。

这本书没有看完，只是翻完了，重点看了第 1-2 章，后续几章快速翻阅了一下，Typora、VS Code、以及各类笔记 APP 都有所了解，平时主要使用有道云笔记，其他的如果有需要再来翻阅或搜索一下。

reveal.js 没听说过，涨姿势了。用 GitHub Pages 写博客，再绑定一个域名转发，太赞了。可惜呀，访问 GitHub 经常…另外，经常看到网上有 GitBook 电子书，这也是一个多人协作写书的不错方案。

最后，了解了 Markdown 的演进过程，现在基本上都在用 GFM (GitHub Flavored Markdown)：https://github.github.com/gfm/

一件事情，你必须把它抽象化，因为抽象化之后才可以简化，简化后才可以标准化，标准化的事情才能自动化，自动化的事情才能规模化。

具体（样例）--> 抽象（模型）--> 简单 --> 标准（流程）--> 自动（程序）--> 规模

为什么 utf-8 编码不存在字节序问题？

因为字节序问题只在字符编码超过 8bit（即 1 byte）时才存在。

utf-16 一次性要编解码两个字节，所以需要考虑字节序问题，因为取值结果不同。

举例：0x1021

• 用大端序存储是：0x10（低位）0x21（高位）
• 用小端序存储是：0x21（低位）0x10（高位）

而 utf-8 编码是按单字节处理的，每次处理只操作一个字节，然后视情况决定是否取下一字节，所以不管是大端序，还是小端序，存储都是：0x10（低位）0x21（高位）。

UTF-8 编码方案已经成为 Unicode 字符编码方案的事实标准，各个平台、浏览器等默认均使用 UTF-8 编码方案对 Unicode 字符进行编、解码。Go 语言也不例外，采用了 UTF-8 编码方案存储 Unicode 字符.

unicode 符号范围 | utf-8 编码方式
00000000 ~ 0000007F | 0xxxxxxx 
00000080 ~ 000007FF | 110xxxxx 10xxxxxx 
00000800 ~ 0000FFFF | 1110xxxx 10xxxxxx 10xxxxxx 
00010000 ~ 0010FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

总结下来，针对 utf-8，编码规则其实只有两条：

• 单字节规则： 对于单字节的符号，字节的第一位（最高位）设为 0，后面 7 位为这个符号的 unicode 码。
• n字节规则： 对于 n 字节的符号（n>1），第一个字节的前 n 位都设为 1，第 n+1 位设为 0，后面字节的前两位一律设为 10。剩下的没有提及的二进制位，全部为这个符号的 unicode 码。

在 go 语言中，一个文件夹下面只能有一个 package，否则无法编译通过，但如果我们在一个文件夹下面编写测试代码（如 xxx_test.go)，package 名称为 xxx_test，代码是可以编译通过的。也就是说，go 官方为了单元测试开了小灶，让两个 package 可以在一个文件夹下共存，这足以说明单元测试的重要性。

论单元测试的重要性，应该将其看作比开发正式运行的业务代码还要重要。为什么会有 TDD 这种开发理念呢？测试驱动开发，意思是先写测试，再写开发。这样做的好处是用测试来验证架构设计，如果你写测试的时候发现不知道怎么测试某个接口或函数（或构建测试入参很麻烦），那么这个接口或函数设计就有问题。每当测试一个接口或函数时，我们都要构建上下文参数，当构建这些很麻烦时，就说明业务依赖的太多了，耦合严重。此时就可以反过来推导我们原先的设计是有问题的。

从另一个角度来说，如果我们把每个接口和函数的单元测试都通过了，由这些函数组成的业务服务自然也是可靠的。数学是可证明的，物理不可证明，只能证伪，而计算机跟自然科学一样，只能证伪，不能被证明。也就是说，如果一个业务由 10 个函数构成，如果这 10 个函数都测试没问题，那么这个业务从整体上来看也是比较可靠的，但我们没法证明它 100% 没问题。反过来，如果测试这个业务没问题，能保证其内部的 10 个函数靠谱吗？不能。所以，我们要先测试小接口小函数，测试通过后，再测试这个业务整体。