MoDoFo.println(”

jdepend使用起来还是比较容易的,但是report分析,以及背后的一些事情还是要弄明白的.否则report就真的成了只是report而没有任何实际价值.
使用jdepend的目的
分析包的依赖情况是否满足面向对象的依赖原则.其实面向对象,设计模式变出那么多花样最后无非就是要解决依赖的问题.但很多情况下,我们用了技巧却忘了为什么用,最后便的为了技巧而技巧,为了设计而设计,而忽略了最终目的.
也许这种感觉只有在深刻的体会过”混乱”之后才能理解吧.
如何分析jdepend的report
Abstractness – 抽象度,该包中抽象类所占的比例
Afferent coupling(Ca) – 被依赖度,有的翻译成传入耦合.我觉得传入耦合不是很清楚,很容易让人理解反了.指依赖该包的其他包的总数. 这个值越高说明他应该要么是公用包,要么是抽象(接口)包
Efferent coupling(Ce) – 依从度,有的翻译是传出耦合.指该包依赖于其他包的个数.通常越高表明依赖其他包越严重,如果这个包不是实现包,并不意味着ce就越大越好.依从度应该在一个合理的范围.同时依从的包应该是stable的.
Instability(I) – 不稳定性.公式 ce/(ce+ca).即依从度在所有依赖中的比例.还比较好理解,如果是完全抽象包(ca=N,ce=0),I=0,如果是完全具体实现包(ca=0,ce=N),I=1.
Distance – 指该包和理想情况的最大差距.这个有点绕.举个例子,如果一个包的A=1,也就是完全抽象的.那么他的I应该是=0的,但如果不是(也即是他还要依赖其他更抽象的包).那么distance=Instability-0(理想值).而如果一个包的A=0,即该包完全是实现,那么他的I应该是1,那么distance = 1(理想值)-Instability
而如果0<A<1,那么就不知道他的I的理想值是什么了.这个时候理想值应该是A,distance=|A+I-1|.
参考资料1

N97总是会无法解锁,发生最多的是在连接电脑之后,有时就是莫名其妙的无法解锁.
只能拔电池.今天通过网络和自己的摸索总算解决了.
解决方法:
使用键盘输入112(没错,这个号码是紧急呼叫)然后点[呼出]键. bingo!!
不过在我的n97上,这种情况出现以后,侧面的解锁键就失效了,必须要重启.

虽然只读过大前研一两本”无足轻重”的书,offcourse和M型社会.但却要承认,他的书以后还是要经常读的.除了主题以外,还有作者的分析方法和思考方法也是很值得品味和学习的.还有就是大跨度的知识穿梭,从全球化到企业营销策略,到政治结构改革,到区域经济,到生活质量的提高,爽!刚开始看的时候觉得怎么好像都在说日本的问题吗,跟我有什么关系??可是越看越发现这就是将来的中国,比如人口结构的老龄化,正在日益凸显的中产阶级问题,区域经济发展,公民化教育,市场活跃度开放度.
“我从25岁起在美国这个竞争社会待了37年,实在很想把那里的严酷告诉现在的年轻人.我之所以不只在日本出书,还在全球出书,巡回演讲,是因为我认为只有把自己放逐到批判的漩涡中,以”不能输”的精神奋战,才能持续磨练自己.一个国家如果没有几十人甚至几百人承受得住这样的锻炼的话,实在很难赢得世界的尊重”

可以说是良心发现吧!
在外的这10年里,我花在兄弟姐妹上的时间可以说是太少了,很多都是一年才能见一次,一次最多几个小时.而很多时候这种短暂的相处又包含很多其他的意义.真正的沟通,恐怕是零.以至于元旦时候见到家琪也找不到什么共同话题.可能确实是久别情疏.
这10年的奔波里,我无时无刻不想有一位兄长可以时时关心,教导我,指导我少犯错误,少走弯路.可是我却没意识到自己也是别人的兄长,也当承担起兄长的责任.每每以工作忙碌为由,可是工作真的比亲情都重要? 决定不是! 那只是我用来逃避兄长责任的借口罢了.
这10年经历让我见识到了很多,也更清楚的看到了自己以及家庭(其他都不重要).我想说的是”格局”.很多时候,我们意识不到自身生长环境的局限性,(或者意识到而满足也罢,这个我就不讨论了)我经常看到的是一些”世家”子弟的那种后天的优越感,这种感觉在我所见的香港人中尤为明显.所谓”世家”不一定有多显赫有钱,而是那种家族式的互相提携和共同进步.这种感觉至少我没有体会过,在我看来就是”格局”,我们所处的环境太”小”了.这个小体现在:小地方相对安逸的生活环境北方人的恋家情节中国传统的对父母的依赖
三重因素,影响到我们对外界的缺乏敏感.没办法,我们的父母所处的年代决定了一些思想情况的有限.再加上我们的家族本身就是刚刚起步,很多东西都需要家族式的积累.我不希望,一个家族最后走的越来越缺乏凝聚力,最终没有什么积淀.如果我们这一茬走到那种地步,那父辈”从农村互相提携跑出来”的积淀就彻底没有了.我们几个又是从头再来.
我的期望:1.亲情,并懂得表达 2.上进,可以体现在很多方面,未必一定是学习3.开放乐观的心态4.保持对外界的敏感5.独立思考,这一点是最好重要的,如果能够保持独立思考,很多问题就不至于任由别人影响.
兄弟共勉!

MTJ(eclipseme)中使用s60的模拟器时,启动会报错:Jar file could not be initialized.(invalid entry compressed size)

解决方法:1.在[Run]->[Run Configuration]中MIDlet页的Executable选择JAD URL,填入相应jad文件的路径,如:D:\workspaces\MoFire.jad
2.Emulation页中的,Extra Emulator Parameters中填入:-Xdescriptor:D:/workspaces/MoFire.jad
出处:http://discussion.forum.nokia.com/forum/showthread.php?t=117158

很早时候在高玮的msn空间上看到一篇关于蝙蝠的文章,已经不记得是原创还是转载了.但是却记得当时自己心里的感受 – 我们都是蝙蝠.发现自己总是处在各类”种群”的边缘…想要成为主流的,但最终成了另类,即便表面上是,内心也总是格格不入.也许这就是我们之所以那么有默契的原因吧,总能有点相似的感触.虽然现在大家各忙各的,很少联络了.
其实成为”蝙蝠”也未尝不好,至少可以保持内心的独立.有时候孤芳自赏也是很有意思的事情.跟着内心的那只蝙蝠,也许真的可以达到”程序员里球踢得最好,踢球的里程序写的最好”的境界.蝙蝠仍然是那只蝙蝠,只是价值观变化了.
这么多年来,我们这些蝙蝠,总想跑出来,目的是能够成为有成就的”异类” – 因为呆在小地方是搞不出什么名堂的,如今,小地方的那些孩子们搞的有声有色,可是我们这些”异类”却也还没有什么成就.好的么,继续奋斗不放弃,不太好的,干脆和小地方一刀两断 – “以后俺们是大城市里的了”.每个人的追求本就没有什么绝对的好坏,只是噪音永远都存在,看你的抗噪音能力了.
写给我们这些蝙蝠们

见到最近有人又在谈高考改革，然后各种＂有见地＂的评论家开始侃侃，历数各种方法的不是，以及政府的不作为。原来的我思路应该也是这样的。
可是这种改革真的是一蹴而就，而且是非要政府来牵头的吗？看来中国人真的是被奴役习惯了-事情都交给主子来决定。
也许每个人都能对自己和社会负责任一点而不是报着不关己或默默忍受的态度，那么各种不合理的东西自然会从内部烂掉。
Powered by MoFire

Powered by MoFire

转自：http://bbs.bianews.com/thread-69395-1-1.html
        MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工 程师团队开发产品时使用。         在硅谷的一些软件公司，MRD仅仅覆盖high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD（产品需求文档）来 定义更加详细的产品需求。        在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。       写好MRD的10种技巧1、从用户角度的编写        从用户角度编写需求内容。使用“用例(Use Case)”和“用户角色（User Personas）”来达到这个。考虑用以下两种方法来详细说明你们公司正在开发的SFA（sales force automation）软件的“Login”的功能性。       方法A：       用户通过一个要求用户提供证书的登陆界面，然后软件允许用户带着特定的权限进入系统。软件鉴别这些证书，在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。       方法B：        Mike是一个销售经理，Cathy是一个销售代表。当他们打开软件，他们看到登陆界面。他们通过用户名和密码进入系统。如果用户名和密码是正确 的，他们能登进系统。一旦登陆进系统，Mike能访问软件所有的功能部件。Cathy只能访问那些对销售代表有有效的功能部件。        哪个方法更加容易阅读和理解?就我的看法,毫无疑问，”方法B”。还有，它同时减少了令人烦恼的阅读！2、使用Screen Shots
        使用Screen Shots或者mockup来你的想法。我们中很多人都听说过“一张图片好比一千个文字”。当提到写MRD的时候，一个screen shot好比一千个文字！        举个例子,看看下面这个screen shot，你需要多少字来描述？我想可能不只一千个字。3、用简单的语言编写        在我超过11年的行业中，我通常注意到的（更多是令我懊恼）一件事是用很做作的语言来写的MRD。我想这个主要是因为MRD听起来是正式的和专业的原因吧。        相反，想象你写的MRD是写给你的在工程师团队工作的朋友。你的目标是帮助他理解你需要什么，以便于他能开发产品实现这些需要。这个将有助于你避开陷入那些令读者人厌烦（有时他们会把MRD撕碎然后再碎片喂给碎纸机）的用做作的语言的陷阱。        还有：        a)保持简短的语句，把长的语句分解成多个小的语句。        b)避免大篇幅的连续文本，把他们分解成多个小的章节。        c)把大块文本内容分解成，screen shots，表格、重点列表等等。4、小心的使用模板
  [...]

转自 http://bbs.bianews.com/thread-69395-1-1.html
BRD　　Business Requirements Document，商业需求文档。这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。
　　商业需求文档重点放在定义项目的商业需求。BRD要能说出客户碰到的一个或多个商业问题，并且通过公司的产品能够解决这些问题。接着建议一个方案 —— 通常是新产品或者现有产品的改进来解决这些问题。BRD也可能包括一个高级的商业案例，例如收益预测，市场竞争分析和销售/营销策略。BRD通常是由拥有 产品经理，产品营销经理或者行业分析师头衔的人撰写的。在小公司，可能由高级主管或者甚至创始人撰写。BRD通常是一份连续的1-3页Word文档，或者 不超过10页的Powerpoint文档。MRD　　Market Requirements Document，市场需求文档。获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目 的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。　　市场需求文档（MRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与BRD指出商业问题和解决这些问题的解决方案不同，MRD更深入提议解决方案的细节。它包括一些或者所有这些细节：            a. 解决商业问题所需要的特色            b. 市场竞争分析            c. 功能和非功能需求            d. 特色/需求的优先级            e. 用例　　MRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的。MRD通常是一份连续的5-25页Word文档，或者正如之后描述那样在一些机构中甚至更长。PRD　　Product Requirements Document，产品需求文档。进步一细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大 块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有 UI/UE支持，出高保真的demo，开发将来可以直接用的那种。　　产品需求文档（PRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与MRD侧重于从市场需要角度看需求的不同，PRD侧重于从产 品本身角度看待需求。通常在特点和功能需求上更深入细节，并也可能包括屏幕截图和用户界面流程。在那些MRD不包括具体需求和用例的机构中，PRD就包含 这些具体内容。PRD通常是由拥有产品经理，行业分析师或者产品分析师头衔的人撰写的。PRD通常是一份连续的20-50页Word文档，或者针对复杂产 品甚至更长。　　提醒：一些机构将这里描述的MRD和PRD合并成一个文档，并称最后的文档为MRD。在这种情况下，MRD包括本段描述的内容，也包括上一段描述PRD的内容，并且可能超过50页。FSD　　Functional Specifications Document，功能详细说明。有一点像“概要设计”，这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。相应的，有很多内容，比如表结构设计，要由项目经理来编写了。　　功能规格文档（FSD）把焦点集中在实现，定义产品功能需求的全部细节。FSD可能通过一张张的截屏和一条条功能点来定义产品规格。这是一份可以直接 让工程师创建产品的文档。与MRD和PRD侧重于以市场需要和产品角度看需求不同，FSD把重点放在了以表格形式定义产品细节，再让工程师实现这些细节。 FSD也可能包括完整的屏幕截图和UI设计细节。FSD通常是由拥有产品分析师，工程领导或者项目经理头衔的人撰写的 – 作者通常属于工程部门。通常一个连续几十页的Word或类似文档。