Cruise全绿了
June 30th, 2009
好久没有过了也～～Cruise全绿，连IE6的测试也通过了也～～
 |
Cruise是个让人快乐的软件，Mingle是个让人不快的软件，因为Cruise不要你去管它，Mingle总要你拖来拖去 _
Heal The World
June 26th, 2009
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.
谨以致敬。
实用主义的性能测试：需求采集
June 12th, 2009
（选自《 ThoughtWorks文集 》第14章）
性能需求采集的重要性经常被人们低估。在这一节里，我将尝试阐明几个重要问题：要度量什么？如何知道我们需要什么？以及如何得到确实有用（而非帮倒忙）的数据？
要度量什么？
最重要的性能度量点有两个：最大吞吐量，以及给定吞吐量下的响应时间。一个好的做法是：分别度量几种不同吞吐量下的响应时间，从中分析负载对响应时间的影响。如果响应的及时性非常重要，那么在确保满足响应时间要求的前提下所能达到的吞吐量可能就会明显低于最大吞吐量。你需要通过度量找出两项数据：当响应时间恰好可以接受时的吞吐量，以及达到预期吞吐量时的响应时间。伸缩性度量的关键则在于：随着数据规模、用户数量或者运行系统的硬件变化，起初得到的性能度量数据会发生怎样的变化。
可靠性的关键度量点是：当负载量高得超乎寻常，或者连续运行了很长时间以后，系统是否仍然正常工作。
如何设定目标？
要想知道系统需要达到怎样的吞吐量目标，你首先需要知道有多少用户会使用这个系统，以及他们的使用模式。用户会多频繁地使用某个功能？这个功能需要多快完成？
业务用户会知道这些问题的答案。你应该让他们明白，你会经常需要向他们咨询这方面的事。然后你应该建立一个良好的沟通流程，以确保信息的获取畅通无阻。
总而言之，你需要有一个可靠的流程与机制来获得所需的信息，使你及时获知支撑业务需求所需的性能指标。如果不经常去计算这些数据，就有可能最后发现你正在朝着已经过时的目标努力。
弄清当前需要负载的吞吐量之后，下一个需要考虑的就是响应时间。在结合UI考虑这个问题时，人们常会有钻牛角尖的想法：既然用户界面要在几秒钟之内响应，那么功能自然必须在更短的时间内完成。但事实并非如此。UI应该立即响应，告知用户：他们的请求已经得到处理；但实际的处理未必马上完成。在整个过程中，系统的其他部分应该照常工作。
响应时间的目标应该主要针对用户界面，并且数值越低越好。而且，不应该期望所有功能都能在同样的一段时间内完成。
如果对前面所说的还不明白，下面我将简单介绍一个采集性能需求的流程。
如何将性能测试融入日常开发流程？
理想情况下，项目组每周应该召开一次会议，确定当前的性能需求。参加这次会议的人应该包括项目经理、关注性能的客户、资深开发者、以及性能测试人员。如果某些性能需求明显无法达到或者完全不合理，开发者就能在第一时间指出。客户的参与是为了提供业务上的信息与知识，从而帮助判断需求的合理性。项目经理需要知道团队做了哪些决定，并提供一些方向性的指导。至于性能测试人员，他们显然应该在场，这样他们才知道需要测试什么。
接下来，你需要找到适当的讨论对象。开发团队需要从客户中找到一个联系人，与他一道决定性能需求，这样才能确保客户和开发者都清楚目标所在。不要把性能需求看作神圣不可侵犯之物，和所有需求一样，它们也应该是开发者与客户对话的起点，双方需要共同讨论决定最终的目标。
一旦需求确定下来，就能决定当需求得到满足时如何向客户展示，并对编写测试的工作进行评估和计划，就跟其他的任务一样。
程序员需要性能测试告诉他们什么？
开发者的需求有很多种，但背后的驱动力总是一致的：如果某段代码需要返工，他们就需要更多的信息来了解当时的情况。这些信息可能来自代码检查工具，也可能来自线程转储，甚至来自日志。他们可能需要知道数据库的忙碌程度，或是负载达到峰值时网络的忙碌程度。
试图预先回答所有这些问题可能并不划算，因为这会需要很大工作量。但我们可以做的是：当问题出现时，弄清哪些信息会有助于开发者解决问题，然后把获取这些信息的任务加到你的任务列表上，并告知客户。此时你就可以判断应该如何进行这些测试：是从此刻开始持续测试，还是只针对眼下的特定问题做一次性测试。
如果开发者的需求以这种方式在会议上提出的，那么所有人都将知道这些需求的存在。客户可以为这些需求排优先级，可以把它们纳入项目计划。最终性能测试将满足各方的需求：它让客户对正在开发的软件保持信心，它也能帮助开发者找到并解决性能问题。
找不到关注性能的客户怎么办？
如果找不到一个关注性能需求的客户，就会有几方面的风险。首先，正在开发的软件可能不符合业务要求，项目可能彻底失败。其次，不管最终的产品如何，客户都可能说它不符合要求，因为他们感觉开发团队没有征求他们的意见。第三，这可能会在团队内部造成紧张气氛，开发团队会觉得自己在被迫做不必要的工作，因为需求不是来自客户──不管项目经理的担心是否正确，这种想法都有可能出现，并导致必要的工作没有被完成，或是相反，开发者们浪费时间去做不必要的工作。
如果客户不懂技术又非要坚持不可能的需求该怎么办？
这种可能性总是存在：客户希望产品的性能达到某个水平，而达到这个水平是不可能或者不经济的。这时你就需要提出一些中肯的问题，把对话引导到真实的业务需求上来，从而打消客户不切实际的要求。
如果客户的要求是关于吞吐量的，可以考虑的问题有：每个工作日处理多少事务？这些事务的时间分布如何？是平均分布还是有明显的高峰期？每个周五下午会有集中访问吗？或者峰值的出现没有特别的模式可循？
关于响应时间，可以考虑的问题有：用户界面的响应时间会对系统的处理能力造成什么影响？能不能把界面与实际的计算操作分离？比如说，可能有这样一种场景：用户输入一些数据，然后进行较长时间的数据处理。此时用户不希望一直等到处理完成，而是希望立即输入下一段数据。所以这时合理的期望不是在一秒钟内完成数据处理，而是将用户界面与数据处理分离，让系统在后台处理前一段数据，同时让用户在界面上输入更多的数据。
以这种讨论方式，我们就能让开发者和客户共同寻找一个对业务价值有意义的性能水平，并且分清什么是当务之急、什么是锦上添花。我们都曾遇到这样的情况：在项目的现有条件下，客户急切希望的某个性能目标不可能达到、或是需要付出高昂的代价。如果相关的分析能尽早开展，客户就有可能在更早的时候做出决定，从而使这些目标成为可能。
如果客户期望的目标不能达成，他们会对最终交付的系统感到失望，哪怕系统其实足以满足业务需求。上述这些讨论有两方面的作用：不仅让开发团队了解客户的真实需求，而且让客户自己也有一个清晰的目标。这样一来，只要系统达到了双方认可的目标，客户就会感到满意。有这些讨论作为基础，客户就不太会坚持不切实际的期望；如果他们仍然感到失望，至少那也是出于合理的原因。
何不让业务分析师一并采集这些需求？
采集性能需求时不一定需要业务分析师在场，原因有几点：首先，此时功能需求的采集应该已经完成了；其次，即使业务分析师在场，开发者还是不能缺席，因为分析性能问题需要获得哪些信息只有开发者才清楚，也只有他们才能判断获得这些信息的途径和难度。性能测试人员应该提出前面介绍的这些问题，以此推动讨论进行，他们也能够判断每个需求是否容易测试。所以，当这些人坐在一起讨论时，业务分析师大可以把时间花在其他更有价值的地方。
小结
需求采集是为了让所有人都清楚：最终交付的产品需要有怎样的性能才能支撑业务目标。之所以要让客户参与，是因为他们最了解自己的业务，这样才能确保采集到的需求足够准确。而且通过讨论也能帮助客户清晰自己对性能的需求，从而有效管理他们对系统的期望。
rake stats (again)
June 8th, 2009
用Ruby翻新一个Java的系统。原来系统功能代码47311行，测试代码13440行（都只计算Java代码）。还没翻完。
+----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+-------+-------+---------+---------+-----+-------+ | Controllers | 1403 | 1188 | 31 | 131 | 4 | 7 | | Helpers | 361 | 311 | 0 | 52 | 0 | 3 | | Models | 2236 | 1837 | 77 | 270 | 3 | 4 | | Libraries | 2115 | 1740 | 30 | 156 | 5 | 9 | | Model specs | 2443 | 2022 | 0 | 18 | 0 | 110 | | View specs | 0 | 0 | 0 | 0 | 0 | 0 | | Controller specs | 3315 | 2716 | 0 | 2 | 0 | 1356 | | Helper specs | 374 | 310 | 0 | 0 | 0 | 0 | | Library specs | 822 | 708 | 0 | 3 | 0 | 234 | +----------------------+-------+-------+---------+---------+-----+-------+ | Total | 13069 | 10832 | 138 | 632 | 4 | 15 | +----------------------+-------+-------+---------+---------+-----+-------+ Code LOC: 5076 Test LOC: 5756 Code to Test Ratio: 1:1.1
这次是JRuby on Rails。我特别喜欢它的部署脚本。
Love Me Or Hate Me
June 8th, 2009
Love me or hate me, it's one or the other. Always has been. Hate my game. My swagger. Hate my fadeaway. My hunger. Hate that I'm a veteran. A champion. Hate that. Hate it with all your heart. And hate that I'm loved, for the exact same reasons.
每年的那几天
June 2nd, 2009
又来了。
好吧，Flickr我已经不大用了，Twitter…虽然让我生活很闷…
但WorldPay也干掉可算怎么回事涅？
害我们的build一下午就没绿过。嗯，这是个好例子，告诉我们，Testability Driven Design是很重要的。
娘希匹。
刻鹄不成尚类骛
May 24th, 2009
又来了深圳。还是为那个著名的客户。
飞机上读《胡适传》，觉得罗老师一半在讲胡适，一半在讲自己的治学观念。“种不亡之远因”这话多次重复以后，扼腕之情，自勉之意，跃然纸上矣。
打破一种旧体系，唤起一种新希望，固非易事。然则，风也说过多次，革命第二天该当何如，恐怕是一个更难、更实在、更不浪漫、却也更要紧的问题。邯郸学步失其故行。在其本身恐怕当时的念头只是“不论这新的是什么，总不能比旧的更坏了”，而在推动者而言，不当不为这“下一步”有所打算。
越当其变化激越之时，越有正本清源的诉求，本是人之常情。只是，如果只把自己看作一介匠人，终归刻鹄不成尚类骛，不得其本犹可得其末，也算不无裨益；倘若硬要存作圣之心，唯恐画虎不成反类犬，便只剩这日见激越的革命热情了。
所以读坛经却偏爱神秀者，自知愚钝，能时时勤拂拭便已。何况是面对着成千上万亟求助者，哪来这许多慧根能幡然醒悟？
能做一点事就是好的。至于能否“必以正名”，于我何有哉？
ThoughtWorks文集：介绍
May 10th, 2009
（摘自《 ThoughtWorks文集 》，第1章。）
作为一家公司，ThoughtWorks汇聚了一批热情洋溢、积极主动、才智过人的员工，他们为客户提供定制软件开发以及切合实际的咨询服务。如果你问一个ThoughtWorker，这家公司最让他最喜欢的是什么，他很有可能会告诉你：正是那些朝夕相处、并肩工作、彼此学习的同事们。在这个群体里融合了技术极客、管理者、分析师、程序员、测试员和行政人员，他们有着不同的种族、文化和教育背景。这种背景和视角的多样性，再加上坚持正确观点的热情，引发了很多活跃的讨论。
如今ThoughtWorks拥有近千名聪明而有见地的员工，在全球6个国家设有分支机构，组织内部几乎没有任何层级，并且一以贯之地坚持信息透明。可以说，我们已经创造了一家成功的企业。但我们对“成功”的定义远不止于此：一家企业的成功不仅意味着让客户满意，还应该对整个行业乃至整个社会产生正面的影响。我们有着更高的目标。
在博客世界里，在技术大会的会场中，在互联网上，在书架上，我们都能听到ThoughtWorker的声音。在不断追求卓越的过程中，我们会近乎冷酷地剖析自己曾做过的事、以及做这些事的方法，以寻求改进之道──在这方面我们永无饗足。在上下求索之中，一旦学到了什么知识，我们就希望与他人共享。
...
这本文集所收录的文章虽然各自成篇，彼此之间却有着千丝万缕的联系：它们共同展示了一片布满迷雾的IT丛林，以及一条条或显而易见、或出人意表的林间小径。文章选题跨度之宽、解决问题的办法差异之大，恰能反映众位作者所在的这个组织为各种思想的萌生营造了一个健康的环境。阅读这本文集恰如管中窥豹，让我迫不及待地想看到这些才华横溢的同事们为整个行业、整个社会创造更多。
见微知著
April 25th, 2009
一、只发小牢骚
“Larry is more evil than Bill.” Well, they are both rich and neither of them would give me even a cent. It’s not about morality, IMHO.
Cucumber sucks. DSL comes from refactoring, instead of heavy up-front design.
Selenium sucks…hard to write and take long to run.
You just have to blame something if you don’t want to blame yourself :D
二、Tech Lead
As a tech lead, I want the team ignore my existence, so that they can do their best job (and I can have a rest).
Try to prevent things from deadlocking each other.
Martin Fowler is now following you on Twitter!
三、见微知著
“见微知著”这个词是见微知著的，如果用粤语来读。
“见”，古音g声。“微”，古音m声。“知”，古音j声。“著”，入声字。
像“见微知著”这样能描述自己的词是自指的。例如“两个字的”这个词就不是自指的。
那么，“非自指的”这个词是不是自指的呢？
迈出走向悖论的第一步。
学好音体美
April 9th, 2009
一、清新
张悬的歌让我听得肠子发青嘴里淡出鸟来，就像一杯豆浆兑了五杯水
苏打绿的歌其实…还好…在我不知道是男人唱的之前
发现自己对新歌的接受度很低，还是听老歌吧
二、同事们
和小龙龙pair的方式是，小龙龙写很牛逼的script，我给小龙龙放歌听。
郑胖子这个昵称如今终于没有歧义了。
完美的黄亮，真是SUI啊～～黄凉粉团招新进行中
路线总是容易讲的，挽起袖子做事才算专业
Copying Java code with Ruby…
三、Endeca
Upgrading to 6.x
I would be happy to stay on the existing Java API. The newer RAD API is still not widely used and will probably add more risk.
Well, personally I’d prefer http-based API than language specific API. However, you know, it’s all about tradeoff.
四、音体美
上学的时候老师说学好数理化走遍天下都不怕
上学的时候老师说音体美都是副科
于是长大了我们羡慕旁人多才多艺
于是长大了我们也想学点音体美
海鸥，考拉先生，大桥，教堂，桌子，椅子，手
画素描是很好玩的事，它让人平静忘记时间
