@Kahnn 不知道呀，没干过，一共几百个人。有邮件能联系的我毛估估一两百。
不知道有人有经验不

@geelaw @summerwar @lovedebug @swulling 感谢各位，我试一下。

@miao 一两百人吧

自己住的房子主要还是从源头材料上抓吧。有朋友卖光触媒喷雾的，也不知道具体有没有用。好像有专门的检测机构，可以花点钱测测。

看到过一些，都是有背景的。而且这玩意儿线下组织维护的成本比较高。

@whusnoopy 搞定了，直接写里面就完了，直接把查询写在$in 后面，不需要赋值再传递。
实测查询的话，的确用单增 id 比较 lt 快一点。
skip 的话，skip100 大概 0.1s ，skip10000 大概 0.2s ，估计量大了还是差蛮多的。
而且再次查询的话 skip 位置可能有偏移。

@whusnoopy 嗯，明白。
再请教个问题，假设先用纯拉取的方式。
我现在是分两步，先从一个记录关系的 collection 获取关注列表，然后到 post 的 collection 获取指定关注列表发的帖子，mongo 有没有什么命令能直接写到一个 aggregate 里嘛？还是一定要分两步来？

@whusnoopy

> 新浪那个前端加载速度, 绝对不比后台做一次拉操作快, 所以用户几乎感觉不到……

这个吐槽，笑死。

@whusnoopy 请教一下
现在尝试下来，直接 aggregate 查询，好像是返回 cursor，是个 generator。
这时候加上 limit，速度其实是挺快的。去掉 limit，数据量大就很慢了。
有没有什么办法可以利用这个 cursor 做翻页？
感觉可能会比重搜一次 post_id 会快一点

@luw2007 那如果某个用户有很多 follower，他每发一帖，都要去更新所有 follower 的 timeline 吗？
另外讨论下：
follower 的 timeline 条数有上限嘛？还是超了那个上限再去数据库里抓？
如果有非活跃 follower，会不会做太多额外的开销？

@fakeshadow 我也想拿到 aggregate 里面来，但不知道用哪个命令。
gt 只有在 id 升序或降序才可以吧。可现在 id 是 16 位英数混排的，很可能不行。

感觉 lz 主要是反对杀鸡用牛刀的现象吧 随便做个啥小功能都挂个 2M 的 js 的确是有点过分
具体还是就是论事 看实际用途看团队便利吧

可以试试 tushare

家里没电视用了十几年投影仪了。
投影的几个问题：
一个是要遮光，不遮光效果大打折扣，怎么都难救。但我现在比较爱大白天工作。
其次考虑一下家里的装修配套。我们一群玩投影的，家里基本都是深色墙面。白墙漫反射画面对比会损失。
另外现在写代码我喜欢多屏，投影目前我们只有一个兄弟公司组了三投影的宽荧幕。当然拿两个投影投白墙兴许也行吧。

清晰度倒是不用太担心，假设宽度 50cm 的一般屏幕你离 50cm 看能接受，那宽度 3m 的屏幕你离 3m 看也就差不多。

灯泡寿命，以我的使用强度，每天大概四小时左右，两三年换一次灯泡吧，不过也就 200 块。
现在的 LED 光源的微鲸那些我不知道效果怎么样，但 LED 寿命长发热低体积小，如果技术成熟也可以试试看。好不好毕竟因人而异，自己觉得行就行。

冬天既戴手套又戴口罩的时候，都挺麻烦。
不过戴口罩概率>戴手套。
室内的话，人脸还是挺方便的。看着屏幕点一下，基本就解锁了。

有几台虚拟机跑财务账

小东西用 excel 比较便利，可以利用 excel 作为数据输入的 GUI。
给客户演示及导出，大多数情况下也是 excel 比较便利。
但如果复杂查询，关联，Excel 里数组公式套多一点，明显就不大行了，还是要上数据库。
Excel 有概率崩，py/pandas/数据库更稳妥点。