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，至今仍然怀念