利用winrar自动备份重要资料

看到这个，发现很有用的文章，对于定期备份项目文件很方便。

每个人的电脑上都有很多有价值的资料，例如你写的论文、Outlook中的信件、IE收藏夹、FeedDemon中的rss链接等等，经常备份的重要性自不用多说，但怎样让备份变为轻松简单而不是繁重的劳动呢，我在网上查找了很多备份工具，发现它们要么很贵，要么存在各种缺陷（如不使用通用的压缩格式），后来发现其实只使用winrar就完全可以完成这个任务，而大部分人的电脑上都有这个压缩软件。

打开winrar的帮助主题，你会发现在winrar的命令行模式里可以指定很多参数，其格式为：

*WinRAR <command> -<switch1> -<switchN> <archive> <files> <@listfiles> <path_to_extract\> *

利用winrar可以从列表文件中读取要压缩的文件/文件夹这个功能，我们可以创建一个列表文件如C:\backup.txt，在这个文件里写入需要备份的文件/文件夹路径，格式很简单，每个路径一行即可。然后创建一个快捷方式（或批处理文件），其命令为：

*"C:\Program Files\WinRAR\WinRAR.exe" a C:\backup.rar @C:\backup.txt *

要进行备份的时候只要执行这个命令即可，这样会在C:\生成备份后的压缩文件，你最好把它转移到其他存储装置上。配合windows的计划任务，还可以进行定时自动备份。你还可以指定其他参数，例如加上-ibck可以让备份在后台执行，加上-t可以在压缩完成后验证等等，具体请参考winrar帮助主题。

这个方法的缺点是你必须自己找出那些需要备份的信息，有一些软件把信息存在注册表里不好备份，所以你可能需要在使用这种方式备份的同时手动备份注册表。不过很多专门用于备份的工具也是没有这个功能的。

以前帖子里说过用Winrar自动备份资料的方法，我现在平均每周备份两次，备份的内容包括日程（Rainlendar）、RSS频道（Rssowl）、Eclipse里的项目、常用IP设置、Outlook Express内容等等，压缩下来大约150M左右，其中主要是（带附件的）信件和项目文件占了大部分空间。

今天发现Eclipse里的一个CVS设置给搞错了，连接的是旧的CVS服务器，我在Eclipse里把服务器的地址改过来再进行Update操作，结果把我之后做的几处修改都覆盖了。还好我昨天晚上刚做了备份，这几天的工作没有白费。

类似这样的意外事件很难预料，事先做好充足的预防工作让我们有备无患，而付出的只是每周几分钟的时间，利当然远远大于弊。

关于Winrar备份我又总结了几条经验：首先可以设计两个备份任务，一个是全面备份，一个是快速备份，一些体积比较大又不是特别重要的不需要经常备份，平时每天进行快速备份，每周或每月全面备份一次就可以了；其次，在命令行里加上-ag参数可以让备份得到的压缩包文件名自动包含当前日期，从而不会覆盖掉以前的备份，该参数还可以指定日期格式，如YYYY-MM-DD等；另外，用-ms参数可以不对已经被压缩过的文件再次压缩，而是直接存放；最后，用-x命令可以排除一些我们不希望备份的文件，比如*.jar文件，一般都可以下载得到。我现在用的备份命令如下，其中backup-q.txt的内容是要备份文件的列表，得到的压缩包名像BAK20050223.rar这样：

"C:\Program Files\WinRAR\WinRAR.exe" a -agYYYYMMDD -ms -x.jar -ep2 -ibck -t c:\backup\BAK.rar @c:\backup\backup-q.txt *
这里要提醒一下，备份的文件最好定期转移到本地硬盘以外的存储地点，比如刻成光盘保存，还是不要过于相信硬盘了。

我自己的Script如下：

O:\Eclipse\Achive\backup.txt
O:\Eclipse\Workspace\Level2Demo
O:\Eclipse\Workspace\StructDemo
O:\Eclipse\Achive\do.bat
"C:\Program Files\WinRAR\WinRAR.exe" a -agYYYYMMDD -ms -x*.jar -ep2 -ibck -t O:\Eclipse\Achive\Workspace.rar @O:\Eclipse\Achive\backup.txt
cmd

安装Together for Eclipse 7.0

去这里下载Together Edithion for Eclipse 7.0，这个是官方的，要注册个用户名才可以下载。大家通过其它渠道获取也可以，但要确定是7.0的。
安装很容易，有安装向导。不过要注意它只能工作于Eclipse 3.0.x，比如3.0.2，不支持3.1final的。
很容易找到的shock的破解在Windows XP下不起作用。如果大家也使用XP，请使用附件里面的ROR的给.net版做的破解，这个也可以用，而且是唯一可用的。
使用的时候先运行一遍Together（一定要使用Together安装目录下的TogetherEC.exe运行），它提示你注册的时候退出。然后运行keygen.jar（双击就可以），然后选择你安装Together目录下的license下面的ttec.slip，然后破解完成了，运行Together就可以进去了。
界面大家自己适应一下，应该容易上手，不过画图的那个palette是自动隐藏的，你用鼠标点击就可以展开（以前因为不知道以为破解没有成功，走了很多弯路，我很笨 __）由于Together默认使用自己的Perspective，所以如果和其它版本的Eclipse共享Workspace也许会报错，需要换回Perspective才可以。

入手的Meizu E5和另一个Meizu ME的对比评价

新E5 EF3（2005年6月29日）

ME V7 EDH（2005年4月8日）

首先说说备受关注的FM能力：

两个都自动搜好了台，我使用了最常听的91.5Mhz的CRI。

这个时候正在放音乐，当时放的是陈亦迅的你的背包，然后是Killing me softly by the song。

使用了A、B切换的方式，使用的耳机是森海的MX500，基本上10秒钟换插一次，体会两者的区别。

说实话，区别太明显了。我一直认为我的E5的FM效果很漂（轻飘飘），感觉像隔着一个房间听歌，本以为Meizu的Mp3都是这个样子，但是对比以后发现ME的声音明显听感好多！当然，不能吹嘘ME有多好，应该说它和E5的风格不一样，ME感觉声音比较近，听着质感好一些。而E5则比较明显的虚一些，闷闷的，声音比较干瘪，或者说就是被压瘪了的感觉。其实以前我就发现E5放FM的这个问题了，因为基本上每天听CRI的Easy start of the Day，里面是直播节目，主持人的声音在E5里面非常明显的换了个声音，对比的对象是我的得声9701收音机，不夸张的说主持人的声音好像是套了个口罩，或者说就像抵挡随身听里面的开了Bass以后那种奇怪的效果，所以，我后来使用E5的时候都把FM的EQ里面的Bass调到最低了。

说到这里，我觉得E5和ME的声音的区别应该和E5新添加的FM EQ有关。而后我又作了试验，调节了E5的FM EQ到不同的组合（还好高低音都只有3格，所以没有太多组合），发现听现场的节目把Bass关掉效果会清晰一些（否则浑浊），但是听平常的FM播放的音乐的时候还是把高低音都放在3格的位置才能达到比较好的效果（质感改善一点）。这么说，我感觉E5的FM EQ有点失败，没有改善效果，反而拖了后腿！

仔细听了ME对比E5（把EQ高低音都放到3格）的效果，E5有差距，听起来明显的空和瘪，但是这也是夸张说了（毕竟是对比测试，对比很明显），因为E5的FM毕竟还是很清晰的（但是解析度绝对不如ME），所以如果量化打分：如果我的9701收音机是95分，那么ME可以达到90分，而E5也可以算80分。

比较有趣的是，我手里正好有个歌美M25 256MB的Mp3，这个也是基于Sigmatel 3520方案的（好像FM方案也一样？），所以对比了一下。呵呵，不过真的听了两下就放弃了，因为M25听CRI还时不时会出现沙沙的声音（信号不灵敏），声音听起来闷闷的（比E5还闷很多），而且低音比较差，和前两者基本没有什么可比性。

最后，关于FM，还要说一下能搜索到的电台：

对比了，比较可喜的是，发现E5搜索到的电台居然更多，不过可能和E5艘台时使用了线控（天线长了）有关。还有，回忆一下，当初换掉那个老E5与我的新E5能搜索的台一样多，也许原来那台老E5没什么大问题:D

列出两个搜索出的电台：

新E5能收到13个：87.6-88.7-90.0-91.5-96.6-97.4-100.6-101.8-102.0（空台）-102.5-103.9106.1-107.3

ME能收到10个：87.6-88.7-90.0-91.5-96.6-97.4-100.6-102.5-103.9-106.1

下面先说说ME和E5的Mp3表现的区别：

说实话，我真的没有听出什么区别，因为似乎两者的表现是一样的，包括使用Turebass、WOW、SRS这样添加大量味精以后两者真的听不出什么区别。但是这里说一下Meizu这两个产品的风格，声音非常清晰，解析度感觉很好，听感很舒服，缺点是声音有一点点空，低音部分量感和空气感都不错，但是低音缺乏点磁性，也就是它造成了声音的发空。感觉这是Sigmatel解决方案的固有缺点，能够被Meizu解决成现在的状态的确很满足了，所以我才买了E5。所以，看来Meizu的确需要换个方案了。还记得以前用的Rio800，声音听感特别好，虽然实际上解析度等指标都并不很高，希望Meizu能够实现个有特点的声音，而不只是现在这样只通过EQ提升音质（这也是不可能的，EQ只改善听感）。

关于录音的效果，由于我不太关心，所以就不评述了。说实话我从来没用它录过音。

到了这里，我觉得不得不说一下换E5的经过。我是北京的，打电话问到去四通大厦换。带裸机过去的，当时还有个老兄在换128MB的E5。听说512MB的货挺多，拿出来一个给我换。我摆弄了一下，没发现新的滚轮有什么区别，仔细看了下发现第一个机器电池盖松。然后又拿了一个出来，发现屏幕没膜花了，又拿了一个，发现滚轮嘎吱嘎吱的，又拿了一个，发现屏幕上面一条一条的不均匀，又拿了一个，发现基本差不多，但是膜上有气泡，随后又要她拿了一个，发现这个屏幕特别的淡，然后又要她拿一个，发现这个电池盖口不齐，此时她那个袋子里面还有两个，我就让她都拿出来看看，发现又是一个屏幕特别淡的（每看是不是对比度设置太低了，难道出厂设置不一样？不过听一些网友说这个与对比度无关），还有一个转轮特别松，所以最终拿了那个差不多但是膜上有泡的。我考，我真贫，想起来都头疼。不过回去才发现，电池盖松很正常，因为没放电池就松，放上电池就好了。

最后，还要说个问题，服务人员很好，他们提供备份数据的服务，把我的数据备份下来考到新E5里面了，感觉很不错嘛。可是……回家后发现染毒……，用Norton奋战半天……，病毒名字叫W32.Meetot，还好只是个自我复制的东西（刚拿回来以为是Meizu送的新的程序呢，后来才发现那个Sysnote.exe是病毒）。你说表扬好呢，还是批评？备份数据太好了，但是希望下次先杀毒，否则成了传染媒体了，哈哈。

最后作个几句话综合：

1、  感觉E5的FM效果不如ME，怀疑和新增的FM EQ有关。

2、  新E5的搜台的灵敏度没有任何问题

3、  新E5的FM 效果可以满足在户外使用，室内还是用收音机好

4、  E5的电池寿命很棒，我经常忘记关机，第二天才发现，电力依然强劲

5、  E5的Mp3效果很满意，在家里在户外都可以满足要求

6、  新E5的质量个体差异很大，也许是仅这批赶制比较仓促

7、  我对E5比较满意，打个8分吧

总的来说，Mp3还是在户外使用吧，在家里还是用音响或者电脑音质更佳。而在户外E5和ME或者牛一些的iriver系列、iPod、Sony HD5那些区别也不会太大了，而且E5的电池续航能力基本超过任何锂电解决方案了，所以我选择了E5。

贴图明天在上。后面有时间我还想说说E5的随机播放的问题，有时间的话。我个人热爱硬件，喜欢在Q3ACN的雷神硬派混迹，声卡等都感兴趣，所以才花时间写写E5的这点感受，抛砖引玉。

我的Space：http://spaces.msn.com/members/iamtin

UML建模工具浅度分析

1、Rose
这个工具我不多说，它应该是最权威的，但不一定是最适合的。但是Rose仅仅是个建模工具，无异于一个画图工具。Rose画的图风格明显，一看就知道是用的Rose。不过要使用它来管理还要结合Rational的其它工具，整体使用的话很庞大。我不多评价，因为没用过，想起被人们称为“巨大”、“资源杀手”、“经常崩溃”、“价格昂贵”我就头疼。希望同组其他同学评估一下，补全。
2、Visio
这个更不用多说了，完全就是个画图工具，而且沾染了MS的风格，不开放，完全陷在自己的小圈子里面。不过有两个别的工具不具有的优点：A、速度快、图形美观、资源占用小、界面友好、容易上手……这些都是MS Office的优点 B、剪贴板格式与MS Word兼容，非常容易嵌入到Word文档中，这个是最有用的功能！
不过可惜，对UML标准也就是睁一只眼闭一支眼，不标准不兼容，且非常不合理的不支持Java，哎，只能忍痛割爱。总之Visio只能用来玩玩，画画漂亮的画骗骗小孩。
3、Together for Eclipse 7.0 or 6.3
说起它感觉就是个痛苦。首先这个东西都是收费的，所以必须破解以后才能体验。刚装上7.0没有发现画类图的工具，抓耳挠腮呀，还是没有解决。而后试验了6.3，这个能够顺利使用，建模应该是UML1.1的东西。图形非常简单，看来法国背景的Borland并没有让它看起来很漂亮，可惜。不过Together本来是仅次于Rational的业界老二，所以东西当然很强大，支持基于模式的UML建模，不过建模以后的图看起来乱七八糟的。但这是由原因的，Together更加偏重于MDA，所以它的输出应该是代码，而不是UML图，所以这个工具面向生产，能够准确的自动生成代码，也支持逆向工程（从代码生成类图），但是图都是简陋的。而我们的这次实践还没有应用MDA这样的概念，设计只是概念指导，文档是重要的输出，所以选择Together可能会是个艰难的选择。
简而言之，Together的功能我们有90%用不到，而用到的那10%还是Together的弱项，你说怎么选择。本工具可以输出XMI，可以与其他UML工具交换。Together目前最新的版本是7.0 for EC，我再找找破解，看看能否翻案，不过希望不大。
同时还要控诉以下Together for EC，我当时用6.3花了好久画的图输出时却犯难了，因为它只支持SVG格式输出。SVG是Adobe的不怎么疼的一个儿子，是一种基于XML的矢量图像格式，类似Flash，而现在Adobe鲸吞了Macromedia以后Flash就变成Adobe的养子了，如此之下SVG这个亲儿子也失宠了，可怜。倒霉的SVG与Adobe的其它东西一样，对中文字体总有点感冒，所以用IE打开乱码，要下载SVG Viewr中文版才可以解决，但是用起来还是特别别扭。在Word里面用SVG，我目前使用illustrator转化SVG为BMP，然后再到Photoshop转化为GIF，然后再嵌入Word，这也是被逼呀，没办法……
BTW：用illustrator转换SVG叶挺麻烦，每次要删除辅助线，挺麻烦的，真的让人有心理阴影，这直接造成让我放弃Together。
4、Visual Paradigm Smart Development Enviroment 3.0 for Eclipse
这个工具获得了本年的Jolt大奖，按理说会不错。体验了一下，首先是界面画画绿绿，感觉有点像是过年贴的年画，后来打听到原来Visual Paradigm是一个香港的公司，呵呵，还是国产软件呢。相比有些花哨的界面，程序的功能真的非常强大，而且在画图的时候可以从从一个个UML对象上面直接派生关系，感觉真的是Smart。
但是缺点又来了：我们工作于Eclipse，但是SDE并不是紧密结合的。分两个部分：Visual Paradigm for UML 5.0 Community Edition、SDE 3.0 for Eclipse and IBM WebSphere Studio Community Edition。后者才是SDE，也就是与Eclipse结合的建模部分，而VP for UML5.0是个比较纯粹的建模工具，它并不与Eclipse完全结合。在使用的时候SDE的Community版本无法从代码逆向工程出UML模型，而且SDE环境无法直接输出图像格式的UML图，必须先导入VP for UML5.0以后才可以输出为其它格式。这样可能会带来一些不方便，我们将无法使用代码与模型同步的功能（如果用企业版好像可以），这是个问题。
再用简单的话说，VP分两个部分，一个是SDE与Eclipse结合，一个是VP for UML5.0纯粹建模和输出UML图，但是两者结合并不紧密。且Community版本代码同步不能用，这是个麻烦。但是总体上这个工具比较强大，理念先进，且完全支持UML2.0。本工具可以输出XMI，可以与其他UML工具交换。所以作为我们的备选方案。目前本工具只支持Eclipse 3.0.x。
5、Omondo EclipseUML Free Edition 2.1.0
这个工具用的人比较多。它更接近一个Eclipse插件，虽然它不是开源的。这个工具比较纯，可以UML2.0建模，支持代码模型同步（类似MDA的方式）。
我们依然先说缺点，这个Free版本无法支持与CVS同步的项目，靠，这真的很烦，如果去掉CVS同步就可以。
说优点：EclipseUML的逆向工程能力非产好用，你可以直接托拽工程里面的类到类图里面，这个非产贴心！如此就可以代码同步了，这对贯穿项目整个生命周期非常有意义。再有，它的UML图画的非常好看，我觉的是上面几个中最棒的！简单、颜色清淡、具有阴影效果、没有锯齿和难看的图形、所有的图标与Eclipse环境统一，这样的UML图真的是别无所求了！但是，没有完美的，目前的Free版本只能输出SVG，靠，这等于和Together一样瘸腿了，不过欣慰的是Studio版支持输出Windows Metafile、CGI、JPEG格式，哈哈，而且有20天试用，如此的话我们完全可以集中输出。再说实在不行可以截图……
EclipseUML Free和前面的UML建模工具比还有个优点，它支持Eclipse 3.1，这样的话就可以和我们的最新的Eclipse3.1+Myeclipse4.0M2环境结合起来工作了，支持逆向工程，UML2.0图很标准很漂亮，CVS支持带来的问题我们可以通过维护一个没有CVS的项目来操作。
CVS项目问题和图形输出还可以通过EclipseUML Studio Edithion来解决，不过可惜的是这个版本只支持Eclipse 3.0.x，和前面那些工具一样啦……
简单的说，EclipseUML支持逆向工程、简单、图形漂亮，支持Eclipse 3.1，方便协同工作，所以应该作为我们项目的推荐方案。

下午，又峰回路转了，对本来在待定状态的Together 7改变了看法。

先是发现以前用的破解方法没有错，而且是在Win XP里面唯一有效的方式，如果决定用，我们就可以破解它。
然后发现原来我以为Together 7没法画图，其实是个低级错误，里面的面板学习VS.net是自动隐藏的，所以我一直没有发现，今天仔细看就看到了（可能写作业的时候太紧张了）。
图好象不是UML2.0的，但是这不算个问题。
图形还是比较平淡，就是很基本的那种，也没有颜色，就是黑白的。可是隐藏在后面的是巨强大的MDA功能，支持画图自动生成代码，而且画图的时候可以使用内置的模式的模版，还可以自定义模式，很强大的。然后发现不能导出单一的图，本来觉得又要失望了……谁知山穷水尽疑无路，柳暗花明又一村，发现居然可以Export一个整体报告出来，输出的时候图像可是可以是BMP、JPG、SVG等等，并且连JavaDoc也一并生成了，还有个很酷的applet树……绝对的爽！

所以基本上Together7还是具有老二的风范的，应该推荐。而Rational系统ZH同学说还是不太稳定，且4CD的体积看了绝对受不了（谁喜欢肥girl？），so，这个老二是绝对值得考虑的！

也就是说：
现在可以考虑的是Together、VP SDE、EclipseUML。Together的类图缺写颜色，但是功能全。VP SDE大家好像都不太喜欢，花花绿绿让人……而且没什么绝招吸引人。EclipseUML的最大优点是支持Eclipse 3.1，可是Free版本没法与有CVS的项目工作，而Studio版只能用20天且不支持Eclipse 3.0.2。所以综述，目前UML工具只能在Eclipse 3.0.2下工作，能够完美注册使用，且能够提供完整解决方案的就是Together for Eclipse 7.0，所以，我最终认为它就是最值得推荐的！

最后我们画个表格来对比一下这几个建模工具：

工具名称 版本 与EC结合 UML2.0兼容 逆向工程 输出图形格式 注册 图形美观 界面友好 MDA支持 支持EC版本 支持CVS 结论
Rational Rose 2003 × × × All 必须 7/10 ? × × × ×
MS Visio 2003 Sp1 × × × All 必须 7/10 10/10 × × × ×
Together 7.0 for EC √ × √ SVG 必须 4/10 6/10 √ 3.0.x √ 推荐
VP SDE 3.0 for EC √ √ ×(注册) SVG、PNG、JPG 免费 8/10 7/10 ×(注册) 3.0.x √ 备选
EclipseUML 2.1.0 Free √ √ √ SVG(其它需要注册) 免费 9/10 8/10 √ 3.1 ×(注册) 推荐

相关连接：
http://www.borland.com/us/products/together/index.html
http://www.visual-paradigm.com/product/vpuml/productinfovpumlce.jsp
http://www.omondo.com/还有一个准备看看：
http://argouml.tigris.org/
看过了，是个纯Java实现，不能与Eclipse协同。总的来说比较一般，就是个建模工具，估计也没有Rose友好，所以不做近一部考察啦。

听来的故事——《爱的左右手》

伟和佳原来也是一对很恩爱的一对小夫妻，结婚前后那些年也是甜甜蜜蜜如胶似漆，好象谁离了开谁，就象身上少了某根筋骨一样的不自在。
但随着时间的推移，婚姻生活渐趋于平淡，又感觉彼此象白开水一样，虽然最解渴，却不如饮料那么甜那么有劲。一次在朋友的聚会上，伟喝了点酒，大声地说：现在啊，摸着老婆的手真的象左手摸右手了，一点感觉都没有了。佳站在几步之遥的厨房内听见，心中猛的一沉，但旋即恢复了常态，端出一盘切好的水果，继续招呼伟的朋友。
其实伟说这话是有所指的，并且希望听到佳的责难，那么，他就可以明明白白地向佳摊牌。但佳却不作声，象什么都不曾听到一样。伟就只好把话仍放在心里。
这几年，伟诉事业发展得很顺利，就象他的公司名称朝阳一样，蒸蒸日上，自然而然地吸引了许多异性仰慕的目光，尤其是几个月前来公司的一位营销经理静，对伟更是发起了强有力的进攻。在伟看来，静除了有姣好的容貌外，性格泼辣而大方，在工作上也很帮得上伟，而佳近年来，除了在家待奉公婆之外，对伟的公司的业务可以说是一壳不通，更谈不上帮助了。所以，伟心中的天平，不由自主地偏向了静。
就在伟准备放下所有顾虑跟佳谈离婚的事的时候，伟突然病倒了，而且来势非常迅猛，不得不住进了医院，伟只记得看到检查结果上的“急性肾衰竭“就晕了过去。醒来时看见佳躺在隔邻的病床上，一脸的疲倦。原来妻子把自己的一个肾换给了他。
两人出院后，伟回到公司，发现静已经卷走了公司所有的客户资料另起炉灶，员工也走得差不多了，公司的状况奄奄一息。伟坐在空荡办公室不禁悲从心来，不知什么时候佳走了进来，从背后抱住了伟，淡淡地说：伟，记得你有个关于爱的左右手的说法，我也自创了一个，你想不想听呢？
伟点点头，佳说：“丈夫和妻子就象左手跟右手，当右手需要帮助，不需要右手开口，左手会自动接上去，而当左手受了伤，右手也会很自然地去抚摸安慰它。因为他们虽然各自独立，但他们本来就是一个整体！”
伟握住了佳的手，这一次，他感觉是如此的温暖和柔软，这感觉一直漫延到心底……

Struts入门应该注意什么？

我认为五点最重要：
1、找一个好的IDE，因为开发Struts应用这样拥有大量XML配置工作的工程最好有一个具有代码生成的IDE。你可以选择Eclipse+Myeclipse或者Eclipse+Lomboz或者JBuilder这样的成熟IDE。
2、速食化的文章看上一两篇就可以了，主要了解一些基本结构就可以了，学习技术光靠吃方便面是肯定不够的。
3、学习Struts这样地开源框架要特别注意版本的区别，1.0 1.1 1.2的Struts都有很大区别，看文章、书都要先搞清楚版本，否则你连一个helloworld也别想搞定。现在书大部分都是1.1的，但是目前应该学习1.2，两者的区别可以参考Apache Jakarta项目的说明。
4、参考一个简单的Demo，实现CRUD操作的就可以，你需要理解一下MVC在Struts中的对应机制。
5、选择一本好书开始认真学习，例如：Manning出版的Struts in Action，OReilly出版的Programming_Jakarta_Struts，还有Jakarta Struts Live。这几本都是经典。

Java&UML，又一些牢骚

这算一种言论而以，站在Java阵营，要能够接受各种忽悠。
这里有几个概念UML&MDA、建模工具&代码生成、软件过程&设计。
MDA是否会顺利，是否要真正自动不需要人的介入没有定论，也就是说出代码是不可能没有人的，难道程序员想要谋杀程序员？
代码生成，需要，但不是全部需要，是通过模型生成这种整体解决还是局部的自动化生成更好用现在也没有定论。这就好像XML与J2EE的关系，XML很好，但是多了你觉得写他们是不是非常的累？比如Struts、Hibernate、Spring这些，哪个的XML不是写到你头疼？
软件过程这个就更不好说了，没有人说一定要自上而下的设计，很多敏捷方法都是边写代码边设计。所以关于这个问题，还是邓爷爷说的：“不管黑猫白猫，逮到耗子就是好猫！”，方法学是为你服务的，你不要被它套牢。

还有，记得哪个大师说，什么设计都是瞎掰，你最终交付的只是你的代码！设计和软件过程是为了保证代码质量的方法，但这种方法从来不唯一，开发过程、OO产生以前，还是有很多高质量的代码，所以……。
当然，不是做起义的农民，只是在想：
UML表示静态很好，那就用它表示静态。
动态，你可以用那些蹩脚的图，当然也可以通过其它的各种定势来暗示实现时的动态关系，毕竟程序员不是傻子，都有一定的悟性。
再下面，关于建模技术真的不太了解了，期待郑浩给点好的例子，还有介绍你的经验，我们很期待。
BTW：我以为是动态语言，眼花了。ZH推荐了Ruby on rails，这东西真的够震撼，绝对提升效率，同样还有Python on Zope，然后又发现Google的大量代码使用了Python（Google主要用C++、Java、Python），而Python作为胶水代码具有超级高的效率，星战3也用了Python，靠，动态语言真厉害。看看而以，现在暂时坚持Java不动摇。

Java框架学习感想——版本差异害死人

版本差异害死人。
说实话，有时怀念用MS的编程环境，都是人家制定好的，不用东那么多脑子选择用什么编程环境、用什么语言、用什么技术等等。
而入了JAVA的伙，学习J2EE，那么多的开源框架，选择就要花费很大的工夫，因为选错了以后修改起来成本可就大了。关键是框架曾出不穷，都宣传自己多么先进，哎，绝对眼花缭乱。而即使选定了框架，如果遇到版本升级，那也有可能是天翻地覆的变化，设让人家是开源的，变化从来多讲究设计精良，并不考虑那么多升级成本问题。
经常面对要学习的新框架、新技术，对于程序员来说是个挑战，很累，但是保持了你的先进性，并且多动脑子还是有益的。而版本变化，只能说学习成本好高，但是选择了Java和开源你就要接受这种高学习成本，有什么办法呢。
我只是发发牢骚，书还是要看的，UML、Paterns、Hibernate、Spring这些都是要抽时间好好看看的，这里结绳记事。
今天好不容易把上次那个Spring step by step搞定了，一直调不通的JSTL的问题原来还是个版本问题。
报错如下：
org.apache.jasper.JasperException: /jsp/hello.jsp(9,34) According to TLD or attribute directive in tag file, attribute value does not accept any expressions
意思是找不到对应的属性，属性不接受表达式。
1.1的URI是<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
1.0的URI是<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"%>
而1.0的版本不支持表达式，所以要用1.1的，而如果又正巧用了1.0的声明，那就会遇到与我一样的问题。
所以，记住修改URI为http://java.sun.com/jsp/jstl/core就好了。
版本差异，呵呵，J2SE1.4&J2SE1.5、Struts 1.1&1.2、Spring 1.1&1.2、Hibernate 2&3、Tapestry 3&4，太多了……
这是常见的对比的冤家：Linux v.s Windows 、 Java v.s .NET 、 OpenOffice.org v.s Microsoft Office System 、 PS2 v.s XBox 、 Palm v.s Windows CE 、 Symbian v.s Microsoft Smart Phone……

Something happen agin!

我的本命年……
围绕着你们……
令人发指的小偷……
我恨你们的一切……
你们有手，你们也有脑子……
但是却用它们偷窃别人……
你们偷走的不仅是财务……
是他们的努力……
是他们的美好回忆……
是他们的快乐……
但是，你们还留下……
痛苦、怀疑、失落……
我们怎么才能从中解脱？
我们怎么才能除掉你们？
我在诅咒，你们这些小偷……
生Baby没有手和脑子……
祝你们早日生Baby……
为什么再次发生？
在我的身上，在我爱的人的身上……
我恨你们……
但是我还热爱我的生命……
警察叔叔，你们应该管管这些小偷了，真的……
警察叔叔，你们应该让我们报案了，不要总是批评教育我们……
警察叔叔，我们不怕发案率高，我们怕它虚低……
警察叔叔，求你们保护我们，而不仅仅是……
警察叔叔，请不要生气，我恨小偷，我爱你们……
请不要问我小偷又对我干了什么，你们都知道小偷干了什么……
希望我的本命年不要总是因为小偷而难过……
我爱你，宝贝，没什么，我都挣钱给你卖，有我你什么都不会失去！

回复Dadou：关于.NET和java性能问题

一个很好的讨论，可以参见通告的连接……
信里面很多高手进行了分析，感觉很有意思，我也写了一点，搅一搅局，哈哈：
看了大家的讨论，我很感兴趣。下面的成绩如果是相邻的，那说明测试了两次，就是两个毫秒的差值。
讨论Java和.Net感觉比较奇怪的。一直都是J2EE和.Net的对比，这个才是门当户对，他们都是面向应用的。况且需要解决的企业程序算法的量比较小，用到这么多ArrayList其实并不常见。
废话一句，J2EE和.Net经常出现的Web应用中，这里的响应速度才决定很多，Yujie引用的那段话说得很公平，因为社区里的人都会维护自己社区的利益，没有自己人会说真话，对于他们并不需要那么多性能测试，只需要你用好，因为一个好的J2EE应用和一个差的J2EE应用型能何止相差100倍？？！！我坚持认为平台并不能决定一切，而应用的设计和实现质量才会比较强的影响性能。
然后，关于虚拟机，.Net Framwork 1.1 2.0的差距好像比较大，这个需要考虑一下，不过看Yujie的对比MS实现的虚拟机看样子不容乐观。
Balder真是让我崇拜，钻研的很深，而且解释的非常到位，我觉得没法更加深入剖析了。但是利用Native方法的东西用来和受控的代码对比，性能差距就是会很大，尤其是这个数字被放到到那么大的时候。
再提，测试中使用了256MB内存的机器，而WinXP SP1跑JVM绝对会使用大量虚拟内存，WinXP会占用18x内存（乐观情况，一般2xx），因为javaw.exe绝对会变得庞大，调用虚拟内存造成的性能损失就更加非线性了，所以，我下面的测试用了1G内存，基本上保证物理内存。然后，CPU也是个问题，尤其适用P4的时候，我不知道Mobile的里面是否支持HT，如果支持HT的JVM和.Net虚拟机的效率会受到它们被编译的时候的编译器的优化的影响，并且影响很大，所以我测试使用了AMD Athlon XP（@2083Mhz）的机器，减少一些影响。
废话说了一大堆，我下面的测试主要针对程序在JVM里面运行的一些影响因素的评估，并且从这些因素里面我们能够发现这个测试的一些不妥当之处。
Balder原始程序：
首先验证一下程序在JRE 1.5(5.0)和1.4.2里面的差别。
JRE 5.0
36657ms
36953ms
JRE 1.4.2
32531ms
34140ms
发现性能居然是1.4.2更好，个人认为也许是5.0 JVM里面对资源利用的一些优化造成的吧，5.0利用资源比较小气，嘿嘿。同时这里提出一个问题，这个测试没有考虑内存占用的问题，因为JVM和.Net虚拟机（CLR?）对物理内存的利用不一定一样的，JVM吃内存是非常有名的，所以更多物理内存带来的效率提升需要考虑进去，还有就是CPU资源的利用，他们在运行的时候到底用了多少时间片？需要用CPU占有率衡量一下，这个也是没有考虑进来的地方，都是潜在的不公平的地方。
去除掉CMovieInfo里面的Math.random()方法。
33593ms
这里random被执行了20000*4次，是最主要的调用random的地方，看来这个的影响并不大。也许是static方法放在虚拟机里面所以对性能影响不大吧。
我把Demo的removeArrayList()里面的删除的random去掉，直接每次删除第1个节点。
75609ms
74859ms
哈哈，这样其实才像个测试，这是一种最坏的情况，每次删除前面的节点，后面的节点就需要蠕动过来，程序彻底没有了random的干扰，并且测试最差情况。这样可以减少随机数产生的测试偏差，而且同时发现Yujie的程序里面random的种子是固定的，这样生成序列应该是固定的（如果是在C语言里面），这对测试不公平。
然后，再修改一下，每次删掉ArrayList的尾巴（mylist.remove(mylist.size()-1)），结果让我瞠目结舌！运行几次都是0ms！
0ms
瓦赛，我终于发现看齐来公平的测试后面隐藏的危险，因为移除的位置太重要了，我怀疑只是
移除尾巴的时候编译器和JVM都有特别的优化。
然后，继续测试一下去除尾巴前面那个（mylist.remove(mylist.size()-2)）。
16ms
也就是说不会全部优化掉，但是差距绝对是戏剧性的！如果把他们花成曲线那会是什么样子？？我觉得有时间我们可以写个用JFreeChart画一个变化的曲线图，估计很有价值。还没有完，我们可以量化一下random()和new对象CMovieInfo所花费的时间，我们保持删除尾巴的操作（mylist.remove(mylist.size()-1)），只是恢复CMovieInfo的代码到最原来的状态，也就是包含那些random()。
16ms
16ms
很稳定，原来random()即使执行了那么多次对性能造成的损失也可以忽略了。
这里插一句，我在画Wave图的时候发现毫秒不够用，想找个更小的时间单位的实现，但是发现没有，请问哪位知道除了对时间点求平均值的方法外有没有更好的表示时间的小单位？
最后BTW：如果把这个东西整理一下，发个帖子，估计会火得不得了，哈哈:D