Google的API终于支持PHP语言了，这对不少前端工程师来说是值得庆贺的事情。
facebook的bigpipe是一种技术，能使一个网页的加载变得更快。
在 http://velocity.oreilly.com.cn/ppts/ChanghaoJiang.pdf 这个PPT的39-79页有详细说明。
我们知道一个HTML页面的加载时间主要分为三部分：服务端生成、网络时延、浏览器渲染。
在服务端生成数据的时候，浏览器是处于闲置状态的，反之亦然。
bigpipe的思想就是将页面分块加载，通过巧妙的JS逻辑，尽可能充分的利用服务器和浏览器的时间（见PPT43页）。
此外，为了对搜索引擎友好，也同时支持页面的single flush。
原文见：http://www.osseye.com/?p=382
说说我的理解，MySQL HandlerSocket Plugin 是一个在 Mysql internal storage engine API 基础上构建的daemon程序。
为什么Mysql internal storage engine API比MySQL直接查询要快？因为直接查询的时候，open/close表的开销占了很高的比例，且互斥竞争比较严重。
MySQL HandlerSocket Plugin绕开了MySQL的client API，对open表的session进行了reuse，并裁剪了很多功能（如SQL parsing, Making Query Plans），实现了一套接近于NoSQL的接口。
我认为大家可以尝试一下这个API，是优化数据库性能的另一条途径。
这是我计划本周五在部门内分享的内容，先贴到这里：
Redis是一款最近比较热门的Key-value数据库，它的代码量少，配置简单，与memcache同样轻量级，对于了解NoSQL是一个很好的入口，相信通过介绍之后，无论是前端和后端开发工程师，都会迅速的爱上这款软件！
* Intro:
o http://dreamhead.blogbus.com/logs/61443218.html
o http://labs.alcacoop.it/doku.php?id=articles:redis_land
o http://code.google.com/p/redis/wiki/ProtocolSpecification
o http://code.google.com/p/redis/wiki/CommandReference
* Features:
o Key-value db
o Fast: all data are loaded in memory and saved on disk
o Supporting data types: Strings(<1Gb), Lists, Hashes, Sets, Ordered sets.
o Interfaces: push/pop、add/remove、sort
o Replication:
+ 一个master支持多个slave
+ Slave可以接受其他slave的连接来替代他连接master
+ 复制在master是非阻塞的，而在slave是阻塞的
+ 复制被利用来提供可扩展性，在slave端只提供查询功能及数据的冗余
* Download:
o http://code.google.com/p/redis/
* Install:
o http://blog.chinaunix.net/u3/102568/showart_2339142.html
* Start Server: ./redis-server
* Close Server: ./redis-cli shutdown
* Command Line Client: ./redis-cli
* Bindings: http://code.google.com/p/redis/#Supported_languages
* APIs: http://code.google.com/p/redis/wiki/CommandReference
* Best Practices:
o Counter
o message queue
o user db
o Autocomplete: http://antirez.com/post/autocomplete-with-redis.html
o Foursquare.com
我们每天都接触到大量的信息，必须要有一个沉淀的机制使其转化为知识，否则在重新利用它们的时候，会消耗不必要的时间。下面我将自己管理知识的方法整理出来，供读者参考。
管理要做的事
最快捷的方式是在桌面上新建记事本；如果你需要用复杂的格式记录它们，建议用onenote；如果你的手机是IPhone、Android、Blackberry系列的，那么恭喜你，还可以使用evernote将你的文件随身携带；不要忘记，小纸条也是很灵活的方式。
管理你的文档
首先要保证你辛苦编写的文档不丢失，为此，我向你推荐几款工具：如果你有自己的备份空间，如FTP、共享文件夹等等，建议使用syncback，它会将你的文档目录与服务器端进行双向同步，显然也没有空间和网速的制约；你还可以用前面提到的evernote或微软的live mesh来进行同步，它们都为我们提供了若干G的共享存储空间。
其次要保证你的文档能被随时找到，我强烈向你推荐Google桌面搜索，它通过为你电脑上的文件编制索引，方便你对其进行查找；另外，不建议使用微软自己提供的windows search，我的Thinkpad X201笔记本，只要启动了它的索引服务，CPU温度就会从正常的45度左右，飙升到80度以上，为了节能和CPU长寿，只得卸载之，而Google桌面搜索就没这方面的问题了。
管理下载的文档
下载的文档特指电影、音乐等尺寸较大大的文件，如果不幸丢失，经济损失尚小，而备份它们的成本却最高。笔者目前也没有想到一劳永逸的办法，毕竟自己花钱购置硬件，总有一个寿命问题。相比较来说，买一块硬盘，加个硬盘盒，是比较经济的存储方式。
管理你的电脑
如果电脑某天不幸需要重装，你便需要手忙脚乱的备份一大堆存放在C盘中的数据，如果平时就将你的数据打理的井井有条，就可以避免这一麻烦。现有几个小办法向读者提供：使用驱动备份专家之类的软件将你的驱动程序备份到别处，如果先前购置的硬件中有驱动光盘，建议将整张光盘做成ISO镜像存放在硬盘上；打开“我的文档”的属性窗口，修改文档路径为C盘以外的某个目录并转移；使用类似Firefox Sync的工具同步或备份你的浏览器书签等数据。
相信大家也有许多自己的经验，欢迎到新浪微博(@房如华bluetent)上与我交流，谢谢。
本周有幸用两天多的时间，与业界顶级的SEO咨询师进行了面对面的交流，收获颇丰。除掉80%不能说的内容，还是有一些common的经验能够分享给大家。这篇文章本身也顺便看看能否带来足够多的搜索引擎流量吧，呵呵。
1、对于百度，平级的文件形式的url要比目录形式的便于收录。
2、在页面里主动做相关网站的链接，并不一定是坏事。假设你的网站是A，相关网站是B，那么，用户从A链到B，比用户从搜索引擎直接点到B要好，此时搜索引擎会认为A更有价值，因为被更多的人点击了。
3、百度关注网站外链的数量，而Google更关注其质量。
4、简单来说，要先保证网站内链的良好结构，再做好外链，否则你可能会浪费很多精力。
5、有一些SEO公司可能在向你灌输错误的理论，因为他们需要你持续的为他们的服务付费，并产生依赖，尤其是一些让你购买他们外链的公司。
我本科是学自动化的，所以工作六年来，一直致力于如何让一台服务器尽可能在无值守的情况下保持工作。但当前两天公司一台服务器的文件系统因硬件原因莫名其妙只读了之后，我突然打算反思自己这种追求完美的观点。
一个服务，放在那里，没人管他，想死是件很容易的事，而且往往都很出人意料，我来从记忆中随便抽些片段：
关于硬盘满：
某天夜里备份一个大目录，先tar后gzip，硬盘满，其上的MySQL服务无法写入，挂掉。
某天tmp分区满，某HTTP Server无法创建socket fd，挂掉。
某个脚本突然多了很多输出，向/var/mail下发了n多消息，导致var分区满，挂掉。
关于内存满：
某个不靠谱的服务需要固定占用2G内存，它为了防止内存泄漏，每天凌晨粗暴的自我重启。某天重启的时候，发现操作系统的内存忽然不够它挥霍了。
在apache的prefork模式下，在并发超大的时候，把系统内存吃光。
关于单点故障：
数据库通常配成一主多从，但主的服务器总有一天会出问题。
若干T的图片服务器，硬盘总是有寿命的，不多说了。
NFS有时候也会给服务添麻烦，比如某个不靠谱的程序员在NFS Server上跑统计脚本，把其它服务器都拖死。
LVS、L7负载均衡器、DNS Server、时间服务器、交换机、路由器、网卡、电源……冗余的代价太高了，有时候我们只能假设它们不会坏，并配上一系列聊以自慰的监控程序。
还有些不重要的服务器，直接放在公司，公司的机房没有UPS，也不一定有备件。如果硬件坏了，虽不影响线上服务，但恢复需要很长时间。如果它是一台开发服务器，那也足以挫伤组员的斗志，估算一下间接损失也可能上万。
关于不健壮的业务逻辑：
到memcache的连接，打开后忘记关闭，一群请求过来，memcache挂掉。
某个SQL语句锁住了整张表，或者创建了超大的临时表，可能几秒内就会把1000个连接占满。
内部的HTTP通讯没有设置合理的超时时间，导致上游压力过大时，内部因连接堆积而瘫痪。
异地备份程序没有确认数据已经传输完毕，就删除了本地数据。
其它：
某天你的网站突然被搜索引擎眷顾了，引发了超大流量，被IDC限速，于是你的服务器就不停的丢包，但你此时还沉浸在幸福当中，却忘了去看网络流量图。
你的隔壁机柜服务器中毒了，可防火墙在你们的上级节点。
以上情况如果平均每个月出现一次，就已经让人足够崩溃了。可是真有那么多Mr. knowall，或者先知，能提前规避这一切吗？从这里可以看出技术管理的重要性，好的团队，好的沟通机制，可以抵抗一些基本风险。说说我建议做和不建议做的：
建议：
核心的服务逻辑尽早做的足够强壮，并封装好，放到整个体系中复用、测试，不断完善并稳定下来。用你最放心的人做这件事情，不要让其他“不重要”的人去修改这个核，要把上述风险控制在你手里。
如果现有的架构已经老旧不堪，考虑新做一个可复用的核，然后一个服务一个服务迁移过去。
内部服务过于HTTP化也不好，内部的通讯是要消耗额外资源的，除非你一定要用nginx来做高可用部署。有些服务可以不Listen端口，而改为Listen socket fd。
有些服务，如果开源的软件已经做了很多年了，就不要自己再做一次，哪怕有创作的欲望，也要克制。把开源软件配置好，不比自己写的技术要求低。
不建议：
亡羊补牢是短视的做法，出现了问题，不要就事论事，关键还要深层次的去想，团队管理和沟通出现了什么异常，而不要划分责任或甚至逃避。我感觉，一个技术相对差的团队不太容易把一个业务搞死，但一个缺乏管理的团队一定会把一个业务搞死，而且是以最浪费资源的方式。
突然想到有两台服务器的服役期快三年了，得想办法赶紧把上面的重要服务挪走。梦想着把我们的系统逐渐改为一个去中心化的架构，这样服务稳定性对硬件寿命的依赖程度就低了。
最近几天利用春节放假的时间，搞定了nginx+php的编译与配置，将源代码和安装脚本都用一个git库维护起来，支持以下特性：
- 在服务器的任何一个目录解压均可，一个脚本完成所有编译工作。
- 将loadbalancer和webserver用不同的配置选项编译。
- php的配置选项与debian发行版保持完全一致，包括suhosin patch。
拖了一年多才完成此事，也算是后知后觉了。计划在三月份，将我负责的所有web服务器及负载均衡器切换到这个体系下。
方法很简单，以Nokia第三版为例，只需要三步操作即可：
1、到这里下载GO Contact Sync，它可以将Outlook的联系人双向同步到Gmail的联系人里。
2、依照Google mobile的步骤，配置自己的Nokia第三版手机。
3、点击手机的“同步”按钮。
非常的方便，而且信息很全面，甚至Google Talk联系人的小头像都同步到手机上了，呵呵。
其实是上周二（4月14日）就已经办了，1740元包年，13个月，每个月可以使用300小时的本地流量。最近一周，我分别在东五环、上地、时速80公里的车上、首都机场旁边和燕郊进行了实地使用，信号都是一样的好，速度都是一样的快，下行超过1Mb没有任何问题。
今天联通出了它未来的3G套餐，貌似150元包月，想钱想疯了？我一直认为接下来联通和移动应该会出一档类似50元100小时之类的套餐，以填补电信资费套餐的空白。没想到它们还生活在太古时代。
最近将公司的一个产品从apache 2迁移到了lighttpd。迁移过程中出现了几次措手不及的问题，但好在没影响线上服务，并且及时找到了原因，也算基本成功了吧，至少今后公司同事做类似事情的时候，不会重蹈覆辙了。
为什么要放弃apache？
这个原因直接从网上搜吧，一堆堆的。从实际工作角度来看，我是这样考虑的：之前用的是apache的prefork模式，它主要的问题是内存占用大（几个G），并且CPU占用会随着瞬时请求增加而飚升。对于一个访问量不断增加的网站来说，这些弊端是不可以接受的。
为什么要迁移到lighttpd？
响应能力高，根据我的测试和网上一些评测报告，粗略的看，能提高一倍左右。负载稳定，这个跟它用epoll还是有很大关系的。内存消耗少，这方面的优势是惊人的，稍后介绍。
为什么不迁移到nginx？
其实我对nginx更偏爱一些，一方面是没看到网上有从nginx迁移到lighttpd的，另一方面对它的并发处理能力很欣赏，但还是因为工作中的复杂情况，没有从apache一次迁移到nginx，确实是忍痛割爱了。
迁移中的重点难点在哪里？
是调优！max-keep-alive-requests和max-keep-alive-idle这两个值困扰了我好久，因为在和apache对比测试的时候，发现lighttpd的并发连接比apache要高几倍，虽说吞吐量大了，但是负载也上去了，后来才发现这两个值设的有点高。这说明，片面追求性能高，也不是好事，比如你可以把keepalive的idle时间设的充分长，但可能瞬时上千个爬虫IP来访问，服务器就挂了。（这块我理解的可能还有些偏差）
在url rewrite方面，apache和lighttpd的规则大部分是相同的，而nginx跟他们就不太一致，很多需要重写。
迁移后的效果如何？
高峰时段的负载也变得很平滑，之前负载的突变彻底消失了，每天的最高负载稳定在2到2.5，很完美的范围哦。
内存占用控制在1G左右。有时候我们不是嫌内存占的多，而是不知道它会占多少。lighttpd在这方面做的非常好，不但内存数量可控，且占用较低；举个例子，同样的fastcgi程序，用lighttpd启动，内存就比apache要小20%甚至更多；在高峰的时候，apache可能会拼命启动很多个fastcgi，而假设一个进程占几十M的话……就等着服务器报警吧，这个时候谁都会束手无策，虽然重启服务很简单，但fork几百上千个进程是需要开销的，更重要的是，每秒还有成百上千的用户在等着访问你的80端口。
一个是图书城，一个是Book Gadget。从主体文字的配色上看，高度一致，甚至右侧的推荐按钮也是相同的，当然后来douban修改成了自己的风格。
现已无法考证这几个网站是谁抄袭谁的了。
今天下午，为了讨论某合作项目，与一个朋友开了次远程会议。
会议的目的是将先前整理的方案进行交流和汇总，并制定某个站点的用户需求和功能列表。如果有一间大屋子，有白板、笔和投影仪，那么讨论起来一定很方便，但恰好条件不具备，于是就决定开个网络会议，并找来一些工具加以辅助。
首先，采用google talk进行文字聊天，因为可以在gmail里方便的搜索聊天记录。
其次，采用QQ语音进行音频聊天，因为相比之下，QQ比google talk的传输质量要好一些，skype可能更好，但我们都没装，于是忽略。
接下来，我们还缺块“白板”，我找来一个叫stixy的网站，这个网站提供类似onenote一样的视图，方便的将文字以贴条的方式记录在白板上，并支持与其它用户的共享和协同编辑。
准备就绪后，会议开始，双方将自己在纸上和ppt上的计划讲解一下，我同时在stixy上记录，整个过程花了一个多小时，达成了许多共识。我起初以为，远程会议是无法达到面对面交流那么直接的效果的，比如聊天的时候可以说闲话，网络质量会影响讨论进展，等等。但实施了一次，发现好处还是非常多的：
远程会议能够让参与者更尊重对方的发言，因为抢话会带来更多的中断，是欲速不达的事情。
远程会议能够让参与者先组织好足够多的语言，然后表达出来，因为你没有那么多形象的手势和白板上的图形可以利用了，如果你不像让对方总质问你每个代词的含义，就把语言组织的更有逻辑些吧。
远程会议能够让参与者更聚精会神的聆听，尤其是做记录的那方。
远程会议能够帮助快速形成结论，因为争吵的成本太高了，大家都付不起，而且，今天是周末，不出去玩还可以睡觉呢，上网多浪费时间啊。
