2014/03/20

Praying for MH370

While all the world is praying for the MH370, I am deeply touched by the pictures created and posted on the web by different people praying for the missing flight. So I made this brief clip using some of them, expressing my best wishes to those on the Malaysia flight MH370.

Courtesy of the copyright owners and holders of the music and pictures.

2013/10/12

立此存照:Comments on Rogers Wireless Outage

According to a CBC report, it has been explained by Rogers that the wireless service outage across the country for a couple of hours on Wednesday evening was caused by a software problem, but no further details released.

Even after the voice and messing services restored, customers continued complaining and leaving huge amounts of comments on the web. More than 1200 comments have been posted on a single CBC article, and interesting information can be read between the comments of the report, besides of expectation of the level of compensation from Rogers, there are also different hypothesis of the root cause of the outage. It is hard to tell if these information are reliable, but really informative and interesting.

Here is the CBC news report and a huge amount of comments followed, and it is too long to have an entire screenshot as I planned, so I had to give up the idea and just captured a part of them attached here.

CBC News: Rogers cellphone outage caused by software problem
Screenshot 1
Screenshot 2


---

借此,测试了百度云盘的外链,不错;以及几个截屏工具滚动截取超长网页的能力,遗憾,无一胜任。

2013/03/29

微博同步控的一次完整测试 | A Sync Test for Google Plus & Tencent Weibo

这篇文章用以记录这两天折腾微博同步的全过程,也即种种不成功方案的总结,这篇文章也包括了自己同步需求的最终实现方案,以及我所预期的更为完美的解决方案。

1、同步需求

我的同步需求很简单,即同步Google+与腾讯微博。由于当下第三方同步工具层出不穷,各微博程序之间的同步事实上已经不像一两年前那么难为,但此轮测过程中,才意识到自己碰到了微同步过程中的一块硬骨头:Google+。

我的云端硬盘几乎都与Google关联,各种资料和应用都跟Google天然捆绑在一起,所以自Google Buzz破茧成蝶进化成Google+ 之日起,我就毫不犹豫决定采用Google+来记录自己的闲言碎语。但由于谷歌受制于“墙”,我也就没有去悉心经营Google+的Circle,自己的社会化网络联系仍以腾讯的Q友为主。这也就是此同步需求的缘由。



2、同步小议

同步实现的方法或方案,不外乎以下三种:

1)同步链(A->B->C -->X)

2)脚本

3)工具(支持绑定多帐户的微博发布平台)


上述三种方法所衍生出的各同步方案,此番测试悉数用尽,竟无一能实现我的同步需求,其实都是谷歌的错。



3、不成功的方案


1)为Google+生成RSS Feed,进而推送至腾讯微博

Google+从问世之日起,就未提供RSS订阅,但网上有不少第三方工具可供生成Feeds (http://bit.ly/15WZvHc,http://bit.ly/15WZGCc,http://bit.ly/15WZseu)。通过这些服务,生成了自己Google+的Feed,交给腾讯微博的“博客同步”,却被“诊断”为非有效RSS地址,于是又裹上一层国产的“飞递”(Feedsky)的外衣,这回腾讯认了,可是“博客同步”的效果实在太差,格式不美观,而且同步慢,最严重是,还会漏递。

2)饭否接收Google+,同时绑定腾讯微博

饭否所提供的与腾讯微博绑定,同步效果不错;同时饭否还有一款第三方开发“饭否博客导入”应用(FFReeder),这就给我提供了上述曲线救国的思路。本来,我确实通过这个方案实现了短暂的同步,后来这个应用无故失效,测试了不同的RSS地址,均未能成功在饭否上发布,因此,腾讯微博那一头也就断了源头活水。


4、同步需求转换

既然Google+与腾讯微博直通的可能性渺茫,我的同步思路便转换成了网络上更为主流的寻求“以Twitter为中心”的同步方案。鉴于此时我已经找到了非常不错的同步Twitter与Google+的方法 (通过Hootsuite),我只要在Twitter与腾讯微博之间建立同步,即可间接地实现我的同步需求。

于是,我先后找到并测试了如下的各方案,仍然是不尽人意,最终逐一放弃,经验教训一言难尽,方法列举如下,细节不再赘述。

3)Gtalk添加饭否机器人(Fantalk),Fantalk同时绑定Twitter与腾讯

4) Tw2other
 

用PHP写的同步脚本,网上有详细介绍(http://bit.ly/YV5kkj,http://bit.ly/YV5iss)

5) 在Google GAE上部署计划任务


这是网上除Tw2other之外,另一个流行的脚本同步方案,网上相关介绍很多(http://bit.ly/YV6dt7,http://bit.ly/YV6uwb,http://bit.ly/YV6goG,http://bit.ly/YV6nRi)


4. 不完美解决方案

通过以上诸多不成功的同步测试,感觉通过同步链或脚本实现同步不靠谱,经不住时间考验,很容易失效。最终决定选用微博同步工具作为不完美的解决方案。此类工具通过认证绑定微博帐户,从而实现在同一个平台写微博、在多个微博帐户发布。之所以说不完美,是因为至今仍未找到支持同时绑定Google+和腾讯微博的。

1)Hootsuite

http://hootsuite.com

这是家加拿大本土的IT公司所提供的:服务,支持Google+、Twitter、Facebook等帐户绑定,没腾讯微博的事儿。

2)微博通

http://www.wbto.cn

这个工具能绑定的帐户还真不少,包括腾讯在内,甚至被墙的也能绑定,可是独缺Google+。

所以,目前就得靠“Hootsuite + 微博通”来实现不完美的同步;同时,期待着假以时日,它们或别的什么工具能让我谷歌与腾讯兼得。


5、其他,关于Google+


同步测试过程中,了解到市场上鲜有Google+的同步服务,根本原因是Google+一直没有对第三方开放API写的权限。那么我就纳闷Hootsuite为何能一枝独秀?后来从这里找到了答案。


2013/03/22

一个笑话,测试驱动的重要性

有这么一个笑话(转):

1. 程序员写出自认为没有Bug的代码。
2. 软件测试,发现了20个Bug。 
3. 程序员修改了10个Bug,并告诉测试组另外10个不是Bug。
4. 测试组发现其中5个改动根本无法工作,同时又发现了15个新Bug。 
5. 重复3次步骤3和步骤4。
6. 鉴于市场方面的压力,为了配合当初制定的过分乐观的发布时间表,产品终于上市了。 
7. 用户发现了137个新Bug。
8. 已经领了项目奖金的程序员不知跑到哪里去了。
9. 新组建的项目组修正了差不多全部137个Bug,但又发现了456个新Bug。 
10. 最初那个程序员从斐济给饱受拖欠工资之苦的测试组寄来了一张明信片。整个测试组集体辞职。 
11. 公司被竞争对手恶意收购。收购时,软件的最终版本包含783个Bug。
12. 新CEO走马上任。公司雇了一名新程序员重写该软件。
13. 程序员写出自认为没有Bug的代码。

怎么样?这个笑话是否博得您会心一笑、心照不宣呢?在这个玩笑似的例子中,一切都是以开发工作在驱动,这首先就是一个方向性错误。产品最终是要为用户服务的,当然应该是以用户和市场作为驱动,并且结合自身的能力最终确定工作的重点。这一错误折射出项目管理者对被管理的内容很不了解,只好任由比较了解的程序员摆布——事实上,他们除了技术,并不会了解更多。

其次是质量把关。基本的质量管理常识告诉我们,每次循环结束前,最重的工作就是总结改进。只有这样才能保证循环运作是向上发展,而不是失去控制地向下发展。也只有有效的测试和质量管理,才能保证迭代过程是收敛发展,并最终达到目标。但在上述例子中,这个部分显然是低效的。

而后是人力资源管理。软件开发是一项劳动密集型的工作,虽然这是脑力劳动的密集,但同样意味着人为因素在其中占有决定性的地位。例子中未能改完BUG的程序员拿到了项目奖金,而同样辛苦工作的测试人员却低人一等,被拖欠薪资,表现出管理者对他们的工作内容毫不了解,以及对软件质量管理的极不重视。这是一种谋杀团队的行为——谋杀一个团队远比建设一个要容易得多。

来源:转自新职的电邮