入手的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……

回复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

做完作业,看看新技术

昨天做完了作业,所以今天是一个相对自由的日子。
GF说她喜欢看Friends,我就把十季都给她下来了,结果带动我也一块儿看,主要是想联系一下听力。很幽默,而且经常围绕Sex,呵呵,看起来挺新鲜的……
而今天的最重要的工作其实是研究一下MyEclipse等一堆新技术。
先看了一下MyEclipse 4.0 M2的一些新的支持,然后以此为起点开始学习它支持的一些新的框架。Hibernate、Struts、JSTL这些用过,只是修改了版本,所以没有更着重于发现。

不过发现对Hibernate3的支持中,MyEclipse可以自动生成SessionFactory,挺好,如果没有写服务的话用这个统一的Session管理也是很好的。
从简单到复杂吧:
1、首先看了JSF:这个东西经常听说,是Sun主推的,把界面完全面向对象化,组件化,是Web里面比较有潜力的一个框架。但是这个东西似乎发展的很慢。我发现Sun推的东西总是

比较难以迅速普及,真可怜。大家都在抱怨这个框架没有好的例子,用的人似乎不多,总是处于开发阶段,什么都不太成熟。但是看程序员介绍Java Web Creator可以直接集成开

发JSF应用,看起来不错,因为好的IDE是效率的保证。研究了一下发展趋势我就没有进一步的研究技术细节,不过了解到JSF偏向程序员的观点,面向对象特性非常好,不过我本人

倒是对这个无所谓,因为界面本来就不应该是程序员写的,界面也根本不必要面向对象。我这么说肯定很多人不同意,也许都是程序员吧:D
2、看了看Tapestry:说实话,这个东西真的是让我非常兴奋。Apache jakarta项目下面的一个框架,东西比较轻量,是一个简单清晰的MVC实现。它的Controler层比较多的依赖后

面的商业逻辑,这样的设计个人感觉会提高效率,并且队分层的清晰没有影响。如果前面用个Struts那样的重一些的框架,分层的时候经常会过度设计,后果嘛,嘿嘿,就是运行

慢维护繁琐。
我最欣赏Tapestry的地方在于它很好的解决了分工问题,它明确的将显示叫给html,而将业务代码巧妙的隐藏在html tag的属性里面,对页面代码的侵入非常的小,所以它的模版

页面都可以用Dreamweaver这样的WYSIWYG设计工具来开发。考!这可是绝对的好消息,这样美工就是美工,程序员就是程序员,不会让程序员拿着美工的页面胡乱修改造成显示效

果差强人意了(呵呵,有点偏袒美工)。程序员的逻辑方在于html绑定的配置里面,Tapestry有两种常用组件,一个是Page一个是Component,一个渲染页面一个是抽象的页面组件

,反正都是面对显示的界面,非常适合做Web方式的J2EE表现层。
另一个令人感觉舒服的地方是分散的配置,看一看典型的Tapestry配置都很简单,一个.application里面只需要配置一些程序级别的设置。而所有的页面和动作都可以分散部

署,.html和.page或者.jwc关联确定一个动作或者页面设置,同时可以调用后面的Java Bean,相互比较独立,不用集中描述部署符,可能比较适合我的思维方式吧。同时Tapestry

也支持多语言,每个页面或者组件都可以对应多种语言,可以通过.html的命名方式或者关联的properties命名来支持多语言,分开的描述还是很舒服。
还有个地方,发现Tapestry的所有后面的Action都是Abstract的,看了说明,它服务的时候会动态派生具体类运行,这样的并发多线程挺好玩,具体优略就不得而知了,但是估计

不错,要不为什么特别亮出来Show。
然后,事实上,我跑了一个Tepestry的HellowWorld,然后修改了些动态的东西,体验了一把新技术就放弃了,放弃的原因主要如下:
因为正在开发的项目用Struts,用了titles来管理布局。以前用惯了JSP:include,而Tepestry里面没有直接的布局类,现在的东西移植不过去,找了一下真的没有特别好的实现。

用了一个特别的html兼容模版结构就没法用jsp里面那些第三方插件库了,这个是个损失,有得必有失。发现Tepestry的程序做简单的项目的比较多,大一点的估计就Appfuse有了

,没有经历仔细研究,放弃了。不过看到Sitemesh这种开放的布局框架可以与Tepestry结合,弥补这方面的缺陷,Appfuse就是这么实现的。
Tepestry对我的另一个打击是刚刚出了Tepestry 4.0Beta2,而且似乎很快就可以正式版了。而现在的仅有的书Tepestry in action是对应3.0的,其他的文章和例子也都是3.0的。

去官方网站发现Tepestry 3.0和4.0的区别是很大的,开源框架从来都是这样,整数版本号一变化就别想平滑升级了,头疼头疼。我仔细看着Tepestry的官方的上手指南开发,不过

我的Myeclipse是只支持3.0的,麻烦,搞了半天,到后来的复杂的例子总是调试不好,发现都是版本冲突造成,变化太大,我又不熟悉,所以干脆就放弃了。干脆等版本稳定一些

再仔细学习吧。同时提一下Tepestry现在年轻气盛,本身很优秀,但是文档很少,中文文档更少,官方网站也提出目前Document还不完善,所以还是要等社区建立好一点,我再入

手吧。
顺便抱怨一下,Struts 1.1 to 1.2,Hibernate 2 to 3,Spring 1.1 to 1.2变化都特别大,学习资料互相冲突,原来的代码都需要比较多的修改才能部署,让新入手的人碰壁再

碰壁,没办法呀……,开源的进化就是跳跃性的。
4、看了看Appfuse。不想多说了,造就下载了,当时没有搞定。但是当初为了这个才装了Ant,才有了后来的学习……这次再挑战,我又是走了无数的弯路,一直ant install-xxx

、ant new、ant这样的运行修改,怎么都搞不定。其中引出修改Tomcat配置符,修改Mysql密码等一系列问题,不多说了。我把Tomcat自动部署从Build.xml中注释掉了,最后发现

用ant setup就可以安装了,靠,他们说明文档怎么不写清楚,我编译的是Struts+Spring+Hibernate的版本,准备对比不同版本研究一下这个程序。说实话能把它部署上真的是太

好了,本来很简单我却走了那么多弯路,可惜,不过有了这样的Demo,估计对以后的开发有帮助。其实在这之前我还花了大量时间调试Spring+Struts+Hibernate组合,在

Myeclipse里面,不过没有搞定,主要是嫌麻烦,写了一半又删掉了,然后又想写……反正耽误了不少时间,以后应该减少这样的事。
5、下载了马达加斯加、史密斯夫妇、马拉松、世界大战这几个电影,都是比价期待的,发现品质还都可以接受,呵呵,周末和她一块儿看。
6、前两天把和平之月一个系列的Mp3全部下载了,真的是很棒的世界音乐。可以去Verycd搜索和平之月,我下了2x张专辑,这是一个唱片公司的厂牌,所以专辑众多,都是亚洲风

情的。
7、升级了下我的ant,忘记说了,否则无法运行appfuse,它需要1.6.2以上的ant,最新好像是1.6.5。我发现ant.apache.org访问不了,很久以前就不行,下载真的挺麻烦的。奥

,对了,还有andromdaMDA,这个东西是个开源的MDA,对于Hibernate开发可以把数据库设计->映射->Pojo这样的过程反过来,建模->生成POJO和映射->数据库设计,也就是模型驱

动开发,有时间研究一下。
Ant可以去这里:http://mirrors.isc.org/pub/apache/ant/binaries/apache-ant-1.6.5-bin.zip
或者这里:http://www.javaresearch.org/members/jross/ant/apache-ant-1.6.2-bin.zip
8、张楚推荐了这个Video:
http://www.nytimes.com/video/src/2005/06/29/technology/highbandwidth/windowsmedia/20050629_GUEST_VIDEO_HI.asx
号称iPod flea,iPod跳蚤,很搞笑的讽刺了Apple:D
9、周日看了Jobs在斯坦福的毕业典礼上的讲话,很受感动,推荐大家Google一下看看。Jobs是Apple的传奇CEO。

解读Wave文件头结构

解读Wave,文件头解释,可以用16位编辑器UltraEdit打开,然后可以观察文件的结构。
我发现对应C语言里面的字WORD(32位),16进制文件对应2个字节(Byte),而DWORD(64位),对应4个字节。
然后顺便普及一下16进制文件的存储规律,对于WORD,先存储低位字节,然后存储高位字节,而DWORD,则先存储低两位的低位,然后是低两位的高位,然后是高两位的低位,然后是高两位的高位。
介绍一下WAVE文件的结构:
标志符(RIFF)
数据大小
格式类型("WAVE")
"fmt"
Sizeof(PCMWAVEFORMAT)
PCMWAVEFORMAT
"data"
声音数据大小
声音数据
查到C语言中对应的WAV的文件头结构如下:
Typedef struct
{
WAVEFORMAT wf;//波形格式;
WORD wBitsPerSample;//WAVE文件的采样大小;
}PCMWAVEFORMAT;
WAVEFORMAT结构定义如下:
typedef struct
{
WORD wFormatag;//编码格式,包括WAVE_FORMAT_PCM,WAVEFORMAT_ADPCM等
WORD nChannls;//声道数,单声道为1,双声道为2;
DWORD nSamplesPerSec;//采样频率;
DWORD nAvgBytesperSec;//每秒的数据量;
WORD nBlockAlign;//块对齐;
}WAVEFORMAT;
然后我们根据实际的一个文件的文件头进行对比分析,然后大家就应该明白了:
首先是一串“52 49 46 46”这个是Ascii字符“RIFF”,这部分是固定格式,表明这是一个WAVE文件头。
然后是“E4 3C 00 00”,这个是我这个WAV文件的数据大小,记住这个大小是包括头文件的一部分的,包括除了前面8个字节的所有字节,也就等于文件总字节数减去8。这是一个DWORD,我这个文件对应是15588。
然后是“57 41 56 45 66 6D 74 20”,也是Ascii字符“WAVEfmt”,这部分是固定格式。
然后是PCMWAVEFORMAT部分,可以对照一下上面的struct定义,首先就是一个WAVEFORMAT的struct。
随后是“10 00 00 00”,这是一个DWORD,对应数字16,这个对应定义中的Sizeof(PCMWAVEFORMAT),后面我们可以看到这个段内容正好是16个字节。
随后的字节是“01 00”,这是一个WORD,对应定义为编码格式“WAVE_FORMAT_PCM”,我们一般用的是这个。
随后的是“01 00”,这是一个WORD,对应数字1,表示声道数为1,这是个单声道Wav。
随后的是“22 56 00 00”,这是一个DWORD,对应数字22050,代表的是采样频率22050。
随后的是“44 AC 00 00”,这是一个DWORD,对应数字44100,代表的是每秒的数据量。
然后是“02 00”,这是一个WORD,对应数字是2,表示块对齐的内容,含义不太清楚。
然后是“10 00”,这是一个WORD,对应WAVE文件的采样大小,数值为16,采样大小为16Bits。
然后是一串“64 61 74 61”,这个是Ascii字符“data”,标示头结束,开始数据区域。
而后是数据区的开头,有一个DWORD,我这里的字符是“C0 3C 00 00”,对应的十进制数为15552,看一下前面正好可以看到,文件大小是15596,其中到“data”标志出现为止的头是40个字节,再减去这个标志的4个字节正好是15552,再往后面就是真正的Wave文件的数据体了,头文件的解析就到这里。
下面从别人的文章转述文件体的数据格式:
16位单声道:
采样一(低字节、高字节),采样二(低字节、高字节),……
16位双声道:
采样一[左声道(低字节、高字节)、右声道(低字节、高字节)],……
这样,我就明白了WAVE的文件结构了,希望大家能够从中得到帮助。

Eclipse3.1和Myeclipse 4.0M2

今天听说这两个都更新了,我就去马上下载下来试验了一下。(Eclipse是一个很好的IDE,特有超强的插件结构……,Eclipse的直接发行版本进行Java开发很好。Myeclipse是一个Eclipse插件,支持J2EE开发,整合了Struts、Hibernate支持等等,开发J2EE的非常好用的平台。)
地址如下,Eclipse Release Build: 3.1:
http://download.eclipse.org/eclipse/downloads/drops/R-3.1-200506271435/index.php
MyEclipse Enterprise Workbench 4.0 M2 for Windows 98/2000/XP (6/28/2005):
http://www.myeclipseide.com/Downloads%2Bindex-req-viewsdownload-sid-10.html刚才试验了一下,EC的界面相应速度明显变快了。Myec运行也很正常,部分图标改变了,能够正常代开以前的工程,也不许要额外的设置,一会儿看看注册是否正常,估计问题不大。
大家有时间可以来试验一下。

Lost in UML

为什么我们小组这周都没有动静呢?
原因是高级系统分析与设计的倒霉作业,哎,痛苦奋战了3天有余……
哎,不认真学习和听课还有看书就是不行,什么概念都不清楚……
我对UML的认识就是几张图,别B4我。
不过花了些时间研究UML Modeling工具:
1、Rose这个不说,ZH说体积达到2G,靠我可不愿意和这种巨无霸为伍,想起来就晕。而且听我一些Buddy说这东西比较容易死机的

2、以前用过Visio,我觉得很好用。不过一些朋友说不标准等等,而且仅限于画图,我就准备学个新的。
3、然后就学习了停很多人说的非常伟大的Borland公司的Together,而且学习了其中和时髦的Eclipse结合的Together for
Eclipse的版本……
4、然后,下载了最新的版本Together fo EC 7.0,然后找了破解,因为这个东西不注册连界面都看不到。结果伟大的Shock(一个
0Day,破解了很多Java应用)的破解居然不能Work,搜寻多方结果大家说Together for VS.NET的ROR(我们国内的骄傲,世界范围
内都受到尊敬,推荐ZH加入)的注册机可以用过来,然后破解“成功”。
5、Together for EC 7.0居然没有画图的图例……我就特别天真的用树模型建模,企图表示用力关联,结果怎么也搞不定,大约花
了我5、6小时研究,都不可能,下载了很多资料也找不到帮助,我气馁了……
6、柳暗花明,我又装了Together for EC 6.3,带破解,可以运行。一进去发现明显有图例工具的!这时候我才发现也许我用的
7.0的破解有问题,真是后悔……
7、研究Togther 6.3,先画了用例图,同时写作业前面的内容,画好了,要导出到Word,结果傻眼了,倒霉的Together居然只支持
输出.svg……
8、说起SVG,那是当初ADOBE为了和Micromedia的Flash对抗推出的一种适量图像标准,文件基于XML,架构优良……不过哪里架得
住Flash的牛势……后来基本上比较惨,境地和VRML差不多……其实最大问题还在于支持太少,连Adobe的Photoshop都不支持它…
…而我就栽在这里了,输出的.svg如何能够转成其它格式?
9、话说我也倒霉,我就妥协了。我干脆去截图……花了很久时间截图,就为了赶在上课前交作业……
10、结果很简单,这种效率下,没有按时完成作业,硬着头皮去上课了……
11、结果很幸运,宋同学和郑同学还有王庆华同学都没有完成作业,心里窃喜,嘿嘿,法不敌众呀,哈哈哈哈:D……
12、又受刺激,听了ZH同学说,原来作业里不只需要用力图,还要用例规约、类图、顺序图、写作图……我考,我当场眼冒金星险
些晕过去……
13、回家我发誓我要搞定它!这里的它指Together for EC生成的.svg文件。首先解决默认.svg中文乱码的问题(考,这么到处都
有这种问题!)。去下载了一个中文的SVG Viewer解决问题了,同时还找到另一种解决方法,就是把原来文件里的font=&oaps宋体
&oaps修改为font="SimSun",这两种法方都可以。
14、然后继续努力,发现原来ADOBE的illustrator(就是我画美事同盟LOGO那个软件)可以打开.svg的,有了它就可以转换格式了
,结果发现illustrator只能存放矢量格式……不过我们有Photoshop呢,从illustrator分离图形,然后粘贴到Photoshop,另存为
……格式转化成功了。
15、先把这些用力图搞定,然后画了顺序图、类图什么的把作业搞定了。
16、然后我觉得Together不过如此,可能比较偏向于Team的过程的解决或者说MDA的解决,它并不是最关注建模本身还有画图这个
重要功能。所以决定抛弃它。我认为下一次完全可以考虑Visio了。
17、宋同学给我推荐了一个获得Jolt大奖的建模工具,说它很有可能很牛。回去查了一下,它就是这个东西:“Smart
Development Environment最终在设计工具类总共8个提名中胜出。其竞争对手包括BM Rational Software Architect, Borland
Together Designer 2005, MagicDraw UML 9.0 和SmartDraw 2.0。”
18、关于Smart Development Environment
Smart Development Environment ( SDE ),是赢得该荣誉的UML建模工具,它是可以应用于各种IDE如Visual Studio .Net,
Eclipse/IBM WebSphere, Borland JBuilder, NetBeans/Sun One Studio, IntelliJ IDEA, Oracle JDeveloper and BEA
WebLogic Workshop上的方便易用的插件,可视化地提供统一的建模和开发环境……
http://www.umlchina.com/News/Content/200.htm
19、恩,要试验一下,搜索到这个东西是visual-paradigm开发的,官方网站在这里,我给一下下载的页面:
http://www.visual-paradigm.com/download/
20、我下载了Visual Paradigm Suite 2.0,里面包括所有需要的东西,包括一个主程序和各个IDE的插件。我下载并安装了,看起
来画画绿绿,且支持输出多种格式的图形,这个看起来不错,而且很多朋友都说很好用。
到这里这个Lost in UML就写完了,我真的是迷茫了,看了高级系统分析与设计的课件、谭火彬的UML课间、下载了基本Java UML的
书不过还没看……其实一个好的工具太重要了,在这里发一下感慨。
BTW:写这个时我键盘旁边的杯子又倒了,真是和前几天的经历一样倒霉,这次键盘没有遭殃,我的床彻底湿了……这里善意的劝
和电脑天天打交道的朋友们一定不要在键盘旁边放水杯、牛奶杯、咖啡杯、可乐杯(他们的破坏力依次增强),否则后果很严重…
…我这次是第多少次了呢?我也记不清楚了,但是真的太多次了……