@keramist 有用啊，一直挺方便的，就是需要 root，如果 root 用的是 supersu 的话要打开系统启动自动授权选项，同时还要在电池优化选择不优化，然后一直挺好用的，没遇到其他问题，其他方法都太麻烦了

顶多按问卷时间分开就是了，调查问卷数据的特点是一旦调查完成，调查结果是不会变的，所以只要生成了调查结果之后基本就不会再查询了，所以这种情况下 group 不是一个好选择，无论是调查完成之后读出来计算还是调查过程中用 redis 实时统计都不错，数据量来说无所谓吧

@AlexaZhou 深表赞同，现在完全搞不清维护的 flask 注册了多少路由，有没有冲突，而且路由匹配多用正则，太多不慢么

每天 30 个俯卧撑有所缓解

选择大学专业还是应该考虑天赋兴趣为主啊

现在都会有 https 支持，那么根本不需要这么短吧，用户每次重新打开 app 或者重新进入网站刷新一遍差不多也就可以了，而且在大量用户使用过程中你也不能保证 5 秒客户端就一定能收到吧，如果用户没收到又发起刷新了呢，那你这不是搞的很复杂了而且还不稳定了

怎么没有，比如小区 365，无数人做过这个，只是都挂了，论坛大多只能以兴趣来聚合，小区潜在用户太小，有相同点能聚集可能就更小了，导致有价值数据约等于零，根本做不起来，事实上小区只能以生活服务聚合，这也就是现在基于小区的社群发展非常火爆的原因

@artandlol #8 只要是密码类型的都有可能泄露，DNA 只是不可猜测，但不代表不会泄露吧
密码泄露了你还能改一下，DNA 做密码泄露了是不是该让你彻底消失！！
再说生物识别向来最容易破解了吧，什么指纹，只要是你活动过的地方，满世界都是

其实科技的进步并不是一步到位的，小的连续的进步最终汇成巨大飞跃，那么高速，城市常规道路的无人自动驾驶完全是眼见就要实现的了啊，而这部分已经解决很大部分需求了吧，干嘛纠结呢

@creatorz #4 难道交规不是公用的，再牛逼他还能不按交规行驶，如果窄路单行道怎么会相遇
如果不是，那么车企应该是本公司拒绝进入，爱干嘛干嘛去，2333

微服务本身界定的是独立功能独立服务吧，没说每个小操作单独封装，每个小操作独立封装完全是没经验的外行瞎传吧

比如你刚才的，应该是两个微服务，下单和支付，创建订单和减少库存只属于下单功能的，修改余额只属于支付功能的，电商类来说下单成功但支付失败本身就是可接受的事情，只需要容错就行，不需要事务的吧

当然如果你这三个必须在同一个事务中操作，那么最好就是一个是一个微服务提供的完整功能

微服务想做事务除了两步提交，似乎也没有什么好的方法了吧，先请求一次所有微服务组件加载验证开数据库事务，再请求提交修改，但是似乎也没办法规避提交过程中又失败的情况

@lhx2008 replace 之后 json.loads 就可以加载了啊，replace 之后就是正常的 json 格式了，可以正常解码的

4E2D 就是“中”的 unicode 的编码，只不过 json 一般来说是用\u4E2D 来表示了
你可以 replace("%", "\\").replace("'", '"')，应该就可以解码出来了
这么坑的。。

@azh7138m 其实问题在于 app 打开了界面已经显示出来了，但是什么都点了没反应，一大堆在后台更新的，微信加载消息是正常的啊，支付宝要让用户等着加载啥

@Willjim Shortcut 是啥？我看设置的快捷换出付款码，也是要先完成 app 启动，一样卡死了

冷启动确实卡死了，目测好多次 30 秒内无反应的，太 tm 的烦人了，放在后台又瞎唤醒淘系的一大片 app，更 tm 的卡的要死，支付宝这些产品经理啊，今年好不容易看起来靠谱多了，现在又开始傻叉了，23333

3m 耳罩不错，隔音效果很明显

snowflake 麻烦是节点位太小了，很难自动根据当前部署机器和进程信息自动生成节点 id，在自动化分布式部署的时候可能会很麻烦

mongodb 的 bson objectid 是 12 自己，base64 编码之后就是 16 字符啊，这就好了啊