另外，取决于你们的 git 仓库的模式，如果是类 GitHub 自己 fork 然后 pull request 的话，可以自己写一点往自己的远端推送，commit 随便写，写完了再把这一批 rebase 成一个合适的 commit 再发 pr

OneDrive 没法写 .gitignore 排除，但是有别的方法

1. 先建一个空的 node_modules 目录，然后在设置里把这个文件夹选成不同步
2. 用软连接（ mklink ），把 node_modules 目录放到 OneDrive 文件夹外面，用软连接做一个快捷方式过去，OneDrive 只会同步这个快捷方式，不过这种快捷方式在某些终端下可能不认，硬连接（ mklink /j ）会被同步

需求 4 不存在，因为你是插 hub 上了，鼠标只跟 hub 上的接收器配对，不存在需要跟多台不同电脑配对

@razios 可以的啊，大致可以认为就是多了一个 SATA 接口出来，如果你还需要长期用，那么要么塞台式机里，要么塞 NAS 里，各种硬盘盒还是不那么靠谱，偶尔备份还行

@shuizhongyu10 算，有时候就是某个学校的人悔某个公司悔多了，导致报复性不招人或者压根不来了

如果只是为了拷数据，用易驱线吧，绿联有个另外加电源的还可以，用完硬盘单独封存

买了 Office365 家庭版，给家里几个人用，现在可以 6 账号公用，里面的 OneDrive 1TB 容量，上下行基本不限速，还有历史文件功能，反正 Office 是要用的，这个也顺便连上去了，挺安心的，Windows 设备各种无缝兼容

班尼路纯色 40 一件，好多颜色，品质还不错

@MrZZZ 我早没在那边了，现在带个小团队，没有用 Java，抱歉

断了重连下？我用 Sony WH-1000XM2 和 MX Anywhere 2s，偶尔会卡，主要表现是耳机里音乐卡的不行，将耳机断掉重连下就好

@HANXIAO1996 可商量就不要写期望薪资啊，这个当面谈

都是这样的，记得当时在 B 家最核心的组，拿了校招 offer 但还没毕业去实习的时候，第一个月晚上九点多走，第二个月晚上十点多走，第三个月晚上十一点多走，第四个月经常十二点过走了（有填打车发票，所以记得），半夜两三点在大组群里说个问题，瞬间有半个群的人回复，大组经理管了快百人，常年早上七点前到晚上十二点走

大道理总说吃得苦中苦方为人上人，然后比你天赋好的人比你还努力，还是加油做自己，问心无愧就好

只说内容框架和排版，不涉及内容本质

1. 部分个人信息重复冗余。比如标题有名字，个人信息部分又有名字
2. 微信如果是手机同号，没必要单独列出来，如果真想联系直接会用手机号搜的
3. 手机号后为啥要注明是河北保定？方便外地座机打的时候前面加 0 ？
4. 工作年限可以从你的工作经历推出来，没必要单独注明，而且第一段实习，严格说很多地方是不算工作年限的
5. 期望薪资写了就不要括号可商量
6. 中英文之间有空格为啥英文标点后又不空格，不管接的中文还英文
7. 中文顿号和英文逗号用于表达并列的中文顿号意思时混用了（比如技能这一节里好几处都是）
8. 最近一段工作经历里，提到了「公司官网后台开发」，为啥又没有项目描述
9. 其他项目提到用 yii2.0 做了商城，那么成品呢？是自己做着玩的，还是给别人商用了，直接给地址？
10. 致谢部分没必要

0. 自己导出打印一份看看，能不能 A4 纸单面打完，如果有超的，考虑优化精简到一页

年前回答过另一个问题，可以解释你的疑问 https://www.v2ex.com/t/525910#r_6737994

这种可能是被运营商和通道商保护性拉黑了（怕你投诉工信部），要解的话，一是找你的运营商，看怎么承诺不投诉然后给你解除黑名单，二是找给你发验证码的平台，让他们找他们的通道商，给你解除黑名单

@JCZ2MkKb5S8ZX9pq 这个不清楚，我都自己裸写的……

@JCZ2MkKb5S8ZX9pq 这个取决于你的最终实现

就这个问题来说，我们先关注 aggregate 到底做了什么。裸的实现应该是从每个 followee 那拿 sort 好的 limit 条数据，然后合并到一起，再 sort 取 limit。如果你需要自己优化这个事情，那就是先从每个 followee 那拿从 post_id 往前的 limit 条数据，然后把所有 followee 的 limit 条数据合并成 n*limit 条，再排序取 limit （这里有个假设是 post_id 是全局单增的）

回到 cursor 的问题，这个 cursor 很可能只有 limit 条，再往后 MongoDB 压根就没给你准备数据，或者还是要按前面我说的那样去重复计算

我觉得你先不用考虑活跃用户和非活跃用户，每个人的 timeline 默认都是有限的，翻前一两页和翻很多页的逻辑都是要区分，前面是缓存好的数据，后面是实时计算。如果你的用户量真的大到这种规模，自然会有人来帮你架构优化的（比如微博）

以前在人人做过，这种 SNS 的首页或信息流，都是有额外的缓存的，当年写过一篇分析，见 https://www.yewen.us/blog/2013/03/push-or-pull-on-sns/

关于翻页用 post_id，最大的好处是可以利用主 key 来做查询加速，查询语句里写 {post_id: {$gt: post_id}}, limit=10 就好，如果是 {}, limit=10, skip=20 的写法，DB 还是要先把前面 20 条取出来扫过去再拿后面的，翻页到后面时性能开销极大，特别是如果还加了其他的条件，可能就是从 100 条记录里选 10 条，和从 10000 条记录里选 10 条的差别

今天早上收到 Apple 的广告邮件，深圳已经三家运营商通吃了 https://www.apple.com/cn/watch/cellular/

@agagega 只能 iCloud 的有个 5G 免费空间就够了，剩下的都用 OneDrive，反正 Office365 对很多人来说是必需品