一直有朋友发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 读书、思考、生活 阅读(108271) |
评论 (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 读书、思考、生活 阅读(28428) |
评论 (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 读书、思考、生活 阅读(28957) |
评论 (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) |
编辑 收藏 我新到这家公司，就开始了一场死亡之旅，我们的项目开发周期是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 读书、思考、生活 阅读(29544) |
评论 (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 读书、思考、生活 阅读(29934) |
评论 (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 读书、思考、生活 阅读(30173) |
评论 (9) |
编辑 收藏决定不再玩连载的把戏了，总共就这么点文字，还不如一口气放出来算了。
这是以前写的书的初稿，后来因为打算全部推翻重写，所以将过去写的内容，作为Open Doc放出。
欢迎下载： AJAX——新手快车道
posted @
2006-03-27 22:39 读书、思考、生活 阅读(6217) |
评论 (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 读书、思考、生活 阅读(3152) |
评论 (16) |
编辑 收藏本来拿到的是一个20多M的MP3文件，还好找到一个工具，转了一下。还是微软的格式牛啊。
下载地址：
posted @
2006-03-22 15:55 读书、思考、生活 阅读(3199) |
评论 (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 读书、思考、生活 阅读(5625) |
评论 (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 读书、思考、生活 阅读(2969) |
评论 (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 读书、思考、生活 阅读(1807) |
评论 (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 读书、思考、生活 阅读(1869) |
评论 (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 读书、思考、生活 阅读(942) |
评论 (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 读书、思考、生活 阅读(4690) |
评论 (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 读书、思考、生活 阅读(1493) |
评论 (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 读书、思考、生活 阅读(1553) |
评论 (0) |
编辑 收藏