博客园_Memento..

程序猿的逆袭-Dota玩什么英雄最容易拿MVP？

2011-12-31T04:49:00Z

相信很多“牛人”都被一些宅男学弟问过这个问题：学长，我作为一个初学程序的菜鸟，要怎么样才能提交自己的编程水平，变成牛人呢？

说实话，这个问题深奥地我有点回答不上来，无外乎只能告诉他“多读”“多写”“搞好数学和算法，练内功”“用好设计模式”“看《编程之美》”等等之类的空话套话。后来剃刀阿遠给出了一个答案让我深受启迪，他说：就一句话——多写给人用的代码。

这句话第一次听上去也许觉得有点装逼，实则不然，我非常认同这个观点。

好吧，宅男学弟又开始问了：学长，什么样的代码才是给人用的代码？毕竟我一个菜鸟我又不是腾讯不能弹窗口邀请别人来用，别人为什么要用一个菜鸟的代码呢？

这个问题相对就更非常具体了，我个人认为，有实用价值同时又让人觉得亲切有趣的程序就可以了。

例如，Dota是一款80后程序猿耳熟能详的游戏，尤其是还没走出大学校门的挨踢宅男的最爱。毫无疑问，如果我们以Dota作为突破点，只要idea有意思、跟Dota紧密相关，就算是菜鸟写的程序也能在学校BBS里被大家争相传阅。

本文就以“统计Dota玩什么英雄最容易拿MVP”为例，做一次抛砖引玉。文末我们可以讨论更多关于Dota辅助程序的idea。

11对战平台是最近流行的Dota平台，与其他对战平台不同的是，11有海量的统计数据。对于每一个玩家，都有最详细的统计，细到包括他所擅长的英雄、历史上用哪个英雄做了哪些事、平均某个英雄出场杀敌数、甚至细到该玩家历史上一共拿了多少个Double Kill都有记录。

本文仅仅示例如何统计MVP而已，相对于11对战平台的数据宝库来说，可谓是“弱水三千，只取一瓢”。思路是这样的：抓取大量（如十万个）活跃玩家的历史场次信息，对所有场次的MVP英雄进行统计。十万个活跃玩家涉及的总Dota场次是千万级的，统计样本已经很充足。

有了基本思路，我们再理一个详尽的流程：

1.抓取数据并保存到本地。（涉及的新手知识：如何抓取网络数据包、通过WebClient下载HTML网页）

2.分析已保存到本地的数据，作出记录。（涉及的新手知识：简单的正则表达式、处理JSON）

3.制作直观统计结果（涉及的新手知识：LINQ和lambda表达式、文件的读写）

这么一个简单的程序，对初学.NET的新手来讲，可以带着兴趣锻炼到如此多的基本功知识点，比看什么枯燥的xxx入门到精通书籍有趣多了！ o(∩_∩)o

第一步用Fiddler抓包获得用户统计页面的URL

通过抓包我们知道：

1.用户统计页面的地址形如：

http://i.5211game.com/rating/?u=4629868

u后面是用户的ID

2.需要登录才能查看统计结果。我们程序获取页面时，可以通过设置Cookie来模拟登录。

第二步使用WebClient构造请求

Cookie部分设置为Fiddler里所抓取到的Cookie值。如果抓取成功就保存到本地文件，文件名以用户ID命名。

  /// <summary>
        /// 抓取某个玩家的数据o
        /// </summary>
        /// <param name="i">玩家平台的ID</param>
        private void GetFiles(int i)
        {
            WebClient wc = new WebClient();
            wc.Headers.Add("User-Agent", "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1");
            wc.Headers.Add("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8");
            wc.Headers.Add("Accept-Encoding", "gzip,deflate,sdch");
            wc.Headers.Add("Accept-Language", "zh-CN,zh;q=0.8");
            wc.Headers.Add("Accept-Charset", " GBK,utf-8;q=0.7,*;q=0.3");
            wc.Headers.Add("Cookie", "设置为你自己的COOKIE");

            wc.DownloadFile(string.Format(urlTemp, beginId + i), (beginId + i).ToString());

}

第三步分析已抓取文件中的数据

用到了简单的正则表达式。本例中所处理的对象为JSON，我们采用Newtonsoft.JSON进行处理。将分析结果保存到Dictionary<string,int>数据结构中，同时更新统计的总场次。

/// <summary>

        /// 读取之前所抓的文件内容
        /// </summary>
        /// <param name="l"></param>
        public void ReadFiles(long l)
        {
            var sr = File.OpenText(l.ToString());
            string content = sr.ReadToEnd();

            //正则表达式提取出HTML文件中的JSON
            var m = Regex.Matches(content, "HeroList.*]", RegexOptions.Compiled);
            if (m.Count > 0)
            {
                //将JSON变成Record类
                var list = JsonConvert.DeserializeObject<List<Record>>(m[0].ToString().Replace("HeroList = ", ""));

                foreach (var item in list)
                {
                    if (!dicMvp.ContainsKey(item.heroname))
                    {
                        dicMvp.Add(item.heroname, item.mvp);
                    }
                    else
                    {
                        dicMvp[item.heroname] = dicMvp[item.heroname] + item.mvp;
                    }

                    //累计场次
                    BattleCount += item.lost + item.win + item.offline;
                }
            }
        }

第四步制作直观的统计结果

软件的用户怎么查看程序运营的结果呢？一般无外乎就是文本文件、网页、图片。我们先写个简单的文本文件吧！。（如果写个漂亮的HTML5页面，相信效果会非常好哦）注意在输出结果前，先把Dictionary<string,int>排序一下，可以使用到简单的lambda表达式。

/// <summary>

        /// 分析结果
        /// </summary>
        private void GetResult()
        {
            var sw = File.CreateText("result.txt");
            StringBuilder sb = new StringBuilder();
            foreach (var item in dicMvp.OrderByDescending(p => p.Value))
            {
                sb.AppendFormat("{0}:{1}\n", item.Key, item.Value);
            }
            sw.Write(sb.ToString());
            sw.Write("\n\n总统计场次:" + BattleCount);
            sw.Close();
        }

运算结果是这样的：

在已统计的数十万场比赛中，最容易获得MVP的英雄前十名依次为：神灵武士、屠夫、嗜血狂魔、赏金猎人、幽鬼、影魔、山岭巨人、召唤师、敌法师、先知。当然，如果统计范围再大一点（把抓取数据的程序跑一整天即可），涉及场次达到千万级，结果会更加准确。

怎么样，非常简单吧？嘿嘿，之前说过了，本文只做抛砖引玉，为那些初学.NET找不到练手项目的人增加一些思路。您可以根据本文很轻松地制作出“最容易打钱的英雄”“杀人数最多的英雄”“最容易推塔的英雄”“最坑爹的英雄”等等等等。。。

关于Dota辅助程序

其实，当您熟知了本文所提及的这些“基础知识”以后，您会发现11对战平台的统计数据可以做非常多的事。

关于Dota辅助程序是我一位同事提出的，可以是各种对战平台（不限于11）的插件形式。可以做的事情有：

1.根据海量统计数据，在某场Dota比赛开始后，根据场上10个英雄，告诉玩家哪个英雄最容易获得MVP。

2.根据海量统计数据和场上已选的9个英雄，告诉玩家应该选哪个英雄更容易打出好的成绩。

3.根据海量统计数据告诉玩家此局应该怎么出装备、怎么升级能甚至整体策略。

4.根据海量统计数据（尤其是天梯的数据），告诉玩家在CM模式（或其他组队模式）应该怎么选英雄搭配（还可以结合对方选的英雄实时运算新策略）。

…………

砖已经够多了，玉就靠你们了。 o(∩_∩)o

有任何问题，欢迎咨询，刘小排r（新浪微博http://weibo.com/cloudera)知无不言，言无不尽。

文中原代码下载地址http://files.cnblogs.com/azure/11Stat.rar

本文链接

来，再做一个社会化推荐引擎

2011-11-29T18:01:00Z

A.背景

在阅读本文之前，我们强烈建议您阅读一下郑昀的《来，做一个社会化推荐引擎》和《一个想法从构思到实现只需7天》，本文所讨论的议题以及我们正在做的事情，都始于他以前在相同领域的工作与思考。我们的测试版社会化推荐引擎取名为“玩聚猫”(http://dullcat.com) ，也是在名称上延续郑昀在三年前发布的同类产品“玩聚SR”。

当然，我们并不是在探讨如何简单地复制郑昀以前的工作，而是探讨如何站在巨人的肩膀上，把社会化推荐引擎做得更好、更全面、更讨用户喜欢。

郑昀在三年前对此的定义是“选择一批IT业界人士的社会化媒体分享源，如曹增辉、冯大辉的GoogleReader分享，白鸦、困兽的twitter，张亮的饭否，还有叽歪de、delicious等等。对这些信息源的分享链接进行汇总，一个信息源推荐就算一票，综合票数、信息源权重、推荐时间点、信息源类型等多种因素，最终形成像鲜果热文、digg或Reddit一样的跨平台社会化推荐引擎，并进一步引入语义关联技术，进化到协同过滤+语义过滤的自动化系统。”

由于数据源的原因，郑昀的定义比较强调“IT业界人士”，而我们想淡化这一点。

我们认为，社会化推荐系统是从社会化媒体中，根据一系列的算法，发现热门内容的系统。其使用的算法除了常规的数据挖掘、聚类外，主要是对各种信息源的『分享行为』进行汇总，对『分享行为』进行加权，综合『分享行为』的数量、信息源权重、推荐时间点、信息源类型等多种因素。她能分享最有价值的信息，能具有视野发散度，能削减信息爆炸。

『分享行为』是指用户在社会化媒体中对特定内容进行分享的行为，包括但不限于新浪微博的“转发”、人人网的“喜欢”、Google Plus的“+1”、以及Digg类网站的“顶”等等。

C.我们为什么要重复发明车轮？

原因很简单的，诞生于三年前的郑昀版社会化推荐系统有他的局限性：

a)由于过分依赖于IT业界人士,所推荐的内容难以吸引非IT人士

b)数据源较少（无论是种类还是数量），Google Reader Shared Item和Twitter占据了超过85%的信息。

c)由于b)，没有形成在更大范围通用的排名公式。

d)没有像Google PR( Google PageRank)那样的指标，无法向用户直观地体现特定文章的价值。

e)推荐者权重模型（如名人效应）没有得到体现

因此，我们打算重新发明车轮，进行一场新的社会化推荐革命！

D.玩聚猫社会化推荐的数据源应该包含哪些？

我们把国内社会化分享媒体分为以下四类：

a) 微博、轻博客类。包含腾讯微博、新浪微博、网易微博、点点网、新浪Qing等；

b) SNS类。包含人人网、开心网、腾讯朋友等；

c) 书签、网摘类。包含强国网摘、CSDN网摘系统、爱库网、QQ书签、有道书签、百度搜藏等等；

d)RSS阅读器。包含Google Reader、鲜果、抓虾、豆瓣9点等等。

E.玩聚猫在处理不同类型社会化分享媒体的『分享行为』要考虑哪些因素？

上文也零星提及了一些，归纳起来有以下几点重要差异：

a) 『分享行为』类型不同。新浪微博有“转发”、人人网有“喜欢”、豆瓣9点有“推荐”、有的网站只有“阅读量”。

b) 网站权重不同。例如爱库网上最热的内容，权重肯定没有新浪微博上同一时间最热的内容权重高。

c)『分享行为』发起人的权重不同。例如李开复转发了一条微博，权重会比50个我转发同样一条微博更高。

d) 『分享行为』的时间也会影响权重。很多时候对于同一信息源、同一内容的『分享行为』是呈指数衰减的。例如在郭美美事件，我第一次在新浪微博看到时已经拥有了两万次转发，我看完后决定转发第两万零一次，明显我的这次转发的权重比第两千零一次转发的权重小。

e) 考虑去重复。例如我同时在我新浪微博和腾讯微博转发了同样一条微博，只能计数一次。

当然，我们希望这些差异对用户透明，因为用户不需要了解这么多。用户只需要一个类似Google PR的数字直接了当地告诉他文章价值就可以了。

所以我们引入了SR(Social Rank)，范围0～10，标识在每篇文章的标题后面。一篇文章的SR能够精确表示它在其他各种社会化媒体的火热程度。

F.玩聚猫SR的计算公式

设置我们有N种数据源，分别是 {S1,S2,S3….Sn} ∈ S

如前文所述，数据源有4种类型，分别是{T1,T2,T3,T4}∈ T。

设类型权重 {WT1,WT2,WT3,WT4}∈W T

对于数据源Si ,

设数据源自身权重为SW(i), SW(i)由网站的Alexa排名、PV量、修正值决定。

T(i)表示它所属于的分类，WT(T(i) ) 表示Si的类型权重

在计算某篇文章的SR时，设A(i) 是该文章在Si数据源里的『分享行为』计数。

那么，

对于这篇文章而言，

SR = Logx ∑i=1..nA(i) ×WT(T(i) )× SW(i)

为什么是Logx 呢？有两点原因，一是它可以使得早期的投票获得更大的权重，比如，当x=10时，前 10 票获得的权重，与 11 到 101 票所获得的权重是一样的；二是使信息的层级呈金字塔型分布，就像Google PR、地震里氏等级一样。

Logx 中x的取值非常重要，玩聚猫的取法是这样的：从已知的m篇预料信息中计算最大的推荐价值

MaxV= Max( Vj= ∑i=1..nA(i) ×WT(T(i) )× SW(i) | j=1..m )

由于SR的范围是0至10，我们令 x^10 =MaxV

从而计算出 x = 10√MaxV

如果MaxV为35000，则X应该设定为2.847，SR = Log2.847 ∑i=1..nA(i) ×WT(T(i) )× SW(i)；推荐价值约200的文章SR为5，推荐价值约4500的文章SR为8，推荐价值大于35000的文章SR为10。

通过这样的公式，为每篇文章都计算出一个Rank值，用户就能直观又精确地了解到文章的价值了。

×注意：玩聚猫的SocialRank和《来，做一个社会化推荐引擎》里提到的排序依据SR Rank不同。玩聚猫的SR跟列表排序依据没关系，只跟内容本身的价值有关系；郑昀只跟排序有关系。

G.玩聚猫还有哪些需要改进的地方？

我们正在以下领域进行奋斗：
1.强化用户权重系统，尤其是引入模糊计算和估值，强调名人效应。
2.通过实验数据，不断改进排名算法。
3.引入智能语义、自然语言，使玩聚猫在面对文本信息时，能够以人类而非机械的方式进行思考、归类、关联、过滤、总结。
4.引入机器学习(如Prediction)，使玩聚猫能够记住每一个用户的口味，个性化地推荐文章。

如果你对社会化推荐感兴趣的话，不妨到玩聚猫看看（目前是测试版本，服务器在国外，可能不太稳定，请见谅）。我们热忱欢迎您的一切宝贵意见、建议和批评。

本文链接

11个IT人士必备的Chrome 插件

2010-09-28T16:21:00Z

Chrome 浏览器现在可谓如日中天，与 Firefox 共同蚕食着 IE 的市场，网页开发者们可能也会开始转向这一新兴的浏览器，来调校自己的网站。而随着 Chrome 插件作者们的介入，为网页开发者提供便利的插件也纷纷崭露头角。

1. Firebug Lite
Firebug 绝对是最受网页开发者喜爱的 Fifefox 插件（没有之一）。通过它可以在浏览器中查看并编辑任何网页的 HTML，CSS 以及 JavaScript，并在修改的同时地看到改动后的效果。Firebug Lite 是针对 Chrome 浏览器的一个精简版本，可以用来查找网页中的错误以便快速更正。
尽管 Firebug Lite 尚不能包括 Firebug 所有功能，但也已经秉承其精粹，且已经提供了针对高级用户控制台界面。

2. IE Tab
微软的 Internet Explorer 浏览器会让很多网页设计者头痛，但目前为止在大众范围内仍是被使用最多的浏览器。IE Tab 扩展实际上是在 Chrome 的一个标签页里用 IE 打开网页，通过它你可以查看网页在 IE 用户的眼里是否显示正常。

3. Eye Dropper
通过 EyeDropper，可以查看 Chrome 浏览的网页中任意颜色的信息。点击扩展的按钮，会打开一个下拉式的色轮界面，其中有一个取色器按钮（Pick color from webpage），点击它，再点击网页中任何位置，就可以查看所点击位置像素的颜色在色轮中的位置、RGB 水平以及 HTML 颜色代码。

4. Chrome SEO
安装好该插件后点击插件按钮就会显示当前网站与搜索引擎优化相关的信息，包括反向链接，Alexa排名、Google PageRank排名等流量值数，在社会化书签网站中的热门程度等。

5. Lorem Ipsum Generator
Lorem Ipsum Generator 扩展可以用来在设计网页时生成填充网页内容的文本，用以调适格式，免去手动输入此类文字浪费的时间。该插件十分小巧，在易于使用的同时也不会占用过多的内存，在需要时可以信手拈来。

6. Resolution Test
顾名思义，Resolution Test 就是通过调整浏览器的大小来查看网站在不同的常见分辨率下的情况。作为网页设计者一般都会配备高分辨率的显示器，但一般的网页访问者来说通常都不会这么奢侈，这个扩展的作用就是用来确保网站的格式在这部分人看来也是正常的。

7. Speed Tracer
Speed Tracer 通过浏览器内建的测量工具来记录网页应用在执行不同任务时所用的时间，以便于开发者找到致使网站运行缓慢的原因。该插件可以显示浏览器在解读执行布局、Javascript时所有的时间以及其它一些细节。
这个插件唯一的缺点在于，必须使用“–enable-extension-timeline-api”这个参数来启动 Chrome 浏览器才能让其正常运作。但既然是网站开发者，这点麻烦就是小菜一碟了，对吧？

8. MeasureIt!
MeasureIt! 名字就很直观。它可以显示出所浏览网页中任意元素的尺寸（像素宽度和高度）。和这个列表中很多插件一样，这个插件也有 Firefox 版本。

9. 1-Click Web Proxy

地址: https://chrome.google.com/extensions/detail/kjdehhkgdgjcekacdccoflccmhbkefce
这个插件应该是国人做的。因为她的中文名字是—— 一键翻墙！
她已经连续一个月排到Chrome Extension 官方Top Rated的第7名了～囧～看来还真是迎合国民的需求啊～
真相在这里：https://chrome.google.com/extensions/list/rating
做IT的经常去国外网站查资料，遇到打不开的网页，比如google groups 、blogspot等，只需要点击这个插件的按钮就可以了。速度还挺不错。

10. Pendule
Pendule 会弹出一个简单易用且设计精美的控制面板，其中包含了很多对于开发者来说很有帮助的任务选项。比如重新载入或是禁用 CSS，查看 JavaScript 代码，隐藏图片，取色器，测量尺，查看页面源代码，以及多种编码验证工具等。是一个很不错的功能基础且全面的开发者用扩展。

11. BuiltWith
BuiltWith 可以给出关于当前网页的一个资料信息，列出了网站中所使用的相关技术。它会显示网页中所使用的小挂件、网站管理员所用的网站流量分析追踪服务、网页所使用的框架以及广告平台等等。
本文链接

使用职责链模式简化工作流相似步骤间的逻辑

2010-04-14T12:45:00Z

在实际建立工作流模型时，往往会有很多相似步骤。相似步骤间的逻辑，往往又会包括大量的if..else..判断。

例如，我们先看一个简单的报销流程。它很可能会是这样的：

看似很简单的四个步骤。但客户会告诉我们：部门经理应该分为两个步骤，因为有些部门设立了“副经理”职位，有些部门甚至“经理”职位空缺，只设“副经理”。换言之，“经理”与“副经理”至少有一个。

于是我们将流程图改为以下情况：

我们发现，增加了一个步骤后，需要增加四条“流程路径”。例如，按照途中的说明，当流程以及流转到了“部门副经理”时，取得下一个步骤需要做一次“if…else…”。如果当前部门有“部门经理”，则下一步流转到“部门经理”步骤；如果当前部门没有“部门经理”，则直接流转到“会计”步骤。

这似乎能够满足客户的要求。但客户的组织机构往往非常复杂，他很可能在某一个时刻又告诉我们：我们共有两级部门，一共四个经理职位，均需要按照上述方式进行流转。

这是非常清晰明了的一个需求。于是我们又继续修改流程模型为：

此时我们就陷入了困境。这新增的两个步骤，带来了更多的逻辑关系，且每个逻辑关系都更为复杂。

例如，假如当前流程以及流转到了“二级部门副经理”处，工作流平台取得下一步骤需要做的判断至少有：

如果该部门有“二级部门经理”,则流转到“二级部门经理”；
如果该部门没有“二级部门经理”，但有“一级部门副经理”，则流转到“一级部门副经理”；
如果该部门没有“二级部门经理”，也没有“一级部门副经理”，但有“一级部门经理”，则流转到“一级部门经理”
如果该部门没有“二级部门经理”，也没有“一级部门副经理”，也没有“一级部门经理”，则流转到“会计”步骤

可以看到，仅仅“二级部门副经理”这一个步骤的“选择下一步骤”逻辑，就包含了4个“if…else…”判断，这是非常丑陋的。开发组往往兵强马壮，此种情况也可以通过大量的人工来保证。不过，可以预计的是，客户的多种流程（如报销、列账、冲销、预付等），都有类似的部门经理逻辑。大量的重复工作，无法保证不出错。

更为恐怖的是，假如客户有一天，变成了三个层级的部门组织架构了呢? 从“三级部门副经理”开始，一直往上，到“会计”步骤，那是不是仍然采用这样简单粗暴的方式？再按照这种方式来做的话，也许我们就直接崩溃了。

怎么办呢？

其实，在GoF的23个设计模式中，就已经提到了一个经典的解决方案：职责链模式。

职责链（Chain of Responsibility）模式
责任链模式是一种对象的行为模式【GOF95】。在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任。

职责链模式的UML图：

这个UML图非常有意思。我们可以注意到，Handler角色自己聚合成自己。这有点类似于《数据结构》里描述的“链式结构”。

抽象处理者(Handler)角色：定义出一个处理请求的接口。如果需要，接口可以定义出一个方法，以设定和返回对下家的引用。这个角色通常由一个抽象类或接口实现。

具体处理者(ConcreteHandler)角色：具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给下家。由于具体处理者持有对下家的引用，因此，如果需要，具体处理者可以访问下家。

我们将这个设计模式运用到刚才所提到的实际环境中。

这时，我们的“抽象处理者”(Handler)是一个能够返回下一步步骤名称的处理类。对于上面提到的“二级部门”的情况，我们将会有五个“具体处理者”(ConcreteHandler)：二级部门副经理、二级部门经理、一级部门副经理、一级部门经理、会计。他们属于两个类别：“经理类”与“会计类”。

“会计类”的处理无逻辑判断。即，当步骤选择器流入“会计类”时，直接返回“会计类”的步骤名。

“经理类”就复杂一些，需要判断当前部门各个层级经理的有无、各个层级经理的是否已经审批。这两种判断可以抽象为两个数组参数的比较。我们设定两个数组参数byte[] candidates与byte[] approvers。第一个数组表示，候选步骤的有与无；第二个数字表示，在数据库记录中，所有步骤的当前审批状态.

例如，假如一个部门有“二级部门副经理、二级部门经理、一级部门经理”，没有“一级部门副经理”，即所有职位从小到大排列，第三大的职位空缺，其余职位齐全——则byte[] candidates的值可以设为{1,1,0,1}。在流程刚刚开始时，所有步骤均未审批，byte[] approvers值为{0,0,0,0}；假如当前流程已经流转到“二级部门副经理”步骤，则byte[] approvers可以的值为{1,0,0,0}。

业务规则有了，参数有了，具体该如何处理呢？其实就是比较两个数组中相同index对应值的相等与否。

例如，假设当前 candidates为{1,1,0,1}，approvers为{1,0,0,0}。从数组索引0开始，依次往后，我们可以知道“需要”“二级部门副经理”审批，当前“二级部门副经理”已经审批；“需要”“二级部门经理”审批，当前“二级部门经理”还未审批。很明显，流程下一步应该流转到“二级部门经理”步骤。

以上的自然语言描述翻译为算法为：按照索引从小到大的顺序，依次比较candidates数组与approvers数组的元素值是否相等；如果相等，跳到下一个索引处继续比较；如果不等，则返回当前索引所对照的步骤名称。

按照我们设计好的“职责链模式”实现这个整体算法。即：每个“经理”处理者类，只判断属于自己索引的两数组元素，如果相等，则“处理”（返回步骤名）；如果不等，则移交下家进行后续判断。

首先构造处理者基类：

   //处理者基类
    abstract class Handler
    {
        protected int dutyId;//处理者对应的数据键值
        protected string stepName;//处理者对应步骤的名称
        protected Handler successor;//后继处理者

        public void SetSuccessor(Handler successor)
        {
            this.successor = successor;
        }

        //处理任务的抽象方法，必须在每个子类进行Override
        abstract public string HandleRequest(byte[] candidates, byte[] approvers);
    }

构造两个类型的处理者子类：经理子类，会计子类。

   /// <summary>
    /// 会计处理者
    /// </summary>
    class Accounting : Handler
    {
        //会计处理者需要赋予“流程步骤名”
        public Accounting(string _stepName)
        {
            stepName = _stepName;
        }

        //当职责链到达会计步骤时，直接进入会计步骤
        override public string HandleRequest(byte[] candidates, byte[] approvers)
        {
            return stepName;
        }
    }

    /// <summary>
    /// 经理处理者
    /// </summary>
    class Manager : Handler
    {
        //经理处理者需要赋予“流程步骤名”与对应的“数据键值”
        public Manager(int _dutyId, string _stepName)
        {
            dutyId = _dutyId;
            stepName = _stepName;
        }
        override public string HandleRequest(byte[] candidates, byte[] approvers)
        {

          //如果两个值不相等，说明这个步骤还未处理过。立即返回该步骤的名称。
            if (candidates[dutyId] != approvers[dutyId])
                return stepName;
            else
                if (successor != null)
                    return successor.HandleRequest(candidates, approvers);
                else
                    throw new ArgumentNullException("没有指定successor！");
        }
    }

客户端：

//客户端
    public class StepSelector
    {
        //假设初始情况是：有二级部门副经理、有二级部门经理、
        //无一级部门副经理、有一级部门经理
        byte[] candidates;

        //初始时，所有人均为审批
        byte[] approvers;

        //传入工作流平台的任务Id，初始化当前状态
        StepSelector(string taskId)
        {
            //◇到业务平台中取得所有的候选步骤
            candidates = GetCandidates(taskId);

            //例如，初始情况可能是这样的：有二级部门副经理、有二级部门经理、
            //无一级部门副经理、有一级部门经理。
            //则设置如下：
            //candidates = new byte[] { 1, 1, 0, 1 };

            //◇到流程平台中取得当前已经完成的步骤
            approvers = GetApprovers(taskId);

            //初始时，所有人均为审批
            //approvers = new byte[] { 0, 0, 0, 0 };

        }

        //客户端主要方法：传入整体数据、当前状态，取得下一步骤的名称
        public string GetNextStep(byte[] candidates, byte[] approvers)
        {
            Manager LevelTwoViceManager = new Manager(0, "二级部门副经理审批");
            Manager LevelTwoManager = new Manager(1, "二级部门经理审批");
            Manager LevelOneViceManager = new Manager(2, "二级部门经理审批");
            Manager LevelOneManager = new Manager(3, "二级部门经理审批");
            Accounting accounting = new Accounting("公司会计审核");

            LevelTwoViceManager.SetSuccessor(LevelTwoManager);
            LevelTwoManager.SetSuccessor(LevelOneViceManager);
            LevelOneViceManager.SetSuccessor(LevelOneManager);
            LevelOneManager.SetSuccessor(accounting);

            //从最低值为“二级部门副经理”开始处理请求
            return LevelTwoViceManager.HandleRequest(candidates, approvers);
        }
    }

请注意“客户端”的代码，它完完全全地示例了职责链模式的调用方法。总体分为三步：1. 实例化处理者。2. 设置后继关系 3.从最前端的处理者开始处理。

值得一提的是，这样的结构是符合“开放封闭原则”的（对修改封闭，对扩展开放）。也就是说，无论是需要两个部门经理来审批，还是四个部门经理来审批，甚至扩展到六个部门经理审批，都是不需要修改已有的业务逻辑代码，只需要在客户端中增加更多的处理者类实例、增加每个类的后继处理者、设置参数，就可以了。

本文链接

玩转双核CPU：左手画圆，右手画方

2010-03-23T16:50:00Z

两年前，微软亚洲研究院出版了《编程之美》一书,其中的第一章第一节“让CPU占用率曲线听你指挥”一文，可谓是在全国范围内掀起了一股玩转CPU占用率曲线热。我本人甚至在坐公交的时候都在思考如何折腾CPU占用率曲线。

书中给出了这样一张让人耳目一新的图，吸引了万千IT少年：

也许您会觉得这还不够好玩。我也是。对了，今天流牛木马打算与各位看官讨论的，是以下这幅图的效果——双核的CPU，左手画圆，右手画方！

该书出版的时候，我正在微软亚洲研究院创新工程组实习，该书的好几位作者都是我的好朋友，如李东、陈远等 ——于是我可以负责任地告诉大家，该书的所有实习生作者，当时他们使用的都是Intel P4 3.4Ghz单核CPU ！ o(∩_∩)o

今天突然想到了这里，就打算拿我的Thinkpad T60来试试。CPU是Genuine Intel(R) CPU T2400 @1.83Ghz ，双核。

首先我将书中提供的C++代码翻译成了C# .翻译过程没任何技术难度，仅供各位看官了解个大概：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            const double SPLIT = 0.01;
            const int COUNT = 200;
            const double PI = 3.14159265;
            const int INTERVAL = 100;
            double[] busySpan = new double[COUNT];  //array of busy times
            double[] idleSpan = new double[COUNT];  //array of idle times
            int half = INTERVAL / 2;
            double radian = 0.0;
            for (int i = 0; i < COUNT; i++)
            {
                busySpan[i] = (double)(half + (Math.Sin(PI * radian) * half));
                idleSpan[i] = INTERVAL - busySpan[i];
                radian += SPLIT;
            }
            double startTime = 0;
            int j = 0;
            while (true)
            {
                j = j % COUNT;
                startTime = Environment.TickCount;
                while ((Environment.TickCount - startTime) <= busySpan[j]) ;
                System.Threading.Thread.Sleep((int)idleSpan[j]);
                j++;
            }
        }
    }
}

将这段代码直接F5，运行结果如下：

果然，与大家意料的一样，两个CPU中都会显示出非常扭曲、不规则的正弦曲线。

按照书中的说法，C++程序可以使用WinAPI里的SetThreadAffinityMast()函数，将程序固定到某个特定的CPU上执行。

查了下MSDN，当然，在.NET里，也有Manage的相似代码。见http://msdn.microsoft.com/zh-tw/library/system.diagnostics.process.processoraffinity(VS.80).aspx

按照MSDN，在代码中加入了简单的两句：

     System.Diagnostics.Process p = System.Diagnostics.Process.GetCurrentProcess();             
          p.ProcessorAffinity = (IntPtr)0x0001;

然后再次F5, CPU中的曲线如下图所示：

1号CPU成规则的正弦曲线相当完美，2号CPU使用率一直为0.

看来这就是书中想让大家达到的效果了。

这个效果让人感觉非常枯燥乏味。2号CPU的资源就浪费掉了，有没有办法将它利用起来呢？

让我们来分析这两句代码：

while ((Environment.TickCount - startTime) <= busySpan[j]) ;

System.Threading.Thread.Sleep((int)idleSpan[j]);

它的意思是，在规定好的时间间隔内（程序中规定了是100毫秒），满负载运行（通过空循环）构成正弦函数需要运行的时间（由之前的计算得到），其余时间就睡觉。如运行69毫秒，睡觉31毫秒，那么在这100毫秒的时间段，CPU的平均占用率就是69%。由于CPU占用率曲线是1秒钟更新一次的，程序使用的每100毫秒一个平均值节点，曲线的平滑度足够了。

继续发散。刚才的例子，如果是运行69毫秒，睡觉50毫秒呢？那么当前的100毫秒CPU占用率仍然会是69%，但如果算法不加调整，仍然以100毫秒为一个平均值节点，这就影响到了下一个100毫秒的CPU占用率。前一个影响后一个，如多米诺骨牌一样，整体的曲线就完全错误了。

也就是说，我们用来控制CPU平均占用率的时间段，每段必须相等。

我们考虑到以上的代码中，在1号CPU中运行了69毫秒，剩下了31毫秒如果转到2号CPU中运行，1号CPU的占用就会降到0，但与此同时我们就可以在2号CPU中“画方”了。

概括起来说就是，当1号CPU小寐的时候，程序在2号CPU中“画方”；1号CPU小寐结束的时候，2号CPU中当前周期的“方”必须完成。

需要注意的是，假如1好CPU画了69毫秒，那么2号CPU一定只能画31毫秒。

按照这个思路，我们先实验一下简单的：在1号CPU中画正弦曲线后的休息时间段，我们在2号CPU中画余弦曲线。呵呵，初中学的三角函数你忘了吗？

我们将原代码中的空循环改为：

            while (true)
            {
                j = j % COUNT;
                p.ProcessorAffinity = (IntPtr)0x0001;
                startTime = Environment.TickCount;
                while ((Environment.TickCount - startTime) <= busySpan[j]) ;
                p.ProcessorAffinity = (IntPtr)0x0002;
                while ((Environment.TickCount - startTime) <= idleSpan[j]) ;
                j++;
            }

“左手正弦，右手余弦”结果差强人意：

我们注意到这个曲线没有之前单CPU运行时那么精确的。

原因是我们切换CPU的运营占用了时间。例如，以前正弦画了69毫秒，我们计算出余弦应该画31毫秒，但切换CPU的操作可能占用了3毫秒（或更多、或每次耗时都不同），整体就不在100毫秒这个间隔范围了，所以曲线结果有误差。

到这里，我的思路已经说完了，相信大家已经明白。

不过，走到这一步，追求完美的我们，的确是遇到了一点障碍。

我经过一些周期上的微调，并且将余弦函数改为了简单的方波函数，最终效果正如本文开头展示的一样，还是不错的。

调整办法？呵呵，真不好意思，我暂时还没有想到一个足够说服大家、可以公式化的调整办法，就请各位看官在这里八仙过海，各显神通咯～

本文链接

博客园_Memento..

程序猿的逆袭-Dota玩什么英雄最容易拿MVP？

来，再做一个社会化推荐引擎

11个IT人士必备的Chrome 插件

4. Chrome SEO安装好该插件后点击插件按钮就会显示当前网站与搜索引擎优化相关的信息，包括反向链接，Alexa排名、Google PageRank排名等流量值数，在社会化书签网站中的热门程度等。

8. MeasureIt!MeasureIt! 名字就很直观。它可以显示出所浏览网页中任意元素的尺寸（像素宽度和高度）。和这个列表中很多插件一样，这个插件也有 Firefox 版本。

11. BuiltWithBuiltWith 可以给出关于当前网页的一个资料信息，列出了网站中所使用的相关技术。它会显示网页中所使用的小挂件、网站管理员所用的网站流量分析追踪服务、网页所使用的框架以及广告平台等等。本文链接

使用职责链模式简化工作流相似步骤间的逻辑

玩转双核CPU：左手画圆，右手画方

4. Chrome SEO
安装好该插件后点击插件按钮就会显示当前网站与搜索引擎优化相关的信息，包括反向链接，Alexa排名、Google PageRank排名等流量值数，在社会化书签网站中的热门程度等。

8. MeasureIt!
MeasureIt! 名字就很直观。它可以显示出所浏览网页中任意元素的尺寸（像素宽度和高度）。和这个列表中很多插件一样，这个插件也有 Firefox 版本。

11. BuiltWith
BuiltWith 可以给出关于当前网页的一个资料信息，列出了网站中所使用的相关技术。它会显示网页中所使用的小挂件、网站管理员所用的网站流量分析追踪服务、网页所使用的框架以及广告平台等等。
本文链接