@harde 订单里面我加一个 expireTime，超过这个时间就表示过期。比如买了一个月会员，一个月后就过期了
@Martin9 这个我也看资料也是这样说的（连接字段上加索引），不过我试了一下，增加前后时间都差不多 15 秒
@nonoyang 现在最新订单会覆盖会覆盖旧的订单（就是只有一个订单），我们也在计划修改这个，把所有历史订单都存下来

试一下冥想（闭目养神）

广州的房东怎么都装修啊...
直接走街串巷看, 我的经验是手写的一般是一手房东. 还有二手房东. 中介一般网上遇到多.
不出钱只能出力, 多逛几圈打几个电话, 看一下. 一般不是本楼的就不要去了, 不知道多远. 这个好处是可以在想要的地方找到房子, 不过累一点.

兴趣转移了而已...我近来老想着买个钓竿去学钓鱼, 周六看到江边钓鱼贼有意思

认知是有误差的.
你以为面试低端岗位的是: 科班出生基础扎实也许太深的不懂干活也不行但是值得培养的好苗子
实际上来面试的是: 三个月培训会套框架也许还能干活但是不懂原理也不敢说三年经验的老实人

@mmrx PUA，全称“Pick-up Artist”，原意是指“搭讪艺术家”. 这点上应该不符合.
现在许多人按内核理解"打一打再揉一揉就"是 PUA. 这个看个人理解.
更多的, 我倾向至少要这个领导知不知道自己是在"PUA"? 我觉得领导可能都不知道这几个字母什么意思.

哪个领导不是人精? 可能我接触的领导段位比较低

我觉得不要什么都往 PUA 上扯, 大部分领导都没那水平. 如果你觉得说话让你难受了又圆回来, 理解对方就是说话水平 la 低 ji, 不过后面看了你脸色不好又说几句好话而已.
只要没有炒了你, 你在当前岗位的工作能力就没问题. 反证法证明这个很容易.

朴素的善良...
我建议先让自己"失业", 然后"降薪".
告诉家人自己失业了, 等几个月换一个"低一点"的工作, 实际薪资就不要告诉家人朋友了.
把自己位置摆低一点, 也许更容易谈, 这也能顺便了解父母的用途. 直接说不想给或问用途, 关系容易爆炸.

最近几次要下载都不行, 看到这个帖子后又重新试了一下. 最后解决的方法是参考这个帖子, https://www.v2ex.com/t/696735 用 ApkPure 更新了 Google Play, 可以正常下载了

需要指出一个误区, 许多人都注意到做菜的被说菜不好吃容易暴走, 但是不要以为这个是因为煮菜付出的劳动得不到认可, 后面还要隐藏的线.
偶尔煮一顿菜, 重点在"煮", 但是每天都煮菜, 选择 /决定每天吃什么菜, 怎么搭配是一件很消耗的事, 而且很容易陷入"无解"的境地. 比如说肉, 鸡鸭鱼肉四种, 每天一个四天就得重复一轮, 就算你加上虾蟹腊肉也只能稍缓一轮. 一个月下来, 买菜就足够消耗精力了. 新的菜式是需要学习的, 也就是说, 家常菜要做到每天有花样, 基本就是 996 的活.
就算你是发工资的老板, 也要被怼. 何况只是一洗碗打下手的?

如果你觉得"独处"利大于弊, 那就开开心心接受弊;
如果你觉得"独处"弊大于利, 那就想一下改变.
如果只是夜里"独处"失眠瞎想, 建议找方法解决自己的失眠.

利益相关:
喜欢独处, 也沉默寡言. 但是周末回家带娃出门娃看到随便一个人都有兴趣, 还带着我穿了门(知道但是从来没去过不怎么熟的阿姨家), 发现带娃才是第一交际力, 只要是都带娃, 不管年龄性别兴趣爱好都能聊几句.

@exc 用硬编码理解 Root 权限应该是不准确的，更应该把 Root 看做一个协议。
在需求上，既然能明确分权限是有意义的，那么把总的权限命名为 Root 还是 Admin 还是其他，都是偏好而已。把初始化交给用户，是一种选择。默认初始化为 Root，也是一种商定好的协议。

这个问题挺有意思的啊
根据不同用户赋予权限, 是现实使用的需要，是代码设计的结果。
CMS 系统存在多个使用用户的，一般都有现实的职位、职责区分，让不同人看到、使用不同的功能，这是 CMS 系统的需求。当然可以所有用户都有全部的权限，此时只有把所有人都用同一权限（ ROOT ）就可以；就是说权限分级是可以兼容这种权限不分级的使用的。
在操作系统上，情况相似，但也有不同。相似是操作系统的确可能是多个人同时使用（服务器）；不同的是，应该也把操作系统上的软件也当做操作系统的用户。此时，权限也是防护电脑的功能。
在软件的使用上，轻度用户和重度用户对系统的了解和需求是不一样的。ROOT 权限也提供了一种方式，方便用户去定制。潜在的，使用 ROOT 权限也要求使用者对系统足够了解，而不是随意折腾。
ROOT 权限并不仅仅解决一个问题或者有一个纯粹的出发点，我更倾向于最初简单的设计随着需求变化迭代后，成为针对大多数场景的解决方案。

没打完发出去了...
我本想说没有这样的书, 然后想了自己看的书, 有的话应该是<App 研发录：架构设计、Crash 分析和竞品技术分析>(从订单历史找的). 但发现可能也不太合适, 原因和我觉得没有这种书一样: 落后.
Android 现在是一个既成熟又年轻的状态. 你可以用过去十年的技术和经验继续构建, 但是这些技术都在慢慢被淘汰. 就连 Java, 逐渐都是 Kotlin.
鉴于题主是后端的, 我觉得拿网络处理来做说明比较容易理解. UI 的开发正常只有一个线程能更新 UI(一般叫主线程, 具体的细节差异忽略). Android 一开始是可以在主线程请求网络的, 这样就导致网络请求时整个页面都停止响应了. 所以网络请求被禁止在主线程调用. 然后就出现了网络请求的封装. 大概带你是这样的:
~~~
New Thread(Runnable(){
result = 网络请求()
handler.post(result);// 返回主线程继续
});
~~~
这种封装第一个问题是每次请求都要新建线程, 很简单, 用线程池解决. 第二个是里面的 handler 持有了当前页面指针, 可能导致内存泄漏. 所以当时很多文章也介绍怎么避免这个问题(handler 不仅仅网络使用, 所以问题还是挺普遍的).
这种经验还有用吗? 如果你用上现在的 Retrofit 库, 你发现这些问题都没有了, 而且用起来还贼简单. 真有人写书还给你介绍这个, 估计你都觉得作者骗钱的. 但是的确还有些新人抄代码抄到这种东西. 可能我还觉得自己年轻, 觉得这种东西也是不久前才看过. 比如我上面说的书, 里面说 ListView 也是被淘汰了, 现在就算你用 RecyclerView 不自己写一个 BaseAdapter 都不好意思给人看.
感觉都是自言自语, 说个还是自己觉得有用的建议: 找一个还在维护的高仿项目, 看一下网络请求处理, 设计(什么 MVVM, MVP 的随缘), 经典的 iOS 底部 tab 样式实现, 列表页面, 详情页面实现就可以了. 如果了要做的功能, 直接搜'高仿 xxx',基本出来的就是最佳实践. 毕竟万一运气不好, 搭环境估计都得花好几天.

我本想说没有这样的书, 然后想了自己看的书, 有的话应该是<App 研发录：架构设计、Crash 分析和竞品技术分析>(从订单历史找的). 但发现可能也不太合适, 原因和我觉得没有这种书一样: 落后.
Android 现在是一个既成熟又年轻的状态. 你可以用过去十年的技术和经验继续构建, 但是这些技术都在慢慢被淘汰. 就连 Java, 逐渐都是 Kotlin.
鉴于题主是后端的, 我觉得拿网络处理来做说明比较容易理解. UI 的开发正常只有一个线程能更新 UI(一般叫主线程, 具体的细节差异忽略). Android 一开始是可以在主线程请求网络的, 这样就导致网络请求时整个页面都停止响应了. 所以网络请求被禁止在主线程调用. 然后就出现了网络请求的封装. 大概带你是这样的:
~~~
New Thread(Runnable(){

x * 1.5 * 0.5 = x * (1.5 * 0.5) = 0.75x
x * 0.5 * 1.5 = x * (0.5 * 1.5) = 0.75x

乘法结合律没有学过? 九年义务教育漏网之鱼?

认识到生命是一代代延续, 没有对死后刀山火海的恐惧, 的确很多人不怕死亡, 唯物论让人觉得"我不怕死".
生死是一个沉重的话题; 能轻松讨论, 说明没有负担. 独生子意外去世留下父母孤寡, 怕不怕? 子女嗷嗷待哺, 双亲意外去世前怕不怕? 这是情感负担, 多轻多重自己才知道.
没结婚前我媳妇和我说过她去跳高的经历. 一个假小子, 天不怕地不怕, 不就是跳高吗? 安全有保证, 只是体会一下失重感. 但是站到几十米高空, 要你主动往下跳, 人类数以万年进化的本能会拉住你的.
拥有健康的身体, 然后天天觉得日子枯燥无聊, 总得熬个夜折腾一下. 普通感冒流鼻涕就开始难受了, 来个重感冒一天昏昏沉沉足以让人投降. 想一下死亡的方式, 再看看自己是否能撑过去?
死亡不是睡一觉, 然后永远不醒来. 它描述一个结果, 也描述一个过程.

一两次还是比较好解决, 我试过最有效的方法应该是:
1. 冥想. 眼观鼻鼻观心. 这种适合坐着的时候, 可以稍微学一下冥想, 知道保持关注呼吸和抛弃杂念. 冥想时间会变得很长, 2 分钟时间就相当于睡了一小会了. 再长忘了什么感觉.
2. 全身用力再放松. 躺着, 从脚到手到头(眼睛), 先用最大力绷紧一会然后放松, 重复来几次. 这个是躺着用的, 很久没用了, 知乎看来的, 之前试过效果还行. 当初没躺的条件, 都是坐着做手和眼睛的动作的.
长期松弛结合, 合理安排时间很重要.
珍爱生命.