document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'LCTT/master'

Browse Source
This commit is contained in:
Xingyu.Wang 2019-02-05 22:10:30 +08:00
commit 4328a736cb
4 changed files with 196 additions and 194 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

87
published/20180809 Two Years With Emacs as a CEO (and now CTO).md Normal file
View File

@ -0,0 +1,87 @@
[#]: collector: (lujun9972)
[#]: translator: (oneforalone)
[#]: reviewer: (acyanbird wxy)
[#]: publisher: (wxy)
[#]: url: (https://linux.cn/article-10510-1.html)
[#]: subject: (Two Years With Emacs as a CEO (and now CTO))
[#]: via: (https://www.fugue.co/blog/2018-08-09-two-years-with-emacs-as-a-cto.html)
[#]: author: (Josh Stella https://www.fugue.co/blog/author/josh-stella)
作为 CEO 使用 Emacs 的两年经验之谈
======
两年前，我写了一篇[博客][1]，并取得了一些反响。这让我有点受宠若惊。那篇博客写的是我准备将 Emacs 作为我的主办公软件，当时我还是 CEO，现在已经是 CTO 了。现在回想起来，我发现我之前不是做程序员就是做软件架构师，而且那时我也喜欢用 Emacs 写代码。重新考虑使用 Emacs 是一次令我振奋的尝试，但我不太清楚这次行动会造成什么反响。在网上，那篇博客的评论也是褒贬不一，但是还是有数万的阅读量，所以总的来说，我写的是一个蛮有意思的题材。在 [Reddit][2] 和 [HackerNews][3] 上有些令人哭笑不得的回复，说我的手会变成鸡爪，或者说我会因白色的背景而近视。在这里我可以很高兴地回答，到目前为止并没有出现什么特别糟糕的后果，相反，我的手腕还因此变得更灵活了。还有一些人担心，说使用 Emacs 会耗费一个 CEO 的精力。把 Fugue 从一个在我家后院的灵感变成强大的产品，并有一大批忠实的顾客，我发现在做这种真正复杂之事的时候，Emacs 可以给你带来安慰。还有，我现在仍然在用白色的背景。
近段时间那篇博客又被翻出来了，并发到了 [HackerNews][4] 上。我收到了大量的跟帖者问我现在使用状况如何，所以我写了这篇博客来回应他们。在本文中，我还将重点讨论为什么 Emacs 和函数式编程有很高的关联性，以及我们是怎样使用 Emacs 来开发我们的产品 —— Fugue，一个使用函数式编程的自动化的云计算平台的。由于我收到了很多反馈，其众多细节和评论很有用，因此这篇博客比较长，而我确实也需要费点精力来解释我如此作为时的想法，但这篇文章的主要内容还是反映了我担任 CEO 时处理的事务。而我想在之后更频繁地用 Emacs 写代码，所以需要提前做一些准备。一如既往，本文因人而异，后果自负。
### 意外之喜
我大部分时间都在不断的处理公司内外沟通。交流是解决问题的唯一方法，但也是反思及思考困难或复杂问题的敌人。对我来说，作为创业公司的 CEO，最需要的是能专注工作而不被打扰的时间。一旦你决定投入时间来学习一些有用的命令，Emacs 就能帮助创造这种不被打扰的可贵环境。其他的应用会弹出提示，但是一个配置好了的 Emacs 可以完全不影响你 —— 无论是视觉上还是精神上。除非你想，否则的话它不会改变，况且没有比空白屏幕和漂亮的字体更干净的界面了。不断被打扰是我的日常状况，因此这种简洁让我能够专注于我在想的事情，而不是电脑本身。好的程序能够默默地操纵电脑，并且不会夺取你的注意力。
一些人指出，我原来的博客有太多对现代图形界面的批判和对 Emacs 的赞许。我既不赞同，也不否认。现代的界面，特别是那些以应用程序为中心的方法（相对于以内容为中心的方法），既不是以用户为中心的，也不是面向任务的。Emacs 避免了这种错误，这也是我如此喜欢它的部分原因，而它也带来了其他优点。Emacs 是带领你体会计算机魅力的传送门，一个值得跳下去的兔子洞（LCTT 译注：爱丽丝梦游仙境里的兔子洞，跳进去会有新世界）。它的核心是发现和创造属于自己的道路，对我来说这本身就是创造了。现代计算的悲哀之处在于，它很大程度上是由带有闪亮界面的黑盒组成的，这些黑盒提供的是瞬间的喜悦，而不是真正的满足感。这让我们变成了消费者，而不是技术的创造者。无论你是谁或者你的背景是什么；你都可以理解你的电脑，你可以用它创造事物。它很有趣，能令人满意，而且不是你想的那么难学!
我们常常低估了环境对我们心理的影响。Emacs 给人一种平静和自由的感觉，而不是紧迫感、烦恼或兴奋 —— 后者是思考和沉思的敌人。我喜欢那些持久的、不碍事的东西，当我花时间去关注它们的时候，它们会给我带来真知灼见。Emacs 满足我的所有这些标准。我每天都使用 Emacs 来工作，我也很高兴我很少需要注意到它。Emacs 确实有一个学习曲线，但不会比学自行车的学习曲线来的更陡，而且一旦你掌握了它，你会得到相应的回报，而且不必再去想它了。它赋予你一种其他工具所没有的自由感。这是一个优雅的工具，来自一个更加文明的计算时代。我很高兴我们步入了另一个文明的计算时代，我相信 Emacs 也将越来越受欢迎。
### 弃用 Org 模式处理日程和待办事项
在原来的文章中，我花了一些时间介绍如何使用 Org 模式来规划日程。不过现在我放弃了使用 Org 模式来处理待办事项一类的事物，因为我每天都有很多会议要开，很多电话要打，我也不能让其他人来适应我选的工具，而且也没有时间将事务转换或是自动移动到 Org 上。我们主要是 Mac 一族，使用谷歌日历等工具，而且原生的 Mac OS/iOS 工具可以很好的进行团队协作。我还有支老钢笔用来在会议中做笔记，因为我发现在会议中使用笔记本电脑或者说键盘记录很不礼貌，而且这也限制了我的聆听和思考。因此，我基本上放弃了用 Org 模式帮我规划日程或安排生活。当然，Org 模式对其他的方面也很有用，它是我编写文档的首选，包括本文。换句话说，我使用它的方式与其作者的想法背道而驰，但它的确做得很好。我也希望有一天也有人如此评价并使用我们的 Fugue。
### Emacs 已经在 Fugue 公司中扩散
我在上篇博客就有说，你可能会喜欢 Emacs，也可能不会。因此，当 Fugue 的文档组将 Emacs 作为标准工具时，我是有点担心的，因为我觉得他们可能是受了我的影响才做出这种选择。不过在两年后，我确信他们做出了正确的选择。文档组的组长是一个很聪明的程序员，但是另外两个编写文档的人却没有怎么接触过技术。我想，如果这是一个经理强迫员工使用错误工具的案例，我就会收到投诉要去解决它，因为 Fugue 有反威权文化，大家不怕挑战任何事和任何人。之前的组长在去年辞职了，但[文档组][5]现在有了一个灵活的集成的 CI/CD 工具链，并且文档组的人已经成为了 Emacs 的忠实用户。Emacs 有一条学习曲线，但即使在最陡的时候，也不至于多么困难，并且翻过顶峰后，对生产力和总体幸福感都得到了提升。这也提醒我们，学文科的人在技术方面和程序员一样聪明，一样能干，也许不那么容易受到技术崇拜与习俗产生的影响。
### 我的手腕感激我的决定
上世纪 80 年代中期以来，我每天花 12 个小时左右在电脑前工作，这给我的手腕（以及后背）造成了很大的损伤（因此我强烈安利 Tag Capisco 的椅子）。Emacs 和人机工程学键盘的结合让手腕的 [RSI][10]（<ruby>重复性压迫损伤<rt>Repetitive Strain Injury</rt></ruby>）问题消失了，我已经一年多没有想过这种问题了。在那之前，我的手腕每天都会疼，尤其是右手。如果你也有这种问题，你就知道这疼痛很让人分心和忧虑。有几个人问过关于选购键盘和鼠标的问题，如果你也对此有兴趣，那么在过去两年里，我主要使用的是 Truly Ergonomic 键盘，不过我现在用的是[这款键盘][6]。我已经换成现在的键盘有几个星期，而且我爱死它了。大写键的形状很神奇，因为你不用看就能知道它在哪里。而人体工学的拇指键也设计的十分合理，尤其是对于 Emacs 用户而言，Control 和 Meta 是你的坚实伴侣，不要再需要用小指做高度重复的任务了！
我使用鼠标的次数比使用 Office 和 IDE 时要少得多，这对我的工作效率有很大帮助，但我还是需要一个鼠标。我一直在使用外观相当过时，但功能和人体工程学非常优秀的 Clearly Superior 轨迹球，恰如其名。
撇开具体的工具不谈，事实证明，一个很棒的键盘，再加上避免使用鼠标，在减少身体的磨损方面很有效。Emacs 是达成这方面的核心，因为我不需要在菜单上滑动鼠标来完成任务，而且导航键就在我的手指下面。我现在十分肯定，我的手离开标准打字位置会给我的肌腱造成很大的压力。不过这也因人而异，我不是医生不好下定论。
### 我并没有做太多配置……
有人说我会在界面配置上耗费很多的时间。我想验证下他们说的对不对，所以我特别留意了下。我不仅在很多程度上不用配置，关注这个问题还让我意识到，我使用的其他工具是多么的耗费我的精力和时间。Emacs 是我用过的维护成本最低的软件。Mac OS 和 Windows 一直要求我更新它，但在我看来，这远没有 Adobe 套件和 Office 的更新给我带来的困扰那么大。我只是偶尔更新 Emacs，但对我来说它也没什么变化，所以从我的个人观点而言，更新基本上是一个接近于零成本的操作，我高兴什么时候更新就什么时候更新。
有一点让你们失望了，因为许多人想知道我为跟上重新打造的 Emacs 社区的更新做了些什么，但是在过去的两年中，我只在配置中添加了少部分内容。我认为这也是一种成功，因为 Emacs 只是一个工具，而不是我的爱好。但即便如此，如果你想和我分享关于 Emacs 的新鲜事物，我很乐意聆听。
### 期望实现云端控制
在我们 Fugue 公司有很多 Emacs 的粉丝，所以我们有一段时间在用 [Ludwing 模式][7]。Ludwig 模式是我们用于自动化云基础设施和服务的声明式、功能性的 DSL。最近，Alex Schoof 利用在飞机上和晚上的时间来构建 fugue 模式，它在 Fugue CLI 上充当 Emacs 控制台。要是你不熟悉 Fugue，这是我们开发的一个云自动化和治理工具，它利用函数式编程为用户提供与云的 API 交互的良好体验。但它做的不止这些。fugue 模式很酷的原因有很多，它有一个不断报告云基础设施状态的缓冲区，由于我经常修改这些基础设施，这样我就可以快速看到代码的效果。Fugue 将云工作负载当成进程处理，fugue 模式非常类似于为云工作负载设计的 `top` 工具。它还允许我执行一些操作，比如创建新的设备或删除过期的东西，而且也不需要太多输入。Fugue 模式只是个雏形，但它非常方便，而我现在也经常使用它。
![fugue-mode-edited.gif][8]
### 模式及监控
我添加了一些模式和集成插件，但并不是真正用于工作或 CEO 职能。我喜欢在周末时写写 Haskell 和 Scheme 娱乐，所以我添加了 haskell 模式和 geiser。Emacs 很适合拥有 REPL 的语言，因为你可以在不同的窗口中运行不同的模式，包括 REPL 和 shell。geiser 和 Scheme 很配，要是你还没有用过 Scheme，那么阅读《计算机程序的构造和解释》（SICP）也不失为一种乐趣，在这个有很多货物崇拜编程（LCTT 译注：是一种计算机程序设计中的反模式，其特征为不明就里地、仪式性地使用代码或程序架构）例子的时代，阅读此书或许可以启发你。安装 MIT Scheme 和 geiser，你就会感觉有点像 lore 的符号环境。
这就引出了我在 2015 年的文章中没有提到的另一个话题：屏幕管理。我喜欢使用单独一个纵向模式的显示器来写作，我在家里和我的主要办公室都有这个配置。对于编程或混合使用，我喜欢我们提供给所有 Fugue 人的新型超宽显示器。对于它来说，我更喜欢将屏幕分成三列，中间是主编辑缓冲区，左边是水平分隔的 shell 和 fugue 模式缓冲区，右边是文档缓冲区或另外一、两个编辑缓冲区。这个很简单，首先按 `Ctl-x 3` 两次，然后使用 `Ctl-x =` 使窗口的宽度相等。这将提供三个相等的列，你也可以使用 `Ctl-x 2` 对分割之后的窗口再次进行水平分割。以下是我的截图。
![Emacs Screen Shot][9]
### 这将是最后一篇 CEO/Emacs 文章
首先是因为我现在是 Fugue 的 CTO 而并非 CEO，其次是我有好多要写的博客主题，而我现在刚好有时间。我还打算写些更深入的东西，比如说函数式编程、基础设施即代码的类型安全，以及我们即将推出的一些 Fugue 的新功能、关于 Fugue 在云上可以做什么的博文等等。
--------------------------------------------------------------------------------
via: https://www.fugue.co/blog/2018-08-09-two-years-with-emacs-as-a-cto.html
作者：[Josh Stella][a]
选题：[lujun9972][b]
译者：[oneforalone](https://github.com/oneforalone)
校对：[acyanbird](https://github.com/acyanbird), [wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://www.fugue.co/blog/author/josh-stella
[b]: https://github.com/lujun9972
[1]: https://linux.cn/article-10401-1.html
[2]: https://www.reddit.com/r/emacs/comments/7efpkt/a_ceos_guide_to_emacs/
[3]: https://news.ycombinator.com/item?id=10642088
[4]: https://news.ycombinator.com/item?id=15753150
[5]: https://docs.fugue.co/
[6]: https://shop.keyboard.io/
[7]: https://github.com/fugue/ludwig-mode
[8]: https://www.fugue.co/hubfs/Imported_Blog_Media/fugue-mode-edited-1.gif
[9]: https://www.fugue.co/hs-fs/hubfs/Emacs%20Screen%20Shot.png?width=929&name=Emacs%20Screen%20Shot.png
[10]: https://baike.baidu.com/item/RSI/21509642

107
sources/talk/20150513 XML vs JSON.md
View File

@ -1,107 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (wwhio)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (XML vs JSON)
[#]: via: (https://www.cs.tufts.edu/comp/150IDS/final_papers/tstras01.1/FinalReport/FinalReport.html#xml-advantages)
[#]: author: (TOM STRASSNER tomstrassner@gmail.com)
XML vs JSON
======
### Introduction
XML and JSON are the two most common formats for data interchange in the Web today. XML was created by the W3C in 1996, and JSON was publicly specified by Douglas Crockford in 2002. Although their purposes are not identical, they are frequently used to accomplish the same task, which is data interchange. Both have well-documented open standards on the Web ([RFC 7159][1], [RFC 4825][2]), and both are human and machine-readable. Neither one is absolutely superior to the other, as each is better suited for different use cases.
### XML Advantages
There are several advantages that XML has over JSON. One of the biggest differences between the two is that in XML you can put metadata into the tags in the form of attributes. With JSON, the programmer could accomplish the same goal that metadata achieves by making the entity an object and adding the attributes as members of the object. However, the way XML does it may often be preferable, given the slightly misleading nature of turning something into an object that is not one in the client program. For example, if your C++ program sends an int via JSON and needs metadata to be sent along with it, you would have to make it an object, with one name/value pair for the actual value of the int, and more name/value pairs for each attribute. The program that receives the JSON would read it as an object, when in fact it is not one. While this is a viable solution, it defies one of JSON’s key advantages: “JSON's structures look like conventional programming language structures. No restructuring is necessary.”[2]
Although I will argue later that this can also be a drawback of XML, its mechanism to resolve name conflicts, prefixes, gives it power that JSON does not have. With prefixes, the programmer has the ability to name two different kinds of entities the same thing.[1] This would be advantageous in situations where the different entities should have the same name in the client program, perhaps if they are used in entirely different scopes.
Another advantage of XML is that most browsers render it in a highly readable and organized way. The tree structure of XML lends itself well to this formatting, and allows for browsers to let users to naturally collapse individual tree elements. This feature would be particularly useful in debugging.
One of the most significant advantages that XML has over JSON is its ability to communicate mixed content, i.e. strings that contain structured markup. In order to handle this with XML, the programmer need only put the marked-up text within a child tag of the parent in which it belongs. Similar to the metadata situation, since JSON only contains data, there is no such simple way to indicate markup. It would again require storing metadata as data, which could be considered an abuse of the format.
### JSON Advantages
JSON has several advantages as well. One of the most obvious of these is that JSON is significantly less verbose than XML, because XML necessitates opening and closing tags (or in some cases less verbose self-closing tags), and JSON uses name/value pairs, concisely delineated by “{“ and “}” for objects, “[“ and “]” for arrays, “,” to separate pairs, and “:” to separate name from value. Even when zipped (using gzip), JSON is still smaller and it takes less time to zip it.[6] As determined by Sumaray and Makki as well as Nurseitov, Paulson, Reynolds, and Izurieta in their experimental findings, JSON outperforms XML in a number of ways. First, naturally following from its conciseness, JSON files that contain the same information as their XML counterparts are almost always significantly smaller, which leads to faster transmission and processing. Second, difference in size aside, both groups found that JSON was serialized and deserialized drastically faster than XML.[3][4] Third, the latter study determined that JSON processing outdoes XML in CPU resource utilization. They found that JSON used less total resources, more user CPU, and less system CPU. The experiment used RedHat machines, and RedHat claims that higher user CPU usage is preferable.[3] Unsurprisingly, the Sumaray and Makki study determined that JSON performance is superior to XML on mobile devices too.[4] This makes sense, given that JSON uses less resources, and mobile devices are less powerful than desktop machines.
Yet another advantage that JSON has over XML is that its representation of objects and arrays allows for direct mapping onto the corresponding data structures in the host language, such as objects, records, structs, dictionaries, hash tables, keyed lists, and associative arrays for objects, and arrays, vectors, lists, and sequences for arrays.[2] Although it is perfectly possible to represent these structures in XML, it is only as a function of the parsing, and it takes more code to serialize and deserialize properly. It also would not always be obvious to the reader of arbitrary XML what tags represent an object and what tags represent an array, especially because nested tags can just as easily be structured markup instead. The curly braces and brackets of JSON definitively show the structure of the data. However, this advantage does come with the caveat explained above, that the JSON can inaccurately represent the data if the need arises to send metadata.
Although XML supports namespaces and prefixes, JSON’s handling of name collisions is less verbose than prefixes, and arguably feels more natural with the program using it; in JSON, each object is its own namespace, so names may be repeated as long as they are in different scopes. This may be preferable, as in most programming languages members of different objects can have the same name, because they are distinguished by the names of the objects to which they belong.
Perhaps the most significant advantage that JSON has over XML is that JSON is a subset of JavaScript, so code to parse and package it fits very naturally into JavaScript code. This seems highly beneficial for JavaScript programs, but does not directly benefit any programs that use languages other than JavaScript. However, this drawback has been largely overcome, as currently the JSON website lists over 175 tools for 64 different programming languages that exist to integrate JSON processing. While I cannot speak to the quality of most of these tools, it is clear that the developer community has embraced JSON and has made it simple to use in many different platforms.
### Purposes
Simply put, XML’s purpose is document markup. This is decidedly not a purpose of JSON, so XML should be used whenever this is what needs to be done. It accomplishes this purpose by giving semantic meaning to text through its tree-like structure and ability to represent mixed content. Data structures can be represented in XML, but that is not its purpose.
JSON’s purpose is structured data interchange. It serves this purpose by directly representing objects, arrays, numbers, strings, and booleans. Its purpose is distinctly not document markup. As described above, JSON does not have a natural way to represent mixed content.
### Software
The following major public APIs uses XML only: Amazon Product Advertising API.
The following major APIs use JSON only: Facebook Graph API, Google Maps API, Twitter API, AccuWeather API, Pinterest API, Reddit API, Foursquare API.
The following major APIs use both XML and JSON: Google Cloud Storage, Linkedin API, Flickr API
Of the top 10 most popular APIs according to Programmable Web[9], along with a couple more popular ones, only one supports XML and not JSON. Several support both, and several support only JSON. Among developer APIs for modern and popular websites, JSON clearly seems to be preferred. This also indicates that more app developers that use these APIs prefer JSON. This is likely a result of its reputation as the faster and leaner of the two. Furthermore, most of these APIs communicate data rather than documents, so JSON would be more appropriate. For example, Facebook is mainly concerned with communicating data about users and posts, Google Maps deals in coordinates and information about entities on their maps, and AccuWeather just sends weather data. Overall, it is impossible to say whether JSON or XML is currently used more in APIs, but the trend is certainly swinging towards JSON.[10][11]
The following major desktop software uses XML only: Microsoft Word, Apache OpenOffice, LibreOffice.
It makes sense for software that is mainly concerned with document creation, manipulation, and storage to use XML rather than JSON. Also, all three of these programs support mixed content, which JSON does not do well. For example, if a user is typing up an essay in Microsoft Word, they may put different font, size, color, positioning, and styling on different blocks of text. XML naturally represents these properties with nested tags and attributes.
The following major databases support XML: IBM DB2, Microsoft SQL Server, Oracle Database, PostgresSQL, BaseX, eXistDB, MarkLogic, MySQL.
The following major databases support JSON: MongoDB, CouchDB, eXistDB, Elastisearch, BaseX, MarkLogic, OrientDB, Oracle Database, PostgresSQL, Riak.
For a long time, SQL and the relational database model dominated the market. Corporate giants like Oracle and Microsoft have always marketed such databases. However, in the last decade, there has been a major rise in popularity of NoSQL databases. As this has coincided with the rise of JSON, most NoSQL databases support JSON, and some, such as MongoDB, CouchDB, and Riak use JSON to store their data. These databases have two important qualities that make them better suited for modern websites: they are generally more scalable than relational SQL databases, and they are designed to the core to run in the Web.[10] Since JSON is more lightweight and a subset of JavaScript, it suits NoSQL databases well, and helps facilitate these two qualities. In addition, many older databases have added support for JSON, such as Oracle Database and PostgresSQL. Conversion between XML and JSON is a hassle, so naturally, as more developers use JSON for their apps, more database companies have incentive to support it.[7]
### Future
One of the most heavily anticipated changes in the Internet is the “Internet of Things”, i.e. the addition to the Internet of non-computer devices such as watches, thermostats, televisions, refrigerators, etc. This movement is well underway, and is expected to explode in the near future, as predictions for the number of devices in the Internet of Things in 2020 range from about 26 billion to 200 billion.[12][13][13] Almost all of these devices are smaller and less powerful than laptop and desktop computers. Many of them only run embedded systems. Thus, when they have the need to exchange data with other entities in the Web, the lighter and faster JSON would naturally be preferable to XML.[10] Also, with the recent rapid rise of JSON use in the Web relative to XML, new devices may benefit more from speaking JSON. This highlights an example of Metcalf’s Law; whether XML or JSON or something entirely new becomes the most popular format in the Web, newly added devices and all existing devices will benefit much more if the newly added devices speak the most popular language.
With the creation and recent rapid increase in popularity of Node.js, a server-side JavaScript framework, along with NoSQL databases like MongoDB, full-stack JavaScript development has become a reality. This bodes well for the future of JSON, as with these new apps, JSON is spoken at every level of the stack, which generally makes the apps very fast and lightweight. This is a desirable trait for any app, so this trend towards full-stack JavaScript is not likely to die out anytime soon.[10]
Another existing trend in the world of app development is toward REST and away from SOAP.[11][15][16] Both XML and JSON can be used with REST, but SOAP exclusively uses XML.
The given trends indicate that JSON will continue to dominate the Web, and XML use will continue to decrease. This should not be overblown, however, because XML is still very heavily used in the Web, and it is the only option for apps that use SOAP. Given the widespread migration from SOAP to REST, the rise of NoSQL databases and full-stack JavaScript, and the far superior performance of JSON, I believe that JSON will soon be much more widely used than XML in the Web. There seem to be very few applications where XML is the better choice.
### References
1. [XML Tutorial](http://www.w3schools.com/xml/default.asp)
2. [Introducing JSON](http://www.json.org/)
3. [Comparison of JSON and XML Data Interchange Formats: A Case Study](http://www.cs.montana.edu/izurieta/pubs/caine2009.pdf)
4. [A comparison of data serialization formats for optimal efficiency on a mobile platform](http://dl.acm.org/citation.cfm?id=2184810)
5. [JSON vs. XML: The Debate](http://ajaxian.com/archives/json-vs-xml-the-debate)
6. [JSON vs. XML: Some hard numbers about verbosity](http://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity)
7. [How JSON sparked NoSQL -- and will return to the RDBMS fold](http://www.infoworld.com/article/2608293/nosql/how-json-sparked-nosql----and-will-return-to-the-rdbms-fold.html)
8. [Did You Say "JSON Support" in Oracle 12.1.0.2?](https://blogs.oracle.com/OTN-DBA-DEV-Watercooler/entry/did_you_say_json_support)
9. [Most Popular APIs: At Least One Will Surprise You](http://www.programmableweb.com/news/most-popular-apis-least-one-will-surprise-you/2014/01/23)
10. [Why JSON will continue to push XML out of the picture](https://www.centurylinkcloud.com/blog/post/why-json-will-continue-to-push-xml-out-of-the-picture/)
11. [Thousands of APIs Paint a Bright Future for the Web](http://www.webmonkey.com/2011/03/thousand-of-apis-paint-a-bright-future-for-the-web/)
12. [A Simple Explanation Of 'The Internet Of Things’](http://www.forbes.com/sites/jacobmorgan/2014/05/13/simple-explanation-internet-things-that-anyone-can-understand/)
13. [Proofpoint Uncovers Internet of Things (IoT) Cyberattack](http://www.proofpoint.com/about-us/press-releases/01162014.php)
14. [The Internet of Things: New Threats Emerge in a Connected World](http://www.symantec.com/connect/blogs/internet-things-new-threats-emerge-connected-world)
15. [3,000 Web APIs: Trends From A Quickly Growing Directory](http://www.programmableweb.com/news/3000-web-apis-trends-quickly-growing-directory/2011/03/08)
16. [How REST replaced SOAP on the Web: What it means to you](http://www.infoq.com/articles/rest-soap)
--------------------------------------------------------------------------------
via: https://www.cs.tufts.edu/comp/150IDS/final_papers/tstras01.1/FinalReport/FinalReport.html#xml-advantages
作者：[TOM STRASSNER][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: tomstrassner@gmail.com
[b]: https://github.com/lujun9972
[1]: https://tools.ietf.org/html/rfc7159
[2]: https://tools.ietf.org/html/rfc4825

109
translated/talk/20150513 XML vs JSON.md Normal file
View File

@ -0,0 +1,109 @@
[#]: collector: (lujun9972)
[#]: translator: (wwhio)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (XML vs JSON)
[#]: via: (https://www.cs.tufts.edu/comp/150IDS/final_papers/tstras01.1/FinalReport/FinalReport.html)
[#]: author: (TOM STRASSNER tomstrassner@gmail.com)
XML vs JSON
======
### 简介
XML 和 JSON 是现今互联网中最常用的两种数据交换格式。XML 格式由 W3C 于 1996 年提出。JSON 格式由 Douglas Crockford 于 2020 年提出。虽然这两种格式的设计目标并不相同，但它们常常用于数据交换中。XML 和 JSON 的文档都很完善([RFC 7159][1], [RFC 4825][2])，且都同时具有<ruby>人类可读性<rt>human-readable</rt></ruby>和<ruby>机器可读性<rt>machine-readable</rt></ruby>。这两种格式并没有哪一个比另一个更强，只是各自适用的领域不用。（LCTT译注：W3C 是[互联网联盟](https://www.w3.org/)，制定了各种 Web 相关的标准，如 HTML、CSS 等。Douglas Crockford 除了制定了 JSON 格式，还致力于改进 JavaScript，开发了 JavaScript 相关工具 [JSLint](http://jslint.com/) 和 [JSMin](http://www.crockford.com/javascript/jsmin.html)。）
### XML 的优点
XML 与 JSON 相比有很多优点。二者间最大的不同在于 XML 可以通过在标签中添加属性这一简单的方法来存储<ruby>元数据<rt>metadata</rt></ruby>。而使用 JSON 时需要创建一个对象，把元数据当作对象的成员来存储。虽然二者都能达到存储元数据的目的，但在这一情况下 XML 往往是更好的选择，因为 JSON 的表达形式会让客户端程序开发人员误以为要将数据转换成一个对象。举个例子，如果你的 C++ 程序需要使用 JSON 格式发送一个附带元数据的整型数据，需要创建一个对象，用对象中的一个<ruby>名称/值对<rt>name/value pair</rt></ruby>来记录整型数据的值，再为每一个附带的属性添加一个名称/值对。接收到这个 JSON 的程序在读取后很可能把它当成一个对象，可事实并不是这样。虽然这是使用 JSON 传递元数据的一种变通方法，但他违背了 JSON 的核心理念：“<ruby>JSON 的结构与常规的程序语言中的结构相对应，而无需修改。<rt>JSON's structures look like conventional programming language structures. No restructuring is necessary.</rt></ruby>”[2]
虽然稍后我会说这也是 XML 的一个缺点，但 XML 中对命名冲突、<ruby>前缀<rt>prefix</rt></ruby>的处理机制赋予了它 JSON 所不具备的能力。程序员们可以通过前缀来把统一名称给予两个不同的实体。[1]当不同的实体在客户端中使用的名称相同时，这一特性会非常有用。
XML 的另一个优势在于大多数的浏览器可以把它以<ruby>具有高可读性和强组织性的方式<rt>highly readable and organized way</rt></ruby>展现给用户。XML 的树形结构让它易于结构化，浏览器也让用户可以自行展开或折叠树中的元素，这简直就是调试的福音。
XML 对比 JSON 有一个很重要的优势就是它可以记录<ruby>混合内容<rt>mixed content</rt></ruby>。例如在 XML 中处理包含结构化标记的字符串时，程序员们只要把带有标记的文本放在一个标签内就可以了。可因为 JSON 只包含数据，没有用于指明标签的简单方式，虽然可以使用处理元数据的解决方法，但这总有点滥用之嫌。
### JSON 的优点
JSON 自身也有很多优点。其中最显而易见的一点就是 JSON 比 XML 简洁得多。因为 XML 中需要标签的打开和关闭，而 JSON 使用名称/值对表示数据，使用简单的“{”和“}”来标记对象，“\[”和“\]”来标记数组，“,”来表示数据的分隔，“:”表示名称和值的分隔。就算是使用 gzip 压缩，JSON 还是比 XML 要小，而且耗时更少。[6]正如 Sumaray 和 Makki 在实验中指出的那样，JSON 在很多方面都比 XML 更具优势，得出同样结果的还有 Nurseitov、Paulson、Reynolds 和 Izurieta。首先，由于 JSON 文件天生的简洁性，与包含相同信息的 XML 相比，JSON 总是更小，这意味着更快的传输和处理速度。第二，在不考虑大小的情况下，两组研究[3][4]表明使用 JSON 执行序列化和反序列化的速度显著优于使用 XML。第三，后续的研究指出 JSON 的处理在 CPU 资源的使用上也优于 XML。研究人员发现 JSON 在总体上使用的资源更少，其中更多的 CPU 资源消耗在用户空间，系统空间消耗的 CPU 资源较少。这一实验是在 RedHat 的设备上进行的，RedHat 表示更倾向于在用户空间使用 CPU 资源。[3]不出意外，Sumaray 和 Makki 在研究里还说明了在移动设备上 JSON 的性能也优于 XML。[4]这很直接，因为 JSON 消耗的资源更少，移动设备的性能也更弱。
JSON 的另一个优点在于其对对象和数组的表述和<ruby>宿主语言<rt>host language</rt></ruby>中的数据结构相对应，例如<ruby>对象<rt>object</rt></ruby>、<ruby>记录<rt>record</rt></ruby>、<ruby>结构体<rt>struct</rt></ruby>、<ruby>字典<rt>dictionary</rt></ruby>、<ruby>哈希表<rt>hash table</rt></ruby>、<ruby>键值列表<rt>keyed list</rt></ruby>还有<ruby>数组<rt>array</rt></ruby>、<ruby>向量<rt>vector</rt></ruby>、<ruby>列表<rt>list</rt></ruby>，以及对象组成的数组等等。[2] 虽然 XML 里也能表达这些数据结构，也只需调用一个函数就能完成解析，但往往需要更多的代码才能正确的完成 XML 的序列化和反序列化处理。而且 XML 对于人类来说不如 JSON 那么直观，XML 标准缺乏对象、数组的标签的明确定义。当结构化的标记可以替代嵌套的标签时，JSON 的优势极为突出。JSON 中的花括号和中括号则明确表示了数据的结构，当然这一优势也包含前文中的问题，在表示元数据时 JSON 不如 XML 准确。
虽然 XML 支持<ruby>命名空间<rt>namespace</rt></ruby>与<ruby>前缀<rt>prefix</rt></ruby>，但这不代表 JSON 没有处理命名冲突的能力。比起 XML 的前缀，它处理命名冲突的方式更简洁，在程序中的处理也更自然。在 JSON 里，每一个对象都在它自己的命名空间中，因此不同对象内的元素名称可以随意重复。在大多数编程语言中，不同的对象中的成员可以包含相同的名字，所以 JSON 根据对象进行名称区分的规则在处理时更加自然。
也许 JSON 比 XML 更优的部分是因为 JSON 是 JavaScript 的子集，所以在 JavaScript 代码中对它的解析或封装都非常的自然。虽然这看起来对 JavaScript 程序非常有用，而其他程序则不能直接从中获益，可实际上这一问题已经被很好的解决了。现在 JSON 的网站的列表上展示了 64 种不同语言的 175 个工具，它们都实现了处理 JSON 所需的函数。虽然我不能评价大多数工具的质量，但它们的存在明确了开发者社区拥抱 JSON 这一现象，而且它们切实简化了在不同平台使用 JSON 的难度。
### 二者的动机
简单地说，XML 的目标是完成一种文档标记。这和 JSON 的目标想去甚远，所以只要用得到 XML 的地方就尽管用。它使用树形的结构和包含语义的文本来表达混合内容以实现这一目标。在 XML 中可以表示数据的结构，但这并不是它的长处。
JSON’s purpose is structured data interchange. It serves this purpose by directly representing objects, arrays, numbers, strings, and booleans. Its purpose is distinctly not document markup. As described above, JSON does not have a natural way to represent mixed content.
JSON 的目标是用于数据交换的一种结构化表示。它直接使用对象、数组、数字、字符串、布尔值这些元素来达成这一目标。这完全不同于文档标记语言。正如上面说的那样，JSON 没有原生支持<ruby>混合内容<rt>mixed content</rt></ruby>的记录。
### 软件
这些主流的开放 API 仅提供 XML：<ruby>亚马逊产品广告 API<rt>Amazon Product Advertising API</rt></ruby>。
这些主流 API 仅提供 JSON：<ruby>脸书图 API<rt>Facebook Graph API</rt></ruby>，<ruby>谷歌地图 API<rt>Google Maps API</rt></ruby>，<ruby>推特 API<rt>Twitter API</rt></ruby>，AccuWeather API，Pinterest API，Reddit API，Foursquare API。
这些主流 API 同时提供 XML 和 JSON：<ruby>谷歌云存储<rt>Google Cloud Storage</rt></ruby>，<ruby>领英 API<rt>Linkedin API</rt></ruby>，Flickr API。
根据<ruby>可编程网络<rt>Programmable Web</rt></ruby>[9]的数据，最流行的 10 个 API 中只有一个是仅提供 XML 且不支持 JSON 的。其他的要么同时支持 XML 和 JSON，要么只支持 JSON。这表明了大多数应用开发者都更倾向于使用支持 JSON 的 API，原因大概是 JSON 更快的处理速度与良好口碑，加之与 XML 相比更加轻量。此外，大多数 API 只是传递数据而非文档，所以 JSON 更加合适。例如 Facebook 的重点在于用户的交流与帖子，谷歌地图则主要处理坐标和地图信息，AccuWeather 就只传递天气数据。总之，虽然不能说天气 API 在使用时究竟是 JSON 用的多还是 XML 用的多，但是趋势明确偏向了 JSON。[10][11]
这些主流的桌面软件仍然只是用 XML：Microsoft Word，Apache OpenOffice，LibraOffice。
因为这些软件需要考虑引用、格式、存储等等，所以比起 JSON，XML 优势更大。另外，这三款程序都支持混合内容，而 JSON 在这一点上做得并不如 XML 好。举例说明，当用户使用 Microsoft Word 编辑一篇论文时，用户需要使用不同的文字字形、文字大小、文字颜色、页边距、段落格式等，而 XML 结构化的组织形式与标签属性生来就是为了表达这些信息的。
这些主流的数据库支持 XML：IBM DB2，Microsoft SQL Server，Oracle Database，PostgresSQL，BaseX，eXistDB，MarkLogic，MySQL。
这些是支持 JSON 的主流数据库：MongoDB，CouchDB，eXistDB，Elastisearch，BaseX，MarkLogic，OrientDB，Oracle Database，PostgresSQL，Riak。
在很长一段时间里，SQL 和关系型数据库统治着整个数据库市场。像<ruby>甲骨文<rt>Oracle</rt></ruby>和<ruby>微软<rt>Microsoft</rt></ruby>这样的软件巨头都提供这类数据库，然而近几年 NoSQL 数据库正逐步受到开发者的青睐。也许是正巧碰上了 JSON 的普及，大多数 NoSQL 数据库都支持 JSON，像 MongoDB、CouchDB 和 Riak 这样的数据库甚至使用 JSON 来存储数据。这些数据库有两个重要的特性是它们适用于现代网站：一是它们与关系型数据库相比<ruby>更容易扩展<rt>more scalable</rt></ruby>；二是它们设计的目标就是 web 运行所需的核心组件。由于 JSON 更加轻量，又是 JavaScript 的子集，所以很适合 NoSQL 数据库，并且让这两个品质更容易实现。此外，许多旧的关系型数据库增加了 JSON 支持，例如 Oracle Database 和 PostgresSql。由于 XML 与 JSON 间的转换比较麻烦，所以大多数开发者会直接在他们的应用里使用 JSON，因此开发数据库的公司才有支持 JSON 的理由。（LCTT译注：NoSQL是对不同于传统的关系数据库的数据库管理系统的统称。[参考来源](https://zh.wikipedia.org/wiki/NoSQL)）
### 未来
对互联网的种种变革中，最让人期待的便是<ruby>物联网<rt>Internet of Things</rt></ruby>。这会给互联网带来大量计算机之外的设备，例如手表、温度计、电视、冰箱等等。这一势头的发展良好，预期在不久的将来迎来爆发式的增长。据估计，到 2020 年时会有 260 亿 到 2000 亿的物联网设备被接入互联网。[12][13] 几乎所有的物联网设备都是小型设备，因此性能比笔记本或台式电脑要弱很多，而且大多数都是嵌入式系统。因此，当他们需要与互联网上的系统交换数据时，更轻量，更快速的 JSON 自然比 XML 更受青睐。[10] 受益于 JSON 在 web 上的快速普及，与 XML 相比，这些新的物联网设备更有可能从使用 JSON 中受益。这是一个典型的梅特卡夫定律的例子，无论是 XML 还是 JSON，抑或是什么其他全新的格式，现存的设备和新的设备都会从支持最广泛使用的格式中受益。
Node.js 是一款服务器端的 JavaScript 框架，随着她的诞生与快速成长，与 MongoDB 等 NoSQL 数据库一起，让全栈使用 JavaScript 开发成为可能。这些都预示着 JSON 光明的未来，这些软件的出现让 JSON 运用在全栈开发的每一个环节成为可能，这将使应用更加轻量，响应更快。这也是任何应用的追求之一，所以，全栈使用 JavaScript 的趋势在不久的未来都不会消退。[10]
此外，另一个应用开发的趋势是从 SOAP 转向 REST。[11][15][16] XML 和 JSON 都可以用于 REST，可 SOAP 只能使用 XML。
从这些趋势中可以推断，JSON 的发展将统一 Web 的信息交换格式，XML 的使用率将继续降低。虽然不应该把 JSON 吹过头了，因为 XML 在 Web 中的使用依旧很广，而且它还是 SOAP 的唯一选择，可考虑到 SOAP 到 REST 的迁移，NoSQL 数据库和全栈 JavaScript 的兴起，JSON 卓越的性能，我相信 JSON 很快就会在 Web 开发中超过 XML。至于其他领域，XML 比 JSON 更好的情况并不多。
### 参考链接
1. [XML Tutorial](http://www.w3schools.com/xml/default.asp)
2. [Introducing JSON](http://www.json.org/)
3. [Comparison of JSON and XML Data Interchange Formats: A Case Study](http://www.cs.montana.edu/izurieta/pubs/caine2009.pdf)
4. [A comparison of data serialization formats for optimal efficiency on a mobile platform](http://dl.acm.org/citation.cfm?id=2184810)
5. [JSON vs. XML: The Debate](http://ajaxian.com/archives/json-vs-xml-the-debate)
6. [JSON vs. XML: Some hard numbers about verbosity](http://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity)
7. [How JSON sparked NoSQL -- and will return to the RDBMS fold](http://www.infoworld.com/article/2608293/nosql/how-json-sparked-nosql----and-will-return-to-the-rdbms-fold.html)
8. [Did You Say "JSON Support" in Oracle 12.1.0.2?](https://blogs.oracle.com/OTN-DBA-DEV-Watercooler/entry/did_you_say_json_support)
9. [Most Popular APIs: At Least One Will Surprise You](http://www.programmableweb.com/news/most-popular-apis-least-one-will-surprise-you/2014/01/23)
10. [Why JSON will continue to push XML out of the picture](https://www.centurylinkcloud.com/blog/post/why-json-will-continue-to-push-xml-out-of-the-picture/)
11. [Thousands of APIs Paint a Bright Future for the Web](http://www.webmonkey.com/2011/03/thousand-of-apis-paint-a-bright-future-for-the-web/)
12. [A Simple Explanation Of 'The Internet Of Things’](http://www.forbes.com/sites/jacobmorgan/2014/05/13/simple-explanation-internet-things-that-anyone-can-understand/)
13. [Proofpoint Uncovers Internet of Things (IoT) Cyberattack](http://www.proofpoint.com/about-us/press-releases/01162014.php)
14. [The Internet of Things: New Threats Emerge in a Connected World](http://www.symantec.com/connect/blogs/internet-things-new-threats-emerge-connected-world)
15. [3,000 Web APIs: Trends From A Quickly Growing Directory](http://www.programmableweb.com/news/3000-web-apis-trends-quickly-growing-directory/2011/03/08)
16. [How REST replaced SOAP on the Web: What it means to you](http://www.infoq.com/articles/rest-soap)
--------------------------------------------------------------------------------
via: https://www.cs.tufts.edu/comp/150IDS/final_papers/tstras01.1/FinalReport/FinalReport.html
作者：[TOM STRASSNER][a]
选题：[lujun9972][b]
译者：[wwhio](https://github.com/wwhio)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: tomstrassner@gmail.com
[b]: https://github.com/lujun9972
[1]: https://tools.ietf.org/html/rfc7159
[2]: https://tools.ietf.org/html/rfc4825

87
translated/talk/20180809 Two Years With Emacs as a CEO (and now CTO).md
View File

@ -1,87 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (oneforalone)
[#]: reviewer: (acyanbird)
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Two Years With Emacs as a CEO (and now CTO))
[#]: via: (https://www.fugue.co/blog/2018-08-09-two-years-with-emacs-as-a-cto.html)
[#]: author: (Josh Stella https://www.fugue.co/blog/author/josh-stella)
作为 CEO 使用 Emacs 的两年经验之谈（现任 CTO）
======
两年前，我写了一篇[博客][1]，并取得了一些反响。这让我有点受宠若惊。那篇博客写的是我准备将 Emacs 作为我的主办公软件，当时我还是 CEO，现在已经是 CTO 了。现在回想起来，我发现我之前不是做程序员就是做软件架构师，而且那时我也喜欢用 Emacs 写代码。重新考虑使用 Emacs 是一次令我振奋的尝试，但我不太清楚这次行动会造成什么反响。在网上，那篇博客的评论也是褒贬不一，但是还是有数万的阅读量，所以总的来说，我写的是一个蛮有意思的题材。在 [Reddit][2] 和 [HackerNews][3] 上有些令人哭笑不得的回复，说我的手会变形，或者说我会因白色的背景而近视。在这里我可以很高兴地回答，到目前为止并没有出现什么特别糟糕的后果，相反，我的手腕还因此变得更灵活了。还有一些人担心，说使用 Emacs 会耗费一个 CEO 的精力。把 Fugue 从在家得到的想法变成强大的产品，并有一大批忠实的顾客。在做这种真正复杂之事的时候，Emacs 可以给你带来安慰。还有，我现在仍然在用白色的背景。
近段时间那篇博客又被翻出来了，并发到了 [HackerNews][4] 上。我收到了大量的跟帖者问我现在使用状况如何，所以我写了这篇博客来回应他们。在本文中，我还将重点讨论为什么 Emacs 和函数式编程有很高的关联性，以及我们是怎样使用 Emacs 来开发我们的产品 —— Fugue，一个使用函数式编程的自动化的云计算平台的。由于我收到了很多反馈，他们表示博客里的众多细节和评论很有用，因此这篇博客比较长，而我确实也需要费点精力来解释我如此作为时的想法，但这篇文章的主要内容还是反映了我担任 CEO 时处理的事务。而我想在之后更频繁地用 Emacs 写代码，所以需要提前做一些准备。一如既往，本文因人而异，后果自负。
### 意外之喜
我大部分时间都在不断得处理公司内外沟通。交流是解决问题的唯一方法，但也是反思及思考困难或是复杂问题的敌人。对我来说，作为创业公司的 CEO，最需要的是能专注工作而不被打扰的时间。一旦你决定投入时间来学习一些有用的命令，Emacs 就能帮助创造这种不被打扰的可贵环境。其他的应用会弹出提示，但是一个配置好了的 Emacs 可以被你完全的忽略掉 —— 无论是视觉上还是精神上。除非你想修改，否则的话他不会改变，况且没有比空白屏幕和漂亮的字体更干净的界面了。不断被打扰是我的日常，因此这种简洁让我能够专注于我在想的事情，而不是电脑本身。好的程序能够默默地操纵电脑，并且不会夺取你的注意力。
一些人指出，我原来的博客既是对现代图形界面的批判，也是对 Emacs 的赞许。我既不赞同，也不否认。现代的接口，特别是那些以应用程序为中心的方法(相对于以内容为中心的方法)，既不是以用户为中心的，也不是面向进程的。Emacs 避免了这种错误，这也是我如此喜欢它的部分原因，而它也带来了其他优点。Emacs 是带领你体会计算机魅力的传送门，一个值得跳下去的兔子洞（校对注：爱丽丝梦游仙境里的兔子洞，跳进去会有新世界）。它的核心是发现和创造属于自己的道路，对我来说这就是创造本身了。现代电脑的悲哀之处在于，它很大程度上是由带有闪亮界面的黑盒组成的，这些黑盒提供的是瞬间的喜悦，而不是真正的满足感。这让我们变成了消费者，而不是技术的创造者。我不在乎你是谁或者你的背景是什么;你可以理解你的电脑，你可以用它创造事物。它很有趣，能令人满意，而且不是你想的那么难学!
我们常常低估了环境对我们心理的影响。Emacs 给人一种平静和自由的感觉，而不是紧迫感、烦恼或兴奋 —— 后者是思想和沉思的敌人。我喜欢那些持久的，不碍事的东西，当我花时间去关注它们的时候，它们会给我带来真知灼见。Emacs 满足我的所有这些标准。我每天都使用 Emacs 来创建内容，我也很高兴我很少考虑它。Emacs 确实有一个学习曲线，但不会比学自行车的学习曲线来的更陡，而且一旦你完成了它，你会得到相应的回报，而且不必再去想它了。它赋予你一种其他工具所没有的自由感。这是一个优雅的工具，来自一个更加文明的时代。我很高兴我们步入了另一个文明的计算机时代，我相信 Emacs 也将越来越受欢迎。
### 放弃用 Emacs 规划日程及处理待办事项
在原来的文章中，我花了一些时间介绍如何使用 Org 模式来规划日程。不过现在我放弃了使用 Org 模式来处理待办事项一类的事物,因为我每天都有很多会要开，很多电话要打, 我也不能让其他人来适应我选的工具，而且也没有时间将事务转换或是自动移动到 Org 上。我们主要使用 Mac shop，谷歌日历，原生的 Mac OS/iOS 工具可以很好的进行团队协作。我还有支旧笔用来在会议中做笔记，因为我发现在会议中使用笔记本电脑或者说键盘记录很不礼貌，而且这也限制了我的聆听和思考。因此，我基本上放弃了用 Org 帮我规划日程或安排生活。当然，Org 模式对其他的方面也很有用，它是我编写文档的首选，包括本文。换句话说，我使用它的方式与其作者的想法背道而驰，但它的确做得很好。我也希望有一天也有人如此评价并使用我们的 Fugue。
### Emacs 已经在 Fugue 中扩散
我在上篇博客就有说，你可能会喜欢 Emacs，也可能不会。因此，当 Fugue 的文档组将 Emacs 作为标准工具时，我是有点担心的，因为我觉得他们可能是受了我的影响才做出这种选择。不过在几年后，我确信他们做出了正确的选择。文档组的组长是一个很聪明的程序员，但是另外两个编写文档的人却没有怎么接触过技术。我想，如果这是一个经理强迫员工使用错误工具的案例，我就会被投诉并去解决，因为 Fugue 有反威权文化，大家不怕惹麻烦。之前的组长在去年辞职了，但[文档组][5]现在有了一个灵活的集成的 CI/CD 工具链，并且文档组的人已经成为了 Emacs 的忠实用户。Emacs 有一条学习曲线，但即使在最陡的时候，也不至于多么困难，并且翻过顶峰后，对生产力和总体幸福感都得到了提升。这也提醒我们，学文科的人在技术方面和程序员一样聪明，一样能干，也许不那么容易受到技术崇拜与类别隔阂产生的影响。
### 我的手腕感激我的决定
上世纪80年代中期以来，我每天花12个小时左右在电脑前工作，这给我的手腕（以及后背）造成了很大的损伤，因此我强烈安利 Tag Capisco 的椅子。Emacs 和人机工程学键盘的结合让手腕的 [RSI][10](Repetitive Strain Injury/Repetitive Motion Syndrome) 问题消失了，我已经一年多没有想过这种问题了。在那之前，我的手腕每天都会疼，尤其是右手。如果你也有这种问题，你就知道这疼痛很让人分心和忧虑。有几个人问过关于选购键盘和鼠标的问题，如果你也对此有兴趣，那么在过去的几年里，我主要使用的是真正符合人体工程学的键盘，不过我现在用的是[这款键盘][6]。我已经换成现在的键盘有几个星期，而且我爱死它了。键帽的形状很神奇，因为你不用看就能知道自己的手指放在哪里。而拇指键也设计的十分合理，尤其是对于 Emacs 用户而言。Control 和 Meta 是你的固定伙伴，不要再用小指做高度重复的任务了!
我使用鼠标的次数比使用 Office 和 IDE 时要少得多，这对我的工作效率有很大帮助。但我还是需要一个鼠标。我一直在使用外观相当过时，但功能和人体工程学非常优秀的高级轨迹球。
撇开具体的工具不谈，事实证明，一个很棒的键盘，再加上避免使用鼠标，在减少身体的磨损方面很有效。Emacs 是达成这方面的核心，因为我不需要在菜单上滑动鼠标来完成任务，而且导航键就在我的手指下面。我现在十分肯定，我的手离开标准打字姿势会给我的肌腱造成很大的压力。不过这也因人而异，我不是医生不好下定论。
### 我并没有做太多配置……
有人说我会在界面配置上花很多的时间。我想验证下他们说的对不对，所以我特别留意了下。我不仅让配置基本上不受影响，关注这个问题还让我意识到，我使用的其他工具是多么的耗费我的精力和时间。Emacs 是我用过的维护成本最低的软件。Mac OS 和 Windows 一直要求我更新它，但在我看来，这远没有 Adobe 套件和 Office 的更新给我带来的困恼那么大。我只是偶尔更新 Emacs，但对我来说它也没什么变化。所以从我的个人观点而言，更新基本上是一个接近于零成本的操作，我高兴什么时候更新就什么时候更新。
有一点然你们失望了，因为许多人想知道我为跟上 Emacs 社区的更新及其输出所做的事情，但是在过去的两年中，我只在配置中添加了少部分内容。我认为也是一种成功，因为 Emacs 只是一个工具，而不是我的爱好。但即便如此，如果你想和我分享关于 Emacs 的新鲜事物，我很乐意聆听。
### 期望实现控制云端
Fugue 用户中有很多 Emacs 的粉丝，所以我们有一段时间在用 [Ludwing 模式][7]。Ludwig 是我们用于自动化云基础设施和服务的声明式、功能性的 DSL。最近，Alex Schoof 利用飞机上和晚上的时间来构建 fugue 模式，它在 Fugue CLI 上充当 Emacs 控制台。要是你不熟悉 Fugue，我们会开发一个云自动化和管理工具，它利用函数式编程为用户提供与云的 API 交互的良好体验。但它做的不止这些。fugue 模式很酷的原因有很多，它有一个不断报告云基础设备状态的缓冲区，由于我经常修改这些设备，所以我可以快速看到编码的效果。Fugue 将云工作负载当成进程处理，fugue 模式非常类似于为云工作负载设计的 top 工具。它还允许我执行一些操作，比如创建新的设备或删除过期的东西，而且也不需要太多输入。Fugue 模式只是个雏形，但它非常方便，而我现在也经常使用它。
![fugue-mode-edited.gif][8]
### 模式及监听
我添加了一些模式和集成插件，但并不是真正用于 CEO 工作。我喜欢在周末时写写 Haskell 和 Scheme 娱乐，所以我添加了 haskell 模式和 geiser。Emacs 对具有 REPL 的语言很友好，因为你可以在不同的窗口中运行不同的模式，包括 REPL 和 shell，Geiser 和 Scheme 很配。要是你还没有用过 Scheme，那么阅读<ruby>《计算机程序的构造和解释》<rt>SICP</rt></ruby>也不失为一种乐趣，在这个有很多货物崇拜编程（校对注：是一种计算机程序设计中的反模式，其特征为不明就里地、仪式性地使用代码或程序架构）例子的时代，阅读此书或许可以启发你。安装 MIT Scheme 和 geiser，你就会感觉有点像 lore 的符号环境。
这就引出了我在 2015 年的文章中没有提到的另一个话题:屏幕管理。我喜欢使用单独一个带肖像模式显示器来写作，我在家里和我的主要办公室都有这个配置。对于编程或混合使用，我喜欢我们提供给 Fugue 使用者们的，新型超宽显示器。对于它来说，我更喜欢将屏幕分成三列，中间是主编辑缓冲区，左边是水平分隔的 shell 和 fugue 模式缓冲区，右边是文档缓冲区或另一个或两个编辑缓冲区。这个很简单，首先按 'Ctl-x 3' 两次，然后使用 'Ctl-x =' 使窗口的宽度相等。这将提供三个相等的列，你也可以使用 'Ctl-x 2' 对分割之后的窗口再次进行水平分割。以下是我的截图。
![Emacs Screen Shot][9]
### 最后一篇 CEO/Emacs 文章……
首先，我现在是 Fugue 的 CTO 而并非 CEO，其次我之前一直想要写一些其他方面的博客，而我现在刚好有时间。我还打算写些更深入的东西，比如说函数式编程、基础结构类型安全，以及我们即将推出一些 Fugue 的新功能，关于 Fugue 在云上可以做什么的博客。
--------------------------------------------------------------------------------
via: https://www.fugue.co/blog/2018-08-09-two-years-with-emacs-as-a-cto.html
作者：[Josh Stella][a]
选题：[lujun9972][b]
译者：[oneforalone](https://github.com/oneforalone)
校对：[acyanbird](https://github.com/acyanbird)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://www.fugue.co/blog/author/josh-stella
[b]: https://github.com/lujun9972
[1]: https://blog.fugue.co/2015-11-11-guide-to-emacs.html
[2]: https://www.reddit.com/r/emacs/comments/7efpkt/a_ceos_guide_to_emacs/
[3]: https://news.ycombinator.com/item?id=10642088
[4]: https://news.ycombinator.com/item?id=15753150
[5]: https://docs.fugue.co/
[6]: https://shop.keyboard.io/
[7]: https://github.com/fugue/ludwig-mode
[8]: https://www.fugue.co/hubfs/Imported_Blog_Media/fugue-mode-edited-1.gif
[9]: https://www.fugue.co/hs-fs/hubfs/Emacs%20Screen%20Shot.png?width=929&name=Emacs%20Screen%20Shot.png
[10]: https://baike.baidu.com/item/RSI/21509642