个人来说，一直希望能将《Go指南》这个项目的版本管理从 bitbucket 迁移到 github。但是由于上游英文源项目仍然在用 hg 作为版本管理工具所以一直也没有这么做。前几天 OlingCat 找我，希望将这个翻译项目放在 github 上的 go-zh 项目中。我当然欣然同意，虽然翻译工作还得用 hg 维护，但是 git 上能够有个镜像也是不错的事情。 （中间略过若干 hg –> git 的鸡零狗碎不说） 在等待同步的时候，我简单阅读了一下“Go 项目翻译规范”，发现一个让我觉得很不舒服的设定。
Tag Archives: 翻译
[翻译]理解 Go 语言的内存使用
许多人在刚开始接触 Go 语言时，经常会有的疑惑就是“为什么一个 Hello world 会占用如此之多的内存？”。Understanding Go Lang Memory Usage 很好的解释了这个问题。不过“简介”就是“简介”，更加深入的内容恐怕要读者自己去探索了。另外，文章写到最后，作者飘了，估计引起了一些公愤，于是又自己给自己补刀，左一刀，右一刀…… ————翻译分隔线———— 理解 Go 语言的内存使用 2014年12月22日，星期一 温馨提示：这仅是关于 Go 语言内存的简介，俗话说不入虎穴、焉得虎子，读者可以进行更加深入的探索。 大多数 Go 开发者都会尝试像这样简单的 hello world 程序： 然后他们就完全崩溃了。
[翻译]这根本不是 BASH 的 bug！
在前几天看到 CVE-2014-6277 这个 BASH 的 bug 的时候，我就觉得挺奇葩的：这这种明显是有意实现的功能怎么会存在这么大的安全隐患呢？我不是专门搞安全的，同时觉得，这个 bug 可能虽然影响广泛，但并不是什么很有技术含量的利用思路。所以我就把这个事情放下没去想它。然而，随之而来的国内国外的各种媒体宣传、安全专家的联名建议、茶余饭后的坊间畅谈……对于 BASH 的这个 bug 无人不认为是个大 bug。不少人为此还在幸灾乐祸……但是我却没从各种评论中找到我的问题的答案。 但是，当我看到这篇随笔时，我不得不赞同作者的观点：这根本不是 BASH 的 bug！ 所以我将原文翻译至此，希望能够带来一些思考。 也许我们今天看到的一个愚蠢的 bug，在历史上的某一天，是一个有意而为之的神奇特性。也许我们应该思考的不仅仅是这一刻的 bug 或者安全隐患本身，而是在软件项目这个极具工程和创作品双重特性的活动中，如何有效的保证某个特性不会变成 bug。所以什么规范了，文档了，可真得不是纸上谈兵！ 不过话说回来，无论如何，我仍然坚信：“Less is exponentially more!（大道至简）”少一点 Feature 或许就是少一点 Bug 呢？
《一意孤行》开源编程游戏汉化版
经过一段时间的工作（其实没花多少时间），我很高兴的跟大家介绍开源编程游戏 Untrusted 的汉化版：《一意孤行》正式发布了。 该游戏讲述了一个研究人工智能的教授 Dr. Eval。面对各种挑战，不断前行的故事。好玩的地方在于，每一关，都需要玩家修改不同的 JavaScript 代码来改变逻辑，让角色到达出口。通关这个游戏除了需要玩家有一定的编程知识之外，还要有丰富的想象力和创造力。同时，如果对人工智能的基本原理有所了解，也能让通关过程事半功倍。不过事实证明，代码民工干体力活也能通关的！:D 在线游戏 在线游戏
[翻译] channel 独木难支
原文在此。遗憾的是文章只提出了问题，并没明确提供如何解决这些问题。但无论如何，对于这种可以引起反思的文章，是不能放过的。另外，我得承认，似乎高层次的分布式系统的抽象，用函数式语言的范式来表述更容易一些（实现上其实未必）。 ————翻译分隔线———— channel 独木难支 或者说为什么流水线作业没那么容易 勇敢和聪明的 Golang 并发模型。 @kachayev 撰写 概述 Go 被设计用于更容易的构建并发系统，因此它有运行独立的计算的 goroutine 和用于它们之间通讯的 channel。我们之前都听过这个故事。所有的例子和指南看起来都挺好的：我们可以创建一个新的 channel，可以向这个 channel 发送数据，可以从 channel 读取，甚至还有漂亮和优雅的 select 语句（顺便提一下，为什么 21 世纪了我们还在用语句？），阻塞读和缓存…… 主旨：99% 的情况下，我其实并不关心响应是由 channel 传递的，还是一只魔法独角兽从它的角上带来的。
[翻译]面向工程师的分布式系统理论
如果一个工程师说起话来像 PhD. 走起路来像 PhD. 干起活來像 PhD. 那他是什么？ 他是一个懂理论的工程师…… 原文在此。 ————翻译分隔线———— 面向工程师的分布式系统理论 Gwen Shapira，系统工程师明星，现在是 Cloudera 的全职工程师，在 Twitter 上问了一个问题，引发了我的思考。 我以前可能这样回答“好吧，这里有 FLP 的论文，而这是 Paxor的论文，还有这是拜占庭将军的论文……”，并且我会列出一个长长的原材料的清单，如果你够快的话大概可以在六个月的时间里看一遍。但是，现在我觉得提供一大堆关于理论的论文对于学习分布式系统理论往往是错误的道路（除非你在读 PhD）。论文通常都很深奥，也很复杂，需要认真的学习，且便随着巨大成就的是丰富的经验，和相关的业务上下文。有什么是需要这样高等级的工程师专家的呢？ 不幸的是，与此同时，缺少一个好的能够通向这些汇总材料的“桥梁”，提炼并融汇分布式系统理论中重要的结论和思路；而一些进行这些总结的材料的难度又过大。在思考的时候，我又想到另外一个问题： 分布式系统工程师应当学习什么样的分布式系统理论？ 就这个例子来说，应当是没这么恐怖的、简单一些的理论。因此，我试着整理了一份我作为分布式系统工程师，每天的工作会应用到的一些基本概念的清单。我觉得这个清单应该足够支持分布式系统工程师设计新的系统。如果我漏掉了什么，务必告诉我！
[翻译]十条有用的 Go 技术
原文在此，实用总结。 ————翻译分隔线———— 十条有用的 Go 技术 这里是我过去几年中编写的大量 Go 代码的经验总结而来的自己的最佳实践。我相信它们具有弹性的。这里的弹性是指： 某个应用需要适配一个灵活的环境。你不希望每过 3 到 4 个月就不得不将它们全部重构一遍。添加新的特性应当很容易。许多人参与开发该应用，它应当可以被理解，且维护简单。许多人使用该应用，bug 应该容易被发现并且可以快速的修复。我用了很长的时间学到了这些事情。其中的一些很微小，但对于许多事情都会有影响。所有这些都仅仅是建议，具体情况具体对待，并且如果有帮助的话务必告诉我。随时留言:)
[翻译]冰激淋制造商和数据竞态
Dave 总是会给我们带来这种很浅显有趣，又意义深刻的文章。原文在此：Ice cream makers and data races。 ————翻译分隔线———— 冰激淋制造商和数据竞态 Dave Cheney 这是一篇关于数据竞态的文章。本文的相关代码在 Github 上：github.com/davecheney/benandjerry。 这个例子模拟了两个冰激淋制造商 Ben 和 Jerry 随机接待他们的客户。
[翻译]编译器(10)-编译到 C
原文在此。 ————翻译分隔线———— 编译器(10)-编译到 C 第一部分：介绍 第二部分：编译、转译和解释 第三部分：编译器设计概览 第四部分：语言设计概述 第五部分：Calc 1 语言规格说明书 第六部分：标识符 第七部分：扫描 第八部分：抽象语法树 第九部分：解析 终于到最后一个步骤了！ 我们的语言规格说明书如此简单，其实可以跳过 C 直接输出汇编。我有两个不这么做的原因。首先，移植性。在这个指引中，我无须编写任何特定架构的 C 代码。C 已经被移植到各种不同的系统中去了，因此可以让 C 编译器为我们做这个工作。 其次，对于许多程序员来说，汇编比起 C 来说要陌生得多。即使你从未使用 C 编写任何东西，它也比汇编要容易理解得多。
[翻译]编译器(9)-解析
原文在此。 ————翻译分隔线———— 编译器(9)-解析 第一部分：介绍 第二部分：编译、转译和解释 第三部分：编译器设计概览 第四部分：语言设计概述 第五部分：Calc 1 语言规格说明书 第六部分：标识符 第七部分：扫描 第八部分：抽象语法树 长征已经走了很远。我们概览了扫描和抽象语法树的基本概念。现在终于可以向着解析前进。