所有的个性化推荐都是一套闭环算法，简单的说通过调整推荐算法来进行评估，如果主要评估指标上升，就是一个正反馈，下降就是一个负反馈。

所以说算法本身没有对错，关键是评估指标的设定，算法只会努力提升这个指标。

举个例子，评估指标是广告点击收入，那么算法就会推更恶俗点击率高的广告或者医疗等单价高的广告；再比如评估指标是用户时长，那么算法就会尽量推你会沉迷的短视频，让你多看。

淘宝的评估指标大概率是淘宝的直通车等收入 + 搜索成交率，前者的权重可能还更高一些，也就是他为了收入，可以降低你的搜索成交率，劣化你的搜索体验。

@applehater 北京有身份证就行。

正式牌照需要本人现场或者远程视频的方式验身。

keychain 很好用啊，如果不出现密码提示框，可以自己手动搜

销售专心买车，而不是想办法从你身上赚提成

前段时间买了 Model3，说几个和传统 4S 店不同的购买流程。

1 手机上下单，第二天提车
2 提车当天有事没法去，直接闪送身份证给他们，他们代上临牌，拖车直接运到家门口，免费。我家可离交付中心有 80km
3 不捆绑保险，你可以自己选择上任意公司的保险
4 没有上牌费，特斯拉找一个专门的中介带你上牌，但是费用特斯拉出。
5 没有捆绑销售，也没有强行推销分期等。

另外一个良好的系统设计尽量规避这种并发挂载模式，扩容高可用都不好做。能不用就不用，不过这个看需求，没那么高可用性也不必操心这个。

比如你设计跨越数个机房的高可用系统，光实例就好几万，你再让他们去通过共享存储去共享数据，那显然是一个非常差的选择。

@v2byy 没啥坑，需要底层存储支持。

写时注意别并发冲突了就行。

上面说的影子设备、Future 实例等，都是声明式接口的一种变种。

一般这种非立刻生效但是耗时预估也不会太久（<10s ）的接口，有三种实现模式

同步接口：优点是上层业务逻辑简单，缺点调用耗时较长，接口并发性能较差。
而且偶尔超时后就比较麻烦，有可能状态不一致。比如下发的动作执行了，但是返回时超时。


异步接口：优点是实现简单，还可以利用消息队列等方式来提升性能，理论上接口不会成为性能瓶颈。缺点是上层的业务开发比较复杂，需要自己实现轮询状态或者用长链接监听状态。


声明式接口：上层只需要下发期望，比如下发灯亮这个期望，设备定时去往这个期望变化。这种就类似于 Kubernetes 的接口，优点是能够保证最终一致性，缺点是还需要配合查询接口来轮询或者长链接 Poll 的方式看下当前状态是否达到期望。


目前从开发习惯上，还是同步或者异步接口比较多，但是复杂控制系统声明式接口有它非常大的优势。

114.114.114.114 DNS 解析失败，不推荐使用公共 DNS

最近比较良心的是快手，头条和阿里
比较坑爹的是拼多多，行权前想方设法赶你走

自己也控制不了，全看老板良心。

因为行权条件你自己决定不了，一股的估值你也决定不了。

说句难听的，以国内大学的考试要求，如果正常学习还大规模挂科，九成九是智商有问题。

不过智商有问题也考不上二本，不好好学就是不好好学，别找太多理由。

@systemcall

EE 也就玩玩弱电，烧几个元件和拿生命做赌注有啥关系？能烧死人还是电死人？

还进维稳名单，也是想多了

将位置定位改成仅使用一次。

不需要数据库，使用 Hash 表就可以了，先做 Hash，然后进行取模 Mod N，分布到 N 个 Hash 表里。

估计需要 3 台 128G 内存的物理机就足够了。

写个 AI，套关系就借十块，全中国那么多人总有愿意借的。

感觉是一片蓝海啊

直接等 M2 iMac