2006年03月14日

昨天看到了google要出9000万解决点击欺诈问题的新闻,好多人也在评论这个,我的感觉是google很大气,虽然只是1%的利润而已,但是基数却不少,7个亿人民币了。这也就是老美,点击欺诈在中国诈了这么许多年,还没有一起官司,可见俺们真是厚道啊。

说到pay on click这种广告形式,在欧美已经由来已久了,目的就是把广告用户分众处理,让广告主的投入更有针对性。好东西嘛。结果又应了那句老话,甭管多好的东西到了中国统统变了味道。结果真的是这样。

首先声明我是有发言权的,因为在中国出现的pay on click我统统都做过,不仅做过,而且把这东西卖给别人,赚取微薄之利。pay on click到了中国最大的变质就是改名叫了竞价广告,并且把google的adwords赞助商广告也叫做google竞价,光这个名字我就觉得超级恶心,在国外,一些模棱两可的词汇是没有人多少人投放广告的,即便投放,价格也不很高,因为广告主知道这些词汇面对的用户不够集中,达不到分众的目的,可是郁闷的是,在国内搜狐和百度竞价横行的那几年,连“机械”这样模糊不清的广告词,都能“竞”出几十块钱一次的天价来,我就纳闷广告主懂不懂媒体规律呀。

回正题,因为曾经是这些公司的代理商,道听途说百度渠道就曾经鼓励代理商点击客户的广告,我还确实见到过点击软件之类的工具,不知道是不是百度官方的意思,不过那时候的广告主不懂,能骗也就骗了贝。后来出现了很多pay on click广告包年收费的现象,也是典型的欺诈,到现在包年收费还是很多google广告“代理商”的重要盈利手段。没办法,客户傻呀。

我觉得google这样的公司已经是相当厚道了,9000万呢,态度可谓相当不错,别学有些人看见大公司被罚就拍巴掌,叫嚣什么google会因此而怎样,我看不会,我们是需要google的。

而且点击欺诈这个词汇也并不确切,因为这毕竟是广告业中明确分众并且明确广告投放次数的唯一一种形式,比起中央电视台春节晚会的1亿多次短信的数量统计不知道要准确多少倍,就算是有人闲着没事多点了几下,您啦忍了认了不就行了吗?就算算法再更新,您的竞争对手就喜欢通过广告进入您的网站,您还不是一样要损失广告费来欢迎竞争对手参观?

厚道些大家都好。

2006年03月13日

啥也别说了,就一个字“牛”,爱好天文?赶紧看吧!

http://www.google.com/mars/

一定得选最好的托管中心,
全套Cisco的网络设备加SUN的服务器
建就建最酷的用户体验
免费注册帐户
每个帐户存储空间最少也得两个G
什么AJAX呀、Tag呀、Rss呀
能给他整地全部给他整上
社区附带一个VIP区,有牛人7×24小时蹲点帮你解惑
Blog上常驻一个叫Keso的家伙
留小辫儿,特大牛的那种
只要一打开页面,甭管有事没事都得用Skype跟人家说
“你丫赶紧给我注册!”
一口地道的京片子
倍儿有面子
网站里还要建一个wiki系统
全部翻译自维基百科
每天翻译量起码百兆计算吧
再建一个站内搜索
支持所有内容全文检索
文本呀、RSS呀、Blog呀,你要搜什么我给你找出什么
就是一个字——快
全站搜一次才用0.00001秒
在这里注册用户的不是CEO就是网络精英
你要是分不清Blog和WebLog
你都不好意思去TrackBack人家
你说这样的网站,VC会投多少?
我觉得怎么着也得两千万美金吧?
两千万美金?那是成本
四千万美金起
你别嫌贵,我还挑东家呢
你得研究VC的投资心理
能掏起两千万的主儿
根本不在乎再掏两千万
什么叫Blogger,你知道吗?
Blogger挑服务商都用最2.0的,不用最好的
所以,我们做web2.0的口号就是:
不求最好,但求最2

写下面几句话的初衷在于我将我的blog从微软的msn spaces换到了这里,换的原因可以讲出很多,比如:

1、不喜欢微软,微软的东西一惯是要钱的,一旦免费了就觉得有阴谋;

2、donews blog的简洁和易用吸引了我,blog不就是写文章么,简单就好;

3、刚从donews网友会上回来,发现大家都是donews作者才去的,读者或者潜水员是不好意思去的,过意不去了;

4、看看我喜欢的用户名还能不能用,先占上(补充一句,这种用不用先占上的思想在免费用户脑袋里是根深蒂固的,这是用户忠诚度低下的根源问题)

5、再加一条,倒霉ms把有用的用户功能都去掉了,比如加上自己的标志的功能,我就腻味ms那种非把自己的品牌挂在别人空间上的那种霸道,而且还打广告,超恶

…… ……

但是不管怎么说,msn spaces 我用了1年了,竟然没有任何的忠诚度,说走就走了,是说明donews的用户策略的成功,还是微软的失败,还是免费用户们无耻的不确定性?我说不好,反正我是没有什么忠诚度的用户了,鄙视自己一下,呵呵。

2006年03月12日
将下列原则应用到你的软件工程中,你会获得立杆见影的成果。

1. 人远比技术重要 

你开发软件是为了供别人使用,没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平,因为他们那时侯将主要精力都集中在技术上。显然,构件(components),EJB(Enterprise Java Beans)和代理(agent)是很有趣的东西。但是对于用户来说,如果你设计的软件很难使用或者不能满足他们的需求,后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的界面上。

2. 理解你要实现的东西 

好的软件设计人员把大多数时间花费在建立系统模型上,偶尔写一些源代码,但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。

3. 谦虚是必须的品格 

你不可能知道一切,你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作,因为软件开发所用到的工具和技术是在不断更新的。而且,一个人也不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件开发的人来说,每天可以学习很多新东西(如果愿意的话)。

4. 需求就是需求 

如果你没有任何需求,你就不要动手开发任何软件。成功的软件取决于时间(在用户要求的时间内完成)、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么,或者软件的需求定义,那么你的工程注定会失败。

5. 需求其实很少改变,改变的是你对需求的理解 

Object ToolSmiths公司(www.objecttoolsmiths.com)的Doug Smith常喜欢说:“分析是一门科学,设计是一门艺术”。他的意思是说在众多的“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要(我理解的意思是需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力 - 译者注)。

如果需求经常改动,很可能是你没有作好需求分析,并不是需求真的改变了。

你可以抱怨用户不能告诉你他们想得到什么,但是不要忘记,收集需求信息是你工作。

你可以说是新来的开发人员把事情搞得一团糟,但是,你应该确定在工程的第一天就告诉他们应该做什么和怎样去做。

如果你觉得公司不让你与用户充分接触,那只能说明公司的管理层并不是真正支持你的项目。

你可以抱怨公司有关软件工程的管理制度不合理,但你必须了解大多同行公司是怎么做的。

你可以借口说你们的竞争对手的成功是因为他们有了一个新的理念,但是为什么你没先想到呢?

需求真正改变的情况很少,但是没有做好需求分析工作的理由却很多。

6. 经常阅读 

在这个每日都在发生变化的产业中,你不可能在已取得的成就上陶醉太久。

每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱,但会使你成为一个很有实力的竞争者。

7. 降低软件模块间的耦合度 

高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。

你可以通过以下方法降低程序的耦合度:隐藏实现细节,强制构件接口定义,不使用公用数据结构,不让应用程序直接操作数据库(我的经验法则是:当应用程序员在写SQL代码的时候,你的程序的耦合度就已经很高了)。

耦合度低的软件可以很容易被重用、维护和扩充。

8. 提高软件的内聚性 

如果一个软件的模块只实现一个功能,那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。

判断一个模块是否有高的内聚性,看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词,则说明你需要将该模块细化。

只有高内聚性的模块才可能被重用。

9. 考虑软件的移植性 

移植是软件开发中一项具体而又实际的工作,不要相信某些软件工具的广告宣传(比如java 的宣传口号write once run many ? 译者注)。

即使仅仅对软件进行常规升级,也要把这看得和向另一个操作系统或数据库移植一样重要。

记得从16位Windows移植到32位windows的“乐趣”吗 ?当你使用了某个操作系统的特性,如它的进程间通信(IPC)策略,或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度就已经很高了。

好的软件设计者把那些特有的实现细节打包隐藏起来,所以,当那些特性该变的时候,你的仅仅需要更新那个包就可以了。

10. 接受变化 

这是一句老话了:唯一不变的只有变化。

你应该将所有系统将可能发生的变化以及潜在需求记录下来,以便将来能够实现(参见“Architecting for Change”,Thinking Objectively, May 1999)

通过在建模期间考虑这些假设的情况,你就有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你最基本的目标。

11. 不要低估对软件规模的需求 

Internet 带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。

今天只有100人的部门使用的应用程序,明天可能会被有好几万人的组织使用,下月,通过因特网可能会有几百万人使用它。

在软件设计的初期,根据在用例模型中定义的必须支持的基本事务处理,确定软件的基本功能。然后,在建造系统的时候再逐步加入比较常用的功能。

在设计的开始考虑软件的规模需求,避免在用户群突然增大的情况下,重写软件。

12. 性能仅仅是很多设计因素之一 

关注软件设计中的一个重要因素–性能,这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。

但是你的设计还必须具有可靠性,可用性,便携性和可扩展性。你应该在工程开始就应该定义并区分好这些因素,以便在工作中恰当使用。性能可以是,也可以不是优先级最高的因素,我的观点是,给每个设计因素应有的考虑。

13. 管理接口 

“UML User Guide”(Grady Booch,Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999)中指出,你应该在开发阶段的早期就定义软件模块之间的接口。

这有助于你的开发人员全面理解软件的设计结构并取得一致意见,让各模块开发小组相对独立的工作。一旦模块的接口确定之后,模块怎样实现就不是很重要了。

从根本上说,如果你不能够定义你的模块“从外部看上去会是什么样子”,你肯定也不清楚模块内要实现什么。

14. 走近路需要更长的时间 

在软件开发中没有捷径可以走。

缩短你的在需求分析上花的时间,结果只能是开发出来的软件不能满足用户的需求,必须被重写。

在软件建模上每节省一周,在将来的编码阶段可能会多花几周时间,因为你在全面思考之前就动手写程序。

你为了节省一天的测试时间而漏掉了一个bug,在将来的维护阶段,可能需要花几周甚至几个月的时间去修复。与其如此,还不如重新安排一下项目计划。

避免走捷径,只做一次但要做对(do it once by doing it right)。

15. 别信赖任何人 

产品和服务销售公司不是你的朋友,你的大部分员工和高层管理人员也不是。

大部分产品供应商希望把你牢牢绑在他们的产品上,可能是操作系统,数据库或者某个开发工具。

大部分的顾问和承包商只关心你的钱并不是你的工程(停止向他们付款,看一看他们会在周围呆多长时间)。

大部分程序员认为他们自己比其他人更优秀,他们可能抛弃你设计的模型而用自己认为更好的。

只有良好的沟通才能解决这些问题。

要明确的是,不要只依靠一家产品或服务提供商,即使你的公司(或组织)已经在建模、文档和过程等方面向那个公司投入了很多钱。

16. 证明你的设计在实践中可行 

在设计的时候应当先建立一个技术原型, 或者称为“端到端”原型。以证明你的设计是能够工作的。

你应该在开发工作的早期做这些事情,因为,如果软件的设计方案是不可行的,在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性,从而,你的设计将更容易获得支持。

17. 应用已知的模式 

目前,我们有大量现成的分析和设计模式以及问题的解决方案可以使用。

一般来说,好的模型设计和开发人员,都会避免重新设计已经成熟的并被广泛应用的东西。

18. 研究每个模型的长处和弱点 

目前有很多种类的模型可以使用,如下图所示。用例捕获的是系统行为需求,数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加入实际数据描述,但是,这对开发者不是非常有用。同样,数据模型对描述软件需求来说是无用的。每个模型在你建模过程中有其相应的位置,但是,你需要明白在什么地方,什么时候使用它们。






19. 在现有任务中应用多个模型 

当你收集需求的时候,考虑使用用例模型,用户界面模型和领域级的类模型。

当你设计软件的时候,应该考虑制作类模型,顺序图、状态图、协作图和最终的软件实际物理模型。

程序设计人员应该慢慢意识到,仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求,要么很难扩展。

20. 教育你的听众 

你花了很大力气建立一个很成熟的系统模型,而你的听众却不能理解它们,甚至更糟-连为什么要先建立模型都不知道。那么你的工作是毫无意义的。

教给你开发人员基本的建模知识;否则,他们会只看看你画的漂亮图表,然后继续编写不规范的程序。

另外, 你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型,以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候(比如UML-译者注),你的团队才能实现真正的合作。

21. 带工具的傻瓜还是傻瓜 

你给我CAD/CAM工具,请我设计一座桥。但是,如果那座桥建成的话,我肯定不想当第一个从桥上过的人,因为我对建筑一窍不通。

使用一个很优秀的CASE工具并不能使你成为一个建模专家,只能使你成为一个优秀CASE工具的使用者。成为一个优秀的建模专家需要多年的积累,不会是一周针对某个价值几千美元工具的培训。一个优秀的CASE工具是很重要,但你必须学习使用它,并能够使用它设计它支持的模型。

22. 理解完整的过程 

好的设计人员应该理解整个软件过程,尽管他们可能不是精通全部实现细节。

软件开发是一个很复杂的过程,还记得《object-oriented software process》第36页的内容吗?除了编程、建模、测试等你擅长工作外,还有很多工作要做。

好的设计者需要考虑全局。必须从长远考虑如何使软件满足用户需要,如何提供维护和技术支持等。

23. 常做测试,早做测试 

如果测试对你的软件来说是无所谓的,那么你的软件多半也没什么必要被开发出来。

建立一个技术原型供技术评审使用,以检验你的软件模型。

在软件生命周期中,越晚发现的错误越难修改,修改成本越昂贵。尽可能早的做测试是很值得的。

24. 把你的工作归档 

不值得归档的工作往往也不值得做。归档你的设想,以及根据设想做出的决定;归档软件模型中很重要但不很明显的部分。 给每个模型一些概要描述以使别人很快明白模型所表达的内容。

25. 技术会变,基本原理不会 

如果有人说“使用某种开发语言、某个工具或某某技术,我们就不需要再做需求分析,建模,编码或测试”。不要相信,这只说明他还缺乏经验。抛开技术和人的因素,实际上软件开发的基本原理自20世纪70年代以来就没有改变过。你必须还定义需求,建模,编码,测试,配置,面对风险,发布产品,管理工作人员等等。

软件建模技术是需要多年的实际工作才能完全掌握的。好在你可以从我的建议开始,完善你们自己的软件开发经验。

如果我没记错的话,3月12号,也就是今天,应该是植树节,一早起来,天气倒是晴好,可是风吹得很狂猛,好在昨天毛毛草草地下了半天的鹅毛大雪(怪天气),今天并没有出现一贯的扬沙天气。想一想已经n多年没有参加过植树了,看了看google,竟然没有一贯性地把标志更换成植树节特色的标志,这更让我心虚不知道今天是不是植树节了。。。这些年总是在忙,在外面吃饭也多,一次性筷子不知道违心地用了多少,哎,对不起那些树啊,决心明天一定要去植树,一定要去,组织个植树节的旅游和聚会,就种速生杨,苗便宜易活防风成材快,这样种2棵应该就能把我用掉的筷子补上了吧。

2006年03月10日

毫无道理,提意见怎么在自己的blog里面写,不上人家那里去提呢,厚厚,这就是我的怪癖,意见也是看缘份的,呵呵。

意见正文:最近 365kit 好慢啊。

其实我是要测试一下关键字好不好用,呵呵。

参加完donews6的网友大聚会,回来一想,XX的,别让什么崇拜俺的人物把俺的名字给抢注了吧,要是真的抢注了,以后再去donews网友聚会的时候可就不爽了,还是先自己搞下来再说了。

于是乎试着注册了一下,呵呵,看来大家还真给面儿,拿下。

注册完了,一想,要是什么都不写那就太不厚道了,也不符合环保主义者的习惯啊,于是登录。

X,竟然这么快,界面简洁易懂,除了.aspx让人看着不爽以外一切都像是为我订制的,爽!

以后就这儿了,终于又抛弃了一件微软的东西(msnspace),心理畅快之极。

呵呵,好了,不费话了,到哥们儿那里讨个有情链接去。。。