Shell's Home

U盘启动

Dec 15, 2008 - 1 minute read - Comments

hihi 大家看过血色星期一没有?那里面有个家伙用随身的U盘当系统带来带去,很酷哎。 贝壳也有个U盘系统盘,做过使用/分区隐藏/Linux启动/密码访问控制,但是基本用不上,首先一个原因就是――太慢。 KST的2GU盘读写速度是5/1.5,貌似用来启动个30多M的系统也够了,可是加上各种检测,时间就远远比硬盘长,而且长很多。所以贝壳正在寻思,什么时候弄个高速(起码要10M)U盘来当系统。分个2G给linux,足够他跑X了,连带编译器什么都可以加上去。 不过在这之前,首先要搞定系统启动问题。混蛋的grub在U盘启动的时候不稳定,一会把U盘当hd0,一会把硬盘当hd0。可以想象,系统启动的时候每次都要手工确认,这种东西鬼才高兴用。而且U盘系统有的时候开关机不稳定,半路死机ext3就损坏,又要拿debian来扫。ext3损坏本来没什么,可是hd识别又出现变化――变的像死机一样。TMD这种鬼环境,加上600M的空间,会用才有鬼了。 先解决这个问题,然后弄个8GU盘来装酷,就这么决定了。 另外,血色星期一的设定弄的很不错,系统是linux(估计是定制的),里面用的是python(就是听说用这个语言才去看的)。不过入侵的时候时间和动作都搞笑了点。真正的入侵往往耗时数天甚至数周,而hack高手也不是拿一堆脚本去淹死服务器的家伙。能够从别人认为完美的地方看出破绽才算入门,而能够从逻辑层面升华到理论的才算是大师。

杭州,火车,咖啡厅

Dec 12, 2008 - 1 minute read - Comments

贝壳,黄昏,杭州,城站火车站旁,上岛咖啡,红烧牛肉饭,充电,无线上网,博客,大家,好玩吗?

竞价排名和不作恶

Nov 23, 2008 - 1 minute read - Comments

前两个月贝壳才刚说到百度的竞价排名,果然,这回又出问题了,而且还出的很好笑。 央视曝光了百度竞价排名中的一些问题,主要是有很多医疗信息,百度并没有核实来源。此后,百度总裁李彦宏声称,法律没有要求百度对付费信息负责。从法律角度说,这是对的,我们今天说的主题也不是他,而是这个(http://www.cnbeta.com/articles/69964.htm)。 本来曝光百度,怎么转眼变成google了? 看来百度不应该叫搜索引擎公司,而应该叫公关公司。前两个月讲三鹿问题,他是公关。央视曝光医疗问题,他是公关。现在出这个,还在公关。不过你可以公你的关,不代表股东会买你的帐。详细情况大家可以看这里(http://realtime.zaobao.com /2008/11/081120_21.shtml)。 估计我这篇blog的百度排名应该会很低吧—— 下面贝壳废话一下,讲解一下竞价排名的问题,google的价值观和策略。 竞价排名在前两年是一个非常好的模式,通过竞价本身,我们就可以发现很多有价值的信息。例如,我们在搜索IBM的时候,肯花钱的蓝色巨人总比不肯花钱的国际大嘴(International Big Mouth)来的有价值吧。然而问题在于,由于搜索引擎价值的外在性很大,又没有监管,搞不好就要出问题。而且往往不是竞价排名供应商出问题,而是上游下游出,他们没法管。首先我们说外在性的问题,所谓外在性,是指由不应当承担后果的人承担后果的一种状况。好比我在XX地开了一个工厂,生产在欧洲要花很多环保费的东西,破坏了当地的环境。我获得了收入,但是后果由当地人来承担。不论出现的原因,由于外在性的存在,会破坏社会公平,因此很多国家都有补偿外在性的措施。例如排污税,针对富人的高所得税等。竞价排名的外在性在于,有人花钱买排名,并不总是发现价值的过程,也可能是减少价值的过程。而减少价值的损失并不总由百度承担,而是由百度的用户承担。更麻烦的是,这个过程是不可监管的。 我们举例详述整个过程。假定有人在百度竞价买了“流产”(这也是百度最贵的排名)这个关键词,那么,什么人会最乐意去购买呢?我们分析一下流产的潜在市场。正规医院的流产总要通过手续,未成年需要父母签字。很多有钱的小孩宁可多花钱也不希望父母知道,因此他们会选择一些非正规的医院。于是,这些市场一般都是非正规的医院把持的,因为正规医院的收费公开固定,流程有一定监管,肯定没法和这些非正规医院去竞标这个关键词。那么非正规医院中,我们可以想象,应当是付出最高价格的人能够获得这个关键词。如果你按照百度的去,那么你去的地方一定是市场上拥有最高的成本收益比的地方——因为只有这样他才能标到百度的关键词。问题是,什么样的医院会拥有最高的成本收益比?如果是监管医院,这个答案一般是私人贵族医院——如果中国有的话。如果是非监管,那肯定有问题。因为他不能贵族化,收入上不去,又要保证成本收益比,只有降低成本咯。而且医疗系统里面,降低成本普通人根本看不出来。不普通的人——不普通还需要自己找非监管医院么?同样,一些用户不希望被监管的医疗问题中,这个关键词应当也是非常贵的。例如生育,肾亏,等等。这个过程也是不可监管的,百度自己难道还逐个核查竞价排名的真实性?他又如何有权力做这个事情呢? 一家不在监管下的医疗机构,这个问题够严重了吧?但是百度有做什么非法的事情么?没有。从法律角度讲,任何人有权付费将某个信息在百度的排名变更。例如,我可以付费将布什是条狗的网页调整到最高——如果我对布什不爽的话。这个不触犯任何法律,除非你调整有悖法律的关键字。你不能说布什是条狗不是事实,因而不允许我调整排名。那么,百度调整这些有问题的医疗机构的网页,并不能说他触犯了任何一条的法律——从法理上讲是这样的。 通常来说,如果是普通机构,市场会自行调整。如果一个公司提供的信息是违背市场本意的,那么这个公司本身就会被市场淘汰。如果你天天提供广告给我们,我们应当一脚把你踢开。问题是,百度获得了足够的互联网资源,百度搜索是个太重要的东西了。因此他可以屏蔽对自己不利的消息。于是,即使百度有问题,大家也不会知道,直到上面的这幕出现。百度被另外一个媒体的老大——央视——点名,他屏蔽不掉了——总不能屏蔽央视吧?当然,他还是屏蔽了部分消息,并且留下了相当的尾巴。 google的核心哲学观点之一就是“不作恶”。简单来说,就是不因为外力——包括广告,赞助,等等——人工改变排名。google的排名一般有两种变更方法,一种是被发现作弊或者犯规,另一种是更改算法。用google的话来说,即使我们认为某个关键字结果是错误的,修正错误的方法不是我们调整这个页面的pagerank,而是使用更公正的算法,保证每个人在同一个起跑线上。这个和美国法律的精髓如出一辙。即使我认为这个判例是错的,我也不会行政干预这个判决。而是通过议会修正法案来修正法律,保证一个更公正的法律。 至于google的广告,不要误会,google也是卖广告的。google的广告都统一显示在页面的右边,和左边的搜索结果严格分离。大家可以很容易的识别出google的广告。如果你们对广告内容有兴趣,可以点击广告——这是google广告的本意。如果你们对广告内容没兴趣,不强迫你们。这个是“不作恶”的本意。

关于乙肝的一点常识

Nov 12, 2008 - 1 minute read - Comments

对于乙肝,贝壳自认为自己了解的已经够多了。至少贝壳知道两对半的意义,作用机理,还有一些乙肝的常识。不过在看了一篇文后,贝壳发现,还是不够多。具体内容可以看这里[1],中国内可能需要穿墙。 认识贝壳的都知道,贝壳是一个偏执于知识和真理的人。然而知识是否一定带来真理?是,也不是。知识未必带来真理,愚昧一定带来恐慌。上文中描述的乙肝患者歧视现象,贝壳并不怀疑。医院里面长长的体检队伍,电视上大量的乙肝药物广告,都是这一现象的残忍注脚。更不提贝壳从事的职业和传播学也有一定关系,自然知道资本和传播结合又没有管制的后果。那么今天,贝壳就着重提出几个乙肝的基础知识,看看大家是否了解。 乙肝是否会终身感染? 根据香港一个资料[2],幼年时感染后会终身感染,成年后感染基本会痊愈。 乙肝感染的方式和概率? 根据这个资料[3],体液交换会传染,包括献血,血液交换,性交和接吻。但是根据上面的文章[1],接吻传染的概率很低。 乙肝对正常人的传染? 根据资料[3]的说法,只要不发生血液污染,即使是夫妻这样亲密常接触的人,只要接种疫苗就可以防护。同时根据上一个问题,多数情况下你没感觉呢就痊愈了。作为80后的城市青年,贝壳记忆中从初中开始接种过三次乙肝疫苗,应当是终身免疫。 乙肝的后果和概率? 根据文档[1]的说法,也许运气不好的话(大三阳伴随谷丙/谷草异常)会肝功能受损(总体的20%),严重的引发肝硬化(受损的4%,总体的0.8%),少量的会形成肝癌(受损的0.4%,总体的0.08%)。按照当前中国全部乙肝患者全为大三阳肝功异常计算,会有96K人患上肝癌。如果考虑实际情况,大概会有1W人上下吧。 ——如果您觉得很多,查查死于心脏病和高血压的人数,再想想您今天的午餐。 乙肝歧视的后果? 计划生育的后果是多出来的男性可以组建一支军队,而乙肝歧视的后果就是患病,无工作的1.2亿人口。——想想这帮人急了拿个针头在你家楼下扎人。 参考: [1].http://item.feedsky.com/~feedsky/my1510/~5935684/129964642/1488578/1/item.html [2].http://www.hku.hk/uhs/he/hep/chi-hepc.html [3].http://www.hbver.com/Article/ygfz/ygzs/200511/4413.html

SCIP,lambda,Church

Nov 10, 2008 - 1 minute read - Comments

贝壳最近在看SCIP,感觉受益匪浅。其中有一个2.6,使用函数表达数字,很难理解。贝壳查了查资料,这篇(http://blogs.sun.com/yongsun/entry/lambda%E6%BC%94%E7%AE%97%E4%B8%8Echurch%E8%AE%A1%E6%95%B0 )写的很好,贝壳就不多说了。贝壳把自己写的内容贴上来,作为一个借鉴。 (define zero (lambda (f) (lambda (x) x))) (define one (lambda (f) (lambda (x) (f x)))) (define two (lambda (f) (lambda (x) (f (f x))))) (define three (lambda (f) (lambda (x) (f (f (f x)))))) (define (add-1 n) (lambda (f) (lambda (x) (f ((n f) x))))) (define (add m n) (lambda (f) (lambda (x) ((m f) ((n f) x))))) (define (mult m n) (lambda (f) (m (n f)))) (define

一些关于盗版、黑屏、开源的事情

Nov 3, 2008 - 1 minute read - Comments

大家都知道,微软搞黑屏了。贝壳暂时就这个事情不发表评论,而是先说一些其他的事情,然后大家再回过头来看这个事情怎么说。 首先是软件的版权区别。开源软件,自由软件,免费软件,共享软件,收费软件,盗版软件,这些我们经常说的名词究竟有什么意义,有什么相同和区别? 首先,大家要了解一个事情,上述对软件的不同称呼,其实是不可并列称呼的。免费收费,是指软件的付费方式,开源闭源,是指源码的公布方式,正版盗版,是指是否侵犯版权。这些其实是不同的事情,只是很多事情有前后的因果关系,因此大家容易混为一谈。一般我们可以将软件分为是否收费,是否开源,什么版权三种分类方式。分清其中的区别有益于阅读下面的内容。 开源软件是指源代码开放的软件系统。多数情况下,开源意味着免费和自由,但是也存在收费的例子。例如许多大型系统(好像有些UNIX就是,但现在具体什么情况,贝壳没有用过,也没有看过软件协议),其源码对使用者开放(注意,开源并不代表对所有人开放,只要使用者有权获得源码即可。当然,如果范围缩小到使用者中的特定群体有权,则不算开源,例如微软的不可泄露协议),但是属于绝对的收费系统。大家很容易理解这里面的原因,既然源码已经开放,那么多数人都可以轻易写出类似的系统,在这种情况下还要坚持收费就愚蠢了。除非源码庞大,需要相当的水准和时间来理解,这样才能保持收费。当然,更多的情况是开源免费,收取专家服务费。 这里中间还要插入一句法律问题(怎么感觉写成法律普及文了),目标软件的作用是给予使用,源码的作用是表达思想,这是公认一致的原则。换言之,如果你发布的是病毒目标,则是违法。如果你发布了病毒源码(当然,要排除恶意发布),则是研究之用,不属于违法。当年DeCSS的审判之所以被判定无罪,即是基于上述原则。 免费软件是指授权方式是不要钱的。现在免费软件的很大一个来源是来自开源社区,然而并非只有开源了才免费,共享软件和试用软件就是其中的两个典型。共享软件的作者允许你可以免费的使用它的软件,但是并不开源。试用软件的作者允许你在一定期限内免费使用软件或其中的一定功能(其实试用软件的完整授权也不一定要用钱,写个邮件把作者夸一顿或者给他做些事情,例如翻译软件,一样可以获得授权)。这些软件虽然免费,但是往往会因为有其他的原因而选择闭源。例如微软的Process Explorer,就是属于共享软件的典型。这个软件原属于sysinternels的作品,后被微软收购。如果是开源软件,搞不好要和微软打官司,也不可能被收购。而Winrar则是试用软件的典型,大家都听说过Winrar推动检查中国大型公司内使用非授权产品的例子吧。这个例子难就难在取证这个软件产品超过了使用期限,因为大多数人可以通过重装来避免提示。 自由软件是一个非常复杂的概念,要理解需要了解一些西方法律精神。自由软件现在在中国基本被视同为开源软件,其实两者是完全不一样的两个东西。自由指的是你拥有软件的选择权,包括是否使用,是否修改,是否散发,是否改善,具体可以参考这个文档(http://www.gnu.org/philosophy/free-sw.zh-cn.html )。为了保证以上权力,开源是必须的,然而开源并不代表你拥有以上权力。我们在上文提到过,是否开源和什么版权是两个事情。开源软件可以选择收费版权,也可以选择非收费版权,但是禁止你修改,再散发软件。这些都不属于自由软件的范畴。 自由软件的起因来自于上世纪70年代出现在美国的自由潮。受到自由潮的影响,当时很多软件大牛都是黑客精神(不是现在这堆脚本小子讲的黑客)的拥护者。他们认为人类学习和使用软件的自由不言自明,他们拒绝为他们的帐户加上密钥,并且以破解软件系统为乐。他们所写的程序也是免费分发。很难想象,在上世纪70 年代的时候,很多现在具备极大影响力的项目在当时只是几个人看不爽而随手做的一些小程序。很多自由项目直到现在还无人可以超越,发挥着重要作用。 自由软件运动是天赋人权观念在知识领域的延伸,目的是推动知识的扩散。因为知识产品都有一个学习的概念,新手需要不断的观摩和学习成熟的系统才能成长。然而如果允许其他人无限制的学习,那么新知识的发明就无法给创造者带来利益,从而导致没有人愿意发明创新。因此专利法规定专利的存在,给予了发明人一定时期的权限,使其可以从中获利。而同时规定了专利期限,使得新手可以学习。(贝壳注:现在的很多专利期限动辄50年70年,实在是太长了一点,10年到20 年的期限应当是合适的)而自由软件在创造伊始就放弃了自身的专利权,给予了其他人学习和改进的权利,因此被认为是软件业的第一推动力。尤其是近些年,在 GNU的推动下,出现很多很优秀的软件产品。当然,其中大部分是和普通人无缘的。例如flex分析器,emacs编辑器。 盗版软件这个词很不好界定,因为有两种界定线。一种是收费软件不付费使用,一种是违反软件使用授权。从范围上说,后者比前者更广泛,因为付费主要是取得软件使用授权,不付费一定违反了授权原则。而违反授权则不一定是不付费,也可能是试用软件超期(违反试用授权中期限限定),未授权可以修改而进行修改(这个尤其多出现在使用源码库的时候),违反最终用户协定(在共享软件中常见)。一般我们说的时候都指前者,但实质上,后者也属于软件权违法的例子。我们不妨用违法软件来称呼后者,而用盗版软件来称呼前者。 盗版软件是否是自由软件思想影响下的产物?绝对不是。我们上文说了,自由软件运动的主要目的是普及软件知识,那么破解软件成果如何普及软件知识呢?无法自圆其说。也有人说这个是打击收费软件,以扩大开源软件的影响力。这就要讲到西方的毒树毒果理论,这个理论认为,非法手段(毒树),无论为了什么目地,其产生的结果一定是恶意的(毒果)。开源软件有着自己的适用范围,不需要也不可以通过这种方式强行介入收费领域。再者说,如果没有收费软件来为大型项目提供资金,没有大型公司来消化软件人才,那么程序员的将来也就无法保证,更谈不上进一步普及和推进计算机研究发展了。 盗版软件只是一些不喜欢付费或者根本不拿版权当回事情的人,为了自己的利益编造出来的一堆谎言。例如微软的这次黑屏,很多人都在抵制,都在骂微软。我们可以想象一下,如果微软的产品出来的时候就带着黑屏措施呢?他们照用不误,最多就是搞一下破解。Winrar也带了保护措施,用的人照样一堆堆,破解照样满天飞。微软只和合法购买者订立了合同,保证不会侵犯他们的权益。非法使用者从根本上就没有依据来保障,你的系统即使上了Windows就当场机器爆炸,也无法控告人家。 其实本质上说,贝壳也是违法软件使用者。在这个社会里面,看清每个软件的版权,然后一点不差的照做是完全不可能的,可能的只有知道行为违法后想法弥补。使用盗版windows则是因为贝壳根本是linux用户,但是同事全是清一色的windows,沟通不方便而被迫使用。既然我不是主动高兴买的,就上个盗版得了,被发现最多回到linux下结束(中国的法律对个人侵权行为只纠正行为)。使用盗版windows,我们人人知道违法,但中国的法律基于告诉乃论,就是所谓的民不告,官不纠。自己知道怎么回事,回去闷声发大财就算了,明明是违法者,还跳出来义正词严的指责受害者,做人不能太CNN。 就如同我在MSN名字中写的那样。我虽然不赞成你黑屏,但是我捍卫你黑屏的权力。

封杀华硕宣告

Oct 29, 2008 - 1 minute read - Comments

兹因华硕陷害门事件(可于google上搜索 华硕 陷害门 黄静,不要使用百度),决定于今日起封杀华硕系列所有产品。不购买,不使用,不推荐,并向认识的人宣告此问题。特此声明。 P.S:虽然华硕不把我们当回事情,但是我们还是要把华硕当回事情,你想当下一个黄静么?

程序生产流程管理的一些想法

Oct 21, 2008 - 1 minute read - Comments

程序的生产管理本质上说应当可以纳入生产管理中,然而程序毕竟是一种特殊的产品,因此程序的生产管理也有其特殊性。下面贝壳从小到大阐述一下个人对生产管理的一些想法。当然,30人以上的团队规模贝壳根本没有碰到过,因此就不予置评。 首先我们从软件的生产流程开始论述,当然你可以没有流程,然而你不能没有过程。没有流程叫做不正规,低成本和高效率,没有过程……没有过程我也不知道你怎么做的,直觉? 管理的头一步是计划,软件生产的头一步是调研和需求分析,然后是紧密关联的系统构架,包括构架选择和结构设计。调研的典型情况是回答以下问题,软件为了谁而做(Who),设计周期和维护周期是多长(When),软件的适用范围(When),软件的意义和核心价值(Why),软件要达成什么目的 (What),如何设计达成这些目的(How)。这些问题中,要达成的目的和如何达成是核心。而后通过详细的讨论,得出到底要做什么东西,具备什么功能,以及一些细节问题。这时期形成的是软件需求分析报告和软件需求说明书。需求说明书的尺度是一个很难把握的问题,一般来说,需要灵活对应市场反馈的软件,需求说明书不用过早细化,反之则可以早细化一些。开发人员多,结构复杂的系统,设计说明书必须详尽,反之则可以简单一点。不过如果忽视甚至无视需求说明书,或者将需求说明书仅仅作为一个官样手续的团队,必定会在后面吃大苦头。如果要规避需求说明书,也并非不可以。贝壳会在最后描述一个原型系统方法,来规避灵活和不确定的需求对需求说明书的挑战。然而注意,这只是需求说明书的形成手段,本质上是以程序员和最终用户的互动来清晰需求,同时潜在的让程序员熟悉需求。并非真的不用讨论和细化需求,更不是提倡做项目不出需求说明。 项目的构架选择是在基本明确需求后做的事情,这个阶段主要明确以下问题。是单机软件还是群体软件,C/S还是B/S,.net还是java还是 C,Windows还是Linux。中间是否使用ORM,使用的话怎么设计细粒度表,不使用的话怎么使用冗余设计。结构设计和构架选择互相分离又紧密结合,结构理论上是脱离构架的,然而某些结构就必须适用某些构架(例如如果用了事务明显就不能用mysql,性能会差死),某些构架则要求你特殊设计结构。结构设计是系统一个非常广阔专业而复杂的问题,有兴趣的可以看系统结构和构架的一些书,还有设计模式和UML的,这里就不细说了。 在系统完成结构设计后,就开始系统的编码过程了。而项目时间确定,到这个时候才有依据。粗说是编码过程,其实又细分为构架实现,技术研发,编码,自测试,系统整合几个部分。结构设计完成后,抽象的结构必须经过严格定义才能进行使用,其中进行严格定义并且文档化的过程绝对不要轻率处理。如果是大型团队,应当指定一个人负责结构定义的维护,并指定几个技术骨干来讨论定义,讨论修改。这个人需要处理每一个对结构修改的请求,分辨是否应当修改结构,并且交给骨干团队讨论。讨论确定后,对定义进行修改,修改定义文档,并且通知所有部门进行修改。 当结构定义后,系统的框架模型已经清晰可见了,剩下的就是编码了。可是否能进行顺利编码呢?未必可行。因为实际上会在过程中碰到很多技术问题。例如需要使用以前没有接触过的框架和组件,需要对抽象数学模型提出可行算法等等。这些问题如果不先行解决,后面的编码无法顺利进行,技术骨干的最主要作用就在这里。在他们解决技术问题后(或者,更经常的,在中间提出的问题被他们解决后),系统就进入了编码阶段。编码阶段的代码一般来说会有不同级别的自测试,从最简单的写个小程序到最复杂的单元测试+冒烟测试,按照项目的级别具体分析。不过即使是再小的项目再小的模块,一般写一点代码就写个小片断测试下是否可行是最基本的常识,除非你能保证所有程序不论大小一次写对。在完成自测试后,还需要整合入系统,并可能伴随冒烟测试。如果结构设计良好,这个阶段会非常顺利,甚至不出现什么大的问题。反之,如果结构散乱,不用到客户那里,在这步就会碰到非常大的阻力。 在完成主程序的编码和整合后,项目进入收尾阶段。一般是漫长的测试和后续工作,主要包括叠代测试,性能分析,编写使用手册和编码手册,编写项目的技术分析,系统分析报告和各种材料。在这个阶段最主要是要通过测试,先于客户找出错误,并且逐步修改掉。良好的测试结果应当是逐步收敛的,当你看到一个逐步发散或者不稳定,根本没有规律的测试修改结果时,你的麻烦就大了。这通常是因为没有构架,构架错误,中间有不适应构架的修改,构架变化,核心算法错误,需求浮动太大等根本问题所导致的。当然,在测试的同时还要进行全面的文档化过程。 在测试和交付后项目是否结束呢?恐怕还没有。下面是漫长的客户服务期,需要收集和分析客户反馈,进行持续改进。不过那就是后面的问题了。下面我们按照团队的大小来逐步讨论团队的分配和任务。 首先是从一人团队开始,当然,如果也能叫团队的话。作为一人团队,也就没有什么分工问题。文档化要以轻量为主,方便自己日后理解,除非是客户特别需求。 而后是典型的一个团队,一个PM带几个技术,可能还有外面的美工支援什么的。人数不超过五人,不分组。这里前期的需求/后期文档都要由PM完成,程序员主要注重编码和测试(尤其是单元测试)。如果时间充裕,建议一些专门编码一些专门测试,这样可以有效保证代码质量。互相的沟通以开会为主,信息的沟通要诀是让每个人都知道别人的事情,尽量多的向别人传递信息。 再下面是一个典型的“大”团队,两个PM带四个程序员四个测试,其中有两个以上技术骨干,再加上一个专职美工和专职的UI Design(或者两个美工,基本差不多),8-16人的“大型”团队。说大型是因为这个团队开始内部就要分工协作了,加引号是因为……即使10个人,基本也就刚够分工的底线而已。 贝壳个人建议,除开美工等支持岗位,将这种团队分成三个部分。一个是PM组,负责和用户沟通协调,产生需求文档,盯项目进度,调度程序员,产生用户文档,产生其他材料。这组PM不要求高技术,对于技术建议会用,但不用精通(最好也别精通,业务骨干做PM是非常浪费的)。但是对于沟通技巧,协调能力和领导能力要求非常高,也要求有相当的文字功底。毕竟他们是要和客户沟通的人,要是鸡同鸭讲就麻烦了。和客户产生矛盾,文档写不好,更是麻烦中的大麻烦。由于协调要求非常高,因此PM组强烈建议至少两人,手机24小时开机!建议设立正副职,采取正职负责,副职挂钩的方式。 第二个团队是研发组(Dev),至少一个技术骨干带队。这组需要负责编码,自测试,系统整合,出开发文档,出技术文档。对于他们要求是沟通能力过关,程序编码效率高。对于系统经验,思考方式的全面和独特没有特殊要求。一般经过培训的新程序员就可以在研发组中担任工作。他们年轻力壮精力旺盛,相对编码效率比较高。不过如果有条件,还是用比较有经验的程序员比较好。在系统的整合测试,返工引发的效率低下控制方面会有相当的好处。 第三个团队是测试组(Test),至少一个技术骨干带队。这组要求负责系统的叠代测试和性能测试,可能还要帮助编写用户文档,进行项目实施,培训和售后支持。这组人的要求是工作勤奋(叠代测试的工作量是非常高的),技术过关(否则无法发现一些问题),系统经验丰富,思考问题全面而独特。因此强列建议由最强的技术骨干和一帮能吃苦的年轻人组成。一般来说测试组和研发组的人员比例在1:2到1:1之间。如果小于1:2,那么会发生测试不充分的情况。如果大于 1:1,只要成本允许,到是强烈支持。 最后一个团队(有人算了算……怎么还有),是系统的管理组。负责项目的构架选择,结构设计,时间节点认定,人事事务,开发成本控制,技术研发。这个团队有非常高的技术能力,管理能力和执行权限,一般由主PM,研发组和测试组骨干,客户代表,公司代表(多数和主PM是一个人)组成。主要是要对项目过程的监控,项目中人员权限的分配,核心技术的研究和管理进行处理。这个团队等若公司和客户的联合代表,对项目负全部责任。 对于30人以下的团队,估计可以按照比例放大组规模来使用同样的组织结构。不过如果再大,同样结构就不合适了。这主要是因为同一个组中的信息是互相完全流通的,超过10人的组会造成非常高的沟通成本。这时候一般是分解系统结构,分解研发组和测试组。将一个大型系统分解为两个或者多个独立的部分,让每个组分别研发和测试。这样可以避免每组内的信息沟通成本过高,可对文档的严密性和规范性提出了更高要求。通常来说,拆分方法有按照功能和按照构架。即按照功能划分出一个一个的业务模块,每个组开发一个完整的业务模块。和按照构架层次分为数据库组,业务逻辑层组和客户层组。通常来说,我支持以业务为主的拆分方法。因为此时组已经够大,让一个组精通所有层次不难。但是让所有组全部完整了解需求可就很难了。 对于这种成规模的开发,注重的主要是两点,文档和测试。最高的要求(也是我认为最好的褒奖)是及时的文档和全面的测试。此时的难点在于,研发过程中程序员经常为了修补问题而修改代码,但是忘记修改程序文档。或者需求变更后PM改了需求说明,通知了Dev,但是忘记通知Test。又或者通知了Test,但是忘记修改用户手册。因为诸多文档其实是对同一内容的不同描述,所以相互具有关联性。其中之一变化经常导致其他文档落后陈旧,而且版本不统一。 测试应当贯穿正规研发过程。从程序员实现一个个功能起就应当开始叠代,直到项目完成后。并且bug的管理应当和需求管理合并,成为几个组沟通的核心。测试的时候一定要注意充分测试和叠代测试,不要象微软一样弄出新的补丁补出老Bug的状况。 下面贝壳讲以下系统原型法,其实这个就是业界常说的敏捷开发。系统原型方法是指以构建非常简单的系统,实现非常核心功能的原型系统为基础,逐步推导出正规系统的功能和需求的系统分析方法。主要适用于系统需求不清晰,分析困难,开发周期短,程序员数量适中的项目。如果上述条件不成立,那么建议不要使用原型方法。 原型法的头一步是分析需求,不用说不确定的,就说为了实现业务目的(至少这个应该知道吧?)需要哪些功能。然后实现一个可用的,不用很美观,不用性能优化的系统。有了这个系统后,客户可以逐步分析使用这个系统哪里不方便,而后交给程序员改进。逐步反复,直到客户满意为止。使用这个方法,客户和程序员间,程序员互相之间要保证充分沟通,文档可以容后再写(前期还不确定呢,怎么写?)。主要是注意逐个的需求管理和Bug管理,这正好和我上面说的合并管理对应。使用这个方法的好处是当不清楚需求的时候可以马上做,逐步清晰。过程比较直观,做出来东西比较实用,也节约时间。坏处就是会浪费一定的程序员人力,而且一个没控制好就一直改一直改不知道哪里是头了…… 当前国内软件业企业的几个问题就是,不注重需求,不注重测试,不尊重专业,不尊重规范,不培养人才,不积累技术,不重视信誉,不打算做事。下面贝壳逐个细说。 不尊重需求,一般来说,老板讲的时候都是需求为重的,可当客户需要变的时候,老板很容易同意需求变更(虽然我可以理解,做生意也不容易)。不尊重测试,做程序的非常理解测试的重要性,然而老板却认为那个岗位可以随便找个人来做。实际上,测试是一个非常专业非常流程化非常严密的东西,测试的主管最好是公司里面最有经验的人。同时,还有不尊重专业的问题。并不是说老板干预程序员的决策,而是很多时候老板根本不了解技术骨干和PM,测试的区别。让技术骨干来做策划,或是负责、或者主导和客户沟通,这都是超级缺乏效率的做法。至于不尊重规范,事先划定的流程,在遇到重大问题的时候,往往就变成了废纸一张。到不是说在重大问题前非要坚持僵硬的步伐,可一个项目一半时间都是重大问题,这就过分了把?先说了项目过程中要推进知识积累,推进技术交流,推进这个推进那个,等项目一忙就全飞了。 同时由于程序员的超高流动率,当前中国的程序界有一个非常不良好的风气,公司基本不培养自己的程序员。都不知道公司是否能开到明年呢,培养了做什么呢?这点在大型公司就比较好,无论什么情况,基础的内部交流总是保证的。只要签长约,多数可以弄到一些培训。中小公司不培养人才一方面是没有必要,另外一方面就是没有能力。于是程序员就被迫自我培训,自学或者脱产参加培训。付出了成本,自然要赶快跳到能实现价值(能把钱赚回来)的公司里面去。中小公司为人员流动付出巨额成本,而且很多都根本无知觉。 举贝壳公司的例子吧。因为发展需要,今年年初公司曾大型招人,C#程序员,结果可用者寥寥无几,很多都是浮夸碰运气的。以至于一天面试十多个人,竟然一个备选都没有的情况经常发生。一个人过来投简历,硕士,要价10K多。不说公司能否负担,看了看做的题目,算法题还不错,C#技术,解决实际问题都一塌糊涂。这种人招进来差不多就是研究算法写Paper的主,要做程序还得培训一下。还有一个人,我前周刚刚送走,转眼又回来,估计是批量投简历的时候忘记筛公司了。还有一个项目经理真的是不错,讲起问题来很深入,经验丰富,可老板认为用不到,贝壳一点办法都没有。由于人员仓促到位,我们在开发后期付出惨烈代价!有一个程序员从到岗到离开公司,最大的贡献就是拖了三个多月的进度,因为他连static函数干吗用的都不知道。还有一些人,很适应岗位,可做不到多久就走了(当然,这是有各种原因的,试用和刚满期的人走是比较正常的事情)。问题是,其他人就要重新接手他的事情,等来了人再换手。这样的直接结果是什么呢?如果说项目拖延有一半是因为我们需求没做到位,另外一半就是团队的人才损失。如果在普通项目上碰到类似问题,来的人不能做事情,人员替换率高。那么本来能按时完成的任务就一定会延后,而且分析的时候很难直接表现出来,多数会被认为是工作效率不够高,工作态度不认真之类的(某种意义上也没错,毕竟不能做事的人,不是因为效率不高就是因为做事不认真)。不能留住人才造成的后果,是通过项目拖延表现出来的,使得公司往往失去了隐性可能的良好口碑。这种软性杀伤是非常致命的但是又是难以直接表现的。 如果说不注重人才,还怎么能积累技术呢?人是技术最主要的载体。尽管我们可以通过互相培训,技术交流,技术文档化来积累技术。但是如果没有老员工的指点,那么新员工是很难吸收企业的原有技术体系的。无法积累技术的直接表现有两个,一个是中国企业没有核心技术,另外一个就是掌握技术的人就卡了公司的脖子。可能有人会举出中国有多少专利多少成果。贝壳告诉你,按照贝壳做项目的经验,那个多数都是项目做好了用来表功的牌坊。很多技术都是公司不敢给个人,个人不敢给公司,因为浮动率太高。许多真正有价值的核心技术往往是因为缺乏大公司(或者缺乏人)作为后台,而无法正式的走向商业化运作,更无法走向系统化理论化。因此中国不但缺乏真正的核心技术(我指能解决问题,有实现难度的技术),更缺乏(这点可以确认)系统化理论化的技术体系。而掌握公司核心技术的人往往就能卡公司的脖子,尤其是技术都掌握在一个人手中的时候。并非说程序员都有坏心或者什么的,而是程序员有很多和老板不一样的想法(例如要重视测试,要重视专业等等)。当程序员觉得他是对的时候,为了和老板争辩,往往会使出走人的杀手锏。固然,公司是对产品拥有产权的。可是掌握核心技术的人不在,没有人能继续改进,研发新的产品系列,这不是要公司的命么?这时候老板就处于弱势的一方。从某个事情来说程序员往往是对的,可是从企业发展来说却绝非好事。 最后两个问题则是中国软件业更深层次的问题,不重视信誉,不打算做事。整天就想着前辈一夜暴富的事情,或者谁谁风投成功吃喝不愁的事情。根本不打算花心思将事业做好,而是设法请客招待人拉风投,找人做假买点击量买排名,花钱黑掉对手的网站,盘剥底层员工,炒作一些无聊的事情增加知名度。某种意义上说,这个才是中国软件业最大的毒瘤。

一件最XXX的事

Oct 13, 2008 - 1 minute read - Comments

好像小时候老师经常出这样的题目,不过我每次都没得可写,总觉得那堆事情太假太做作。没想到,我这两天亲身经历了一件很囧的事情。 事情是这个样子的。贝壳前两天玩开心(好啦,我知道很无聊,不过发现一堆N久没有联系的同学,很好玩那),然后突然想到搜索高中同学。首先跳出来的是我们的于飞同学,据记载,不出我们所料,去日本了。然后是一位叫江宁的同学,哪位?贝壳怕自己忘记了某些曾经的同学,所以打算点进去看看她的好友里面是否有高中的朋友,然后发现——这是谁? 她的列表中有一位“阿达”,这位同志刚刚加我,并且和我一样,是赵一搏的朋友,换句话说,是初中和大学圈子里面的。是不是贝壳点错了?还是开心太强大了? 事实证明,都不是,是事情太巧合了。贝壳联系该同志本人后发现,所谓“阿达”,乃是丁之光同学,正宗的初中和大学同学。而江宁同学在牛栏山高中复读,是杨亮和大佟的同学。他们是同事,我发消息的时候正好在旁边,OMG。 够囧了吧?好戏还在后面呢—— 贝壳一时高兴,问,那个秦伯韬你认得么?认得。段旭辉呢?认得。张雷?认得。王巍?认得。朱金辉?认得。许智翔?谁? shit,怎么就是不认得贝壳,俺这么有名的说。 不过此同学认出了我一箩筐的高中同学,于是贝壳自己都混了。然后说——段是在上海念书么?不是。那上海念书的是谁?张雷。(到底谁在牛山混的久啊?)哦——我知道,大佟的男友吧—— 刚刚说完——对面发出了一阵吓死人的叫声—— (贝壳):说错了么?我记得是杨亮女朋友和我说的(不就是刘莹同学么)—— (江宁):张雷很帅的—— (贝壳):小声点,大佟也是你朋友—— (江宁):呃—— (贝壳):好像我记得一起看过他们,那次我去复旦玩,大佟和张雷都来的,朱金辉陪他四中的女友,没来—— 然后对面发出一阵杀气—— (江宁):说,朱在复旦有几个女友—— (贝壳):啊,我又说错什么了? (江宁):我一个姐们,是朱前女友—— (贝壳):(原来是上门讨债的,少说的好)哦,哦,可能我记错了—— (江宁):OOXX..**(省略一堆话,具体可以自行想象),不过你是可能记错了,当时王巍的女朋友是四中的—— (贝壳):。。。(乌鸦飞过)。。。—— 天啊,贝壳不想活了——

分词算法的具体实践

Oct 12, 2008 - 1 minute read - Comments

说到分词算法,可能很多人都很陌生,然而说起百度,google,很多人却是耳熟能详。google,百度在搜索的时候,输入关键词后瞬间就可以得到结果,如果用通用数据库是无法做到的。实行这个加速的关键就是分词算法。例如”项羽是萝莉控”这句句子,我们一般搜索都是搜索项羽,或者萝莉控,萝莉。你见过有去搜”是萝”这个关键字的么?因此系统通过分词,将句子分解为”项羽/是/萝莉控”,去处单字常见词”是”(如果要索引”是”,可以想像有多少文章没有”是”的),我们就得到了项羽和萝莉控两个词。再通过反向关联,建立项羽,萝莉控指向文章的连接,就可以完成瞬间的搜索了(具体原理不说了,只要有一定数据库基础的人都应当能想明白原理)。并且通过关联性,某种程度上也可以提供”是萝”的搜索(带”是”的词,带”萝”的词,相关度最高)。 那么,如何来计算分词呢?方法很多,大家可以在网络上搜索下,贝壳就不赘述了。贝壳现在要说的是这次贝壳主要试验的方向,基于词典的机械分词中的最大分词算法。 机械分词算法是当今的主流,关键原因在于速度问题。虽然正确的分词很有价值,然而如果速度太慢,一样没有什么用处。机械分词一般可以保证 98%-99.5%以上的正确率,同时提供极高的分词速度。而机械分词一般来说,都是基于词典的。主要有正向分词算法,逆向分词算法,最大匹配分词算法。其中最大匹配分词算法具备最高的灵活性,只要你能评价一个切分的优秀程度,算法能把所有可能算出来让你评价。然而大家可以想像,这个是非常耗费CPU的。贝壳在这个基础上,做了一个具体的实现和细化加速。并且有准备做为一个开源项目来长期运作(只要有人有意向接手合作)。 首先我们先说贝壳这个算法的评价原则。贝壳认为,评价原则应当有以下几点。同时也必须要说明,以下原则是无法正确评价所有情况的。不过以下原则在原则正确的基础上比较便于优化。一、无法分析的词最少(这是全局最大匹配的理论核心)。二、匹配出的原子最少(这是保证分词优秀性的指标)。三、匹配出原子的出现概率和最高(这是纯粹没有办法了从概率上提高匹配正确的可能)。 当我们分析一句话的时候,我们可以想像,这句话应当是正常的,可被理解的。换句话说,句子中应当都是有意义的词。那么,在匹配后无法理解的词是什么呢?一种是匹配错误,一种是新单词,一种是单字成词和无意义助词。单字成词的例子有上面的”是”,我们可以通过一个比较小的词典去除。那么,假定词典够大的情况下,无法理解和分析的词越少的组合越正确。而同样一句话,匹配出的原子越少,在搜索的时候效率越高。因此我们有规定了原子最少原则。至于最后一个,在无法分析词一致,原子个数一致的情况下,我们只能通过出现概率来猜测可能性。 然后,现在让我们分析一下分词的特点,并且做一定的优化。首先就从最著名的例子,”长春/市长/春节/致辞”开始。 长春市长春节致辞 首先,匹配算法一定要先搜索到一个出现的词,有词才有匹配优化问题。没有词的话,你试试看分词”嗡嘛呢呗咪吽”。根本无法可分。因此首先我们要计算出一个出现的单词。贝壳是从正向开始计算的(主要是因为词典的加速方法是头索引的)。 *长春*{市长春节致辞} *长春市*{长春节致辞} 好的,我们匹配到了两个,不过这就是全部可能么?不是,否则就变成了正向最大搜索。你可以看看”有意见分歧”。如果从头一个匹配到开始计算,无论如何都是”有意/见/分歧”,而事实是”有/意见/分歧”。因此我们还有一种可能,在头一个匹配到的位置,其实并不匹配。不匹配多长呢?最大长度不会超过最短的匹配词。为什么?我们来看下面一个例子。 *长春*{市长春节致辞} *长/春/(这两个字不是词,而是两个无法理解的字){市长春节致辞} 很明显,后一种分法违背了我们的第一原则,无法分析的词最少。无论后面怎么计算,其最优结果是相同的。在后续结果相同的情况下,头一次匹配到词后,所有可能的跳空(搜索可能的不匹配)最大长度严格小于最短匹配词的长度。 那么是否所有跳空都要搜索呢?也不,我们可以继续剪枝。对于情况”有意见分歧”来说,这个路径是必须搜索的。但是对于我们的例子来说,是无需搜索的。为什么呢?我们看以下计算。 *长/{春市长春节致辞}(下一个匹配是什么?总不会是春市吧,所以应当是"市长") *长/春/市长*{春节致辞} *长春*{市长春节致辞} 大家可以看到,其实这个路径是无需计算的。那什么情况下需要计算呢? 一旦跳空,其跳空后寻找到的下个词的位置必须严格小于最短词的词尾位置。否则就没有搜索价值。具体可以看以下示例。 XXXXXXXNNNNNNNNNNN(X是词,N是无关紧要的) SSSSSSSXXNNNNNNNNN(S是跳空或者跳空后形成的无法理解字,X是词,在这种情况下,无论后面怎么评价,都不影响该匹配被剔除) OK,我们回到例子,刚刚我们说了,有”长”的匹配。但是通过刚刚的剪枝,又被剪了出去。我们下面分别计算两个情况。 市长春节致辞 *市/{长春节致辞} *市长*{春节致辞} 长春节致辞 好,我们先不计算下去了。通过上面的计算,我们发现,在计算过程中经常需要计算同一内容的结果。我们可以想一下,同样的分词,同样的算法,出现的应当是同样的结果。就是说,分词函数是状态无关的算法。通过分解一个单词,得到一个最优结果。那么,我们对于同样的数据,何必需要计算两次呢?贝壳上文中提到过记忆函数,这次就用上了。根据贝壳的试验结果,如果记忆全部词的分解结果,会造成大量的记忆-释放,而内容基本没有用到,造成效率下降。如果只记忆长词的分解结果,往往又会因为太长,大多数句子无法达到长度而根本没用。这中间有个平衡值,具体多少贝壳就不说了。我们可以按照上文的方法计算以下两个过程,得到结果。大家可以自行验证。 春节致辞 *春节*致辞* 长春节致辞 *长/春节*致辞* *长春*节/致辞* 结合上面的过程,我们推算得到结果。 *长春*{市长春节致辞} *长春*市长*春节*致辞* *长春市*{长春节致辞} *长春市*长/春节*致辞* *长春市*长春*节/致辞* 按照上面的评价原则,我们得到了正确的结果。 大家可以看看其他例子,这里着重说一下”有意见分歧”。 有意见分歧 *有*意见*分歧* *有意*见/分歧* 注意,有是单字成词,见可不是。如果见单字成词,做看见讲,那这句话就彻底成歧义句了。可以理解为,有意的要看到(或者让其表现出)分歧。这一般是古文语法。由此也可以看出上述原则在理解古文的时候往往会出现问题。同时还要指出的是,在匹配”长春市长春药店”的时候,会出现以下结果。 长春市长春药店 *长春*市长*春药店* *长春市*长春*药店* 两者的无法理解词都没有,切分数一致,最后硬是因为春药店出现概率低而被筛掉。可见系统有的时候是依赖概率和人品在工作的。 经过上面的原则和算法,贝壳实现了一个python的分词程序,1000行代码,原型系统。90W条词情况下,在AMD MK36上(2G主频)分词效率66K/s上下,具体看分词的选项(例如顺序分词就比较节约资源,分词排除重复就比较慢,启用多线程后在单CPU 机器上更慢),内存使用114M。使用C++写的核心词典后,90W条词的情况下分词速度80K/s,比python的核心词典快了20%,内存70M,节约内存40%。不过可惜,这个核心词典是公司产权,贝壳无权公布。并且贝壳做了一些工作,准备使用分词程序来生成分词词表。这个么贝壳就不准备讲了。前面讲的内容贝壳准备放到试验型站点 http://shell909090.3322.org/split_word/split_show/ 上面去,08年内有效。有兴趣联系我的可以发 mail给我,shell909090+split@gmail.com,欢迎大家试验并提出意见。