macOS 也走上层级和阴影设计了，这个大概就是趋势了

用领先业界 10 年的体验做 5 年前的功能，苹果还是那个苹果
不过 ipad 那个 pencil 和 airpods 真是吓到人了，苹果对用户体验的理解这个地球上独一档

“为啥作为综合视频网站主页的二次元信息那么浓呢”这句话真是挺冒犯的，B 站明明就是一个 2 次元视频网站正在做综合化……

行云流水个屁，iPhone 这个密码解锁按得快了第一个数字永远输不进去

希望员工完成月度计划才走，基于你的职位和承担的责任，我认为没有太大的问题，你有你的目标和压力，能理解
但是“要么 30 天”这个，你想做什么呢？当你说出“要么 30 天”这几个字的时候，你的员工的想法是什么？我认为 80%的人都会“行啊那就 30 天，给你搞定计划我是 SB”对吧
问题是，人家就留了 30 天，你的业务目标能达成？你没达到目标，员工丢失了 Offer，你制造了一个什么样的局面？有赢家吗？
再回头去看你一开始的期待，你的项目管理的风险管理呢？人机物法环风险预算呢？可能性+严重性的风险管控呢？做个领导只要屁股一坐就完事了吗？

@poppy37 所以我就不怎么想要下一代，自己欢快地跑完全程算数

如果打算有下一代，可以考虑让下一代在起跑线上有些作为，但千万别把这个当成下一代的目标，这是你自己的目标
如果不打算有下一代，大概率你一个人这辈子也不会活得太凄惨，就当逛街过完它呗

有不止 100W 现金，啥也做不了，留着防风险，连稍微有点风险的理财都不敢动

@xingyuc 先进不一定需要激进，其实 Github 在某些细节上非常先进，比如 Review 过程的自动刷新

@timqian 那这就是个很普通的皮肤功能了，我见过的应用里 Reeder 做得很好

有没有考虑过定制 UI 本身就不是一个体验优秀的过程

与其说先进了，不如说以前的 github 在 UI 上跑得实在太慢落后得明显

你看嘛，一个 HTTP 请求的 URL 放在第一行的
然后 body 可能是很大的，甚至可能是一个文件，所以 body 有可能是流式处理的
这也就代表着，如果你需要将一个请求分配到一个具体的函数上去的话，等 body 全部解析完是很慢的也很没必要的
举个例子，body 是一个文件流的话，只要我分配到了“把文件存起来”这个函数上，这个函数就可以把 body 流对接到 file 流。但如果我没办法分配到函数上，我就要等 body 流读完，把这个流放在内存里（假设内存没爆掉），然后解析 body 分析函数，把整个内存里的流给它，它再存到文件里，这效率多低啊
所以一些参数放在 URL 是非常合理的，特别是用来鉴权的、判断路由的等等
当然我可以不用 URL 而用 HTTP 头，但 HTTP 头的危险性在于你不知道中间有哪个 SB 一样的代理自说自画给你改了或者弄丢了……

@realpg 我们叫百度，算 Top 里应该问题不大

@realpg 公司是 Top……算了我也不知道 Top 几了已经被你们黑得体无完肤了。但有自己的整套云，只论成本的话要比我报的数字低很多，只是这个云对内部门间也是按对外的价格结算的

@realpg 是的不同的实现成本会完全不同，用云服务肯定相对会贵一些，但稳定性和数据保障性更靠谱一些，外加运维的成本几乎没有。然后 CDN 那个费用就完全看规模了，规模不上去屁事没有，规模上去了可不是按流量算钱这么简单了，所以我一直不敢对全网开放

@realpg 解压和不解压是不一样的，代理和同步全量存储是不一样的
NPM 的全量解压后大约有 20TB，对象存储约 2500 一个月
CDN 以我们公司为例，仅小范围推广的情况下，产生 7TB 一个月的流量，1700 一个月

同步的计算成本可以用 3 套方案：
1. 用官方 NPM 的 couchdb replica 方案，成本不高，但国内网络原因稳定性极差
2. 用淘宝 npm 的增量接口，同样成本不高，但那个接口事实上会偶尔漏一点东西，需要有一套机制去补上
3. 用轮询 npm 全量做对比的方案，成本极高，我用 FAAS 实现这一套核算下来 5000 一个月

除此之外，无论如何不能避免的首次同步全量，大约会有 5000-6000 的成本

确实到不了几万，但小一万一个月是存在的

现在这情况你让他上哪呢？ A 股吃得住吗，美股看中美关系吗，港股去找乐子吗？

我们有一个这样的东西，逻辑不难，下载 gz 包解压放进存储里，存储用对象存储就行，不贵
要省钱的，就请求来的时候发现没有再下载解压，第一次访问慢
想速度的，全量同步进来，成本比较高，存储加带宽几万一个月吧