适合没事的时候随便翻一页，然后细细品位，结合自己做过的项目，想象该内容对原有项目可能产生的影响，或者看到一页，就会对自己的某个项目产生共鸣了，不管怎么说，我喜欢这本书。

btw，今年的blog计划已经差不多破产了，还好其他的都还坚持着。

目标

类似于监控项目，但是监控端做在web上，监控的内容是嵌入式设备，可以和server做tcp通讯，嵌入式设备和server之间5秒一个消息。server在接收这些消息以后，传输给web客户端，展现在web页面上，页面采用js分析数据。

步骤

1. server端的设计
2. firefox客户端
3. ie客户端
4. server重新设计
5. ie客户端重连
6. nginx的加入
7. flex的加入
8. flex的ie的问题

现在开始第一步，server端开始因为没有概念，所以很简单，有client端来就启动一个erlang的process，然后在接收到嵌入式设备的数据之后，就发送给注册了的process上，一直连接着，大致也就是mochiweb生成的代码，然后添加几句代码，当然指的是web的代码，其他和嵌入式设备通讯的还是有比较多的，然后使用http的chunk支持，每次发送消息出去是一个chunk。

现在加入firefox客户端，由于firefox的标准性，非常简单，用XMLHttpRequest，使用状态3和状态4，3的时候处理数据，4的时候重新连接，发现一个小问题，在3的时候，数据不一定是完整的，于是在处理的时候，发现有结束符号的才处理，没有结束符号的，留给下次处理，基本没有大问题。

现在加入ie客户端，由于IE的XMLHTTP对状态3的支持不好，于是没有办法处理，弃用ie的ajax，google后，发现htmlfile这个activeX控件，基本原理还是iframe，但是处理了进度条问题，不会有一直连接的提示，看着不错，选用，不过在server端需要根据agent，来判断不同的客户端，应为iframe是不会自动处理数据的，需要加入script标签，每个数据提示他的父窗口处理。基本实现功能，留下的问题是重新连接。

这个时候，qa在验证问题的时候说，ie和firefox都有内存问题，放久了就浏览器挂了，所以需要重新设计一下，其实想想也正常，客户端一直在接收数据，不死才怪呢，因为如果没有异常情况，连接是不会断开的，5秒一个数据，都存在client的内存中，死定了，好像在client端没有办法断开连接，那就在server端想办法吧，于是在server端记录消息量，在一定的数量的时候，断开，目前我们选择为100个，差不多10分钟，这个时候在firefox表现良好，而在IE中就问题大了，IE暂时还没有办法重连。

IE的重连问题，又google了，发现htmlfile其实就是一个window类型的js对象，这就好办了，动态监测window的状态，找到一个状态是window.document.readyState，连接的时候状态为loading，而断开了就是complete，呵呵，这个就简单了。settimeout一下，搞定。

在实际的部署中，mochiweb的webserver只是一点点内容，需要配合java的application才可以完成所有内容，于是在前端加入了nginx，大家都开始不工作鸟，google大神有上马了，原来是nginx的buffer的问题，干掉它，在对mochiweb做反向代理的时候，加上buffering off，搞定。

目前server，firefox，IE都情绪稳定这个时候flex加入了进来，开始的时候，想选用flex的socket对象，可耻的flex的socket对象，需要认证服务器，在可能的情况下，需要对认证服务器做ha，做lb，基本不可以接受，在没有确定没有其他方法之前，先不理socket，后来发现了urlstream。

urlstream，可以监控数据传输，在必要的时候处理一下数据，状况和firefox的xmlhttprequest差不多，并且也没有垮域认证的问题，就是它了。

正当爽的时候，IE上的flex又发来问题，在做客户端的时候，IE总是不时的来捣乱一下，总之，在我记录google记录之后，到现在已近快2年的时间中，搜索的次数，已经接近2w次，平均一天30次左右，当然这次，google也没有让我失望，IE可耻的做了2k的buffer，不到这个时候就不给结果，当然我也只能做做坏事了，发现是ie先给它上去2k的无用数据，在贡献二氧化碳，浪费能源的路上，我又走上了坚实的一步。

终于到了不是完成的完成，过几天他就要自己去跑了，希望他一路走好，由于现在终端数量不多，就不谈性能问题了，让他去吧。希望以后我在做10W个终端，10W个浏览器的项目的时候，他们都还活着。

• erlang ha的实现方案
• ajax长轮询的完整解决方案，包括客户端和服务端（erlang）
• flex长轮询的解决方案
• flex的安全机制，是指跨域访问的时候，包括http和socket

另外有些想法没有实现过

• erlang mnesia的性能测试

这些应该都会成文

看来应该立个计划,如何好好处理一下evernote中的内容了

初步想法如下

1. 分为多个notebook,把以前有兴趣的,现在没有兴趣的内容分出去,或者导出,可以加快evernote的速度
2. 创建新的notebook,把自己已经理解的内容分离出去,或者导出
3. 创建新的tag,标明用于查询的文档,就是一些信息,而不是需要思考的内容
4. 新的tag,标明用于实践的文档,或者需要验证的,或者自己未理解的
5. tag需要更加细化,解除现有的基本是一个文档一个tag的问题,让以后查询更加容易
6. 把原来存在evernote中的pdf文档,放到dropbox中

暂时就以上这些内容,不过时间可能会很久,怎么说evernote的数据库都快超过100M了,大部分都是文本的内容.不过相信这么做还是非常有意义的.

究其原因，应该是以前涉及到的项目也比较小，基本是一条路走到底，N个项目也搞定了，需要做验证的东西就都是足够小，一般一两天也就可以搞定，内容基本也就在java内部，有多年的工作经验，也就得心应手。并且以前做TL的时候，在项目前期和后期会忙一点，在中期还是一个比较空的时候，可以做很多自己想做的事情，时间也比较稳定，基本没有人打扰。

当然，搭建验证环境也是一个麻烦的事情，象以前java，基本就在eclipse里就搞定了，现在的环境，需要涉及几个linux的环境。

而现在，很大一部分时间用于文档的阅读上，涉及的面太广，最近一个项目，就涉及到嵌入式系统，可能的erlang语言，网络编程，手机客户端，手机web客户端，以及正常的PC web客户端，但是PC的web客户端又会有flex部分，并且项目又有较高并发的要求。综合起来，就是一个特别复杂的系统，而验证的部分也就特别多了。先不要说验证，先假设一个相关的架构都已经足够复杂。需要验证的点到处都是。

另外一个问题，在做Architect的这段时间内，感觉会议就特别多，和客户的，和pm的，和开发人员的，和qa的，可以说没完没了来形容，我记得有一天最多的会议是6个，其中有3个是一个小时以上的。

Architect需要做到的涉及面，也就是阅读文档的这块，还可以用零星的时间来处理，那需要动手的这块，应该如何解决呢。从理论上来讲，GTD的方案应该可以用上来，把需要大块的时间先安排，以前由于事情不是很多，GTD基本只是做到collect，现在看来，应该是需要往下一步发展了。

昨天从当当订货，今天中午送到了，不过从昨天开始看英文版的电子书已经看到第10章，看来这本书，又要被拿来垫桌脚了，如果开始写程序了，应该也不会翻这个，还是直接翻文档来的快。原来以为英文版本的，靠我的英文水平会有很多理解不了，不过语言类的书一般都比较通俗易懂，不像一些方法论的，看PEAA的时候，才叫头疼呢。

不过拿到货，有的时候不想用电子产品的时候翻翻也好。另外后面的章节应该会稍微难懂一点，有本中文书，还是可以快速浏览一下。

终于进入erlang的怀抱了。

在笔记本上安装好ubuntu之后，看到现在的ubuntu已经有很好的支持虚拟机了，类似ubuntu-vm-builder，还有libvirt等，都支持多种虚拟方式，比如xen，kvm，qemu等。

首先看到libvirt可以支持命令行，于是就选择了libvirt，安装可以使用virt-install，管理就是virsh了，感觉比较简单，有问题可以man virt-install，而virsh就是一个shell，里面的命令都可以看到帮助。比较麻烦的就是网络，因为笔记本在家里用的是无线，在公司用的是有线，做bridge比较麻烦，并且家里和公司的网段也不一样，公司也分配不到多余的ip，于是只有做nat了，反正也不是做服务。

另外linux上本来就有ssh服务开的，真想处理一下，也可以做ssh跳板，或者ssh 隧道。

接下来就是开始虚拟操作系统的安装过程了，选什么好呢，再做几遍LFS（反正过年空），或者开始gentoo？或者先装个server版本的centos吧。

关键的还是需要先升级一下内存，郁闷的是去百脑汇打听了一下ddr3的笔记本内存，可耻的年前没货鸟！看来过年还是在家里玩wii吧。

基本功能是一个大量写操作的中间数据存储，在使用大量的put和get操作之外，也有一定量的fwmkeys的接口，用于检索某个操作的所有数据。由于个人的不专业，虽然在原型的时候，有做一定的测试，包括压力，但是没有对所有的接口做压力测试，于是就出现了在压力测试的时候，tokyotyant经常达到100％的cpu使用，然而，要做的事情，总归是要做的。于是对现在用到的所有tokyotyant接口做了一个压力测试。

得到的结果如下

threads       times        time（ms）        action            cpu   
5              200000        62625            write            15％
5            20000        6515            write            5％   
5            20000        50062            read            2%   
5            20000        23797            read            4%   
5            2000*30        16297            write            12%   
5            200            126109            fwmkeys+mget    99%   
5            200            125031            fwmkeys            99%   
5            2000(30)    7281            mget            4%   

这个结果可真够惊人的，fwmkeys提供了一个看似很美丽的接口，却是一个陷阱。接下来就优化使用的方式了，对于原有fwmkeys做的事情，在java端手工生成kay值，在做mget，幸亏这个业务还可以控制。

别人都早做了新年的计划，不过我比较老土，没有过农历新年，总没有新年的感觉，所以现在做计划，感觉还是有点早。

简单列一下吧，希望明年的这个时候，会是一个满意的答卷。

• 5本书
• 每周2篇blog，从2月1号开始
• 一个用erlang实现的应用，
• 学习用c重新实现memcached（只是学习）
• 一个分布式计算的学习和验证（可能是gearman）
• 当然照顾好家和将要到来的小宝宝，还是重中之重