posts - 59,  comments - 323,  trackbacks - 0
一直有朋友发email来索要那本OpenDoc的源代码,这里一并给出下载地址。

http://www.blogjava.net/Files/zbw25/code.rar

抱歉,拖了这么长时间。

Update:
昨天在BlogJava上传的文件,今天就不能下载了,比较晕。。。

http://www.javaeye.com/topic/19448

这是在JavaEye的发布OpenDoc的地址,里面有下载的Link。
http://www.javaeye.com/topics/download/54f814f5-b77f-46e1-bf61-bd384493f118

应该要注册成为javaeye的用户后,才能下载。
posted @ 2006-10-18 19:45 读书、思考、生活 阅读(108272) | 评论 (11)编辑 收藏
 
 

我写的总结
 

  如果和超级女生这样的大赛相比的话, Ajax 大赛应该被称之为“ Ajax 小赛”吧。 250 名初赛选手, 10 多名复赛选手,三个来自于一个网站“ Ajax 中国”的评委。这样的比赛意义在哪里呢?

 

  仅仅看数量,是看不出来的。

 

  Ajax Web 应用的一种,而且可以肯定的说,是 Web 应用中最为复杂的一种,一个 Web 项目,我们通常都会分为“美工”、“ Web 静态页面制作”、“ Server 端系统开发”这样几个工种。而 Ajax 应用则同时需要 Server 端与 Client 端复杂的端到端编程技术。

 

  对于参赛选手而言,这些工作,都得靠一己之力来完成,在 2 个多月之内,做出来的作品,要美观,要好用,要有创意,要符合 W3C 组织的 Web 标准,还得正确有效的作为一个程序在浏览器里运行。真的,不容易!这 11 位(可能会修改)参赛选手,每一位都不容易!

 

  我们(大赛组织者、评委和参赛选手)都非常确切的意识到,我们正处在一场变革刚刚起步的阶段。 Ajax 可能仅仅是这场革命开始时,最响亮的一个名字。激动人心的发展将会接踵而来,而我们这些人将会自豪的宣称,我们从一开始就不是旁观者,而是实实在在的参与者,和有力的推动者!

 

  看着选手们的代码,我们的信心更加充足,这些 Ajax 的爱好者和参与者们,不仅是热忱的,更是踏实的。不但是严肃认真的,更是勇于创新的。由这样的一群人来推动 Ajax 在中国的发展,实在是一个极好的开始。

 

  而 Ajax 大赛,正是这样一个机会,使得这一群中坚力量,能够集结、凝聚,进而取得更加卓越的成就。这就是我对于这个比赛意义的理解。


   说实话,稍微吹了一点

posted @ 2006-07-14 21:35 读书、思考、生活 阅读(30203) | 评论 (0)编辑 收藏

“出来混,总是要还的。”这话说得真好。我最近的blog写得太少了,想写的东西,其实又实在是不少,一日复一日的堆积心里,又想写,又不想写,难受呀。

这篇blog原本还是打算在Word 2007里写的, 后来作为草稿发上来,发现还有不少不如意的地方,还是在线写吧。

想说的事情挺多的,一件一件的说吧。

一、敏捷中国大会,6月6日在上海交大举办了一场。专门介绍ruby的,昨天在csdn的martin fowler的中文blog上,也贴出了完整的演讲全文。《Ruby是一个非常好的开发工具》,《现场演示Ruby编程》,《细数Ruby语言优缺点》。关于这次活动的一篇Blog按理我早就该写了,但是却一直没有写出来。有两个原因,一个是那天老马在开讲之前,熊节是打算在边上当翻译的,谁知道交大的同学们牛啊,纷纷表示,不必翻译,都听得懂的,我一个学俄语的人,在那里抗议也没什么用,大家都一副听力很好的架势,老马在上面叽里呱啦的讲着,下面的同学们不时的笑着……我呢,也只能随着大家的笑声,冲着老马空洞的笑着……;第二个原因呢,是个原本打算等CSDN的演讲的翻译出来,我也好引用一下,谁知这一等,就是半个月,我都已经换了一个工作了。

说实话,那天老马的演讲,我没听懂,不过因为他在那里现场coding,所以我还是看懂了一些代码。Ruby的代码给人留下了深刻的印象,而且我不知道是不是Martin故意装作是一个初哥,反正看起来他对ruby的语法也不怎么熟悉,不过ruby厉害的地方就在于,你就算是个初哥,边试边弄,也能把程序鼓捣出来。

原本的计划是介绍Ruby DSL的,不过时间明显的不够用,关于DSL的部分反而讲得很少,还好这两天armlinux-w翻译了一篇专讲Ruby DSL的文章过来:《用Ruby 创建领域特定语言》。当时看到Martin演示的,用Ruby语言描述的配置文件时,脑子里颇有些想法,也写了问题交上去问,不过老马也来不及一一回答,后来想想,提的那个问题,也没有经过自己的深入思考与实践,不提也罢。

倒是我提的另外一个问题,颇有些价值,当时正好交大的林德樟老师也在,我以前就对林老师的那句语录有所不满《XP是草书,UP是正楷,先草书后正楷,就会乱套》。在自己的Blog上也和林老师的门徒们吵过架,如今Martin教主本人既然来了,我等看客正应该把这仗挑起来才是。于是我就提了一个问题,让两位专家都来评价一下这句话。可惜的是,后来他们两人的精彩交锋,我也没怎么听懂,还是林老师还用中文阐述了一遍自己的观点,我算是了解了一下他的逻辑。

原来我以为,林老师这样的说法,是出于在校教师“和稀泥”的考虑。这下我才了解到,原来林老师是真的这么认为的。而他这么一种说法的依据,还是惯常的“中国国情论”。或者称之为“补课论”。因为美国人是现有软件工程,才有极限编程,而我们现在的软件产业还落后人家几十年,所以不把软件工程这一课不上,是不行的。然后林老师还颇有些“攻击力”的询问Martin,当初你先写了UML,后来又写了XP,不也是这样一个心路历程吗?老马如何回答,我也没有听懂,但是在我看来,林老师混淆了三个概念,一个是国家级的软件产业的发展水平,一个是企业级的软件开发的管理水平,一个是开发人员的技术与理论水平。这三个不同的水平被他搅在一起,用于支撑自己的说法,实在是所以,会后我又追上去问林老师,我提出了三个概念混淆了云云,没想到林老师相当和蔼可亲的对我说:“嗯,你说的没错”,然后又说到关于大学的软件教育的问题,我在说很多刚毕业的学生,对于软件开发的理解,往往停留于知识点的积累上,而没有去思考,我打算把这些知识点,组合起来运用,以达到什么目的。很多学生,只是说我知道什么什么,而不会说,我会做什么什么。林老师又和蔼可亲的对我说:“嗯,你说的没错。我一直跟学生们说,学校和企业是完全不同的,真正的知识,只能在企业里才能学到。”然后我又说,其实软件学院应该多推荐学生去企业实习,还有就是多鼓励学生参与Open Source的项目呀。林老师还是和颜悦色的对我说:“是啊,不过现在的企业,要他们肯接收学生实习,不容易的。在美国,每年暑期都会有大量的实习生招聘,这其实就是企业在做慈善呀。再说现在的大学老师,对Open Source的了解,也很少的呀。”然后,我就跟林老师告辞了。作为一个老师,他给我留下了很好的印象,但是,我更加悲观的发现,要通过学校教育,提高软件开发人员的素质,好难啊!

会后大家又找了一家小饭店FB了一下,CSDN的霍泰稳也来了,我还给他们提了一个建议,以后CSDN最好能够搞一个系列的活动,不断的把世界各地的软件大师们请到中国来,巡回演讲,收取门票,整理成每年基本的《软件大师在中国》这样书出版,还有视频光盘也可以卖钱,各位大师的中文Blog也都建在CSDN,应该是一桩双赢的好事啊,就看他们是不是打算做了。

(待续)

posted @ 2006-06-20 23:05 读书、思考、生活 阅读(28430) | 评论 (6)编辑 收藏
最近一直在讨论招人的事情,如何判断一个人的水平,怎么样才算是没有bug,等等等等。也看到一些并不怎么有趣的反对意见,比如:
不要出来搞笑说:
没有bug的程序?????????
靠,站着说话不腰疼。那个公司可以做出没有bug的软件来?
当然,没有写过程序的人不出bug!!
估计这位同志不会写代码,是个理论专家。
还是不要这么狂的好。
我估摸按你的标准,你是肯定不会被别人录用的!
123说:
你是编程的吗?
无“BUG”搞笑吧你
测试是不能查出所有BUG的
而且不是所有测试都能穷举的
只能是测试覆盖率达到一个标准
BUG出现的概率达到标准
才算产品
“ZERO-BUG”做梦去吧
说实话,这两个名字我看都不是用户名,而且很可能是同一个人,就是所谓的troller。我说的没有bug,是交给我的demo没有bug,这样的要求很高吗?我还没有出算法题,要求应聘者的算法效率呢?仅仅要求一个正确实现简单功能的程序,很过分吗?
 
在JavaEye还看到另外一篇帖子《大伙能进来讨论下“跳槽”的问题》,有一个小伙子,对自己的代码有感情,对人有感情,对公司有感情,所以当公司遇到困难的时候,一时间舍不得走。这样正常的事情,居然颇遭到不少人的冷嘲热讽,和各种“善意”的劝诫。
 
我就觉得非常奇怪,一个程序员,如果对自己写的代码没有感情,怎么可能写出漂亮的代码来?同样的道理,如果一个程序员,对自己的工作质量没有追求,又怎么可能成为高水平的程序员?一个前来应聘的人,为了得到offer而写的demo,就这种情况下,在寄出代码之间都不认认真真的检查检查,这样粗心大意的家伙,我怎么敢招?
 
总而言之一句话:“对代码有感情,对质量有追求”,这是成为好程序员的基本前提。
posted @ 2006-06-18 02:23 读书、思考、生活 阅读(28041) | 评论 (14)编辑 收藏
  我写了一篇blog叫做《招人不难》,很多朋友很赞同,也有的朋友不同意我的意见,他们很怀疑:“有bug的一律不要?没有BUG的代码是不存在的...blabla”
 
  正好今天又看到一篇转贴的笑话,叫做《【转】从一个笑话看软件开发管理》,大意是,程序员交出了自以为没有bug的代码,然后一切都变得越来越糟糕,而程序员总是会交出自以为没有bug的代码。
 
  我们今天就来谈谈,一个程序员,什么时候可以交出自己的代码,并且可以自豪的对别人说:“我的代码里面,没有bug!”。
 
  先说传统的做法,一个负责的程序员,应该在交出代码之前,自己跑好多次自己的代码,左看右看,上看下看。直到交出去的时候,没有一个人能够发现其中的问题。这样的能力一般只有天才才能具备,我以前遇到过一个。但是,如果我企图以这样的标准来招人的话,那就是在发疯,怎么还敢说“招人不难”?
 
  说说可行的办法吧。一个程序员如果足够的谦虚,时时想证明自己可能犯错,即将犯错,或者已经犯错。那么他就会尽量写出足够多的TestCase,以便打消自己的疑虑。直到所有的测试用例全部通过,屏幕上显示出美丽的绿色长条,他才能确信,自己的代码没有bug。
 
  所以,我的判断标准,也很简单。如果寄给我的代码,没有附带测试用例,我就自己运行他的程序,随意的乱找,找到一个我认为是bug的,那就是有bug了。如果寄给我的代码,附带了足够的测试用例,我只要Run一次,看到绿条,这一关就算是过了。~~~很简单吧。
 
  也许有人会说,那如果他的测试用例很简单呢?岂不是不能说明什么问题?怎么不能说明问题呢?首先可以说明:这是一个会写测试用例的程序员!其次,我会看看他的测试用例的代码,大概覆盖了多少的功能特性。当然,这是更进一步的能力判断。但是至少,他的代码已经达成了他自己的设计了呀。
 
  所以:“有bug的一律不要”,意味着,你最好能够自己证明自己没有bug,否则,我如果找到一个bug,你就没戏了。
posted @ 2006-06-11 10:34 读书、思考、生活 阅读(29256) | 评论 (10)编辑 收藏
  孟老师最近有点烦,面试了一个刚毕业大学生,结果发现那家伙一问三不知。随后的跟帖也是常见的感叹:
  “现在的大学生过于浮躁”
  “真不明白本科都在学什么”
  还有一位台湾同胞说:“本來還以為只有在台灣有這種情形,原來兩岸的情都相同。”
 
  因此,打算写这篇blog,介绍一下我是怎么招人的。其实,招人并不难。
 
  1、写招聘广告
  2、收简历,初步了解背景情况,然后让加我的MSN
  3、在MSN里,就问一个问题:以下几种技术,你哪一种最熟悉,哪一种最不熟悉
  4、你就用最不熟悉的那种技术,做一个demo给我,没有时间限制,要求如下:
    -首先是demo的质量,一定不能有任何bug
    -其次是代码的质量,要干净,明白,好懂。
    -要有创意
    -在功能创意与时间进度之间,自行平衡
  5、拿到代码之后,先看看能不能正常运行,看看有没有bug。
  6、在Google里搜索代码的关键段落,看看有没有抄袭,或者了解一下借鉴的程度
  7、看他的代码,是不是足够干净,足够合理,足够朴素
  8、如果一个人能够在很短的时间里,自行快速学习一种新的技术,并交出足够质量的代码。这样的员工,我就准备要了。至于面试,无非是谈谈工资的高低意向罢了。
 
  这样的招人办法,要点在于:
  1、我不关心他的学历,工作经验,年龄和技术背景,因为招到一个出色的员工,他会持续的自我学习,不断的进步。
  2、有bug的一律不要
  3、代码最能够说明问题,其他一切判断都要在我看过他的代码之后。一个人,不要玩弄聪明,不要炫耀技巧,写老老实实,干干净净的代码,合理的贴切的变量命名、方法命名、类命名,合理而不多不少的类间关系。这样的代码,就是漂亮的代码。能写出这样的代码的人,就有足够好的思维和品性。
  4、快速学习的能力要比过去的工作经验更加重要,因为那么多工作经验,也要有助于完成今后的工作,才能体现出价值。
  5、不抄袭,有创意,这样的人才很难得。
  6、有计划的实现功能,能够在功能和时间进度之间合理决断。这就是有大局观的人才。
 
  当然,这样招人的基础是,你自己的代码水平要够高。很多公司根本就没有这样的水平,只能靠笔试来判断人家的水平。
 
  我工作过的公司,曾经有一个小伙,他的代码,缩进不是靠Tab,而是“按下空格键,任代码随意后退”,他的代码,弯弯曲曲,难看至极。前两天,他跟我说“我笔试得了90多分,当场拿到了4.5K的Offer。”可见,笔试是毫无意义的测试手段。
 
btw:还有问题,这样招人效率不是很高,也比较累,紧急招人的情况不适用。当然,紧急招人的项目,通常肯定是搞不好的。
posted @ 2006-05-30 16:11 读书、思考、生活 阅读(28959) | 评论 (36)编辑 收藏
  大多数程序员,都极度痛恨写文档。Coding是愉快的,而Write是痛苦的。有一部分原因,其实是要归咎于程序员自身,以我的经验,很多程序员往往会“艰于表达”,尤其是用“文字、图表、PPT、Word”之类的Office Document来表达。当然,还有一部分原因,是由于很多项目开发实践中,文档的前后矛盾、形式主义、反复修改、歧义重重,常常让程序员们抓狂。
 
  UML是一个比较好的工具,但是,仅仅靠UML,是无法将项目的知识描述清楚的。也有不少项目组在引入了UML之后发现,文档的工作量不但没有减少,而是更多了。随着项目的进展,需要维护的设计文档数量,也更多了。也因此造成了更多的前后矛盾,形式主义,反复修改。
 
  根本的痛苦,并不在于一开始写一份文档,而在于所有写下的文档,都必须跟随项目的进展而随之变化。当我们写出来的文档越多,需要被持续维护的文档也就越多,需要反复检查文档间的可能存在的矛盾也就越多,所有扔出去的石头,最后都会落回到自己头上。
 
  于是,还有不少项目组,将文档工作与代码工作截然分开,文档就写一次,用来应付上面的管理层,而代码自管自的继续开发。对于小型项目来说,这其实是一个不错的权宜之计。但是一旦项目越来越庞大、复杂。所有的隐性的知识,都仅仅存在于程序员的脑子里,所有成文的东西,都可能是错的,而真实的情况,却隐藏在代码之中。如果代码质量再糟糕一些,后来维护的朋友,就遭遇火坑了。
 
  文档,写还是不写,这是一个问题!
 
  还记得测试驱动开发吗?为自己的每一个方法,每一个类,都写出单元测试来。不但如此,更加彻底的做法是,在写代码之前,先写测试用例。这样才能保证不会忘记写测试用例。更大的好处在于,这样有助于思考、有助于获得更加完善的设计,有助于写出更加高质量的代码,有助于安全的重构,有助于自动化的持续集成实践。总之,是好得不能再好的一项开发实践。
 
  这一实践之所以可行,就在于他将繁杂的集中的测试工作,分解为日常的,必须不断进行的工作。当你每天都在写测试用例,当你的每一个测试用例,都能够与代码完全对应时,压力反而减轻了,工作量也更少了,更重要的,一些优良的习惯也因此被养成了。
 
  在两年前,我要开始一个全新的P2P网络电视项目时,也在考虑关于文档的问题。当时我发现了Open Source的WikiPedia。这是一个PHP的WIKI,最大的应用是维基百科全书。因此,这个项目的质量就绝对值得信赖。我就将它拿过来,作为我们项目文档管理的工具。
 
  用Wiki来管理项目文档,基于以下一些考虑:

文档是项目的知识,这些知识必须集中管理、容易获取、人人可以编辑。

项目在生长,代码在增加,文档也必须能够跟随项目自然生长,强行划分设计阶段和开发阶段,是不可取的。

Wiki不是传统的项目文档,而是一个应交流需要,可能随时增删改的知识库。项目组的成员,遇到问题,就应该首先查看Wiki,如果这是Wiki中没有,那么他应该找人询问。而那个知道答案的人,如果他不想再今后不断的回答同一问题,就应该把这个答案写入Wiki,这就是Wiki条目增长的自然动力。

传统文档最大的问题在于浪费,而Wiki通过持续修改,按需提供的方式,保证了所有写下的文字,一定有超过一个人需要读它。

 
  在Wikipedia的基础上,我又做了一些增强,以更好的辅助项目的管理。

Include功能,增加include标签,可以在一个条目中,引入其他条目的全文,而不是仅仅增加一个link。

文档的层次结构,当项目的文档条目逐渐增加,分门别类的条目,更加便于查找,也可以有效的避免条目重名的问题。

一个Click,就能够创建新一个条目,用于填写当天的工作安排。

  相应的管理制度,也必须建立起来。

每日15分钟文档制度,基于“填写当日工作”的功能,我规定每个项目组成员,每天要花三个5分钟来写文档,早上的5分钟,填写当日工作计划。中午的5分钟填写上午的工作情况,下班前的5分钟,填写下午的工作情况。这样,每天的文档工作相当轻松,但是文档能够保证持续的跟随项目成长下去。更进一步的,这样的制度,对于项目的进度控制,也很有帮助。

User Case条目驱动,所有分解出去的User Case,在分配到责任人之后,该责任人的第一项工作,就是在Wiki中写下对于这个User Case的理解。随后项目进展,也应该持续的维护这个条目。

同时进行Bug的管理,Bug也作为Wiki中的条目,以便于和其他条目项目引用。

每次Check In CVS时,必须写注释。这是更加细节的文档,然后我还做了一个小程序,能够自动的从CVSTrac中读出当天Check In代码的注释。供每个人在写当天文档的时候引用。

  总而言之,我对于项目文档的看法,并不是非此即彼的极端主义者。在我看来,好的项目文档管理政策,应该有助于集中团队知识和智慧,同时不要让程序员痛苦和反感。这样才叫做有效的项目管理。仿造Martin Fowler的著名文献《持续集成》,我给这篇Blog起这样一个名字《软件开发文档的持续集成》,希望能够引发更多的、更深入的思考。
posted @ 2006-05-12 14:23 读书、思考、生活 阅读(28625) | 评论 (3)编辑 收藏
<2006年5月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

常用链接

留言簿(20)

随笔档案

友情BLOG

搜索

  •  

最新评论

阅读排行榜

评论排行榜