June 2009 Archives

我在Twitter上的这个试验性的：每日推荐一位推友计划，已经来到了第二季。在 5月35 日那几天短暂被封之后，Twitter 用户依旧活跃。短短的消息即可迅速传递我们的情绪，表达我们的愤怒。这是这个时代最好的工具。

再次说一下推荐的几条理由：

• Twitter 背后的那个人在某个领域要有一定影响力或者有趣或是 Twitter 内容比较有价值。
• 订阅人数(followers)不超过 500 个才可能会加入推荐候选列表。如果订阅者少于100，基本发现很难形成良性互动，有的新用户就会意兴阑珊--毕竟自言自语不是很有意思的事情。而一旦超过200，就基本到了一个比较良性的循环了。对于超过500的,基本上不用推荐也会自然增长，边界效益不高。
• 非商业行为。同时避免侵犯隐私，每个人的介绍以网络可以搜索到的为准。
• 在每个工作日进行推荐，一般在下午 15:00 左右，这个时间也是公司下午茶时间，基本不影响工作。

如果要跟踪这个推荐计划，请 follow 我(@Fenng )，另请参考之前的第一季。介绍语基本上都是我拟就的，如果有不合适之处，那肯定是我没说好。如果你看到某个 Twitter 用户比较有趣，可以给我留言( @Fenng) 告诉我。

• @mujiang
  朱一, 曾是Abebook.com架构师，现 Amazon的 Database Architect，海外华人，不明白为啥总自称木匠:) 另：他友情帮我们做了TOP第四章初稿。
• @fengchunpei
  冯春培, 常年活动于ITPUB,id: biti_rainy，发帖数万... Oracle ACE，现任阿里巴巴 B2B 研究员。在国内数据库界人称大师。
• @yeka52
  周筠, 博文视点出版社(武汉)负责人，IT图书出版界奇才，众多重量级IT技术图书出自她的策划。 对所有教育及出版，以及设计相关的事情都感兴趣。
• @hdcola
  黄冬, 为国内 FreeBSD 社区默默贡献不小。曾负责过新浪研发中心的多个部门和产品，后离职创业，现在供职无限讯奇，为中国移动12580核心合作伙伴。
• @delphij
  Xin LI, FreeBSD commiter...新浪北美的，操作系统界领域的大牛
• @freebat
  王慧文, 校内网的Cofounder。现为 冒泡网 的站长。maopao.com 是一个类似 Twitter/FriendFeed 的网站，据说要做自己的特色。
• @eygle
  盖国强, 知名数据库专家, 是数本Oracle技术图书的作者。恩墨科技创建人(八卦一下，恩墨是他儿子的名字) 他的个人站点：http://www.eygle.com/ 。
• @lastmailbox
  邹欣, 微软亚洲研究院资深人士。搜索一下，你就知道！ 《移山之道》、《编程之美》(合作) 作者。 他的Blog耐看。
• @funy
  付宁, SNS第三方应用开发者与实践者，他捣鼓的 SNS 应用曾日收入$2000。Web2.0 创业人。
• @wulujia
  吴鲁加, 资深网络安全技术牛人。大成天下创建者，总经理。他的Blog：http://wulujia.com/ 。
• @milkr
  稻草, 设计师，Blogger，虾米网设计总监。 UCDChina 杭州联系人，他的Blog：http://www.v4uu.com/blog/ 。
• @chedong
  车东, 著名Blogger, 资深互联网人，前雅虎高级技术经理，前BlogBus CTO，现已加盟搜狐，任职产品总监。
• @yanhui
  阎辉, CSDN 产品总监（对CSDN有意见可以找他)。《程序员》杂志创刊就做，五年，后任CSDN执行总编。现在在做高端技术管理者社区CTO俱乐部，以及正在研究和实践基于社区的新型商务产品模型。
• @chndonny
  陈栋，来自阿里 B2B DBA 团队，技术杠杠嘀, 爱好摄影。想当年兄弟我刚到杭州的时候就借住在他的房子。
• @Crossday
  戴志康, Discuz! 创建人。80 后科技精英代表人物之一(其它几个不知道都跑哪里去了)。
• @hutuworm
  冯亮, 阿里最有趣的技术Geek之一。沉浸于 Linux 系统管理十余年，以此为业逾五载。现为运维架构师。业余偶猎文史哲社政法诸学。《Linux Network Cookbook 中文版》译者。
• @gaochunhui
  高春辉, 老网民应该都知道他，当年中国个人站长第一人。手机之家（imobile.com.cn)创建人，ECSHOP创建人... 我眼中的老高：仍然对技术有着极高热情的家伙。
• @Kimihuang
  黄航飞, 老阿里人，我们并肩为支付宝战斗过。电子产品爱好者，F1粉丝。现在在阿里妈妈(淘宝)做产品运营。擅长给支付宝找茬。他的Blog是我见过用Mac用户装修最差的一个，他的女儿比他可爱，哈
• @syutlyc
  杨帆, cnBeta.com 副站长(有IT新闻给他爆料吧)。IT Pro, 企业解决方案咨询顾问，曾在微软总部IT部门和微软中国的顾问咨询部门工作了4年。擅长微软企业服务器产品。喜好古典音乐。
• @zhuzhijun
  祝志军，互联网资深人士。TechWeb.com.cn 创建人。老祝的Blog 最近很有料：http://zhijun.techweb.com.cn/ 。
• @zhangjb
  张翼轸，潮人。我喜欢看他的Blog： http://blog.earlzhang.com/ "用理性的视角去探讨护肤品、时尚、男装、奢侈品、爱情这些风花雪月" 。
• @xdanger
  戴云杰，VeryCD 的联合创建人、CTO（有谁没有用过电驴麽?) 。技术高手，Geek。也是 Google 和苹果的粉丝。
• @arthur369
  西乔，Magicome公司创建人，提供 Web 技术开发项目外包开发及产品端顾问咨询。这位同学在2009年六月四日结婚，新郎是 @virushuo 同学 。
• @aimingoo
  周爱民, 刚加盟支付宝的牛人。国内软件开发界资深软件工程师。《Delphi源代码分析》、《大道至简》、《JAVASCRIPT语言精髓与编程实践》等图书作者。
• @Peoplecbc
  人物·志，中文网志年会人际交流平台-http://people.cnbloggercon.org/ 。
• @jinghuaz
  晶华, 前谷歌中国，现在在美国 Mozilla Labs。关于用户体验与开源软件。
• @csdncto
  蒋涛, CSDN 掌门人。《程序员》杂志总编。IT人，太极拳、围棋重度爱好者。
• @horse
  詹膑, 高校教师, 独立顾问, Blogger, 奇遇花园咖啡馆老板。典型的跨界人。
• @jeffz_cn
  赵劼, 网名老赵，洋名Jeffrey Zhao。目前担任上海柏盛网络技术有限公司架构师。InfoQ 中文站编辑。
• @zhidong
  王志东, 软件英雄。中文之星、四通利方和新浪创始人。点击科技创始人，Lava-Lava ，正在体验 Twitter 中。
• @gigix
  熊节, 笔名透明，知名 IT 技术专家，现为 Thought Works 咨询师。多本重量级图书的译者，最近的译作是《卓有成效的程序员》。
• @zhuangbiaowei
  庄表伟, 年轻的老技术人。印客网(http://www.inker.com.cn/) 技术总监。
• @anson_ho
  何烨, Geek. 独立策划人. 涉猎：网络、电台、公关、品牌、汽车。他的Blog：http://www.anson-ho.com 。
• @ShooterPlayer
  沈晟, 射手网（http://shooter.cn/）站长，射手播放器（http://splayer.org/）主要开发者。
• @jinhuang
  黄劲, 走秀网创始人之一。走秀网(http://www.zoshow.com/) 是一家定位于时尚电子商务领域的新锐网站。
• @liuyan
  今日推荐推友:刘岩, 六间房(6.cn)的创建人。刘岩参与过新浪网和亚信公司的融资和上市，并领导完成了亚信公司对杭州德康公司的收购。现任六间房CEO。

现在是广告时间：

• @BetaCafe
  贝塔咖啡馆...支持Twitter订咖啡，定期发放Twitter 优惠券
• @JobsDigg
  帮找工作 ...我的实验性项目
• @Alipay
  来自支付宝的半官方小道消息

最后，或许你应该关注一下这个" 热门锐推用户"榜

--EOF--

越来越觉得 The Matrix 真是一部伟大的电影，直接预言了中国互联网的发展趋势。最近接而连三的网络屏蔽事件已经快让人喘不过气来。我相信有一天那群人会在你的身体内植入电子芯片，控制你的的身体与思想，"帮助"你在和谐中得到永生。

"你有狼牙棒，我有天灵盖"，即使是网络顺民，最终也会在这样的层层阉割与过滤下激起反抗。总会有人冲破层层封锁，到达锡安(Zion) ，在 Matrix 中被解放的人都将在那儿。在锡安，没有"连接被重置"，没有"此信息禁止评论"，没有"据当地法律法规和政策，部分搜索结果未予显示"...

在这个信息时代，键盘就是武器，只要敢于说不，1984 就不会持续多久，无处不在"关心"我们的老大哥也将最终瓦解。而那些与强权分食腐肉的鬣狗们，也将得到唾弃与审判。

--EOF--

关于支付宝的证书使用中出现的 800A138F 错误是个老问题了。这里尝试对这个问题做说说个人看法。

历史原因说来话长，我尽量说得简要一些。首先需要涉及证书（Certificate ）在操作系统中通过 ActiveX 形式的登记（Enrollment ）这事儿。在 Windows XP 之前，延续使用的是 XEnroll.dll 这个库接口。但是因为这东西比较古老，且出于"更安全"、更方便开发的角度上考虑，从 Windows Vista 与 Windows Server 2008 开始引入 CertEnroll.dll （参考)。这个差异也导致了支付宝证书在不同版本的操作系统间的导出再导入可能会出现问题。

一般来说，错误信息类似如下：

错误原因：'cenroll' 为空或不是对象，错误代码：800A138F。
Microsoft XEnroll，在产生密钥对时失败！错误原因：'null'为空或不是对象，错误编码：800A138F

(这个错误信息表明是使用 XEnroll.dll 过程中出现了问题。)

不知出于什么考虑，微软上 Vista 的时候居然没考虑到 XEnroll.dll 这东西没了，向后兼容性如何处理呢? 而有些第三方开发厂商也不是未卜先知。所以，Vista 大量涌入市场的时候就暴露出来了问题(当然第三方开发商也要狠狠的打自己自己一个嘴巴)。微软的拿手解决方案就是发行一个补丁 ，在 Vista 和 Windows Server 2008 上也能使用老的 "Certificate Services Web enrollment pages" （其实就是给 操作系统里安装一个 XEnroll.dll 库)。参见知识库 922706 。

这个 800A138F 错误大多数时候出现在 Vista 系统上。也是有很多其他客观因素的，其中比较主要的一个是 User Account Control(UAC)这个特性带来的麻烦。UAC 默认级别替用户"多考虑许多"，安全级别控制的很好，好到这个安全成了麻烦。这个如果通过系统管理员用户一项一项的去设置的话，是可以对付安装上的，但是不可避免的是，很多用户不是操作系统专家，甚至不知道什么是"系统管理员"，所以如果把 UAC 关闭的话，可能会直接省了不少麻烦，但是这样的话，又有很多用户会觉得安全性受到了威胁，也难免抓狂，这个选择很是两难。

除了 Vista ，在 XP 上也会遇到这个错误。一般来说，某些第三方的小工具会禁止 Microsoft Certificate Enrollment CAB (这也是非常头疼的一个问题)，这种情况下可以考虑修改注册表或者是在这类工具的插件管理的地方把这个 CAB 放开。或者考虑修改注册表的方式 (参考)。

我的个人建议是：不要使用 Windows Vista ！(请默念10遍：Windows Vista 是个烂系统) 这是个微软内部都承认失败的操作系统。使用老的 Windows XP 吧，毕竟，微软已经承诺对 XP 延续支持到 2011 年了。至于 Windows 7 ，尽管叫好声不断，但我们现在只能期待。

另外，对于 IE 用户，建议使用 IE7 或者 IE8 (IE6 出来已经有 10 年，老掉牙矣，且从安全性的角度上考虑也的确不佳)。

以上是对支付宝证书错误 800A138F 的一点非专业解释，兄弟我并非 Windows 操作系统专家，期待对 Windows 操作系统更为熟悉的朋友进行补充以及纠正。现在情况已经如此，一刀切解决问题似乎不太现实，没有理由推卸任何责任(尽管个别读者可能这么认为)，只能尽量、尽快改进--现在已经在和合作方一起进行对此错误的处理！

用户的痛苦我也是感同身受！这并非客套话。

--EOF--

注意：这篇文章有实效性，且包括作者本人主观看法。

更新：从用户的反馈来看，Windows 7 比 Vista 易用性和性能好了很多，推荐使用。

淘宝开放平台( Taobao Open Platform, TOP ) ，面向第三方的开放式电子商务服务基础服务框架，重装上阵。前一段时间提前接触了一点这个项目，真是个非常有想象空间的事情。

可以肯定的是，这是"大淘宝"战略的一个重要环节。从最初的 Taobao.com 一个站点，现在是一个平台，将来再到一个更大的商业生态系统。

(上图出处)

去年下半年淘宝有过一次尝试("淘园"项目)，与上次的初步尝试截然不同的是，这次已经不再通过阿里软件这一层进行接入，从开发者使用角度上看，减少了交互环节,更加直接方便。此外，可供使用的应用程序接口愈加丰富，更贴近用户使用习惯。随着开发者社区的成熟和开发者规模的扩大，淘宝提供平台化的支持也是可以想见的事情。

对于所有的开放平台开发者来说，最关心的问题莫过于盈利模式。现在 TOP 关于盈利模式主要有两种形式：一是淘宝客佣金模式，再一个是淘宝插件分成模式。还是比较清晰的。就我个人而言，更倾向于前者的模式。也期待淘宝运营人员能够根据实际情况制定更加有利于开发者的策略，积极促进与开发者之间的互动。胜，在于人。

与其在一些 SNS 网站捣鼓那些游戏插件，还不如来开发电子商务第三方应用呢。你说呢?

以上仅为个人看法。所用信息均为公开资料。请勿跨公司抓捕 :) 

--EOF--

拜读了关于 LinkedIn 几位工程师写的构建 TB 级的 key-value 系统的经验：Building a terabyte-scale data cycle at LinkedIn with Hadoop and Project Voldemort。具体实现过程有大致的描述，就不鹦鹉学舌了。

其实现在很多公司可能都面临着这个抽象架构图中的类似问题。以 Hadoop 作为后端的计算集群，计算得出来的数据如果要反向推到前面去，用什么方式存储更为恰当? 再放到 DB 里面的话，构建索引是麻烦事；放到 Memcached 之类的 Key-Value 分布式系统中，毕竟只是在内存里，数据又容易丢。Voldemort 算是一个不错的改良方案。

值得借鉴的几点:

• 键(Key)结构的设计，有点技巧；
• 架构师熟知硬件结构是有用的。越大的系统越是如此。
• 用好并行。Amdahl 定律以后出现的场合会更多。

关于 key-value 应用的解决方案又多了一种。LinkedIn 对此应用案例也还在发展中。如果业务类型类似，不妨关注一下。

--EOF--

技术团队小的时候，似乎只有人手不够才是最大的问题。而随着队伍壮大之后，管理者会最终发现除了徒增更多的沟通交流成本之外似乎并没有带来额外的生产力。

一个庞大的技术团队就好比那艘叫做 瓦沙 (refer 2) 的大船，看似将来可以横行海上，其实自身恰恰最为危险。

大野心

这是大技术团队中最容易发生的一个问题。兵强马壮，高手云集，那就造一艘大船！逐一制定看似切合实际而实际超出团队能力的目标，要做就做大的，颠覆性的、革命性的、划时代的....项目，而对小项目根本不屑于一顾。历史给我们的经验教训是，凡是过于庞大的东西迟早要毁灭。

对于大项目，我最喜欢讲的一个故事是"大山临盆"：

大山临盆，天为之崩，地为之裂，日月星辰，为之无光，
房屋倒塌，烟尘滚滚，天下生灵，死伤无数
--最后生下一只耗子

大一统

团队一大，管理者喜欢制定一些条条框框的东西，"规范化"是一把双刃剑，这事情本身没错，但不可采取"拿来主义"照搬别人的做法，也别听一些厂家的蛊惑而购买"停不下来的红舞鞋"。切记不可抹杀团队成员个性，不要降低团队成员生产力，不能以浪费团队成员激情为代价。不然的话，大团队也必然暮气沉沉。团队成员能动性发挥不出来，再加多少人力也于事无补，只能陷入焦油坑，越挣扎越难摆脱困境。

乱想录@BetaCafe

--EOF--

上半年好像我写了不少推荐序。《Apache源代码全景分析第1卷》已经面市一段时间了。读过这本书的电子稿，先睹为快之后写下推荐序。

如果说没有 Apache 就没有 Internet 可能有些夸张，但至少可以说没有 Apache ，互联网不会发展这么快。根据互联网研究公司 NetCraft 的统计，多年来 Apache 一直是稳居 Web 服务器市场头把交椅，至今仍占据超过 50% 的市场份额。就整个互联网来说，Apache 仍然是最重要的软件之一。

尽管近几年来涌现出不少以"高性能"为卖点的新的 Web 服务器软件，比如 Lighttpd 、Nginx 等，吸引了不少用户注意力，不过 Apache 因其功能广泛，有些仍具有不可替代性，在技术领域仍然是 Web 服务器风向标。话说回来，"重剑无锋，大巧不工"，有的时候软件性能表现不佳，更多原因可能是对其了解不够、使用不当造成，并非软件自身有多大缺陷。 对 Apache 来说，更是如此。所以，通过分析源代码了解 Apache 软件架构体系，熟知其本质，方能更有效的使用 Apache Web 服务器，从而发挥出最大效能。为网站节省资源，为企业节省资金，也能为用户提供更好的访问体验，好处多多。

此外，随着互联网业务的复杂化，很多网站使用 Apache 的过程中也遇到了新的挑战，常常要在业务的驱动下对 Apache 进行扩展性的开发(例如扩展日志模块以便于更复杂的日志统计)。这个时候，源代码分析是绕不过去的一件事儿，尽管源代码获取是轻而易举之事，但 Apache 代码毕竟凝聚了开源软件界的群体智慧，要想高效分析却是并非易事，相信这本书能让有此需求的读者少走弯路，剥丝抽茧，获得更多启发与借鉴。

说起源代码分析，其实几年前市面上出现过一些此类话题的图书，不过基本上是印上大段源代码加上几句注释了事，读者可能会有吃到注水猪肉的感觉。而本书的读者对这一点大可放心，书中代码只是点到即止，相对环保多了。

后记：此书编辑够用心的，这里这个案例可见一斑。

--EOF--

阿里巴巴 DBA 团队 简朝阳的大作《MySQL性能调优与架构设计》已经开始正式上市。我刚认识朝阳同学的时候，他还刚刚毕业，短短两三年后，已经能够独当一面，应该说阿里 DBA 团队是个很锻炼人的地方，当然重要的是他的刻苦钻研的劲头儿。早早就看过他的初稿，这本书是他倾力之作，有理由大力推荐。下文是我前一段时间写的推荐序。

拥抱MySQL数据库技术

时至今日，恐怕已经没有人再把 MySQL 当成一个玩具性质的软件产品，即使是数据库市场执牛耳者如Oracle公司也不得不正式面对来自MySQL的冲击。如果说几年前，还有人对使用MySQL 有所疑虑么? 经过几年来互联网的高速发展，无数大型网站用其成功案例证明，以MySQL为基础的数据层解决方案已经成为互联网应用不可或缺的一个重要组成部分。

当下也是数据库技术应用处于激烈变革的时期。这并不是说传统的关系数据库技术在这两年有了多大的新突破，而是用户的需求在迅速变化。更多时候，用户不再需要单一的软件产品，而是灵活、高效、可靠、可控、低廉的解决方案。很多大型站点甚至根据自己的需求来改进 MySQL，进而回馈给开源社区，这也是开放的魅力所在，对于传统的商业数据库软件商来说，这是不可想象的事情。

MySQL早已不再是单一的数据库软件，以其为基础发展起来的各种开源组件令人目不暇接，而用这些组件构成的解决方案也是层出不穷。如何能够把以 MySQL为核心的这一系列软件充分运用，构建大型可扩展性网站，正是不少LAMP架构体系的网站开发者乃至架构师一直关心的问题。现在中文图书市场上 MySQL相关的书籍并不在少数，但放眼看去，绝大多数是教程类的内容，这本《MySQL性能调优与架构设计》则主要着眼于性能与架构这两个当下大家更为关注的话题，结合作者几年来的实战经验与研究心得，相信能让不少网站少走弯路。

期待这本书让更多人受益。如果读者朋友们也能把自己的心得分享出来，那是再好不过的事情了。经常有即将毕业的学生以及网络上的朋友给我发来邮件，表示对数据库技术有兴趣，但是不知道如何切入，我的建议是，从学习MySQL开始吧！

--EOF--

昨天的"电子商务和产品设计沙龙，暨 BetaCafe开业酒会"非常顺利，非常成功，发自内心的感谢各位朋友的支持! 很欣慰，这半年的又一件事情做完了。

这半年来，做了几件吃力不讨好的事情。不过想想郭靖给我讲的一句话，"你觉得这事情有价值没有? 有的话就去做!" 让我感悟颇深，也坚定了许多。一件事情是否有价值，不能只看别人的评价。

这些天几件事情并发的进行，感觉非常累，无论是工作还是个人生活上的事情，单独一件都能把自己搞得特别疲惫。有的时候要做点决定不是那么容易的事情，总有一些出乎意料的事情发生。

接下来尝试恢复到以前的状态，开始写点东西。这段时间更新并不频繁，好几个朋友都提及过这个事情，"现在写的没有以前好"。但我有什么办法?

--EOF--

现在网络上已经可以看到很多公司的团队对外的 BLOG ，关于这个话题，在这里记录一下我的一些个人看法。当然贵团队如果已经开博或者即将开博的话，毋须照搬，这不是什么指导。

明确团队开博目的

首先必须确定要传递哪些信息给读者? 宣传公司团队文化? 技术宣传? 产品宣传? 还是兼而有之? 如果只是为了跟风，那就没必要的。实际上，我相信大部分团队 BLOG 不过是跟风而已，不过跟风跟的好，也能起到不错的作用。如果能认真经营 BLOG ，它就能给你带来价值，超乎你想象的价值。

一般而言，建议对外开博前，可以在内部先试运行一下，给大家熟悉网络环境一个缓冲期。

不与业绩指标挂钩

据说很多团队的 BLOG 居然和 KPI 挂钩的，这是非常不适合的做法。很明显这会导致一个现象：到了接近考核的时候，团队每个成员都流水帐一样连发多篇文章凑数，对读者来说，是一种信息轰炸，起不到什么正面作用，对团队多数成员来说，也觉得这样圆满完成任务也不错嘛，势必影响真正用心写文章的成员。当然我相信很多人看了我这个帖子后会改变 KPI 的设置方式，比如"每月要发布几篇"... 简言之，本末倒置。

控制文章发布频率

团队 BLOG 管理员(没错，应该有个管理员)应该控制文章正式发布的频率。细水长流，尤佳。记住，节奏最有力量。

控制频率的另外一点是要做好长期性准备，不要几天热乎劲儿过去之后就乏于更新。如果潜在读者偶尔访问过来，发现最近一篇更新是一年前，或许就会留下负面印象。

不要强制团队成员

必须要认清的一件事情是，一个团队中，肯定有些人员的确不善于文字表达，如果要他写一篇文章，可能比杀了他还更难受。如果强制性的压着他憋文章，恐怕只能适得其反。好的方式是发起者能够引导团队成员中的那些低调者，使他觉得这事情有意思，可以尝试一下，能够更多锻炼自己。比如针对技术人员来说，写文章过程中如果熟悉一下 HTML 基本语法，在日常工作中也不无裨益。

不要堆砌垃圾文章

这里面的一条铁律是：不要转贴那些网上随处可见的"心得"，"感悟"之类的心灵鸡汤文章，那些文章不能改变外界对你团队的正面看法(当然有可能增加负面看法)。适当的转载关于自己团队或者公司的第三方文章是可以接受的。

记住，垃圾信息和网站质量成反比的。信息不是越多越好。

内容格式非常重要

内容是团队向外展示的载体，固然重要，可如果文章不经过很好的格式化，就好比一块好田地长满了庄稼也同样长满野草一样让人讨厌。这是如此简单的一点，但我们还是能看到有许多团队对此熟视无睹。一篇连段落都不分的技术文章内容再好，也不会有更多技术人喜欢看。

不但 Web 页面要注重格式化，对 RSS 输出也同样也要注意，甚至应该更加以重视。至于输出全文，那是必须的。团队 BLOG 不要在乎什么 PV 之类的事情，那是非常土鳖的做法。内容是否有价值，不在于有多少人看了这篇文章，而是有多少目标读者从中得到收益。

--待续-