可以参考一下云计算的 API Gateway——链接由 Gateway 负责建立，但不处理任何逻辑，而是把收到的请求（附加上连接 ID ）转发给无状态的后端服务去处理，这样只要 Gateway 不挂，就可以负载均衡了

C：考完试的那一刻起就还给老师了
Python：我不常用，每次不得不用的时候都重新学一遍，反正也简单
Java：现在用得较少了，但为不彻底忘掉，每天拿它刷刷 Leetcode
Laravel(PHP)：经常用到，但我正在尽力抛弃它
JS：以前只用它做前端，Serverless 以后开始全面使用 Node 做后端，个人觉得这是 PHP 最有力的替代品。

总结起来一句话——如果你只是开发网站的话，学 JS （包括 TypeScript ）就够用了

Those can be written in JavaScript will be written in JavaScript.

serverless

有些云数据库自带缓存服务，并提供 write-through 缓存模式，可以保证数据更新时缓存也更新。

不过我觉得这可能就是加了个 trigger

这个真不一定，一方面要看原作者是用什么语言写的，另一方面要看你自己的习惯。

就多数官方文档而言，我感觉英文的阅读速度更快一些，因为中文翻译出来的很多词并不是你操作中见到的词，总得想对应关系。有些劣质翻译就更别提了，词不达意特别影响理解。

但纯中国人做的教程就没这个问题，尤其是那种技术名词不做翻译，直接用英文的教程，简直是完美。虽然我平时也很鄙视“散装英语”，但这种中英混杂（对我来说）确实是效率最高的。

至于 Vue 这种中国人做的东西，中文官方文档已经很好了，没必要阅读英文。毕竟在同等质量下，还是母语阅读速度快。

@xiaoleis 有道理，供给和需求的减少量是一样的，所以房东卖房并不影响租房市场的价格。导致房租上涨的还是前面说的那个原因——房租低于利息

@qdwang 你说的没错，影响房价和租金的变量有很多，但分析问题的时候不能让他们都变化，每次只能假设其中一个变量变化，这样才能看出价格与这个变量的关系

这其实是个管理问题，细枝末节太多了，且没有成就感，容易让人厌烦。

要解决这个问题，就得从这两方面入手：

1 、解决“多”的问题。
其实多本身不是问题，不知道有多多才是问题，所以解决问题的第一步就是把所有待解决的“细枝末节”都列出来。这样从产品到开发，从领导到下属，都知道具体还有哪些活要干，就不会说出“就这么点活了，一天能干完吧？”这样的话。

2 、解决“成就感”的问题。
到这个阶段，一般不会再有突破难题的那种成就感了。但成就感不仅来自于突破难题，还可以来自于按时完成任务。把上一步列出的问题定个时间表，每天完成哪些。如果按时、甚至提前完成了，就奖励开发者尽情的玩，绝不多做，或者多做的部分额外有奖金，这就有成就感了。
这一点是很多团队亟需解决的，因为很多管理者其实不懂管理，都是学而优则仕上来的。他们倾向于给完成任务的人再派别的任务，等于按时完成任务的人会受到惩罚，所以团队的效率和士气就会越来越低。

楼主可能忘了利息这个吞金兽，常常比房租还狠。

以楼主所说的月租 4000 的房子为例，在北京的话，月租 4000 的房子大概售价在 250 万左右。

为了好算账，我们假设这 250 万全是贷款来的，现行基准利率是 4.9%，那么每年要支付的利息为 122500 元，而楼主交的房租才 48000 元，还不足利息的一半。

有人可能觉得，房东并不一定都是贷款来的，所以不用付那么多利息。更有可能房子买得较早，成本也没有 250 万那么多。但不管怎么算，房东都有一套价值 250 万的资产，所以房东如果是个理性的人，就应该想办法让这 250 万发挥最大价值。

当然，“最大价值”是个主观概念，有人追求保值，有人追求增值。所以咱就先算一下最稳妥的投资方式——把房子卖掉，把钱存银行里吃利息。目前四大行三年期以上定期存款利率是 2.75%，所以在无风险的情况下，资产每年可以增值 68750 元，这也比收房租赚得多。

这么看来，房东们都是不会算账的傻子？但这显然是不对的，因为房价本身也会上涨，不仅能弥补房租的亏损，还能赚到更多的钱。

所以，现在的租房者其实是享受了房价上涨的红利的，如果房价不涨了，那么房东就只能通过提高房租来弥补利息的亏空了。

又有人说了——如果房价不涨了，房东会选择把房子卖掉。卖得人多了，房价就会下跌。房价下跌了，租金与房价的比例就跟利率差不多了，所以房租不会涨。但别忘了，这些房东在出售房产的同时，也退出了租房市场，导致租房市场的供给减少。供给（房东）减少，而需求（房客）没变，还是会推动房租上涨。

OBS +1

收费的也没它好用，非常专业。

@neoblackcap 看来我说的太多，埋没了关键词——钱

你说的是账的问题，而我说的是钱的问题。

财务根本不管这笔钱是哪个科目的，只要进了公司账户，想出去就得走流程。

@winglight2016 电商平台可不只有天猫，有些平台没有“确认收货”这个概念。

如果是自建平台就更直接了，一下单钱就归财务了，进来的钱想再出去可就难了。

见的太多了，互联网和传统行业的观念冲突是一方面，僵化的财务制度是另一方面。

尤其是财务制度，别说楼主这种没什么权力的小兵，就是 CEO 也经常被没有互联网经验的财务人员气得骂娘。财务人员都很保守，他们严格遵循从学校学来的那一套，完全不适应电商的节奏。你还不能说他们错，因为他们不按规则执行就可能承担刑事责任。

我不知道其他公司都是怎么解决的，反正我们公司最终也没能改掉财务制度，而是增加了一个负责背锅的职位。比如退款，这个背锅人会先走借款流程（因为这个流程比退款简单）把钱拿出来给人退掉，再走退款流程冲掉借款……总之烦得很

看到这个需求就想到 TypeScript 的 interface，可惜 Java 没有

经历过三家创业公司，有做成的，也有夭折的，说说经验：

1. 这三家公司的第一任技术负责人，没有一个做到 B 轮的。原因很简单，公司初创时不好招人，所以早期加入的技术负责人能力并不是很强。

2. 这三个技术负责人有拿着股份愉快离职的，有收获无多平静离职的，也有像楼主这样发帖痛斥 CEO 无良的。但无论怎样，总归是要离职的，因为他不走，公司就得死。

3. 早期协议很重要，因为技术人员对公司的重要性是条余弦曲线——开始很重要，然后逐渐降低，甚至降为负值，成了公司的负担，直到公司进入下一轮发展期…… 所以，技术合伙人如果早期没谈好所有细节，以后也没机会再谈了。

总结起来一句话——技术合伙人在加入时就应做好 A 轮后离职的准备（包括心理、法务、财务准备）

全用 http code 做状态码是一种理想，实际很难做到，因为你总会有一些非标准的或是需要细分的状态。

所以还是 http 的归 http，业务的归业务就好，不要被那些鼓吹纯 http code 的人吓到，须知任何事情走向极端都是邪教。更何况很多大公司的 API 也在这么做（比如 amazon ），你不是一个人！

@EVJohn 解决不了 bug，就解决提出 bug 的人

@tangkaichuan 我弄过这个，用 IMAP 协议收取 GoogleVoice 短信，处理加工后还能通过 SMTP 协议回复短信

用了没几天，我的账号就不能收发短信了。也没见什么通知，反正就是收不着短信，我发的别人也收不到。用 Hangouts 也不行