前段时间买了 iRobot 880 美亚买的， 599$

* 效果比较满意，吸力强劲，
* 家里地上东西不能太多（会影响寻路导致有些地方扫不到），特别不能有绳子之类的，会卷进去卡住
* 每隔几天要清理一次 HEPA 滤芯，可能我家灰尘大。。已经换过一个滤芯了
* 可以设置定时自动扫，很方便，扫完自己归位充电
* 有灰尘感应，感应到比较脏的区域会来回加强清扫
* 配有两个灯塔/虚拟墙，小户型不怎么用的上
* 噪声挺大的，人在的话听着会觉得烦躁，设定上班出门之后开扫。。

其他品牌没用过，推荐 iRobot
擦地的机器人要另外买，没用过

跑步机上跑过，大概25分钟的样子。。时速开始设置7-8慢跑，热身之后设置12+

部分资源没有https导致IE访问会有安全警告，体验不好。。应该要全站https之后再放出来比较合适把

一个亲戚想通过淘宝进余额宝操作，看到安全警告吓尿了好嘛。。

@hitsmaxft 赞同这个说法，Controller 还往页面上 throw exception 是作死

妹子挺萌的

吱

@frozenshadow

这个也算是行业潜规则了。。先把人忽悠到店里再说，给你推荐别的房子

工友你好

我用 cherry 青轴啊，把同事吵醒是因为中午本来就不应该码代码啊，刷刷手机，鼠标点点网页刷刷v2就好了阿

午休时间本来就不长

有很多非常类似的SQL，应该怎么抽象处理，每一句都要自己写吗？
比如selectByXXX, deleteByXXX

--
我们项目是用 freemarker 自己写模板文件生成的代码
顺便还能把基本的dao和service文件（基本的CRUD，其他业务逻辑当然要手写了）也一并生成了

交了学费，1w进去练手，剩6.5k

爬虫？

3天就能撸出来。。给力的

@buddha

貌似是不能直接以 mtr 显示 xx% lost 作为直接的丢包判定

root@localhost:~# mtr --report www.google.com
HOST: example Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 50.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2

比如这个 report，其实是第2个节点限制了 icmp 协议包，并没有丢包

这篇文章说的很详细
https://www.linode.com/docs/networking/diagnostics/diagnosing-network-issues-with-mtr

However, it is common practice among some service providers to rate limit the ICMP traffic that MTR uses. This can give the illusion of packet loss when there is in fact no loss. To determine if the loss you’re seeing is real or due to rate limiting, take a look at the subsequent hop. If that hop shows a loss of 0.0%, then you can be pretty sure that you’re seeing ICMP rate limiting and not actual loss.

真正丢包的模式是类似这样的
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2

In this case, you see 60% loss between hops 2 and 3 as well as between hops 3 and 4. You can assume that the third and fourth hop is likely losing some amount of traffic because no subsequent host reports zero loss. However, some of the loss is due to rate limiting as several of the final hops are only experiencing 40% loss. When different amounts of loss are reported, always trust the reports from later hops.

那些密码要就拿去好了。。

@dbfox

就这个需求来说，个人觉得确实是web这边做比较合适的，理由就一个，灵活

如果下回产品说改个排序规则什么的，在客户端做的话就要重新发布客户端
在web这边实现只要改下输出逻辑就行了

在显示的时候做，谁显示谁负责~

XSS 过滤逻辑可能没 cover 到所有 case（或者后来可能会出现一些新的case）
这时候如果在存储之前做过滤，后来发现有些 case 没过滤掉咋办？回去数据库找没 cover 到的数据改掉？

如果在显示的时候做，只要改下显示逻辑即可，相对改数据库来说，简单很多吧

个人更倾向于 DB commit 后 更新/清空 cache 对应的 key 的做法

设置一个很短的过期时间，多短的时间算是“很短”呢？
长了数据不一致问题会比较明显，短了 cache hit rate 降低，cache 就没啥意义了