百年修得同船渡
千载结缘同窗读
三十沧桑染鬓白
少时冰心在玉壶

前几天偶尔看了篇奇文“闾丘露薇：扔向布什的鞋子和记者伦理学”，文中最后的话很有意思：“不过一个真正的记者，应该是明白，工作就是做一个记者应该做的事情。而社会，应该是鼓励记者做自己应该做的事情，所以，扔鞋子的记者，在我眼中，绝对不是一个英雄，喊口号的记者，也不配记者这个称号。”

看了这篇文章，我不禁想到百年前的谭嗣同，他的角色最多不过是参政者（破格提拔官至四品），职责只是帮上司出谋划策，按理说实在犯不上把自己的小命拼上（何况上司已经倒了），但他在关键时刻没有选择“出国旅游”，而是选择了“一定要流血警醒世人”。当然，我们不能要求每个人都这么选择，包括我认为自己都不会做出同样的选择，但没有人能，也没有人配判定他死的值不值得，因为你的任何判定其实都是在判定“如果我是谭嗣同，选择了死，值不值得”，而死对于谭嗣同，只有一个答案：“值得”，因为他这么选择了！

世界本没有真相，我无意讨论伊拉克是被美国“占领”了，还是被“扶助”，但在这样一个颠沛流离的国度里，很明显两个鞋子发出的声音要比一个称职的记者发出的声音要震撼得多！因为两只鞋子让世界人敬佩这位记者，敬畏伊拉克人民，而这是一个仅仅称职的记者奋斗一辈子都难以做到的。

不是人人能都当出头鸟，我相信闾丘露薇和我一样都不具备这样的勇气和胆量，每人都有每人的选择，但当别人选择了我们不敢选择的东西，请别侮辱他！

当人遇到困惑的时候，读一读TAOCP，会有境界的提升

继趋势、瑞星等公司后，奇虎公司昨日首次披露了“云计算”战略，该公司已经部署了超过2000台服务器的国内最大的云计算中心，借此正式杀入“云计算”战局。

　　奇虎董事长周鸿祎昨日给部署“云计算”的公司设置了一个门槛，称“必须有1000台以上的服务器”才能保证实现“云计算”战略。奇虎方面表示，“云计算”的实现要求安全厂商必须拥有海量用户，足够的服务器群以及海量数据处理能力，三者缺一不可。而庞大的数据中心就要求至少拥有1000台以上的服务器。

　　奇虎内部人士透露，奇虎已经在全国20多个城市的机房中购置了超过2000台服务器，带宽达到50G，借此组建自己的“云计算中心”。

结论：记者SB or 奇虎SB or BOTH

int SelfSort(vector<int>& vec)
{
int loop_number=0;
for(int i=vec.size()-1;i>=1;)
    {
     loop_number++;
     if(vec[i]<i)
        swap(vec[i],vec[vec[i]]);
     else
        i--;
    }
return loop_number;
}

int main(int argc,char* agrv[])
{
srand(time(NULL));
vector<int> vec;
for(int i=0;i<1000;i++)
     vec.push_back(i);
random_shuffle(vec.begin(),vec.end(),p_myrandom);
cout<<SelfSort(vec)<<endl;
return 0;
}

DCF chm

what is Javascript Development Environment

JavascriptDevelopmentEnvironment，简称JSDE，是一套面向特殊需求的JS开发部署环境，对于JS的开发人员，它支持扩展JS语法、分析JS工程、分析CSS工程、整合JS代码、分析JS工程、除错等功能，是一套基于linux平台的，面向RIA开发人员的开发环境。

需求来源

JSDE的需求最早来源自RIA组的JS开发实际环境，JS开发需要两套系统：开发模式和线上模式。开发模式为人为编写的代码，线上模式为经过除注释、整合、混淆后的代码。可以近似的理解为开发模式对应源代码，而线上模式对应包含、link后的目标代码。
以linux下GCC编译环境为例，需要makefile的依赖分析， gcc的预编译、编译、链接等环境，最终形成从源代码.c文件到线上部署的可执行程序的转变。不像成熟的编译语言，JS语言没有统一、商业化的线上部署的环境支持，正基于此，为了提高整个RIA的开发效率、线上部署效率，一套灵活、具体的可靠的JSDE就显得尤为重要。

功能

JSDE具有以下12点功能：
1，致力于为RIA打造基于linux平台的JS开发部署环境：
基于通用框架，面向特定需求
2，具有支持类如自定义函数等扩展JS语法功能：
开发人员可以自形扩展javascript的语法，以达到方便工程的目的，扩展的语法由JSDE负责进行解释和转义
3，具有检查JS语法错误功能
可以检查代码的语法正确性
4，具有去除注释功能
可以去除代码的各种注释说明，以达到代码瘦身的目的
5，具有去除冗余代码功能
可以去除代码中的冗余部分，比如多余的分号、空格等，以达到代码瘦身的目的
6，具有整合代码功能
可以通过预编译，实现解释语言的include
7，具有依赖关系分析功能
类似Makefile，分析工程中的文件、函数等依赖关系，给出结构图，方便调试
8，具有编码检查功能
可以针对实际线上环境，检查工程文件编码格式，并提出警报
9，具有include once和检查功能
实现#pragam once等宏定义，保证依赖文件关系保持拓扑性(无环)
10，具有整合CSS功能
根据CSS语法和依赖关系，整合CSS代码
11，具有发布工程的功能
按工程配置，发布工程，完成开发模式到线上模式的转换
12，具有代码混淆功能
混淆代码，实现霍夫曼编码，达到代码瘦身的目的

最近的竞技体育真多，PGL、NBA，Euro2008，白天黑夜连滚播出。竞技体育的一大特点就是只重结果，结局只有赢或者输，强调享受过程只能是loser的言论。在工作中，也要具备这样的精神，期待胜利时刻的那一声怒吼。

    话说部门第N腐败归来后，已近午夜，登录进服务器，半天在VIM敲不进一个字符，脑子里想起白天看的一个小灶消息，“林丹为什么拿球拍怒砸韩国羽毛球队教练李矛？”：
    话说，林丹走过韩国队教练席的时候，李矛悄悄的在林丹耳边问：“听说你买中石油了？”，超级丹遂大怒，挥拍砸向......
   
    PS：推荐一下偶像LX的博客，下次他来游戏频道做客，我一定一定要和他合影！！！
    http://blog.sina.com.cn/luoxian1984

这几步，走的很艰辛
那几句，说的挺悲伤
怎料未施幕前胭粉
隐现幕后岁月沧桑
辗转星空长夜
女人决绝泪光
昔高大身影
今意外的镇定慌张

此一幕，看的好热闹
头一条，炒的蛮开心
果然张张天上君子
又食人间烟火气息
大国气象价值
半生奋斗泡汤
你悲欢离合
我年终的八卦乐章

    前段时间给N年前的一些代码code review，其中涉及到了一个人机博弈的程序。人机博弈中有一个很重要的结构，就是优先队列，其作用的是能够随机的insert一些数据，并保证随时能获得最小(大)的点，其实该结构在大部分的图算法中（包括寻路问题）也很常用。我原来的代码使用heap实现的，不过最近看了一篇paper，是描述《帝国时代》游戏中寻路算法的数据结构的，很是新颖，其用线性表+缓存的结构就可以达到相当快的速度，于是想拿它来试试，看看它和堆哪个快。结果很失望，还是堆快，而且快的不是一星半点，当然也许在特定领域会有不同的表现。
    为了完善该paper的思想，我决定对这个结构进行改进，看看能不能接近或者超过堆。先看看堆的优先队列是如何实现的，我这里使用STL里面的结构：
class PriorityQueueHeap
{
private:
  vector<int> vec;
public:
  int ExtractMin();
  void Insert(const int value);
  void Display(){}
  bool IsEmpty(){return vec.empty();}
};
void PriorityQueueHeap::Insert(const int value)
{
vec.push_back(value);
push_heap(vec.begin(),vec.end(),greater<int>());
}
int PriorityQueueHeap::ExtractMin()
{
pop_heap(vec.begin(),vec.end(),greater<int>());
int min=vec.back();
vec.pop_back();
return min;
}
    接下来，我开始对线性表的结构进行改进，首先将固定缓存进行扩展，变成了动态缓存，在做了这个改进后，发现性能有显著提高，大约相当于STL Heap版的60%，这当然是不令人满意的；而后，利用桶排序的思想分割线性表并结合动态缓存修改算法，经过一系列精心的优化（比如减少函数调用次数，利用内联等等）后，惊人的效果出现了，测试表示改进后的时间比STL要快了将近30%，测试程序如下：
srand((unsigned)time(NULL));
for(int k=0;k<1;k++){
 KobePriorityQueue pq1; (PriorityQueueHeap pq1;)
     for(int i=0;i<=100000000;i++){
     int value=rand()%16777216;
     pq1.Insert(value);
     if(!pq1.IsEmpty()&&rand()%8==1)
        pq1.ExtractMin();
     }//end for i
}//end for k
    KobePriorityQueue是经过我改进后的结构，PriorityQueueHeap是STL最小堆实现，测试程序会不停的插入节点，并随机取最小点，随机数1/8的来源是因为大多数寻路问题（棋盘问题）新增节点和删除节点的比是8。测试结果如下(linux 4核,4G内存)：

根据我上篇提到的boost::object_pool的一些问题，我试着把object_pool做了一些改进，改进完的性能测试如下（测试环境linux服务器,4G内存，4核CPU(3052MHz)）
#include "kobe_object_pool.hpp"
using namespace std;
using namespace boost;
//--------------------------------------------------------------
class SS
{
public:
int value;
float value2;
SS(){}
};
//--------------------------------------------------------------
int main(int agrc,char** argv)
{
boost::kobe_object_pool<SS,boost::default_user_allocator_new_delete> my_pool;
int test_range=10000000;
for(int i=0;i<test_range;i++)
    {
     SS* p=my_pool.construct();
     my_pool.destroy(p);
    }
real    0m0.049s
user    0m0.040s
sys     0m0.000s
//--------------------------------------------------------------
boost::object_pool<SS> my_pool;
for(int i=0;i<test_range;i++)
    {
     SS* p=my_pool.construct();
     my_pool.destroy(p);
    }
real    0m0.125s
user    0m0.120s
sys     0m0.000s
//--------------------------------------------------------------
for(int i=0;i<test_range;i++)
    {
     SS* p=new SS();
     delete p;
    }
real    0m0.695s
user    0m0.690s
sys     0m0.000s
//--------------------------------------------------------------
return 0;
}

可以看见，使用我的kobe_object_pool要比boost_object_pool快了1倍多，比常规的内存分配快了一个数量级。这里有一个说明：
kobe_object_pool要求使用者调用完construct后一定要调用destroy，以保证对象的析构可以被正常唤起，否则将会有隐患的资源泄漏；而boost::object_pool则不然，它可以在pool析构时释放用户所遗留析构的object。这也是boost::object_pool的一个优点吧，但如果用户可以保证唤起析构，那么使用kobe_object_pool还是有性能优势的。

    boost::object_pool绝对是一个超失败的设计！该内存池模块，基于sss(simple segregated storage)，以32为长为block大小，成倍增长，本来挺好的设计思想，利用了chunks空间存free list既节省了overhead空间又节省free list空间，还包装了对象构造和析构，但就是毁在了它的释放操作。真是不看代码不知道，一看吓一跳，它的释放效率居然是O(N)，原因在于它的free list不同于boost::pool的free list，它的free list是有序的，我理解设计者的目的，因为有序的free list可以保证在最终垃圾回收时的效率保持在O(N)（否则是O(N*N)），但设计者难道不知道释放chunk的使用频率远远大于最终回收时的一次吗？鬼才会使它呢，真是失败中的失败。。。遗憾啊
    补救的方法一个是使pool代替（但这样就会丧失面向对象操作的遍历，比如需要自己调用构造析构等），或者自己写一个object_pool的版本。
PS：顺便搜了一下，拍的人还不少，http://lists.boost.org/boost-users/2007/03/25888.php

     今年9月9日是中国共产党第一代领导人毛泽东逝世30周年纪念日。与30年前举国同悲、万民哭泣的哀悼相比，大多数中国人对毛泽东逝世纪念日不再有特别的感受，年轻一代甚至根本不清楚毛泽东的生卒日期。

    近日在北京某大学随机采访了五名学生，他们都不知道毛泽东逝世的日子。在被要求“用一句话评价毛泽东”时，五名学生中有二人说毛泽东建立了新中国，三人说他有功也有过。几名学生的回答基本符合文革后官方对毛泽东“功大于过”的评价。不过，中国社会不同阶层对毛泽东的评价也大不相同：很多知识分子认为毛泽东发动的“反右”和文革给中国带来深重灾难，历史还将重新审视毛泽东；在不少工人、农民以及一些痛恨腐败、敌视西方的人士眼里，毛泽东仍是正义、清廉的化身和对抗西方的英雄。
 
     作为创始人和领袖，毛泽东率领中共经过28年的残酷战争，终于在1949年建立了一个由中共主导的新中国。这一改天换地的创举，使后来的继任者无论与毛泽东有多大的歧见和恩怨，都不能或不敢抛弃毛泽东的旗帜。

     但毛泽东晚年的极端路线又使中国陷入严重危机。在毛泽东去世两年多后，中国进入邓小平领导的改革开放时代。从1978年开始，中国为推进改革开放，和知识分子联起手来从各方面否定毛泽东的文革路线，开启了一场影响深远的思想解放运动。

    对很多中国人来说，改革开放的过程，在一定程度上就是抛弃毛泽东的政治遗产和生活观念的过程。政治上，毛泽东被一步步抬下神坛，从一个“句句是真理”的圣人变成了“晚年犯了严重错误”的领导人；经济上，毛泽东深恶痛绝的私有经济开始蓬勃发展，中国人的整体生活水平得到空前的改善；文化上，毛泽东坚决反对的所谓“四旧”和“资产阶级生活方式”只是如今多元文化的一部分。

维护毛泽东

    然而，否定毛泽东文革路线的根本目的还是要维护毛泽东建立的政体。30年来，每当反思毛泽东向反思专制制度方向发展时，就会被制止，同时以歌颂毛泽东打天下时的“功”掩盖他建国后的“过”。

    经过多年的重复，毛泽东的“功”早已被媒体宣传到极致，例如他如何领导长征、如何打败蒋介石，如何保持艰苦朴素的生活习惯等等，但对毛泽东1957年以后发动“反右”、“大跃进”和“文化大革命”摧残知识分子和传统文化，导致数以千万计中国人“非正常死亡”的“过”，却一直讳莫如深。这种宣传并不仅是为了捍卫毛泽东的个人声誉。

    令人尴尬的是：毛泽东的“功”大多都是好几十年前的事，从中可以利用的价值已十分有限，而毛泽东强化统治、发动文革的“过”却殷鉴不远，既不能深究，也不能让毛“七、八年再来一次文革”的预言应验。因此，对毛泽东的纪念往往只能“舍近求远”或干脆保持低调。

    有关毛泽东功过的话题恐怕还要持续很多年。一方面，毛泽东的斗争勇气和始终代表社会下层的平民精神，使他仍受到许多百姓的怀念；另一方面，毛泽东留下的阶级斗争理论和乌托邦式的共产主义理想等遗产已被彻底抛弃，但他在中国政治中刻下的“毛记”烙印仍清晰可见，成为中国现代化进程中难以逾越的障碍。

于泽远