coding in a complicated world
pagefile.sys：Windows 的交换（SWAP）文件。默认在 C 盘根目录，和内存一样大，可以在“高级系统设置”中更改其位置和大小。hiberfil.sys：休眠模式系统状态转储文件。一般也会有几个 G。swapfile.sys：Win10 引入，作用和 pagefile.sys 相同，但他的大小可以自动调整。desktop.ini：文件夹配置文件（隐藏文件），用于自定义文件夹的外观和行为。thumbs.db：缩略图缓存文件（隐藏文件），用于加快文件夹中图像文件的显示速度。ntuser.dat：用户配置文件（隐藏文件），包含了用户的注册表设置和个人偏好。boot.ini：启动配置文件，用于指定启动选项和操作系统位置。# sudo yum remove docker \
# docker-client \
# docker-client-latest \
# docker-common \
# docker-latest \
# docker-latest-logrotate \
# docker-logrotate \
# docker-engine
# 检查是否有旧的安装
yum list installed | grep docker
sudo yum remove ...
sudo yum install -y yum-utils
# 使用国内镜像
# sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
yum list docker-ce --showduplicates | sort -r
sudo yum install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
用户视角：
管理视角：
架构视角：
功能视角：
开发视角：
假设有这么一个项目组，共 5 个人，开发了一个项目，由 10 个服务组成的一个项目管理系统。
基于这套系统，又封装成了两个产品，分别面向开发团队和一般团队。
一个团队，一个项目，一个系统，两个产品。
后来业务发展、商务合作、法务合规的缘故，项目组另外再部署一套一模一样的系统，专门为某个客户服务。
一个团队，一个项目，两套系统，三个产品。
再后来，这套专有系统持续创造较大的利润，项目组为他另外开一个新的项目进行管理，需求、开发进度等等都独立开来。但是还是这个团队来做。
一个团队，两个项目，两套系统，三个产品。
这个逻辑有问题么？
logging 内部的服务级别：
DEBUG 10
INFO 20
WARNING 30
ERROR 40
CRITICAL 50
根据使用习惯，INFO 是重要信息，DEBUG 是普通信息。线上也是开到 DEBUG 级别。
然后调试信息也是通过 DEBUG 服务打印，然后通过 conf.DEBUG_MODE 来区分是不是要打印这种 DEBUG 级别的调试信息。
觉得不甚方便，想了一下，有两种思路：
方案一感觉相对合理一些，但是对于已有项目还是方案二好。
def trace(self, message, *args, **kwargs):
if self.isEnabledFor(TRACE):
self._log(TRACE, message, args, **kwargs)
TRACE = logging.TRACE = 5
logging.addLevelName(TRACE, 'TRACE')
logging.Logger.trace = trace
| 符号 | Unicode码(Hex) | 名字 |
|---|---|---|
| ✓ | U+2713 | CHECK MARK（勾号） |
| ✔ | U+2714 | HEAVY CHECK MARK（粗勾号） |
| ☐ | U+2610 | BALLOT BOX（方格） |
| ☑ | U+2611 | BALLOT BOX WITH CHECK（打勾方格） |
| √ | U+221A | Square Root (开平方，根号) |
常用英文字母 x / X 或者数学中的乘法替代。
| 符号 | Unicode码(Hex) | 名称 |
|---|---|---|
| ✗ | U+2717 | BALLOT X (交叉) |
| ✘ | U+2718 | HEAVY BALLOT X (粗体交叉) |
| ☐ | U+2610 | BALLOT BOX (方格) |
| ☒ | U+2612 | BALLOT BOX WITH X (带交叉方格) |
| × | U+00D7 | 乘法符号 |
| ⨯ | U+2A2F | 向量积 |
| ✕ | U+2715 | Multiplication (乘法符号) |
| ☓ | U+2613 | Saltire |
| ✖ | U+2716 | Heavy Multiplication X Emoji |
| ㄨ | U+3128 | Bopomofo Letter U |
| Ⅹ | U+2169 | Ⅹ Roman Numeral Ten |
| 符号 | Unicode码(Hex) | 名字 |
|---|---|---|
| ○ | U+25CB | WHITE CIRCLE |
| ● | U+25CF | BLACK CIRCLE |
| ◯ | U+25EF | LARGE CIRCLE |
网上的大多数职业建议，都来自那些取得了巨大成就的人。所有这些建议都没有充分考虑运气的因素，实际上很多人运气不好，事业受到了很大影响。
现在，很多企业陷入了困境，我就在一家这样的科技公司工作了两年。回顾这两年，我总结了几点经验教训。如果你的职业生涯也遇到了坏运气，不妨可以参考一下：
更多内容在英文原版中：Career advice for people with bad luck
滑坡谬误（Slippery slope）指的是使用一连串的因果推论，夸大了每个环节的因果强度，而得到不合理的结论。
它的典型形式是，"如果发生 A1，接着就会发生 A2，接着就会发生 A3，接着就会发生 A4，......，接着就会发生 An"，然后推论"由于 An 不应该发生，因此我们不应允许 A1 发生"。
从 A1 推论至 An 的过程就像一个滑坡。
它的问题在于，每个"坡"的因果强度不一，有些因果关系只是可能、而非必然，有些因果关系相当微弱，有些因果关系甚至是未知或缺乏证据，因而即使 A 1发生，也无法一路滑到 An，An 并非必然发生。
若有充足证据显示每个"坡"都有合理、强烈的因果连结，即不构成滑坡谬误。
例一：如果我今天借了10元给小明，他明天又会跟我借一百元，接下来就借一千元、一万元，我岂不破产？
小明今天借十元也不表示明天就会借一百元，就算明天借一百元也不表示以后就会借一千元，就算小明借一千元甚至一万元，也不表示说话者就会破产。
例二：孩子如果不上好的小学，就考不上好的中学，之后就考不进好的大学，接着会找不到好的工作，然后会穷困潦倒，一生就毁了！
孩子如果不上好的小学，也不表示之后就考不上好的中学；就算考不上好的中学，也不表示就考不进好的大学;就算考不进好的大学，也不表示就找不到好的工作；就算找不到好的工作，也不表示会穷困潦倒；就算穷困潦倒，也不表示一生就毁了。
例三：员工偷懒公司便会损失，公司赚不到钱就要裁员，被裁员的人会没工作，没工作的人为了生计就会铤而走险。因此，上班偷懒是非常严重的问题。
公司损失不表示公司会赚不到钱，就算公司赚不到钱也不表示公司就要裁员，就算公司裁员也不表示被裁的人会走投无路，就算被裁的人走投无路，也不表示会为了生计铤而走险。
其他关联组件：
Microsoft Office 的云上版本，提供了更多功能。
StarOffice -> OpenOffice -> LibreOffice
参考：https://en.wikipedia.org/wiki/Apache_OpenOffice
https://en.wikipedia.org/wiki/OnlyOffice
毛子项目，AGPL 协议开源，原名 TeamLab。在俄罗斯，以 P7-Office 为名。
URL / URI 的设计中规定允许的字符，如果出现了其他字符就需要转义，这套规则被称之为百分号编码（Percent-encoding）。
WWW 的设计中就使用了这套规则，比如 URL 地址、和表单提交（application/x-www-form-urlencoded）等场景，所以这个编码规则也被称之为 URL 编码（URL encoding）。
编程时，编码解码操作一般就叫 urlencode，urldecode。
编码的方式非常简单，就是把字节用 16 进制的方式表示，然后每个字节前面加一个百分号。
查看文档（手动替换文档编号）：
搜索：