默认分类

QClub广州站2012年第二期回顾

5月5号QClub广州第二次活动,广州早上依然下大雨,不过10点以后就停下来了,应该未对大家来参加活动造成影响。

这次仍然在UC优视广州公司的培训室举办,这次在UC行政MM的帮助下,举办轻松了很多。会场座位、水、咖啡机、水果、茶点都提前帮忙准备好了,还根据上次的建议专门搭建了可供培训室使用的半开放网络环境,而且提供了纪念品(5只松鼠公仔+5只松鼠搪胶摆件)。感谢帮忙的同学,小红花送上。

 

本次的主题是敏捷,来的听众涉及技术和项目管理、QA等角色,人数在48~53人左右(两点钟以后有几位过来),报名人数在五地中属于多的,不过依然没有超过70%的到场率。还有一位高校的老师,非常认真地作笔记并在Open Space环节与大家作了分享交流。

 

敏捷这个话题没有细分,在两场演讲中,并不能覆盖特别多的内容。两场演讲中,两位讲师的话题都偏技术,会导致非技术听众听演讲时能获取的内容会比较少。以后需要在主题确定上相对精细些,以使来的听众更有针对性。不过Open Space环节大家的讨论非常积极,分享也很精彩,还给大家介绍了很多有价值的开发或敏捷相关的工具,不少人反馈在讨论环节有不少收获。

这次活动讲师的演讲时间、Open Space环节的分享都有些超时,一直持续到下午18:20左右结束。

在这次活动中,还征集了几位志愿者,感谢五位热心的朋友。以后有他们的帮忙,我们会在广州办得更好。

 

这次做的好的地方:

1. 本地赞助商的充分支持。有负责会务接待的UC的专业行政MM帮忙,这次在会场、网络、纪念品、茶点准备等方面都做得好了很多,正式很多。

2. Open Space环节,这次改为大家提出话题,我统一列出,再由大家选话题讨论的方式,要讨论的话题很清晰,不至于讲完了话题就不记得了。另外,伯薇推荐的魔贴确实非常好用,推荐其他组织活动的人员也使用。

3. 礼品丰富。这次InfoQ寄来了10本书、20份QCon光盘、UC的10份礼品,共计有40份,80%的参会人员都会拿到礼品,而且礼品都很受欢迎(书最受欢迎,且反馈想要QCon的视频)。主要也是按提供分享、参与互动的人发放出去;QCon光盘按照同一公司的只发一份、有认识人的只发一份的方式发放下去,这样大家都可以互相拷备共享。

4. Steven Mak控场能力很好,与听众的互动很好。

5. 召集并确定了五位志愿者,以后办活动力量更壮大了,宣传和找讲师也会更轻松些了。

 

可改进的地方:

1. 话题的选定,可以更精细一些。敏捷这个话题过大,导致听众产生了不一致的预期,部分预期不符的听众听的效果不一定好。

2. 前期准备有些仓促。前期的宣传有些晚,从确定下来话题与讲师,从QCon回来后只有两周的时间准备。下次可以更早开始。另外,可以更早地在其他技术社区宣传,引导其他社区的同学过来。

3. 对讲师的Slides与讲师确定较晚。以后时间准备得早的话,可以更早与讲师确定Slides,并请讲师多准备一些实际的案例,以便让观众获取更直观的内容。

 

下期主题的想法:

这次简单收集了下大家对下期主题的想法,提到了不少内容;Steven提出做Code Retreat,也是个不错的主意。近期再向大家征集下建议。

 

这次活动,比第一次效果好了很多。希望以后在几位志愿者的支持下,QClub广州站能办得越来越好。

照片:http://hi.baidu.com/guorabbit/album/item/e549e350352ac65c6ea0a9cefbf2b21192138a31.html?isnew=1

(这是手机拍摄的,明天上传专业相机的拍摄相片。今天发现网盘没上传上去。)

阅读全文
类别:默认分类 查看评论

2012-2-25 QClub广州站活动总结

2月25号,在UC优视广州公司的培训室,举办了QClub广州站今年的第一场活动。这是自己第一次组织QClub活动,紧张又兴奋,经过一段时间的准备,终于成功举办了。

本次活动中,大体情况如下:

1. 报名人数105人,实际到场67人左右。报名热情,但到场率不高。当天广州下了雨,广州也很久没有办过QClub这样的活动了,估计不少人也不太了解活动情况,打了退堂鼓。

2. 演讲嘉宾,一位是来自UC优视,一位来自正点科技,对讲师的选取比较合适。一位讲解成熟团队、较成熟产品的开发经验、对未来发展趋势的展望,另一位讲解企业初创期的发展注意点、如何处理初创期的一些问题。这两位的演讲各具特色,对听众有一定的参考价值。

3. 第三个环节的Open Space环节大家发言踊跃,互动超出预期,效果较好。

4. 17:40左右结束。奖品准备多了,最后让能简述出来QClub 是什么、InfoQ与QClub的关系、准备多久办一次的同学,送了两份奖品,哈哈。

 

做得好的地方:

1. 主题选择比较符合当前大家的关注热点。选择“移动应用开发经验交流”,吸引了不少想投身或尝试移动应用开发的人们报名参加。

2. 前期宣传比较到位,报名人数较多。

3. 为活动申请了东道主的一些赞助礼品,在Open Space环节发放时比较受欢迎,最后没发出去的两件公仔奖品,散场后被两位同学申请领走了,看来男生也比较喜欢公仔 :)。

4. Open Space 环节大家比较活跃,很多人带着实际开发中的困惑提出了想讨论的主题,在这个环节与大家有了充分的交流,也有不少人上台做了充分的分享,哈哈。还有几位同学表示在跟大家讨论的过程中,找到了一些团队没有想到的解决方案,效果不错。

 

做得不好的地方:

1. 活动的开始时间安排不太好。写的是1:30-2:00签到,但是不少人是在1:20到1:40之间到的,早到的人时间较松散,而过了1:40之后到的人比较少。最终1:50提前开的场。后续需要考虑签到时间与实际开始时间的安排(与大家说早到的可以与前后左右互相交流认识一下,但是大家没有那么多互动)。

2. 活动的日期选择。那天广州比较热闹,广州当天有另一场开发语言PK的技术沙龙;隔天深圳也有一场技术沙龙,可能吸引走了一部分人。遇上撞场,要从老社区分流出来人员参加QClub活动,需要沙龙的品牌在广州推广一段时间才好。

3. 培训室没有开放的Wifi,不少人提出了有无Wifi,但事前没有意识到大家的这个需求。以后需要注意:有IT人参加的地方,一定要准备方便的网络环境。

4. 茶点准备比较仓促,技术沙龙中男生居多,休息时,大家对茶点吃的不太多。下次准备提供小番茄等简单的小型水果为主。

5. 拍照大意了。只用微博发了一些照片,几乎没有用相机拍照,拍照角度比较单一。后来发现微博中的照片都被打了新浪微博的水印,上传后也不太清晰。下次需要请一位朋友来专门准备拍照。

阅读全文
类别:默认分类 查看评论

【转】Pomodoro不只是番茄

Pomodoro不只是番茄May 4th, 2010Leave a commentGo to comments

(本文转自Juven Xu 的个人网站,作者Juven Xu,原文地址: http://www.juvenxu.com/2010/05/04/pomodoro-not-just-tomto/

 

Pomodoro这个词来源于意大利语,意思是番茄。你可以认为它是水果,或者是蔬菜,但你可能想不到他会和软件行业的敏捷开发联系起来。这个世界本来就充满了各种趣味,软件开发也并非一定要是非常严肃的工作。本文我会介绍一本名为Pomodoro Technique Illustrated的书,它能教你如何使用一个番茄定时器高效地管理时间。

你的工作效率有多高?

在我介绍Pomodoro这一技术及相关的书籍之前,不妨先问你几个问题:

你有能力在同一时间段内游刃有余地同时处理多个问题么?你能否保持25分钟的完全专注?除了当前的工作不考虑其它,不受内部或者外部的干扰?你一天的保持专注的工作时间有多少?真的有8个小时么?什么是番茄技巧?

如果你仔细考虑了上面的几个问题,你可能会惊讶于自己工作效率之低。这并不奇怪,作为一个人,我们都不善于同时处理多个任务,因为任务上下文的切换非常耗时耗力,而且会打消我们的激情。25分钟的专注听起来很容易,但实际做到往往比想象的难,你往往会在做某件事情的时候想到其他可能更重要的事情,或者接个电话、回封电子邮件,甚至不自觉的打开微博等等…,如果做一个统计,你会发现8小时的工作时间中你真正专注工作的时间可能小于5个小时,或者更少。(既然8个小时都没利用好,要加班做什么?)

番茄技巧是FRANCESCO CIRILLO在1992年发明的一项旨在帮助团队或个人用更少时间做更多事情的实践。这种方法异常的简单,其步骤如下:

维护一份Activity Inventory列表,在里面记录所有你需要完成的任务。并且以番茄为单位(25分钟)大致估算每个任务的量。每天工作之前建立一份To Do Today列面,从Activity Inventory中选择那些今天需要完成的任务,放到To Do Today中。这个列表必须是具有高度可行性的,例如所有任务的番茄量之和不大于16个(6小时40分钟的完全专注时间)。从To Do Today中选择一个任务开始执行,同时开启番茄定时器(我使用自己HTC Hero自带的定时器),在定时器鸣叫之前,不考虑该任务之外的任何事情。定时器鸣叫后,立刻停止手头的工作,休息5分钟。起来走走,倒杯水,总之别做工作相关的事情。完成4个番茄后,休息约20分钟。一天工作完成后,记录当天完成的任务数量,完成的番茄数量至Records列表。自我回顾,总结,并找到可以提高的地方。

番茄技巧的核心是专注,在一个番茄周期里,你必须全身心地投入到工作中去,尽可能地排除任何外界的干扰。同时,为了保持专注的质量,你也必须周期性的休息,根据人身固有的节奏调节自己。

延伸阅读Pomodoro Technique Illustrated这本书由著名的Pragmatic Bookshelf出版,它的每一页都配了一张彩色铅笔画,令这项本来就简单的技术显得更加妙趣横生。我在看过电子版之后,还是忍不住从Amazon买回纸质版收藏。好消息是,最近得知该书中文版已经由图灵引进,已在翻译过程中。FRANCESCO CIRILLO编写了一本官方的The Pomodoro Technique Book,没有上一本生动,但提供了足够的细节,而且该书可以免费下载得到。Pomodoro Technique Illustrated的作者Staffan Nöteberg维护了一个以Pomodoro为主题的博客。Pomodoro技术的官方站点也有很多资源等你发现。

最后我想说的是,软件开发没有银弹,自我管理也没有,方法终究只是一个辅助的手段而已。一切方法的前提都是我们需要有足够的自控能力。另外,方法只有在你信任它时才会发挥足够的效果。我是番茄技巧的Fans,希望本文能让你也成为番茄团的一员。

 

本文转自Juven Xu 的个人网站,作者Juven Xu,原文地址: http://www.juvenxu.com/2010/05/04/pomodoro-not-just-tomto/


阅读全文
类别:默认分类 查看评论

(转)“人人都是产品经理”之歪门邪道

1、吹,一定要会吹,产品经理就是靠一张嘴吃饭的。

一定要配一台苹果电脑装一下逼,这样别人看来做的产品怎么着都和苹果有点关系。别人说细节的时间要往大方向扯,别人扯未来的时候要往细节扯,这样你就能主导话题。

2、面带微笑的接受一切需求,一定要表现的很真诚。

这是保持良好形象的必备素质,面对任何需求方时,一定要亲切,对方一切的困难需求都要立马答应。能不能做不用担心,万事都要等会议结束后,“过两天”再给回复。至于兑现最后还不是老子说的算。

3、画龙点晴其实不难,文案随便“优化”一下。

产品DEMO随便画一下就可以扔给设计师了,等设计师做完后,就又是产品经理唱主角了。在评审会上是树立地位的时候,挑刺其实不难,看到【注册】按钮,马上可以骂,这文案用户看的懂吗?注册什么?什么注册?马上改成【填好了,立即注册成为新用户!】

4、自己也不知道怎么做时,要坚持用反问,你觉的呢?

有时候最尴尬的是你指出这里有问题,对方马上问怎么改,如果你回答不出就很囧。其实作为有水平的产品经理,当然不能直接给答案,要反复的问别人,你觉的呢?你认为怎么做?只要对方一开口,你就赢了,方法看下面一条。

5、萝卜为什么要生根,保证问的你哑口无言…

产品经理:注册按钮为什么放在这里?设计师:别的网站都是这样的吧。产品经理:那些网站?设计师:XXX、XXX……产品经理:还有呢?设计师:XXX、XXX……产品经理:还有呢?设计师:*&@*没了!产品经理:这些网站能代表所有吗?设计师:都是主流网站吧。产品经理:我问你这些网站能代表所有吗?设计师:不能。产品经理:既然不能,那你为什么把注册按钮放在这里?(回到开头,继续绕,绕三次,那设计肯定晕。)

6、抄近路拿到“半成品”,保证找出一堆BUG…

产品经理要随时树立自己的威望,不然合作过程中没人听你。为了显出自己的权威,一定要在第一时间进行“跟踪”。程序员差不多快做好,还没校对的时候,这是最容易挑毛病的时间,保证一挑一大堆。

7、压缩工时再加催命,领导肯定喜欢。

很多人说产品经理是夹在高管和底层中间的角色,夹心饼干不好当。其实不是,关键是怎么做。对于上级领导,压时间领导一定喜欢,领导问这项目多久啊?你要说一个月,领导说一个礼拜行不行,聪明的产品经理马上说,保证完成任务。至于能不能做出来,让那些设计师程序员加加班就行了。

8、实在找不到错误,就找错别字。

这个不用多说了吧,你懂得。而且错别字这种问题可大可小。你即可以说成严重误导用户,也可以说成打字的时候打错了。反正就看程序员乖不乖了。

9、还是找不出错,那就找万能的交互错误。

产品经理要是说不出点意见,会显的很没水平。最好就是找设计师的茬,原则就是让设计师开口,只要他一开口,你就赢了。产品经理:你说一下购物车为什么要这样设计?设计师:(随便说…)产品经理:你这个设计交互有很大的问题!(方法见3、4、5条)

10、绩效考核3.75分并不难,只要把屁股稍稍抬起。

别人要说了,产品经理这样折腾,最后产品数据出不来绩效考核就过不了了呀。其实定指标的时候要和领导商量好,定一个自己有把握的指标。如果真不行,差不多发现数据上不去的时候,就想点办法让数据统计产生“误差”,只要数据统计规则一调整,那3.75分就不是梦。

以上是释德和朋友们闲聊时候收集的“案例”,仅供娱乐,切勿模仿,后果自负。
要想成为一个合格的产品经理,绝对不是两三天的事。工作一两年就号称资深产品经理,肯定是上面这些人。产品经理是一个集运营、设计、技术、营销、品牌、广告、管理……多专业综合性的一个岗位,需要长期的工作积累才能胜任的,这不是高等教育可以培养出来的,更不是某些公司内部吹牛评级评出来的。


作者:董释德(微博

阅读全文
类别:默认分类 查看评论

(转) 分享Marty Cagan的一篇文章:出色的产品经理具备的素质

个人素质和态度
        技术可以学习,素质却难以培养,有些素质是成功的产品经理必不可少的。
对产品的热情
        有这样一群人,他们对产品有一种本能的热爱,把自己生活中的一切事物都看成产品,怀揣对优秀的产品的热爱和尊重。这份热情是产品经理必备的素质,是他们夜以继日克服困难、完善产品的动力。这份热情能感染团队成员,激励所有人。
        辨别这种特质很容易,可以让应聘者谈谈自己最喜欢的产品及喜欢的原因,聊聊不同领域的产品和他讨厌的产品,问问对方,如果有机会,他打算怎样完善自己最喜欢的产品。热情是难以伪装的,虚伪的做作容易毕露无遗。
用户立场
        理想的产品经理不一定来自产品的目标市场(这种情况有利也有弊),但是他必须融入目标市场。这一特质对制造大众产品的高科技企业尤为难得。我们倾向于从自己的角度去理解用户和市场。事实上,目标用户的经验、喜好、价值观、知觉能力、忍受程度、技术理解很可能与我们的大相径庭。
        可以就产品的目标市场向应聘者发问,让他谈谈如何换位思考。了解应聘者对目标市场的感觉,最重要的是看对方是尊重目标市场希望融入其中,还是打算一意孤行改变用户习惯。
        对国际化的产品和针对特定地域的产品来说,换位思考尤其重要。各种文化虽有共通之处,但也存在许多差异。有些差异对产品无关紧要,有些则至关重要。应该考察应聘者是否足够了解目标市场,能否区分这两种差异。
智力
        人的智力水平是无法替换的。产品管理需要洞察力和判断力,因此必须具备敏锐的头脑。勤奋当然是必需的,但从事这项工作光有勤奋还远远不够。
        招聘聪明人是项知易行难的任务,结果在很大程度上取决于招聘者的能力和可靠性。常言道,“物以类聚,人以群分”,此言不虚。方法之一是测试应聘者解决问题的能力。微软令人称道的、深入而有效的面试,即是考察应聘者解决问题的能力,通常由一位或多位领域专家就一个问题对应聘者进行深入考察。面试官不关心应聘者是否知道正确答案,而看重应聘者解决问题的思路和方法(智力优于知识)。如果应聘者回答正确,面试官会将问题略作调整,询问应聘者在新情况下如何应付。重复这个过程,直到应聘者被迫处理他不知道答案的情况,说出解决方法。
职业操守
        每种团队角色承担的义务和付出的努力都不相同。产品经理肩负着产品的前途和命运,绝不适合贪图安逸的人担任。即便掌握了时间管理和产品管理的技巧,产品经理依然要为产品投入大量精力。成功的产品经理能拥有时间享受清闲的家庭生活吗?只要具备足够的经验,我相信可以做到。但是,如果你期望的是一周只工作四十个小时,下班后把工作抛诸脑后,那是不现实的。
        成功的产品经理需要付出多少努力?在这个问题上,我对应聘者向来坦率,产品管理工作绝不能用时间来衡量,付出多少都不为过。紧急情况下临时找来的“救火队员”多半不是合适的产品经理人选。
        在漫长的项目周期里,产品经理需要付出的努力和承担的义务并非一成不变。有的阶段比较轻松,有的阶段则很紧张。但是称职的产品经理对产品的关注和忧虑程度,以及愿意为之付出努力的热情是不会改变的。
正直
        在所有产品团队成员里,产品经理最能体现公司和产品的价值观。通常产品经理不直接管理团队成员,不能要求别人执行命令,所以他必须通过行动影响、说服身边的同事。这种影响基于相互的信任和尊重,要求产品经理必须是个正直的人。
        产品经理是产品团队、销售团队、公司高管之间的枢纽,经常要协调处理各种问题,比如提早供货、满足大客户的特殊要求。产品经理如何处理这些难题,同事们都看在眼里。
        信任和尊重需要时间培养,产品经理唯有通过工作展示自己的素质和能力,才能成为真正的团队领导。如果产品经理对待同事缺乏诚意,怀有私心,一碗水端不平,那么势必会影响整体团结和工作效率。产品经理虽然不必事事精通,但应当知道每位成员最擅长做什么,尊重大家发挥工作特长的意愿,充分信任大家。
        考察一个人是否正直绝不比考察他的智力容易,考察陌生的应聘者是否正直就更难了。对那些有工作经验的应聘者,可以问问他们如何处理工作中的压力,多追问工作细节。
信心
        很多人相信经验可以让人产生自信。如果仅凭经验可以建立信心,为什么许多工作多年的产品经理却毫无自信?相反,刚刚步入社会的大学毕业生却往往充满自信(虽然这种自信通常源自对自身状况的无知)。
        自信是很重要的素质。公司高管、产品团队、销售团队都需要看到产品经理的信心,确信他们投入的时间、金钱、努力不会付之东流。自信的人更有说服力,更容易成为人们愿意追随的领导者。
态度
        称职的产品经理把自己当成产品的CEO,愿意为产品的最终成败承担全部责任,绝不找借口。虽然他清楚产品按时成功上市要克服许多困难——开发难度大、开发时间长、成本过高、产品复杂等,但他明白预见和解决这些问题是他的责任。
        这并不是说产品经理要事必恭亲,监督每个人的工作,而是指出现问题时他应该及时承担责任,进展顺利时他应该及时给大家以鼓励。称职的产品经理知道,虽然产品的实现离不开大家的协助,但是他应该对自己的产品创意负责。
        技能
        掌握一些重要的技能是打造成功产品的关键。我相信,只要具备优秀的个人素质,所有技能都可以习得。
运用技术的能力
        很多成功的产品经理是工程师出身,因为策划产品在很大程度上取决于对新技术的理解,以及如何应用技术解决相关的问题。出色的产品经理并不需要自己发明或实现新技术,但必须有能力理解技术、发掘技术的应用潜力。培养理解技术的能力有多种途径,可以参加培训课程,阅读相关书籍和文章,向程序员和架构师请教,参加开发团队的头脑风暴也不失为一种途径。
注意力
        产品经理要优先解决重要问题。研发产品的过程中有很多干扰。能否集中注意力解决关键问题、克制不断增加功能的冲动、不受关键人物或重要客户的影响,取决于产品经理是否有足够强的自律性——不但要遵守公司制度,还要严格要求自己。几乎所有产品都有些不那么重要的功能——这些功能对提高销量和用户满意度毫无作用。如果去掉这些功能,产品甚至会因为简单、易用获得更多用户的喜爱。我建议过滤多余的功能,缩短研发时间,降低生产成本,让产品更早上市。
时间管理
        电子邮件、即时消息和手机构成的世界充满了干扰。你可能一大早就来上班,拼命工作一整天,连吃饭喝水都顾不上,深夜回到家却发现到头来没完成一件重要工作。时间都用来“救火”和处理“紧急”事件了。
        熟练、迅速地区分重要任务和紧急任务,合理地规划和安排时间是产品经理必备的技能。如果产品经理无法集中精力完成真正重要的任务,那产品就难免命运多舛了。
        我认识太多每星期工作七十个小时、累得精疲力竭的产品经理。他们把所有的时间和精力都花在工作上,体力透支到了极限。对他们而言,最可怕的事实莫过于做的都是无用功。为此,我有意在培训课程中加入了时间管理和合理安排工作任务的内容。产品经理的时间应该用来改变现状,而不是疲于奔命参加大小会议、逐一回复邮件。有许多事情不值得做。
沟通技能
        虽然沟通技巧可以学习,但要做到出类拔萃需要经年累月的练习。沟通(包括口头表达和书面表达)能力是产品经理必备的技能,如前所述,产品经理只能以理服人,绝不能靠职位压制他人。
        口头表达能力可以在面试中测试,测试书面表达能力则需另寻他法。我常建议应聘者随身携带文字材料证明其书面表达能力,比如,不涉及专利的产品策划文档。
        注意,如果应聘者使用非母语时带有口音或有轻微的语法错误,不代表其沟通技巧不佳,只要说话口齿清晰、易于理解、具有说服力即可,完美的发音和语法不是必要条件。
        产品经理会花许多时间写电子邮件、产品说明文档、策划书、同类产品分析文档等。聪明的产品经理不会浪费时间写没人看的东西,一旦决定动笔就要做到最好,言之有物,让人信服。
        书面表达务必条理清晰、言简意赅,因为同事(特别是公司高管)会根据这些文字评估产品经理的工作。有时文字材料是他们评判的唯一依据。
        还有一种常见的沟通形式是演讲。对许多人来说,面对听众演讲并非易事,有效地表达观点更是困难。尽管如此,演讲是产品经理的家常便饭。产品经理必须用最短的时间向公司高管、大客户、销售团队解释产品的内涵和重要性。
        我们都听过糟糕的演讲——幻灯片一张接一张没完没了,演讲人死板地朗诵条目,听众不得不费劲地揣摩每张图表的意义,既抓不住重点,也不明白价值何在。
        与此相反,成功的产品经理尽可能减少幻灯片的页数,他们的演讲充满热情、重点清晰、数据充分、引人入胜,绝不超时(甚至提前结束)。他们更喜欢听众提问,即使遇到暂时无法回答的问题,也会努力尝试向提问者和听众阐述自己的理解。杰里·韦斯曼(Jerry Weissman)的《演讲制胜:讲故事的艺术》是一本非常好的提高演讲水平的指南。
        商业技能
        作为产品团队的发言人,产品经理要协调团队与财务部门、营销部门、销售团队、公司高管之间的工作——必须使用这些人听得懂的概念和术语。
        我认为产品经理应该具备双语技能。这并非指中文和英文,而是指产品经理既能与程序员讨论技术,又能与管理层和营销人员讨论成本结构、边际效应、市场份额、产品定位和品牌。
由于上述原因,很多产品经理都是商学院毕业的。企业需要懂得商务的人,所以雇用MBA。虽然MBA也可以成长为出色的产品经理,但总的来说商业技能只是产品经理需要具备的多种技能之一,而且完全可以在商学院以外的地方学到。比如,技术人员进入产品管理领域后,通过阅读、培训学习商业技能是很常见的事。

阅读全文
类别:默认分类 查看评论

广州亚运城收楼,质量惨不忍睹,触目惊心

[以下转自论坛,该业主已在QQ群里被多次举报并无法登录发言,开发商能够操纵的人还真不少,暗无天日]

近期亚运城开始陆续收楼了,根据实地反映的情况,房子存在多种问题:


墙壁空鼓、地板空鼓、楼顶漏水、外墙渗水、发霉、长蘑菇、长木耳、水管外露、电线断路、电梯很小、面积缩水,厅和阳台很小、地面出现像地震弄出的裂缝……



乍一看是装修和维护的问题,似乎只要要求开发商整改一下就能住人的,但我有些个人看法:



连表面这些蒙人的东西都不能做好,还能做好内部吗?

大家真的心里觉得整改后,就可以安心住在里面吗?



回顾一下整个购房的过程:



首先是打出很好的宣传,是亚运面子工程, 不能在外国人面前丢脸,也总不能闹出什么国际笑话,而且描绘出很多美好的将来,说配套多好多好。

让很多人都十分向往,在看过板房后,有种“一旦错过就不再”的感觉。



因此也就造就了2010年刚开卖就疯抢的场面。

很多业主表示“稍微犹豫一下就被人抢了”,所以合同什么的都是“随便看看”或“看都没看”就签约了。



一个均价100万的东西,能让那么多人不关心法制本身就脆弱的国度下的合同就签名的,确实是“神器”了。



这个神器神就神在他的背景和光环,具体原因不多解释,买卖双方和旁观者都看得出来。



我不是第一批去买的,但在购买的时候,看了样板房也不是100%相信的,还是希望看到实际房子,于是多次跟售楼方提出先看真房的愿望。但都被毫无力度的理由搪塞回来了,归纳一下,主要有:



1、这不是二手买卖,没得看的,像其他新房一样的手续

2、去年那么多人都买了,难道开发商会欺骗那么多人吗?

3、这个是5大品牌开发商共同打造的,难道他们要毁了自己的信誉吗?

4、运动员和各国媒体都住过了,难道政腐要做给国人抹黑的事情吗?



其实现在回顾起来,这些都是什么破理由啊。



1、新房因为多数是没建好的,也没有装修,所以没什么好看的。但这个已经住过人了,因此该理由不成立。

我当时有提出此观点,售楼方的说法改成了:那里堆放了很多亚运时期的东西,目前在陆续搬离中,所以不便参观。

也就是打扰人家工作了,于是也将就相信了吧。



2、现在回顾起来,开发商确实可以做到欺骗那么多人,毕竟中国人不是都能像江西老表那么大胆的。而且一旦出现不团结的情况,最后就是全军覆没。国人最能干的就是不团结,很多事情都是想想没把握就算了。



3、就像双汇一样,现在还不是卖得很好吗?总要找个地方住啊…………



4、亚运会是秋季举办的,不冷不热不潮湿,建出如此优越的条件都挨不过的房子,他们还好意思混啊,而且他们有的是专家,知道挨过那几个月的最低成本是多少。而且,住在里头的人吃好睡好有人服务,才不多嘴说什么咧。国内的乱说不用混了,国外的Facebook什么的都早就被和谐了,完全没有人言可畏之畏。



出于上述几个观点,结合实际收房的情况,可以得出如下推论:



1、开发商一开始就没打算用心做个好房子,首先工期就比较赶,能做到合格估计都是比较难。打算把成本投到后期的宣传上,加上亚运的光环,质量可以放一边。



2、合同中存在多处不利于买方的条款,一旦出现问题,买家会承担一切损失。这些条款在那里摆着,几千人都没有发现。充分证明在签约的时候,过分相信光环的力量,以及签约时被人误导,说“其他地方都是跟一般的购房合同一样的,就看几个跟价格、身份证号等画了‘圈圈’的地方就可以了”。此事有人做了现场录音,可以作为证据提出。

也就是说,一开始就为今后打官司做了准备,万一打官司,买方自己签字,按了手印,法律上是合法的。

但目前业主可以提出签约含有误导情节,不过这份精密设计的合同中本身也有漏洞,也就是指明了如果条款明显对一方不利,其效果不成立之类的。



3、连合同中说明的部分,现在都已经可以无视法律,敢不遵守。那没有提及的部分呢?现在已经有说法,里头的热水是1吨30元的,空调遥控器是80元一个的(非赠送)。拿热水来说吧,整个房屋的水龙头都是冷热使用的,1吨30元的热水显然是抢钱的,不要指望听证会了,就是听价会。那么业主能做的就只有买电热水器和改造整个热水系统。没有个5000估计搞不定吧。

热水问题只是一斑,今后还有多大只的豹在等着我们还不知道呢,比如学校和医院两大吸血鬼,还有垃圾焚烧场什么的。在一个基本封闭的环境中,与翁中之鳖无异,任人宰割。大家到时候就抱着“既住之则安之”这种忍气吞声的想法生活吧。



4、出现问题后,大家想到的无非就是退房和整改两种解决方案。很多人已经决定退房无望,能整改的希望也很小,原因感觉是自己签了合同,感觉理亏。这也是开发商感肆无忌惮做出豆腐渣工程的根源。有人甚至说出“那么多人退房开发商岂不是倒闭”的不知道站在谁的立场说话的理由来提出只能整改。说白了,整改或许根本就是开发商预计的结果。因为一旦整改了,就等于给业主判了无期徒刑。

整改如果交给开发商处理,到时候估计又跟亚运一样,“当时还行”,大家想想还是算了,自己弄吧。因为再出问题,就不能像现在一样那么集中的力量了。有些半年出问题,有些一年出问题。半年出问题的想找开发商,人太少搞不定,拉上还没出问题的,大家觉得有戏吗?然后就这样一片片被再次愚弄了。

所以想想都发毛了吧, 于是考虑自己弄,让开发商赔钱。但肯定也是赔不够的,实际可能需要1500每平方米的,最后能拿到1200算不错了,这里又亏了一大笔。而且拆掉原来的装修本身也是要钱的。



说到拆装修,这里要谈论到质量问题。由于亚运的时候的装修只是往房子里加东西,基本不涉及拆。所以就算有质量问题也不会造成什么后果。但如果现在全城整改,在一个不明质量问题的房子上拆拆装装,到时候说不定家具往里头一搬,就会全体散架。

到时候新闻说的就是《无知业主装修心切导致伤亡惨重》,说不定可以混一个全国哀悼日,提前出现在历史书里。



终上所述,我认为业主唯一的出路就是退房。



下面看看退房的话,到底是否“没可能”?



首先从法律上,售楼方恶意隐瞒了消费者的知情权。试问:如果买的时候,大家看过实体房,会买吗?会以现在的成交价买吗?



然后从合同上,存在多处对业主不利的条款,有利用“光环”让人签约以保护自己的预谋之嫌。同时,结合有人给“误导签约”做了全程录音,加上合同本身也有对开发商不利的疏漏。也就是在这种情况下签订的合同是无效的。

 

再有,从房子的验收报告上,只能是一个结果——

房子没经过验收,随便弄个假的证明。

如果真的上了法庭,这个是必须要开发商拿出的证明。

而作为业主,应该是可以指定开发商拿出具体某一个单位的报告,然后对照验收检查的项目逐个跟实际情况对比。

比如厨房墙壁空鼓的,验收处写合格,那足以证明作假。

然后多拿几套,超过3~5套,就足以证明报告作假。




本次涉及的金额过大,受害人数也很多。不能单一借鉴一般消费纠纷导致消费者处于劣势的事实来让自己退缩。

一般的消费纠纷,往往是消费者要花费比商品高出许多倍的金钱成本和时间成本来维权,所以很多人选择了忍受和放弃。



除非大家都来钱很容易,100万的东西也不屑维权的话,我表示此文白写。



希望看到的人多转发,让更多人意识到不退房的危害吧。

阅读全文
类别:默认分类 查看评论

【转】蒙特卡洛模拟

原文地址:http://www.cabit.com.cn/help/Read.asp?id=83

 

风险分析是我们制定的每个决策的一部分。我们一直面对着不确定,不明确和变异。甚至我们无法获得信息,我们不能准确的预测未来。蒙特卡洛模拟( Monte Carlo simulation)让您看到了您决策的所有可能的输出,并评估风险,允许在不确定的情况下制定更好的决策。


什么是蒙特卡洛模拟( Monte Carlo simulation)

蒙特卡洛模拟( Monte Carlo simulation)是一种计算机数学技术,允许人们在定量分析和决策制定过程中量化风险。这项技术被专家们用于各种不同的领域,比如财经,项目管理,能源,生产,工程,研究和开发,保险,石油&天然气,物流和环境。

蒙特卡洛模拟( Monte Carlo simulation)提供给了决策制定者大范围的可能输出和任意行动选择将会发生的概率。它显示了极端的可能性-最的输出,最保守的输出-以及对于中间路线决策的最可能的结果。

这项技术首先被从事原子弹工作的科学家使用;它被命名为蒙特卡洛,摩纳哥有名的娱乐旅游胜地。它是在二战的时候被传入的,蒙特卡洛模拟( Monte Carlo simulation)现在已经被用于建模各种物理和概念系统。

蒙特卡洛模拟( Monte Carlo simulation)是如何工作的

蒙特卡洛模拟( Monte Carlo simulation)通过构建可能结果的模型-通过替换任意存在固有不确定性的因子的一定范围的值(概率分布)-来执行风险分析。它一次又一次的计算结果,每次使用一个从概率分布获得的不同随机数集。根据不确定数和为他们制定的范围,蒙特卡洛模拟( Monte Carlo simulation)能够在它完成计算前调用成千上万次的重复计算。蒙特卡洛模拟( Monte Carlo simulation)产生可能结果输出值的分布。

通过使用概率分布,变量能够拥有不同结果发生的不同概率。概率分布是一种用来描述风险分析的变量中的不确定性的更加可行的方法。常用的概率分布包括:

正态分布(Normal)-或"钟型曲线".用户简单的定义均值或期望值和标准差来描述关于均值的变异。在中部靠近均值的值是最有可能发生的值。它是对称的,可以用来描述多种自然现象,比如人的身高。可以通过正态分布描述的变量示例包括通货膨胀率和能源价格。


对数正态分布(Lognormal)-值是正偏的,不像正态分布那样是对称的。它被用来代表不会小于零但可能有无限大正值的结果。可以通过对数正态分布描述的变量示例包括房地产价值,股票价格和石油储量。

均匀分布(Uniform)-所有的值发生的机会相等,用户只需制定最小和最大值。可以通过均匀分布描述的变量示例包括一个新产品的制造费用或未来销售收入。

三角分布(Triangular)-用户指定最小,最可能和最大值。在最可能附近的值最可能发生。可以通过三角分布描述的变量示例包括每时间单位内的过去销售历史和库存水平。


PERT分布-用户指定最小,最可能和最大值,类似三角分布。在最可能附近的值最可能发生。然而在最可能和极值之间的值比三角分布更有可能发生;那就是说,the extremes are not as emphasized. 可以通过三角分布描述的变量示例包括在项目管理模型中的一项任务的持续时间。

离散分布(Discrete)-用户指定最可能发生的值和每个值的可能性。比如关于诉讼结果的示例,20%的机会陪审团判决无罪,30%的机会陪审团判决有罪,40%的机会审批有效,10%的机会审批无效。

在蒙特卡洛模拟( Monte Carlo simulation)过程中,值被从输入概率分布中随机抽取。每个样本集被称为一次迭代,从样本获得的结果被记录。蒙特卡洛模拟( Monte Carlo simulation)执行这样的操作成百上千次,可能结果形成一个概率分布。用这种方法,蒙特卡洛模拟( Monte Carlo simulation)生成了一个更加全面关于将会发生的结果的视图。它不仅仅告诉什么结果会发生,而且还有结果发生的可能性。

蒙特卡洛模拟( Monte Carlo simulation)提供了许多超越确定性或"单点估计"分析的优势:

概率结果,结果不仅显示会发生什么,而且还有每个结果发生的可能性

图形化报告,因为蒙特卡洛模拟( Monte Carlo simulation)生成的数据,它很容易创建不同结果和他们发生机会的图形。这对于和其他投资者沟通结果是很重要的。

敏感性分析,如果只有很少的一些案例,确定性分许就很难发现哪个变量对结果影响最大。在蒙特卡洛模拟( Monte Carlo simulation)中,很容易发现哪个输入对底线结果有最大的影响。

情境分析,在确定性模型中,对于为不同输入值的不同组合建模来真实的查看不同情境的效果是很困难的。使用蒙特卡洛模拟( Monte Carlo simulation),分析员能够正确的查看当确定的输出发生时某个输入对应的值。这对于进一步的分析来说是无价的。

相关性输入,在蒙特卡洛模拟( Monte Carlo simulation)中,可能要建模输入变量之间的相关关系。它对于准确的描绘在某些因子增长时,其它的因子是如何增长或下降的情况时是重要的。

对蒙特卡洛模拟( Monte Carlo simulation)的增强是使用拉丁超立方(Latin Hypercub)抽样,它对于从整个分布范围内抽样更准确。

Palisade对蒙特卡洛模拟产品

用于个人计算机的电子表格应用的出现给日常工作中使用对蒙特卡洛模拟的专业人士提供了一个机会。Microsoft Excel是占有主导地位的电子表格分析工具,Palisade’s @RISK是适用Excel的处于领导地位的蒙特卡洛模拟插件。早在1987年,Palisade就为DOS平台下的Lotus 1-2-3引入了蒙特卡洛模拟,长期以来@RISK因为其计算准确,建模灵活和容易使用而享有盛誉。导入到Microsoft Project中产生了蒙特卡洛模拟的其它逻辑应用-分析在大型项目管理中的不确定性和风险。@RISK for Project是Palisade用于 Microsoft Project的蒙特卡洛模拟插件。

阅读全文
类别:默认分类 查看评论

Mercurial (hg)配置说明

这个工具在国内很少人使用,所以中文资料匮乏.只有官方的website上有一些少得可怜的中文资料了.不过总体上来说,hg还是比较好用的。接下来开始 HG 的使用

1.建立用户hgrepo

其它用户将用这个账户用hg服务器push代码。

useradd hgrepo -d /home/hgrepo # add user hgrepo
passwd hgrepo

2.建立hg代码仓库

如果代码仓库名称为project.hg,则可用如下命令。

cd /home/hgrepo
mkdir project.hg
cd project.hg
hg init # 初始化代码仓库
建立一个测试文件

echo "hello, mercurial" > sample.txt
hg add  # add
hg ci     # check in

3. 打开http

打开一个端口,让远程用户可以clone仓库中的代码.
在打开端口前请确定文件权限正确。

更改文件权限
chown hgrepo.hgrepo /home/hgrepo/project.hg -R
chmod og+rw /home/hgrepo/project.hg -R
打开端口

cd  /home/hgrepo/project.hg -R
hg serve -p 8002 &
可将上面两行加入/etc/rc.local这样就可以在开机的时候自动运行了。

4.使用hg

完成步骤3以后,我们就可以使用了。

clone到本地

例如你的服务器的名字为test.

hg clone http://test:8002
然后在本地目录就会出现一个project.hg的一个copy.

修改Client端的配置

更改.hg/hgrc,加上default-push和username

[paths]
default = http://test:8002
default-push = ssh://hgrepo@test//home/hgrepo/project.hg/
[ui]
username=shaohui.zheng
这样你就可用hg push 向服务器提交code了。这时服务器会问你passward,这个password就是用户hgrepo的password.

Good Luck.

官方网站

http://www.selenic.com/mercurial/

另外还有个 Windows 下的客户端与其配合使用

TortoiseHg

http://www.oschina.net/p/tortoisehg

=======================================

使用:
1.初始化
假设你的源代码目录为proj,执行以下步骤可以建立初始的repository
$ cd proj
$ hg init         //生成repository
$ hg add /fullpath/filename //加入文件
或者
$ hg addremove    //加入可识别的文件,去除其他文件
$ hg commit       //生成你的代码的第一个版本
执行此命令会让hg调用vi,这时你可以键入一些关于当前提交内容的一些信息,然后保存退出,这个版本就行程了。

2.版本
以后每当你改动文件后都可以使用hg commit命令来生成一个新的版本
$ hg parent  //查看当前的版本
$ hg log     //查看所有历史版本
$ hg tag    //可以在一些重大的阶段制作tag,以便于将来对代码的一些里程碑进行回溯 
$ hg tags   //查看所有的tag,进行大的版本比较
$ hg co 版本号 //可以检出任意一个版本进行修改
而如果需要废弃某一版本后的所有版本可以使用hg strip 版本号,这样以后的提交的版本号将会从此版本号之

后计算。

3.文件
$ hg status  //查看现在代码中文件的状态,m表示修改过,a表示新加的文件,
              ?表示文件状态未知。
新生成的文件使用 $ hg add /fullpath/filename后状态就会由?变为a
!!!新生成的文件务必要用ad

详细出处参考:http://www.itqun.net/content-detail/194720.html

d命令加入repository,否则在做diff文件的时候会没有新文件的内容!!!
$ hg revert //当你改变了一些文件又后悔后就可以使用此命令来取消改动
$ hg clone source dest //可以完整地将一个repository拷贝到另一个目录,这很适合做分支处理或者作一些实验型代码。
$ hg update  //从原始代码树中取得最新的更新
$ hg pull 和 hg push 分别从原始地代码树中取得或者提交最新更新地文件

4.patch
$ hg diff //比较当前改动和当前版本的区别,也可以用-r参数指定两个版本进行比较,比较的结果可以从定向到文件,此文件即是一个标准的patch文件。
$ hg import /fullpath/filename //将patch文件打到当前的代码树上。

详细出处参考:http://www.itqun.net/content-detail/194720_2.html

 


阅读全文
类别:默认分类 查看评论

23种设计模式MM版形象描述

设计模式最难的莫过于不好理解,要是有个形象的例子就好了。
以下是从CSDN转过来的设计模式泡MM版,通俗易懂,而且你绝对不会忘。当然这只是给刚入门的人学习。
想要经一步学习,还是去买本sun公司的java design pattern吧。


创建型模式

1、factory―追mm少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是mm爱吃的东西,虽
然口味有所不同,但不管你带mm去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行
了。麦当劳和肯德基就是生产鸡翅的factory


工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。
消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如
:如何创建及如何向客户端提供。

2、builder―mm最爱听的就是“我爱你”这句话了,见到不同地方的mm,要能够用她们的
方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到mm我
只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的mm也可以轻松
搞掂,这就是我的“我爱你”builder。(这一定比美军在伊拉克用的翻译机好卖)

建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有
不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化,客户不必知道
产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

3、factory method―请mm去麦当劳吃汉堡,不同的mm有不同的口味,要每个都记住是一
件烦人的事情,我一般采用factory method模式,带着mm到服务员那儿,说“要一个汉堡
”,具体要什么样的汉堡呢,让mm直接跟服务员说就行了。

工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去
做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产
品类应当被实例化这种细节。

4、prototype―跟mm用qq聊天,一定要说些深情的话语了,我搜集了好多肉麻的情话,需
要时只要copy出来放到qq里面就行了,这就是我的情话prototype了。(100块钱一份,你
要不要)

原始模型模式:通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原
型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类,产
品类不需要非得有任何事先确定的等级结构,原始模型模式适用于任何的等级结构。缺点
是每一个类都必须配备一个克隆方法。

5、singleton―俺有6个漂亮的老婆,她们的老公都是我,我就是我们家里的老公
sigleton,她们只要说道“老公”,都是指的同一个人,那就是我(刚才做了个梦啦,哪
有这么好的事)

单例模式:单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个
实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。

结构型模式

6、adapter―在朋友聚会上碰到了一个美女sarah,从香港来的,可我不会说粤语,她不
会说普通话,只好求助于我的朋友kent了,他作为我和sarah之间的adapter,让我和
sarah可以相互交谈了(也不知道他会不会耍我)

适配器(变压器)模式:把一个类的接口变换成客户端所期待的另一种接口,从而使原本
因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个
合适的实例给客户端。

7、bridge―早上碰到mm,要说早上好,晚上碰到mm,要说晚上好;碰到mm穿了件新衣服
,要说你的衣服好漂亮哦,碰到mm新做的发型,要说你的头发好漂亮哦。不要问我“早上
碰到mm新做了个发型怎么说”这种问题,自己用bridge组合一下不就行了

桥梁模式:将抽象化与实现化脱耦,使得二者可以独立的变化,也就是说将他们之间的强
关联变成弱关联,也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而
不是继承关系,从而使两者可以独立的变化。

8、composite―mary今天过生日。“我过生日,你要送我一件礼物。”“嗯,好吧,去商
店,你自己挑。”“这件t恤挺漂亮,买,这条裙子好看,买,这个包也不错,买。”“
喂,买了三件了呀,我只答应送一件礼物的哦。”“什么呀,t恤加裙子加包包,正好配
成一套呀,小姐,麻烦你包起来。”“……”,mm都会用composite模式了,你会了没有


合成模式:合成模式将对象组织到树结构中,可以用来描述整体与部分的关系。合成模式
就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合
成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。

9、decorator―mary过完轮到sarly过生日,还是不要叫她自己挑了,不然这个月伙食费
肯定玩完,拿出我去年在华山顶上照的照片,在背面写上“最好的的礼物,就是爱你的
fita”,再到街上礼品店买了个像框(卖礼品的mm也很漂亮哦),再找隔壁搞美术设计的
mike设计了一个漂亮的盒子装起来……,我们都是decorator,最终都在修饰我这个人呀
,怎么样,看懂了吗?

装饰模式:装饰模式以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案
,提供比继承更多的灵活性。动态给一个对象增加功能,这些功能可以再动态的撤消。增
加由一些基本功能的排列组合而产生的非常大量的功能。

10、facade―我有一个专业的nikon相机,我就喜欢自己手动调光圈、快门,这样照出来
的照片才专业,但mm可不懂这些,教了半天也不会。幸好相机有facade设计模式,把相机
调整到自动档,只要对准目标按快门就行了,一切由相机自动调整,这样mm也可以用这个
相机给我拍张照片了。

门面模式:外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一
个高层次的接口,使得子系统更易于使用。每一个子系统只有一个门面类,而且此门面类
只有一个实例,也就是说它是一个单例模式。但整个系统可以有多个门面类。

11、flyweight―每天跟mm发短信,手指都累死了,最近买了个新手机,可以把一些常用
的句子存在手机里,要用的时候,直接拿出来,在前面加上mm的名字就可以发送了,再不
用一个字一个字敲了。共享的句子就是flyweight,mm的名字就是提取出来的外部特征,
根据上下文情况使用。

享元模式:flyweight在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量
的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在
享元内部,不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态
不能影响内蕴状态,它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类
中区分开来,将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象
,而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的
数量。

12、proxy―跟mm在网上聊天,一开头总是“hi,你好”,“你从哪儿来呀?”“你多大了
?”“身高多少呀?”这些话,真烦人,写个程序做为我的proxy吧,凡是接收到这些话
都设置好了自动的回答,接收到其他的话时再通知我回答,怎么样,酷吧。

代理模式:代理模式给某一个对象提供一个代理对象,并由代理对象控制对源对象的引用
。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下,客户不
想或者不能够直接引用一个对象,代理对象可以在客户和目标对象直接起到中介的作用。
客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象
,而仅仅持有一个被代理对象的接口,这时候代理对象不能够创建被代理对象,被代理对
象必须有系统的其他角色代为创建并传入。

行为模式

13、chain of responsibleity―晚上去上英语课,为了好开溜坐到了最后一排,哇,前
面坐了好几个漂亮的mm哎,找张纸条,写上“hi,可以做我的女朋友吗?如果不愿意请向
前传”,纸条就一个接一个的传上去了,糟糕,传到第一排的mm把纸条传给老师了,听说
是个老处女呀,快跑!

责任链模式:在责任链模式中,很多对象由每一个对象对其下家的引用而接

起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。客户并
不知道链上的哪一个对象最终处理这个请求,系统可以在不影响客户端的情况下动态的重
新组织链和分配责任。处理者有两个选择:承担责任或者把责任推给下家。一个请求可以
最终不被任何接收端对象所接受。

14、command―俺有一个mm家里管得特别严,没法见面,只好借助于她弟弟在我们俩之间
传送信息,她对我有什么指示,就写一张纸条让她弟弟带给我。这不,她弟弟又传送过来
一个command,为了感谢他,我请他吃了碗杂酱面,哪知道他说:“我同时给我姐姐三个
男朋友送command,就数你最小气,才请我吃面。”,

命令模式:命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任
和执行命令的责任分割开,委派给不同的对象。命令模式允许请求的一方和发送的一方独
立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收
,以及操作是否执行,何时被执行以及是怎么被执行的。系统支持命令的撤消。

15、interpreter―俺有一个《泡mm真经》,上面有各种泡mm的攻略,比如说去吃西餐的
步骤、去看电影的方法等等,跟mm约会时,只要做一个interpreter,照着上面的脚本执
行就可以了。

解释器模式:给定一个语言后,解释器模式可以定义出其文法的一种表示,并同时提供一
个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样
在有了一个简单的文法后,使用模式设计解释这些语句。在解释器模式里面提到的语言是
指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类
的等级结构,也就是一系列的组合规则。每一个命令对象都有一个解释方法,代表对命令
对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。


16、iterator―我爱上了mary,不顾一切的向她求婚。

mary:“想要我跟你结婚,得答应我的条件”

我:“什么条件我都答应,你说吧”

mary:“我看上了那个一克拉的钻石”

我:“我买,我买,还有吗?”

mary:“我看上了湖边的那栋别墅”

我:“我买,我买,还有吗?”

mary:“你的小弟弟必须要有50cm长”

我脑袋嗡的一声,坐在椅子上,一咬牙:“我剪,我剪,还有吗?”

……

迭代子模式:迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多
个对象聚在一起形成的总体称之为聚集,聚集对象是能够包容一组对象的容器对象。迭代
子模式将迭代逻辑封装到一个独立的子对象中,从而与聚集本身隔开。迭代子模式简化了
聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象,每一个迭代子的迭
代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。

17、mediator―四个mm打麻将,相互之间谁应该给谁多少钱算不清楚了,幸亏当时我在旁
边,按照各自的筹码数算钱,赚了钱的从我这里拿,赔了钱的也付给我,一切就ok啦,俺
得到了四个mm的电话。

调停者模式:调停者模式包装了一系列对象相互作用的方式,使得这些对象不必相互明显
作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时,不会立即影响其他
的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互
作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化,把对象在小尺度
的行为上与其他对象的相互作用分开处理。

18、memento―同时跟几个mm聊天时,一定要记清楚刚才跟mm说了些什么话,不然mm发现
了会不高兴的哦,幸亏我有个备忘录,刚才与哪个mm说了什么话我都拷贝一份放到备忘录
里面保存,这样可以随时察看以前的记录啦。

备忘录模式:备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模
式的用意是在不破坏封装的条件下,将一个对象的状态捉住,并外部化,存储起来,从而
可以在将来合适的时候把这个对象还原到存储起来的状态。

19、observer―想知道咱们公司最新mm情报吗?加入公司的mm情报邮件组就行了,tom负
责搜集情报,他发现的新情报不用一个一个通知我们,直接发布给邮件组,我们作为订阅
者(观察者)就可以及时收到情报啦

观察者模式:观察者模式定义了一种一队多的依赖关系,让多个观察者对象同时监听某一
个主题对象。这个主题对象在状态上发生变化时,会通知所有观察者对象,使他们能够自
动更新自己。

20、state―跟mm交往时,一定要注意她的状态哦,在不同的状态时她的行为会有不同,
比如你约她今天晚上去看电影,对你没兴趣的mm就会说“有事情啦”,对你不讨厌但还没
喜欢上的mm就会说“好啊,不过可以带上我同事么?”,已经喜欢上你的mm就会说“几点
钟?看完电影再去泡吧怎么样?”,当然你看电影过程中表现良好的话,也可以把mm的状
态从不讨厌不喜欢变成喜欢哦。

状态模式:状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象
是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里,每一个
状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态
改变的时候,其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状
态类的子类。当系统的状态变化时,系统便改变所选的子类。

21、strategy―跟不同类型的mm约会,要用不同的策略,有的请电影比较好,有的则去吃
小吃效果不错,有的去海边浪漫最合适,单目的都是为了得到mm的芳心,我的追mm锦囊中
有好多strategy哦。

策略模式:策略模式针对一组算法,将每一个算法封装到具有共同接口的独立的类中,从
而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。
策略模式把行为和环境分开。环境类负责维持和查询行为类,各种算法在具体的策略类中
提供。由于算法和环境独立开来,算法的增减,修改都不会影响到环境和客户端。

22、template method――看过《如何说服女生上床》这部经典文章吗?女生从认识到上
床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步
骤(template method),但每个步骤针对不同的情况,都有不一样的做法,这就要看你随
机应变啦(具体实现);

模板方法模式:模板方法模式准备一个抽象类,将部分逻辑以具体方法以及具体构造子的
形式实现,然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的
方式实现这些抽象方法,从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架,而
将逻辑的细节留给具体的子类去实现。

23、visitor―情人节到了,要给每个mm送一束鲜花和一张卡片,可是每个mm送的花都要
针对她个人的特点,每张卡片也要根据个人的特点来挑,我一个人哪搞得清楚,还是找花
店老板和礼品店老板做一下visitor,让花店老板根据mm的特点选一束花,让礼品店老板
也根据每个人特点选一张卡,这样就轻松多了;

访问者模式:访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这
些操作需要修改的话,接受这个操作的数据结构可以保持不变。访问者模式适用于数据结
构相对未定的系统,它把数据结构和作用于结构上的操作之间的耦合解脱开,使得操作集
合可以相对自由的演化。访问者模式使得增加新的操作变的很容易,就是增加一个新的访
问者类。访问者模式将有关的行为集中到一个访问者对象中,而不是分散到一个个的节点
类中。当使用访问者模式时,要将尽可能多的对象浏览逻辑放在访问者类中,而不是放到
它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。
阅读全文
类别:默认分类 查看评论

中国河北省保定市五四东路180号—–英语翻译

NO.180, Wusi East Road, Baoding City, Hebei Province, China


类别:默认分类 查看评论