今年五险都归地税代收了，不敢不交。但是公积金还没归地税？回头归地税代收了那也没有这种潜规则了

@razios 这个不清楚了，看是不是群晖里有自己的文件格式，或做了 RAID 啥的，最好先在群晖里把数据备份好，然后这块盘拆出来低格当新的用

如果只是为了激活和正版教徒，推荐去注册一个 Windows Insider Program，之前是只要注册了的就可以免费激活 Win10Pro，如果想更符合规范，那就让自己停留在预发布通道而不是把内测关掉（关掉后还是激活状态）

另外，取决于你们的 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 默认都是有限的，翻前一两页和翻很多页的逻辑都是要区分，前面是缓存好的数据，后面是实时计算。如果你的用户量真的大到这种规模，自然会有人来帮你架构优化的（比如微博）