每一个实例对象，都有自己的属性和方法的副本。

我们为 Right 定义 of 的原因是，如果一个类型容器可以 map，那它就应该 map。看上面的例子，你应该会对 of 通常的工作模式有一个直观的印象，而 Left 破坏了这种模式。

这样可以方便的进行单元测试，不需要模拟Api.fetch函数的具体返回结果。

要注意的是，在saga模式中不能保证隔离性，因为没有锁住资源，其他事务依然可以覆盖或者影响当前事务。

T1, T2, ..., Tj(失败), Tj(重试),..., Tn

因此，Gamma表示的是对冲风险的难度

为了避免在时间处理上出现问题，核心就是统一输入输出时间的转化。因此解决的思路也是两个：

对于具有名称不可重复的自然特性的对象，最好使用Version 3/5的UUID。

logger.debug

跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

这样启动时不需要和 Zookeeper 通讯获取 Worker ID. 做到了完全的去中心化

snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。这个算法单机每秒内理论上最多可以生成1000*(2^12)，也就是400W的ID。

在配置时，NTP可以利用冗余服务器和多条网络路径来获得时间的高准确性和高可靠性。即使客户机在长时间无法与某一时间服务器相联系的情况下,仍可提供高准确度时间。

所以，一旦数据存储在IPFS中，它就会是永久性的。比如我们经常会遇到的某个资源删除无法访问的问题。 这种情况，在IPFS上就不会发生。即便是把该站点撤销，只要存储该站点信息的网络依然存在，该网页就可以被正常访问。存储站点的分布式网络越多，它的可靠性也就越强。

Q: how can i ensure something remains online? A: you can do this by keeping one or several ipfs nodes online pinning the content you're interested in backing up, the more ipfs nodes pinning content, the better redundancy you get. Tools such as ipfs-persistence-consortium, pincoop, and ipfs-cluster on top of ipfs allow you to share the costs of bandwidth with other people or organizations. Then, protocols like Filecoin will allow you to just pay the network to do it for you (i.e. similar to how people pay "the cloud companies", but here you're paying the network itself). (Filecoin is not live yet)

换一种解释，预言机整个完整的工作流程是这样的，首先预言机从小米官方获取小米9A的电视价格，然后向特定区块链上的地址进行转账，并将价格信息写入交易备注，这样智能合约只需要查看特定地址的交易记录，就可以获取小米9A的价格了。而由于区块链会自动同步存储包含交易的区块，所以智能合约几乎只需要访问本地就能得到价格信息。既保证了访问效率，又保证了价格的一致性。

例如，一个需求非常大的应用是一个用来对冲以太币（或其它密码学货币）相对美元价格波动的智能合约，但该合约需要知道以太币相对美元的价格。最简单的方法是 通过由某特定机构（例如纳斯达克）维护的“数据提供“合约进行，该合约的设计使得该机构能够根据需要更新合约，并提供一个接口使得其它合约能够通过发送一 个消息给该合约以获取包含价格信息的回复。

下面这个示意图就是一个智能合约模型：一段代码（智能合约），被部署在分享的、复制的账本上，它可以维持自己的状态，控制自己的资产和对接收到的外界信息或者资产进行回应。  智能合约模型：它是运行在可复制、共享的账本上的计算机程序，可以处理信息，接收、储存和发送价值。

module.exports属性表示当前模块对外输出的接口，其他文件加载该模块，实际上就是读取module.exports变量。

有时候，上面四个 Accept 字段并不够用，例如要针对特定浏览器如 IE6 输出不一样的内容，就需要用到请求头中的 User-Agent 字段。类似的，请求头中的 Cookie 也可能被服务端用做输出差异化内容的依据。 由于客户端和服务端之间可能存在一个或多个中间实体（如缓存服务器），而缓存服务最基本的要求是给用户返回正确的文档。如果服务端根据不同 User-Agent 返回不同内容，而缓存服务器把 IE6 用户的响应缓存下来，并返回给使用其他浏览器的用户，肯定会出问题 。 所以 HTTP 协议规定，如果服务端提供的内容取决于 User-Agent 这样「常规 Accept 协商字段之外」的请求头字段，那么响应头中必须包含 Vary 字段，且 Vary 的内容必须包含 User-Agent。同理，如果服务端同时使用请求头中 User-Agent 和 Cookie 这两个字段来生成内容，那么响应中的 Vary 字段看上去应该是这样的： Vary: User-Agent, Cookie 也就是说 Vary 字段用于列出一个响应字段列表，告诉缓存服务器遇到同一个 URL 对应着不同版本文档的情况时，如何缓存和筛选合适的版本。

Such behavior means that errors might be visible somewhere in the user interface, or maybe, when some operation is performed on the wrong value, but not at the moment when the real typo occurred.

Cookie存储在浏览器中，对客户端是可见的，客户端的一些程序可能会窥探、复制以至修正Cookie中的内容。而Session存储在服务器上，对客户端是透明的，不存在敏感信息泄露的风险。

但是这可能会使调试变得更麻烦

var sortUserTasks = R.compose(R.map(R.sortBy(R.prop("dueDate"))), activeByUser);

注意到有什么不同了吗？这里没有提到任务列表。Ramda 代码只给我们函数（没有给数据参数）。

`prop` takes two arguments. If I just give it one, I get a function back

Use eMMC in Data Reliability Mode Typical eMMC devices also should not be powered down during a write/erase cycle, as they can be prone to the same failures as an SD Card. However, the eMMC devices that Technologic Systems uses in our products include support for a "Write Reliability" mode, and a "psuedo SLC" mode. These modes can be access by setting a fuse on the eMMC device. With both of these enabled the eMMC only risks up to 512B during a write. In the event of a power loss that 512B of data would return the values from a previous write rather than corrupt or erased data like a typical SD card. Even in cases where the wrong data is present on the next boot, fsck is able to deal with the older data being present in a 512B block. The downsides to setting these modes are that it will about half the size of the eMMC module to 1.759Gib by default, and write speed will be slightly slower. Used with ext3/4 and the filesystem configured to journal data, this can provide a very robust system. This mode still has the tradeoff that any data not yet committed to disk will be lost.