清理evernote，看到去年8月10日写的博客改版的计划。许多都已经做到了，许多细节处理或许之后有空的时候，可以写几篇长文出来分享。 经过细节调整，一般情况下，可以在1s之内完整“呈现”页面，这靠的不单单是“页面的输出HTML静态化”这么简单的事情来完成的。 此中大概，如果有兴趣，可以参考：[天下武功，唯快不破] 本篇暂且记录一些未完成的东西，其中每一点差不多都能做成单独的服务或者在网上已经有了成型的产品。 阅读全文

09年，有一款脚本相当流行，通过创建随机的tag以及分类，或者给搜索参数添加随机数字/字符串来达到拖挂MySQL的目的。其实不单单对于对搜索没有防备的WordPress有效，对于任何资源有限，而执行时间比较长，没有缓存的操作，都有一定的杀伤力，如果IP数量比较多，且持久的进行测试/攻击，那么便可以造成拒绝服务的效果。昨天发帖之后，有个童鞋倒是提醒了我，于是更新了一下内存缓存的策略。 阅读全文

服务器迁回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的项目折腾那么多？错误觉得前端应该去做大流量的产品，但是实际不是，老板兼师兄之一吐槽说，前端应该是服务于用户体验的，在又经历了反复重构前后台代码后，觉得虽然折腾，但是值得，毕竟，成品可以节约其他人的时间，尤其是每天依赖这些工作的人的时间。如果你的产品访问量巨大，这只是产品的形态决定的，或者是营销活动带来的，这，不是工程师该有的业务价值。 阅读全文