n97无法解锁的问题解决

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

不过在我的n97上,这种情况出现以后,侧面的解锁键就失效了,必须要重启.

[转载]互联网公司的PM(产品经理)该如何写文档

原文地址

互联网公司的PM(产品经理)该如何写文档

作 为互联网公司的PM(产品经理),我们需要面对众多部门,因为自己就是项链里的那根线。需要书写各种文档,最常见的就是PRD(产品需求文档),当然根据 重量级和时间等多因素,可以提交不同类别的,例如DRD(设计需求文档)和ERD(工程需求文档)。嘿嘿,DRD和ERD是我自己发明的。更多小的ECR 级别项目中,文档大家写的都很自由。

  今天晚上在跟工程师讨论中,得到了一些启发,摘录部分。

  给工程师看的文档
  1 工程师喜欢看结构化文档,不喜欢看描述性文档。
  描述性文档也要给工程师看,并且最好亲口说,因为这对理解产品策略和发展方向有帮助,工程师可以帮助PM弥补没考虑到的地方

  2 工程师喜欢流程图甚于Mockup,而Mockup是给领导给Marketing等成员看最合适;
  并不绝对,初级工程师反倒喜欢mockup,而高级工程师经验多了两者没区别

  3 Mockup是画大饼,产生食欲,争取资源和获得理解的方式。“有照片的菜单永远比只列菜名的菜单受欢迎”,这是马总说过的;
  Mockup务必不要过于精细,否则累的是PM,领导和其他团队会一开始就进入细节盘问阶段,不利于表述产品目的和大的功能模块

  4 工程师更喜欢菜谱,而且是西式菜谱。做一道菜需要几分钟,几滴色拉油,烤炉温度和时间,需要哪些工序,前后顺序和量化归纳。
  这个并不绝对,聪明的工程师不喜欢菜谱,不喜欢纯粹编码。有些时候不妨像做中国菜一样,给对方发挥余地。只是碰上好搭档的概率不多,更多情况下菜谱更保险

   5 软件工程是西方的泊来物,标准化文档非常重要。很多老外PM希望达到一种境界,进行完详尽的分析和文档后,开发人员按部就班就行了。中国人做菜喜欢个性发 挥,油盐酱醋通常都需要自己拿捏,菜谱上多“少许、半勺、少量”等描述性词语。有时候PM也希望工程师这样做菜,我们想吃甜味,但放多少克糖是需要厨师自 己揣摩。

  6 自己揣摩有利有弊,好处是PM省心,坏处是项目不可控。如果从风险角度考虑,软件工程中的过程改进及文档管理是受欢迎的。

  给界面设计师看的文档

  除了工程师,那么UI设计师的DRD(设计需求文档)又该怎样拿捏?

  MS Office的Visio在PM中比较受欢迎,对于那种没有FW和PS操作经验的PM来说就更重要了。当然你也可以使用Word,但Word在画框图方面可视为不专业,对于入门级PM或者轻量级设计框图也适用。

  对Word下了这么个定论,非常惭愧。工具是死的,人是活的,高级PM也能做到拈花折枝即可杀人的境界

   根据我的经验,如果项目一旦正式启动,PM最好不要采用Photoshop或者Fireworks等软件自己来做设计。那样会让自己陷入细节,总想着跟 UED去PK设计技巧,做了自己不该做的事。因为Visio已经将模块做成控件,所以自己不需要拉框线,做精细的按钮。

  对于界面设计,除了正常的界面文案外,其他辅助性文字尽量使用一整块的灰块表示,PM不要陷入按钮和字体设计中。PM的眼睛应该像眺望远方一样,看到的只是起伏的群山轮廓,至于山上长的树是什么颜色,相信UED。

   倘若PM有空余时间,而且项目并非公司会投入UE资源去做的,还处于idea阶段。那么自己不妨用PS或FW做些精细设计。毕竟在立项前,PPT中配上 能看上的图,会增色很多,也更有说服力。让每个人头脑中不会出现1000个想象的产品,可以统一起来。至于精细到多细,要自己把握,这很花费时间的。一个 半成品的Demo专业UED也需要2-3个工作日,拿业余时间设计是不可能精细到那种地步。如果非要有个衡量标准,那就是图层尽量控制在100个以内,不 要使用需鼠标贝赛尔曲线效果,少用染色效果,不用滤镜。

  给UED的设计稿,参考纸媒在版排前的草图,那种黑白框线,文字用灰色细条代替。有空我再思考总结如何具体把握。如下图:




名词解释:
RD:Research and Development,在这里是指研发人员,就是公司的工程师
Mockup:图样,原型图,在这里的意思是初始设计图
UED:User Experience Designer ,用户体验设计。

概要设计应该包括哪些内容

转自:http://learnsoftwareprocesses.com/2007/09/20/high-level-design-document-template/

The High Level Design Document is a pretty important document for a project, covering at a high level the overall design of the solution. If one were to try and present a very succinct summary of the High Level Document, it could be something like this:
– Detailed use case scenarios of key process flows of the application
– The class model and relationships
– The sequence diagrams which outline key use case scenarios
– The data/object model with relational table design
– User interface style and design

High-level design is the transitional step between WHAT [requirements for sub-systems] the system does,
and HOW [architecture and interfaces] the system will be implemented to meet the system requirements.
This process includes the decomposition of system requirements into alternative project architectures and
 then the evaluation of these project architectures for optimum performance, functionality, cost, and other issues
[technical and non-technical]. Stakeholder involvement is critical for this activity. In this step,
internal and external interfaces are identified along with the needed industry standards.
These interfaces are then managed throughout the development process.

Some examples of a High Level Document available at these links:
Link 1, Link 2, Link 3, Link 4

对Java技术面试非常有用的几本书

Effective Java – 2002年的Jolt大奖,详细讲解了57个平时 不大会深入了解而又非常重要的知识点。作者Joshua Bloch还有一本类似的书 – Java Puzzlers
Effective Enterprise Java – Effective Java的姊妹篇,专注于企业级Java应用的各种蹊跷和最佳实践。
Bitter Java – 从负面学习,在教训和犯错中成长。作者列举了大量的反模式来挑战我们那些被动接受的先入为主。
高质量Java程序设计:2003年的一本书,作者是几个国内的程序员。模仿Effective Java的组织形式,通过35个条款,讲解了一些在实际工作中经常会忽视的问题。
SCEA study guide – 考试用书,如果可能遇到面试=笔试的情况,当然还可以把其他的study guide都拿出来看看。
各种specification,直接到JCP找相应的JSR:

针对特定的工具和领域:推荐 in action 系列,比如hibernate in action, spring in action, lucene in action …

Writing a Good Thesis

Software testing课上觉得最有用的居然是最后一个slide – Writing a Good Thesis

  • Introduction, explaining the target of the study
  • Motivation of the study, such as problems in current methodologies
  • Background or related work
  • Theory with mathematical proofs or sketches of rationales
  • Algorithms with descriptions
  • Implementations
  • Real-life applications
  • Evaluations such as complexity analysis, case studies, experiments, and comparison with results from related work
  • Discussions, including alternative strategies or approaches, and threads to validity
  • Conclusion and future work

SUCCESS story

昨天参加的一个seminar关于金融海啸背景下的就业。是来自ETI的Victor Ng主持的,讲的不多主要还是大家交流,认识了几个朋友。
其中Victor讲到的关于SUCCESS story(“成功”故事)觉得很有启发。

Strategic – 策略,其实就是中心,主题。比如奥巴马的”change”
Unique – 独一无二的,不应该是每个人都有的经历
clear – 清晰,要求表达清楚
concrete – 可靠,真实
exciting – 有趣,可以吸引别人的兴趣
short – 简短,要在1分钟左右讲完
skill-oriented – 技术导向,我觉得这个是可选可不选。视乎故事的内容决定。

其实之前面试的时候有过类似的经历,当时可能表达的不够清楚,也有可能选取的故事不好。看来这些也是要准备的。其实会讲故事的人才有魅力~这倒是真的。

香港到深圳机场

把自己的搜罗到的一些信息和一些亲身经历,总结一下从香港到深圳机场的若干种走法。

1.新界 – 罗湖 – 330大巴
凡是东铁线可以覆盖到的范围都可以考虑走这条路线,乘东铁到罗湖,过关,乘小巴,或者地铁到科学馆乘330大巴。
优点:时间相对稳定
缺点:上上下下比较麻烦,时间长。乘小巴通常用时50分钟,但是一定要注意小偷,尤其是行李拿的比较多的时候很容易被盯上。由于小巴要在市区拉人,有可能会遇到堵车。所以总用时的变数会大一点。推荐还是坐330。
返程:直接到罗湖,比较方便
总用时:2小时~3小时
后注:据说在罗湖也可以坐330,只是要走到火车站那边的330下客站。之后直接坐到华联大厦的总站。为什么我之前就没想过呢?

2.九龙、九龙塘、旺角,上环,湾仔直达巴士
每隔半小时发一班(九龙机铁(中港直通车)站是15分,45分出发),上去睡一觉就到了,从深圳湾口岸(西部通道)过关。我只坐过九龙的中港直通车。
优点:省事,不用上下折腾
缺点:和乘地铁通过罗湖过境比要贵一点(100hk$)
返程:深圳机场一出来就可以看到中港直通车柜台,基本也是半小时一班,半点,整点出发,但是通常会晚10几分钟把人装满。参考
总用时:1小时20分钟左右

3.上环信德中心乘渡轮通过蛇口过境
到深圳蛇口的渡轮只有早上9点一班,然后可以在蛇口乘机场10线到机场(半小时一班)
优点:时间比较短,渡轮50分钟,大巴约30分钟
缺点:时间不灵活,只有一班
返程:不知道
总用时:轮渡50分钟,从蛇口打车或者乘机场10号线(约50分钟)

4.跨境巴士从落马洲过境,然后机场9线到机场
在油尖、荃湾、湾仔、太子…都有往皇岗口岸的跨境巴士。看这里有比较详细的介绍,也可以直接打电话咨询。
优点:几乎遍布全港,选择范围广。花钱最少的路线(落马洲过境25+机场9线20)
缺点:票价不一,要问清楚时间。通常都是半小时一班。时间不好把握。机场9线从皇岗口岸出发半小时后一班,半点出发
返程:不知道
总用时:到落马洲50分钟~一小时,机场9线45~50分钟

5.香港国际机场乘turbojet直达深圳机场福永码头
到福永码头后有直达机场的车,大概10几分钟。我没亲自走过。不过从香港机场到深圳应该比较近。
优点:不知道
缺点:不知道

6.其他的中旅等旅行社也在不同地方分布有直达深圳机场的大巴,通常价格都是100港刀以上。这个就是要问了。
优点:不知道
缺点:不知道

最后更新:2009-4-14

怎样获取手机的mac地址

输入*#62209526#

前提是手机要有网卡

window定时关机

两个命令: at 和shutdown

最简单的组合:

c:at 00:00 shutdown

晚上12点关机。
如果正在下载东西,又不想让PC熬夜。可以用这个。

spring的tip

发现用spring有一个问题,如果某个人忘记加入一个类文件,而这个依赖是在spring中体现的,那么在编译时不会报错, 而显然是不好的.这种错误应该在编译的时候就应该报出来. 考虑在编译时检查一次bean依赖, 最简单就是初始化一次application-context.