一直有朋友发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 读书、思考、生活 阅读(108266) |
评论 (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 读书、思考、生活 阅读(30200) |
评论 (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 读书、思考、生活 阅读(28424) |
评论 (6) |
编辑 收藏
最近一直在讨论招人的事情,如何判断一个人的水平,怎么样才算是没有bug,等等等等。也看到一些并不怎么有趣的反对意见,比如:
不要出来搞笑说:
没有bug的程序?????????
靠,站着说话不腰疼。那个公司可以做出没有bug的软件来?
当然,没有写过程序的人不出bug!!
估计这位同志不会写代码,是个理论专家。
还是不要这么狂的好。
我估摸按你的标准,你是肯定不会被别人录用的!
123说:
你是编程的吗?
无“BUG”搞笑吧你
测试是不能查出所有BUG的
而且不是所有测试都能穷举的
只能是测试覆盖率达到一个标准
BUG出现的概率达到标准
才算产品
“ZERO-BUG”做梦去吧
说实话,这两个名字我看都不是用户名,而且很可能是同一个人,就是所谓的troller。我说的没有bug,是交给我的demo没有bug,这样的要求很高吗?我还没有出算法题,要求应聘者的算法效率呢?仅仅要求一个正确实现简单功能的程序,很过分吗?
在JavaEye还看到另外一篇帖子《
大伙能进来讨论下“跳槽”的问题》,有一个小伙子,对自己的代码有感情,对人有感情,对公司有感情,所以当公司遇到困难的时候,一时间舍不得走。这样正常的事情,居然颇遭到不少人的冷嘲热讽,和各种“善意”的劝诫。
我就觉得非常奇怪,一个程序员,如果对自己写的代码没有感情,怎么可能写出漂亮的代码来?同样的道理,如果一个程序员,对自己的工作质量没有追求,又怎么可能成为高水平的程序员?一个前来应聘的人,为了得到offer而写的demo,就这种情况下,在寄出代码之间都不认认真真的检查检查,这样粗心大意的家伙,我怎么敢招?
总而言之一句话:“对代码有感情,对质量有追求”,这是成为好程序员的基本前提。
posted @
2006-06-18 02:23 读书、思考、生活 阅读(28038) |
评论 (14) |
编辑 收藏
我写了一篇blog叫做《
招人不难》,很多朋友很赞同,也有的朋友不同意我的意见,他们很怀疑:“有bug的一律不要?没有BUG的代码是不存在的...blabla”
正好今天又看到一篇转贴的笑话,叫做《
【转】从一个笑话看软件开发管理》,大意是,程序员交出了自以为没有bug的代码,然后一切都变得越来越糟糕,而程序员总是会交出自以为没有bug的代码。
我们今天就来谈谈,一个程序员,什么时候可以交出自己的代码,并且可以自豪的对别人说:“我的代码里面,没有bug!”。
先说传统的做法,一个负责的程序员,应该在交出代码之前,自己跑好多次自己的代码,左看右看,上看下看。直到交出去的时候,没有一个人能够发现其中的问题。这样的能力一般只有天才才能具备,我以前
遇到过一个。但是,如果我企图以这样的标准来招人的话,那就是在发疯,怎么还敢说“招人不难”?
说说可行的办法吧。一个程序员如果足够的谦虚,时时想证明自己可能犯错,即将犯错,或者已经犯错。那么他就会尽量写出足够多的TestCase,以便打消自己的疑虑。直到所有的测试用例全部通过,屏幕上显示出美丽的绿色长条,他才能确信,自己的代码没有bug。
所以,我的判断标准,也很简单。如果寄给我的代码,没有附带测试用例,我就自己运行他的程序,随意的乱找,找到一个我认为是bug的,那就是有bug了。如果寄给我的代码,附带了足够的测试用例,我只要Run一次,看到绿条,这一关就算是过了。~~~很简单吧。
也许有人会说,那如果他的测试用例很简单呢?岂不是不能说明什么问题?怎么不能说明问题呢?首先可以说明:这是一个会写测试用例的程序员!其次,我会看看他的测试用例的代码,大概覆盖了多少的功能特性。当然,这是更进一步的能力判断。但是至少,他的代码已经达成了他自己的设计了呀。
所以:“有bug的一律不要”,意味着,你最好能够自己证明自己没有bug,否则,我如果找到一个bug,你就没戏了。
posted @
2006-06-11 10:34 读书、思考、生活 阅读(29252) |
评论 (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 读书、思考、生活 阅读(28948) |
评论 (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 读书、思考、生活 阅读(28623) |
评论 (3) |
编辑 收藏
我新到这家公司,就开始了一场死亡之旅,我们的项目开发周期是3个月,人员大概有3~6个不一定。而以我的经验,我们大概要做的,是一个3~5个人年的非常复杂的创新型项目。新加盟的技术总监,是一个崇尚文档交流的“老干部”,因此,我们花了一个月的时间,在写各种各样的设计文档。真正能够用于开发的时间,是2个月。
我们这个小组的另外一位组员,也是一位经验丰富的项目经理,他崇尚的,是文档UML化描述。因此,我现在除了写文档,还要用Rational Rose画好多好多的图~~~
在他们两位来这个项目组之前,我其实已经写出了一份基本完整的User Case列表,而且和另外一位组员已经进入测试驱动的、结对编程阶段了。。。
大家可能已经看出来了,这其中的开发模式,简直就是混乱不堪。到底是文档驱动?UML驱动?用例驱动?还是测试驱动呢?
问题还不止这些,我们的大老板比较喜欢和我们一起讨论设计,甚至会和我们争论具体的某个算法。开发文档没有统一的管理,汇报机制没有明确的定义,项目需求随时都可能变动,就连到底我们这个小组会有几个人,都还是一个未知数,这样的死亡之组,不知各位有什么好的建议?
背景资料介绍完毕,抱怨结束,下面讨论正题:
文档驱动、测试驱动、用例驱动、模型驱动、特征驱动。。。。他们都要解决的是什么问题?
要回答这个问题,还真不容易。我们得问一个更加重要的问题,真正驱动项目的,究竟是什么呢?我想,应该是需求吧?
那么,这些“文档”、“测试”、“用例”、“模型”、“特征”,究竟是什么呢?对于需求的描述!我们之所以不会直接用需求来驱动项目开发,而是要借助工具,来帮助我们描述需求,就是因为口语化的需求描述是非常模糊的,充满歧义的。所以,选择什么来驱动我们的项目,其实就是要看,以上这些工具,哪一个能够更好、更准确的描述需求?
文档其实是最难准确描述需求的一种方式,如果是纯文字的文档,就更难。我们的技术总监,非常喜欢读写文档,我最近也创下了一天写47页文档的最新记录。但是,当我们开会的时候,我还是经常需要提醒我们的技术总监,麻烦他再仔细看看文档第XX页的第XX段,以及配合着另一份文档的XX小节,来确切的理解我的意思!如果没有我的解释,他就会误解我的文档。
当然,如果要写出不需要我来解释,他就能理解的文档,那么文档的工作量,将会极其惊人!我以前写过一篇blog,《Jacobson博士演讲观后感》是我对UP的创始人的极度反感的集中体现。GHawk,以及交大林老师的所谓“UP”的观点,当然不可能获得我的赞同。在GHawk的最新一篇blog:《UP & XP之争,意义何在?(续)》中,GHawk说:“唯一的问题是:“如何确保测试用例的质量”。显然,我们不能把一把不直的尺子度量出来的结果作为可靠的参考依据。怎么解决呢?“结对编程”么?嗯,这是一个不错的方式,那么最终该信赖谁呢?是Pair中的A还是B呢?或者,是Leader么?那么又是谁提出的要求呢?是老板么?还是客户?政府?法规?市场?……问题没有终结了。”
由此我可以推断,他对于XP的认识,基本上是停留在猜测的阶段。对于这篇blog的观点,我就不逐一反驳了,我的猜测是,他经历过一次失败的XP尝试,而究其原因,我猜测是因为他们那个所谓的XP Team中,没有一个人,曾经实践过一次正规的XP开发。
再来看模型驱动,这中间有一个大问题,因为需求是“问题域”的范畴,而模型,则是“解答域”的范畴,试图通过解答域的精确描述,来实现对于需求的准确描述,肯定不靠谱啊。
特征驱动,我认为FDD其实是老方法的新名词,具体的实践,可能更加接近测试、迭代式的过程。了解不过,所以我也不打算多说。
用例驱动与测试驱动,其实我认为这是一个硬币的两面,用例要尽快的翻译为测试用例,而测试用例,正是为了更加准确的表述需求用例。这是我能够想到的,驱动项目开发的,最好的方法!
posted @
2006-04-26 00:32 读书、思考、生活 阅读(29541) |
评论 (31) |
编辑 收藏
几段在脑子里盘旋了很久的话:
带一个项目,要保证项目的质量,当然要靠Team Leader的水平。那么,什么才是最重要的项目质量呢?当然是代码质量!一个软件项目,最重要的产品当然是代码!
如果这个Leader看不懂项目的代码,他只能通过要求文档的质量,来间接的控制代码的质量。一个能够看得懂代码的Leader,他就能够直接控制代码质量。而能够直接控制代码质量的Leader,对于文档的要求,会合理很多。
直接控制与间接控制,哪一个更加有效,是不言而喻的。当然,那些没有代码阅读能力的Leader,他们会更加强调文档的重要性,甚至舍本逐末,认为文档质量才是项目质量的体现。进而变态地追求文档完美,以至于浪费了程序员写代码的时间。这样的Leader,根本就不可能管好项目的。
公司往往会出于恐慌,向员工要求很多详尽的文档,主要是为了防止员工离职带来的损失。而问题在于,公司的主要努力,应该用于留住员工,而不是用于加强“善后能力”。更不是为了增强善后能力,搞得员工越发想离开这家公司。
btw:
补记一段交锋对话:
UP和Agile都是工程过程实践的总结,林德彰先生说过“UP是正楷,XP是草书。先学好了UP,才能学好XP;先学XP再学UP就会乱套。”
Agile强调的是“代码是真正有价值的东西。”这同样也是实践的结果。二位对于过程有不同的看法并不能说明孰是孰非,这只是在不同的实践内容和阶段上的总结。在过程的选用问题上,只有不断地实践才是前进的方向。
我的回答是:
林德彰的说法,是一个在校教师,典型的和稀泥的说法,我不同意。
没想到今天有一个朋友WANG回了一帖:
老林是在校教师?你应该去看一下人家在美国打拼的经验~~
我的回复是:
他在美国打拼怎么了?还有好多土生土长的美国人,也不鸟那什么UP呢?
我为什么要听一个海龟来上课呢?
这年头,海龟还不够多吗?
另外对GHawk多说一句话:让组员快速磨合的最好办法,是结对编程,而不是大家埋头写文档。
posted @
2006-04-22 21:35 读书、思考、生活 阅读(29924) |
评论 (21) |
编辑 收藏
我们现在这个公司的大老板,平时在三楼办公。但是,每天都会有几次,他会在我们的办公室里走来走去——“进行着聊胜于无的监督工作”。
我想,他大概没有听说过“XP”、“结对编程”这样的名词。
4月15日,周六,我参加了BEA上海User Group的一次活动。北京来的Charls,做了一次非常精彩的演讲。名字叫做《一个Xper的心路历程》。全场笑声不断,Charls的感染力征服了每一个人。
演讲最后提出的一个观点是:“成为一个Xper,就是成为一个合格的程序员”。要勇于暴露自己的不足,要善于沟通,要谦虚,要有计划,要……做到了这些,我们才算是“刚刚够格”。
我基本上已经被说服了……在Charls演讲结束的时候,我只想问一个小问题。因为他说,在项目组里,如果有人遇到问题,不要自己偷偷摸摸
的Google搞定,而是应该马上“举手”,看看小组里有没有人能够马上告诉你答案。这才是“勇于暴露自己的不足”。而我还想从另外一个角度问一下。
(以下对话是一个大概的回忆)
“我一直以来的工作方式是这样的,遇到问题的时候,首先Google一下,这样我不但可以找到当前这个问题的答案,还能够了解很多周边的知识,触类旁通。如果直接问人的话,问题解决,我也就不再深入了。这样是不是对于个人能力成长不太有利呀。”
Charls:“项目进度在那里,当然是马上解决问题最好。”
我:“那么我们是不是可以这么理解,XP对于项目开发的目标很有效,而对于程序员个人能力的成长目标,不是很有效?”
Charls:“我一直这么说,XP更加高级的剥削方式……”
顿时,我豁然开朗。XP的好处,从老板的角度来看,应该更多:
结对编程——最有效的相互监督机制
结对编程——最有效的内部培训机制
测试驱动开发——最有效的质量保证体系
User Story+客户现场办公——最低成本的需求收集、分析机制
每日集成——有效降低集成、测试成本
…….
从程序员的角度来说,这些“与我何干”呢?
所以,一个追求利润最大化的老板,就应该选择XP,而一个聪明的老板,不但要运用XP,还要保证8小时工作制,甚至给员工20%的
On Beach时间(来源于Gigix对于ThroughWorks的介绍)。这样才能保持员工的可持续编程能力。如果我是老板的话,我就会这么干!
那天讨论的话题中,还有一些XP没能够很好回答的问题:
比如文档。在我以前的开发实践中,我们都建立了一个Wiki,并且强制程序员每人每天就Wiki几次,以分散写文档的压力。
比如对于人员的高要求的疑问。我的理解是,XP对人员提出了很高的要求,但是同时也提供了最有效的人员培训机制(结对编程),所以,对于入职人员的要求,并不需要很高,更多的是考察一个人的沟通能力、学习能力,而不是开发的能力。
posted @
2006-04-18 06:44 读书、思考、生活 阅读(30170) |
评论 (9) |
编辑 收藏
决定不再玩连载的把戏了,总共就这么点文字,还不如一口气放出来算了。
这是以前写的书的初稿,后来因为打算全部推翻重写,所以将过去写的内容,作为Open Doc放出。
欢迎下载: AJAX——新手快车道
posted @
2006-03-27 22:39 读书、思考、生活 阅读(6216) |
评论 (24) |
编辑 收藏
这是一个Java的NIO开发框架,我在上一家公司,和现在所在的这家公司,都已经使用了这个框架。但是,开发人员始终只有他一个人。
前天他写了一篇Blog:《
目标》,对我有很大的触动。我也一直存在这样的疑虑,为什么我们要用Java开发网络应用?或者说,使用java开发的网络应用,难道注定只是一个快速原型,就像当年用VB开发桌面应用?一旦需要面对性能需求时,就得推翻过去的工作,用C/C++重新实现一遍?
现在,目标已经很明确了——“无限接近于C/C++效率的java网络框架”。这是Cindy的终极目标,而我则相当确信,我一定要为这个目标,做出贡献!现在,我已经是Cindy项目的第二名成员了
zoomq在woodpecker上写道:
每日至少抽一刻钟解答列表中初学者的问题,
每周至少抽两小时整理新学知识,用Blog/Wiki/mail将体验发表/分享出去,
每周至少抽四个小时来翻译自个儿喜爱的自由软件的文档,
每月至少抽八小时编程,推进自个儿的项目,
每年至少参加一次自由软件的活动,传播自由软件思想,发展一名“自由人”……
只要我们每个人都坚持下去……
10年!就足以改变中国软件的整体风貌!
自接触电脑以来,自由/开源软件也一直给我诸多帮助和乐趣,Linux、Python、Vim凡此种种。当我有些业余时间,有些体会和收获时,又该为自由/开源社区做何回馈呢?
我的思考是:参加一个项目,或者发起一个项目,使用一个项目并且提交反馈,宣传一个项目。不要仅仅是感叹中国开源项目的水平。如果你是一个程序员,那么,你也可以为之做点什么。
posted @
2006-03-27 13:53 读书、思考、生活 阅读(3149) |
评论 (16) |
编辑 收藏
本来拿到的是一个20多M的MP3文件,还好找到一个工具,转了一下。还是微软的格式牛啊。
下载地址:
posted @
2006-03-22 15:55 读书、思考、生活 阅读(3194) |
评论 (7) |
编辑 收藏
我有很浓厚的“地图情结”,以前我写过一篇《我的信仰地图》,最近又做了一次关于Ajax的演讲,名字叫做《Ajax技术地图》。我一直以来的观点是,世界是一个整体,在这个巨大的世界之中,任何事物、任何知识,任何观点,都有其合理、自然的位置。理解这个世界的过程,就是逐步将需要了解的各种事物,在作为整体的一个世界中,找到其位置。了解这个位置的前后左右,相互关系,相互影响。这样的理解世界的学习方式,我认为是最为有效的。所以当我在JavaEye看到关于《代码大全》的广告时,我的第一反应就是:这不是世界地图吗?
看了看他的目录,竟然有35章之多?架构、分析、设计、编程、测试、重构、面向对象、调试、规范、管理、软件质量控制、协作、优化、开发工具、注释、甚至个性、开发艺术等等等等,只要是与软件有关的,基本上他都写到了。
说实话,我当时相当的不屑......可能吗?居然有这么一个家伙,能够像当年的托马斯•阿奎那一样,以一己之力,写出《神学大全》?CSDN的网站上介绍这个Steve McConnell,在1998年的时候,被Software Development杂志的读者评为软件业最具影响力的三大人物之一,与Bill Gates、Linus Torvalds齐名。一个写书的,能和两个写代码的天才齐名?网站上的那些推荐的话,个个都是大名鼎鼎,个个都是推崇备至。作为我这样一个有逆反心里的家伙来说,直觉上就是:“会不会呀,有这么牛吗?”
当然了,我也不好多说什么,毕竟没有看过书~~~
没想到好事居然找上门来了,博文视点的魏泉是我要写的那本Ajax书的责任编辑。而《代码大全》也是他们负责出版的。那天他找到我,说是让我看看这本书的书稿……看看能不能写一篇书评。这等美差,我很爽快的就答应下来了。
一看之下,果然是很喜欢,作者的思考问题的方式,与我的方式相当的接近,都是尽可能将多种、甚至矛盾的事物,放在一个整体的环境中来理解。比如对于隐喻,用于描述软件开发的特征的各种各样的隐喻,其实各有其价值,如果能够组合运用,自然能够获得一种平衡。正如作者所说:“使用隐喻又是件说不清楚的事情(fuzzy business)。你需要适当地引申它的含义,才能从其中蕴含的深刻启发中受益。但若你过分地或者在错误的方向上引申了它的含义,它也会误导你。正如人们会误用任何强大的工具一样,你也可能误用隐喻,但它的强大的功效,还是会成为你智慧工具箱中的一个宝贵部分。”
这样的一种看法,可以说“中正平和、深具智慧”,这是我们在大多数关于软件开发的论述中,很难看到的。
再比如说,作者在第三章时给出的一个表格:三种常见的软件项目种类,及其典型的良好实践。就将软件分为商业系统、性命攸关的系统以及性命攸关的嵌入式系统。然后指出对于这三类不同的应用,在开发手段、管理强度、设计、构建、测试、部署等等方面的差别化策略。这样的分类,自然就避免了将各种开发手段,简单的对立起来比较的方法,显得更加具有说服力。
再比如说,全书给出了相当多的Check List,这样的表格,实在是大有益处,借用地图的隐喻来书,这样的CheckList,就是一个一个的定位器,它能够帮助你认清自己的位置,了解问题所属的范畴,了解应该努力的大致方向。这样的“开发工具”,真是独一无二。
这本书我目前只看了前面的5~6章,实在没有太多的发言权,不过我现在已经可以肯定,这是一本非常有价值的好书,我推荐所有没有看过的朋友去看看这本名副其实的经典之作。
说实话,天下没有免费的午餐,我这篇书评,也是属于交差之作。人家出版社把样书给你看,请你写书评,当然希望你能说些好话幸运的是,这些好话,的确都是我自己愿意说的。
posted @
2006-03-22 15:53 读书、思考、生活 阅读(5624) |
评论 (5) |
编辑 收藏
广州之行,真是匆匆又匆匆,在广州呆的时间,算上在飞机场的时间,都还不到24个小时。
个中甘苦,就不在这里说了,还是把PPT传上来吧。
之所以叫处女秀,是因为这是我第一次上台做技术演讲,但是这句话却不是我自己想到的,而是江南白衣说出来的。
PPT的标题是《Ajax技术地图》,基本上是一个纯粹空对空的理论探索,不出现一行代码。还好随后曹晓钢的演讲,同样是讲Ajax,充斥了无数的代码,相信广州的朋友们,一定爽到了。
PPT的下载地址是:
http://www.ajaxcn.org/space/start/2006-03-13/1/Ajax%E6%8A%80%E6%9C%AF%E5%9C%B0%E5%9B%BE.pps
广州游记和其他感想,就明天再补吧。
posted @
2006-03-13 22:47 读书、思考、生活 阅读(2967) |
评论 (8) |
编辑 收藏
去广州参加BEA的User Group活动。
演讲题目是:《Ajax技术地图》
副标题是:为即将到来的技术变革做好准备。
11日晚19:45起飞,22:25到达白云机场。
12日晚19:25起飞,21:20回到上海。
奇怪啊,去要2小时20分,回来只要1小时55分。顺风、逆风吗?
得抓紧时间写PPT了
posted @
2006-03-10 22:34 读书、思考、生活 阅读(1806) |
评论 (7) |
编辑 收藏
庄表伟 说:
JSVM,我觉得有一个方向可以尝试去发展,就是浏览器中的对象管理,起到一个VM的作用
dlee 说:
问题就是你敢不敢去做小白鼠,或者叫做生活在剃刀边上。对于一个严肃的项目,我做项目经理,是不会采用jsvm的。
庄表伟 说:
那为什么你就会采用prototype呢?
dlee 说:
prototype背后有强大的支持,而不是像jsvm那样只有万春华同志等很少的几个铁杆。
庄表伟 说:
为什么?你是看着哪边人多去哪边的吗?
dlee 说:
你看那些叫喊"顶"、"支持"、"牛"的人会不会贡献一行代码。你太容易非黑即白了。当然不完全是这样,不过支持能力是一个非常重要的考虑因素。
庄表伟 说:
我的意思是,JSVM,该不该用他,只能由我们看过他的代码以后,来决定?
dlee 说:
你有能力维护所有的代码吗?
庄表伟 说:
我只是用他呀,又不是要改他
dlee 说:
我的意思是说,如果你在项目中使用了Spring,Rod Johnson玩累了,明天就宣布解散这个项目。你自己独立去维护Spring的代码。你去用什么啊,它只有很少的UI组件,其中还有问题。 你不要夸口这些自己都能开发好,我两年前开发了一个比较好用的Grid,花费了一周多的时间。你自己去实现这样一个组件后再说话。
庄表伟 说:
我不是用他的UI呀,而是用他的这个框架,来组织自己的代码。
dlee 说:
你不用它的UI,有什么必要使用这个框架呢?dojo/prototype一样可以做到啊,我是认为你这样做引入了不必要的成本。况且你如何判定使用的UI库在设计理念上与jsvm完全没有冲突?
庄表伟 说:
OK,你现在已经有结论了,但是我还没有仔细看过他的代码呢,所以我现在还没有结论,等我看过以后,自然会有一个结论的。
dlee 说:
在Ajax库这方面,大部分人都跟我希望的一样,需要一个全面的解决方案。你说的jsvm专精于做某个领域,我认为是行不通的。任何运行于浏览器的js框架都应该是为UI服务的。没有实现过很多UI组件,如何检验它的这个架构设计的合理性?
庄表伟 说:
目前看来,prototype,也只是专精于基础领域的,在它之上,另有script.aculo.us、Rico、Behaviour这样的lib
dlee 说:
你喜欢摆擂台,那么就摆个擂台,大家都实现Grid组件,看看谁做得好。
庄表伟 说:
呵呵,这倒是个好办法
dlee 说:
你可以跟醒来来详细讨论,问题不是你想想得那么简单。做小白鼠也有好处,晓钢就经常偷偷练习一些自己的独门绝技。
庄表伟 说:
呵呵
dlee 说:
你可以将我跟他的冲突理解为主要在一个领域,就是我不认为解决他所说的两个问题,需要这么重的方案。而且他的解决方案从JS开发者的角度看来也不是很优雅。
庄表伟 说:
嗯,这两点,我基本上是同意的
dlee 说:
万春华同志的兴趣不在UI组件方面,这使得他偏离了浏览器JS诞生的使命。今天我跟醒来说过类似的意思。 我们的分歧不完全在技术本身上面。因为我们思考问题的思路差别很大,所以没有出现很大的交集
庄表伟 说:
嗯,我比较理解你的意思了,但是,我不是很同意...
dlee 说:
你看过他们的代码了吗?
庄表伟 说:
看了一些
dlee 说:
代码的模块程度如何?有没有可能将醒来说的一些部分完全去掉?
庄表伟 说:
哪些部分?
dlee 说:
我觉得他们如果做一些更加清晰的划分,划分出一个最小的core部分,而且像Spring那样划分成很多不同的jar,这样会更好一些。最糟的情况是要么全有要么全无
醒来 已经添加到此对话中。
dlee 说:
你既然对jsvm非常感兴趣,就和醒来先详细谈谈。我作为旁听好了。
庄表伟 说:
呵呵,好的呀
醒来 说:
好啊,我 最近刚看了jsvm的源码
庄,你觉得jsvm怎么样
庄表伟 说:
我刚开始看他的代码。说实话,我觉得他的js代码写得非常好,也很干净、清楚。因此,这样的一个人,写出这样水平的代码的人,对于js的理解,肯定是相当深入的。
醒来 说:
代码写的是真不错
庄表伟 说:
我以前曾经想当然的认为,他不了解js,只喜欢java,所以才会把js,扭曲成java的样子这样的想法,肯定是偏见。那么,在承认对方有足够的智力与经验的前提下,再来看他的代码,我觉得更不该"断然否定",说他"一无是处"。
醒来 说:
我在javaeye 上提出了我的意见,我也认为他的代码写得很不错,但是侧重点有点不合时宜。现在真是有些像java虚拟机了,基本是一个classloader + class cache 的实现
庄表伟 说:
还有这个:
a) 独立模式:standalone, 该模式下,当前页面的jsvm独立加载,不和系统中其他页面的JSVM发生关联。
b) 应用程序模式:application, 应用程序模式下的页面会除了加载jsvm以外,还将构造一个Application的环境。其他模块模式的页面会共享Application的资源。
c) 模块模式:module, 模块模式的页面必须运行在一个Application模式的页面下。该页面可以通过application框架共享资源以及访问全局变量。
d) 自动模式:auto, 页面根据环境自动选择是独立模式还是模块模式。
我觉得很有点意思
醒来 说:
从名字上来讲,jsvm倒是符合本意。但是java的成功不是只靠一个jvm的,我觉得 jdk 更关键
庄表伟 说:
现在的js库,除了jsvm,都是以一个Page为单位运行的,鲜有"Application"的概念。而VM的提出,我认为,为将来合理的Browser Object Cache Layer,提供了可能
醒来 说:
我有点怀疑,这样带来的复杂性有没有必要
庄表伟 说:
而且我还希望将来JSVM,能够更好的支持请求任务队列的管理,这样的机制,JS的语法本身提供得并不够好。还有多线程的管理,JS也没有像Java那样的,语法级的支持。
dlee 说:
我不大相信浏览器中的JS将来会被用在这样的目的
醒来 说:
其实我觉得,这些应该是浏览器提供的功能,在浏览器未发展到这个程度之前,强迫javascript畸形的实现,不一定值得
庄表伟 说:
嗯,这是问题的关键...我前面的畅想,的确是我希望将来的JS,能够支持的一部分
dlee 说:
是的,我们希望将来的JS引擎来提供这些基础设施
庄表伟 说:
现在JSVM,也许能够支持一部分,也许还不能够,所以,说不定哪天JS 2.0出来,JSVM就没有意义了
醒来 说:
所以对于jsvm的模式,应用程序模式还可以理解,模块模式很难让人明白有什么用
庄表伟 说:
这是一个思考模式的问题
假设你对于js本身不熟悉,要让你合理、自然的划分多个js文件,合理、自然的在该load的时候才去load,这就相当的费力
醒来 说:
所以我的意见就是,jsvm 希望吸引人来开发,应该要给出jsdk 差不多,一个jsvm 吸引不了人
庄表伟 说:
当然,更加正确的道路,当然是按照js的本性来做,提出某种"js loading design pattener"。但是,在经验还没有被总结成模式之前,模仿java式的代码组织,不失为一种方案
醒来 说:
load js 的模式其实现在都是 用一个同步的xmlhttprequest 去加载js,然后eval。这个 dojo 和 prototype 都有提供基础支持
庄表伟 说:
不是如何loading。而是,我现在有几百K的js文件,如何切分成合理的大小,然后在需要的时候去调用他们
醒来 说:
这个想法是对的,也是jsvm值得肯定的地方
我的主要意见是说它提供的 jsc 的形式有点鸡肋,同时缺乏简单高效的工具类,所以吸引不了开发人员。jsvm2 的代码里有 1/3 就是为了支持这个自创的jsc语法
庄表伟 说:
这是...败笔...。jsc我也不喜欢,混杂了部分js语法和部分java语法...还不如仅仅规定一个必须的头部,其他的完全采用js语法呢。还有一点我觉得是这个万兄在那里畅想,就是JSVM打算支持多种语法的设想,工作量太大了。
dlee 说:
不过万春来同志说这个可以不用
醒来 说:
所以我建议索性抛弃jsc,以万兄的javascript功力,写一部分有用的工具类,我觉得不会有人真的愿意用 var map = new HashMap(), map.put(k, v); 这样的方式写js
庄表伟 说:
对的
dlee 说:
所以我刚才说:
我觉得他们如果做一些更加清晰的划分,划分出一个最小的core部分,而且像Spring那样划分成很多不同的jar,这样会更好一些。最糟的情况是要么全有要么全无。
醒来 说:
jsc 是可以不用,但jsvm 加载了接近80k的js就为了支持jsc, 没有意义啊
庄表伟 说:
他现在是有多个js的,只是他core的部分太大了
醒来 说:
庄,如果你去看runtime.js 就知道了,jsvm2其实把jsc都预先编译了,否则效率一定太低
现在甚至还有一些观点,不要把js分得太多,因为要激发太多的http连接,反而响应性更不好。毕竟js的加载是同步的 ,这各ajax的异步核心思想有冲突。
dlee 说:
这个考虑也是很有道理的
庄表伟 说:
激发太多的http连接?还是激发太多的同步http连接?
dlee 说:
那个所谓的classloader就是向服务器请求一个包含js类的文件,然后evaluate。而且也要考虑evaluate的执行效率
醒来 说:
每一个import 就是一个http 连接。当然,jsvm 考虑到了cache
dlee 说:
对的,就是发出一个xmlhttp请求
庄表伟 说:
其实,他完全可以将自己的jsdk,做成一个jsc文件,一口气load进来
dlee 说:
不是多个连接,这个要看服务器怎么配置。其实支持http1.1的浏览器和服务器都是保持长连接
醒来 说:
jsvm的cache 也有些问题,他所谓的application模式,在不同的浏览器上实现各不相同,ie是js源码用ie的htc 技术保存的,ff 是存cookie。cookie 的容量是有限制的,所以cache 主要是针对 ie。
dlee 说:
可能是在同一个http连接上发送多个http请求,这些请求需要排队
庄表伟 说:
OK,我提一个方案,你们看是不是可以作为"最佳实践"之一:
对于多个异步请求,可以让他分次异步提交。
对于多个同步请求,应该将多个请求打包以后一次提交。
这个作为"请求队列管理"的一部分
醒来 说:
道理应该是这样,jsvm里好像没有这样的控制,import语句也没有这么智能
庄表伟 说:
其实jsvm应该这么做,比如他load一个jsc文件进来,里面的import语句可能有一堆,就应该是一口气load其他的jsc,不该再分多次了
醒来 说:
我总觉得 线程/队列 这些该是浏览器的事情,用js开发很不保险
庄表伟 说:
你看过我写的那个RSSReader的代码吗?里面就有一个请求队列的
醒来 说:
jsvm做不到,因为load的jsc里又有import 语句,这是递归的
庄表伟 说:
不是递归,是分层的
醒来 说:
要么js语言升级,要么浏览器升级,我总觉得现阶段就想让ajax完全达到替代桌面应用的程度是不可能的
庄表伟 说:
这个当然是不可能的...
醒来 说:
所以在现阶段,还是不要搞复杂了,多线程和队列能用到的地方毕竟不多
我觉得dlee强调的对的,现在需要的是组件
语言级别的东西,就让js语言和浏览器标准去慢慢支持吧
庄表伟 说:
我理解你们所认为的"轻重缓急"了。根本的观点在于:"急于将浏览器中应用,推向完全的桌面应用,并不现实"。立足于"更好的浏览器端应用",而非"尽可能像桌面应用的浏览器端应用",这么说来,当务之急自然是UI控件的完善与丰富
dlee 说:
我觉得浏览器中js诞生的使命就是改善交互和UI
醒来 说:
对,就是这个意思
dlee 说:
而且我从项目开发负责人的角度,更希望一个全面的解决方案。不是什么都需要我去做集成
庄表伟 说:
JSVM的问题,不在于他语法上像Java,而在于他的目标上像Java!
dlee 说:
也可以这样来理解
醒来 说:
ajax 里的cache 应该是去cache 数据,用来cache js代码,意义多大呢,所以jsvm太技术化了
dlee 说:
在Ajax in Action中,提出了一种独占式应用。就是像Word一样,可能每天都要用上几个小时。目前的Ajax技术,包括一些基础框架,还很难达到这个要求。所以确实需要这样一类基础架构,但是我们认为这些支持最好由浏览器和JS引擎来提供。
庄表伟 说:
看来我们已经初步达成共识了
醒来 说:
js 就是用来操作DOM的,不要让它承担太多重任,xmlhttp本来也不是 js的一部分,浏览器的扩展而以
dlee 说:
我发现现在很多人有一个通病。就跟我在那个ajax和model2框架的讨论中说的那样。毫不思考地就将一种技术或者架构用于设计意图之外的场合。其实把IFrame用于异步请求也是这个情况
醒来 说:
对jsvm 的建议就是抛弃jsc,完善它自己的面向对象架构,并提供工具类支持,这样才有可能和 dojo 有竞争。所以在国外是称为 tricks, 是有贬义的意思,但翻译成中文,变成窍门,反而有了褒义了
dlee 说:
Ajax in Action的作者称作hacky的做法,带有贬义
dlee 说:
令Ajax显得与众不同的地方不是它所使用的技术本身,而是通过使用这些技术所带来的新的交互模式。我们所习惯的传统的Web交互模型并不适合于独占式的应用,只有打破了这种交互模型,新的可能性才会慢慢浮现出来。
这是Ajax in Action的一句话,说得非常有道理。我们看到如此众多的人都对Ajax感兴趣不是偶然的。现在我们处在web app发生革命性变化的前夕
庄表伟 说:
嗯,我更关注:慢慢浮现出来的这些可能性中,哪些是正道,哪些是邪道
醒来 说:
我是觉得一定要擦亮眼睛,多从用户的角度想问题
庄表伟 说:
这是对的
posted @
2006-03-02 22:05 读书、思考、生活 阅读(1867) |
评论 (1) |
编辑 收藏
1、今天,我到新的单位去上班了,地点在张江,是一家做手机游戏的公司。从我们家这里过去,要花1.5~2个小时。还好我在搭车网上找到了一部同去张江的车,每天来回15块,很不错。
2、到这家公司,我的工作是Server端架构设计,所以我最近急需补充很多Server端架构方面的知识。所我再一次看起了《POSA 2》,又在网上订了《POSA 3》、《Java并发编程—设计原则与模式(第二版)》、《Effective Java中文版》与《Practical Java(中文版)》。这下又有得要看了。
3、3月12日,我很有可能会到广州,参加那里的BEA User Group。
初步的题目是:《Ajax技术地图》
一、 技术地图概览
初步介绍一下,要研究Ajax技术,需要了解的相关技术的范围。
二、 结构(Structure)、表现(Presentation)与行为(Behavior)
介绍正统Web标准中的三大要素。
三、 模型(Model)、视图(View)与控制(Controller)
介绍正统表现层MVC模式。
四、 思考一:浏览器端的MVC?
随着Ajax应用越来越复杂,浏览器端是否需要引入MVC模式呢?
五、 难题一:SPB与浏览器端MVC的关系
SPB与MVC之间,应该是一种什么关系,需要有一个概念上的梳理。
六、 难题二:浏览器端MVC与服务器端MVC的关系
如果在浏览器端与服务器端,都定义出MVC结构,显然存在着冲突,这样的冲突,该如何调和。
七、 思考二:Web服务器的角色演变
提出一个思路,Web Server --> Web Service,也就是在浏览器端实现MVC模式,而在服务器端,分别实现Model Service、View Serivce、Controller Service。
八、 一个三维的世界
一个地图,并非一个简单的平面,作为一个三维的世界,我们对于技术的理解,又可以分为三个层次:理论的层面、真实世界的层面以及作为整理世界一部分的层面。
九、 在真实世界中的难题
介绍一些目前Ajax应用开发中,真正存在的困难,困惑,苦恼,陷阱......
十、 思考三:对于整合世界的向往
C/S与B/S能否融为一体?
开发工具能否一站购齐?
开发效率能否更快更轻松?
十一、 难题三:Ajax的能力限制
主要谈一谈Web应用无法跨越或者目前无法跨越的一些障碍,比如网络编程;比如线程控制;比如UI表现能力等等。同时也介绍一些前沿的进展。
十二、 难题四:开发工具的功能整合
简单介绍一下目前各家IDE对于Ajax的支持。
十三、 难题五:UI控件的重用与整合
自己从头做UI,实在是太麻烦了,用人家的,又有整个的麻烦,但是从提升开发效率来说,控件化开发,又是必由之路……
十四、 畅想未来…
关于Ajax技术的一些畅想。
因为发现与曹晓钢的Topic严重撞车,所以可能还会做一些修改~~~
posted @
2006-03-01 21:58 读书、思考、生活 阅读(940) |
评论 (2) |
编辑 收藏
AJAX——新手快车道
前言
AJAX是什么?
首先、AJAX是一种很酷的技术,一旦采用了AJAX,就能让你的Web页面,你的网站,甚至连同你们公司,都变得很酷。在Web2.0的时代里,不使用一点AJAX技术的网站,就会显得很老土,很落伍。
但是,这样的理解,其实是很肤浅的。仅仅是从一个外行,从一个使用者的角度出发,来理解AJAX,就像我在本书的第一章AJAX我也行中那样,开发出很愚蠢,甚至都没有资格被称之为AJAX应用的纯IE、XMLHTTP应用。
AJAX更酷的一点在于,对于传统的Web开发人员来说,AJAX所运用的,是更加先进的,更加标准化的,更加和谐高效的,完整的Web开发技术体系。遵循这样的体系开发Web应用,能让你的开发过程变得更加轻松,也能使你们的开发团队,显得很酷。在Web2.0的时代里,还在采用过时的技术来开发Web,会显得很老土,很落伍。
AJAX的相关组成技术,每一个都已经出现了N年以上了,对这些技术的组合运用,也远远早于AJAX这个名词出现之前。所以,我真正敬佩的,并非提出
AJAX这个缩写的Jesse James Garrett。而是那些早在N年以前,就已经在探索、实践的先行者,他们始终在追求的:是更好的用户体验,以及更好的开发体验。这样的精神,才是最可宝贵的,也是最值得我们学习的。许多年过去以后,当我们再回头来看当年的这些热门技术,也许早已经变得老土,变得落伍了。在这样的历程中,哪些人会成长为高手?会成长为大师呢?就是那些永不满足,永远在追求更好的用户体验,永远在追求更好的开发体验的人!
新手如何上路
软件开发这个领域,永远都在飞速发展,大家都必须不断的学习新的知识、技能、框架、IDE、甚至新的语言。传说中的骨灰级高手们,就像传说中的大侠,任何武器、哪怕是一块木头到了他们手里,也能发挥惊人的威力,人家练了几十年的看家本领,他们随手使来,也竟然像是打娘胎里就开始练了一样。为什么?
就算不吹那么玄的,平常我们能够碰到的那些老手,在学新东西的时候,也比那些新手学得更快,理解得更深,运用得更熟练。而新手们呢?往往就会漫无头绪,焦头烂额,以一副张着茫然的大眼睛的经典表情,出现在各大论坛的新手求助区里。他们欠缺的,究竟是什么呢?为什么老手学新东西,就没遇到那么多困难呢?
泛泛地说,自然是经验上的欠缺。仔细地说来,又可以分为三个方面:
一、本质,一种技术与另一种技术之间,往往会有本质上的相通之处,当你对一种技术的理解与思考越来越深入时,学习一种新技术也会更加容易。触类旁通,举一反三的能力,就是来自于对于技术本质的追寻。
二、地图,本质上或多或少的相通,也提示着我们技术之间的相互关联,当你了解的技术越多,了解得越是深入,在你的内心,就能建立起越发清晰的技术地图。各种知识都有一个自然、合理的位置。那么当一个老手要学习一门新技术的时候,他其实并非在探索一个全新的、未知的领域,而是有很多脉络可寻,也很多已知可以帮助他们快速了解未知。
三、技巧,面对同样的未知,面对同样的难题,新手们一筹莫展,而老手们却掌握着更多的技巧和手段,帮助他们试探可能性、缩小问题的范围、迅速定位问题、不犯明显愚蠢的错误、甚至能够列举出更具命中力的搜索关键词,而这些技巧,都帮助老手在前进的道路上,更少跌倒,即使跌倒,也能更快的爬起来。
作为一本写给新手的入门书籍,我们希望展现给读者的,是一个老手如何学习新技术的过程。我们相信,这样的一个学习过程,对于新手来说,是更具有价值的。
何谓快车道
必须老老实实的承认,我吹牛了!老手虽然会比新手学习得更快一些,但是也同样会碰到麻烦,遇到障碍,感觉头痛。如果没有真正的专家的指导,我不可能如此迅速地将AJAX掌握到目前这样的程度,要真是让我自学三个月,然后就写出书来的话,那真是在骗钱了。
老手能够快速学习的另一个重要的诀窍是:认识很多牛人朋友J
如果没有李锟与赵泽欣的专家级指导与帮助,如果没有与李锟AJAX结对编程的体验,如果没有三个人在MSN上无数次的长聊,我想要在短期内建立起:
对于AJAX本质的理解;
对于整个AJAX以及相关技术地图的理解;
对于AJAX编程开发所需要的很多技巧、手段的掌握;
几乎是不可能的。
如果没有(N多需要感谢的人)的(N多方面的帮助),我们这本书,也不可能以现在这样的深度,以(N个月)内完成的速度,送到读者的面前。
希望这本书,能够对大家快速学习AJAX,有所帮助。
这是我原来写的前言,自我感觉,写得还是不错的。可惜啊,这最后几段,现在看来是用不上了。
posted @
2006-03-01 21:57 读书、思考、生活 阅读(4689) |
评论 (39) |
编辑 收藏
1、可视化,但不是直接编辑。类似于Dreamweaver,但是应该再增加一个独立的DOM Tree。任意选择一个DOM节点,就能够高亮相关的CSS规则。任意选择一个CSS规则,就能够高亮受影响的DOM节点。开发工作,是对于DOM Tree的操作+对CSS规则集的管理。而不是直接手动去拖拽页面元素。
2、智能的CSS优化。那么多CSS规则,甚至是跨页面的CSS规则,有多少是可以重用的,有多少是可以归并的,有没有可能设计出一个CSS优化算法,鼠标一个Click,一切就完美了。
3、JavaScript的Debug。基本上能够做到MyEclipse那样,就非常棒了。
4、代码智能感知。MyEclipse似乎也能做出这个效果,就是不知道准确性是多少。
5、代码重构支持。不止是JavaScript的重构,还有XHTML、CSS的重构......
6、JavaScript基础库生成。如果有这样一个Wizard,我能够选择针对的浏览器平台、版本、想要用到的功能......N多选项,然后它就帮我汇集众家之长,去掉无关的代码,在生成一个我需要的JS文件。这个世界就近乎完美了。
7、集成各种UI组件库。各种好的UI,在线Update,拿来就用。
8、UnitTest的完善支持......
差不多了,就遐想到这里吧...
posted @
2006-02-05 22:53 读书、思考、生活 阅读(1492) |
评论 (1) |
编辑 收藏
鸡年最后一篇blog,一堆乱七八糟的东西,也就不分多篇了。
一、维基百科的访问记录
- 2006年1月1日8:55湖北武汉电信修改hosts文件,使用原hosts无法访问,将145.97.39.132换成145.97.39.134能访问,速度正常.
- 2006年1月1日10:50,广东深圳,电信ADSL,通过国外代理登陆成功,否则无法登陆
- 2006年1月1日23:46山东省济南市广电修改hosts文件,用IE成功登陆.
- 2006年1月2日6:15山东潍坊市,正常连入.
- 2006年1月4日16:59,北京,教育网,需要代理.用维基提供的145.97.39.*代理访问很快.
- 2006年1月6日20:00湖南长沙.145.97.39.132、145.97.39.134均无法使用.使用144登录成功.
- 2006年1月6日20:04,武汉,中国电信ADSL,只能使用145.97.39.138或140两个维基代理;其他维基代理无法找到服务器,使用145.97.39.130代理服务器出现404页面.
- 2006年1月9日13:25,江苏常州中国电信ADSL不可直接访问(用[1] 及[2] 访问成功)
- 2006年1月11日10:04,武汉,中国电信ADSL,使用MultiProxy可流畅访问,使用tor+SocksCap32组合包不能流畅访问.
- 2006年1月11日13:44(utc+8),广州,使用[3]登陆.原站无法登陆.
- 2006年1月11日23:00河南郑州河南网通ADSL不可直接访问现在使用自由门5.5
- 2006年1月12日17:30,辽宁沈阳辽宁网通不可直接访问现在使用自由门5.5
- 2006年1月12日17:54,北京host文件不知道为什么不灵了不知道ip是不是有变化还是现在不只封锁dns了用无界6上来的
- 2006年1月12日00:16,香港PCCW可以直接访问
- 2006年1月12日3:22,成都,中国电信ADSL无法直接访问,无界浏览6.9访问成功
- 2006年1月12日10:02,吉林长春,网通ADSL,直接访问不能,通过代理服务器成功
- 2006年1月13日1:40,内蒙古联通,不能直接访问,通过无界浏览6.9访问成功
- 2006年1月13日3:20,深圳联通,不能直接访问,FreeGate5.5代理访问成功
- 2006年1月13日香港时间23:26深圳中国电信ADSL不能直接访问,使用无界6.9可以成功访问
- 2006年1月15日秦皇岛铁通adsl,可以直接访问
- 2006年1月15日23:52山东网通不可直接访问代理访问
- 2006年1月15日15:00天津网通ADSL不可直接访问现在使用自由门5.5今天搜索到一个网站大陆可以直接访问[4] ,是不是维基的网站啊,看地址像是个商业网站,还有SOHU的广告,是不是假冒网站啊,有人解释吗?
- 2006年1月15日23:34北京网通不可直接访问在爱问上找到了下面这个上来的
- 2006年1月17日0:23北京网通ADSL不能直接访问通过香港电讯盈科代理速度正常
- 2006年1月17日17:20吉林长春网通ADSL不能直接访问通过torpark代理速度非常快
- 2006年1月18日22:38福建电信ADSL不可直接访问通过代理正常
- 2006年1月19日14:02黑龙江中国电信不能直接访问通过torpark代理速度非常快
- 2006年1月23日23:01黑龙江哈尔滨市,网通,torpark代理
- 2006年1月27日16:09上海电信,代理
- 2006年1月27日23:29上海电信,Free Proxy
- 2006年1月28日16:58,青海西宁,电信ADSL上网,利用自由门正常连入,速度正常。
GFW哪怕再伟大,也不可能真正的隔断Internet......
二、最近看的几部电影
1、《一个馒头引发的血案》,狂笑类电影,非常之出色。以至于我居然兴起了想看看这部电影的原材料的心思。
2、《无极》,唯一的长处是给《馒头》一片提供了原材料。我那天看了前面30分钟,实在是看不下去了。
3、《小强历险记》,出色的构思,传奇式的拍摄,这一切在颁奖典礼那天达到了最高潮。然后事情就演变成了一出活剧,黑色得不得了。还是六哥——张立宪的总结有道理:
零诚意 零新意 零意义 零特技 零演技 零逻辑 零成本
零床戏 零打戏 零哭戏 零专业 零职业 零事业 零票房
这42个字,竟然是一字都不可改,佩服啊!
4、《金刚》,有无数的人推荐这是一部好电影,还有好多人看到最后哭出来了。我看了以后,一点都不喜欢。这不是一部人道主义的电影,而是一部“猿道主义”的电影。死了那么多的人,也没见到谁难过一下,最后死了个巨猿,倒变成“悲剧”了。荒谬!
5、《僵尸新娘》,绝对好看,创意十足,充满温情,人性的光辉由此得以体现。
三、一个域名
打算申请一个域名:www.rsslife.info
大概的意思是:Rich Smart Simple Life。具体想做什么,暂时就不透露了。
四、春节晚会
还是那么烂,而且一年比一年烂。小品和相声都没法看了。歌舞还不错。
五、原创祝福短信
狗年新春旺旺旺,
身体健康棒棒棒。
吃饭睡觉香香香,
工资收入涨涨涨。
原创短信一条,诚意拜年,庄表伟。
posted @
2006-01-28 23:43 读书、思考、生活 阅读(1082) |
评论 (1) |
编辑 收藏
结构(Structure)、表现(Presentation)、行为(Behavior),是Web开发标准中的一个重要概念(以下简称SPB)。而模型(Model)、视图(View)、控制器(Controller)的MVC模式呢,是图形界面应用的重要模式之一,自然也广泛的用在了Web应用的开发之中。
最近热门起来的Ajax技术,又刺激了人们对于MVC模式的更多思考。本文的很多观点得到了jasonhsu的一篇论文《基于递归MVC结构的Web应用软件分析模式》的启发,特此感谢。
现在我们要考虑技术范畴:SPB、MVC与Ajax之间的相互关系,或者说,在采用Ajax技术的Web应用中,SPB与MVC之间,应该是怎样的一种关系。
左边是一个标准的SPB模型,结构通过CSS渲染之后,显示给用户。JavaScript可以通过DOM API以及DOM Event与结构交互。
右边则是我将JavaScript部分放大之后的情况。
大致上,我们写一个稍微复杂一些的Ajax应用的时候,JavaScript部分,就应该一分为三。一部分是用来做DOM与Style控制。另一部分则专心与Server打交道,通常就是用XMLHTTP了,然后将获取的数据,在浏览器中构建一个Model层。再一部分就是表现层的业务逻辑,主要需要处理各种Event,做出正确的反馈。
这样的三个部分,顺理成章的,也就成了Browser中的MVC了。
写完这点东西之后,我再次看了一下jasonhsu的文章,以及Ajax in Action中的第四章《The page as an application》,发现我的思路似乎与Ajax in Action中的思路几乎完全一致,而与jasonhsu的有所差别。
虽然人家已经说了,不过我毕竟是自己想通了这一层的,嘿嘿。
posted @
2006-01-26 23:52 读书、思考、生活|
编辑 收藏
“吃药”是一句上海话,就类似于“被晃掂”的意思。
大家先看看这段代码:
<div id="a">
</div>
<script type="text/javascript">
var node=document.createElement("div");
node.setAttribute("class","test");
var tn=document.createTextNode("Test1");
node.appendChild(tn);
var a=document.getElementById("a");
a.appendChild(node);
</script>
它在FireFox里能够正确运行,一个class为test的div,被正确的显示出来了。但是在IE里面,死活就是不行。
后来我才知道,不能用setAttribute,而是得用setAttributeNode。
<div id="a">
</div>
<script type="text/javascript">
var node=document.createElement("div");
var attr=document.createAttribute("class");
attr.value="test";
node.setAttributeNode(attr);
var tn=document.createTextNode("Test1");
node.appendChild(tn);
var a=document.getElementById("a");
a.appendChild(node);
</script>
犀牛书里是这么说的:“通常,用setAttribute()方法,比用setAttributeNode()简单。但是,要为XML文档定义一个性质包含实体引用的性质时,应该使用setAttributeNode()方法。”
什么叫XML文档呀?什么叫性质包含实体引用的性质呀?反正我在IE里,搞搞HTML文档,就是出不来,用了setAttributeNode,就成功了。
所以,我“吃了犀牛书的药”了。
posted @
2006-01-25 01:23 读书、思考、生活 阅读(809) |
评论 (0) |
编辑 收藏
一个初步的想法,先简单说一下。
1、最初的图形用户界面,都是代码堆出来的,用代码来画界面,用代码来响应事件,用代码来处理事件。
2、OO风潮一起,GUI的框架自然也要跟进,基于控件的
GUI开发,大行其道。
4、基于控件的开发,封装细节,因此也各自独立。大家通过消息机制来沟通。这样就导致有一部分逻辑是被封装在控件内部,另一部分则散布在控件“四周”。
5、
DHTML->
AJAX->
XUL这样的发展思路,显示了另外一种开发GUI应用的可能性。结构与表现分离,要修改界面效果,自然是修改CSS来得方便。结构与行为分离,自然能够对所有的“动作部分”集中思考。
个人认为,后一种GUI应用开发的架构模式,是更加合理的。
posted @
2006-01-22 11:25 读书、思考、生活 阅读(1552) |
评论 (0) |
编辑 收藏