Martin Tournoij 发布的文章

对于框架、库或者工具来说,怎样做才算是“简单”?也许有很多的定义,但我的理解通常是易于调试。我经常见到人们宣传某个特定的程序、框架、库、文件格式或者其它什么东西是简单的,因为他们会说“看,我只需要这么一点工作量就能够完成某项工作,这太简单了”。非常好,但并不完善。

你可能只编写一次软件,但几乎总要经历好几个调试周期。注意我说的调试周期并不意味着“代码里面有 bug 你需要修复”,而是说“我需要再看一下这份代码来修复 bug”。为了调试代码,你需要理解它,因此“易于调试”延伸来讲就是“易于理解”。

抽象使得程序易于编写,但往往是以难以理解为代价。有时候这是一个很好的折中,但通常不是。大体上,如果能使程序在日后易于理解和调试,我很乐意花更多的时间来写一些东西,因为这样实际上更省时间。

简洁并不是让程序易于调试的唯一方法,但它也许是最重要的。良好的文档也是,但不幸的是好的文档太少了。(注意,质量并取决于字数!)

这种影响是真是存在的。难以调试的程序会有更多的 bug,即使最初的 bug 数量与易于调试的程序完全相同,而是因为修复 bug 更加困难、更花时间。

在公司的环境中,把时间花在难以修复的 bug 上通常被认为是不划算的投资。而在开源的环境下,人们花的时间会更少。(大多数项目都有一个或多个定期的维护者,但成百上千的贡献者提交的仅只是几个补丁)


这并不全是 1974 年由 Brian W. Kernighan 和 P. J. Plauger 合著的《 编程风格的元素 The Elements of Programming Style 》中的观点:

每个人都知道调试比起编写程序困难两倍。当你写程序的时候耍小聪明,那么将来应该怎么去调试?

我见过许多看起来写起来“极尽精妙”,但却导致难以调试的代码。我会在下面列出几种样例。争论这些东西本身有多坏并不是我的本意,我仅想强调对于“易于使用”和“易于调试”之间的折中。

  • ORM 对象关系映射 库可以让数据库查询变得简单,代价是一旦你想解决某个问题,事情就变得难以理解。
  • 许多测试框架让调试变得困难。Ruby 的 rspec 就是一个很好的例子。有一次我不小心使用错了,结果花了很长时间搞清楚究竟哪里出了问题(因为它给出错误提示非常含糊)。

我在《测试并非万能》这篇文章中写了更多关于以上的例子。

  • 我用过的许多 JavaScript 框架都很难完全理解。Clever(LCTT 译注:一种 JS 框架)的语句一向很有逻辑,直到某条语句不能如你预期的工作,这时你就只能指望 Stack Overflow 上的某篇文章或 GitHub 上的某个回帖来帮助你了。

这些函数库确实让任务变得非常简单,使用它们也没有什么错。但通常人们都过于关注“易于使用”而忽视了“易于调试”这一点。

  • Docker 非常棒,并且让许多事情变得非常简单,直到你看到了这条提示:
ERROR: for elasticsearch Cannot start service elasticsearch:
oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:258:
applying cgroup configuration for process caused \"failed to write 898 to cgroup.procs: write
/sys/fs/cgroup/cpu,cpuacct/docker/b13312efc203e518e3864fc3f9d00b4561168ebd4d9aad590cc56da610b8dd0e/cgroup.procs:
invalid argument\""

或者这条:

ERROR: for elasticsearch Cannot start service elasticsearch: EOF

那么…你怎么看?

  • Systemd 比起 SysVinit.d 脚本更加简单,因为编写 systemd 单元文件比起编写 shell 脚本更加方便。这也是 Lennart Poetterin 在他的 systemd 神话 中解释 systemd 为何简单时使用的论点。

我非常赞同 Poettering 的观点——也可以看 shell 脚本陷阱 这篇文章。但是这种角度并不全面。单元文件简单的背后意味着 systemd 作为一个整体要复杂的多,并且用户确实会受到它的影响。看看我遇到的这个问题和为它所做的修复。看起来很简单吗?


via: https://arp242.net/weblog/easy.html

作者:Martin Tournoij 选题:lujun9972 译者:LuuMing 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

当你用电子邮件系统发送自动回复时,你需要注意不要向自动生成的电子邮件发送回复。最好的情况下,你将获得无用的投递失败消息。更可能的是,你会得到一个无限的电子邮件循环和一个混乱的世界。

事实证明,可靠地检测自动生成的电子邮件并不总是那么容易。以下是基于为此编写的检测器并使用它扫描大约 100,000 封电子邮件(大量的个人存档和公司存档)的观察结果。

Auto-submitted 信头

RFC 3834 定义。

这是表示你的邮件是自动回复的“官方”标准。如果存在 Auto-Submitted 信头,并且其值不是 no,你应该发送回复。

X-Auto-Response-Suppress 信头

由微软.aspx)定义。

此信头由微软 Exchange、Outlook 和其他一些产品使用。许多新闻订阅等都设定了这个。如果 X-Auto-Response-Suppress 包含 DR(“抑制投递报告”)、AutoReply(“禁止 OOF 通知以外的自动回复消息”)或 All,你应该发送回复。

List-Id 和 List-Unsubscribe 信头

RFC 2919) 定义。

你通常不希望给邮件列表或新闻订阅发送自动回复。几乎所有的邮件列表和大多数新闻订阅都至少设置了其中一个信头。如果存在这些信头中的任何一个,你应该发送回复。这个信头的值不重要。

Feedback-ID 信头

由谷歌定义。

Gmail 使用此信头识别邮件是否是新闻订阅,并使用它为这些新闻订阅的所有者生成统计信息或报告。如果此信头存在,你应该发送回复。这个信头的值不重要。

非标准方式

上述方法定义明确(即使有些是非标准的)。不幸的是,有些电子邮件系统不使用它们中的任何一个 :-( 这里有一些额外的措施。

Precedence 信头

RFC 2076 中没有真正定义,不鼓励使用它(但通常会遇到此信头)。

请注意,不建议检查是否存在此信头,因为某些邮件使用 normal 和其他一些(少见的)值(尽管这不常见)。

我的建议是如果其值不区分大小写地匹配 bulkauto_replylist,则发送回复。

其他不常见的信头

这是我遇到的另外的一些(不常见的)信头。如果设置了其中一个,我建议发送自动回复。大多数邮件也设置了上述信头之一,但有些没有(这并不常见)。

  • X-MSFBL:无法真正找到定义(Microsoft 信头?),但我只有自动生成的邮件带有此信头。
  • X-Loop:在任何地方都没有真正定义过,有点罕见,但有时有。它通常设置为不应该收到电子邮件的地址,但也会遇到 X-Loop: yes
  • X-Autoreply:相当罕见,并且似乎总是具有 yes 的值。

Email 地址

检查 FromReply-To 信头是否包含 noreplyno-replyno_reply(正则表达式:^no.?reply@)。

只有 HTML 部分

如果电子邮件只有 HTML 部分,而没有文本部分,则表明这是一个自动生成的邮件或新闻订阅。几乎所有邮件客户端都设置了文本部分。

投递失败消息

许多传递失败消息并不能真正表明它们是失败的。一些检查方法:

  • From 包含 mailer-daemonMail Delivery Subsystem

特定的邮件库特征

许多邮件类库留下了某种痕迹,大多数常规邮件客户端使用自己的数据覆盖它。检查这个似乎工作得相当可靠。

  • X-Mailer: Microsoft CDO for Windows 2000:由某些微软软件设置;我只能在自动生成的邮件中找到它。是的,在 2015 年它仍然在使用。
  • Message-ID 信头包含 .JavaMail.:我发现了一些(5 个 50k 大小的)常规消息,但不是很多;绝大多数(数千封)邮件是新闻订阅、订单确认等。
  • ^X-MailerPHP 开头。这应该会同时看到 X-Mailer: PHP/5.5.0X-Mailer: PHPmailer XXX XXX。与 “JavaMail” 相同。
  • 出现了 X-Library;似乎只有 Indy 设定了这个。
  • X-Mailerwdcollect 开头。由一些 Plesk 邮件设置。
  • X-MailerMIME-tools 开头。

最后的预防措施:限制回复的数量

即使遵循上述所有建议,你仍可能会遇到一个避开所有这些检测的电子邮件程序。这可能非常危险,因为电子邮件系统只是“如果有电子邮件那么发送”,就有可能导致无限的电子邮件循环。

出于这个原因,我建议你记录你自动发送的电子邮件,并将此速率限制为在几分钟内最多几封电子邮件。这将打破循环链条。

我们使用每五分钟一封电子邮件的设置,但没这么严格的设置可能也会运作良好。

你需要为自动回复设置什么信头

具体细节取决于你发送的邮件类型。这是我们用于自动回复邮件的内容:

Auto-Submitted: auto-replied
X-Auto-Response-Suppress: All
Precedence: auto_reply

反馈

你可以发送电子邮件至 [email protected]创建 GitHub 议题以提交反馈、问题等。


via: https://arp242.net/weblog/autoreply.html

作者:Martin Tournoij 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Shell 脚本很棒,你可以非常轻松地写出有用的东西来。甚至像是下面这个傻瓜式的命令:

# 用含有 Go 的词汇起名字:
$ grep -i ^go /usr/share/dict/* | cut -d: -f2 | sort -R | head -n1
goldfish

如果用其他编程语言,就需要花费更多的脑力,用多行代码实现,比如用 Ruby 的话:

puts(Dir['/usr/share/dict/*-english'].map do |f|
  File.open(f)
    .readlines
    .select { |l| l[0..1].downcase == 'go' }
end.flatten.sample.chomp)

Ruby 版本的代码虽然不是那么长,也并不复杂。但是 shell 版是如此简单,我甚至不用实际测试就可以确保它是正确的。而 Ruby 版的我就没法确定它不会出错了,必须得测试一下。而且它要长一倍,看起来也更复杂。

这就是人们使用 Shell 脚本的原因,它简单却实用。下面是另一个例子:

curl https://nl.wikipedia.org/wiki/Lijst_van_Nederlandse_gemeenten |
    grep '^<li><a href=' |
    sed -r 's|<li><a href="/wiki/.+" title=".+">(.+)</a>.*</li>|\1|' |
    grep -Ev '(^Tabel van|^Lijst van|Nederland)'

这个脚本可以从维基百科上获取荷兰基层政权的列表。几年前我写了这个临时的脚本,用来快速生成一个数据库,到现在它仍然可以正常运行,当时写它并没有花费我多少精力。但要用 Ruby 完成同样的功能则会麻烦得多。


现在来说说 shell 的缺点吧。随着代码量的增加,你的脚本会变得越来越难以维护,但你也不会想用别的语言重写一遍,因为你已经在这个 shell 版上花费了很多时间。

我把这种情况称为“Shell 脚本编程陷阱”,这是沉没成本谬论的一种特例(LCTT 译注:“沉没成本谬论”是一个经济学概念,可以简单理解为,对已经投入的成本可能被浪费而念念不忘)。

实际上许多脚本会增长到超出预期的大小,你经常会花费过多的时间来“修复某个 bug”,或者“添加一个小功能”。如此循环往复,让人头大。

如果你从一开始就使用 Python、Ruby 或是其他类似的语言来写这个程序,你可能会在写第一版的时候多花些时间,但以后维护起来就容易很多,bug 也肯定会少很多。

以我的 packman.vim 脚本为例。它起初只包含一个简单的用来遍历所有目录的 for 循环,外加一个 git pull,但在这之后就刹不住车了,它现在有 200 行左右的代码,这肯定不能算是最复杂的脚本,但假如我一上来就按计划用 Go 来编写它的话,那么增加一些像“打印状态”或者“从配置文件里克隆新的 git 库”这样的功能就会轻松很多;添加“并行克隆”的支持也几乎不算个事儿了,而在 shell 脚本里却很难实现(尽管不是不可能)。事后看来,我本可以节省时间,并且获得更好的结果。

出于类似的原因,我很后悔写出了许多这样的 shell 脚本,而我在 2018 年的新年誓言就是不要再犯类似的错误了。

附录:问题汇总

需要指出的是,shell 编程的确存在一些实际的限制。下面是一些例子:

  • 在处理一些包含“空格”或者其他“特殊”字符的文件名时,需要特别注意细节。绝大多数脚本都会犯错,即使是那些经验丰富的作者(比如我)编写的脚本,因为太容易写错了,只添加引号是不够的
  • 有许多所谓“正确”和“错误”的做法。你应该用 which 还是 command?该用 $@ 还是 $*,是不是得加引号?你是该用 cmd $arg 还是 cmd "$arg"?等等等等。
  • 你没法在变量里存储空字节(0x00);shell 脚本处理二进制数据很麻烦。
  • 虽然你可以非常快速地写出有用的东西,但实现更复杂的算法则要痛苦许多,即使用 ksh/zsh/bash 扩展也是如此。我上面那个解析 HTML 的脚本临时用用是可以的,但你真的不会想在生产环境中使用这种脚本。
  • 很难写出跨平台的通用型 shell 脚本。/bin/sh 可能是 dash 或者 bash,不同的 shell 有不同的运行方式。外部工具如 grepsed 等,不一定能支持同样的参数。你能确定你的脚本可以适用于 Linux、macOS 和 Windows 的所有版本吗(无论是过去、现在还是将来)?
  • 调试 shell 脚本会很难,特别是你眼中的语法可能会很快变得记不清了,并不是所有人都熟悉 shell 编程的语境。
  • 处理错误会很棘手(检查 $? 或是 set -e),排查一些超过“出了个小错”级别的复杂错误几乎是不可能的。
  • 除非你使用了 set -u,变量未定义将不会报错,而这会导致一些“搞笑事件”,比如 rm -r ~/$undefined 会删除用户的整个家目录(瞅瞅 Github 上的这个悲剧)。
  • 所有东西都是字符串。一些 shell 引入了数组,能用,但是语法非常丑陋和费解。带分数的数字运算仍然难以应付,并且依赖像 bcdc 这样的外部工具($(( .. )) 这种方式只能对付一下整数)。

反馈

你可以发邮件到 [email protected],或者在 GitHub 上创建 issue 来向我反馈,提问等。


via: https://arp242.net/weblog/shell-scripting-trap.html

作者:Martin Tournoij 选题:lujun9972 译者:jdh8383 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

这也许是一个不太受欢迎的观点,但大多数主流公司最好不要再使用 k8s 了。

你知道那个古老的“以程序员技能写 Hello world ”笑话吗?—— 从一个新手程序员的 printf("hello, world\n") 语句开始,最后结束于高级软件架构工程师令人费解的 Java OOP 模式设计。使用 k8s 就有点像这样。

  • 新手系统管理员:

./binary

  • 有经验的系统管理员:

在 EC2 上的 ./binary

  • DevOp:

在 EC2 上自部署的 CI 管道运行 ./binary

  • 高级云编排工程师:

在 EC2 上通过 k8s 编排的自部署 CI 管道运行 ./binary

¯\\_(ツ)\_/¯

这不意味着 Kubernetes 或者任何这样的东西本身都是坏的,就像 Java 或者 OOP 设计本身并不是坏的一样,但是,在很多情况下,它们被严重地误用,就像在一个 hello world 的程序中可怕地误用 Java 面向对象设计模式一样。对大多数公司而言,系统运维从根本上来说并不十分复杂,此时在这上面应用 k8s 起效甚微。

复杂性本质上来说创造了工作,我十分怀疑使用 k8s 对大多数使用者来说是省时的这一说法。这就好像花一天时间来写一个脚本,用来自动完成一些你一个月进行一次,每次只花 10 分钟完成的工作。这不是一个好的时间投资(特别是你可能会在未来由于扩展或调试这个脚本而进一步投入的更多时间)。

你的部署大概应该需要自动化 – 以免你 最终像 Knightmare 那样 —— 但 k8s 通常可以被一个简单的 shell 脚本所替代。

在我们公司,系统运维团队用了很多时间来设置 k8s 。他们还不得不用了很大一部分时间来更新到新一点的版本(1.6 ➙ 1.8)。结果是如果没有真正深入理解 k8s ,有些东西就没人会真的明白,甚至连深入理解 k8s 这一点也很难(那些 YAML 文件,哦呦!)

在我能自己调试和修复部署问题之前 —— 现在这更难了,我理解基本概念,但在真正调试实际问题的时候,它们并不是那么有用。我不经常用 k8s 足以证明这点。


k8s 真的很难这点并不是什么新看法,这也是为什么现在会有这么多 “k8s 简单用”的解决方案。在 k8s 上再添一层来“让它更简单”的方法让我觉得,呃,不明智。复杂性并没有消失,你只是把它藏起来了。

以前我说过很多次:在确定一样东西是否“简单”时,我最关心的不是写东西的时候有多简单,而是当失败的时候调试起来有多容易。包装 k8s 并不会让调试更加简单,恰恰相反,它让事情更加困难了。


Blaise Pascal 有一句名言:

几乎所有的痛苦都来自于我们不善于在房间里独处。

k8s —— 略微拓展一下,Docker —— 似乎就是这样的例子。许多人似乎迷失在当下的兴奋中,觉得 “k8s 就是这么回事!”,就像有些人迷失在 Java OOP 刚出来时的兴奋中一样,所以一切都必须从“旧”方法转为“新”方法,即使“旧”方法依然可行。

有时候 IT 产业挺蠢的。

或者用 一条推特 来总结:

  • 2014 - 我们必须采用 #微服务 来解决独石应用的所有问题
  • 2016 - 我们必须采用 #docker 来解决微服务的所有问题
  • 2018 - 我们必须采用 #kubernetes 来解决 docker 的所有问题

你可以通过 [email protected] 给我发邮件或者 创建 GitHub issue 来给我反馈或提出问题等。


via: https://arp242.net/weblog/dont-need-k8s.html

作者:Martin Tournoij 选题:lujun9972 译者:beamrolling 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

我之前写过为什么将 JSON 用于人类可编辑的配置文件是一个坏主意,今天我们将讨论 YAML 格式的一些常见问题。

默认情况下不安全

YAML 默认是不安全的。加载用户提供的(不可信的)YAML 字符串需要仔细考虑。

!!python/object/apply:os.system
args: ['ls /']

print(yaml.load(open('a.yaml'))) 运行它,应该给你这样的东西:

bin   etc   lib    lost+found  opt   root  sbin  tmp  var sys
boot  dev   efi    home        lib64 mnt   proc  run  srv usr
0

许多其他语言(包括 Ruby 和 PHP 1 )默认情况下也不安全(LCTT 译注:这里应该说的是解析 yaml)。在 GitHub 上搜索 yaml.load 会得到惊人的 280 万个结果,而 yaml.safe\_load 只能得到 26000 个结果。

提个醒,很多这样的 yaml.load() 都工作的很好,在配置文件中加载 yaml.load() 通常没问题,因为它通常(虽然并不总是!)来自“可靠源”,而且很多都来自静态的 YAML 测试文件。但是,人们还是不禁怀疑在这 280 万个结果中隐藏了多少漏洞。

这不是一个理论问题。在 2013 年,正是由于这个问题,所有的 Ruby on Rails 应用程序都被发现易受远程代码执行攻击。

有人可能会反驳说这不是 YAML 格式的错误,而是那些库实现错误的的问题,但似乎大多数库默认不是安全的(特别是动态语言),所以事实上这是 YAML 的一个问题。

有些人可能会反驳认为修复它就像用 safe_load() 替换 load() 一样容易,但是很多人都没有意识到这个问题,即使你知道它,它也是很容易忘记的事情之一。这是非常糟糕的 API 设计。

可能很难编辑,特别是对于大文件

YAML 文件可能很难编辑,随着文件变大,这个难度会快速增大。

一个很好的例子是 Ruby on Rails 的本地化翻译文件。例如:

en:
   formtastic:
     labels:
       title: "Title"  # Default global value
       article:
         body: "Article content"
       post:
         new:
           title: "Choose a title..."
           body: "Write something..."
         edit:
           title: "Edit title"
           body: "Edit body"

看起来不错,对吧?但是如果这个文件有 100 行怎么办?或者 1,000 行?在文件中很难看到 “where”,因为它可能在屏幕外。你需要向上滚动,但是你需要跟踪缩进,即使遵循缩进指南也很难,特别是因为 2 个空格缩进是常态而且 制表符缩进被禁止 2

不小心缩进出错通常不算错误,它通常只是反序列化为你不想要的东西。这样只能祝你调试快乐!

我已经愉快地编写 Python 长达十多年,所以我已经习惯了显眼的空白,但有时候我仍在和 YAML 抗争。在 Python 中,虽然没有那种长达几页的函数,但数据或配置文件的长度没有这种自然限制,这就带来了缺点和损失了清晰度。

对于小文件,这不是问题,但它确实无法很好地扩展到较大的文件,特别是如果你以后想编辑它们的话。

这非常复杂

在浏览一个基本的例子时,YAML 看似“简单”和“显而易见”,但事实证明并非如此。YAML 规范有 23449 个单词,为了比较,TOML 有 3339 个单词,Json 有 1969 个单词,XML 有 20603 个单词。

我们中有谁读过全部规范吗?有谁读过并理解了全部?谁阅读过,理解进而记住所有这些?

例如,你知道在 YAML 中编写多行字符串有 9 种方法吗?并且它们具有细微的不同行为。

是的 :-/

如果你看一下那篇文章的修订历史,它就会变得更加有趣,因为文章的作者发现了越来越多的方法可以实现这一点,以及更多的细微之处。

它从预览开始告诉我们 YAML 规范,它表明(强调我的):

本节简要介绍了 YAML 的表达能力。预计初次阅读的人不可能理解所有的例子。相反,这些选择用作该规范其余部分的动机。

令人惊讶的行为

以下会解析成什么(Colm O’Connor 提供的例子):

- Don Corleone: Do you have faith in my judgment?
- Clemenza: Yes
- Don Corleone: Do I have your loyalty?

结果为:

[
    {'Don Corleone': 'Do you have faith in my judgment?'},
    {'Clemenza': True},
    {'Don Corleone': 'Do I have your loyalty?'}
]

那么这个呢:

python: 3.5.3
postgres: 9.3

3.5.3 被识别为字符串,但 9.3 被识别为数字而不是字符串:

{'python': '3.5.3', 'postgres': 9.3}

这个呢:

Effenaar: Eindhoven
013: Tilburg

013 蒂尔堡 Tilburg 的一个流行音乐场地,但 YAML 会告诉你错误答案,因为它被解析为八进制数字:

{11: 'Tilburg', 'Effenaar': 'Eindhoven'}

所有这一切,以及更多,就是为什么许多经验丰富的 YAMLer 经常会将所有字符串用引号引起来的原因,即使它不是严格要求。许多人不使用引号,而且很容易忘记,特别是如果文件的其余部分(可能由其他人编写)不使用引号。

它不方便

因为它太复杂了,它所声称的可移植性被夸大了。例如,考虑以下这个从 YAML 规范中获取的示例:

? - Detroit Tigers
  - Chicago cubs
:
  - 2001-07-23

? [ New York Yankees,
    Atlanta Braves ]
: [ 2001-07-02, 2001-08-12,
    2001-08-14 ]

抛开大多数读者可能甚至不知道这是在做什么之外,请尝试使用 PyYAML 在 Python 中解析它:

yaml.constructor.ConstructorError: while constructing a mapping
  in "a.yaml", line 1, column 1
found unhashable key
  in "a.yaml", line 1, column 3

在 Ruby 中,它可以工作:

{
    ["Detroit Tigers", "Chicago cubs"] => [
        #<Date: 2001-07-23 ((2452114j,0s,0n),+0s,2299161j)>
    ],
    ["New York Yankees", "Atlanta Braves"] => [
        #<Date: 2001-07-02 ((2452093j,0s,0n),+0s,2299161j)>,
        #<Date: 2001-08-12 ((2452134j,0s,0n),+0s,2299161j)>,
        #<Date: 2001-08-14 ((2452136j,0s,0n),+0s,2299161j)>
    ]
}

这个原因是你不能在 Python 中使用列表作为一个字典的键:

>>> {['a']: 'zxc'}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  TypeError: unhashable type: 'list'

而这种限制并不是 Python 特有的,PHP、JavaScript 和 Go 等常用语言都有此限制。

因此,在 YAML 文件中使用这种语法,你将无法在大多数语言中解析它。

这是另一个从 YAML 规范的示例部分中获取的:

# Ranking of 1998 home runs
---
- Mark McGwire
- Sammy Sosa
- Ken Griffey

# Team ranking
---
- Chicago Cubs
- St Louis Cardinals

Python 会输出:

yaml.composer.ComposerError: expected a single document in the stream
  in "a.yaml", line 3, column 1
but found another document
  in "a.yaml", line 8, column 1

然而 Ruby 输出:

["Mark McGwire", "Sammy Sosa", "Ken Griffey"]

原因是单个文件中有多个 YAML 文档(--- 意味开始一个新文档)。在 Python 中,有一个 load_all 函数来解析所有文档,而 Ruby 的 load() 只是加载第一个文档,据我所知,它没有办法加载多个文档。

在实现之间存在很多不兼容

目标实现了吗?

规范说明:

YAML 的设计目标安装优先级降序排列如下:

  1. YAML 很容易被人类阅读。
  2. YAML 数据在编程语言之间是可移植的。
  3. YAML 匹配敏捷语言的原生数据结构。
  4. YAML 有一个一致的模型来支持通用工具。
  5. YAML 支持一次性处理。
  6. YAML 具有表现力和可扩展性。
  7. YAML 易于实现和使用。

那么它做的如何呢?

YAML 很容易被人类阅读。

只有坚持一小部分子集时才有效。完整的规则集很复杂 —— 远远超过 XML 或 JSON。

YAML 数据在编程语言之间是可移植的。

事实并非如此,因为创建常见语言不支持的结构太容易了。

YAML 匹配敏捷语言的原生数据结构。

参见上面。另外,为什么只支持敏捷(或动态)语言?其他语言呢?

YAML 有一个一致的模型来支持通用工具。

我甚至不确定这意味着什么,我找不到任何详细说明。

YAML 支持一次性处理。

这点我接受。

YAML 具有表现力和可扩展性。

嗯,是的,但它太富有表现力(例如太复杂)。

YAML 易于实现和使用。
$ cat `ls -1 ~/gocode/src/github.com/go-yaml/yaml/*.go | grep -v _test` | wc -l
9247

$ cat /usr/lib/python3.5/site-packages/yaml/*.py | wc -l
5713

结论

不要误解我的意思,并不是说 YAML 很糟糕 —— 它肯定不像使用 JSON 那么多的问题 —— 但它也不是非常好。有一些一开始并不明显的缺点和惊喜,还有许多更好的替代品,如 TOML 和其他更专业的格式。

就个人而言,当我有选择时,我不太可能再次使用它。

如果你必须使用 YAML,那么我建议你使用 StrictYAML,它会删除一些(虽然不是全部)比较麻烦的部分。

反馈

你可以发送电子邮件至 [email protected]创建 GitHub issue 以获取反馈、问题等。

脚注

  1. 在 PHP 中你需要修改一个 INI 设置来获得安全的行为,不能只是调用像 yaml_safe() 这样的东西。PHP 想尽办法让愚蠢的东西越发愚蠢。干得漂亮!
  2. 不要在这里做空格与制表符之争,如果这里可以用制表符的话,我可以(临时)增加制表符宽度来使它更易读——这是制表符的一种用途。

via: https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html

作者:Martin Tournoij 选题:lujun9972 译者:MjSeven 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出