这篇文章用以记录这两天折腾微博同步的全过程，也即种种不成功方案的总结，这篇文章也包括了自己同步需求的最终实现方案，以及我所预期的更为完美的解决方案。
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为何能一枝独秀？后来从这里找到了答案。
Showing posts with label testing experience. Show all posts
Showing posts with label testing experience. Show all posts
2013/03/21
2011/08/14
Google Task的伪Bug
Google Task是Google的一个轻量级的Todo List小工具，称不上强大，却很管用，又因为是谷歌的产品，与Google的其他应用整合得非常方便，比如 Google Calendar。所以，对于多如牛毛的其他在线Todo List工具软件我一概不予理会。
美中不足的是，Google Task的New List不能作降序排列，新建的List永远排在列表末端。比如，当我为今天的待完成任务新建了一个以日期为名的2011-08-15列表后，我却不得不像翻日历一样从最老旧的列表头一直拖到列表尾，才能查看到我今天的任务列表。为此，我也与其他用户一同在Google的网站上抱怨和反映过，希望Google开发团队能够修复这个"Bug"。
然而，今天偶然打开Google Task那个不足1分钟的DEMO视频时，镜头中有个画面闪过DEMO中所用的列表名，不是我那种日期命名的列表，而是“某某人的列表”，比如：Gordon's List。
就这么一瞅，着实启发了我，谁规定一定要以日期为列表命名？仅仅是因为Todo的内在日期属性？而且以日期命名列表、逐日新建列表的副作用实在太过于明显了——列表会越来越长，当然还包括上面提到的“Bug”——新列表永远被置于末端。
换个思路，如果以类别为名新建列表呢？比如建三个列表，分别为“工作”、“学习”、“生活”，将每日必做事项分门别类填入这三个类别。新建、修改和查找列表及列表中的任务时，鼠标只需在三个列表之间切换，何须担忧谁排在上、谁排在下？
对于怕麻烦的用户，甚至于可弃此“新建列表功能”不用，就在唯一的默认列表内不断添加、删除（或者不去删除）每日工作事项、学习任务和生活安排，也绝没有什么不妥。
这个小发现，除了让我的Google Task用得更欢，还给了我一个不小的启发，有时候“Bug”是人造成的，这个人不是Developer，而是QA和Customer自己。在没有需求说明书或者需求不明的情况下，碰到“Bug”尤其要多想想，而且要跳出思维定势，熟悉软件在某些时候还真不是一件容易的事情。不想，不做多角度的思考，就很容易掉进“伪Bug”的陷阱。
美中不足的是，Google Task的New List不能作降序排列，新建的List永远排在列表末端。比如，当我为今天的待完成任务新建了一个以日期为名的2011-08-15列表后，我却不得不像翻日历一样从最老旧的列表头一直拖到列表尾，才能查看到我今天的任务列表。为此，我也与其他用户一同在Google的网站上抱怨和反映过，希望Google开发团队能够修复这个"Bug"。
然而，今天偶然打开Google Task那个不足1分钟的DEMO视频时，镜头中有个画面闪过DEMO中所用的列表名，不是我那种日期命名的列表，而是“某某人的列表”，比如：Gordon's List。
就这么一瞅，着实启发了我，谁规定一定要以日期为列表命名？仅仅是因为Todo的内在日期属性？而且以日期命名列表、逐日新建列表的副作用实在太过于明显了——列表会越来越长，当然还包括上面提到的“Bug”——新列表永远被置于末端。
换个思路，如果以类别为名新建列表呢？比如建三个列表，分别为“工作”、“学习”、“生活”，将每日必做事项分门别类填入这三个类别。新建、修改和查找列表及列表中的任务时，鼠标只需在三个列表之间切换，何须担忧谁排在上、谁排在下？
对于怕麻烦的用户，甚至于可弃此“新建列表功能”不用，就在唯一的默认列表内不断添加、删除（或者不去删除）每日工作事项、学习任务和生活安排，也绝没有什么不妥。
这个小发现，除了让我的Google Task用得更欢，还给了我一个不小的启发，有时候“Bug”是人造成的，这个人不是Developer，而是QA和Customer自己。在没有需求说明书或者需求不明的情况下，碰到“Bug”尤其要多想想，而且要跳出思维定势，熟悉软件在某些时候还真不是一件容易的事情。不想，不做多角度的思考，就很容易掉进“伪Bug”的陷阱。
Subscribe to:
Posts (Atom)