老的 Opera 是新的 Vivaldi 。
新的 Opera 是 360 Chrome 。
你说的是哪个。

17 万一个月，比我们这还便宜点。当然房子比我住的小不少倒是。
日本的消费水平总体来说还算可以，至少衣食还是比我们这稍微便宜点的。

@jackroyal 只是东部到了而已，西部还没到。
另外人家说今天放，没说今天零点放。说不定指的是下午呢。

@wizardoz https://www.douban.com/note/222812632/

@shiji
@scusjs
AUTO_INCREMENT 是不能小于数据表里字段最大值的。
自增的作用本来就是指示表里数据最大值的，根本不是上面说的什么「拿来同步用」的。
同步用老老实实上唯一 ID 。

@visionsmile 撒，这个我不熟啦。
但是 C++的确是很尴尬的。
旧标准用起来难受得要命，新标准各种奇淫技巧倒是好，但是又太淫了根本候不住啊。
有时候想想还不如用别的语言好呢……

把硬盘用 diskgenius 整个克隆过去不就好了……

GlusterFS 自带一个 NFS 服务，直接访问应该就行了。

（不过 Windows 的确是比较麻烦就是了）

时间同步， IP 地址与主机名上报，另外可能还有支持内存气球之类的黑科技。
通常来说没有意外的话都是装了比较好。

把 GlusterFS 配置好，然后挂载到比如 /mnt/shared_disks 下，然后直接往里写就好了。

（你是在说 Linux ……吧？）

@wujunze http://releases.ubuntu.com/16.04/
Windows 10 。

现在东部是 4/20 23:55 ，西部是 4/20 20:55 ，你跟我说今天发布？

GlusterFS 直接就是文件系统啦，何必客户端，挂到系统里直接用就好了。
另外还听人说过 Ceph 。

http://mingw-w64.org/ 类似的东西。

@msg7086 s/遇上 /于是 /

@lygmqkl 很多时候的很多做法其实是妥协的结果。
如果什么事情都能找到最理想的员工用最理想的办法去做，当然什么都好说。
但是团队就是团队，就会遇上一些奇妙的事情。
比如因为没钱所以招不了大牛，因为要抢占市场所以赶着开发，遇上留下了各种技术债什么的。
自动路由大概就是技术债的一种吧。
还债方法要么用显式路由，要么就如你说的，合理拆分，详细归档。
PS: 国内情况我也不清楚，不过哪里都有你说的这种人，应该也不限定于国内的。

C++真的要谈性能的时候，就不是「学好 C++」这么简单了。
比如说最近我玩过的 x265 ， C++写的。
核心计算部分全都是汇编。
而且全都是花大量大量的时间去精心调试的。
你知道 Intel Parallel Studio 吧，这货开起来然后看 AVX 指令集在 CPU 管线里的执行效率，然后进一步优化代码的结构，才能带来那么 0.5%的速度提升。
这块你要是熟，那才是大把大把的钞票。
x265 里剩下的那些 C++的部分，说实话全部用 PHP 写我看都没什么大问题。
所以 C++其实处在一个很尴尬的境地里。
只有用汇编不现实，又要对性能有要求的地方，才能用到 C/C++。

比如……游戏服务器，或者是嵌入式开发。

然而游戏服务器好像也开始用黑科技来写了（什么 Erlang 啊之类的）。

@lygmqkl 你说的都没错。
我对我自己说的话负责任，但是没法对别人因为我说的话产生的影响而负责任。
毕竟这里是讨论区，我觉得有互相不同的观点才是正常的。
那么我们就来看看你提到的这几点吧。
1. 文档，质量控制，版本控制，测试。
是的，是应该有这些。但是偏偏我司的系统就是没有。
去年来了个新员工， Ruby 老手，进来以后花了几个月时间分析和优化系统。
后来在各种注释里留下不少对之前员工的脏话后愤而辞职了。
如果你的系统这几点都能做好，当然不成问题。
但是不是所有的公司都能做到这样。就说自动路由，你能保证你对外暴露的接口都能完整地整理在文档里吗？
俗话说得好，代码才是最好的注释。显式申明你用到的路由本身就是一个精确反映实际的文档。
2. 路由在项目初期就定下来。
你开玩笑的吧，一个要做几年的项目的路由能一开始就定下来？
我们现在的系统就是 50k 行代码，前后写了七八年，经手的程序员几十人。
路由就是我 26 楼写的自动路由，前端界面往后端调用的时候直接 Call 到 Controller 上的方法。
（实际情况其实比这个还复杂点，但是和本题无关所以就不提了。如果想知道我可以再说下去。）
然而我们根本不知道前端到底用到了哪些后端方法。
所以每次动控制器的时候根本不知道哪些方法是前端会用到的，哪些是可以随便改动的。
3. 大项目拆分。
这个没错。但是有几个问题。
大项目不可能无限分割成微型项目。所以不可避免的有些项目还是有数千甚至上万行。
如果全部用自动路由，你还是得到处搜索函数名，确保没有奇怪的地方调用到你的函数，才可以改动结构。
除非你把所有的代码都从控制器里剥离出去，放在 Service 或者 Model 里。
然而这样的话控制器就成了实质性的路由文档了。
（并没什么不可以，如果架构师和程序员都靠谱的话，这样其实是不错的。）
（但是你并不总是能遇到靠谱的同事。）
4. 不知道你说的是什么。 26 楼的话，那个就是自动路由了。

最后说下利益相关吧。 PHP 从初中开始玩，那时候还只有 PHP4.x ，还没到谈框架的年代。后来 PHP5 了自己写了个框架，工作以后送给公司用了，后来成了公司的核心框架，虽然并没什么亮点。现在写 Rails ，在一个五六人的团队里一起做一个 8 年多的 Rails 1.x 项目，大概有 50k 行的量，虽然基本都是辣鸡。现代 PHP 我已经不会写了，弃掉 PHP 的时候 Composer 才刚刚出来，所以对 Laravel 了解不多，不确定显式路由是不是有坑，不过至少 Rails 里显式路由的规则数量我还是可以接受的。上文大多以 Rails 的角度来谈路由，如果 Laravel 有不同之处还请提出来。
谢谢。