diff --git a/translated/tech/20170116 Using the AWS SDK for Gos Regions and Endpoints Metadata.md b/published/20170116 Using the AWS SDK for Gos Regions and Endpoints Metadata.md
similarity index 52%
rename from translated/tech/20170116 Using the AWS SDK for Gos Regions and Endpoints Metadata.md
rename to published/20170116 Using the AWS SDK for Gos Regions and Endpoints Metadata.md
index aa7564e8e3..7805a6d6a1 100644
--- a/translated/tech/20170116 Using the AWS SDK for Gos Regions and Endpoints Metadata.md
+++ b/published/20170116 Using the AWS SDK for Gos Regions and Endpoints Metadata.md
@@ -1,20 +1,17 @@
-使用AWS的GO SDK获取区域与终端节点信息
+使用 AWS 的 GO SDK 获取区域与终端节点信息
============================================================
-
+LCTT 译注： 终端节点（Endpoint），详情请见: [http://docs.amazonaws.cn/general/latest/gr/rande.html](http://docs.amazonaws.cn/general/latest/gr/rande.html)
-译注: Endpoint(终端节点)[详情请见: http://docs.amazonaws.cn/general/latest/gr/rande.html](http://docs.amazonaws.cn/general/latest/gr/rande.html)
+最新发布的 GO 的 SDK [v1.6.0][1] 版本，加入了获取区域与终端节点信息的功能。它可以很方便地列出区域、服务和终端节点的相关信息。可以通过 [github.com/aws/aws-sdk-go/aws/endpoints][3] 包使用这些功能。
-最新发布的GO的SDK[v1.6.0][1]版本, 加入了获取区域与终端节点信息的功能. 它可以很方便地列出区域, 服务 和终端节点的相关信息.可以通过[github.com/aws/aws-sdk-go/aws/endpoints][3]包使用这些功能.
-
-endpoints包提供了一个易用的接口,可以获取到一个服务的终端节点的url列表和区域列表信息.并且我们将相关信息根据AWS服务区域进行了分组,如 AWS 标准, AWS 中国, and AWS GovCloud (美国).
+endpoints 包提供了一个易用的接口，可以获取到一个服务的终端节点的 url 列表和区域列表信息。并且我们将相关信息根据 AWS 服务区域进行了分组，如 AWS 标准、AWS 中国和 AWS GovCloud（美国）。
### 解析终端节点
-设置SDK的默认配置时, SDK会自动地使用endpoints.DefaultResolver函数. 你也可以自己调用包中的EndpointFor方法来解析终端节点.
+设置 SDK 的默认配置时， SDK 会自动地使用 `endpoints.DefaultResolver` 函数。你也可以自己调用包中的`EndpointFor` 方法来解析终端节点。
-Go
-```
+```Go
// 解析在us-west-2区域的S3服务的终端节点
resolver := endpoints.DefaultResolver()
endpoint, err := resolver.EndpointFor(endpoints.S3ServiceID, endpoints.UsWest2RegionID)
@@ -26,12 +23,12 @@ if err != nil {
fmt.Println("Resolved URL:", endpoint.URL)
```
-如果你需要自定义终端节点的解析逻辑,你可以实现endpoints.Resolver接口, 并传值给aws.Config.EndpointResolver. 当你打算编写自定义的终端节点逻辑,让sdk可以用来解析服务的终端节点时候,这个功能就会很有用.
+如果你需要自定义终端节点的解析逻辑，你可以实现 `endpoints.Resolver` 接口，并传值给`aws.Config.EndpointResolver`。当你打算编写自定义的终端节点逻辑，让 SDK 可以用来解析服务的终端节点时候，这个功能就会很有用。
-以下示例, 创建了一个配置好的Session, 然后[Amazon S3][4]服务的客服端就可以使用这个自定义的终端节点.
+以下示例，创建了一个配置好的 Session，然后 [Amazon S3][4] 服务的客户端就可以使用这个自定义的终端节点。
-Go
-```
+
+```Go
s3CustResolverFn := func(service, region string, optFns ...func(*endpoints.Options)) (endpoints.ResolvedEndpoint, error) {
if service == "s3" {
return endpoints.ResolvedEndpoint{
@@ -52,10 +49,9 @@ sess := session.Must(session.NewSessionWithOptions(session.Options{
### 分区
-endpoints.DefaultResolver函数的返回值可以被endpoints.EnumPartitions接口使用.这样就可以获取SDK使用的分区片段，也可以列出每个分区的分区信息。
+`endpoints.DefaultResolver` 函数的返回值可以被 `endpoints.EnumPartitions`接口使用。这样就可以获取 SDK 使用的分区片段，也可以列出每个分区的分区信息。
-Go
-```
+```Go
// 迭代所有分区表打印每个分区的ID
resolver := endpoints.DefaultResolver()
partitions := resolver.(endpoints.EnumPartitions).Partitions()
@@ -65,10 +61,9 @@ for _, p := range partitions {
}
```
-除了分区表之外, endpoints包也提供了每个分区组的getter函数. 这些工具函数可以方便列出指定分区,而不用执行默认解析器列出所有的分区.
+除了分区表之外，endpoints 包也提供了每个分区组的 getter 函数。这些工具函数可以方便列出指定分区，而不用执行默认解析器列出所有的分区。
-Go
-```
+```Go
partition := endpoints.AwsPartition()
region := partition.Regions()[endpoints.UsWest2RegionID]
@@ -78,19 +73,18 @@ for id, _ := range region.Services() {
}
```
-当你获取区域和服务值后, 可以调用ResolveEndpoint. 这样解析端点时,就可以提供分区的过滤视图.
+当你获取区域和服务值后，可以调用 `ResolveEndpoint`。这样解析端点时，就可以提供分区的过滤视图。
-获取更多AWS SDK for GO信息, 请关注[开源库][5]. 若你有更好的看法,请留言评论.
+获取更多 AWS SDK for GO 信息, 请关注[其开源仓库][5]。若你有更好的看法，请留言评论。
-
--------------------------------------------------------------------------------
via: https://aws.amazon.com/cn/blogs/developer/using-the-aws-sdk-for-gos-regions-and-endpoints-metadata
-作者：[ Jason Del Ponte][a]
+作者：[Jason Del Ponte][a]
译者：[Vic020](http://vicyu.com)
-校对：[校对者ID](https://github.com/校对者ID)
+校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
diff --git a/translated/tech/20161216 The truth about traditional JavaScript benchmarks.md b/translated/tech/20161216 The truth about traditional JavaScript benchmarks.md
index 1a4b281fda..5b0ea6b2de 100644
--- a/translated/tech/20161216 The truth about traditional JavaScript benchmarks.md
+++ b/translated/tech/20161216 The truth about traditional JavaScript benchmarks.md
@@ -1,29 +1,35 @@
探索传统 JavaScript 基准测试
============================================================
-可以很公平地说，[JavaScript][22] 是当下软件工程最重要的技术。对于那些深入接触过编程语言、编译器和虚拟机的人来说，这仍然有点令人惊讶，因为在语言设计者看来，JavaScript 不是十分优雅；在编译器工程师看来，它没有多少可优化的地方；而且还没有一个伟大的标准库。这取决于你和谁吐槽，JavaScript 的缺点你花上数周都枚举不完，不过你总会找到一些你从所未知的神奇的东西。尽管这看起来明显困难重重，不过 JavaScript 还是成为当今 web 的核心，并且还成为服务器端/云端的主导技术（通过 [Node.js][23]），甚至还开辟了进军物联网空间的道路。
+可以很公平地说，[JavaScript][22] 是当下软件工程最重要的技术。对于那些深入接触过编程语言、编译器和虚拟机的人来说，这仍然有点令人惊讶，因为在语言设计者们看来，JavaScript 不是十分优雅；在编译器工程师们看来，它没有多少可优化的地方；而且还没有一个伟大的标准库。这取决于你和谁吐槽，JavaScript 的缺点你花上数周都枚举不完，不过你总会找到一些你从所未知的神奇的东西。尽管这看起来明显困难重重，不过 JavaScript 还是成为了当今 web 的核心，并且还（通过 [Node.js][23]）成为服务器端/云端的主导技术，甚至还开辟了进军物联网空间的道路。
-问题来了，为什么 JavaScript 如此受欢迎？或者说如此成功？我知道没有一个很好的答案。如今我们有许多使用 JavaScript 的好理由，或许最重要的是围绕其构建的庞大的生态系统，以及今天大量可用的资源。但所有这一切实际上是发展到一定程度的后果。为什么 JavaScript 变得流行起来了？嗯，你或许会说，这是 web 多年来的通用语了。但是在很长一段时间里，人们极其讨厌 JavaScript。回顾过去，似乎第一波 JavaScript 浪潮爆发在上个年代的后半段。不出所料，那个时候 JavaScript 引擎加速了各种不同的任务的执行，这可能让很多人对 JavaScript 刮目相看。
+问题来了，为什么 JavaScript 如此受欢迎？或者说如此成功？我知道没有一个很好的答案。如今我们有许多使用 JavaScript 的好理由，或许最重要的是围绕其构建的庞大的生态系统，以及今天大量可用的资源。但所有这一切实际上是发展到一定程度的后果。为什么 JavaScript 变得流行起来了？嗯，你或许会说，这是 web 多年来的通用语了。但是在很长一段时间里，人们极其讨厌 JavaScript。回顾过去，似乎第一波 JavaScript 浪潮爆发在上个年代的后半段。那个时候 JavaScript 引擎加速了各种不同的任务的执行，很自然的，这可能让很多人对 JavaScript 刮目相看。
-回到过去那些日子，这些加速测试使用了现在所谓的传统 JavaScript 基准——从苹果的 [SunSpider 基准][24]（JavaScript 微基准之母）到 Mozilla 的 [Kraken 基准][25] 和谷歌的 V8 基准。后来，V8 基准被 [Octane 基准][26] 取代，而苹果发布了新的 [JetStream 基准][27]。这些传统的 JavaScript 基准测试驱动了无数人的努力，使 JavaScript 的性能达到了本世纪初没人能预料到的水平。据报道加速达到了 1000 倍，一夜之间在网站使用 `