diamondtin

好的前段比好的后端难找。

但是，公平的说，同样水平的后端待遇比前端好。

至少湾区是这样的。

http://cl.ly/image/0n0P3x0K2C0U/Screenshot%202014-02-16%2010.32.08.png
http://cl.ly/image/410u0k0O1e1A/Screenshot%202014-02-16%2011.48.40.png
http://cl.ly/image/1w370q2t0h2E/Screenshot%202014-02-16%2013.34.44.png

这里有几张从 MongoDB 转 TokuMX 以后的性能数据变化。这是一个在线的游戏的 REST API，app server 是 python 的。

我的朋友刚刚在他的 Startup 用了 TokuMX 替换 Mongo，因为协议相同，所以没有代码改变。在 VPS 上面跑性能平滑了很多，因为他们不用 mmap，所以不再那么 io 敏感了。而且还有一个变化，就是数据文件小了很多（22GB -> 3GB，他的 case）。我准备试试用它替换我们的 MongoDB。

@virushuo Redis 默认的 rdb 方式是 snapshot 的，可以自己定义触发 snapshot 的条件，可以是定时，也可以是单位时间写入超过一定数量才触发。还有 AOF 方式，是 append 的方式写入增量 journal，可以自己定义 fsync 的触发条件（默认每秒一次），这种方式丢数据的概率就很小了。但是 AOF 方式对 IO 会比较敏感。redis 的 sentinel 做 failover，所以服务可用性也有保证，我们用 gevent patch 过的 redis driver，监听 sentinel 的 pubsub channel，failover 的切换非常快。我们游戏的 leaderboard 都是用 redis 做主存的，连接不高的部分用 mongodb。

图片主颜色的算法可以参考这里：
Using python and k-means to find the dominant colors in images http://charlesleifer.com/blog/using-python-and-k-means-to-find-the-dominant-colors-in-images/

固定尺寸的网格布局可以动态也可以静态，用 Masonry 肯定可以，只是你需要预先随机一个尺寸给那个图片就能达到这个效果。虽然这里不是用的所谓“瀑布流算法”。

这样的数据如果查询的时间单位是按天的话，是适合做一下map-reduce的。这样数据量会小很多（按照上面样例数据会小几个数量级）。处理过的每个ip的流入流出流量按日期计入数据库，这样mysql或postgres保存两个月的应该没啥问题，而且查询网段的时候比较容易实现。

如果查询的时间单位比较细的话，那么每条数据尽量都要保存，那么存在面向列的数据库里面比较合适，HBase是比较常见的选择。这样需要选择好每个属性的排序规则，但是我还是觉得查询起来肯定很慢。最好配合另外一个批处理的服务（MR）生成常查询数据的每日汇总结果，应付绝大多数的查询。

用LunchBar。家里另外一台用Alfred，只是因为用MAS装比较方便而已。

Point在于TextMate很Mac。The missing texteditor for Mac, but it lost it's creator's love.

Panic的Prompt