随心所欲

Blog搬家了

Michael — Tue, 01 Mar 2005 11:58:00 GMT

这将是在这个站点（webuc.net/mechiland）的最后一篇blog, 新的blog搬家到

http://michael.nona.name

原有的blog已经迁移到新的blog. 本blog将不再更新，感谢各位的支持！

当微操作遇上刺蛇海

Michael — Thu, 30 Dec 2004 15:34:00 GMT

StarCraft游戏初期，神族高级玩家一般喜欢在出了一两个狂热者就带上一个农民出发，利用优秀的微操作能力很可能推倒一些心理素质不太好的Player，尤其是对付虫族的小狗，如果操作得当，两个狂热者往往可以消灭掉6~8个小狗。然而这一战略如果用过了头，比如，在刺蛇海面前，再优秀的微操作马上变得可笑。在一次国内的比赛中，我曾经看到过这样一场悲壮的比赛。

有一句话说得很对：先做正确的事，然后正确地做事。如果把大型项目比喻为刺蛇海，那么我们无论如何都不能在这样庞大的攻势面前傻乎乎的用某一两个“设计模式”、“PoEAA”或者“Core J2EE Patterns”这样的微操作。原因很简单，在业务架构尚不清晰的情况下，盲目的用小规模的技术组件来套用是愚蠢的做法。我经常听到不成熟的程序员这么在说：晤，这里可以用状态模式，嗯，那里可以用解释器模式。问问他是否真正明白业务的需求，他一脸茫然。当目标从一开始就错误的时候，再优雅的设计得到的顶多是一堆优雅的垃圾。

那么，正确的事是什么？是正确评估分析你的业务。业务架构是技术架构的基础，业务语义是技术语义存在的前提。这个问题之所以没有被得到重视，是因为我们现在做的大多数系统都还比较简单，我以前做过的项目基本上用事务脚本便可以解决，通过数据库的增删改查从而完成特定功能；在此基础之上建立了一系列技术组件，比如OA, 工作流，CMS。在分析项目的时候，将功能需求往已有的技术组件上套，然后用不太先进的技术完成了一个又一个的项目。因此我说，项目成功的保证一定不是所采用的技术，而是对业务的理解程度。

我们比较不幸。客户越来越成熟，对信息系统所能带来的生产力期望值越来越高（政府项目除外）。大量的旧的系统如电力，金融等，开始被迁移到J2EE平台。J2EE平台技术的成熟并不等同于业务的成熟，当一个系统膨胀到刺蛇海的规模时，当功能需求书堆起来一米多厚、功能错落有致、交叉相连时、就是这样也不足以描述需求时，那么技术方面的某些小小的微操作、模式就像是刺蛇海面前可怜的狂热者，潇洒却凄凉；又如同印尼海啸面前“坚固”的漂亮的海边别墅，不堪一击。在对这样大的项目进行分析的时候，业务是最重要的。将业务分析清楚才是正确的事，而不是上来就往J2EE N层模式上套。放之四海皆准的方案，往往可行性、操作性成问题。只有当业务分析清楚了，业务功能之间的联系也分析清楚了，怎么做就变成了很简单的事情：无论你怎么做，代码写的多么难看，只要完成功能，你做的事情都决不是Dirty work.

然而，业务分析也太艰难：当你面对一个具有十几个子系统、几千种交易、数百种工作流、子系统功能之间纵横交错的时候，没有业务知识和技术知识的双重修炼，这件事情无异于mission impossible. 这方面，我想才是自己需要修炼的一个方向。Raimundo同志正在进行这方面的研究，希望能够有所建树。

稍微有点高兴的是，目前我们接触到的项目大部分并不庞大，大部分都能够进行归类，比如简单的业务逻辑普通的增删改查就能完成，复杂一些的加上工作流支持；大一些的公司有能力对这些操作进行积累，称之为“技术组件”，因此某些以构件为核心的解决方案（公司）抢到了许多订单。从一段时间趋势来看，这种方式也是目前最可行的一种方式。

控制发散思维

Michael — Wed, 22 Dec 2004 09:27:00 GMT

深入开源世界的程序员的思维大多发散严重，这种发散在很多情况下是有害的。在制作一个新的产品/项目之前，很多人都会说，唔，你应该参考好的开源东西，把他直接使用。殊不知这样拿来就用伤害最大：因为自己根本没有机会仔细思考自己要做的东西是什么样子的。这就是Hibernate之所以创建EHCache的原因。在EHCache之前，已经有不少Cache实现，为什么没有直接使用？因为Hibernate自己都不知道Cache接口应该是什么样的。因此有了小小的简陋的EHCache, 正是有了这个小小的东西，其他Cache机制的集成才成为可能。因为Hibernate知道与外界集成要遵循的接口是什么。如果当初直接采用某一种Cache实现，恐怕就没有了现在灵活的Cache机制了。

（这种思维的方式同样可以推广，为什么小公司不愿意接受数额较大的融资，因为这样很容易将小公司原本不太清晰的发展观念冲垮，最后什么也不是。）

现在设计平台，发现陷入了这样一个怪圈：我总想将最新最好的开源产品集成到平台中，却忽略了Roadmap Feature的定义，也就是说，没有一个清晰的标尺来定义平台某一个版本应该包含那些特征，应该达到什么效果。这样做的后果是我陷入在一个又一个优秀的产品中，像上瘾的烟鬼拔不出来。在深邃的开源世界里，一切的一切都太又诱惑了：为了选定一种O/R映射方案，我比较了JDO的各种实现以及Hibernate，阅读了大量文档（广告？），最后还是回归到Hibernate; 为了选定一种Mock测试方案，我比较了EasyMock, jMock, 之前我从未用过Mock测试，现在我对EasyMock的机制已经相当清楚了；为了选定一种代码覆盖率工具，我比较了Clover, Jcoverage和Emma，最后选定了Jcoverage，为了选择一种IoC容器，我比较了Spring和 HiveMind，最后选定Spring, 为了选定一种Web开发框架，我重新审视并比较了SpringMVC, WebWork, Struts, Tapestry.，最后选定了Tapestry。这个过程充满了感叹，也充满了诱惑性：很多具有相关性设计精美的项目会时不时招摇的在你眼前晃来晃去，让你忍不住看下去，然后你一个下午的光阴就耗费在从Google或者TSS或者JavaLobby一个链接开始而引入的一个深渊，留下你无法弥补的4个小时的时间。看着越来越近的Release Date, 心情越来越不爽。

因此，一旦前期调研结束，程序员应当果断的将与开源的联系一举切断，专心致志的投入到实现中去，一旦发现有可能抠出新的设计的地方，不要马上就找开源的产品，请先用自己的智慧设计一个能用哪怕是破败不堪的（好的设计是重构出来的，不是吗？）东西，先将框架搭建出来，一个迭代过后，开始重构，等到这个设计基本成型了，能够运行了，然后重新获得与OS的联系，参考同类产品，进行重构或者集成。这么做的目标是控制住发散的思维，在有限的时间内拿出一个在当前状态下最好的方案与实现，没有底线的项目/产品是个毫无意义的泡泡，脆弱，除了作为夸夸的谈资，经不起明眼人的一锥子。

不跳脱衣舞

Michael — Tue, 16 Nov 2004 17:30:00 GMT

许多Blog开始沉寂下来，这应该是一件好事。目前积攒的能量大概已经释放的差不多了罢，否则我的FeedDemon上为何迟迟不见重量级的文案，只有些许简单的文档零星散落，让人感受到了这个冬季依然存有活物。当然，昨日黑今日白的娱乐圈新闻不在此列，Intel与AMD永远的口水战及其记者壁垒也不在此列，更不提永远看不到尽头的在伊拉克的美国大兵。

Blog诞生初期那一阵子引发了众多英雄的诞生。由于交流渠道的扩充，每个人的技术能力在一夜之间被暴露出来，技术圈内Blog迅速成为交流技术思维的工具，如同百晓生的兵器谱，每个人的心里对Blog的优劣有了一个明显或者隐藏的排名。然而早期的激情与自己的能力在被释放之后，Blog歇了下来。 Blogger们，如同我自己，开始担心，如果Blog很长时间没有东西更新，会不会如同被抛弃的孩子被人遗忘。巅峰到低谷的感觉很难受，于是出现了我前面Blog提到的"口水文字"，这些文字就像想引起女生注意的男孩做的恶作剧，单纯得可爱，单纯的令人心碎。

电视中，电影中时常会有脱衣的表演。我想到一个非常悲凉的比喻，技术人通过Blog表达自己思想的过程就像表演脱衣舞。每传达了一个思想就脱掉了一件衣服。思想的深度和广度表示了衣服的华丽程度，从而引起观众更多的惊叹。高明的舞者总能在一个适当的时间内将衣服脱到适当然后谢幕，引起观众的美感与期待；而不太高明的技术者往往迫不及待的在不太长的时间内将自己脱个精光，或者匆匆躲进后幕，换一件更为破烂不堪的衣服出来表演。

Martin Fowler的网站访问量巨大，他的著作遍及世界，被众多读者品读。他二十余年软件行业的积累，通过每年一两本书或者几个月一篇文章的方式释放出来，观众看到的是一个高明的舞者，一个让人追逐让人陶醉的舞者。很多事情，特别是技术上，需要太久太久的积累，过早的不适当的释放，就像《赤旗寰球记》中“亿万民主投票拳”，满天胡打但不中要害。百年的酒耐人寻味，多年的积累让人承认才有成就感，来得快的东西，去得也不慢。

最后，以我自创的一句话结束：你是否拥有让众人传唱千年的裸体？如果不是，请不要跳脱衣舞。

新发现一个blog: Mike Spille's Blog

Michael — Tue, 09 Nov 2004 09:03:00 GMT

http://www.pyrasun.com/mike/mt/

Mike Spille's Blog, 愤世疾俗，言词锋利，言之有物，让我一下子想起两个人，一个是javaeye的readonly, 一个就是raimudo. :)

封闭开发，没有想法

Michael — Wed, 27 Oct 2004 21:36:00 GMT

在封闭开发。

想法少了，山清水秀的环境，不太繁重的工作（每天工作9.5小时左右），吃穿住都算方便的居住地点，隔半个月还能回城一次，每天还有时间打保龄、健身或者游泳，还有一群认识和不认识年龄相当趣味相投而性格各异的伙伴，我想说这应该是我参加的最舒服的一次封闭开发。

由于有其他的活动分散注意力，思维的速度明显慢下来，大脑得到了休息，以前的一些症状，如眼睛痛，左脑神经痛，见不得风，身体衰弱，后背起疙瘩，睡着了大脑都在思考等各种症状，明显的到了缓解。

上周到昨天在举行篮球赛，我们平台组不负众望夺得冠军。我也是很久没有打篮球了，好歹几天的加强训练，还能勉强打满半场。昨晚上庆功，以各种名目来劝酒的来了一拨又一拨，最后大家尽兴了，摇摇晃晃到了办公室，晕晕乎乎的打了一会儿CS，实在支撑不住回宿舍睡觉了。

Gmail 1G邮箱

Michael — Thu, 21 Oct 2004 19:28:00 GMT

今天上了许久不上的Yahoo 1G邮箱，想到了一些事情。

首先是Google, 然后是Yahoo, 然后是Sina. 这个追逐的背后，真的是扩容那么简单吗？

按照普通用户的用法——我指普通的用户，是通过Email做正常的事情，而不是存贮巨大文件的，一般的用户根本用不到那么大的空间，几十兆足以，因此就可以将空间进行动态分配，你看到自己的邮箱剩余空间永远都剩下1000M - 已经使用的。纵然空间不够了，存储设备也足够廉价，随时买来就是了。

那么，这个1G邮箱真的那么诱人吗？

这么说大小只是其次的东西，Yahoo, Sina或者后续的ISP，只是在抢嚎头。那么大的空间，我想，只有Google的Gmail达到了使用这么大空间的资格。原因很简单，Google拥有世界领先的搜索技术。在Gmail的广告中，有这么一句：don't delete the email, archive it. 这句话才将大容量邮箱的精髓表达出来。往来那么多的信件，在这么大的存贮空间中，全球这么多的用户，如果没有优秀的搜索技术，1G的空间，除了空间的堆砌，实际上没有什么意义，除非你想把Email邮箱当作下载服务器。不过遗憾的是大多数邮件服务器的下载速度都不是太快，而且服务商也不会太乐意你这么干。

Blog终于正常了

Michael — Fri, 15 Oct 2004 08:18:00 GMT

前前后后，已经过去两个月了。希望不要再出问题了……

今天看了看链接统计

Michael — Thu, 15 Jul 2004 19:09:00 GMT

今天看了看Blog中的链接统计，发现一个很有趣的现象：受访问最多的Blog居然是“大话西游台词回顾”，几乎每天都有十几次点击，多的达三十多次。来源无一例外是Baidu或者Google等搜索引擎。而与此同时反馈最多的也是这个Blog。从此可以看出，大部分人对《大话西游》依然情有独钟，即便多年过后，有些台词现在读来依然令人回味无穷，特定的场合想起特定的台词，令人不禁心有戚戚。比如，“在一个月黑风高阴森恐怖的晚上我是至尊宝你是白晶晶,奇妙的爱情就从桥头上这一点火开始的”，想起电影中菩提和至尊宝的场景重现，令人捧腹，还有……算了，不说了，再次读这些台词，感觉真的不错。

客户交流

Michael — Thu, 24 Jun 2004 17:12:00 GMT

今天跟客户的监理交流的时候，我恨不得把他揪出来打一顿。

发现社会上费劲的人实在太多。所以，一开始就把谈话对象（你的客户，你的用户）的智商放到最低层次，然后再一步一步告诉他想要的东西。比如，你告诉他什么是资料归档，那么你最好做好从操作鼠标点击左右键开始的心理准备。这样做也许会伤害高智商用户（客户）的感情，但是，相信我吧，所谓隔行如隔山，你不会遇到多少聪明的客户的。