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

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

至少湾区是这样的。

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

我觉得这个问题和『无限猴子定理』(http://zh.wikipedia.org/wiki/%E7%84%A1%E9%99%90%E7%8C%B4%E5%AD%90%E5%AE%9A%E7%90%86) 很相似，那个定理讨论的是概率，无穷小概率时间还是有“可能”发生。
虽然24位800x600的图片看似不大，不过这个数实际是天文数字，实际上不可能。

但是关于索引这些图片倒是比想象中靠谱一些。因为24位800x600图片对应的全部可能正好可以映射到它对应的二进制序列上面应该是1406KB，由于这个空间是密集的，所以这1406KB就可以作为这张图片的唯一编号。那么给定一个照片的二进制表示那么这张照片的编号也就知道了。

不知道我这洋相是否对。

据o6z同学说Lisp最大的问题还是多人协作不方便，Lisp是微语法的语言，大家一起构建一个新的世界很容易造成冲突。所以我对Lisp做Web框架持保留意见，他的生态系统和互联网生态系统没啥交叉。我觉得最应该接受Lisp的还是学校，让学生早点普及Functional programming，而后理解这些function is first class citizen的OO语言（OO和Functional的关系请参考徐X的大作 http://www.infoq.com/cn/articles/object-have-dead）就会更透彻。

Smalltalk的seaside也很有趣，不过它不普及。小众语言的小众框架的命运也就是这样了。况且Rails也不是Ruby这门语言的产物，而是“最佳实践合集”，它要做的是“有态度的Web框架”，它的这种价值取向和其它Web框架又有些不同。

闲扯有些零碎。

Mesloz这个修改过的Menlo不错。看这个post：http://mir.aculo.us/2010/10/12/the-long-search-for-a-terminal-font-is-over/

Instapaper我觉得解决的是long reads的问题。feeds和daily news这些碎片新闻大部分都是短阅读，但是我们时不时发现也有需要10-15分钟去度的long reads。Instapaper帮我们整理这些文章，抽取并重排，让排版更适合阅读。
以前用Evernote，因为它是很早的一站解决方案，可是后来发现Notational Velocity了。

听起来像无线路由器连接太多了……

很牛。
我非常喜欢Pure Reader的设计。可惜没有注册pinboard.in，正在用trunk.ly。希望Pure这个idea可以走到更多网站去。

我也觉得按钮小。内容图片选的很漂亮，不过文字内容很单薄，不耐阅读。

def mid_night_timestamp():
timestamp = int(time.time())
if timestamp % 86400 == 57600: //57600 = 86400 + (60 * 60 * -8)
return timestamp
else:
return timestamp / 86400 * 86400 + (60 * 60 * -8)

This is faster :D
不过仅在时区固定的时候有效，替换一下时区offset就可以了。如果在TimeZone aware的环境，需要用tzinfo的offset修改一下。