分类 观点 下的文章

不管怎么说,好的交流是一个活跃的开源社区的必备品。

我通常不会定下大的新年决心。当然,我在自我提升方面没有任何问题,这篇文章我希望锚定的是这个日历中的另外一部分。不过即使是这样,这里也有一些东西要从今年的免费日历上划掉,并将其替换为一些可以激发我的自省的新日历内容。

在 2017 年,我从不在社交媒体上分享我从未阅读过的文章。我一直保持这样的状态,我也认为它让我成为了一个更好的互联网公民。对于 2019 年,我正在考虑让我成为更好的开源软件维护者的决心。

下面是一些我在一些项目中担任维护者或共同维护者时坚持的决心:

1、包含行为准则

Jono Bacon 在他的文章“7 个你可能犯的错误”中包含了一条“不强制执行行为准则”。当然,要强制执行行为准则,你首先需要有一个行为准则。我打算默认用贡献者契约,但是你可以使用其他你喜欢的。关于这个许可协议,最好的方法是使用别人已经写好的,而不是你自己写的。但是重要的是,要找到一些能够定义你希望你的社区执行的,无论它们是什么样子。一旦这些被记录下来并强制执行,人们就能自行决定是否成为他们想象中社区的一份子。

2、使许可证清晰且明确

你知道什么真的很烦么?不清晰的许可证。这个软件基于 GPL 授权,如果没有进一步提供更多信息的文字,我无法知道更多信息。基于哪个版本的GPL?我可以用它吗?对于项目的非代码部分,“根据知识共享许可证(CC)授权”更糟糕。我喜欢知识共享许可证,但它有几个不同的许可证包含着不同的权利和义务。因此,我将非常清楚的说明哪个许可证的变种和版本适用于我的项目。我将会在仓库中包含许可的全文,并在其他文件中包含简明的注释。

与此相关的一类问题是使用 OSI 批准的许可证。想出一个新的准确的说明了你想要表达什么的许可证是有可能的,但是如果你需要强制推行它,祝你好运。会坚持使用它么?使用您项目的人会理解么?

3、快速分类错误报告和问题

在技术领域, 很少有比开源维护者更贫乏的东西了。即使在小型项目中,也很难找到时间去回答每个问题并修复每个错误。但这并不意味着我不能哪怕回应一下,它没必要是多段的回复。即使只是给 GitHub 问题贴了个标签也表明了我看见它了。也许我马上就会处理它,也许一年后我会处理它。但是让社区看到它很重要,是的,这里还有人管。

4、如果没有伴随的文档,请不要推送新特性或错误修复

尽管多年来我的开源贡献都围绕着文档,但我的项目并没有反映出我对它的重视。我能推送的提交不多,并不不需要某种形式的文档。新的特性显然应该在他们被提交时甚至是在之前就编写文档。但即使是错误修复,也应该在发行说明中有一个条目提及。如果没有什么意外,推送提交也是很好的改善文档的机会。

5、放弃一个项目时,要说清楚

我很不擅长对事情说“不”,我告诉编辑我会为 Opensource.com 写一到两篇文章,而现在我有了将近 60 篇文章。哎呀。但在某些时候,曾经我有兴趣的事情也会不再有兴趣。也许该项目是不必要的,因为它的功能被吸收到更大的项目中;也许只是我厌倦了它。但这对社区是不公平的(并且存在潜在的危险,正如最近的 event-stream 恶意软件注入所示),会让该项目陷入困境。维护者有权随时离开,但他们离开时应该说清楚。

无论你是开源维护者还是贡献者,如果你知道项目维护者应该作出的其他决心,请在评论中分享!


via: https://opensource.com/article/18/12/resolutions-open-source-project-maintainers

作者:Ben Cotton 选题:lujun9972 译者:bestony 校对:wxy

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

微服务是个好东西,就像乐高积木一样,你可以拼成各种东西,当前,前提是你足够会玩。

从早些年的 SOA 和中间件,到现在的微服务和容器,但似乎历史总是螺旋式变化的。看起来笨拙而大而无当的独石应用,其实在很多场景,要比微服务更适合。

话说,微服务的锅该那只汤姆猫背吗?:->


via: http://turnoff.us/geek/are-you-ready-for-microservices/

作者:Daniel Stori 译者&点评&校对:wxy 合成:wxy

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

JSON 已经占领了全世界。当今,任何两个应用程序彼此通过互联网通信时,可以打赌它们在使用 JSON。它已被所有大型企业所采用:十大最受欢迎的 web API 接口列表中(主要由 Google、Facebook 和 Twitter 提供),仅仅只有一个 API 接口是以 XML 的格式开放数据的。 1 这个列表中的 Twitter API 为此做了一个鲜活的注脚:其对 XML 格式的支持到 2013 年结束,其时发布的新版本的 API 取消 XML 格式,转而仅使用 JSON。JSON 也在程序编码级别和文件存储上被广泛采用:在 Stack Overflow(LCTT 译注:一个面向程序员的问答网站)上,现在更多的是关于 JSON 的问题,而不是其他的数据交换格式。 2

XML 仍然在很多地方存在。网络上它被用于 SVG 和 RSS / Atom 信息流。Android 开发者想要获得用户权限许可时,需要在其 APP 的 manifest 文件中声明 —— 此文件是 XML 格式的。XML 的替代品也不仅仅只有 JSON,现在有很多人在使用 YAML 或 Google 的 Protocol Buffers 等技术,但这些技术的受欢迎程度远不如 JSON。目前来看,JSON 是应用程序在网络之间通信的首选协议格式。

考虑到自 2005 年来 Web 编程世界就垂涎于 “异步 JavaScript 和 XML” 而非 “异步 JavaScript 和 JSON” 的技术潜力,你可以发现 JSON 的主导地位是如此的让人惊讶。当然了,这可能与这两种通信格式的受欢迎程度无关,而仅反映出缩写 “AJAX” 似乎比 “AJAJ” 更具吸引力。但是,即使在 2005 年有些人(实际上没有太多人)已经用 JSON 来取代 XML 了,我们不禁要问 XML 的噩运来的如此之快,以至于短短十来年,“异步 JavaScript 和 XML” 这个名称就成为一个很讽刺的误称。那这十来年发生了什么?JSON 怎么会在那么多应用程序中取代了 XML?现在被全世界工程师和系统所使用、依赖的这种数据格式是谁提出的?

JSON 之诞生

2001 年 4 月,首个 JSON 格式的消息被发送出来。此消息是从旧金山湾区某车库的一台计算机发出的,这是计算机历史上重要的的时刻。Douglas Crockford 和 Chip Morningstar 是一家名为 State Software 的技术咨询公司的联合创始人,他们当时聚集在 Morningstar 的车库里测试某个想法,发出了此消息。

在 “AJAX” 这个术语被创造之前,Crockford 和 Morningstar 就已经在尝试构建好用的 AJAX 应用程序了,可是浏览器对其兼容性不好。他们想要在初始页面加载后就将数据传递给应用程序,但其目标要针对所有的浏览器,这就实现不了。

这在今天看来不太可信,但是要记得 2001 年的时候 Internet Explorer(IE)代表了网页浏览器的最前沿技术产品。早在 1999 年的时候,Internet Explorer 5 就支持了原始形式的 XMLHttpRequest,开发者可以使用名为 ActiveX 的框架来访问此对象。Crockford 和 Morningstar 能够使用此技术(在 IE 中)来获取数据,但是在 Netscape 4 中(这是他们想要支持的另一种浏览器)就无法使用这种解决方案。为此 Crockford 和 Morningstar 只得使用一套不同的系统以兼容不同的浏览器。

第一条 JSON 消息如下所示:

<html><head><script>
    document.domain = 'fudco';
    parent.session.receive(
        { to: "session", do: "test",
          text: "Hello world" }
    )
</script></head></html>

消息中只有一小部分类似于今天我们所知的 JSON,本身其实是一个包含有一些 JavaScript 的 HTML 文档。类似于 JSON 的部分只是传递给名为 receive() 的函数的 JavaScript 对象字面量。

Crockford 和 Morningstar 决定滥用 HTML 的帧(<frame>)以发送数据。他们可以让一个帧指向一个返回的上述 HTML 文档的 URL。当接收到 HTML 时,JavaScript 代码段就会运行,就可以把数据对象字面量如实地传递回应用程序。只要小心的回避浏览器保护策略(即子窗口不允许访问父窗口),这种技术就可以正常运行无误。可以看到 Crockford 和 Mornginstar 通过明确地设置文档域这种方法来达到其目的。(这种基于帧的技术,有时称为隐藏帧技术,通常在 90 年代后期,即在广泛使用 XMLHttpRequest 技术之前使用。 3

第一个 JSON 消息的惊人之处在于,它显然不是一种新的数据格式的首次使用。它就是 JavaScript!实际上,以此方式使用 JavaScript 的想法如此简单,Crockford 自己也说过他不是第一个这样做的人。他说 Netscape 公司的某人早在 1996 年就使用 JavaScript 数组字面量来交换信息。 4 因为消息就是 JavaScript,其不需要任何特殊解析工作,JavaScript 解释器就可搞定一切。

最初的 JSON 信息实际上与 JavaScript 解释器发生了冲突。JavaScript 保留了大量的关键字(ECMAScript 6 版本就有 64 个保留字),Crockford 和 Morningstar 无意中在其 JSON 中使用了一个保留字。他们使用了 do 作为了键名,但 do 是解释器中的保留字。因为 JavaScript 使用的保留字太多了,Crockford 做了决定:既然不可避免的要使用到这些保留字,那就要求所有的 JSON 键名都加上引号。被引起来的键名会被 JavaScript 解释器识别成字符串,其意味着那些保留字也可以放心安全的使用。这就为什么今天 JSON 键名都要用引号引起来的原因。

Crockford 和 Morningstar 意识到这技术可以应用于各类应用系统。想给其命名为 “JSML”,即 JavaScript 标记语言 JavaScript Markup Language 的意思,但发现这个缩写已经被一个名为 Java Speech 标记语言的东西所使用了。因此他们决定采用 “JavaScript Object Notation”,缩写为 JSON。他们开始向客户推销,但很快发现客户不愿意冒险使用缺乏官方规范的未知技术。所以 Crockford 决定写一个规范。

2002 年,Crockford 买下了 JSON.org 域名,放上了 JSON 语法及一个解释器的实例例子。该网站仍然在运行,现在已经包含有 2013 年正式批准的 JSON ECMA 标准的显著链接。在该网站建立后,Crockford 并没有过多的推广,但很快发现很多人都在提交各种不同编程语言的 JSON 解析器实现。JSON 的血统显然与 JavaScript 相关联,但很明显 JSON 非常适合于不同语言之间的数据交换。

AJAX 导致的误会

2005 年,JSON 有了一次大爆发。那一年,一位名叫 Jesse James Garrett 的网页设计师和开发者在博客文章中创造了 “AJAX” 一词。他很谨慎地强调:AJAX 并不是新技术,而是 “好几种蓬勃发展的技术以某种强大的新方式汇集在一起。 5 ” AJAX 是 Garrett 给这种正受到青睐的 Web 应用程序的新开发方法的命名。他的博客文章接着描述了开发人员如何利用 JavaScript 和 XMLHttpRequest 构建新型应用程序,这些应用程序比传统的网页更具响应性和状态性。他还以 Gmail 和 Flickr 网站已经使用 AJAX 技术作为了例子。

当然了,“AJAX” 中的 “X” 代表 XML。但在随后的问答帖子中,Garrett 指出,JSON 可以完全替代 XML。他写道:“虽然 XML 是 AJAX 客户端进行数据输入、输出的最完善的技术,但要实现同样的效果,也可以使用像 JavaScript Object Notation(JSON)或任何类似的结构数据方法等技术。 ” 6

开发者确实发现在构建 AJAX 应用程序时可以很容易的使用 JSON,许多人更喜欢它而不是 XML。具有讽刺意味的是,对 AJAX 的兴趣逐渐的导致了 JSON 的普及。大约在这个时候,JSON 引起了博客圈的注意。

2006 年,Dave Winer,一位高产的博主,他也是许多基于 XML 的技术(如 RSS 和 XML-RPC)背后的开发工程师,他抱怨到 JSON 毫无疑问的正在重新发明 XML。尽管人们认为数据交换格式之间的竞争不会导致某一技术的消亡。其写到:

毫无疑问,我可以编写一个例程来解析 JSON,但来看看他们要重新发明一个东西有多大的意义,出于某种原因 XML 本身对他们来说还不够好(我很想听听原因)。谁想干这荒谬之事?查找一棵树然后把节点串起来。可以立马试试。 7

我很理解 Winer 的挫败感。事实上并没有太多人喜欢 XML。甚至 Winer 也说过他不喜欢 XML。 8 但 XML 已被设计成一个可供任何人使用,并且可以用于几乎能想象到的所有事情。归根到底,XML 实际上是一门元语言,允许你为特定应用程序自定义该领域特定的语言。如 Web 信息流技术 RSS 和 SOAP(简单对象访问协议)就是例子。Winer 认为由于通用交换格式所带来的好处,努力达成共识非常重要。XML 的灵活性应该能满足任何人的需求,然而 JSON 格式呢,其并没有比 XML 提供更多东西,除了它抛弃了使 XML 更灵活的那些繁琐的东西。

Crockford 阅读了 Winer 的这篇文章并留下了评论。为了回应 JSON 重新发明 XML 的指责,Crockford 写到:“重造轮子的好处是可以得到一个更好的轮子。” 9

JSON 与 XML 对比

到 2014 年,JSON 已经由 ECMA 标准和 RFC 官方正式认可。它有了自己的 MIME 类型。JSON 已经进入了大联盟时代。

为什么 JSON 比 XML 更受欢迎?

JSON.org 网站上,Crockford 总结了一些 JSON 的优势。他写到,JSON 的语法极少,其结构可预测,因此 JSON 更容易被人类和机器理解。 10 其他博主一直关注 XML 的冗长啰嗦及“尖括号负担”。 11 XML 中每个开始标记都必须与结束标记匹配,这意味着 XML 文档包含大量的冗余信息。在未压缩时,XML 文档的体积比同等信息量 JSON 文档的体积大很多,但是,更重要的,这也使 XML 文档更难以阅读。

Crockford 还声称 JSON 的另一个巨大优势是其被设计为数据交换格式。 12 从一开始,它的目的就是在应用程序间传递结构化信息的。而 XML 呢,虽然也可以使用来传递数据,但其最初被设计为文档标记语言。它演变自 SGML(通用标准标记语言),而它又是从被称为 Scribe 的标记语言演变而来,其旨在发展成类似于 LaTeX 一样的文字处理系统。XML 中,一个标签可以包含有所谓的“混合内容”,即带有围绕单词、短语的内嵌标签的文本。这会让人浮现出一副用红蓝笔记录的手稿画面,这是标记语言核心思想的形象比喻。另一方面,JSON 不支持对混合内容模型的清晰构建,但这也意味着它的结构足够简单。一份文档最好的建模就是一棵树,但 JSON 抛弃了这种文档的思想,Crockford 将 JSON 抽象限制为字典和数组,这是所有程序员构建程序时都会使用的最基本的、也最熟悉的元素。

最后,我认为人们不喜欢 XML 是因为它让人困惑。它让人迷惑的地方就是有很多不同的风格。乍一看,XML 本身及其子语言(如 RSS、ATOM、SOAP 或 SVG)之间的界限并不明显。典型的 XML 文档的第一行标识了该 XML 的版本,然后该 XML 文档应该符合特定的子语言。这就有变化需要考虑了,特别是跟 JSON 做比较,JSON 是如此简单,以至于永远不需要编写新版本的 JSON 规范。XML 的设计者试图将 XML 做为唯一的数据交换格式以支配所有格式,就会掉入那个经典的程序员陷阱:过度工程化。XML 非常笼统及概念化,所以很难于简单的使用。

在 2000 年的时候,发起了一场使 HTML 符合 XML 标准的活动,发布了一份符合 XML 标准的 HTML 开发规范,这就此后很出名的 XHTML。虽然一些浏览器厂商立即开始支持这个新标准,但也很明显,大部分基于 HTML 技术的开发者不愿意改变他们的习惯。新标准要求对 XHTML 文档进行严格的验证,而不是基于 HTML 的基准。但大多的网站都是依赖于 HTML 的宽容规则的。到 2009 年的时候,试图编写第二版本的 XHTML 标准的努力已经流产,因为未来已清晰可见,HTML 将会发展为 HTML5(一种不强制要求接受 XML 规则的标准)。

如果 XHTML 的努力取得了成功,那么 XML 可能会成为其设计者所希望的通用数据格式。想象一下,一个 HTML 文档和 API 响应具有完全相同结构的世界。在这样的世界中,JSON 可能不会像现在一样普遍存在。但我把 HTML 的失败看做是 XML 阵营的一种道义上的失败。如果 XML 不是 HTML 的最佳工具,那么对于其他应用程序,也许会有更好的工具出现。在这个世界,我们的世界,很容易看到像 JSON 格式这样的足够简单、量体裁衣的才能获得更大的成功。

如果你喜欢这博文,每两周会更新一次! 请在 Twitter 上关注 @TwoBitHistory 或订阅 RSS feed,以确保得到更新的通知。


  1. http://www.cs.tufts.edu/comp/150IDS/final_papers/tstras01.1/FinalReport/FinalReport.html#software
  2. https://insights.stackoverflow.com/trends?tags=json%2Cxml%2Cprotocol-buffers%2Cyaml%2Ccsv
  3. Zakas, Nicholas C., et al. “What Is Ajax?” Professional Ajax, 2nd ed., Wiley, 2007.
  4. https://youtu.be/-C-JoyNuQJs?t=32s
  5. http://adaptivepath.org/ideas/ajax-new-approach-web-applications/
  6. 同上
  7. http://scripting.com/2006/12/20.html
  8. http://blogoscoped.com/archive/2009-03-05-n15.html
  9. https://scripting.wordpress.com/2006/12/20/scripting-news-for-12202006/#comment-26383
  10. http://www.json.org/xml.html
  11. https://blog.codinghorror.com/xml-the-angle-bracket-tax
  12. https://youtu.be/-C-JoyNuQJs?t=33m50sgg

via: https://twobithistory.org/2017/09/21/the-rise-and-rise-of-json.html

作者:Two-Bit History 选题:lujun9972 译者:runningwater 校对:wxy

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

这幅漫画讽刺了一些不懂架构的人,盲目使用复杂的、新的架构来尝试业务,建立了一堆无用的组件(灯/LAMP,即常见的 Linux+Apache+MySQL+PHP 网站架构),但却不知道该怎么用这些组件完成需求。


via: - http://turnoff.us/geek/wrong-architect/

作者:Daniel Stori 译者&点评:Besony 校对:wxy 合成:Bestony

本文由 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中国 荣誉推出

我们是聪明地工作,而不是刻苦工作,但仍能把工作做好。

Linux 的系统管理员的工作总是复杂的,并且总是伴随着各种陷阱和障碍。做每件事都没有足够时间,当你想完成那个半秃头老板(PHB)给的任务时,他(只会)不停在你的后面盯着,而最核心的服务器总是在最不合时宜的时间点崩溃,问题和挑战比比皆是。而我发现,成为一名 懒惰的系统管理员 Lazy SysAdmin 可以解决这一困境。

(LCTT 译注: 半秃头老板 Pointy-Haired Boss (PHB),那是呆伯特漫画中的角色,缺乏一般知识常识及其职位所应具有的管理能力,爱说大话且富有向物理显示挑战的精神,大概长成下图这样。)

我在即将在 Apress 出版的新书 《The Linux Philosophy for SysAdmins》(LCTT 译注:暂译《系统管理员的 Linux 哲学》)中更详细地讨论如何成为一个懒惰的系统管理员,那书预计会在 9 月出版(LCTT 译注:已于 2018 年 8 月出版)。这本的部分内容摘录自该书,特别是第九章,“成为一名懒惰的系统管理员”。在我们讨论如何做到这点前,让我们简单了解一下成为一个名懒惰的系统管理员意味着什么。

真实生产力 vs. 虚假生产力

虚假生产力

在我工作的地方,半秃头老板相信的管理风格叫“ 走动式管理 management by walking around ”。通过判断某人在不在他的键盘上输入东西,或者至少要看看他们显示器上显示的东西,来判断他们的工作是否有效率。这是一个糟糕的工作场所。各部门间有道很高的行政墙,这会造就了许多的、微小的沟通壁垒,大量无用的文书工作,以及获得任何事情的许可都要等待漫长的时间。因为这样、那样的原因,不可能高效地做任何事情,如果真的是这样,那是非常低效。为了看起来很忙,我们都有自己的一套 “看起来很忙”的工具包 Look Busy Kits (LBK),可能是一些短小的、用来显示一些行为活动的 Bash 脚本,或者是 tophtopiotop 之类的程序,或者是一些持续显示某些行为活动的监控工具。这种工作场所的风气让人不可能真正高效,我讨厌这种地方,也讨厌那个几乎不可能完成任何有价值的事情的事实。

这种糟糕场所对真实的系统管理员来讲是场噩梦。没有人会感到快乐。在那里花费四五个月才能完成的事,在其他地方只需的一个早晨。我们没有什么实际工作要做,却要花大量的时间干活来让自己看起来很忙。我们在默默地竞赛,看谁能创造最好的“看起来很忙”的工具包,这就是我们花费最多时间的地方了。那份工作我只做了几个月,但好像已经耗费了一生。如果你看到的这个监狱的表面,你可能会说我们是很懒,因为我们只完成了几乎为 0 的实际工作。

这是个极端的例子,它完全与我所说的“我是一个懒惰的系统管理员”的意思相反,而做一个懒惰的系统管理是件好事。

真实生产力

我很幸运,曾为一些真正的管理者工作过 —— 他们明白,系统管理员的生产力并不是以每天花多少小时敲键盘来衡量。毕竟,即使一只猴子能敲击他们的键盘,但也不能说明结果的价值。

正如我书中所言:

“我是一个懒惰的系统管理员,同时我也是一个高效的系统管理员。这两者看似矛盾的说法不是相互排斥的,而是会以一种非常积极的方式相辅相成……

“系统管理员在思考的时候是最高效的 —— 思考关于如何解决现有问题和避免未来的问题;思考怎样监控 Linux 计算机,以便找到预测和预示这些未来的问题的线索;思考如何让他们的工作更有效率;思考如何自动化所有这些要执行的任务,无论是每天还是每年一次的任务。

“系统管理员冥思苦想的那一面是不会被非系统管理员所熟知的,那些人包括很多管理着系统管理员的人,比如那个半秃头老板。系统管理员都会以不同的方式解决他们工作中苦思的部分。一些我认识的系统管理员会在沙滩、骑自行车、参加马拉松或者攀岩时找到最好的想法。另一些人会认为静坐或听音乐的时候思考得最好。还有一些会在阅读小说、学习不相关的学科、甚至在学习 Linux 系统的时候可以最佳思考。关键是我们都有不同的方式激发我们的创造力,而这些创造力的推进器中很多并不涉及键盘上的任何一个按键。我们真正的生产力对于系统管理员周围的人来说可能是完全看不见的。”

成为懒惰的系统管理员有一些简单的秘诀 —— 系统管理员要完成一切需要完成的事,而且更多的是,当所有人都处于恐慌的状态时要保持冷静和镇定。秘诀的一部分是高效工作,另一部分是把预防问题放在首位。

成为懒惰系统管理员的方法

多思考

我相信关于懒惰系统管理员最重要的秘诀在于思考。正如上面的摘录所言,优秀的系统管理员会花大量的时候思考这些事情,如何更有效率地工作,在异常成为问题前如何定位,更聪明地工作,做其它事情的同时会考虑如何完成这些事情等等。

例如,除了撰写本文之外,我现在正在想一个项目,我打算在从亚马逊和本地计算机商店采购的新部件到达时才开始。我有一台不太关键的计算机上的主板坏了,最近它的崩溃更频率。但我的一台非常老的小服务器并没有出现故障,它负责处理我的电子邮件和外部网站,以及为我的网络的其余部分提供 DHCP 和 DNS 服务,但需要解决由于各种外部攻击而导致的间歇性过载。

我一开始想,我只要替换故障设备的主板及其直接部件:内存、CPU,可能还有电源。但是在考虑了一段时间之后,我决定将新部件放到服务器中,并将旧的(但仍然可用的)部件从服务器移到故障设备中。可以这样做的,只需一、两个小时就可以从服务器上移除旧部件并安装新的。然后我就可以花时间更换出故障的电脑里的部件了。太好了,所以我开始在脑海中列出要完成的任务。

然而,当我查看这个任务列表时,我意识到服务器中唯一不能替换的部件是机箱和硬盘驱动器,这两台计算机的机箱几乎完全相同。在有了这个小小的发现之后,我开始考虑用新的部件替换出了故障的计算机的部件,并将之作为我的服务器。经过一些测试之后,我只需从当前的服务器移除硬盘,并将它安装到用了新组件的机箱中,改下网络配置项,再更改 KVM 交换机端口上的主机名,并更改机箱上的主机名标签,就可以了。这将大大减少服务器停机时间,大大减少我的压力。此外,如果出现故障,我可以简单地将硬盘移回原来的服务器,直到我可以用新服务器解决问题为止。

所以,现在我在脑海中已经创建了一个完成这项工作我所需要做的任务清单。而且,我希望你能仔细观察,当我脑子里想着这一切的时候,我的手指从来没有碰过键盘。我新的心理行动计划风险很低,与我最初的计划相比,涉及的服务器停机时间要少得多。

当我在 IBM 工作的时候,我经常看到很多语言中都有写着“思考”的标语。思考可以节省时间和压力,是懒散的系统管理员的主要标志。

做预防性维护

在 1970 年代中期,我被 IBM 聘为客户工程师,我的领地由相当多的穿孔卡片设备组成。这也就是说,它们是处理打孔卡的重型机械设备,其中一些可以追溯到 20 世纪 30 年代。因为这些机器主要是机械的,所以它们的部件经常磨损或失调。我的部分工作是在它们损坏时修复它们。我工作的主要部分,也是最重要的部分,是首先要防止它们损坏。预防性维护的目的是在磨损部件损坏之前进行更换,并对还在运行的部件进行润滑和调整,以确保它们工作正常。

正如我在《系统管理员的 Linux 哲学》中所言:

“我在 IBM 的经理们明白这只是冰山一角;他们和我都知道,我的工作是让顾客满意。虽然这通常意味着修复损坏的硬件,但也意味着减少硬件损坏的次数。这对客户来说是好事,因为他们的机器在工作时工作效率更高。这对我有好处,因为我从那些快乐的客户那里接到的电话要少得多。我也睡了更多的觉,因为这样做的结果是更少的非工作时间的紧急电话。我是个懒惰的(客户工程师)。通过提前做额外的工作,从长远来看,我需要做的工作要少得多。

“这一原则已成为系统管理员的 Linux 哲学的功能原则之一。作为系统管理员,我们的时间最好用在最大限度地减少未来工作量的任务上。”

在 Linux 计算机中查找要解决的问题相当于项目管理。我检查系统日志,寻找以后可能会变得非常危险的问题的迹象。如果出现了一些小问题,或者我注意到我的工作站、服务器没有做出该有的响应,或者如果日志显示了一些不寻常的东西,所有这些都可以暗示出潜在的问题,而对于用户或半秃头老板来说,这些问题并没有产生明显的症状。

我经常检查 /var/log/ 中的文件,特别是 messagessecurity 文件。我最常见的问题之一是许多脚本小子在我的防火墙系统上尝试各种类型的攻击。而且,不,我不依赖 ISP 提供的调制解调器/路由器中的所谓的防火墙。这些日志包含了大量关于企图攻击来源的信息,非常有价值。但是要扫描不同主机上的日志并将解决方案部署到位,需要做大量的工作,所以我转向自动化。

自动化

我发现我的工作有很大一部分可以通过某种形式的自动化来完成。系统管理员的 Linux 哲学的原则之一是 “自动化一切”,这包括每天扫描日志文件等枯燥乏味的任务。

像是 Logwatch 这类的程序能够监控你的日志文件中的异常条目,并在异常条目发生时通知您。Logwatch 通常作为 cron 任务每天运行一次,并向本地主机上的 root 用户发送电子邮件。你可以从命令行运行 Logwatch,并立即在显示器上查看结果。现在我只需要每天查看 Logwatch 的电子邮件通知。

但现实是,仅仅收到通知是不够的,因为我们不能坐以待毙。有时需要立即作出反应。我喜欢的另一个程序是——它能为我做所有事(看,这就是懒惰的管理员)——它就是 Fail2ban。Fail2Ban 会扫描指定的日志文件,查找各种类型的黑客攻击和入侵尝试,如果它发现某个 IP 地址在持续做特定类型的活动,它会向防火墙添加一个条目,在指定的时间内阻止来自该 IP 地址的任何进一步的黑客尝试。默认值通常在 10 分钟左右,但我喜欢为大多数类型的攻击指定为 12 或 24 小时。每种类型的黑客攻击都是单独配置的,例如尝试通过 SSH 登录和那些 Web 服务器的攻击。

写脚本

自动化是这种哲学的关键组成部分之一。一切可以自动化的东西都应该自动化的,其余的尽可能地自动化。所以,我也写了很多脚本来解决问题,也就是说我编写了脚本来完成我的大部分工作。

我的脚本帮我节省了大量时间,因为它们包含执行特定任务的命令,这大大减少了我需要输入的数量。例如,我经常重新启动我的电子邮件服务器和垃圾邮件过滤软件(当修改 SpamAssassin 的 local.cf 配置文件时,就需要重启)。必须按特定顺序停止并重新启动这些服务。因此,我用几个命令编写了一个简短的脚本,并将其存储在可访问的 /usr/local/bin 中。现在,不用键入几个命令并等待每个命令都完成,然后再键入下一个命令,更不用记住正确的命令顺序和每个命令的正确语法,我输入一个三个字符的命令,其余的留给我的脚本来完成。

简化键入

另一种成为懒惰的系统管理员的方法是减少我们需要键入的数量。而且,我的打字技巧真的很糟糕(也就是说,我一点也没有,顶多是几个笨拙的手指)。导致错误的一个可能原因是我糟糕的打字技巧,所以我会尽量少打字。

绝大多数 GNU 和 Linux 核心实用程序都有非常短的名称。然而,它们都是有意义的名字。诸如用于更改目录的 cd 、用于列出目录内容的 ls 和用于磁盘转储的 dd 等工具都一目了然。短名字意味着更少的打字和更少的产生错误机会。我认为短的名字通常更容易记住。

当我编写 shell 脚本时,我喜欢保持名称简短而意义(至少对我来说是),比如用于 rsync 备份的 rsbu(LCTT 译注,Rsync Backup 的简写)。但在某些情况下,我喜欢使用更长的名称,比如 doUpdates 来执行系统更新。在后一种情况下,更长一点的名字让脚本的目的更明显。这可以节省时间,因为很容易记住脚本的名称。

其他减少键入的方法包括命令行别名、历史命令调回和编辑。别名只是你在 Bash shell 键入命令时才做的替换。键入 alias 命令会看到默认配置的别名列表。例如,当你输入命令 ls 时,会被条目 alias ls='ls –color=auto' 替成较长的命令,因此你只需键入 2 个字符而不是 14 个字符即可获得带有颜色的文件列表。还可以使用 alias 命令添加你自己定义的别名。

历史命令调回允许你使用键盘的向上和向下箭头键滚动浏览命令历史记录。如果需要再次使用相同的命令,只需在找到所需的命令时按回车键即可。如果在找到命令后需要更改该命令,则可以使用标准命令行编辑功能进行更改。

结束语

一名懒惰的系统管理员实际上也有很多的工作。但我们是聪明地工作,而不是刻苦工作。早在一堆小问题汇聚成大问题之前,我们就花时间探索我们负责的主机,并处理好所有的小问题。我们花了很多时间思考解决问题的最佳方法,我们也花了很多时间来发现新的方法,让自己更聪明地工作,成为懒惰的系统管理员。

除了这里描述的少数方法外,还有许多其他的方式可以成为懒惰的系统管理员。我相信你也有一些自己的方式;请在评论中和我们分享。


via: https://opensource.com/article/18/7/how-be-lazy-sysadmin

作者:David Both 选题:lujun9972 译者:zgj1024 校对:wxy

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