IT瘾随笔推荐

读《米哈游员工手册》有感

Sun, 21 Aug 2022 06:00:00 CST

我读的是 B 站 Up 主手打的《米哈游员工手册》，感受很深。米哈游的员工手册里有对于技术的热爱，有工科男的直率，对于具体的细节也讲解的清晰明确。非常好。

我的自我感受是： 我想去米哈游工作！我想去体验一下这样的生活！

以下是我认为写的很好的片段。其中「说到做到」、「有话直说」、「追求极致」是给职场新人很好的帮助。

以下内容来自 B 站 Up 主，感谢他的辛苦手打

作者：Violet-紫色闪电 https://www.bilibili.com/read/cv17027078 出处：bilibili

Context Not Control

Context, not Control的理念来源于Netflix。

先解释一下字面意思：

什么是Context?一切做决策需要的背景信息，都叫Context。比如：我们项目目标用户是啥，我们的历史数据如何，一测用户平成是咋样的反馈，做一个Feature的人力成本如何，技术风险的高低，甚至某个同学熬夜加班效率特别高23.等等这些都是Context

那什么是Control呢? 一切流程化的执行手段，比如: OA审批流程，指令拆分分解，委员会投票表决等。

那对我的工作而言，这两者是啥区别？

“Control”的工作方式意味着，严格遵守你的上司给你下达的指令，不必去多想他为什么这么决策，只管执行好就行，也不用考虑这个指令之外的事情，只对下达的这个命令范畴内的事情来负责。如果需要其他人来配合那就拆分，然后分配任务出去，然后同样严格控制他们来执行。这种工作方式，在很多大型企业和组织，都是十分常见的。

“Context”的工作方式则不一样。当进行一个任务的时候，我们首先需要全面的了解上下文的信息，基于自己对眼前工作的专业的认识，结与相关人员充分沟通同步认知，然后做出好的解决方案并执行完成。

举一个具体的例子，当我们要实现一个怪物的自动索敌跟踪功能的时候。

“Control”的故事会是这样：客户端主程和策划讨论完成后，基于他的知识与经验，告诉具体做Feature的程序A，用Unity的NavMeshAgent来创建Navmesh，然后实现一个寻路算法，来满足需求上的功能。

Context的故事则是这样的:客户端组长拉具体的负责实现的程序A同学和策划进行深入讨论，告诉他要做一个这样的Feature，并建议可以用到NavMeshAgent这样的功能。

看起来故事的开头并没有太大的差别，甚至很多时候这两个故事的结果也会差不多，程序A顺利使用NavMeshAgent实现了Feature，并通过了验收与测试。但是当我们的项目越来越大，越来越复杂的时候，这两条故事线的发展会天差地别。

Control线的，程序A看完了文档，看完了策划的需求文档，开始动手实现，一天后他实现了功能，在一个测试场景里跑了一下，发现没有太大问题，他喊策划来验收了一下，从而提出了修改意见，然后自己跑了跑也发现问题不大。这时候程序A认为再过一天修完Bug ，close掉这个feature毫无风险，第二天，修完bug后他把这个功能放到游戏大世界中去。这是一个面积一万倍于测试场景的世界，而且地形的复杂程度也比测试场景要高很多，不过地形复杂这件事早在程序的意料之中，他准备再花一整天时间来好好处理各种意料之外的情况。想到这里。他按下了NavMesh的Build按钮，起身准备去接一杯水，1分钟后程序A回到自己的工位，他发现这个还没有build，他敏捷的意识到出问题了，这个世界太tmd大了，光离线构建一个NavMesh就要好久，这可能会是个坑。程序啜了一口水，想了想，马上就要周版本打包了，这个任务还是得close。主程说了让我用这个方法，他应该心里有数吧，反正我毫无bug的把这个功能实现完了。策划也验收得差不多了，就这样先提交一版吧，程序A不知思考了几分钟，正等他回过神来的时候，NavMesh已经构建完了。在PC上这还是挺快的嘛，程序A继续开始做其他的功能与测试，并准时在打包前提交了全部代码。

几个小时后，当晚的周版本打包完成了，大家开始下载，不知为何今晚的下载速度有些慢大家又开始抱怨这个WiFi AP太卡了，都集中在同一时间下载。终于，十几分钟后，有人下载好了，开始回归Feature。“卧槽，怎么闪退了？”一个用iPhone 7的人喊到、“是啊，我这里好像也闪退了。”越来越多的人发现自己的设备无法正常进行游戏。简单统计后，大家发现，除了最高端设备，好像其他的都很容易闪退。经过了1个小时的排查后，大家发现，这周周版本的包比上一周整整大了500mb，而这其中95%都是内存爆炸，都是因为太多NavMesh的载入而导致的。当目光投向程序A的时候，他很坦然地承认了问题，确实看来不能这么做。然后他用比别人更专业，更精准的语言来描述了问题，以及在当前Solution下无解的程度。现在皮球回到了客户端主程的身上，在忙碌的周版本的午夜，他的疲惫显而易见的浮在脸上。因为屁股后面还排了好几个人在反馈问题。PM还在问他要不要重新打包好验收其他功能，给他用来思考这个问题的时间只有不到一分钟。那肯定是没办法离线缓存所有的NavMesh啊。这个世界太大了，是的，程序A附和道，然后他继续在等待新的指示。主程叹了一口气。在叹气的这蓄须臾之间他想了很多，今晚的下班时间应该又是3点以后了吧；这个寻路的功能这么做下去恐怕要重新设计了；恐怕没法三言两语就把后续的走路时间给讲清楚，他自己还需要去思考更多；还有，他还想到了这项目再这么做下去，简直就是个无底深渊……

在另一条世界线上，Context线的故事，则完全不同，程序A还在会议室里跟策划讨论，这次的会议有点长，客户端组长已经忙别的去了。“这个功能，要用在哪？地下城？”“嗯，不止地下城，大世界也会有。”策划答道。嗯，地下城还好说，除了地形之外，其他跟崩三差不多，“那大世界是啥需求？怪可以随处跑吗？”“可以。”策划随口答道，这在他看来是跟其他毫无差别的需求，十分平常。而此时，程序A脸色沉了下来，见程序A没有爽快的接锅，策划同学眉头一皱，发现事情并不简单。“有什么问题吗？”他试探性低问道。“有，你确定世界这么大，怪的活动范围是不受限制的对吧？”程序A又确认了一遍。“是的，至少是可以被拉到很远的地方的。”策划回答道。“我先去了解一下NavMeshAgent的功能吧，现在还没法确定这个功能怎么做。”好吧，虽然PM要求的需求评审时间快到了，但此时好像也只能这样了。“那么有什么问题随时找我吧，如果有问题，我们也可以想想其他的解决方案”，策划说到。两人起身走到门口，策划突然停住了脚步，因为在他看来这个需求十分平常，不是所有游戏都是这样的吗？他觉得这个问题必须问清楚。于是他问道：“我们跟其他游戏在实现上有什么不同吗？”正在翻阅手机的程序A抬起头：“有很大的不同啊”，他放下手机，上面显示着NavMeshAgent的文档。他开始跟策划解释为什么有巨大的不同，平时少言寡语的程序A，像是打开了封印千年的话匣子，为什么要离线缓存多大的Mesh，如果Runtime计算会不会卡，异步Load我们可能要自己实践…，等程序A再次闭上嘴的时候，他自己觉得自己的脑中貌似已经有了一个大概的Solution了。策划一直听完了程序A的陈述，偶尔插一两个问题，虽然有些细节他不清楚，但大概意思是get到了。好歹我本科也是读CS的呢，策划自己心里盘算着。这场会议，终于在近两个小时的讨论后结束了。

后来程序A了解完了NavMeshAgent的功能向程序组长表示，直接来用并不靠谱，但在长期的沟通中，他们都清楚这个Feature还是必须要做完，再后来他们又去找了工具组，引擎组，大家一起讨论了一个改造NavMeshAgent的方案，基于各方面的支持，先实现了一版功能。然后，又是几周的迭代和反馈测试，才最终把这个功能稳定下来。

Context线的故事讲完了，如果你问我为什么中间没有写，策划SB吗？程序是不是老油条这样的桥段。我会告诉你，并不是他们多么的，而是他们在长期的沟通中，已经完全同步了。互相理解是因为，在同样的背景信息（Context）下，基于逻辑，得出了同样的结论。

为什么是 Context ？

相比Control，强调Context的管理模式有什么好处？

第一、分布式运算，让更多人参与决策，利用集体的智慧。对于组长，因为精力有限，做审批决策只花30分钟，但团队成员他们在一线决策有更丰富的外部信息，它可以花三个小时，做更多的调研之后才判断。

第二、可以更快速的执行，不需要层层汇总，不需要汇总到一处，不需要所有决策在CEO或制作人这里排队列，能够更及时的响应。

第三、充分的外部信息输入。在Control的模式中，任何信息都要到CEO这个节点，靠CEO再分发出去，CEO很大程度变成了公司和外部之间的接口，相比单靠CEO接触外界情况，了解市场行业或者外部环境，让更多的同事，更多节点直接面向行业，信息确实会更充分，角度也不一样。

第四、参与感激发创造力。做同样的事情，如果团队成员知其然，也知其所以然，会比只知道指令，做起来更有意思。这个对于发挥团队成员创造力是有帮助的。

第五、可规模化。Context的建设，表现形式可能是内部的系统，可能是知识共享文档，这些都是可以复用的，是可规模化的。而CEO和Leader们的时间、精力是有瓶颈，靠拼体力，脑力，耐力来解决，是有瓶颈的，是没有规模效应的。

当然，有时候也需要Control：

一、紧急情况和重点项目。比如重大的玩家口碑危机需要快速响应。重点项目也是如此，如果竞争对手已经逼近，这个时候进行分布式的讨论，自下而上的涌现，来不及解决问题，时间窗口很快就过去了。所以紧急情况和处理重点项目需要Control。

二、创新业务和新团队早期。如果一个新团队设立，或者一个新Leader刚加入，这个时候需要Control，新业务早期，需要更多支持配备资源的时候，也需要CEO统一协调，主导进展。

三、不匹配的职位安排。某个岗位的人跟公司理念差距很大，那么他的Leader也是需要Control来干预的，比如一个资深运营同学，之前一直是做强商业化产品，游戏运营以拉收入为主。那么他的Leader在早期也是需要Control的。

说到做到

什么是”说到做到”？

“说到做到”的意思是，在miHoYo内，以任何形式作出的承诺，都应该在承诺的时间内，保证质量的完成。承诺的形式可能是一封邮件、一个TAPD上的任务、一段微信上的聊天，也可能是在走廊里跟别人说了一句话：”诶，这个东西我今天晚上给你做好。”那么就要在你所承诺的时间节点保证质量地把它完成，这就是说到做到的意思。

为什么要”说到做到”？

说到做到是项目能够正常推进的最基本的执行力保证。

如果每个人的承诺不能够按时兑现的话。那我们就无法基于这个承诺去做一个更大的团队的计划，我们的产品计划就全都是空谈。

当然，作为一个数字娱乐产品，在软件工程中会碰到各种各样的风险，所以更需要我们可以科学的预估，科学的做出计划。

说到做到，就是这样一个十分基础的要求。

怎么做到”说到做到”？

1.先搞清楚任务需求，才能给出靠谱的承诺

在一项任务的讨论阶段。如果你对其中的目的、要求存在疑问时，务必当面提出来。千万别抱有”应该是这么个意思吧”之类的想法，很可能你的理解和现实会有极大的偏差。

有哪些基本信息是你需要明确的？

1）交付结果是什么？（是一个工作计划的邮件？完成一个功能的代码？还是下班的时候把空调关掉？）

2）交付的衡量标准，完成这项工作结果的程度。你们对好坏的衡量标准的认识是不是一致的？（能用？易用？友好？……什么程度呢？）

3）交付的截止时间，也就是我们常说的Deadline。

我们希望就算你的Leader或者合作伙伴没有很清楚地定义这些问题时，你也要和他非常明确地沟通清楚，因为这会直接影响到你是否能说到做到。

除了这些直接要求以外，任务和任务之间的上下游关系，是否存在配合这项任务的人等这些辅助信息，也都能帮助你更好的理解这项任务。在充分了解任务的背景信息后，尽可能把这项任务拆解成细分行动，并评估清楚每一个小行动所需的时间和资源，你才能给出一个真正意义上务实的、可达成的承诺。

2.对于没有把握的事，一定不要给出承诺

主要体现在三点：

1）当工作任务具有不确定性时，正确且安全的做法是：不要草率做出承诺。你应该把你看到的不确定性因素抛出来，并且主动去了解这些不确定的情况。

2）对于无法评估的不确定性问题，先进行尝试，摸一摸路，估计一个预研时间。等预研时间到了，或者有了阶段性结论，再进行下一步的评估。

3）绝对不要因为：碍于面子、Push自己不要拖延或迫于组长压力等愚蠢的理由做出你预期无法完成的承诺

特别对于新人，或者对于项目情况不了解的时候。请务必记住，不作出承诺才是最负责的做法。否则耽误的会是整个项目的进度预期，而不仅仅是眼前的这一个任务。

3.充分细分&累加时间，是一个靠谱的预估方法

为了能够评估出一个合理的任务完成时间，我推荐一个方法：

在充分了解需求的情况下把每一个需求和目标进行细分，细分到不能再细分为止，然后把这每一细分项的时间算出来，再把它们累加起来，应该会有一个相对靠谱一些的结果。一般来讲，一个细分任务的时间不应该超过2天时间。否则，我会认为这个任务一定有可以继续细分的空间与必要。

有话直说

什么是”有话直说”？

有话直说的意思是：在我们公司内，当你发现一个问题，或者感觉哪里做的不对的时候，唯一正确的做法是：找到这个问题的当事人，当面向他客观陈述这个问题，这个就是有话直说。

这个问题，可能是产品上的问题，比如说你觉得这个地方策划设计的不对，也可能是团队上的问题，比如说你觉得某个地方我们运转不对，或者说你认为某个人好像没有尽到应尽的职责。不论什么问题，我们都应该在看到这些问题后的第一时间当面有话直说。

为什么要做到”有话直说”？

有两个重要的原因：

1有话直说是通往卓越产品的重要保障；

2.鸵鸟姿态面对小问题，必将酿成大炸弹。

我分别来解释一下。

先说第一条：有话直说是通往卓越产品的重要保障。

在miHoYo刚刚成立的时候，我们几个创始入共同立下了一个规则：无论遇到什么问题，我们都要有话直说。有话直说并不容易，但是作为一家创意企业，有话直说是通往卓越的唯一途径。我们希望自己和miHoYo都能不断进化，而为了实现这一点，我们需要对彼此极度坦诚，有话直说。

因为我们知道任何一个人在团队里面，不管是制作人也好，是策划负责人也好，是美术负责人也好，都是有他的局限性的。简单来说。作为一个人，他一定有其擅长的地方，和不擅长的地方；有他特别容易关注的地方，和容易忽视的细节。所谓人无完人，人就是这样一种生物。但我们对于产品的要求是无限接近于完美的，那怎么办呢？必须通过一个团队来取长补短，互相弥补彼此的缺陷，发挥长处。那如何做呢？就是要在团队里面，可以听到来自不同角度的声音和意见，所以我们需要有话直说。对于任何一个人，当我们觉得他负责的东西有问题的时候，应该立刻告诉他，这样才能让他获得一个更全面的认识，避免个人视野的局限，帮他建立一个全面的认知。只有看到的问题全面了，再以严密的逻辑进行判断，才有可能做出比较好的决定。

这里有一个很有趣的现象。大家都知道，我们公司没有主美，主程这样的Title，而只讲美术组长，程序负责人。为什么呢？因为主x。往往会给人一种，他说了算，对错都由他来一言定之的印象。这样以难免个人影响太重，难免在获得部分正确判断的同时也放大了个人缺陷。而XX负责人，或XX组长则意味着：这个岗位的同学，负责组织整个团队一起来取长补短，发挥每个人擅长的事情，最终把一个问题解决好。他是组织者，也是负责人，但不等于其他人要言听计从。每一个人都拥有对自己负责事情的决策权，也必须遵循有话直说，开放地接收各种意见。

再说第二条：鸵鸟姿态面对小问题，必将酿成大炸弹。

在miHoYo短暂的发展史上。我们也曾经犯过类似的错误。冰冻三尺非一日之寒，大问题也都是因各种小问题没有被及时解决从而变得愈发严重。通常当问题还在初期阶段时，解决起来不仅成本小，方式也多。但如果问题没有得以及时暴露，经过不断积累，它会像病毒一样扩散，破坏面越来越大。这时再去解决它就可能会牵一发而动全身，付出的代价无法估量，甚至导致团队决裂、产品最终失败。

所以有话直说，可以保证在问题还比较小的时候就暴露出来，并把它及时解决。我们坚信，我们应当把问题和分歧摆到桌面上，从而及早地暴露问题，及时的解决问题。

“有话直说”该怎么做？

1.当面直接说，及时说，绝不在背后说

当看到任何项目上的问题、产品的缺陷、项目成员的不足的时候，当遇到跟团队其他人意见不合或者对某些事情做法不满的时候，唯一正确的做法就是找到当事人，当面跟他反馈、吐槽甚至吵架。直面所有的问题，有话直说，创造环境做直接的沟通，这是正确的做法。对任何公司同事，当面不会说的事情也绝不在背后议论。一个公司里直在讨论问题的场合没有声音而背地里有嗡嗡嗡的声音，就是不正常的表现。这种嗡嗡嗡的声音大都是以匿名、小圈子的形式存在的；小团体甚至是办公室政治的形成大多都是从两个人同时吐槽同一个对象开始的。背地吐槽对任务、团队、尤其是对你自己，没有任何正面作用。非但不会解决问题反而会增加问题的复杂度。

2.客观陈述，对事不对人

有话直说的文化有时候会让人不适，尤其在存在分歧的时候，我们有话直说的唯一目的就是让问题或者分歧暴露出来并朝着好的方向去发展。因此只有客观陈述事实，只针对”事” 本身才能推动问题的解决，针对”人”解决不了任何问题。

表达时怎么算是对”事”，怎么算是对”人”：

对”事”：对事情本身下判断（正确与否的结论）、给支撑结论的论据（问题定位）或提供处理方式的建议（解决问题的方法）。如”这打出来的伤害太低了（判断、结论），你的圣痕搭配得有问题（问题定位），换个”薛定谔上”输出会更高（解决问题的方法）” 。

对”人”：对人（人格、个性）产生攻击行为。如：”某某就是不行”，”某某完全不懂”。

3.直面冲突，求取共识

很多人以为，掩盖分歧是维持和睦最容易的方法，这种观点大错特错。回避冲突也就回避了解决冲突的机会；躲过了小的矛盾，之后往往会有大的矛盾，甚至会导致人与人的疏离。只有直面且积极解决小的矛盾，才会更好地维持长久的信任关系。认真处理分歧，有话直说，当事方之间开放、坚定地进行高质量的反复讨论，细心梳理所有问题的过程，这些方法都非常有用。因为它们有助于双方了解此前不清楚的情况，这是有话直说的另一层含义。

我们需要做三件事：

1）把我们的真实想法摆在桌面上；

2）存在经过深思熟虑的分歧，但人们愿意在相互了解的过程中更改观点；

3）如果分歧依然存在，拥有一种大家一致同意的决策方式（如投票或者拥有清晰的权威）。以便我们能够不带怨气地把分歧留在身后。

我们相信任何组织或任何人际关系想要保持的好，这些都是必需的。我们极力鼓励大家有话直说。直面冲突，求取共识。

4.保持开放心态，着眼大局

我们充分鼓励大家有话直说，但这并不意味着你提出的建议或吐槽就一定要被采纳和解决。影响一件事对错与否的判断因素有很多（可能是时机、获取背景信息的丰富程度、看待问题视角等等），但我们最终会把决策权交给具体负责这项任务的同学（他所掌握的信息不但是最全面的，同时承担的责任也是最大的）。当观点争执不下，然而事情还要继续推进的时候，就需要由这位决策同学出来确定路径并执行落地。如果决策已出，就必须要放下个人的异议（事后会进行决策复盘），全力以赴去达成目标。

针对有话直说我们总结一下，在miHoYo最让人痛恨的有这5种人：

1.马后炮的，事后会说”你看，当时我就觉得这地方不对……”；

2.当面不说，喜欢在背后议论人的，拉帮结派搞小团体的；

3.分不清楚什么是对事，什么是对人的；

4.好好先生，明明看到了问题就让问题烂着，而无动于衷的；

5.唯我独尊，个人意志高于集体意志的。

最后，必须说明，有话直说≠一人一票。

这是关于有话直说必须跟大家强调的一件事情：有话直说的目的是暴露问题。任何人提出来的意见，可能是对的，也可能不对。可能只是提问者自己的另一种局限视角。所以，有话直说绝对不意味着说了必须改，也不应该被滥用做少数服从多数。

我们一直以来的理念都是，谁在一线做这件事情，谁最了解一线的情况，谁来做决定，并为结果负责。有话直说，是为了帮这个决策者，更多的看到全局的信息与意见，然后让他可以在一个更丰富的信息下，做出更好的决定。

追求极致

怎么做才算“追求极致”？

有两句话请大家记住：

1.别人能做到的事情，我们一定能做到；

2.没有什么事情是做不到的。

这是有严密逻辑的两句话，而不是鸡汤，我们逐一解释一下。

先说第一句，别人能做到的事情，我们一定能做到。其实我们历史上一直是这么做的。比如说我们做崩2时，之前从来没有用过Unity，但是我们看到其他团队可以用Unity+ Maya来做出流畅细腻的纸片人骨骼动面，那我们就坚定地用同样的技术路线在iPhone4的机型上做出了一样能够流畅运行的效果。再比如说我们在做崩3卡通渲染的时候，我们之前也从来没做过3D游戏，但是.看到Guilty Gear卡通渲染效果做出来了，虽然它是在Play Station上，但我们觉得同样的方法在mobile平台上面做，基于iPhone6的硬件性能，其实问题也不大，所以说最终我们也确实在效果上实现了十分接近的卡通渲染表现。

那么逻辑上我怎么解释这个问题呢？上文中提到过，我们所处的是一个数字创意产业，我们所用的生产工具与这个地球上所有顶级的公司相比，没有本质差别。最好用的商业引擎，源代码我们都有，第三方中间件都可以买到，Open Source项目大家都能看到。然后生产所需的知识，我们能够接触到的也和全球其他顶级公司无异，开源的代码，最新研究的Paper与分享，这些都是可以公开透明看到的。那么在我们的生产工具和知识都跟别人基本一样的情况下，为什么别人做出来的东西我们做不到？我能想到的理由只有一个，我们比他们“笨”！但是miHoYo一直崇尚的是跟优秀的人在一起做优秀的事情，没有人承认自己笨。所以说我们没有理由说在这个世界上别人能做到的事情我们是做不到的。做不到的人，不应该在miHoYo。

再说第二句话，没有什么事情是做不到的。你可能会想这个实在是太鸡汤了，这个世界上怎么可能会没有什么事情是不可能做到的。

其实在我们看来，一件事能否做到，这是个态度问题。比如有人提出一个需求，然后程序说这个东西我做不了，这在miHoYo就是一个很严重的态度问题，因为这不是一个追求极致的做事方式和态度。一个东西不能实现，一定是有原因的。假设我极端的反问，给你200年时间，这个东西还做不出来吗？我觉得200年以我们目前的科技发展速度来看，很多现在幻想的东西都有实现的可能。那还有什么理由说做不出来呢？所以说，能做或者不能做，是一个在各种条件下才能判断的复杂问题，不是一句话不能做就可以草率下结论的。我们的目的是解决问题，而不是甩锅。

正确的沟通方式是，当我们遇到困难的时候，去讲清楚为什么在你看来它做不出来，这一定是有原因的。可能是因为，我们代码上有历史遗留问题，要实现这个需求，先要两周的时间来重构代码，然后再花三天时间来把这个feature做出来。那把这个情况讲清楚，就是正确沟通方式的。再比如，我们所做的一个设计，实现成本很高，会让运维成本翻5倍，执行的同学一看尿了，说这哪行，肯定不能接受，然后就说不能做。但可能这个成本正是我们乐意去承受的，因为它能够给用户带来的变化远比这个付出还要大，或者这个功能做出来就是产品的核心竞争力，我们就是要做不计性价比的投入。所以说，能做不能做，还是必须结合各方面信息来判断，而不能单方面草率下定论。只有把这样的问题抛出来，我们才能够分析出是否存在一个更好解决方案，可能存在work around的方法，绕过困难，又满足需求，也可能这就是一个要不计成本硬刚下去的核心功能。

我们现在正在做的项目，少则几十人，多则几百人，在一个这么大的一个团队规模下，任何人都无法看到整个项目的每一个细节。所以要做到产品结果上的追求极致，就要求每一个人必须把自己所做的事情做到极致。只有每个人都以追求极致去要求自己，把我们产品的每一个基本模块做好，最终合在一起，那才能最终成为一个极致的产品。

关于 To B & To C 账号体系的设计问题

Sun, 01 May 2022 06:00:00 CST

钉钉账号是个人所有的么？

答案是「否」，钉钉账号表面上是你自己的账号，但在企业的逻辑当中，这是「企业授权给你使用的」，本质上，这些都是企业的资产，企业是有权处置这些资源的。你所说的、所看的、所做的，都是企业提供的资产，企业可以根据自己的需求来调整这些资源的所在位置。

为什么钉钉和我们使用的微信、QQ 不同？

这是钉钉的不同的一点，在钉钉当中，任何一个账号，都是有对应的租户的（除了你的个人租户）。租户才是资源的所有者，我们只不过是使用者。而我们使用的微信、QQ 其实也不是我们的，在微信的用户协议当中写明了，我们所拥有的不过是微信账号的使用权。只不过，因为腾讯离我们很远，我们可以认为不会对我们执行任何操作（当然，实际上如果你发一些不和谐的内容，也会被设置为内容自见），但在钉钉中，租户的管理员可能就是我们身边的同事，在这种情况会更有「隐私」和企业所有的对比。

7.1.2 微信帐号的所有权归腾讯公司所有，用户完成申请注册手续后，仅获得微信帐号的使用权，且该使用权仅属于初始申请注册人。同时，初始申请注册人不得赠与、借用、租用、转让或售卖微信帐号或者以其他方式许可非初始申请注册人使用微信帐号。非初始申请注册人不得通过受赠、继承、承租、受让或者其他任何方式使用微信帐号。

综上所述， 你的账号，并不属于你。

信安之路入坑指南

Sun, 12 Jul 2020 19:37:43 CST

疫情下的高考已结束，又快到填志愿的时候了，又有不少知青要加入信安这个圈子。为了响应组织号召，撰写此文作为信安行业的入坑指南，希望能对刚入圈的同学有所帮助。

如何入门学习

1、明确目标，并以目标为导向，用以致学

刚开始的时候，相信很多人会先去搜索信息安全要学什么课程，可能有人会告诉你要先C，再学数据结构和算法，学数据结构和算法前又要学离散数学，总之会有无穷无尽的东西在等着你，导致最后自己都不知道该学啥了……

其实学习什么课程都只是手段而已，但你学习这些课程的目标是什么需要先明确，比如想去国内个的漏洞奖励平台刷web或软件漏洞拿奖金，或者报个CVE漏洞，开源个安全项目等等，这样目标和动力就都有了。

2、细化目标制定具体的学习内容

假设你的目标是挖腾讯PC软件漏洞赚奖金吧，那腾讯PC软件有啥，电脑管家、腾讯视频、QQ、QQ影音等等，先选个门槛低点的QQ影音吧，目标就细化成挖掘音视频文件解析软件的漏洞。

挖掘文件解析漏洞的技术就涉及代码审计、Fuzzing、逆向等等，再细化下目标，挑Fuzzing吧。

入门Fuzzing涉及哪些系统性的技术内容呢？可以拿国外知名大会的培训课程为例，比如BlackHat、CanSecWest等等，这里以CanSecWest上的 “Advanced Fuzzing and Crash Analysis”培训课程为例:

https://cansecwest.com/dojos/2019/vulndisco.html

4天的培训课程计划已经给出了循序渐进的学习内容，你只需要多利用搜索引擎去查找相关的书籍、论文、工具进行学习和实践。

比如课程给出的前置条件：

Students should be prepared to tackle challenging and diverse subject matter and be comfortable writing functions in in C/C++ and python to complete exercises involving completing plugins for the discussed platforms. Attendees should have basic experience with debugging native x86/x64 memory corruption vulnerabilities on Linux or Windows.

涉及C/C++、Python和汇编，这里就需要先去找相应语言的经典书籍先入个门，至少保证先看得懂代码。

再看第一天的课程目录，用相关标题去搜索就可以得到相关的知识点，比如AFL、libFuzzer、Corpus generation等等，遇到不懂的就是一个知识点，自己设法去弄懂并实践它就是学习的过程：

整个示例过程总结起来就是：

挖腾讯漏洞赚钱 =》PC软件 =》QQ影音 =》文件Fuzzing =》培训课程目录 =》搜索相关书籍、论文、工具进行学习

其它目标的学习内容制定类似，包括web渗透、内核攻击等等。

3、无限循环：学习=》应用=》反馈=》学习

完成第2步的学习之后，就去实践（示例：挖QQ影音的漏洞，或者其它已公开的漏洞的挖掘验证），看能否挖到0day或1day，若不能就针对公开漏洞的信息继续改进优化，再验证效果，以此不断循环，直至相信这是体力问题，也不是能力问题。

这里以二进制漏洞学习为例，但其它领域web、IoT方向都均适用。学习过程遇到迷茫，很多时候只是不知道目标和手段（学习计划等）之间的关联性而已，设法找到它，并细化到可执行的内容，再设置一些里程碑目标（比如重现历史漏洞的挖掘过程）来增加自信心，最后就是持之以恒下去。

关于CTF

在学校时，有机会就多去打打CTF，提高实战能力，国内不少课程内容都比较落后，现在也有一些高校会直接采用工业界出版的一些书籍作为教材，也是一种进步。

一本书的出版经常代表着其内容已经过时，除了一些计算机基础书籍，比如C/C++、编译原理、系统原理等等这些，即使再过10年也不会过时。其它很多技术会随时时代变迁，技术日新月异，而CTF题目往往会跟着技术热潮来变更，在学习基础的同时，又能帮助跟上技术的更新变化节奏。

学习工具推荐

印象笔记、Mendeley、Inoreader是我最想推荐的三款工具，均有跨平台客户端，以及浏览器插件，数据在多平台同步，搭配使用非常方便。

关于Mendeley和Inoreader的使用，我也曾写过文章推荐，详见《谈谈追踪前沿学术研究的技巧》和《RSS-优秀的个人情报来源》

平时我Inoreader订阅RSS，用印象笔记来收藏文章，用Mendeley追踪学术论文，并在上面作笔记，方便未来查阅和复习。另外，Mendeley还有个功能，就是会根据你所收藏的论文，去推荐更多相关技术的论文，比如参考文献中的内容。比如关注Linux Kernel Fuzzing，那么它会推荐更多的内核Fuzzing论文给你，如果有公开的PDF下载，还可以直接通过它索引下载，这种学术论文的追踪并不是印象笔记能比的。个人主要是用印象笔记来收藏一些非学术论文的文章，还有一些工业界安全会议的ppt等等。

对推荐书单的补充说明

之前笔者曾发过”信息安全从业者书单推荐”（ https://github.com/riusksk/secbook），相信很多圈内人看过，期间也很多人提问过，这里整理补充说明下。

配合书籍，注重实战：列举那么多书并不是想让大家从头翻到尾看完，而主要是向大家推荐一些我曾经看过并觉得较好的书而已，大家自己根据自己需要选择即可。同时，理论归理论，很多东西需要配合实战，光看书也没用，依然建议大家试试”用以致学”的方法。
书单并非网上收集列举的：由于书单较多，有不少人质疑只是把网上有的书随便收集罗列下而已。之前在github回应过，这里再说明下。书单均是个人看过或者业界认可的经典书籍（部分书籍没全看完，但不妨碍对书籍质量的判断），跟网上罗列的安全书单不同，并非把网店上的各安全书籍都罗列上的。如果你有何好书推荐可在 Github Issues上提交合并，待我看过之后，如果觉得可以就会在此处更新，会在Github上不定期更新书单。
关于阅读时间的问题：多数人一看到书单，就会问这些得多久才能读完？我觉得没必要纠结于此，有空有兴趣就挑本书看下即可，读书没必要把它当作一种负担，保持细水长流的方式，持续学习就好了。如果真的说时间的话，我从06开始学习安全，到今天差不多14年，14年读完那些书，我觉得问题也不大，但关键在于自己掌握了多少。我建议抛开时间、数量的考量，遵循自我内心的喜好，保持学习即可。
书单仅代表个人喜好：不同人对同一本书通常会有不同的评价，这里仅代表个人喜好，你可以有不同的看法。比如有些人曾推荐过《逆向工程核心原理》，但我觉得它内容过旧，且没有《加密与解密》写得好，所以我一直没入书单推荐。但你觉得此书对你有帮助，那就保持你的这份喜好，不必执着于书单本身。

股票市场

Sat, 20 Jun 2015 18:09:23 CST

国内市场本质还是一个投机市场而没有价值投资，市场监管机制本身的不完善和信息的不对称性，注定了散户本身的弱势地位。任何上涨时候的疯狂伴随的都是暴跌时候的毁灭，正是由于这个原因更应该要做到尊重市场和趋势，对市场时刻保持敬畏之心。

对于自己的判断要勇于认错，当持有的股票出现下跌时候，我们习惯性的是找寻支撑该股票上涨的理由或做着不合理的价值分析，即我们不断为自己错误的判断找理由而不是尊重趋势尽快的认错，最终而出现深度的套牢或者亏损，措施下次的机会。

在一个牛市里面，所有的人都赚钱了好像并没有人亏损。但是一定要注意当你持有的是股票的时候你的盈利始终都是账面盈利即浮盈而不是最终真正的盈利。即使你持有的是股票账户的现金只要没有完全脱离市场，你所有的盈利都有可能迟早还回给市场。股票市场是一个相当体验人性的地方，即贪婪和恐惧，自己盈利或者看到他人大幅盈利的时候往往都考虑的是如何挣的更多，或者融资或配资加杠杠快速的盈利和一夜暴富，所有的贪婪或对市场本身的不尊重最终都得由自己买单。

尊重趋势，不要轻易抄底，尽量做右侧交易，不要去做超短或者做打板的涨停板敢死队。真正能够超短快速盈利的人少之又少，即使在牛市里面我们也会看到做超短的人往往出现账面亏损。

不要根据技术分析炒股，但是并不是说技术分析本身不重要，最基本的K线分析，量价分析，均线分析往往还是要熟悉和掌握，技术不是绝对，也可能出现分析错误，但是对于股票本身的涨跌大趋势，量价突破等仍然会体现在技术指标上面。

任何股票都应该有一个合理的估值，这个估值本身涉及到公司的总市值，成长性，市盈率，同行业，跨行业等一系列比较的内容。比如我会看到创业板很多公司市盈率上1000倍，市净率上100倍，一年的营收1个亿但是股价上100，对于这种情况即使再好的成长性也无法支撑合理的估价和市值。一个公司的估值，不要单纯的看股票价格和市盈率，更加重要的是股票当前的市值，以及当前市值和跨行业的其它公司的市值比较。在这次的牛市初期你可以看到很多公司的股票市值在10个亿左右，但是现在整个市场已经很难找到股票市值在40个亿下的公司。即使公司经营亏损，净资产为负但是由于本身重组概念市值也可能高高在上。

当然整个股票市场市值在60-70万亿，已经超过过整个GDP，或者说已经到了一个相对高风险的区域，即使当前没有突破08年6124的高点，但是实际上80%的股票已经早翻了多倍和创了新高，即整个风险和估值体现是远远超过了前期高点。这轮牛市超越6124虽然是一种必然，但是你会看到情况上即使超过了6124点，很多股票在当前已经早已经完成驻顶，或者说很多人在牛尾已经不可能再赚钱。

要知道任何对前高的突破都会带着放量才会成立，而成交量的放大都是需要真正的新的资金进入，这些都是真金白银。包括当前持续的IPO发行抽水，对场外配资的打击和禁止都直接影响到增量资金的流入。同时当出现下跌的时候极其容易造成恐慌和踩踏。当前的大量融资盘和场外配资确实是插在这轮杠杠牛市下的一把尖刀。

我们习惯于听消息炒股，很多人也都变成了股神，但是在整个前期牛市的市场里面你会看到，即使你不听消息买人而是避开大金融和有色随机的买入一支股票，其涨幅本身并不会有太大的差异。即牛市的本质还是会轮涨，包括最终低价股的消灭。即使你不听消息炒股，而是尊重趋势长期持有效果是一样的。这轮牛市相信很多人的感慨都是换来换去最终的收益远远小于前期捂住一只股不动的收益高。

股票市场投资的第一规则是避免亏损，第二规则请参考第一规则。这轮很多老股民可能都没有胆子大的新股民赚的多，但是真正能够在市场存活的还是老股民，因为很多经验真正是血汗钱换来的。宁愿少赚点也要控制节奏真正做好仓位管理，能够按照自己既定的策略进行操作。懂得止损很重要，但是懂得止盈同样重要。什么时候真正花钱买了教训，真正能够做好仓位管理，能够学会空仓，而不是天天的追涨杀跌往往才开始第一步。

自选一个自己的股票池长期跟踪，只做自己熟悉的股票并长期观察，而不是随意的跟风和盲从，你关注的股票越多往往就很难把每一只股票的股性分析清楚。长期反复的做精几只股票往往获取到最大的收益。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

敏捷

Sat, 06 Sep 2014 13:02:52 CST

对于敏捷开发，我前面其实已经有很多文章提到了，再次强调下敏捷的核心思想个人理解为三个重要的方面。其一是需求的条目化并以需求点进行的全程追踪和跟踪；其二是短周期迭代；其三是基于持续集成思想的进度和质量可视化。

对于敏捷开发本身，对于很多内容我仍然坚持自己的观点，具体如下：

对于大型全新系统的开发，如果是以底层数据为核心的业务系统，则不能单纯的应用敏捷开发。这类系统对全局业务建模和数据建模的要求会更高，以保证架构完整性和概念一致性。而不是任务已经并行分配下去，出现问题了再去做调整，敏捷的短周期迭代不是做这个用的。这类的总体设计个人理解主要包括了子系统或模块的划分，接口的识别，底层全局数据概念模型，这些必须一开始就要搞清楚。

对于新组建的团队，团队成员相互不了解或能力差异过大，团队没有历史项目实践的磨合和经验积累，没有比较成熟稳定的技术框架时候，建议慎用敏捷开发。敏捷开发是迭代计划和版本，但是当前的迭代版本仍然是需要我们能够做出合理的估算，而不是存在大量的不确定性。

敏捷开发里面有一个重要的实践，即CI持续集成，这里面会涉及到单元测试，但是这不是XP极限编程里面的TDD测试驱动开发。有人认为没有采用TDD就不是敏捷开发是相当教条型的错误。即使再CI持续集成和每日构建，冒烟里面我们仍然是多种做法。一种是只写能够冒烟测试通过的少量单元测试用例，一种是只对按界面展现和逻辑实现横向分工的团队要求对于技术组件接口的朝外提供要首先写单元测试代码。TDD测试驱动开发真正能够实践好能够坚持下来的多内基本很少，这个根本就不是熟悉了TDD就能降低工作量的问题，其次对于希望通过写测试代码来想清楚需求的方法不推荐，需求是需要可验证但是不代表必须测试代码能够写清楚需求才可验证；再次单元测试往往比较难到UI和展现层，即使有Junit自动跑了还是需要人工测试，这个工作量并没有省。

敏捷方法论本身的思想是重视沟通和协同，减少不必要的文档，因此敏捷并不是没有文档。当前还是很多人认为通过实施敏捷方法可以不写文档，认为文档没有用处这又是走到一个极端。那么什么叫不必要的文档？个人理解其一已经在项目团队里面形成规约性质的内容，则已经有历史规约可以追溯到；其二是各种日常沟通协调中形成的讨论，记录，白板等内容，不会太注重规范格式但是要能够记录下来；其三是对于他人看你的源代码就能够理解清楚的东西不必再文档化。

想到哪里就做到哪里，拿着需求点就马上去做，出现问题了不断的返工和修改还美其名曰重构，通过敏捷为幌子来逃避写文档，虽然第一个迭代快速能出来但是产品能够真正上线运行进度周期反而成倍增加，再者或强调我们是敏捷每周40小时工作时间。这些都是中敏捷的毒太深，还是那句话，传统的类似瀑布的软件生命周期模型都没有应用好，能够把敏捷应用好是不可能的。团队人员本身编程能力和经验就差距较大，对自我能力和生产率评估也很弱，相互也不了解情况下能够简单的通过敏捷来纠正这些问题也是不可能的。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

DigitalOcean使用小记

Sat, 18 Jan 2014 23:28:56 CST

晚上看到微博上的@developerWorks同学推荐 DigitalOcean, 赫然发现自己使用 DigitalOcean大概也一年了(2013年2月28日开始），自从前段时间把52nlp搬牵过来之后，我在国外的vps就只有 DigitalOcean了。所以在微博上简短回复了一下：

上半年就开始用DO了，52nlp前段时间也搬到DO了，用的是10美元每月的Plan, 彻底告别了linode。

自从08年底52nlp开张以来，依次用过便宜好用的虚拟主机host2ez, 朋友免费赞助的小空间，Godaddy上免费附赠的空间（但是带广告），国外的老鹰主机（Hawkhost)，以及用信用卡注册免费使用一年的AWS（但是一直没用上），直到遇见口碑极高的Linode，花上20多美元/每月搞一个完全自主拥有root权限的VPS（Virtual Private Server）后，发现自己已经离不开VPS了，虽然没有了Cpanel之类的控制面板可用(貌似也可以自己安装），但是更享受这种完全自主的命令行控制和Root权限。之后接触并玩过的VPS还有目前使用的阿里云和 DigitalOcean。

Linode大概使用了有两年，期间几乎没有出过什么问题，感觉非常棒，不过印象去年也是微博上某个朋友推荐我用 DigitalOcean，号称配置SSD VPS（ SSD cloud server， SSD云主机），了解了一下它的配置，发现最低配5美元/每月的Plan（512MB内存，1核，20G SSD硬盘, 1TB流量）和我每月20多美元的Linode Plan的配置基本旗鼓相当（不过目前linode最低配已经升级为1G内存…，印象也是这一年期间逐步加量不加价的，有竞争就是好啊），不过国外便宜的VPS有很多，不能因为便宜就放弃Linode，所以在没有放弃Linode的前提下选了一个 Digital Ocean中最便宜的5美元/月的Plan玩一下，在这个上面诞生了“ 我爱公开课”，“ 挖课”等网站，也跑了一个python flask网站，课程图谱的前身： CourseraReview，从2013年2月28号到目前为止，基本上还没有出现过什么问题，感觉还不错，也欢迎大家体验这几个网站。

2013年年底，终于决定告别用了2年多的Linode，不是因为Linode不好，而是性价比没有 DigitalOcean好，刚好这篇对比DO和Linode的英文文章“ Digital Ocean vs. Linode”也道出了我的心声，这哥们也使用了2年的Linode，但是最终决定告别Linode，投向 DigitalOcean的怀抱。所以除了之前5美元的vps外，我又为52nlp选了一个DigitalOcean中最流行的10美元/月的Plan或者官方说法是”Droplets”，下面是我的后台截图，2个DigitalOcean Droplets：

这是10美元/月 vps的配置情况，选的是NewYork 2机房，安装的是Ubuntu 12.04 64位服务器（这个注册购买Digital后可选很多Linux服务器）:

DigitalOcean的后台相对也很简洁，image下可以手动备份VPS镜像，自动备份需要付费（大约是你所用Plan价钱的1/5), 下图是一个自动备份记录：

SSH Key菜单下是教你如何添加ssh key建立2台机器之间的互信，以后通过ssh登录VPS不需要再次输入ssh密码：

Billing是 DigitalOcean计费的页面，包括当前使用情况以及历史记录，DigitalOcean貌似允许欠费，另外相对于Linode每月月初就收费的情况，DO是按照小时计费的，相对灵活很多。这是我的账单页面，是从13年2月28号开始使用的，用Paypal付款，另外直接用双币信用卡付款也行：

Support页面是寻求 DigitalOcean工作人员帮助的地方，这个很重要，即使是VPS，也不能保证不会出任何问题，万一遇到个啥问题挂了，如果联系不上客服就麻烦了。DO虽然是初创企业，不过这一块儿做得挺不错的。目前为止，我提过两个不是很紧急的问题，一个是咨询如何直接用信用卡付款的问题，另外一个比较有意思，就是在购买第二个10美元配置的vps时，我先通过google搜了一个DO的优惠码（coupon)，这个优惠码显示可以省10美元，但是需要注册一个新的账户，我尝试在我这个老账号里使用，发现没有填这个优惠码的地方，就通过Support页面的New Ticket咨询如何使用？大概10分钟之类就收到回复，不过意思是很遗憾，老账号不能使用，只有新帐号可以使用，不过神奇的是在我的billing页面又显示我多了10美元（有邮件通知），所以这个优惠码还是生效了，估计是工作人员直接操作的，所以大家要是有优惠码的问题，不妨骚扰DO的工作人员。以下是我的support页面：

关于优惠码，可以通过goole “digitalocean coupon” 发掘，我上次就是google了一个”thechangelog10″, 不知道现在还能用不？另外微博上@devloperWorks同学爆料：DigitalOcean 继续给力！10美元免费送！最新优惠码：2014SSD 已亲测，可用。只对新用户注册有效，想买 VPS 的同学可以关注下：

关于 DigitalOcean优惠码，稍微再补充一下：

1、DigitalOcean官网：https://www.digitalocean.com/

2、登录DigitalOcean后，点击添加信用卡。

3、然后在右下角输入免费赠送x美元的优惠码：例如2014SSD，稍等一会儿就可以直接返回到Billing中看到自己已获10美元了。

至于DNS，API之类的目前我还没有用到，这里就不介绍了。关于 DigitalOcean的注册，今日到官方主页后，点击Sign Up后输入你的邮箱和密码即可，之后blabla的按照流程做即可，如果还不明白，可以看看下面这个“ digitalocean注册及使用简单教程”，这里就不详述了。

好久没有在这里扯淡了，今天晚上看到微博有感而发，从去年年初开始使用DigitalOcean，到目前为止DigitalOcean上超过100万个server在运行，深感口碑的力量之强大。最后再说明以下，这篇文章里嵌入了 DigitalOcean的推介链接，这也是国外一种常用的商品推介模式，如果您通过这个链接注册DigitalOcean并成功消费10美元，这里将得到一点refer money, 也非常感谢您的支持。

最后关于DigitalOcean, 以下摘自 36氪的一点介绍：

Digital Ocean 成立于 2012 年，是一家从 TechStars 孵化出来的云托管服务提供商。其特色服务是提供快速的固态硬盘服务器，宣称可在 55 秒钟搭建好一台云服务器。所有的服务器均拥有 1G 的网络接口，每月基础套餐为 1TB 流量，超出部分按每 GB2 美分计算。公司还提供了灵活的 API 供客户控制其私有虚拟服务器。控制面板也相当直观易用。目前在 Digital Ocean 上部署的服务器数量已达 34.6 万（注：现在以超过100万），公司目前每天新增的订户约为 500。

注：原创文章，转载请注明出处“ 我爱自然语言处理”： www.52nlp.cn

本文链接地址： http://www.52nlp.cn/digitalocean使用小记

最好的外语学习软件——Rosetta Stone

Thu, 12 Dec 2013 18:08:07 CST

在我接触的众多外语学习软件中，罗塞塔石碑（Rosetta Stone）是最好的，没有之一。无论是对于初学者的启蒙，还是对于已学过的矫正提高，都颇具效果。他是一款采用直接教学法的语言学习软件。如果你想学习美语、英语、日语或其他语言，在这个软件里只能感受到所学语言的图像、声音和文字。没有任何其他自己母语的帮助和参考。因此，使用这个软件可以像学习母语的环境来学习外语。

罗塞塔石碑的故事

罗塞塔石碑（英语：Rosetta Stone，又译为 罗塞达碑），是一块制作于公元前196年的大理石石碑，原本是一块刻有古埃及法老托勒密五世（Ptolemy V）诏书的石碑。但是，由于这块石碑同时刻有同一段内容的三种不同语言版本，使得近代的考古学家得以有机会对照各语言版本的内容后，解读出已经失传千余年的埃及象形文之意义与结构，而成为今日研究古埃及历史的重要里程碑。罗塞塔石碑最早是在1799年时由法军上尉皮耶-佛罕索瓦·札维耶·布夏贺（Pierre-François Xavier Bouchard）在一个埃及港湾城市罗塞塔（Rosetta，今日称为el-Rashid）发现，但在英法两国的战争之中辗转到英国手中，自1802年起保存于大英博物馆中并公开展示。

罗塞塔石碑学习软件的特点

罗塞塔石碑（Rosetta Stone）这个软件是十分优秀的语言入门级软件。与一般方法的不同是：他没有直接告诉你什么是对的，你需要靠猜，反复猜，而且复习机制很不错。石碑的优势是锻炼你的英语思维，石碑并不能像词根词缀记忆法那样让你记住很多单词。事实上，甚至你还有很多单词不会拼写，他强调的是一个沉浸式的语言环境，所以， 这是一款用于真正学语言的软件，而不是应试的软件。

里面分为：

核心课程（包含本节主要内容，形式：用鼠标选择即可，没有发声、拼写。）
发音（以鼠标选择的形式）
词汇（以鼠标选择的形式）
语法（以鼠标选择的形式）
阅读（用mic读，不推荐。解释在后）
写作（用鼠标点击屏幕上的软键盘，来拼写单词，不推荐。解释在后）
听力（以鼠标选择的形式）
听力与阅读（以鼠标选择的形式）
口语（以鼠标选择的形式）
复习（以鼠标选择的形式）
重点（四节课一次，以鼠标选择的形式）

例（听力）：
现在，软件发出一句话： “this swimming pool is inside。”

你点击中间下面的图片（ this swimming pool is inside。）那么，系统会给你一个类此庆祝的声音。并在图上打个勾，然后下一个。

若你点击，不是中间下面的图片（ this swimming pool is inside），那么，系统会给你一个不怎么好听的声音，并在你选择的图上打叉，并重新读一遍，让你再次选择。

漏屋老师在他的经典著作《找对英语学习方法的第1本书》中推荐了塞塔石碑（Rosetta Stone，中文名译作如意通），我在我的微信公众号（wangyueblogging）中也进行了详细地介绍，而在此之前，我就已经在使用这个软件进行美式英语学习了，感觉很棒。

如何获取罗塞塔石碑学习软件

罗塞塔石碑在中国有官方网站，可以在那里购买和下载学习软件，一门语言4-5阶段，价格在7-800元左右，软件支持 PC 各个版本和 Mac。

望月推荐你购买正版，不过，在网上也有一些破解版。比如，VeryCD 上搜索罗塞塔石碑有 PC 版的资源。对于 Mac 用户，Google 一下『罗塞塔石碑 Mac』同样可以获取许多资源。

支持作者 | 媳妇的淘宝店

也许您还喜欢：
小众软件评选之我最喜欢的软件	如何找到靠谱的电脑软件	我眼中的安卓手机装机必备软件	2009世界顶级杀毒软件排行榜及下载	杀气腾腾的国产杀毒软件
无觅

谈缘创派创业项目-1

Sun, 08 Dec 2013 09:12:40 CST

校园通移动APP

这是很好的一个基于校园强SNS关系的移动应用平台。但是又不仅仅是基于强SNS关系，而是增加了校园相关资源的整合和发布。现在看到的是一些学校已经是官方的名义在做类似的应用，这类应用没有学校官方的支持是很难做的，仅仅是单纯的SNS就没有了相应的竞争力，无法整合学校的各种平台资源。其次这类应用很难做一个对所有学校都适合的SaaS应用模式，各个学校能够提供的平台资源本身差别就很大，导致这类应用较难形成一个快速复制的模式。

问答机器人移动APP

这类应用真正做好了的话就是完全的基于问答模式的信息聚合，对于移动端用户来说根本无须安装各类移动APP，从哪到哪如何坐车？附近有哪些银行，餐馆？某地的天气如何？某种产品有无推荐？有哪些玩的地方推荐？可以讲这类应用难的不是LBS位置服务和相应信息，而是难在语义分析和快速响应。

现在可以看到微信服务号有些可以开始做问答，后面的趋势则是对于常用的公众服务类问答能否真正的整合，对于最终用户来说只有一个问答入口，问答平台怎么去进行语义分析，怎么整合大量的开放平台提供的开放能力，怎么进行知识的聚合和结果的输出，不是用户关心的事情。这是基于问答的很好的自服务的模式。

智慧家居和移动端控制系统

这是一种涉及到移动互联网，视频监控，物联网等多种技术在智慧家庭的一个整合。这种产品和系统首先有一个应用前提就是高速低价的移动互联网网络。还有就是极其简单的购买，安装和使用成本。大家可以考虑下类似于小米电视盒这种类型的应用，这个不仅仅是价格上的优势，更多的是使用的简单和方便。如果这类系统最终的结果是需要大量的上门安装和实施，那就不可避免的成为规模化推广的瓶颈。而对于垂直领域的高端社区，别墅，已经有不少的专业化公司在做这种智能化家居设计和实施。

当我们在做市场需求分析的时候一定要区分出两种情况和用户群，一种用户是这类产品确实很好，需要每天都去用，不用都觉得少了点什么；还有一类是刚开始觉得很好奇，买来用几天感觉也不过如此，不用也没有觉得少了点什么。这有点类似原来谈过的kano模型，对于移动家居控制系统来说很多用户实质是属于第二类。

易工厂和企信

很好的一个产品，从企信到开发的易工程BaaS平台，可以简单的理解为基于企业强SNS关系的一个基于微信模式的一个强聚合平台。微信能力本身不是重点，而是这种基于沟通协调为主体的强应用聚合能力才是重点。在腾讯QQ阶段并没有妨碍到企业IM即时协同的发展。因此有理由相信这种垂直领域模式有发展空间。

但是要注意到的是企信这种产品最终将成为企业信息化移动应用APP端的一个重要聚合。其本身只是一个平台，更加重要的是各种业务应用在这个平台的聚合，前期的重点可能只是协同办公，但是随着平台的发展，只要保留这种开放聚合能力，各种业务应用都可以以小APP的模式聚合进来，这是企业信息化应用移动端的一个重要入口和全新的移动端应用的构建模式。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

谈教育培训云

Thu, 17 Oct 2013 22:05:09 CST

2012年听说是MOOC年，MOOC是Massive（大规模的）、Open（开放的）、Online（在线的）、Course（课程）四个词的缩写，指大规模的网络开放课程。它是由很多愿意分享和协作以便增强知识的学习者所组成的。斯坦福，麻省理工都推出有自己的MOOC平台和课程，最近看到清华大型也推出了学堂在线，也不断的在开发新的在线学习课程。互联网发展了这么多年，远程e-learning一直没有得到很好的发展，绝对不是培训平台本身的问题，而更多的是开放理念的问题，是源源不断的课件内容的提供的问题，是大家对互联网在线教育和学习模式的逐步适应的问题。

互联网的在线培训教育既可以根据专业垂直业务领域整理完善的知识体系架构，安排系统的学习路径和知识路线，也可以是问题驱动下的点状学习。过分强调系统性将丧失平台的灵活性和交互协同性。同时这种培训平台同样需要理解web2.0的核心要素，培训平台搭建完成后更多的是群体化的培训课件的创作，是培训学员间的交互和协同，这可能才是培训平台得以发展的动力。既然类似知乎这种问答平台能够逐步被大家接受，在认知盈余理念下有更多的人会愿意进行知识的分享，那么就逐渐酝酿了培训云平台发展的基因。

培训云最终仅仅是一个平台能力的提供，通过这个平台是需要将培训的课件内容提供商，培训讲师，培训学员逐步迁移到这个平台上，形成一种多方的协同和自学习的氛围和知识圈，这就是培训云平台的生态环境。这个生态环境本身是自适应和自我发展的，不用太担心培训内容的创作和提供，只需要关心形成SNS下的协同和交互模式，以加强培训平台本身的强粘性。

培训教育云本身不是完全替代传统的教育培训模式，而是对已有教育模式的延伸。形成一种自我学习，终生持续学习，随时随地学习的一种学习网络。一种远远超过原有的线下培训教育模式下更大的虚拟培训学习圈。没有互动和协同的培训最终会被新的线上培训+协同分享+线下实践的新模式逐步代替。

培训教育云同样可能根据专业领域，根据各种层级进行细分。包括我们看到的黄岗教育云谷模式，类似多贝教育的全开放模式，针对某一个群体和行业认证的培训云平台，一些教育培训机构推出的半封闭培训云平台。在企业内部我们往往可以看到企业大学和企业内的培训教育平台，这种培训教育平台同样需要借鉴刚才说的互联网培训平台和web2.0，sns的思路进行改进，以解决原有的单向和封闭性局限。

虽然题目叫教育培训云，但是我们并没有太多去关注教育培训平台的底层云技术架构，这个并不是关键内容，更关键的教育培训后续的基于互联网的开放运营模式和新的教育培训生态环境。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

知乎问答-知识结构怎样组织更合理

Mon, 14 Oct 2013 14:58:05 CST

一个抽象的问题，那就用较为抽象的方式再做一次回答。前面已经有很多谈知识结构和知识管理方面的文章，也谈过知识结构的组织和整理，这里也借助该问题再做一次思考。

首先什么是知识结构？简单点来说就是一个知识体系，它里面包括了知识的组成，知识的层级关系，知识点间的前后依赖等。一个知识结构应该是覆盖了某个专业的知识领域中所有相关的知识点，即使用该知识结构中所涉及到的知识我们应该具备解决专业领域问题的能力。

单独来看知识结构这个词，容易理解为静态的一个呈现，类似我们说知识树，因此容易想到的最直观的呈现方式还是思维导图，其本身就是一种知识树的呈现方式。但是要意识到的是没有对一个知识域的全面理解，没有大量的零散知识的收集和整理，没有系统的学习和实践是很难整理出一个完整的知识结构的。思维导图这种组织方式看起来很简单，但是要考虑知识如何分类分层，哪些是在同一个层级，知识之间是什么关系就相当不容易了。所以题目的问题往往并不是说采用思维导图，而是根据已有的知识积累如何形成一个合理的思维导图，能够体现出你清晰的逻辑思路和知识架构。

思维导图本身最接近知识树，但是说到底它是一种单维度的知识逐层展开的描述方式。而很多时候我们面对的知识体系往往存在2个或更多重要的维度，比如对于项目管理体系，往往存在9大知识领域和项目生命周期过程两个重要的维度，在这种情况下简单的通过思维导图描述往往并不是最好的方式。因此在这种情况下建议最好的方式还是矩阵方面描述，矩阵两边是重要的两个维度，表格中间是具体的知识点信息。这样可以让我们对知识的组成结构有一个更加立体的展现。

上面说的都是较为常用的知识的静态组织和展现形式，但是我们可以考虑下为何要整理知识结构，仅仅是为了对于某个专业域的知识体系有一个全局的认识和理解吗？答案显然不是，我们整理知识结构还有一个重要的目的就是能够应用某个知识结构去解决特定的领域问题。那这里就有一个重要的问题，即知识如何用？当你考虑到这点的时候，知识结构自然转移到了通过流程或方法论的形式来组织的。

庖丁解牛，不仅仅是要了解牛的组成结构，更加重要的是要了解到应该如何下刀，先后顺序应该是如何的。因此对于知识结构的而言采用动态的流程或方法论的思路来组织往往是更好的方式。要知道流程往往就是做事情的方式，解决问题的方法或步骤最终也是流程。流程分为阶段或子流程，具体的活动等，而我们的知识点往往则会附属在这些流程和活动节点上面。在每个节点上面我们需要输入什么，输出什么，需要借鉴什么标准规范或模版，需要人具备的技能都可以描述清楚。

我们可以借鉴cmmi方法论的一个重要方法，即是首先是端到端流程或生命周期方法论驱动的一个总体知识体系全图，然后分解到具体的过程域（关键知识域），对于每一个知识域而言，都需要包括标准模版，培训教材，工具技术，指导书，检查单等各种文档资料。所有的内容都会严格的定义清楚，一个固化的过程就是一个完整的解决问题的知识体系。这个知识体系是动态的，是以应用为目的的，也是前人经过多年积累形成的重要过程资产。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

谈开发质量和过程管控

Sun, 13 Oct 2013 10:29:03 CST

这里站在甲方信息化部门的角度谈下对开发厂商质量和过程的管控话题。

在构建企业私有云paas平台的时候，里面有一个重要的内容就是应用开发框架，这个应用开发框架可以理解为包含了应用技术架构（分层架构，开源组件选择等）和各种规范约束（编码规范，接口调用规范，UI规范）的一个空框架。各个开发厂商都必须遵循同样的一套技术架构来开发应用，这个不仅仅是解决开发的应用能够部署到paas平台的问题，更多的是解决后期的运维和管理问题，也进一步加强了各个开发厂商之间的可替代性。在传统的应用软件招标中往往我们只强调了开发语言和数据库使用什么，而实际应用内部的技术架构，采用的技术组件仍然由开发商控制，对于甲方来说完全是一个黑盒，不利于后期的质量和过程管控。

在paas平台搭建到一定程度后，可以看到企业内部可以复用的各种IT能力逐步成型，这既包括了各种技术服务能力，也包括了业务服务能力。形成了一个很多的可共享的服务能力支撑库。而新的应用系统必须要基于已有的各种IT能力资产进行开发，加强复用，降低重复开发。这也是我们说的后续应用系统开发能够快捷反应，逐步降低开发成本的一个原因。但是很多时候面对开发厂商固有的模式，推动上往往必须有强大的执行力。

平台+应用，一方面是通过平台实现敏捷性和成本降低，一方面是通过平台约束上层应用采用统一的开发框架，技术架构和标准规范，从而加强后续对应用的质量和过程管控能力。

对于开发厂商的研发过程，给出一个最简单的基于CMMI思路的一个研发过程图如下：

那么站在甲方的思路，要加强开发过程和质量管控的最好的方式就是加强对需求方案和验收发布两端的强管控能力，对于研发过程中加强里程碑评审的能力。对于项目管理而言则加强PMO对项目群管理的能力。在支撑域中最基本的配置管理和变更管理是必须的，要注意到甲方对配置管理的层面往往高于单个应用，往往涉及到的是更加全局跨系统的配置和变更管理能力，端到端的需求全程跟踪和闭环管理能力。

对于甲方驱动的研发过程管控能力，可以总结为三大类，具体如下：

可固化：主要是指规范，流程和相关工具的制定和采用。
可管控：主要是值项目管控过程中的评审，决策，沟通汇报，问题风险管理和监控预警机制。
可量化：主要是指研发管理中的基础度量和KPI指标体系的建立

可以讲做好上面三个方面的内容是甲方逐步深入研发过程管控的一个基础。甲方的研发质量和过程管控不是要替代单个应用开发商的研发项目管理和质量管理，而更多的目的是类似CMMI三级一样形成一个适合甲方管理的组织级的过程和管控机制，从单个应用厂商本身的成熟还不足够，更加重要的是组织级的基线和成熟度。

对开发厂商的管控逐步打开内部的黑盒，但是要注意不是完全接管，而是加强关键点的里程碑评审和结构化决策机制。基于这个思路，另外再提下研发过程管控的一些关键点。

对于需求层面，我们要注意往往不是简单的统一需求方案，特别是涉及到跨多个应用系统的方案制定的时候，需要的不仅仅是需求方案，同时包括了技术方案。这个方案会约束高层的的一些总体架构设计和实现思路方面的内容，以防止后续各个应用在实现过程中走偏。

加强对两端的管理，包括需求方案和验收发布两端的管理，而弱化对厂商开发内部的管理，对于开发厂商内部的过程管控只需要加强里程碑监控和评审即可。以做到最基本的闭环管理。对于开发商内部的研发过程重点是制定相应的标准规范和约束，加强QA管控。

配置管理要形成企业级的配置管理库，各个厂商最终的研发过程资产都必须入库，要加强各种配置审计工作，同时源代码配置管理也需要逐步深入管理，方便后续的统一发布和部署流程的对接。而取代原因的开发厂商在验收的时候才一并提交验收资产的模式。

在纵向团队的基础上，可以考虑形成各种横向的联合性质的虚拟团队。包括易用性团队，性能优化团队，技术专家团队，业务专家团队等，以专家团队的方式来解决各个应用可能存在的共享问题，并且在解决后逐步上升到企业知识库中。形成组织级的度量和KPI体系，切实用数据说话，通过数据分析形成持续改进机制。这一点往往是最难的，但是又必须执行，至少需要做到定性+定量的开发商考核和评估机制。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

谈去IOE

Sun, 15 Dec 2013 20:32:31 CST

大家要注意到去IOE当前本质已经是变化为解决数据库层面的问题，对于应用服务器和中间件，采用X86服务器和负载均衡，集群技术本身已经不存在太大的问题。包括起可靠性，可扩展性和性能等。当前我们看到的很多应用本身也是应用服务器层基本全部X86+虚拟化，而对于数据库往往还在使用小型机和集中存储。

现在的高性能的X86服务器性能已经赶上了3，4年前的中端小型机性能。比如现在的6到8C，8核高配的X86服务器性能能够达到80-100万TPMC，而3年前的中端小型机性能也就60万TPMC的样子。对于小型机的替代大家最关心的问题仍然是高可用性，小型机基本可以达到5个9的高可用性，而现在随着类似至强7500等X86服务器引入了大量在小型机中才使用到的RAS技术，基本达到4个9是没有太大问题的。

还有就是小型机的纵向扩展能力相当强，比如CPU可以最多扩展到24个，而对于X86服务器则是希望通过横向扩展来应对小型机的纵向扩展能力。而横向扩展自然带来的一个问题就是分布式的问题。

对于数据库层面，拿MySQL数据库来和Oracle数据库做一个比较，当前第三方的评测是在相同的硬件配置条件下两个数据库的性能和Benchmark数据库相当。而实际上对于数据库层面我们更加关心的还是在海量数据下的复杂事务处理能力。如果对于存储大表数据都在千万行级别一下，可以说两个数据库可能不会出现太明显的差距。而如果对于大于千万或上亿数据的海量数据OLTP处理上，Oracle估计还是具备有明显的优势。而对于这一个问题的解决，根据互联网企业的经验，仍然是通过数据库的水平拆分和垂直拆分来解决这个问题。

类似EMC提供的集中存储是另外一个重要的话题，可以看到在使用集中存储的时候，我们很容易去实现类似Oracle的RAC集群，同时本身集中SAN,NAS存储也具备更高的存储高可用性和高可靠性。类似互联网企业淘宝也曾经谈到过，在采用廉价的本地磁盘存储后，由于大量的IO磁盘读写也经常出现硬盘挂掉的情况。虽然这些可以通过RAID技术来避免单独故障，但是对于存储的高可靠性确实本地存储赶不上集中存储。

由于在去小型机，Oracle数据库和集中存储情况下，将直接转换为数据库层的构建成为一个share nothing的分布式数据库集群。而现在的MPP+Share nothing的New SQL数据库，类似Greenpulm，Vertica，Hive等更多的都是解决OLAP层面的问题。而对于去IOE首先需要解决的是联机事务处理层面的事情。

那么对于Share nothing的分布式数据库，当前也有类似Mysql Cluster技术来支撑，但是这种分布式数据库虽然做到了高可靠性，但是由于需要支撑CUD操作，导致这种集群很难达到满足实际应用需求的存储容量和业务高性能。在实际的业务应用场景下，除了少量的类似MDM主数据场景比较适合采用外，真正的核心的大量业务操作和逻辑处理场景往往并不适合。

基于这种情况，当前最常用的技术就变化为了对数据库进行水平拆分和垂直拆分，但是这种拆分我们希望的是对应用层透明，因此在数据库上面引入了一个核心的DaaS服务层。但是当前的DaaS服务层很难做到数据库的完全透明，同时对于上层的应用构建造成一定的约束。包括有些跨库的Sql语句，类似跨库聚合Group By等的语句不支持，这些都需要应用层自己去解决。

在跨库后带来的一个重要问题就是分布式事务的问题，对于DaaS来说可以解决部分分布式事务的问题，但是需要采用严格的XA两阶段提交来解决分布式事务，本身的高可靠性和一致性仍然需要进一步进行验证。而对于应用，仍然需要应用去解决一些分布式事务的问题，即通过事务补偿，BASE方法等去解决分布式事务的问题，这些本质上都是削弱了对高一致性的支持，这也是CAP定量经常说的，在一个分布式的系统中很难真正做到三者全部满足。在满足高可用性和分区容错性的基础上，往往需要牺牲一定的高一致性。

由于采用数据库拆分和DaaS层，对于应用层的应用构建将带来比较大的变化，特别是很多原来数据库没有拆分的时候一个SQL就搞定的问题，一个通过数据库层事务就能解决的问题，都会变成了分布式事务问题，或者多次调用服务操作才能够解决的问题。这往往才是说的去IOE的一个关键。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

谈Hadoop下各技术应用场景

Wed, 30 Oct 2013 19:06:37 CST

数据采集和DataFlow

对于数据采集主要分为三类，即结构化数据库采集，日志和文件采集，网页采集。对于结构化数据库，采用Sqoop是合适的，可以实现结构化数据库中数据并行批量入库到hdfs存储。对于网页采集，前端可以采用Nutch，全文检索采用lucense，而实际数据存储最好是入库到Hbase数据库。对于日志文件的采集，现在最常用的仍然是flume或chukwa，但是我们要看到如果对于日志文件数据需要进行各种计算处理再入库的时候，往往flume并不容易处理，这也是为何可以采用Pig来做进一步复杂的data flow和process的原因。

数据采集类似于传统的ETL等工作，因此传统ETL工具中的数据清洗，转换，任务和调度等都是相当重要的内容。这一方面是要基于已有的工具，进行各种接口的扩展以实现对数据的处理和清洗，一方面是加强数据采集过程的调度和任务监控。

数据存储库

数据存储在这里先谈三种场景下的三种存储和应用方式，即Hbase，Hive，impala。其中三者都是基于底层的hdfs分布式文件系统。hive重点是sql-batch查询，海量数据的统计类查询分析，而impala的重点是ad-hoc和交互式查询。hive和impala都可以看作是基于OLAP模式的。而Hbase库是支撑业务的CRUD操作，各种业务操作下的处理和查询。

如何对上面三种模式提供共享一致的数据存储和管理服务，HCatalog是基于Apache Hadoop之上的数据表和存储管理服务。提供统一的元数据管理，而不需要知道具体的存储细节当然是最好的，但是Hcatalog本身也还处于完善阶段，包括和Hive ,Pig的集成。

基于Mysql的MPP数据库Infobright是另外一个MPP(share nothing)数据分析库的选择，如果本身已有的业务系统就是基于Mysql数据库的，那么采用Infobright来做作为一个OLAP分析库也是一个选择。但是本身
Infobright的性能，Infobright社区版的稳定性，管控功能的缺失等仍然是需要考量的因素。

对于mapreduce和zookeeper本身就已经在hbase和hive中使用到了。如hive的hsql语言需要通过mapreduce解析和合并等。而对于impala要注意到本身是基于内存的MPP机制，没有用到mapreduce框架去处理，Dremel之所以能在大数据上实现交互性的响应速度，是因为使用了两方面的技术：一是对有嵌套结构的嵌套关系型数据采用了全新的列式存储格式，一是分布式可扩展统计算法，能够在几千台机器上并行计算查询结果。

实时流处理

这个hadoop框架本身没有包含，在此也做一个分析，前面已经摘录过文章对实时流处理做过介绍，而实际上真正实时流处理的场景并不多，任何一个技术的出现都是为了解决实际的业务问题。比如twitter推出storm可以解决实时热点查询和排序的问题，基于一个巨大的海量数据数据库，如果不是这种基于增量stream模式的分布式实时任务计算和推送，很难真正满足都业务对性能的要求。

同样对于s4和storm只是提供了一个开源的实时流处理框架，而真正的任务处理逻辑和代码仍然需要自己去实现，而开源框架只是提供了一个框架，提供了基本的集群控制，任务采集，任务分发，监控和failover的能力。真正在企业内部应用来看，很少有这种实时流场景，而与之对应的CEP复杂事件处理和EDA事件驱动架构，这个前面很多文章也都谈到过，这个基于消息中间件实现的事件发布订阅和推送，事件链的形成相对来说更加成熟。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

知乎问答-如何做一个软件需求分析师

Wed, 30 Oct 2013 19:32:57 CST

这个问题很大，这篇不想再去重复一个软件需求分析员的知识体系结构，而是挑重点来谈下成为一个合格的软件需求分析人员的关键点。

我原来对软件需求的定义或描述更多是偏于对现实世界的定义，而对软件架构的描述为现实到实现之间的第一层抽象。在这里纠正一下即：用户需求是对现实世界的定义，而软件系统需求是现实到实现的第一层抽象，即业务建模和软件系统用例建模。在原来的软件工程里面我们更多谈到的一个词是系统分析员，我现在将其拆分为了软件需求BA和系统架构SA两个角色。而实际上一个真正优秀的软件需求人员必须具备两方面的能力。

从软件需求在整个软件生命周期中的定位来看，其上接业务，下接设计和技术。从这个概念上来讲软件需求人员必须具备业务和技术两个方面的能力。

对于业务，首先要解决的是对业务的理解，然后才是在理解后业务的形式化表达和业务建模能力。而对业务如何理解，最核心的仍然是顶层的流程建模和分析能力，底层的业务活动和规则清晰的描述能力。在这里里面涉及到流程梳理和定义能力，业务单据和对象的抽取和定义能力，业务规则的清晰阐述能力，和流程配套的相关的岗位角色，交互等描述能力。要知道在这块往往并不需要太多的IT背景和软件工程的知识，更多的是对业务的熟悉，对流程管理和分析方法的了解。

上面一步的业务更多的是属于顶层方面的内容，而第二个层面往往会过渡到系统软件需求层面的内容，在这里我们更加强调的是类似面向对象的用例分析和建模的方法，这包含了业务用例和系统用例分析和建模，是一种很好的形式化的方式来定义和描述业务的方法。包括从流程分析转入到用例，单个具体的用例分析和建模，每个用例详细的基本流，扩展流，业务规则，参与角色，界面原型，业务对象和对象属性等各个方面内容的描述，要知道我们做用例建模的目的是能够按用例驱动的核心，平滑的转入到架构设计中去，因此用例分析建模已经不是简单的描述现实世界的问题，已经涉及到业务或用户需求到系统需求的第一层抽象转换。

要做好需求的第二步的事情，那么单纯的只有业务背景就不足够的，必须还具备相应的IT和软件工程的技术背景。这个背景往往并不是说要做过多久的软件设计开发，但是只是是做过，通过软件开发你能够很清楚的知道一个软件从需求调研和分析开始，最终是如何形成一个软件系统的。这个背景知识可以更加方便我们去考虑用例建模，去认识到为何要采用这种方式去用例建模，真正理解用例中每个描述点如何影响到最终业务系统的实现。

没有技术背景很难真正成为一个优秀的软件需求分析师，最多也就是一个业务需求分析师。

要知道，当你进行用户需求调研后，往往收集到的都是一个个的用户需求点，而一个软件需求分析员要做的是最终将这些需求实现为一个完整的业务系统。这里面就涉及到业务模块的划分，模块间的分析，需求层面的复用能力分析，各种性能，可靠性，安全等非功能性需求。这些更加已经是一个完全的系统分析方面的内容，或者说软件需求已经会兼顾部分软件架构设计的内容，因此作为一个软件需求人员更加需要去了解业务组件化，服务化，软件模块集成，复用等方面的技术内容。也需要去了解涉及到UCD，交互设计方面的内容，这些都是形成一个高质量的软件业务系统的重要输入。

一个优秀的软件需求人员既不应该因为具备技术和开发背景而导致在需求分析和建模中的各种程序员思维，也不应该完全抛弃技术单纯的去描述业务不管实现的难易度。软件需求人员衔接了最终用户和内部的设计开发，是两者之间重要的沟通和协同桥梁。各种沟通和人际关系处理技巧，各种软技能的要求更是必不可少的，在此不再展开去描述。

一个优秀的软件需求人员不存在是否能做新领域的软件需求的问题，因为最终真正有用的需求分析的方法论和模式，去理解和熟悉业务和快速形式化描述和建模的方法，有不断的实践总结出来的快速理解业务的能力。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

谈数据切分后的一些解决思路

Sun, 22 Dec 2013 10:40:46 CST

当我们在谈去IOE时候，一定会带来的一个问题就是单节点本身的计算或存储能力不足而导致的数据水平或垂直切分，那在数据切分后如何解决这些问题就成为一个好的DaaS层能否真正发挥作用的重点。

对于分布式事务的问题，前面已经谈了很多，对于一个DaaS下针对逻辑库（一个逻辑库下面存在多个物理库节点）是可以通过标准的XA两阶段提交协议来实现分布式事务的，但是本身不仅仅是可靠性的问题，更加关键的是性能问题，特别是在高并发下的性能问题。因此在应用实现的过程中还是需要尽量避免使用分布式事务，仅仅在需要使用分布式事务的少数特殊场景通过显性声明的方式使用分布式事务。对于能够采用事务最终一致性BASE的场景，尽量是结合消息中间件的能力，采用最终一致性的方式；对于不能接受最终一致性的场景尽量采用事务补偿的方式来弥补事务失败造成的影响。

在数据拆分有原有的一个单库多表关联查询操作，往往会转变为一个跨库的join查询操作，而现在的针对mysql的daas方案很难真正的支撑到这种类型的操作，即使能够支持估计也很难真正达到一个高性能。在我们原来的设想中这些问题都简单的转化为应用层去解决，这务必是增加了一个应用层开发的复杂度和难度。而针对这种情况最好的方法是构建一个统一的领域服务层来解决，即最终的上层或顶层是关注的领域服务能力，虽然跨库的问题在DaaS层很难解决，但是在领域服务层却比较容易定制开发相应的服务来解决。

举例来说，一个采购订单查询，采购订单头和明细信息在一个逻辑库，而对于物料和供应商主数据在另外一个物理库，但是对于应用来说关注的是一个完整的采购订单信息。因此完全是可以在领域服务层提供一个采购订单查询的服务，在服务内部进行多次的DaaS层服务调用和组装来完成内部的复杂性。这也是我们常说的，但进行数据库拆分后，务必需要引入更加强壮的领域服务层的原因。

在数据拆分后还有一个比较难以解决的问题，即是对于业务系统的大量查询分析和统计功能的处理，由于我们的数据库进行了切分，导致这些功能已经类似于传统BI里面的OLAP层的功能特性。对于这种业务场景和需求，往往并没有完全的实时性需求，我们能够满足准实时性就可以了。因此对于这类功能推荐的方法仍然是需要将当前的各个分库里面的数据整合到NewSql数据库里面进行处理（Hive，infobright，impala)等，这些数据库需要满足的特性就是MPP+Share nothing架构特性，在这种架构下可以看到对于海量数据的分析和统计可以保证业务需要的准实时性要求，唯一需要考虑的是当前很多的NewSQL数据库都是一个读库，很难进行CUD等各种操作，因此转化后需要解决的问题就是对于业务库中的增量数据如何实时的更新到NewSQL数据库里面，注意是增量更新而不是类似当前很多方案里面的全库重新导入和生成，这也是在解决查询统计功能的一个难点。

对于MySQL的读写分离集群我们看到，随着slave节点的增加，为了保证master和slave节点之间的一致性，将会出现明细的延迟，也直接影响到应用CUD操作的性能。对于这个问题，当前可以考虑的解决方案就是要拆分为两级的读写分离集群，对于第一级的读节点保证高一致性和性能，对于第二级允许有较大的延迟，仅仅用于查询分析等。

在最近的一年过程中，我们对基于Mysql的DaaS层产品逐步的改进和完善，包括分布式事务，DDL操作，函数和存储过程支持，多租户和资源隔离，子查询，底层多种数据库适配和支持等做了大量的改进和性能测试。已经基本形成一个可以在实际业务中应用的产品，同时该产品也开始应用到我们自研的ESB服务总线中。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

10个下载和在线观看美剧的好网站

Wed, 22 Jan 2014 22:38:14 CST

去年下半年，在同名的微信公众号（wangyueblogging）中做了一个调查，了解大家平时看美剧追剧时都在哪些网站下载或者在线观看，在这里整理出10个最好的观看或下载美剧的来源网站给大家，希望对你的春节有所帮助。

一、下载美剧的好网站

为什么要将美剧下载下来看呢？优势当然是有的，比如高清无卡顿，未删减等等，美剧下载资源站有很多，这里列举用户推荐度较高的6个：

1. http://eztv.it

英文站，速度快，电视网播完一部剧后两小时，就有bt种子和磁力链接提供了。格式全，标清avi和高清720p几乎都有。而且EZTV是公共站点，无需注册，随时访问随时下载。你如果有闲心，还可以定制首页，那就可以及时知道自己热捧的剧是否停播、是否出新集了。

2. 人人影视

人人影视的字幕质量不是最高（后期会出精校版），而且广告满天飞，但是胜在名气大。

3. 天天美剧

天天美剧是一个公益性网络资源共享组织，致力于分享美剧、英剧各种片源。资源非常丰富，更新及时，是美剧迷的福音。

4. 美剧天堂–謦灵风软美剧论坛

尽管经历了那次变故之后，风软的更新速度明显降了下来，但是其字幕的质量一直是最高的，而且坚持做老剧的态度让人敬佩。只是，能把现在论坛的背景音乐关了吗？

5. 破烂熊

破烂熊的资源和字幕一般发布不会很早，不争首发之类，字幕也是精校的，尤其是英剧和澳剧这些稍小众的剧做得很好。

6. 海盗美剧

海盗美剧是最全面、最专业的高清美剧、高清英剧、高清电影资源平台,力求为大家提供最完美的收藏版美剧、英剧、电影。

二、在线观看美剧的好网站

其实现在主流视频网站对于美剧都比较重视，引进了许多正版的主流美剧和英剧。

7. 搜狐美剧

2010年最先购买了《迷失》，之后搜狐引进的美剧都以收视率高为主，像《生活大爆炸》《绝命毒师》《尼基塔》等，虽然现在数量不是最多的，但是基本每个剧在国内都有稳定的收视人群。而且经过几年的发展，现在很多剧都能做到与美国同步和半同步，字幕的速度也都保持在1-2天之内。缺点是英剧的数量太少。

8. 优酷美剧

最先有追剧选项，目前是字幕速度最快的网站。貌似也是整体数量最多的，主要也是以比较火的美剧为主。而且还有相当数量的英剧（英剧-优酷电视剧频道）。和搜狐相比，优酷的英剧不论是数量还是质量都要高很多。

9. 乐视美剧

乐视是13年秋季档引进美剧数量最多的，而且引进策略和其他网站不同，除了国内比较火的《破产姐妹》《国土安全》和《吸血鬼日记》等，还有很多小众的美剧，喜欢淘各种剧的可以关注一下。

10. 爱奇艺美剧

爱奇艺有点跟风的感觉，和以上三家相比没有太大的优势，尤其对于剧迷来说，除了片头广告时间短点，不是很推荐。

也许您还喜欢：
越狱第四季在线观看及下载地址（持续更新）	推荐2013年值得关注的10部美剧	在中国看美剧那些事儿	三个下载在线视频的网站	鄙视美剧的英剧
无觅

再谈领域建模和领域服务

Sun, 01 Sep 2013 07:50:58 CST

对于贫血的领域层，主要体现在两个方面，一个是没有领域业务对象的概念（领域模型中的聚合根），一个是没有明确的粗粒度的业务规则逻辑处理层。在这种情况下，原有的业务逻辑层变化为仅仅是DAL层的一个简单封装或通道，实际的业务处理全部转化到action层或dal层进行了处理，导致无法真正提炼一个业务模块真正应该具备的领域服务能力。

粗粒度的领域服务提供包括两个方面，一个是完整的领域业务对象提供的数据服务，一个是处理业务规则和逻辑用的业务服务。在领域驱动设计中，前者部分在仓储模型中完成，后者在service中完成。这里要注意DDD里面的service，和我们基于SOA分析和设计中的服务层仍然还是有差别，所有的共性的，应该提供给应用层访问的粗粒度的能力都应该抽象为服务层的服务。

在当前的领域分层架构中没有服务层的概念，在领域层和应用层都有服务，可以将服务层进一步抽取出来，服务层即向应用层提供所有的服务能力。这个服务能力不仅仅是原子服务能力，也包括了组合服务能力。对于服务层提供的服务能力，由服务层控制事务。对于进一步的服务编排，则在应用层进行完成，如果完全基于SOA参考架构，则在上面还会有BPM或BPEL层，重点是对原子服务进行组装和编排。

实体要考虑两个层面，一个是完全的data entity，一个含操作的entity，为了考虑在SOA架构中的数据和操作分离，建议还是采用完全的data entity实体，这个时候这种实体可以进一步作为跨层传输的DTO对象。而对于原有的DAO层，也不仅仅是实现数据的持久化，很多OR-Mapping操作也会在该层完成。数据层关注的是数据对象即和数据库一一映射的表，而领域层关注的是领域对象（可能涉及多张强聚合的表）；数据层最终关心的是数据对象的持久化，而领域层关心的是业务对象全生命周期的管理。

在考虑了数据和操作分离后，对于聚合根的业务对象应该有一个专门的业务对象类，来处理所有和业务对象属性，状态变化相关的操作，即控制业务对象完整的数据和生命周期。而service类本身不应该对数据进行任何cud操作，service类的所有操作都应该转入到业务对象类中进行处理。在这种模式下service类目的仅仅是处理业务规则和逻辑，最终处理结果的落地仍然通过业务对象类来完成。

一个完整的业务系统的构建，不是简单的横向分层，还包括了纵向的分业务模块和业务组件。在领域驱动设计里面没有太多的对这两块结合的描述。在这里要注意两个方面的内容，一个是每一个业务组件都会向上层提供领域服务能力，第二每一个业务组件也会向其它业务组件提供领域服务能力。如果考虑业务系统开发的完全组件化架构和后续的分布式组件部署，那么就需要考虑对于向外部提供的领域服务，需要采用根据松耦合的服务方式向外部提供和发布（soap web service/rest 等），而对于内容提供的领域服务即可以仍然沿用常规api方式。对于同一个业务模块而言，如果要考虑到后续的领域服务层也可以单独的分层部署，那么所有的领域服务都需要通过松耦合的方式向外发布。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

UI设计有哪些知名网站

Thu, 26 Sep 2013 09:28:30 CST

经常有初入门的朋友会问，我想学习 UI设计，都有哪些网站啊。特此分享10个国内外知名度较高的 UI设计网站。（纯属个人观点，勿喷）

国内

站酷

中国最具人气的大型综合性设计网站

评：不认识这个你都不好意思说你是设计师。

http://www.zcool.com.cn

盒子 UI

分享以用户体验为中心的设计

评：好像不开放用户发布文章，但上面作品真心不错，主推栏目是UI设计、交互设计及用户研究。

http://www.boxui.com/

优艾网

一家服务于全球UI设计行业专业人员和相关企业的网络媒体和专业UI设计服务提供商

评：早期影响力较大的老牌UI设计网站之一，但后来明显定位有误，人气也没那么旺了。

http://www.chinaui.com/

UIRSS

国内最具影响力的UI设计门户网站和垂直型社区

评：2012年改版后也红火过一段时间，但不知为何2013年感觉又停滞不前，有段时间首页推荐内容居然几个月没更新。

http://www.uirss.com/

花瓣网

分享、收集素材的综合性网站

评：后起之秀，内容比站酷更广泛，用户主动采集发布为主要内容来源，但也面临一个问题：内容重复较多。

http://www.huaban.com/

国外

dribbble

一个面向创作家、艺术工作者、设计师等创意类作品人群提供作品在线服务的网站。

评：大家都喜欢叫追波，发布作品必须有邀请码，入门门槛相对较高，这也保证了作品的质量。

http://www.zcool.com.cn

pinterest

分享、收集素材的综合性网站

评：瀑布流鼻祖，花瓣网应该也是模仿该网站而来（个人猜测而已）

http://www.pinterest.com/

deviantART

是一个为艺术家展示各自作品、并交流讨论而设计的社交网络服务网站。

评：简称DA，作品涵盖面较广，质量也不错。

http://www.deviantart.com/

Behance

著名设计社区，创意设计人士可以展示自己的作品，发现别人分享的创意作品

评：内容跟上面几个差不多，但内容分类索引较好。

http://www.behance.com/

PSDbox

原创Ps教程，并归纳出比较适合初学者的部分

评：设计师入门必备啊。

http://www.psdbox.com/

知乎问答

Sun, 11 Aug 2013 16:24:47 CST

谈善于思考的人思考能力的兑现

思考能力的价值体现包括两个方面内容，一个是分析解决问题的能力，一个是识别和环境风险能力的提升；一个是把握现在的能力，一个是预见趋势的能力；一个是内观自身的能力，一个是外观环境的能力；一个是归纳的能力，一个是演绎的能力；不论是上面所说的哪个方面，都需要看到思考能力本身形成的两个重要点，即一个是偏流程方法和步骤层面的，一个是偏数据分析和预测方面的。

对于流程方法层面，即根据大量的实践积累，不断的思考和总结，通过已有的方法论和理论，加上自己的实践积累和修正，形成适合自己的分析和解决问题的方式和方法，形成独立的分析解决问题的能力。不要去照搬任何已有的理论和方法论，而是要形成自我的经验模式，这点相当重要。这点靠的不是理论转理论，而是理论实践之间的不断迭代和循环，不断的总结思考和修正，逐步形成。

对于数据分析层面，则是思考能力更加深远的一个方面，在已有的带来实践经验积累的数据的基础上，我们能够更好的计划和预测未来，我们的估算和预测能够有更高的准确度。包括短期的计划和宏观局势的预测等。预测的基础是历史数据的变化所反映出的趋势和依赖关系，预测的重点是基于数据又不脱离于具体的环境和人，预测靠的不是单纯的理论模型，更多的是大量的系统思维下的定性和定量分析。在第一个层面我们重点强调了过程和可重复性，而在这点则重点强调了对数据的敏锐度，基于数据的可预测性和可控性。

关于咨询行业的case study研究的问题

如果我们还是在学习阶段或学院派，我们可以做大量的case study，这世上从来就不缺案例，也不缺方法论和各种咨询中的方法工具技术的使用。做case study即在已有的某种结果的情况下，将我们学到的各种咨询方法，分析解决问题的方法，从现状分析和资料收集开始，逐一的按问题定义分析和解决的思路进行剖析，最终将已有的各种理论方法工具和已有的结论联系起来。这种方式本身也有好处，即至少根据一个已有的案例将学到的各种理论知识比较好的贯彻和衔接起来了，有了一个系统的认识。

但是真正实践中你会看到，脱离真正实践，脱离case当时的真实环境的理论转理论本身并不会有太大的意义。这就类似于，如果已有到一个结果，我们可以采用多种不同的分析方法和工具来推导出这个结果；但是我们真正实践的难度在于你往往并不知道结果，所以你就更不知道你当前采用的方法和工具是否能够达到一个你满意的结果和目标。

与其找别人的case来做case study，不如是自己多关注实践，将团队实践的内容作为真正的case来仔细分析和复盘。我并不是说各种咨询界已有的各种结构化分析和决策方法工具不好，而是不要误入歧途，不要以为使用了结构化的分析解决问题方法，就一定能够得到一个满意的目标和结果。工具带给你的始终是工具，需要的是去了解各种咨询方法工具后的思考模式。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

再谈工作型ppt的制作

Sun, 25 Nov 2012 12:29:39 CST

前面写过两篇，可以先参考：
谈工作型PPT的制作： http://blog.sina.com.cn/s/blog_493a84550100o06j.html
工作型PPT制作参考范例下载： http://blog.sina.com.cn/s/blog_493a8455010167xn.html

对于工作型PPT而言，一个好的PPT是一本书，一个更好的PPT是明白了书本身也就是在讲述一个故事。结构本身是静态概念，而呈现则是动态概念，动静结合是一个好的PPT的基础，同时一个好的结构不足以满足就是一个好的故事，而需要的是一个好的呈现来驱动一个好的结构。在金字塔原理里面，谈金字塔是静态结构，谈金字塔的形成即归纳演绎方法是动态呈现。 结构是结果，而归纳演绎是过程，好的PPT要展现的不仅仅是结构化的结果，而是形成该结果的过程。

这个概念理解后再回头谈总体框架的构思上，在前面一篇文章里面已经谈到过这部分的内容。在这里要说的是总体框架即PPT的章节目录，章节目录很多时候是静态架构，那么就需要一个动态流程串联静态架构，形成一个好的PPT的核心演绎思路和过程。 所以大总体框架一定要意识到是动态的，而非简单的静态章节目录。

在这里我原来举例说明过，比如一个解决方案的PPT，为何章节目录是现状分析，业务解决方案，技术解决方案，实施过程和说明，为何这样分？要能够说明清楚，整个章节目录本身就是我们分析和解决问题的方法，是随着故事线索层层递进的，和听众的思考过程是一样的，是一个故事。再回来说个人年终总结，很多时候一下想的就是静态结构，即工作内容，工作创新，工作不足，个人期望。好像没有什么动态可以遵循。那如果按目标驱动的思路重新来想下就清楚了，即首先公司的KPI体系对岗位的要求是什么样的？我对岗位理解是如何的，我是如何做的？我做后的KPI绩效如何？是否达到目标，有哪些超出了哪些还不足？基于不足的地方我后续应该怎么做？这样一思考，一个简单的静态架构变化为一个动态的架构。大家可以思考下哪种方法去陈述工作绩效更加容易被他人所理解。

总体框架结构定清楚后，进入到每个章节的内容。每个章节本身又是动态和静态结合的思路，动态要说明的是你的叙述方法，研究方法究竟是如何的？在把这个说清楚后再过渡到具体的静态结构展开，把每个点描述清楚。我们来分析一个例子，比如现状分析，当进入到这一章节后马上就开始讲流程现状，业务现状，组织现状，IT现状，那感觉就会很突兀，为何我们就要从这几个方面来将现状？这几个方面现状直接的关系是如何的？你现状分析的思路是如何的？这些疑问我们就无法回答，听众也无法知悉。所以还得先讲两个东西，即现状分析的方法论或思路，现状分析本章节本身的承上启下关系。这些说明白了才能静态结构展开。

动态架构本身就是一直类似流程分析的动态架构，用的最多的就是阶段图，流程图；而静态架构无非是树结构和表格结构，对应矩阵，树结构，思维导图等都是静态架构的展现方法。对应静态展现我们用的最多的就是组成要素构图方式，包括一个事物分几个方面来讲，三方面还是四方面，后续再各个方面逐步展开讲。而静态架构陈述的重点又是看似静态，实质为动态，我为什么要分三个方面讲？三个方面内容又是如何揉合在一起支撑目标。很多时候我们的PPT是只将中间，不讲前后，看似结构化，实际呈现不清。

你要给听众展现一个饼，那就是不仅仅要把饼的原材料说清楚，更加重要的是饼的加工过程得说清楚。一个好的ppt不仅仅传送的是结果，更加重要的是过程。 目标驱动，抽象方法，动态呈现，静态为根，动静结合，围绕主题，层次分明，衔接平滑，即是重点之重点。

最后再说一下具体的内容页，一个好的PPT任何一内容页，要么在叙述过程的活动节点上，要么在某个静态分解的叶子节点上。如果两者都不在，那么这页内容脱离主题，要去掉或者进行优化。即任何一个内容页要么是在叙述树的春夏秋冬演进过程，要么本身就是树的树干或树叶。这种结构就是完整的。

其次结构完整不代表就完全没问题了，很多时候我们看很多思维道导图或分层架构，发现的最大的问题是本来某个章节内容都处在树的树干层次，但是有的在讲树干，有点去已经细化到树枝或树叶，这是一个不容易注意的问题，即本身的层次分级规则不统一。有的地方落入细节，而有点地方有草草了事，不是头重就是脚轻，虽然不影响走路，但是看的人自然别扭。分解大家都会，但是如何保证每次分解都处于同一个水平层次就难了。

对应系统性的报告型PPT，往往内容量很大，注意了以上所有环境还不能解决问题，走着走着往往就迷路了，不仅仅是听众，包括汇报者也落入该问题。所以时刻不要忘记承上启下，小结总结的作用，实现章节间的平滑过渡。其次即前面也谈到过的，内容页要增加引导性内容，以小上标的方式显示在ppt上面，避免迷路。

到了单页PPT的制作，前面谈到过很多构图和呈现方法了，不再多说，重点是保证风格一致。这也是从我今年来做ppt，已经很少用任何的ppt工具模版库，全部靠自己画，目的就是保持整体风格一致化。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

用上20M光纤的之后

Fri, 05 Oct 2012 10:41:32 CST

今年中秋国庆节，完成了可谓人生中最重要的事情，买房，搬家住新房。终于从脏脏的小巷子搬到了漂亮的公寓楼房。也就此伦为了房奴，接受每个月惊心动魄的按揭贷款还债……
　　这段时间可能大家会觉得我太懒了，更新软件不够及时，其实是在为上述事情奔波，趁着这个假期办完该办的事情，也可以安下心来做工作。
　　最重要的网络问题一定要解决。之前住的地方比较偏僻，无光纤，拉的是4M ADSL，网络不够稳定。现在移到这边，直接改成了光纤，4M光纤加上普清机顶盒，实际上速度已经比以前更快，因为ADSL的铜线损耗实在是太大了，光纤几乎是零损耗。而普清机顶盒放在大彩电，比例明显是不对称的，人被压扁，那感觉非常不舒服。于是便上营业厅咨询，业务员称必须要装12M带宽以上才可以装高清机顶盒，然后看看价格，20M带宽比12M带宽只每月贵20元。那我就直接装个20M的得了。中国电信在这个区域的服务态度和在以前住的偏僻地方简直是有天壤之别，响应非常快，预约第二天师傅便上门改装，更换机顶盒，用HDMI线接入，高清电视终于来了，网络也变成了20M。现在迅雷下载速度达到2.5MB/S以上，只是上传仍是限制在了512KB（这没办法，广州全城都是这样，普通宽带上传速度限制得非常厉害，除非是企业宽带，那可就是上下行一样的速度）。接入高清机顶盒之后，自带了几个高清频道，如湖南卫视高清、CCTV高清、CCTV-1高清、浙江卫视高清、江苏卫视高清、深圳卫视高清、黑龙江卫视高清、北京卫视高清、广东卫视高清、东方卫视高清等等。这高清看得是把人的脸毛细孔都看得出来了，我妈说看得都不太习惯了，太清晰了感觉人的皱纹都出来了，人也拉长了，这也难怪，她已经看普清压扁的尺寸习惯了另外还有百多个普清频道可看。更神奇的一个功能便是回看功能，能够随时看前2天的电视节目，时光倒流看错过的节目，此外还有点播节目，更可以看高清电影电视（有些要额外包月收费的），还有游戏通讯功能等。看来以后电视便是一个云终端啰。有线电视可以扔到一边去了。
　　总之，光纤的生活真爽！赶紧全国普及吧。
Tags - 光纤 , 高清

项目管理ppt下载

Sat, 29 Sep 2012 20:38:49 CST

项目管理培训的ppt前年做了部分，一直没有做完，今年准备花些时间全部做完，并全部共享出来。最近做完的主要是项目成本管理和项目质量管理。

成本管理： http://vdisk.weibo.com/s/dyHc0/1348535220

成本管理涉及到比较多的财务的内容，包括财务上的预算管理，成本核算，概预核决，资金管理。原来项目管理更多的是进度意思，质量意思，而后续更加重要的就是成本意识。合同签订下来，项目能够启动是第一要务，而项目执行过程中最重要的就是项目执行能够赚钱，成本能够控制住。

质量管理： http://vdisk.weibo.com/s/dq7pH/1348450780

质量管理对于IT项目和软件研发项目中，需要关注到的是软件研发项目本身的一些特点，关于软件质量熟悉，质量计划，质量度量方法，软件质量保证和质量控制等。其次是统计学和6sigma可以说对深入理解质量管理，特别是体系化质量方法，用数据说话，将质量意识真正融入到整个项目管理过程中，形成持续改进和零缺陷的质量文化来说相当重要。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

谈SaaS应用趋势和变化

Sat, 15 Sep 2012 12:29:33 CST

SaaS可以说是云计算三层里面发展最早的一层，包括在线邮箱也可以说是个人SaaS应用，而Saleforce等在国外发展也很早，那个时候还没有完全提出完整的云计算架构框架。现在来看，SaaS应用的发展，一个必须要解决的问题不是多租户运营问题，而是SaaS应用本身的可伸缩性问题，并不是说SaaS一定要基于IaaS或PaaS，而重要的是随着客户的增多应用必须支持应用和平台层的可伸缩性。因此底层分布式计算和存储技术，集群，弹性调度等是必须要考虑的问题。不支持弹性扩展能力不能叫一个完整的SaaS应用。

几年前，SaaS比较火，包括后面的神码在线，八百客都推出相关应用，包括SaaS平台。原来我一直强调过SaaS平台只是应用的一个集中展现和运营平台，而不是PaaS。最近看到新浪借助SAE等发力开始推开放应用和托管平台。其切入点在于个人和小团队，感觉这个切入点相对好。很多原来做SaaS不成功的就是切入点选择上的问题，而现在来看更好的演进路线就是个人-》小团队-》中小企业这种方式进行演进更加合理。而对于大型集团型企业来讲，SaaS一直是很难进入的壁垒，那么可以看到大型集团型企业的重点是内部的私有云SaaS应用，很多时候我们看到大型集团型企业各个分支机构，子公司都在建设自己独立的业务系统，完整可以演进为私有云内部的SaaS模式。

随着互联网和底层IaaS和PaaS云平台技术的发展，后续对于小型SaaS应用的开发和运营模式会发生很大的变化。即小型团队或个人借助公有云已有的IaaS层和PaaS层能力完全可以获取到相应的基础设施资源，平台层资源，外部各种开放式能力资源等。可以完成一个SaaS应用的开发，测试和发布上线过程，而最终的运营也可以完全转给专门的SaaS平台运营商。类似facebook的模式，以后确实就是平台和用户资源为王，新浪现在两点都在手上，完全可以看好后续新浪朝大量有价值的SaaS应用发展。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

再谈软件平台

Sat, 15 Sep 2012 13:50:54 CST

首先我们再来看下企业内搭建软件平台的核心目标，主要包括如下几点：

a.软件人员从过多关注共性技术转化到对核心业务需求和逻辑的关注。
b.提升开发效率，降低开发成本，直接影响到我们最终给客户工作量和报价时的优势。
c.更加快速的通过配置方式满足业务需求能力，不是所有变更都需要重新部署和全流程测试。
d.统一企业所有软件开发框架模式，进一步提升复用度和企业IT资产库积累。

当企业就开发一款产品化产品的时候，往往并不一定太关注软件平台的事情，但是当我们涉及多个产品线，开发多个业务域的软件产品的时候，软件平台就相当重要。客户需求一驱动，往往需要新搭框架和新建系统，从头开始往往浪费大量时间和精力。平台核心思路就是所有技术共性内容下移到平台层（包括工作流，组织权限，消息缓存技术组件和开发框架模式等），在此基础上再考虑构件业务平台，实现共性业务组件的复用和平台化。基于技术平台+业务平台，构建定制化的业务应用。

我一直在强调，企业能够最终提供一个软件平台，面对任何新的应用的时候，我们只需要考虑业务建模，在业务建模完成后形成各个业务功能模块。最终只需要考虑一各个业务功能模块的开发的集成进入即可。从这点开平台本身也有SOA思想融入，彻底实现业务和IT技术的解耦，更加容易实现业务到应用的转化和集成工作。

平台提供各种能力引擎，应用功能模块开发只需要考虑如何消费和使用这些能力引擎即可，在PaaS架构下面我们叫资源或能力汇聚网关。平台本身又是一个完整的快速开发框架，包括了对象和数据库建模，流程建模，界面建模和规则建模的能力。而这个里面最难的是规则引擎和规则建模，很多时候我们太希望所有规则都可配置，进而得出一个所有内容都可配置就可以轻松完成功能开发的模式，但是没有银弹，很多努力到现在也没实现。因此我们并不提倡将功能开发变化为一种完成可视化的界面流程配置方式来开发，这一方面约束开发人员技能成长，一方面本身在熟练后可视化配置开发模式还不如直接代码编写速度快。很可能就两个配置文件修改问题，你都可能在可视化界面配置上折腾半天。

平台一定要融入SOA和组件化架构的思想，我们看普元提供的平台这是一个很大的优势。很多时候我们在跟客户谈我们的应用基于SOA架构，结果自身也完全没有立即SOA和组件化的核心思路。各个模块之间还是紧耦合，完全无法实现独立的产品配置和部署。如果一个平台最终能够提供的是我们在上面开发不同的组件和构件，最终通过不同的组件和构件来组装和发布适合不同客户需求的可配置产品，那么平台本身发挥最大的价值。构件库形成可复用资产，而构件组装灵活响应需求变化。

在公用云PaaS参考架构中，并没有谈到太多关于产品平台和技术平台的事情，而在企业私有云架构中，这块却是必须要关注的内容，可以理解为私有云PaaS中的开发态核心内容。

关于SOA和平台关系参考： http://blog.sina.com.cn/s/blog_493a84550100tsh7.html
青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

企业架构-分层和维度

Fri, 14 Sep 2012 18:04:48 CST

在企业架构思考中，价值链一定是一个核心的维度，价值链展开包括核心的企业业务线条，如包括内部，外部物流，产品研发，生产制造，市场，销售，售后等核心业务价值链，也包括人力，财务，综合，安全等支持业务线条。

在从业务到IT转换过程中，一般涉及到概念，逻辑，物理三个阶段，也是从业务规划到建设实施落地的过程，这个也是我们在分析核心的架构域的时候必须考虑的内容，包括业务，应用，数据各个方面基本都会涉及到这三个方面的内容。

企业架构本身强调的是业务驱动IT，业务和IT的匹配和融合而不是两张皮，在这里可以看到核心我们关注的点包括流程，活动，数据，组织，资源五个方面的内容。而每个方面基本都涉及到业务和IT两个方面的内容，包括业务到IT的转化和映射。例如业务职能或活动最终会转化我们的应用模块和功能，业务单据最终会转化为数据模型等。如下图来说：

任何一个维度本身可能又是一个层次结构或多维结构，这点需要注意，如流程本身也是高端流程逐步分层的架构，组织本身也是完整的分层组织架构模式等。

架构本身也是一个重要的维度，包括现在谈的企业架构包括了流程架构，业务架构，数据架构，应用架构（含集成架构），技术架构，基础设施架构几个方面的内容。确实，企业业务和IT的核心能力在前面几个架构中都会涵盖到而且相互联系。

IBM在CBM组件化业务模型的时候，分为了两个维度，一个是刚才谈到的业务线维度，一个维度是从组织管理角度的思考，分为了战略层，管理层和执行层。那么这三层是另外一个需要考虑的维度，包括我们建设任何一个IT系统都需要考虑清楚目标用户和管理分层后的需求。

从企业后续大的IT技术架构层面，可以看到进一步融合了SOA，云，传统技术架构。整体来看分为资源层，服务层和应用层。资源层本身又可以细分为物理资源和逻辑资源，包括IT服务器存储网络基础设施，虚拟化资源池，数据库中间件，部署的业务组件等。服务层是资源层能力的识别和暴露，形成核心的业务能力，而应用层包括了应用模块单元，也包括了应用模块组装，门户展现等内容。

在zachman企业架构框架里面，一个重要的维度是5W+1H，涉及到数据，功能，网络，组织，进度，战略。另外一个维度有点类似前面说的概念，逻辑和物理模型。包括了范围，实体，系统，技术，构件和功能实体等层次。这有点类似我前面一些文章谈到的从业务到IT落地，业务组件化的思想。

ANSI/IEEE对架构定义是，一个系统的基础组织，集成它的组件，这些组织内部，组件内容和组织和组件间的关系和环境，以及管理设计和概念原则。概括起来就是结构，模块，组件，标准，它们之间的关系和治理。

企业总体架构的简单公式定义为， 企业总体架构=架构的模块组件+它们之间的关系+管控治理

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

知乎问答

Thu, 13 Sep 2012 21:56:16 CST

1.产品经理应该从哪些切入点来着手新项目

了解项目的产生背景，项目的需求和范围，明确项目的目标（进度目标，质量目标），分析项目环境和各方干系人关系，确定手里面有哪些资源即资源的能力水平，评估要达到项目目标存在的潜在风险和问题，基于以上来考虑项目计划。

2.百度为何没有一个强大的客户端产品

前面已经很多人说了百度还是有类似输入法，百度影音等客户端产品的，所以问题我转化了什么业务场景下更容易发展客户端产品来说。具体包括如下场景：

a.有比较复杂的而且需要快速响应的界面交互，客户端产品有优势。
b.当需要和本地计算机各种资源进行交互的时候，客户端产品占有优势，很方便快捷完成。
c.当需要离线状态也需要能够使用的时候，客户端产品占优势，如邮件客户端。
d.客户端产品不是取代在线产品，而是对在线产品的增强。

基于以上假设来看，那搜索来说，基本不满足上述条件，很难发展壮大客户端产品。

3.如何设计自己的知识库，让价值最大化？个人的知识库记录了各种备忘，读书笔记，收藏信息，实践信息。组织分类看似清晰，实则很不便于查找和使用。且会让人产生惰性，不愿意去查知识库。另外存储的知识如何升级？如何跟别人一起碰撞以后自我升级？

这个问题这样理解，我把知识库分为两个大部分内容，一个部分为完全原始的从网上收集到的资料库，一个为自己写出来的各种文档，读书笔记，阅读资料后的截图等。对于资料这块建议大目录库管理即可，不要花太多时间去做细致分类，没有用，用个everything工具全解决了。而对于第二部分内容则重点归类整理，按业务主体，按产品，按项目一定要整理归档好，我们对这部分实践文档的需求不是点上的，而是需要系统性的。

4.你的时间如何安排的？

除了开会和大量沟通外，核心KPI跟踪外，某段时间都有一些核心关注主题，以这些主题的大量泛读和主题阅读为主，泛读到一定量后开始思考和整理，将思考内容写为博客作为知识沉淀。

5.IT咨询顾问如何进行职业规划？

先做1-2年技术积累，了解信息化和软件架构，再做1-2年需求积累，了解基本的需求分析和建模方法。后续进行大量的业务积累，流程管理，项目管理和方法论积累。前面两个积累好了后面就容易，不会在后续发展过程中遇到IT基础技术背景不足的瓶颈。
青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

架构设计和概要设计

Tue, 11 Sep 2012 21:35:57 CST

初步再来探讨下架构设计和概要设计的区别和边界问题。先谈下架构设计：

架构设计包括了功能性架构和技术架构设计两个部分的内容，功能性架构解决业务流程和功能问题，而技术架构解决非功能性需求等问题。两种架构都包括了动态和静态两个方面的内容，对于功能性架构中动态部分为业务流程驱动全局用例，用例驱动的用例实现等；对于技术架构中动态部分为架构运行机制，而静态部分为框架，分层等方面的内容。

功能性架构包括了全局用例设计，这个本身是用例分析和设计的一个延续，而全局用例分析建议的思路仍然是业务流程，业务用例建模到系统用例建模的过程。全局用例分析清楚后可以开始考虑子系统和模块的划分，形成系统的功能架构图，当然在划分过程中一定要考虑到通过CRUD矩阵等分析方法来分析模块如何划分合理，如何保证模块本身高内聚和松耦合。

在全局用例分析完成后涉及到数据模型的设计，数据建模仍然从业务驱动，从最初的业务对象和单据入手，到最终的数据概念模型和逻辑模型等。架构设计中全局数据模型不一定覆盖所有的数据对象和数据表；但是核心的主数据，核心业务单据数据一定要覆盖到，模型到的层次到逻辑模型即可。如果用面向对象的分析方法，这里需要出的是UML建模中的概念模型和逻辑模型，体现核心对象和类，核心对象和类之间的关系。

将全局用例分析和数据模型建立融合在一起，可以看到这两者结合起来会形成一个系统完成的领域模型层。一直认为领域模型思路应该引入架构设计，只有领域模型才是真正关注功能性架构，而不用马上关注到具体的技术分层和技术实现。

前面两者做完后可以看到一个大系统被分解为了多个子系统或模块，那么接着要考虑的就是模块间的集成架构，分析完集成架构模块间的接口基本就出来了。接口设计应该是架构设计的另外一个核心内容。要明白架构设计一个重要作用就是架构设计完成后各个模块可以并行开始概要设计，详细设计和开发工作。只要大家都遵循架构设计约定的接口规则即可以了。

集成架构考虑完另外一个核心内容就是公共可复用组件的抽取和识别，包括了功能组件和技术组件，需要识别出来哪些是可复用的，如何进行复用。对于复用层次本身又包括了数据层复用，逻辑层组件复用，界面层UI组件的复用等。复用是架构价值体现的的另外一个关键点。

这些都做完后，接着一个步骤应该在架构设计阶段做的就是对架构输出成功进行模拟验证，前面完成了分解动作，必须通过模拟验证来看看后续分解内容能否很好的集成和组装。很多时候我们做架构设计的时候往往不做这块内容，导致架构设计一些内容变成空中楼阁，无法落地。

再回来看技术架构设计，首先谈下静态部分的内容。这里面就包括了软件开发的分层架构，开发框架等内容，包括开发规范约定，技术平台和语言的选择，使用的规约等都需要考虑。很多时候我们看到谈架构的时候说到的三层或多层架构，仅仅是完整架构设计里面很小的一部分内容。

除了分层架构外，接着考虑的就是各种非功能性需要，我们在架构上需要如何设计。这里面包括了事务，缓存，异常，日志，安全，性能，可用性，容错能力等。这些逐个点都要在架构设计中说清楚如何考虑，由于这些本身就属于一个应用系统中技术平台要考虑的内容，因此应该设计为较为公用的技术组件供上层的业务组件使用。要明白很多时候为何谈到AOP或可插拔架构，只有这样去考虑问题，才会考虑真正的功能性架构设计和功能实现和非功能性技术架构这块充分解耦，实现进一步的灵活装配。

再回到架构设计视图层面，还需要考虑的就是整个应用系统的部署架构，部署架构本身也包括了逻辑视图和物理视图，应用最终开发出来了如何进行部署，这涉及到了IT基础架构方面的细化，也需要考虑清楚。

概要设计

概要设计首先要明白的是根据架构设计的内容进一步对某个模块的设计进一步细化。架构设计在系统级，而概要设计在子系统或模块级。拿建筑来比喻，架构设计是把一个建筑的框架结构全部定清楚，包括地基要挖多深，核心框架和承重结构如何，每一层的结构图如何，应该分为几个大套间这些内容都应该定下来。每个大套间的水，电，气等管道接入点在哪里等。而概要设计要做的是拿着一个套间，来考虑这个套间内部该如何设计，如何划分功能区域，如何将水电气接入点进一步在房间内延伸，哪些地方需要进一步增加非承重的隔断等。

基于以上思路我们看到在架构设计的时候，除了很少部分的核心用例我们会谈到具体的用例实现完，大多数功能我们都不会谈到具体的用例实现层面。而到了概要设计则需要进一步的分解我这块模块究竟需要实现哪些功能点，具体的每个功能点究竟如何实现都必须要考虑到。

严格的概要设计，我们希望是到了概要设计的某个功能模块，模块所涉及到的核心的类全部会出来，类关系图全部会出来。数据库设计也进一步细化到该模块的数据库物理模型。对于用例进行用例实现分析，在实现分析过程中可以看到每个类核心的public方法全部会分析识别出来。

拿着架构设计的接口，概要设计也需要进一步细化，细化出接口具体的输入输出和使用方法，包括模块应该使用哪些外部接口，模块本身又提供哪些接口出去都必须细化清楚。做概要设计的时候一定要清楚当前做的这个模块在整个应用系统架构中的位置，和外部的集成和交互点。

概要设计不用到详细设计这么细化，包括类里面的私有方法，public方法的具体实现步骤和逻辑，伪代码等。但是我们要看到概要设计里面对于核心的业务逻辑必须要设计清楚如何实现，实现的机制和方法。很多时候我们到了概要设计画uml的时序图，很多时候一看没有任何意义，全是跨层的简单的交互和调用。这个应该在架构设计的架构运行机制说清楚即可。设计到多个业务类间的交互调用才是重点，一个简单的功能增删改查，完全没有必要画什么时序图。

其次架构设计中给出了各种安全，性能，缓存的设计。那么在概要设计中出来另外一个问题，即架构给出的各种实现方案和技术，我们在概要设计中如何选择，如何使用。不是所有功能都需要缓存，那就要说清楚哪些功能根据分析需要缓存，需要缓存哪些对象，缓存本身的时效性如何设置等问题。

概要设计作为我们要达到一个目的，就是不论是谁拿走概要设计来做，最终实现出来的功能模块不会走样，功能模块最终实现出来可能有性能，易用性等方面的问题，但是整个功能实现的大框架一定是定了的。

另外一篇文章可参考：http://321echo.blog.163.com/blog/static/999257872010020102113705/

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

再谈卓越绩效框架模式

Mon, 10 Sep 2012 14:55:03 CST

为了帮助企业应对日趋激烈的竞争环境，美国在1987年按照《马尔科姆• 波多里奇国家质量提高法》设立了国家质量奖，同时制定了卓越绩效模式标准作为美国国家质量奖的评价依据。波多里奇国家质量奖标准在提高组织业绩，改进组织整体绩效，促进美国所有组织相互交流、分享最佳经营管理实践并为组织带来市场成功等方面发挥了重要作用。卓越绩效的框架模式如下图：

一个企业的成功和卓越涉及到两个方面，一个是道，一个是术。道即公司的战略，文化，价值观，领导力等方面的内容；而术则指企业方法，工具层面的内容。即要以道驭术，又要以术载道。忽视了术的道是水中月，镜中花，无法真正落地；而忽视了道的术本身又执迷在工具中而迷失了方向。

整个卓越绩效框架分为三个层面，最底层为过程支持层面，中间位核心业务价值实现层面，而最上面则是组织管控层面。过程支持层面沿用了传统质量管理很多内容和方法，融入了知识管理和学习型团队内容；而核心业务包括领导作用和经营结果两个三角；领导作用偏道层面，而经营结果偏术和实践层面。最上层不仅仅涉及到组织治理环境，更涉及到内外环境，关系和组织治理等更高层面的内容。

要注意在卓越绩效里面谈的质量是一种大Q的概念，传统的ISO和TQM等更加关注的是产品服务质量，过程质量等，而对于卓越绩效中的质量更加关注的是经营质量，关注卓越领导和战略下对经营质量的推动作用。虽然各种质量体系都强调持续改进，但是卓越绩效框架更加强调了学习型组织和以人为本下，以经营关注为焦点的持续质量改进行为。再回过来看，可以说对于ISO，6Sigma等质量体系更加关注术的内容，而对于卓越绩效框架则更加偏重道的内容，道和术的结合。卓越绩效和传统的ISO9001相比较，主要更加突出了战略，绩效和社会责任三个方面的内容。战略是领导三角的核心，而绩效又是经营三角的核心，社会责任则是企业和管理者应该承担的内容。

下面谈下卓越绩效的核心价值观，主要包括了11个方面的内容：

1.远见卓识的领导

再次强调了领导力而非管理规范流程，任何标准规范流程都无法代替领导力的作用，一个企业能够走多远跟企业领导的远见卓识，领导自身的道德修养和知识结构都有很大的关系。对于这点需要考虑的就是企业本身的核心价值观和文化应该是什么？基于该文化企业的发展战略，目标，体系，方法应该是如何的？如何调动全员积极性，建立可持续发展的学习型组织和团队等。

领导者必须要考虑清楚组织或企业和外部环境的关系，组织和员工见的关系，领导战略和价值创造间的关系。战略和领导的结果都是为了经营价值的创造，也只有经营价值创造才可能承担更多的社会责任。

2.顾客驱动的卓越

在ISO9000的质量管理原则里面也谈到了以顾客关注为焦点。要理解顾问驱动本身也就是价值驱动，一个产品或服务只有顾客认同和消费，使用价值才可能最终变化为企业的商业价值。如果一句话来谈，即是在顾客需求的时候，快速敏捷的提供顾问需要的高质量的产品，并持续提供后续服务，提升客户满意度。

3.培养学习型组织和个人

这个涉及到卓越绩效框架里面的以员工为本和知识管理，价值观和文化多方面的内容。在《第五项修炼》里面专门就在谈学习型组织和个人的问题。而这里面核心还是思维模式，心智模式的转变，知识管理思想的传递等。学习组织需要基于一个乐于收集，分享，创造的团队。

对于这一点，越发感觉价值观和文化，企业战略等对学习型组织建设起到很重要的影响。一个学习组织必须足够的激发每个员工的分享和知识创造热情。我们发现，很多时候有人愿意在互联网类似知乎网站分享知识，但是却没有习惯在企业内知识社区分享知识，这就是文化和价值观的问题，不是方法工具层面的问题。包括最近大家推荐比较多的《认知盈余》一书，也可以看到，学习型组织和知识分享，不是简单的物质激励就是能够解决的问题，很多时候知识分享更多的是自我实现的过程。

4.尊重员工和合作伙伴

一个是员工间的互相尊重，一个是企业和员工间的互相尊重，尊重是一个双方相互的过程而不是单向的。企业对员工的尊重包括了提供公平的竞争环境，鼓励和激励优秀，鼓励创新，为员工提供适合的个人职业发展渠道，鼓励知识分享和员工自身目标的实现等。

在外部，与顾客、供应商、教育机构、银行、社会团体等建立战略联盟与合作伙伴关系。当前任何一个企业或组织的经营都不可能封闭进行，而是一个开放的环境，开放的环境就需要更多的尊重和包容，协同发展。

5.快速反应和灵活性

我们原来谈的比较多的是个人敏捷和团队敏捷，而企业相同也需要敏捷。敏捷包括两个方面的核心内容，一个是速度要快，生产率足够高；一个是对于市场和客户需求变化的时候，要迅速的转变自己。从这些方面来看，一个企业的敏捷一方面是组织，团队和个人的敏捷；其次是我们供应链和产品开发过程的柔性。

6.关注未来

关注未来包括了战略目标和风险危机意识两方面的内容。要制定组织的发展战略，分析和预测影响组织发展的各种因素：顾客期望、新的机会、市场占有率、技术发展、新的顾客、法规要求、新的期望、竞争对手战略。根据组织确定的战略目标，制定中长期、短期计划，并配置所需的资源，保证战略目标的实现。

7.促进创新的管理

创新本身包括了商业模式创新，产品服务创新，管理创新，技术创新多方面的内容。创新不仅仅局限于研究开发部门的技术和产品创新，管理创新也很重要。管理创新包括：思想观念、组织机构、运行机制和业务流程等多方面的创新。

对于创新，我比较认可的还是微创新，不用什么都从头做起，而是应该在前人的基础上持续发展。创新不是完全没有方法论可以遵循，包括前面文章有谈到过，对于创新仍然有类似TRIZ方法论可以遵循。

8.基于事实的管理

简单来讲即用数据说法，基于事实的管理即基于数据的管理，对于这点完全可以参考6sigma方法论中的定义，测量，分析，改进，控制。基于事实的管理需要我们重视数据的采集，分析，基于数据的科学决策。

9.社会责任

社会责任包括了环境，安全，社会道德，公共健康等方面的内容，也包括了企业从事公益事业和活动等。德鲁克把社会责任分为两类：一类是对社会的影响，即企业的经营对社会产生了什么影响;另一类涉及到社会问题，即企业能够为社会做些什么。对社会的影响超出了企业为社会所提供的产品和服务，这并不是企业存在的目的，而是在营运过程中不可避免地产生的副产品。对此，德鲁克的忠告是：一旦发现对社会造成了负面影响，最好予以消除。

10.重视结果和创造价值

经营结果不限于销售额和利润，包括：产品和服务结果、以顾客为中心的结果、财务和市场结果、人力资源结果、组织有效性结果、领导和社会责任结果。“结果”应是有“因”之果，是“过程”的结果；“过程”的成熟度如何，要看“结果”；“过程”的改进应以“结果”为导向。

11.系统的视野

系统＝综合、一致、整合。综合意味着把组织看成一个整体，建立于关键的经营要求，包括战略目标和行动计划（整体）；“一致”意味着链接标准各项要求，确保计划、过程、测量指标和行动之间的一致性（纵向）；整合建立在一致至上，意味着绩效管理体系中的各独立的要素以充分互连的方式运作（横向）。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

SOA资料学习

Fri, 14 Dec 2012 15:18:44 CST

相关资料可以在微盘下载到。具体根据标题名称搜索。

支付宝的SOA实践

从对象到组件，首先可以把对象理解为更细粒度东西，而组件是更加粗粒度的模块，对象更多关注技术，而组件应该更加关注业务。前面我们谈过技术组件和业务组件，在SOA思想下业务组件化的思想就更加重要。组件本身而言很简单，南向接口和北向接口，或者再有底座平台支撑。接口通过服务方式来实现，组件通过OSGI等技术实现高度的解耦和可热插拔性。组件本身也可以更加灵活的组装或编排。

对应烟囱群的打破，不仅仅是SOA服务的引入，更加重要的是平台和集中化思想的引入，是集中化后再将集中的能力服务化。所有共性和可复用的内容都可以集中。包括了传统所说的技术平台和共享数据中心，组件核心能力提供包括了技术，数据和业务三个方面，自然对应到技术服务，数据服务和业务服务。

组件是一个粗粒度的概念，从组件到服务简单来讲，组件本身的能力通过服务暴露出来，组件之间的交互只能通过服务交互进行。通过服务交互实现了组件间的集成，通过多个组件间的交互实现了整个应用的集成。

总体集成包括了三个方面的内容，一个是数据集成，一个是应用服务集成，一个是界面集成。数据集成重点是传统的ETL方式，而服务集成则是以服务和消息为主，界面集成则是基于单点和统一认证下前端技术的延展。在集成方式选择上的优先级应该为界面集成优先考虑，然后是服务集成，最后才是数据集成。

服务总线ESB是SOA架构中的一个核心内容，可以看到总线本身的作用仍然是围绕统一的服务代理和服务目录提供，消息转换，路由这几个关键点。再次强调服务总线的技术架构本身也应该是基于组件化和松耦合思想，通过各种插件或拦截器来实现对日志，安全，QoS等的进一步需求满足。

对于CAP，ACID和BASE理论在前面的文章已经有过介绍，原子性与持久性必须根本保障。为了可用性、性能与降级服务的需要，我们只有降低一致性( C ) 与隔离性( I ) 的要求。而BASE的解决方案不是不关注一致性，而是最终一致性。在BASE方案实现中一个重点就是消息中间件和事件消息的使用。通过该方法来解决由于组件化后带来的大量的分布式事务问题。

文章里面关于柔性事务这个提法相当好，柔性事务是一个混合体，包括了两阶段性，补偿性，异步确保性，最大限度通知型等。两阶段性完全满足 ACID，而异步确保型则重点是BASE理论思路。一个完整的业务活动(Business Activity)，是ACID与BASE的混合体。

企业私有云架构和实施蓝图

该资料是Intel的一个白皮书，有一定的参考价值。从这个私有云参考架构来看，可以看到包括了IaaS，PaaS，管控和自服务几个核心方面的内容。在这里简单摘录下IaaS层和PaaS层的业务需求和构建目标的描述。

laaS 为一套支持私有云的虚拟化多租户基础设施。laaS 基础设施可提供计算服务，通常以带有相关存储和网络连接的虚拟机（VM）形式存在。它可使不同业务团队的多个应用无缝共享通用的基础物理资源，例如服务器和存储。无需购买物理服务器、软件、数据中心空间和网络设备，我们的内部客户可通过虚拟机的方式获得这些资源。

这有助于我们提高每个池内的资源利用率，从而实现能效提升。同时它还支持实施更先进的服务，例如平衡物理服务器和存储构架之间的工作负载。工作负载平衡借助于虚拟机实时迁移而实现，后者可在一个资源池中的物理资源之间迁移虚拟化应用，整个过程对用户完全透明，不会中断应用所提供的服务。

对于PaaS，我们的目标之一是让开发人员花更多的时间创建应用并减少花在系统工程任务的时间。为了实现这一目标，我们的 PaaS 解决方案为开发人员提供了针对应用研发的标准平台，同时帮助他们减轻维护服务器操作系统等大部分传统任务（例如补丁安装、配置和监控）的负担。

我们已在 laaS 基础环境之上构建了 PaaS解决方案。借助 laaS 功能，该方案可支持平台动态地响应需求。该平台为一项应用可使用的标准服务；每个平台组件可根据需要进行扩展和收缩，进而满足应用在生命周期各个阶段的不同需求。

我们的 PaaS 构架旨在推动和简化最重要应用环境的标准化。我们将至少提供两个主要 PaaS 平台：一个基于我们的行业标准企业计算堆栈，另一个基于开源技术。每个堆栈均为开发人员提供了一套标准的功能，最初包括一个数据集、Web 服务器、身份验证与授权服务和一个应用服务器角色。我们计划之后再陆续添加一些其他的服务，例如分析和报告。

应用开发人员可借助下一节中描述的自助门户申请和管理其 PaaS 应用平台。他们可基于每个应用的要求来挑选服务器平台或完善软件堆栈。

为了让 PaaS 所有功能得以充分发挥，开发人员需要调整其应用以应对不断变化的环境，这可能需要他们通过应用内的API call 来调用适当的 laaS 和 PaaS 服务。例如，如果应用超出预期接收到大量 Web数据请求，它可要求快速增加 Web 前端服务器的数量。

2010中国SOA市场研究报告

虽然是两年前的一份材料，但是这份材料仍然有一定的参考价值，这种材料最新的一般为付费材料，所以看下两年前的材料，对比下现在SOA市场和技术的发展也有一定益处。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密

企业架构-应用架构构图

Mon, 19 Nov 2012 22:50:21 CST

在这里要谈的是在传统的企业架构-应用架构的基础上进一步体现SOA和企业私有云平台的思想，而非传统意义上简单的原有企业各个业务系统功能架构的堆砌。这个思想包括两个方面的内容，一个是集中化和平台化，一个是SOA服务化和业务能力组件化。

对于该构图模式考虑两种，首先第一种是充分考虑平台层独立和平台层能力的体现：

其中技术平台提供业务无关的共享技术能力，以技术服务的方式注册到ESB服务总线，包括了消息，缓存，日志，安全，异常等各种技术组件和技术能力。广义的技术平台同时包括了开发平台，将标准的组件化开发框架融入到开发平台中，保证所有的应用基于统一标准的分层架构和开发模式进行开发。

在技术平台上面规划业务平台和数据平台，业务平台和数据平台都和业务相关。业务平台本身提供可共享的各种业务服务能力，数据平台提供可共享的数据服务能力。技术平台为业务平台和数据平台提供支撑，数据平台同时为业务平台提供数据支撑。业务平台和数据平台分别提供业务服务和数据服务注册到ESB实现服务能力共享。

业务平台实现业务服务的复用，需要识别可复用的业务组件和业务能力。对于数据平台则实现共享数据中心，包括了主数据和可共享的动态数据，实现数据能力的共享。

有了以上内容后再来构建更上层的业务应用，这个时候业务应用可以充分的利用三个平台提供的技术服务，业务服务和数据服务，来进一步构建具体的应用功能。如果严格按照SOA参考架构的思路，应用完全可以基于服务的组装和编排，再加上规则引擎的能力，界面设计器等完成应用的构建。

应用构建完成后最终仍然通过统一门户来实现集成，打破传统业务系统的边界概念。在该模式下回归到单个业务系统，可以进一步根据SOA参考架构对资源-服务-应用的分层模式进行重新组合，形成单个应用本身的基于组件化和SOA服务的参考应用架构：

整个架构里面分资源，服务，应用标准的三层。其中资源层为各个业务组件，是独立存在的可以单独开发，设计，部署和运维的业务单元。业务组件的能力通过业务服务暴露出去。

对于服务层又分两层，首先是最基础的原子服务，包括了业务服务，数据服务，技术服务等；其次是上次的组合服务和流程服务，到了流程服务层面，加上具体的界面基本就可以形成一个完整的应用功能。该图可以更加明显的描述出应用功能是通过服务组合和编排产生出来的。应用功能上面仍然通过门户集中。

该两种画法没有完全按照企业私有云PaaS参考架构，而只是融入了SOA共享服务和私有云资源集中化的思想，打破传统业务系统边界，其下是逻辑资源的集中，其上是统一门户的汇聚，中间是组件化的能力单元和通过ESB总线的集成和共享。形成企业完整的应用架构整体。

青春就应该这样绽放游戏测试：三国时期谁是你最好的兄弟！！你不得不信的星座秘密