HoneyHoney

城堡@舍农索城堡，原由 zhongxiao37 上載。

来来来，继续舍农索城堡

香波城堡，原由 zhongxiao37 上載。

来来来，香波城堡！

Mona Lisa 蒙娜丽莎画前，原由 zhongxiao37 上載。

我永远没有勇气挤到这样的人群中去。只是为了看那A4纸大小，看不清的蒙娜丽莎。

野花, originally uploaded by zhongxiao37.

渐渐的，我发现，美丽其实就在身边，更多的时候，是我们错过了什么。就像草原上那抹阳光，放眼看去不过如此，似乎并没有什么。但拿起相机，你则需要用它去发现隐藏的那份美。

都江堰·外江，原由 zhongxiao37 上載。

上一次来都江堰还是10年前了，那会儿是初中。一眨眼，10年过去了。
那会儿父母还算年轻，看着一条条皱纹爬上额头，脾气越发像个小孩，自己心里真怕哪天陪不了他们了。有空尝尝回家吧。

1. 什么是LB?
   load balancer。负载均衡。将负载进行平衡、分摊到多个操作单元上进行执行，从而降低平衡服务器的负载。
2. LB如何工作？
   
   如图所示，客户端访问服务器的时候，首先访问到的是LB，然后再由LB进行分配。
   1. 首先，LB里面配置有pool和node。每个pool其实就是node的集合。
   2. 客户端访问的时候，LB根据request分配到相应的pool，然后再从pool里面的node挑选出来进行处理。
   3. node其实也就是具体存在的服务器（也有可能是其他，但是现在没有接触到）。
   4. node处理完以后，将reponse返回给LB，再返回给客户端。
3. 玩玩而已
   1. 假如LB里面，Pool A 配置有两个Node B、C。
   2. 在浏览器里面访问服务器，实际是被丢到了Pool A上。ping服务器，将得到Pool A的IP地址。
   3. 在浏览器里面直接访问节点B，即可直接绕过LB。同样也可以通过改服务器配置文件来实现。

公司今年Star Trip去大连玩，人品爆发得到一个机会。时间匆匆，本来想去滨海路溜达的愿望都没有达成。只是匆匆逛了一下老虎滩极地海洋公园。

#虾米音乐#♫ 分享 岑己何时的精选集《仅怀念ni和逝去de爱情》 http://www.xiami.com/song/showcollect/id/10581037

被爱的和有所爱的，都在做着同样的事情：犯贱。

周二买了小米手机，周三到货，算来已经用了几天了。上手还算快了，现在感觉良好。
折腾三天，基本搞定基本的应用了。感觉就像原来自己在大学买的掌上电脑复活了一样。一分兴奋，和一分怀旧。
记得大学的时候，猴子拿着宏基的一款掌上电脑，我的那个羡慕劲啊～省吃俭用，囤了大半年的积蓄，终于从网上入手了一款ppc. 题外话，那会儿的淘宝还没有现在这么让人迷乱。京东也不知道在哪里。大部分的交易是论坛里面找人做担保，或者直接先款后货。那会儿的人真诚实啊！好吧，算我没有遇到坏人。
买来ppc以后就开始各种折腾：泡论坛，看帖子。然后下载各种软件，再找各种注册码。。。各种折腾！记得备份系统的时候是最郁闷的。当时最多只能够4G的内存卡，自己又只买了1G的卡，各种折腾。。。再次题外话，那会儿博客是个新鲜玩意，早一批的微博也是一年以后才流行的。（比如叽歪，饭否。）
有了ppc以后，吃饭香了，睡眠迟了。每天晚上装模作样的跑去上自习，实际上是找先玩一通ppc再说：阅读白天从电脑上更新下来的rss，再做个笔记表示自己很有见解，实际上现在啥都忘记了。或者大半个自习就耗在游戏上了。
ppc除了用来玩游戏（我是说我自己的使用习惯），看rss，还有很多作用，比如：记账，看书，看电影，听歌，查资料等等。基本能够满足我小P民的需求了。
回想大学时候自己看完的小说基本都是在ppc上面看完的。坐在电脑桌前我就很是焦躁，看不了书。
再回想自己记了两年的帐啊！全部都是在ppc上面完成的。
可惜，ppc渐渐退出了历史的舞台，而是以新的一个面孔出现在大家的面前。最好的例子就是windows mobile到windows phone的转变。从wm2002系统到今天，10年了，变化还是很大。
现在一边听着歌，一边敲字。思索着，互联网本来就应该这样做：人们不应该是坐在桌前，而应该是在随时随地通过身边的小设备连接到网络。
怀念那些死去的和半死不活的老智能机们：黑莓，掌上电脑，palm。。。

1. Bug report是门技术活，和写作有关
   不要以为bug report只是简单的描述复现步骤，如果是如此简单，那么谁都可以当测试人员了。即使在测试团队里面，大家有时候还是会去讨论bug report描述不清楚，看不懂，缺少信息等等。为什么会出现这样的情况？
   好了，我在这里就不吐槽国内语文教学如何如何"坑爹"的了。或者，你可以告诉我，中文是一门语境高的语言。可是我的bug report用不到那么高的语境，我需要的只是需要把一个事情描述清楚而已。
   正如大家说，英语学不好，多半是由于语文没有学好。同样，语文没有学好，bug report也写不好。同样一个bug，在不同人的眼里，可以有不同版本的bug report。但是，总有那么一个report，是最简单的，最有效的。有点像设计中的一个理念："总有那么一个最简单，最有效的解决方案！"努力提高自己的写作能力，对于bug report是很有帮助的。
   
2. 如何提高bug report质量
   问题太广，方法太多，需一条一条细数（下面一条一条整理）。但是，如果说没有相应的经历，我估计总是有人不能够理解下面的内容，正如我现在依旧看不懂很多电影。《程序员修炼之道》里面也提到，没有经过几十万行代码的锤炼，是很难达到高手的境界的，也就很难理解高手所说的信息。（额，我不是想说我是高手，只是想说，有过相应的经历以后，再来看这些，会产生一些共鸣。）
3. 多看，多想，多练。
   关于这个，有一个题外话。一般而言，技能提升的方法有2种：外部环境和内心驱动，即外部提供足够的环境促使个人发展和内部驱使自己的个人发展。就我而言，我还是内心驱动那种，结果就是，有时候别人 忽悠我，我生硬地点点头，回头继续干自己的，直到撞到南墙才反省。
   "多看，多想，多练"这个是我刚进公司的时候，上面的manager给我的一个tip。
   1. 多看。刚进公司那会儿不知道如何报bug，或者报的bug太龊，几乎每次都要被师傅给呵斥一顿。后来的方法是看别人报的bug。这个渐渐成了自己每天都会做的一件事，读读别人报的bug，然后试着自己去重现一下。这样，既对产品了解了，知道哪里容易出bug，又能够学习别人报bug的风格。
   2. 多想。在看了那么多bug以后，思考的是：如果这个bug丢给我，该如何去报？动动脑子是一件好事。在想不出比别人更好的描述之前，就会拿当前的描述作为最好的模范，直到有一天你会博采众家之长。
   3. 多练。动手与否，效果很不一样。有时候，我们想了很多，等到做的时候又老是忘记写上重要的信息，或者发现了之前思考不足/遗漏的地方。无论如何，这些是好事，促使自己报出更好的bug。
4. Bug Summary
   我们的测试经理曾经说过，好的bug summary是成功的一半（其实，我也说过，比如在这里 :) ）。怎么说呢？如果bug summary写得足够好，那么别人几乎不需要再仔细看里面的内容，就知道你所描述的bug是怎么回事了。就开发而言，看完summary，再回想一下当初自己是如何设计的，就能够分析出这个问题是如何出现的，该如何去修；就需求分析员/测试经理而言，从summary里面能够读出这个bug的严重性和优先级，尤其是在bug triage的时候，可以节省很多时间。
   好吧。那我把bug summary写得老长老长，将所有想说的都写进去吧！额。。。那这不是bug summary了。既然是summary，那么ta应该是简洁的，优雅的。所以，一般而言，写bug summary的时候，需要思考两个问题：1. 能不能够再短些？2. 有没有歧义？如果说既短又没有歧义，那么，恭喜你，成功一半了。
5. Versions
   应该说很多团队都会在bug report里面包含这些信息。比如，浏览器(Firefox 10.0, Chrome 18.0), 操作系统(Ubuntu 11.04, Windows 7), Flash player version, Build version. Version info可以很好的指出这个问题在哪个版本上面会有这个问题，什么时候出来的，什么时候在哪个版本上修好的。
6. STR (Steps to Reproduce)
   终于到STR了。好吧，这里要详细描述问题是如何出现的。但是，先等等。你的第一步可以执行不？如果说别人第一步都找不到入口，那后面如何执行下去。要保证第一步是可以执行的。但是这样有可能导致另外一个情况：步骤很多，20多个步骤。好吧，你写得绝望，开发也看得绝望。如何解决？在STR之前插入pre-condition，也就是说，在做第一步操作之前的一些准备工作。或者，提供测试环境上面的数据给开发作为reference。
   关键步骤的时候，尽量用'华丽的分割线'将其标出来。要不，开发没有留意到你这里是这么写的，直接说"不能够重现"，那一来一往又多几分折腾。
7. Screenshot, Video
   截图和视频是"必杀技"。对于界面上的issue，一个简单的截图超过千言万语；对于复杂的操作，一段视频胜过20多行steps。对于截图有一个小提示，尽量将问题所在地方圈出来并加上注释。要不，有可能别人费老大劲在你的图上找问题所在"你妹的，到底哪里有问题啊？我怎么看都是好的呢？坑爹呢！"
8. 【进阶】Error log
   抓取错误信息并试图去读错误信息。一般来说，如果error是被代码捕获到的话，那么error log里面提示就能够很好的说明这个问题为啥会出现了。（应该大部分开发都会这么做吧！）至于没有被代码捕获的error log，那么error log里面的哪个文件多少行哪个方法的时候抛错，也是很有意义的。这对于开发，是好事。对于测试人员来说，如果对代码有兴趣的话，还可以从log里面看到后台是如何实现的。一般而言，后台里面有很多debug级别的信息，描述了后台是如何处理消息的，在处理什么的时候报错的。这样对于理解背后service是如何工作的很帮助。慢慢积累多了，就知道某个error为何会出现，或者根据error log分析出如何重现问题（这个是分析production环境上缺陷的很好方法）。
9. 【进阶】Comments.
   如果说，以上都有了，都很不错了，那么，一个简单的comments将为这个bug report'画龙点睛'。比如，你写到'这个缺陷只在这种条件下能够重现，其他条件下没有这个问题'，或者'这个缺陷是由于client端发送给service端的消息错误导致的'。这些，可以更好地帮助别人， 也可以为你加分。
10. Template
    按照上面的说法，建立一个适合自己/小组的bug report template将是很有用的。这样能够保证bug report里面提供足够的信息，省去到时候漏掉这个漏掉那个的。既然这么好，为什么不用呢？（其实，当初写template的缘由是自己每次都要去copy以前的bug report。后来，直接抽出里面共有的部分，建立成template。其实，开发常常干这事。）
11. 因人而异，因地制宜。
    最后来点玄乎的吧！回头来看以上的东西，真的就那么好么？一是，这只是我自己脑海里面的东西， 这些东西可能不适合你，而且，若干年以后我自己再来看这些不知道是不是会苦笑；二是，本来这些不是一成不变的，因人而异，因地制宜吧！
    如果说，简单的界面问题，你有必要写那么多steps么？一个简单的截图搞定；如果说，你的开发团队就在你的身边，简单口述/重现一下问题给他，胜过文字的冷冷冰冰； 如果说你的开发团队在地球另外一边，那你还是老老实实写那么多东西吧！一来一回真的很折腾！