@ku9527 对作者其实也是一样的，辛辛苦苦防盗其实是得不偿失。You don't know JS 的作者就索性把书的 markdown 格式免费放 GitHub 上，加个链接到正版的购买地址。追求体验或者希望用金钱支持作者的自然会去买正版。各种防盗版的做法其实只会危害正版用户的体验，得不偿失

防盗成本太高，不如随便让人盗
像 O'Reilly 都是 DRM free 的，随便盗版。但是它家还有一个按时间付费的平台 O'Reilly Safari，书和视频资源随便看，体验好，有钱的自然会选这样的正版。
只要付费用户的收入能覆盖成本，对出版社来说盗版其实无所谓的

informit 长期折扣，平均一本 20 刀，DRM free 而且三种文件格式（ EPUB，PDF，MOBI ）。Pearson 和 Addison-Wesley 的全覆盖
O'Reilly 的动物书全 DRM-free 而且无水印，很多平台都买得到，一般我走 Google Play Books 。甚至 Humble Bundle 都有卖动物书 https://www.humblebundle.com/books/definitive-guides-to-all-things-programming-oreilly-books?hmb_source=search_bar
archive.org 也会有一些免费的书可以借阅，我在这上面看的 Java Puzzlers
也就 Elsevier 和 MIT Press 的书比较贵，不太好买。大部分英文书质量高而且也就一小时工资钱。毕业后我都买正版书。

去呼吸科，医院睡一晚上检测
听医嘱

@cmai 我只是想从语言规范层面去了解这个问题，而不是依赖于 JVM 的实现

JLS 17.4

A memory model describes, given a program and an execution trace of that program, whether the execution trace is a legal execution of the program. The Java programming language memory model works by examining each read in an execution trace and checking that the write observed by that read is valid according to certain rules.

The memory model describes possible behaviors of a program. An implementation is free to produce any code it likes, as long as all resulting executions of a program produce a result that can be predicted by the memory model.

This provides a great deal of freedom for the implementor to perform a myriad of code transformations, including the reordering of actions and removal of unnecessary synchronization.

所以我的理解是，JMM 只是规定了程序执行的顺序，即 JLS 里提的 happens-before 顺序。任何不违背这个顺序的重排序的优化都是合法的，因此会出现这种情况

Effective Java 3rd Edition Item 78: Synchronize access to shared mutable data

"This optimization is known as hoisting, and it is precisely what the OpenJDK Server VM does. The result is a liveness failure: the program fails to make progress."

取决于你的同事

无所谓

Roy T Fielding: A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC’s functional coupling].

我觉得回帖中九成的人没有看到 restful 的本质。

想一下你浏览 V2EX 的这个过程：你在浏览器输入 v2ex.com 或者从别的网站跳过来。服务器向你发送超媒体文本标记语言（也就是 html ），浏览器渲染后你可以看到这个帖子的链接，于是你知道你可以点这个链接从而看到这个帖子。作为人类你是自我驱动地去看到各种各样的超媒体（图片，链接，表单等等）并去获取各种各样你所要的信息。

理想情况下的 restful 是这样子：你的客户端向 v2ex.com 请求（协议和方法不限），服务器响应的也是一个超媒体，包括一些信息和客户端接下来可以进行的行为。在“人类”的例子里就是 html 和<a>。你的客户端想要看关于 restful 的信息所以它请求了这个帖子的接口，从而获取到了信息。

http 和 http 的方法只是方便了机器之间约定了请求的方法。但是 restful 可以不依赖于具体的网络协议和方法。如果服务器和客户端之间的交流是基于超媒体的，那么即便你全用 post 和 200 也可以是 restful api 。

@LokiSharp 我也是非常不喜欢 vue-i18n 。除了你说的原因，还有一点就是 vue-i18n 似乎是把组件当成上下文来用。比如 A.vue 的 i18n 中的 key 可以和 B.vue 的 i18n 中的 key 完全一样，区别仅仅是分属于不同组件。这样对于翻译者来说需要理解 Vue 当中的组件的含义，我觉得对非技术人员来说不太友好。

另外我猜测，如果不使用 vue-i18n 的 v-t directive 用法，用到 i18n 信息的地方都是 reactive 的，也就是在 dom diffing 的时候会被纳入计算，可能会对渲染性能有影响。

我个人觉得目前 i18n 做得比较好的 Vue 项目是 Gitlab，https://gitlab.com/gitlab-org/gitlab-foss 。它们就是用了 gettext 风格的翻译，可以自动提取信息到翻译平台上翻译。翻译完了信息可以回写到翻译文件上。另一个我比较喜欢的 i18n 方案是 https://github.com/Demivan/fluent-vue

另外现在的前端 i18n 方案大都是：浏览器加载了各种基础的 js 文件，js 说我要用某种语言，此时再 lazy load 我要的语言文件然后进行翻译的渲染。我在访问一些国外的网站时就出现过语言文件加载不出来，然后页面上完全无法正确显示的情况。比如我本来预期看到的是“用户名”和“密码”，结果出现的是“{username}”，“{password}”这样的你所说的占位符。所以我在尝试另一种思路：在 Vue“编译”.vue 文件之前对.vue 文件“预处理”，将所有的“占位符“替换成翻译好的信息，再交由 vue-loader 处理，最后出来的组件和页面就是已经经过“本地化”的了。这个做法更接近于 l10n 而不是 i18
n 。如果用户不经常切换语言，我想这样做会体验更好，但是代码编写的灵活性会下降，打包时间也会变长。https://github.com/tychenjiajun/jeanrry-loader 就是这样的一个尝试。

openjdk

Effective Java Item 61: Prefer primitive types to boxed primitives

包装类型效率低而且容易产生 NPE，实际上就是把 NPE 甩锅给调用者。负责任的程序员都会用基本类型，即便用包装类型也应该写好 javadoc。

以前在某开源厂实习用的 IRC，至今仍然怀念