不费硬件资源，费人力资源，费精力。
每次涉及到账号体系的时候，都需要考虑三方授权问题。
1，多账号绑定怎么办？
2，多一个业务逻辑就多一个服务内容，每次部署升级迁移备份都少不了它怎么办？
3，也多一个失败风险点，引起的客服、投诉量怎么办？
4，三方服务失败 /被墙怎么办？
5，三方服务被脱裤，安全体系崩溃影响我方怎么办？

你看，换位思考一下，随便想一想都这么多问题。不是问题不存在，而是代价和收益的比较。

——做个三方登录加维护多少成本？
——大概每年 100w 吧。
—— 100w 就够了？那做呗。这么小的代价，给到用户的感受是非常不同的。我们 x 牛，要以用户的价值为中心！
——好的 boss ！我这就去安排！
——对了，这部分功能的用户量有多少？
—— 3。。。3 个。
——哈？虾蟆？ 3 个？ 3 个人每年 100w 你莫不是今天停药了？这么边缘化的功能，砍掉！

以上纯属瞎掰，具体数值请楼上各位了解运营层或财务层的决策大佬们提供。

不管需求有多少，不管有没有二次开发便利。
定价 100 元 /天就是在侮辱人格。

浮点数是有范围和精度的。
http://www.cnblogs.com/BradMiller/archive/2010/11/25/1887945.html
可以照这个文章自己手算一遍。

开发圈有哪些约定俗成的常见缩写？

req = request
resp = response
res = resource
app = application
auth = authorization/authentication 这点非常不认可，同一个常见缩写居然能代表两个不同的词。
dev = develop
env = environment
db = database
pkg = package
svr = server
i18n = internationalization
cert = certificate
msg = message
addr = address
tmp/temp = temporary
var/def = variable/define 其实 var/def 已经是很多语言的关键字了
calc = calculate/calculation
src = source
dest = destination
min/max = minimum/maximum 应该已经不算了吧。。。
doc = document
dir = directory


foo/bar = 不知道该起什么名字好


未完待续。

先看书，再提问。
你这问题本身就不及格。

@lxy 没毛病，Python 的 in 用的是==比较。
>>> a = [1]
>>> b = a[:]
>>> b is a
False
>>> c = [a,a]
>>> a in c
True
>>> b in c
True

@flyingghost #9 算我眼瞎，看到“新浪”、“博” 就以为是说新浪微博，万万没想到这年头还有人挂念着新浪博客呢啊。。。
而且看样子楼里跟我一样瞎的还不止一个。😂

1，ABP 屏蔽掉这个框。

2，抛弃官网，使用“眼不见心不烦”等第三方插件，Weico 等第三方 App 品尝微博。

3，抛弃微博。

第二种。
函数头部先把参数异常、外部环境异常、内部状态异常等所有非法异常统统处理完。
接下来安安静静的专心处理函数本身的主体逻辑。

虽然看起来有点丑，但实用，清晰。

这个可能不是七牛处理的水印。
七牛的水印功能很简单，只能某个位置加一个覆盖，做不了这种满脸铺的水印。

前一段时间流行空密码 mongodb 扫描，很多数据库中招。朋友的库被清了以后，留了一句消息，大意是你的数据我已经备份并删除了，给钱就恢复云云。你妹，大几 G 的数据说备份就备份了？流量记录上看不出任何反常，明显就是忽悠。

后来流行加密勒索。这种工具改个信息就可以重新发布出去，后来纷纷加入的脚本小子，谁会去管解密的问题？

把这个当长久生意诚信营业的，都太天真。也许刚开始个别黑客这样做确实是有信誉的，甚至平时业内也曾经发生过很多次有名有姓的黑客组织勒索大公司的事。但现在已经是大批根本没名字没品牌的人大规模参与这件事，有三个问题：
1，大家都在做，都做的差不多水平，每个个体都泯然众人，并没有品牌需要维护。
2，大家都在骗，市场已经被做烂掉，单单你一个人去维护品牌信誉，没有任何效果，市场并不会认可（更何况你还是不会被记住的草芥之一，参见 1 ）。
3，因为 1 和 2，这个市场已经受到足够关注和防范，该补的漏洞补，该备份的数据备份，眼看着这生意就没得做了，一个明天就消亡的夕阳产业，还需要维护品牌信誉？这，就是一锤子买卖。

首先我要说，这是一个硬需求。
说进地铁认真听广播的，你们没有沉浸式的看小说看视频吗？塞个耳机还指望广播？哪有 duang 的一下屏幕上弹个提示框来的有效？我要是睡觉呢？绝对不如塞裤裆里的手机一阵猛震。

然后：
1，用计时器的，你们上地铁都会输入当前位置和列车启动时间吗？其实已经把使用场景限死在了：1，只有上了车以后。2，需要输入当前位置。这样的产品设计非常不友好。
2，用加速计的点子非常靠谱。可以作为第一辅助因素。在确定位置信息不可靠的情况下甚至可以上升至首要因素。只要确保模式识别准确，滤去机主移动等杂波就好。另，加速模型拟合可能要考虑不同线路车型，并且处理不了跳站、紧急停车等意外情况。
3，自己架设 iBeacon 的同学，先不说硬件成本和准入成本，单说可用性。在肉肉相交的车厢内，连移动信号都岌岌可危的严苛条件下，iBeacon 基站得多大功率？
4，定位才是王道。GPS 没戏，基站不用说肯定是主力，wifi 热点可以考虑。很多地铁有公共 wifi 或者现成的商业 wifi 提供，信息来源可以来自于众包或者商业合作。

以上就是作为一个野生程序员用技术思维能得到的最好方案。但，都是废渣。商业合作才是王道。所有地铁都有实时的运营监控系统，和他们合作把数据给个接口就可以了。LZ 既然说的是高德，他们有这个体量，也有这个实力去谈合作。

你们都敢买 70 年的房子。。。

这件事本身就不是一件简单易懂的事，想讲得简单易懂就必然很肤浅（比如经常用来做多线程比喻的银行工作窗队列），想讲清楚就得涉及到方方面面细节。
The devil is in the details.

辛苦了！

py+xxx 的包大把低质量废柴。。。真是让人伤心。

```
showWaitingUI();
sleep(10000); // 产品经理交待，为二期优化做铺垫
doSomething();
showDoneUI();
```