-
Eclipse@Beijing
It started from 8:25AM, July 22. But it was cloudy and we couldn’t see sun until around 9:30…
It looked like moon…and as I said, it was cloudy, which made the ‘eaten sun’ lookedmore likemoon…However, moon could never look like this…
So…that was it. Yusiew sent a message to my mobile said ‘it’s amazing’. Err…itwasnot really amazing watching a partial eclipse from Beijing. It even didn’t turn dark.Disappointing.
-
无欲则刚
今天是怎么回事呢？
除了奇怪的天气和奇怪的事情之外，一打开豆瓣又看到某老师为了推销主打书竟然赤膊上阵连五毛行径也用上了。
上次建议豆瓣给投票加上权重时，真没有想到会有如此不爱惜羽毛的老师呢。
风说，利欲熏心这个熏字很形象。范进中举，教给猪油蒙了心。
博之以文，还得约之以礼不是？
子曰，见贤思齐，见不贤而内自省。
-
Move To Multi-threaded Rails
When doing performance in local box, we found that requests are waiting to be processed due to Railsissingle-threaded by default. We changed the configuration to enable multi-threaded mode as describedin this blogentry:
(also refer toRails 2.2 releasenotes)
The most important change was to eager-load /lib directory, and thus move libraries for test out ofit.
config.threadsafe! also disables automatic loading by ActiveSupport::Dependencies.Alternatively, youcan just add lib/ directory to eager load paths. The following inside production.rb will do that :
config.eager_load_paths “#{RAILS_ROOT}/lib”We had some rough tests to ensure the functionality is not broken. Multi-threaded mode also mightrequire morememory than single-threaded mode. Still keep testing.
-
Tech Lead的三重人格
ThoughtWorks项目中tech lead的三顶帽子
- 技术决策者
- 流程监督人
- 干扰过滤器
温伯格定义技术领导者的三种功能
- 定义问题
- 管理思想的交流
- 保证质量
-
对象健身操：拒绝else
（摘自《ThoughtWorks文集》，第6章，“对象健身操”）
规则2. 拒绝else关键字
每个程序员都熟知if/else结构。几乎每种语言都支持if/esle。简单的条件判断对于任何人来说都不难理解。不过大多数程序员也见识过令人眩晕的层层嵌套的条件判断，以及连绵数页的case语句。更糟糕的是，在现有的判断条件上加一个新的分支通常是非常容易的，而将它重构为一个更好的方式的想法却罕有人去提及。条件判断结构通常还是重复代码的来源。例如，状态标识经常会带来这样的问题：
public static void endMe() {if (status == DONE) {doSomething();} else {// other code}}你有很多种方式重写这段代码，去掉else关键字。例如下面的代码：
public static void endMe() {if (status == DONE) {doSomething();return;}// other code}public static Node head() {if (isAdvancing()) { return first; }else { return last; }}public static Node head() {return isAdvancing() ? first : last;}在上面的例子中，第二段代码由于使用了三元运算符，所以代码长度从四行压缩到了一行。需要小心的是，如果过度使用“提前返回”，代码的清晰度很快会降低。《设计模式》[GHJV95]一书中关于策略模式的部分里有一个实例，演示了如何使用多态避免根据状态进行分支选择的代码。如果这种根据状态进行分支选择的代码大量地重复，就应该考虑使用策略模式了。
面向对象编程语言给我们提供了一种更为强大的工具——多态。它能够处理更为复杂的条件判断。对于简单的条件判断，我们可以使用“卫语句”和“提前返回”替换它。而基于多态的设计则更容易阅读与维护，从而可以更清晰地表达代码的内在意图。但是，程序员要做出这样的转变并不是一帆风顺的。尤其是你的代码中可能早已充斥了else。所以，作为这个练习的一部分，你是不可以使用else的。在某些场景下可以使用Null Object模式，它会对你有所帮助。另外还有很多工具和技术都可以帮助你甩掉else。试一试，看你能提出多少种方案来？
-
过犹不及
道也者，不可须臾离也；可离，非道也。是故君子戒慎乎其所不睹，恐惧乎其所不闻。
（离，去声。○道者，日用事物当行之理，皆性之德而具于心，无物不有，无时不然，所以不可须臾离也。若其可离，则为外物而非道矣。是以君子之心常存敬畏，虽不见闻，亦不敢忽，所以存天理之本然，而不使离于须臾之顷也。）
莫见乎隐，莫显乎微。故君子慎其独也。
（见，音现。隐，暗处也。微，细事也。独者，人所不知而己所独知之地也。言幽暗之中，细微之事，迹虽未形而几则已动，人虽不知而己独知之，则是天下之事无有着见明显而过于此者。是以君子既常戒惧，而于此尤加谨焉，所以遏人欲于将萌，而不使其滋长于隐微之中，以至离道之远也。）
子曰：「道之不行也，我知之矣：知者过之；愚者不及也。道之不明也，我知之矣：贤者过之；不肖者不及也。」
（知者之知，去声。道者，天理之当然，中而已矣。知愚贤不肖之过不及，则生禀之异而失其中也。知者知之过，既以道为不足行；愚者不及知，又不知所以行，此道之所以常不行也。贤者行之过，既以道为不足知；不肖者不及行，又不求所以知，此道之所以常不明也。）
-
AgileChina 2009- Pragmatic Agile
由在敏捷领域最具有影响力的技术社区InfoQ中文站、敏捷方法论的领导厂商 ThoughtWorks共同主办的敏捷中国技术大会（Agile China2009），将于9月11日~12日（周五、周六）在北京举行。届时将有超过500人来自电信、金融、互联网、教育等行业在内的高级软件开发人员、项目管理人员等参加。本次大会将特别邀请敏捷宣言缔造者、敏捷编程（XP）方法学创始人KentBeck，敏捷开发权威人士、敏捷宣言的创始人之一，Dave Thomas，敏捷宣言签署人之一SteveFreeman等国际敏捷领域专家，以及在团队中成功应用敏捷的阿尔卡特、赛门铁克、诺基亚-西门子、华为、腾讯等公司的项目负责人参与此次大会并分享他们的心得。
敏捷中国技术大会（Agile China 2009）是国内敏捷技术领域最高水平的大会，本次大会将由InfoQ中文站负责大会策划、营销和项目实施。InfoQ中文站在今年4月已成功举办了QCon全球企业开发大会，邀请了国内外30多名讲师，超过550位架构师、技术总监、项目经理和高级工程师参加了本次大会，大会及其运营团队获得了空前的好评，并誉为国内“技术含量最高”的大会。而今年的敏捷中国技术大会，也将一改往年的风格，参会者以高端开发者和技术管理者为主，融合管理和工程实践，推广全面敏捷之路。
会务咨询： 010 – 89880682 agilechina@cn.infoq.com
赞助咨询： 010 – 89880682 sponsor@cn.infoq.com
-
Cruise全绿了
好久没有过了也～～Cruise全绿，连IE6的测试也通过了也～～
Cruise是个让人快乐的软件，Mingle是个让人不快的软件，因为Cruise不要你去管它，Mingle总要你拖来拖去_
-
Heal The World
Heal the world.Make it a better place.For you and for me and the entire human race.There are people dying.If you care enough for the living,Make a better place for you and for me.
谨以致敬。
-
实用主义的性能测试：需求采集
（选自《ThoughtWorks文集》第14章）
性能需求采集的重要性经常被人们低估。在这一节里，我将尝试阐明几个重要问题：要度量什么？如何知道我们需要什么？以及如何得到确实有用（而非帮倒忙）的数据？
要度量什么？
最重要的性能度量点有两个：最大吞吐量，以及给定吞吐量下的响应时间。一个好的做法是：分别度量几种不同吞吐量下的响应时间，从中分析负载对响应时间的影响。如果响应的及时性非常重要，那么在确保满足响应时间要求的前提下所能达到的吞吐量可能就会明显低于最大吞吐量。你需要通过度量找出两项数据：当响应时间恰好可以接受时的吞吐量，以及达到预期吞吐量时的响应时间。伸缩性度量的关键则在于：随着数据规模、用户数量或者运行系统的硬件变化，起初得到的性能度量数据会发生怎样的变化。
可靠性的关键度量点是：当负载量高得超乎寻常，或者连续运行了很长时间以后，系统是否仍然正常工作。
如何设定目标？
要想知道系统需要达到怎样的吞吐量目标，你首先需要知道有多少用户会使用这个系统，以及他们的使用模式。用户会多频繁地使用某个功能？这个功能需要多快完成？
业务用户会知道这些问题的答案。你应该让他们明白，你会经常需要向他们咨询这方面的事。然后你应该建立一个良好的沟通流程，以确保信息的获取畅通无阻。
总而言之，你需要有一个可靠的流程与机制来获得所需的信息，使你及时获知支撑业务需求所需的性能指标。如果不经常去计算这些数据，就有可能最后发现你正在朝着已经过时的目标努力。
弄清当前需要负载的吞吐量之后，下一个需要考虑的就是响应时间。在结合UI考虑这个问题时，人们常会有钻牛角尖的想法：既然用户界面要在几秒钟之内响应，那么功能自然必须在更短的时间内完成。但事实并非如此。UI应该立即响应，告知用户：他们的请求已经得到处理；但实际的处理未必马上完成。在整个过程中，系统的其他部分应该照常工作。
响应时间的目标应该主要针对用户界面，并且数值越低越好。而且，不应该期望所有功能都能在同样的一段时间内完成。
如果对前面所说的还不明白，下面我将简单介绍一个采集性能需求的流程。
如何将性能测试融入日常开发流程？
理想情况下，项目组每周应该召开一次会议，确定当前的性能需求。参加这次会议的人应该包括项目经理、关注性能的客户、资深开发者、以及性能测试人员。如果某些性能需求明显无法达到或者完全不合理，开发者就能在第一时间指出。客户的参与是为了提供业务上的信息与知识，从而帮助判断需求的合理性。项目经理需要知道团队做了哪些决定，并提供一些方向性的指导。至于性能测试人员，他们显然应该在场，这样他们才知道需要测试什么。
接下来，你需要找到适当的讨论对象。开发团队需要从客户中找到一个联系人，与他一道决定性能需求，这样才能确保客户和开发者都清楚目标所在。不要把性能需求看作神圣不可侵犯之物，和所有需求一样，它们也应该是开发者与客户对话的起点，双方需要共同讨论决定最终的目标。
一旦需求确定下来，就能决定当需求得到满足时如何向客户展示，并对编写测试的工作进行评估和计划，就跟其他的任务一样。
程序员需要性能测试告诉他们什么？
开发者的需求有很多种，但背后的驱动力总是一致的：如果某段代码需要返工，他们就需要更多的信息来了解当时的情况。这些信息可能来自代码检查工具，也可能来自线程转储，甚至来自日志。他们可能需要知道数据库的忙碌程度，或是负载达到峰值时网络的忙碌程度。
试图预先回答所有这些问题可能并不划算，因为这会需要很大工作量。但我们可以做的是：当问题出现时，弄清哪些信息会有助于开发者解决问题，然后把获取这些信息的任务加到你的任务列表上，并告知客户。此时你就可以判断应该如何进行这些测试：是从此刻开始持续测试，还是只针对眼下的特定问题做一次性测试。
如果开发者的需求以这种方式在会议上提出的，那么所有人都将知道这些需求的存在。客户可以为这些需求排优先级，可以把它们纳入项目计划。最终性能测试将满足各方的需求：它让客户对正在开发的软件保持信心，它也能帮助开发者找到并解决性能问题。
找不到关注性能的客户怎么办？
如果找不到一个关注性能需求的客户，就会有几方面的风险。首先，正在开发的软件可能不符合业务要求，项目可能彻底失败。其次，不管最终的产品如何，客户都可能说它不符合要求，因为他们感觉开发团队没有征求他们的意见。第三，这可能会在团队内部造成紧张气氛，开发团队会觉得自己在被迫做不必要的工作，因为需求不是来自客户──不管项目经理的担心是否正确，这种想法都有可能出现，并导致必要的工作没有被完成，或是相反，开发者们浪费时间去做不必要的工作。
如果客户不懂技术又非要坚持不可能的需求该怎么办？
这种可能性总是存在：客户希望产品的性能达到某个水平，而达到这个水平是不可能或者不经济的。这时你就需要提出一些中肯的问题，把对话引导到真实的业务需求上来，从而打消客户不切实际的要求。
如果客户的要求是关于吞吐量的，可以考虑的问题有：每个工作日处理多少事务？这些事务的时间分布如何？是平均分布还是有明显的高峰期？每个周五下午会有集中访问吗？或者峰值的出现没有特别的模式可循？
关于响应时间，可以考虑的问题有：用户界面的响应时间会对系统的处理能力造成什么影响？能不能把界面与实际的计算操作分离？比如说，可能有这样一种场景：用户输入一些数据，然后进行较长时间的数据处理。此时用户不希望一直等到处理完成，而是希望立即输入下一段数据。所以这时合理的期望不是在一秒钟内完成数据处理，而是将用户界面与数据处理分离，让系统在后台处理前一段数据，同时让用户在界面上输入更多的数据。
以这种讨论方式，我们就能让开发者和客户共同寻找一个对业务价值有意义的性能水平，并且分清什么是当务之急、什么是锦上添花。我们都曾遇到这样的情况：在项目的现有条件下，客户急切希望的某个性能目标不可能达到、或是需要付出高昂的代价。如果相关的分析能尽早开展，客户就有可能在更早的时候做出决定，从而使这些目标成为可能。
如果客户期望的目标不能达成，他们会对最终交付的系统感到失望，哪怕系统其实足以满足业务需求。上述这些讨论有两方面的作用：不仅让开发团队了解客户的真实需求，而且让客户自己也有一个清晰的目标。这样一来，只要系统达到了双方认可的目标，客户就会感到满意。有这些讨论作为基础，客户就不太会坚持不切实际的期望；如果他们仍然感到失望，至少那也是出于合理的原因。
何不让业务分析师一并采集这些需求？
采集性能需求时不一定需要业务分析师在场，原因有几点：首先，此时功能需求的采集应该已经完成了；其次，即使业务分析师在场，开发者还是不能缺席，因为分析性能问题需要获得哪些信息只有开发者才清楚，也只有他们才能判断获得这些信息的途径和难度。性能测试人员应该提出前面介绍的这些问题，以此推动讨论进行，他们也能够判断每个需求是否容易测试。所以，当这些人坐在一起讨论时，业务分析师大可以把时间花在其他更有价值的地方。
小结
需求采集是为了让所有人都清楚：最终交付的产品需要有怎样的性能才能支撑业务目标。之所以要让客户参与，是因为他们最了解自己的业务，这样才能确保采集到的需求足够准确。而且通过讨论也能帮助客户清晰自己对性能的需求，从而有效管理他们对系统的期望。
