服务器迁回HK有一两周了，访问状况看着不错。对于鸭梨访问的情况，有带宽/网卡/TENGINX/REDIS/HHVM的层层关卡下，可以保障机器MYSQL无虞。从后台机器浏览看，大概经历了10次左右的网络流量峰值，不过DB没有什么异常。回想起来，从SAE迁出之后，有好久没有使用过Object-Cache了，这次针对程序，单独写了一套缓存逻辑，带有一个有意思的小功能，“投币”，访客访问一段时间后，会根据情况添加缓存的生命周期，单个页面经历热点事件和被抓取的情况下，结果感人。只可惜的是Redis不支持hsets中的key的expire，需要自己实现一套逻辑来维护sets中的key的过期。 阅读全文

不知道从什么时候开始，不管是写独立博客，还是网络应用，甚至写托管博客的人都会朝着“大”网站看齐，去追求网站的响应速度，通俗点说，就是白屏时间，因为据各种报告说，网站打开速度更快一些，带来的用户体验就更好一些，从而带来更多的附加利益。但是对于用户来说，快，并不是简简单单请求数目尽可能少，和服务器吞吐能力尽可能大。那么，怎么快？由于本人水平有限，内容可能有误，欢迎拍砖斧正，和帮助补充。谈到速度（参考物和例子稍后一起提），我们首先能想到的事物有： 阅读全文

两年前写了这个东西[Error Tracker]，还记得周围的人都觉得没有用，唯独师傅说这个东西不错。 来到西厂的时候发现，其实类似的东西投入生产不久，但是沉淀的数据可以带来许多抉择的判断，不过好像厂内的类似东西做的有点复杂了，不适合敏捷使用（单机部署）。 阅读全文

翻硬盘时，看到了老游戏的视频资料。 阅读全文

比较古老的资料，window 游戏汉化资料参考，by chinaavg @shine007。说到汉化，有的时候，你需要代理dll替换原始的导出函数，或许以下例子会对你有用： 阅读全文

清理硬盘，看到了一份BIOS资料，搜索了一下，目测资源好像很少了，未免资源断档，需要它的童鞋无奈，我发上来好了。 阅读全文

很快就要面对新的一年了，该审视一下过去一年里自己的状态了。不过，想想今年校招的童鞋在面试邀约的时候都看过我搞的界面，想想每天PC访问淘宝的童鞋都会执行我写的代码，想想直接写的推荐界面每天的推荐成交额和双十一双十二成交额和引导数量（当然，这些都离不开提供优质内容/快速完备的框架的其他童鞋），双十二侧栏每一条宝箱/红包推送消息都会让我去读写用户数据，费了这么多用户的电（误），也是有点小激动...去年的时候，时不时的会被嘲讽一下，你就为了2000DAV的项目折腾那么多？错误觉得前端应该去做大流量的产品，但是实际不是，老板兼师兄之一吐槽说，前端应该是服务于用户体验的，在又经历了反复重构前后台代码后，觉得虽然折腾，但是值得，毕竟，成品可以节约其他人的时间，尤其是每天依赖这些工作的人的时间。如果你的产品访问量巨大，这只是产品的形态决定的，或者是营销活动带来的，这，不是工程师该有的业务价值。 阅读全文

写了一个简单的小插件，用来加速Gravatar，稍加改写，可以加速其他家的头像。 阅读全文

代码比较多，但是比较简单，一眼就看明白的，so，文字尽量少写了。因为众所周知的网络原因，gavatar也开始越来越慢，写了一个小东西来解决这个问题，过程中遇到了get_headers这个函数，甚是忧伤，记录下来，以免后来人踩坑。 更新记录，函数稍微改了一下，返回值基本和之前序列化后的结果一致，暂时没考虑支持子项也支持数组等（考虑细节性能，还想把没用的http头砍掉....）需求很简单：获取图片的head信息。调试程序的时候发现这个函数的调用很缓慢，即使绑定ip，有时候都能蹦到20多秒。 阅读全文