@Seria 低碳生酮饮食，但这种突然瘦下来的，1 是体型不是那么好 2 是容易反弹

1. 你这一天一顿，都不是 16+8 了吧。。。
2. 楼上都说三年才瘦多少斤，效果不明显，我反而持反对意见，其实你长时间能坚持的，才是好方法，比如我自己试过低碳生酮这种减起来确实很快，可能一个月就能下 10 斤，但是有什么用呢，你很难长期坚持，一旦正常饮食马上就反弹了。

@yiyiniu 软件其实保障不了啊。。。30 天能不能完成主要是看研发真实时间能不能搞定，和 jira 这种软件有啥关系。jira 最多也就把任务拆解，然后每个任务上写好预估时间，只能说如果你更新的勤快，软件也许能告诉你做到一半的时候来不及或者也许可以提前。对工期本身其实没多大影响，甚至人少的时候可能还是负作用。

mac 不是有自带的 vnc 吗，话说是不是亚马逊相关的租赁更适合？

你说尴尬倒是比较好理解，自卑属实不太理解啊。。。

本质就是不断更新 jira issue 的状态，通过各种状态来统计。事实上 jira 并不能提高多少效率，只是对 issue 的追踪比较好，然后可以做一些分析罢了。提升效率还是要从研发流程，沟通基准，自动化程度来做的。毕竟是死板的工具，你只要定规则，那么必定就有漏洞可以钻，一项任务的复杂度，难易程度，都会影响他的工时，人员技术能力以及业务的熟悉程度也会影响它的工时，单纯从 jira 很难解决这些问题，而这些问题又是影响评判的主要因素之一。
我司基本只用 jira 来做：
1. 提需求，投票评判需求
2. bug 追踪，设计好流程，记录原因，解决方案
3. 分析 bug ，某些反复触发或者相关问题，需要梳理重新解决的
4. 一次上线内需求拆分成多个 issue ，这里其实并没有太多作用，只是象征性记录，更多的还是靠组内沟通

送暑假补课班

15 年年底就已经末期了，那会我们公司挂个 iOS 岗位一天能收 200 多简历

感觉没有。。。16 年新款挤牙膏，直接海鲜市场 1.1w 入了 LT2 ，用到 21 年 3k 多出了，入了 M1pro 32+1T

书的内容感觉还是存文件合理些，你要实现的功能再用其他数据库。
比如书先丢到各种云存储中，path 入关系型数据库，做一些分类，收藏，标题搜索等内容。
后续的功能针对书 id 建立笔记，高亮内容等。比如 https://github.com/alienzhou/blog/issues/28

不对外，感觉 git 写点 markdown 就行了

icloud , 主打一个不用操心

0.其实要求不高的话，一个路由器也能覆盖，就是有些地方速度会比较慢
1.网口 2 做柜子的时候设计一下，看是否能留两个面板的位置挖孔，到时候 ap 贴在衣柜里面
2.有线 mesh 网口 1 网口 2 ，感觉应该差不多了，书房可能信号不是那么好

基于关系型数据库 能优化的：
1. 首次 fetch 只查 id ，根据 id 最后获取想要的数据
2. 部分冗余，部分卡顿场景具体分析解决
3. 分表，这个要针对业务场景了，有些情况要就是没法分的
4. 冷数据处理，比如几年前的数据，把它迁移走
5. 建立好索引，优化查询语句
基于 CDC：
1. 做个新的宽表，数据仍旧放在 PG
2. 新宽表放到 ES CH 等地方