coding in a complicated world
git log --grep=fix: --oneline --after='2018-07-01' --author=markjour
git grep -C3 sign_position $(git rev-list --all)
git log -G'前置'
git log -G'前置' -p | grep '前置' -C5
git log -G'前置' --oneline --name-status
-S<string> --pickaxe-regex 和 -G<regex> 作用相近，
不过 -S 只会列出搜索内容增删的相关信息，也就是所在行修改了，但是搜索内容没有变化的会忽略
https://github.com/chubin/wttr.in
curl wttr.in/wuhan
curl wttr.in/wuhan?lang=zh
curl wttr.in/jiangxia?lang=zh
# 指定日期
curl wttr.in/jiangxia@2020-06-07?lang=zh
View options:
0 # only current weather
1 # current weather + today's forecast
2 # current weather + today's + tomorrow's forecast
A # ignore User-Agent and force ANSI output format (terminal)
F # do not show the "Follow" line
n # narrow version (only day and night)
q # quiet version (no "Weather report" text)
Q # superquiet version (no "Weather report", no city name)
T # switch terminal sequences off (no colors)
指定 view:
# 只看今天的天气
# 不显示颜色
curl "wttr.in/jiangxia?0T&lang=zh"
Tkinter 可以认为是 Python 官方支持的 GUI 框架，接近标准库的地位，样式风格就是极简。
基于 Tcl/Tk。
PyQt Riverbank Computing 提供的第三方 Python 绑定，非常知名。
风险：GPL 协议，并不是和 Qt 一样的 LGPL。也就是说，使用 PyQt 开发的软件必须开源，除非购买商业授权。特别不建议使用。
没有看到 GitHub 仓库。
PySide Qt 官方 Python 绑定，也叫 Qt for Python。
据说当年 Qt 的持有者，Nokia 公司，找 Riverbank Computing 谈 PyQt 的授权问题，没有谈成，因而从新开发了这个项目。
没有 GitHub 仓库，代码可以在 官方 cgit 上看到。
注意：这里就指 pyside2，和更老的 pyside 区分开来。
PyGObject GTK 官方 Python 绑定
原来叫 PyGTK，多好，不知道为什么改成这个名字
https://gitlab.gnome.org/GNOME/pygobject
https://github.com/GNOME/pygobject
基于 Web 技术gooey 
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元给小明，他明天又会跟我借一百元，接下来就借一千元、一万元，我岂不破产？
小明今天借十元也不表示明天就会借一百元，就算明天借一百元也不表示以后就会借一千元，就算小明借一千元甚至一万元，也不表示说话者就会破产。
例二：孩子如果不上好的小学，就考不上好的中学，之后就考不进好的大学，接着会找不到好的工作，然后会穷困潦倒，一生就毁了！
孩子如果不上好的小学，也不表示之后就考不上好的中学；就算考不上好的中学，也不表示就考不进好的大学;就算考不进好的大学，也不表示就找不到好的工作；就算找不到好的工作，也不表示会穷困潦倒；就算穷困潦倒，也不表示一生就毁了。
例三：员工偷懒公司便会损失，公司赚不到钱就要裁员，被裁员的人会没工作，没工作的人为了生计就会铤而走险。因此，上班偷懒是非常严重的问题。
公司损失不表示公司会赚不到钱，就算公司赚不到钱也不表示公司就要裁员，就算公司裁员也不表示被裁的人会走投无路，就算被裁的人走投无路，也不表示会为了生计铤而走险。