Using OpenCC to convert from zh-cn to zh-tw

Pipfile

@@ -0,0 +1,13 @@
+[[source]]
+url = "https://pypi.org/simple"
+verify_ssl = true
+name = "pypi"
+
+[packages]
+opencc = "*"
+click = "*"
+
+[dev-packages]
+
+[requires]
+python_version = "3.6"

translate.py

@@ -0,0 +1,63 @@
+"""Convert zh-cn to zh-tw
+Refer to https://github.com/BYVoid/OpenCC
+"""
+import click
+import opencc
+
+from pathlib import Path
+from pprint import pprint
+
+
+@click.group()
+def cli():
+    pass
+
+
+def convert(infile: str, outfile: str, cfg: str):
+    """read >> convert >> write file
+    Args:
+        infile (str): input file
+        outfile (str): output file
+        cfg (str): config
+    """
+    converter = opencc.OpenCC(cfg)
+    with open(infile, "r") as inf, open(outfile, "w+") as outf:
+        data = inf.readlines()
+        data = list(map(converter.convert, data))
+        outf.writelines(data)
+    print(f"Convert to {outfile}")
+
+
+@cli.command()
+@click.option("-i", "--input", "infile", required=True)
+@click.option("-o", "--output", "outfile", required=True)
+@click.option("-c", "--config", "cfg", required=True, default="s2twp.json")
+def file(infile: str, outfile: str, cfg: str):
+    """read >> convert >> write file
+    Args:
+        infile (str): input file
+        outfile (str): output file
+        cfg (str): config
+    """
+    convert(infile, outfile, cfg)
+
+
+@cli.command()
+@click.option("-i", "--input", "infolder", required=True)
+@click.option("-o", "--output", "outfolder", required=True)
+@click.option("-c", "--config", "cfg", required=True, default="s2twp.json")
+def repo(infolder, outfolder, cfg):
+    if not Path(outfolder).exists():
+        Path(outfolder).mkdir(parents=True)
+        print(f"Create {outfolder}")
+    infiles = Path(infolder).resolve().glob("*.md")
+    pair = [
+        {"infile": str(infile), "outfile": str(Path(outfolder).resolve() / infile.name)}
+        for idx, infile in enumerate(infiles)
+    ]
+    for p in pair:
+        convert(p["infile"], p["outfile"], cfg)
+
+
+if __name__ == "__main__":
+    cli()

ch1.md → zh-cn/ch1.md

@@ -1,6 +1,6 @@
 # 第一章：可靠性，可扩展性，可维护性
 
-![](img/ch1.png)
+![](../img/ch1.png)
 
 > 互联网做得太棒了，以至于大多数人将它看作像太平洋这样的自然资源，而不是什么人工产物。上一次出现这种大规模且无差错的技术， 你还记得是什么时候吗？
 >
@@ -40,9 +40,9 @@
 
 ​	其次，越来越多的应用程序有着各种严格而广泛的要求，单个工具不足以满足所有的数据处理和存储需求。取而代之的是，总体工作被拆分成一系列能被单个工具高效完成的任务，并通过应用代码将它们缝合起来。
 
-​	例如，如果将缓存（应用管理的缓存层，Memcached或同类产品）和全文搜索（全文搜索服务器，例如Elasticsearch或Solr）功能从主数据库剥离出来，那么使缓存/索引与主数据库保持同步通常是应用代码的责任。[图1-1](img/fig1-1.png) 给出了这种架构可能的样子（细节将在后面的章节中详细介绍）。
+​	例如，如果将缓存（应用管理的缓存层，Memcached或同类产品）和全文搜索（全文搜索服务器，例如Elasticsearch或Solr）功能从主数据库剥离出来，那么使缓存/索引与主数据库保持同步通常是应用代码的责任。[图1-1](../img/fig1-1.png) 给出了这种架构可能的样子（细节将在后面的章节中详细介绍）。
 
-![](img/fig1-1.png)
+![](../img/fig1-1.png)
 
 **图1-1 一个可能的组合使用多个组件的数据系统架构**
 
@@ -174,7 +174,7 @@
 
 大体上讲，这一对操作有两种实现方式。
 
-1. 发布推文时，只需将新推文插入全局推文集合即可。当一个用户请求自己的主页时间线时，首先查找他关注的所有人，查询这些被关注用户发布的推文并按时间顺序合并。在如[图1-2](img/fig1-2.png)所示的关系型数据库中，可以编写这样的查询：
+1. 发布推文时，只需将新推文插入全局推文集合即可。当一个用户请求自己的主页时间线时，首先查找他关注的所有人，查询这些被关注用户发布的推文并按时间顺序合并。在如[图1-2](../img/fig1-2.png)所示的关系型数据库中，可以编写这样的查询：
 
     ```sql
     SELECT tweets.*, users.*
@@ -183,13 +183,13 @@
       JOIN follows ON follows.followee_id = users.id
       WHERE follows.follower_id = current_user
     ```
-    ![](img/fig1-2.png)
+    ![](../img/fig1-2.png)
 
     **图1-2 推特主页时间线的关系型模式简单实现**
 
-2. 为每个用户的主页时间线维护一个缓存，就像每个用户的推文收件箱（[图1-3](img/fig1-3.png)）。 当一个用户发布推文时，查找所有关注该用户的人，并将新的推文插入到每个主页时间线缓存中。 因此读取主页时间线的请求开销很小，因为结果已经提前计算好了。
+2. 为每个用户的主页时间线维护一个缓存，就像每个用户的推文收件箱（[图1-3](../img/fig1-3.png)）。 当一个用户发布推文时，查找所有关注该用户的人，并将新的推文插入到每个主页时间线缓存中。 因此读取主页时间线的请求开销很小，因为结果已经提前计算好了。
 
-    ![](img/fig1-3.png)
+    ![](../img/fig1-3.png)
 
     **图1-3 用于分发推特至关注者的数据流水线，2012年11月的负载参数【16】**
 
@@ -220,9 +220,9 @@
 
 ​	即使不断重复发送同样的请求，每次得到的响应时间也都会略有不同。现实世界的系统会处理各式各样的请求，响应时间可能会有很大差异。因此我们需要将响应时间视为一个可以测量的数值**分布（distribution）**，而不是单个数值。
 
-​	在[图1-4](img/fig1-4.png)中，每个灰条表代表一次对服务的请求，其高度表示请求花费了多长时间。大多数请求是相当快的，但偶尔会出现需要更长的时间的异常值。这也许是因为缓慢的请求实质上开销更大，例如它们可能会处理更多的数据。但即使（你认为）所有请求都花费相同时间的情况下，随机的附加延迟也会导致结果变化，例如：上下文切换到后台进程，网络数据包丢失与TCP重传，垃圾收集暂停，强制从磁盘读取的页面错误，服务器机架中的震动【18】，还有很多其他原因。
+​	在[图1-4](../img/fig1-4.png)中，每个灰条表代表一次对服务的请求，其高度表示请求花费了多长时间。大多数请求是相当快的，但偶尔会出现需要更长的时间的异常值。这也许是因为缓慢的请求实质上开销更大，例如它们可能会处理更多的数据。但即使（你认为）所有请求都花费相同时间的情况下，随机的附加延迟也会导致结果变化，例如：上下文切换到后台进程，网络数据包丢失与TCP重传，垃圾收集暂停，强制从磁盘读取的页面错误，服务器机架中的震动【18】，还有很多其他原因。
 
-![](img/fig1-4.png)
+![](../img/fig1-4.png)
 
 **图1-4 展示了一个服务100次请求响应时间的均值与百分位数**
 
@@ -232,7 +232,7 @@
 
 ​	如果想知道典型场景下用户需要等待多长时间，那么中位数是一个好的度量标准：一半用户请求的响应时间少于响应时间的中位数，另一半服务时间比中位数长。中位数也被称为第50百分位点，有时缩写为p50。注意中位数是关于单个请求的；如果用户同时发出几个请求（在一个会话过程中，或者由于一个页面中包含了多个资源），则至少一个请求比中位数慢的概率远大于50％。
 
-​	为了弄清异常值有多糟糕，可以看看更高的百分位点，例如第95、99和99.9百分位点（缩写为p95，p99和p999）。它们意味着95％，99％或99.9％的请求响应时间要比该阈值快，例如：如果第95百分位点响应时间是1.5秒，则意味着100个请求中的95个响应时间快于1.5秒，而100个请求中的5个响应时间超过1.5秒。如[图1-4](img/fig1-4.png)所示。
+​	为了弄清异常值有多糟糕，可以看看更高的百分位点，例如第95、99和99.9百分位点（缩写为p95，p99和p999）。它们意味着95％，99％或99.9％的请求响应时间要比该阈值快，例如：如果第95百分位点响应时间是1.5秒，则意味着100个请求中的95个响应时间快于1.5秒，而100个请求中的5个响应时间超过1.5秒。如[图1-4](../img/fig1-4.png)所示。
 
 ​	响应时间的高百分位点（也称为**尾部延迟（tail latencies）**）非常重要，因为它们直接影响用户的服务体验。例如亚马逊在描述内部服务的响应时间要求时以99.9百分位点为准，即使它只影响一千个请求中的一个。这是因为请求响应最慢的客户往往也是数据最多的客户，也可以说是最有价值的客户 —— 因为他们掏钱了【19】。保证网站响应迅速对于保持客户的满意度非常重要，亚马逊观察到：响应时间增加100毫秒，销售量就减少1％【20】；而另一些报告说：慢 1 秒钟会让客户满意度指标减少16%【21，22】。
 
@@ -246,13 +246,13 @@
 
 > #### 实践中的百分位点
 >
-> ​	在多重调用的后端服务里，高百分位数变得特别重要。即使并行调用，最终用户请求仍然需要等待最慢的并行调用完成。如[图1-5](img/fig1-5.png)所示，只需要一个缓慢的调用就可以使整个最终用户请求变慢。即使只有一小部分后端调用速度较慢，如果最终用户请求需要多个后端调用，则获得较慢调用的机会也会增加，因此较高比例的最终用户请求速度会变慢（效果称为尾部延迟放大【24】）。
+> ​	在多重调用的后端服务里，高百分位数变得特别重要。即使并行调用，最终用户请求仍然需要等待最慢的并行调用完成。如[图1-5](../img/fig1-5.png)所示，只需要一个缓慢的调用就可以使整个最终用户请求变慢。即使只有一小部分后端调用速度较慢，如果最终用户请求需要多个后端调用，则获得较慢调用的机会也会增加，因此较高比例的最终用户请求速度会变慢（效果称为尾部延迟放大【24】）。
 >
 > ​	如果您想将响应时间百分点添加到您的服务的监视仪表板，则需要持续有效地计算它们。例如，您可能希望在最近10分钟内保持请求响应时间的滚动窗口。每一分钟，您都会计算出该窗口中的中值和各种百分数，并将这些度量值绘制在图上。
 >
 > ​	简单的实现是在时间窗口内保存所有请求的响应时间列表，并且每分钟对列表进行排序。如果对你来说效率太低，那么有一些算法能够以最小的CPU和内存成本（如前向衰减【25】，t-digest【26】或HdrHistogram 【27】）来计算百分位数的近似值。请注意，平均百分比（例如，减少时间分辨率或合并来自多台机器的数据）在数学上没有意义 - 聚合响应时间数据的正确方法是添加直方图【28】。
 
-![](img/fig1-5.png)
+![](../img/fig1-5.png)
 
 **图1-5 当一个请求需要多个后端请求时，单个后端慢请求就会拖慢整个终端用户的请求**
 
@@ -376,7 +376,7 @@
 
 ​	不幸的是，使应用可靠、可扩展或可维护并不容易。但是某些模式和技术会不断重新出现在不同的应用中。在接下来的几章中，我们将看到一些数据系统的例子，并分析它们如何实现这些目标。
 
-​	在本书后面的[第三部分](part-iii.md)中，我们将看到一种模式：几个组件协同工作以构成一个完整的系统（如[图1-1](img/fig1-1.png)中的例子）
+​	在本书后面的[第三部分](part-iii.md)中，我们将看到一种模式：几个组件协同工作以构成一个完整的系统（如[图1-1](../img/fig1-1.png)中的例子）