现在部门内进行数据收敛，特征相关的指标会逐渐收敛到 XFS 系统中。目前已经建设有 OFS(order feature system)、PFS(passenger feature system)。年后会建设 DFS(driver feature system)。 这些系统有共同的特征，根据 XID + 几个额外的参数来进行特征查询。而特征的具体存储可能是在 Rockstable(未来也可能是在 fusion)，或者是在 MySQL，还可以来源于其它跨部门第三方系统的 API。 之前 XFS 对外主要提供

常见的工程语言可分为解释型和编译型两种，比如写 php 的，一般就不怎么在乎 debugger 之类的东西。为什么？~~如果真出了问题，我可以临时把出问题的服务机器从线上服务中摘除出来，甚至申请一个较高的权限去修改代码，然后到处去 die/echo。虽然有人说这么做不太好，或者一般公司也不给开权限。不过着急的时候，这个肯定是可行的。~~然而像 java/go 这种编译型的就比较麻烦了。线上一般只有程序的运行环境而没有编译环境。就算是在线下，每次去加一行 fmt.Println 或者 System.out.println 都去编译一遍代码也是会明显降低幸福感的事情(当然这里有人说现在

公司内部有一个流传很广的负载均衡算法，大概的流程如下： 数组元素对应的是 ip+port 列表，形如下面这样： 100.69.62.1:3232 100.69.62.32:3232 100.69.62.42:3232 100.69.62.81:3232 100.69.62.11:3232 100.

最近在和 chai 大一起写开源书 advanced go programming book。实际上这个项目 16 年就开始了(汗。。最开始放在闭源仓库里，热情高涨的时候写两句。不过 private 的东西，总感觉像 dev/null 一样，和在只有自己能看到的小本本上写日记差不多，写久了以后会感觉有点没劲。 写书是一个很好的过程，系统化地总结学习过的知识，锻炼毅力和语言表达能力。不管哪种职业，语言表达能力和梳理能力都是必备的。顺便还能达到某些不可告人的目的(233。 具体可以参见这里： > https://github.com/

接上篇 模块 最早的时候，程序员们为了重用代码，会直接把代码 #include 到自己的项目中来，然后把库代码和应用代码一起编译出一个可执行应用。这个时间点，library 是通过源代码分发的。但是那个时候外部存储设备非常慢，而内存则非常贵并且容量很有限。没有办法把所有代码都放在内存中进行编译，这样编译器就需要多次从外部存储设备中读取源代码，然后多次访问巨慢的外部存储。可以预见，库的代码越多，可能会导致程序的编译过程就越慢，为了缩短编译时间，程序员们想出了可以把库和 application 分开编译的法子： 只要把 library 加载到固定的内存位置，例如 2000，那么我们就可以直接使用编译好的 library 了。 不过这种做法很快遇到了问题，程序自己要使用的内存很快就超过了