今天介绍五个统计应用，都是我亲身体验，并且十分靠谱的应用，现分享如下：

1、doesfollow

判断某人是否follow了某人。点开之后直接输入需要查询的两人的帐户名即可，例如我们可以看一下Twitter的创始人Evans Williams是否follow了奥巴马的Twitter账号，输入ev、BarackObama回车即可看：

不过我坚持认为Follow要基于一种自由、必要的原则：不要强迫任何人follow你，也不要follow太多的人。我相信我的700多个follower中肯定有一部分人不需要follow我的：）

2、TweetStats

这个工具可以帮你分析你自己的Twitter内容，例如你经常和什么人交流，一般什么时间段发言，等等，十分有趣；只需要输入你的用户名即可（你也可以偷窥别人的，嘿嘿）

这个是我的Twitter的日均统计图：

这个是奥巴马同学的图：

3、Twitterholic

Twitterholic不但能够统计出你的一些基本数据，更能将这些数据与其他Twitter用户进行比较，而得出一个排名。这也是众多统计应用中最有趣的一点，例如这里是北京地区的follow数前十名：

而总的统计数据显示，奥巴马同学的排名无论是Follow还是Friends都是第一名，他有158,015个好友，其中有152,941个follow了他。

说个花絮：据我所知，Obama的Twitter有专人维护，并不会主动follow任何人，而一旦有人follow过来，就会follow回去。看来有5000多人在骗的奥巴马的follow之后又偷偷地抛弃奥巴马同学了，呵呵……

4、TwitterRank

好了，最后一个介绍TwitterRank这个创意。记得大约一个月前，我和几个冤大头在Twitter上发了一个“我的TwitterRank是xxx”之类的消息。然后不少同学都纷纷前往试探。结果紧接着就开始了大面积的传言说TwitterRank是钓鱼网站。然后我第一时间修改了密码，并通知朋友们也修改密码。这事儿也就告一段落了。

结果今天再去看TwitterRank的官方网站，发现作者摆明了自己的身份：Ryo Chijiiwa（在Yahoo做过技术主管）。而事实也并非那么可怕，至少，ZDNet、Mashable都给出了正面的评价。而这位Ryo同学，也整出一个“Top50”的榜单，截图如下：

 

据我个人观察，这几个人都具备follower和following比极高，updates数极多的特色；同时也是更新积极的一批同学。

不过说实话，Twitter是一个非常私人的东西，如果是网页、媒体应该有Page Rank来衡量权威度的话，TwitterRank即便真的是一个很科学的计算，也没有太大实质价值：难道你会在Twitter上守着看新闻么？我是不会的……恐怕只有韩国明星的粉丝们才会24小时守着一个新闻源看新闻……

5、Tweetwasters

这个统计系统可以告诉你有多少时间浪费在Twitter上了：）我的结果是：一共有1946次更新，如果每一次更新要花掉30秒的话（很保守的估计），那么我已经在Twitter上“浪费”了16个小时。看来我真是健康啊：）

2008年12月28日新增两个：

6、Twitter Grader

这是一款早期的Twitter统计工具。遗憾的是，算法似乎需要更新了，我的Grade居然是99.4，而满分（100）的Twitter更是有一大把。截图：

7、monitter

比较酷的一个监控器，可以选择三个关键词进行监控。采用了AJAX技术，只有一个页面，输入关键词即可，十分简易，截图：

注意，上方有一系列小工具，例如限定地理范围、改变配色方案等，都很有趣，可以尝试一下。

15条评论, 立即发言 | 本文关键词: API, SNS, twitter, 第三方客户端

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1638

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

今天，我分享一些自己所知更多的更新渠道。由于Twitter提供很开放的API，并且专注于平台本身，因此第三方的产品都做的十分优秀。这和国内SNS惺惺作态的开放形成鲜明对比。

其实，经过数年的发展，Twitter的第三方应用不胜枚举，在这个Wiki形式的页面，按照操作系统、应用类别，统计了几百个Twitter应用。但是，真正优秀的应用却并不多。更何况这个Wiki页面居然被墙了（听一首《老师你好》解解气吧）

这里，我将自己体验过的数个优秀的应用分为“桌面设备”和“移动设备”两类来介绍，欢迎补充（尤其是Mac用户）：

一、桌面应用

以下列举一些Twitter的优秀第三方应用，大家各取所需即可。我个人推荐Twhirl

1、官方Widget

官方Widget主要有Flash版本和HTML版本两种。功能简易但比较稳定，适用于放在博客侧边栏或者其他Profile页面。Flash版的截图：

获取地址在：twitter.com/widgets/which_widget

2、Twhirl

我可以肯定Twhirl是最受欢迎、最稳定高效的一款Twitter客户端。因为它使用了Adobe AIR技术，并且有商业公司支持（融资到1200万美元的seesmic）。是的，这款技术能够跨平台使用FlashPlayer、DHTML和Native文件系统等丰富地API，使用方便，功能强大。更重要的是，它的安装采用了Adobe在FlashPlayer中内嵌的安装机制，十分流畅：进入这个页面，点击右侧那个“Install now”，就可以安装了。截图：

3、Spaz

Spaz也许现在还比Twhirl粗糙许多，但这是一款开源的AIR程序，前途无量。下载地址在这里，我的一张截图：

PS：Spaz还有一个可爱的地方就是会有不少小音乐提示。

4、Digsby

虽然理念先进，并且跨平台强，Digsby却是一个SNS+EMail+IM的“怪胎”。我个人觉得网站宣传画虽然做的不错，但细节还需要改进，而且把这么多服务集成到一体，自然前路漫漫：本来用户是希望能提高效率，可现在的Digsby我认为还不如分别单独使用SNS、EMail和IM来的方便。如果要长期使用，最好观察一段时间再下载。我也放一张截图：

（上图中右侧是好友列表，Twitter的时间线需要点击一下才出现，很怪诞的设计啊……）

二、移动设备

我个人并不支持短信方式的同步。因为众所皆知的原因，中国运营商的垄断地位导致手机话费奇高，垃圾短信无处不在。我建议使用WiFi或者GPRS包月登录互联网，通过Opera或其他浏览器使用。

以下列举三个我认为不错的同步方式。

1、对于普通手机，使用官方的m.twitter.com，优势是轻量、便捷。如果没有Opera、Safari等现代浏览器，也能使用。截图：

2、对于iPhone、iPod Touch，推荐使用Hahlo来进行更新、同步。直接用iPod/iPhone上的Safari打开hahlo.com即可。截图：

3、如果你是重度的Twitter用户，也可以考虑安装一个Terrific（Apple Store链接）或者Twinkle客户端在iPod或者iPhone上。由于是免费的，个人建议直接通过iTunes获取（确认您安装了iTunes）。

友情提示一下：如果没有注册iTunes账号，最好先获取一个Redeem code，用Facebook成为这个Page的fans，然后再点这个链接就可以了。具体的大家可以搜索一下。我十分建议大家使用Terrific，而Twinkle太商业化了，远不如当时的那个以Jailbreak+Installer开发的单独安装版。

32条评论, 立即发言 | 本文关键词: API, SNS, twitter, 第三方客户端

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1637

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

首先，Flash作为客户端技术，想要完全保证它的安全，是非常困难的。如果把破解视为“攻”，反破解视为“防”，我认为在“攻”这一块，各种技术还是非常强的。

首当其冲的是ActionScript Viewer（ASV）软件。目前ASV6已经可以直接查看AS2、AS3的源码，并能根据SWF生成一个JSFL（JavaScript Flash，Flash IDE提供的一种JavaScript API技术，我曾在本科三年级时做过一系列研究）命令序列和资源库。利用一段JSFL命令，我们可以操纵IDE，而利用ASV6生成的JSFL，我们甚至可以还原一个FLA文件出来！

很多时候，对一个Flash游戏进行作弊，仅需要弄清楚游戏分数的提交目的地址和参数名称即可。比如你玩一款赛车游戏，用40.56秒跑完全程，这时候可能Flash会提交一个t=40.56到某目标地址，比如mygame.com/myscore.php，这些参数，直接用Firebug就能看到，根本不需要生成FLA源文件。即便在提交表单时，做一些简单的混淆，仍然容易被ASV识破具体算法。

的确，我们把保护自己的手段过度地依赖于技术了，这会让我们失去很多机会。

其实，Flash游戏防作弊、抄袭，非技术渠道更加重要，这里简单说一下两点：

1. 游戏内容本身要承载品牌
   抄袭者对于一个品牌性很强的应用，很难继续“添油加醋”。例如某娱乐公司做了一款游戏，其中许多游戏人物都来自它旗下的签约艺人，你就很难抹掉这种品牌特征，然而对于那些毫无品牌概念嵌入的Flash，几乎不做修改就能直接用，例如我上面提到的“伸懒腰的时钟”；
2. 积分排名系统要灵活多变
   积分系统的智能化一定要做好，排名可以按照社会关系和时间范围来分。例如，我和好友的排名，24小时之内的排名。即便是这个Flash再容易破解，如果每天数据都更新一次，破坏者也很难有精力耗下去

希望这两点能为您新的Flash游戏开发带来帮助，不过，倒是有一个问题，当所有的游戏都是来自于抄袭渠道时，还有人会自己开发Flash么？

我这么说的原因是，国内某著名SNS社区已经开始官方集体出动破解Flash并以外部应用程序之名义植入到自己的平台下……似乎还有一个规模化的技术破解团队和人肉“助破解”社区：所有不幸遇难（当然，你也可以认为是荣幸被看上）的SWF都被在_root植入了一个LoadVars对象负责提交分数到自己的服务器；而人肉破解社区则负责查看哪些Flash会有外链（有过于强的保护意识），凡是发现外链到作者网站的Flash都会被扣上“弹出广告”的罪名并可“举报”给伟大光荣的“管理员”同学……

当然，这次我也没有必要愤怒了，只是遗憾这些Flash游戏的作者在发布他们的游戏之前并没有看到本文。而我觉得作为一个转型为Blogger的Flash Developer，多少是有点幸运的：）

25条评论, 立即发言 | 本文关键词: API, SNS, 破解

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1494

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

《关于51.com开放平台服务上线及运营管理的有关说明》

一、总体目标
51.com的开放平台是51.com公司遵循开放、公平竞争原则建立的一个支持第三方公司或者个人进行应用开发和运行的平台。51开放平台是大家共享的一个平台，大家的应用在一个环境里运行，我们面对的也是一样的用户，所以，我们有必要遵循一些共同的标准，以保证整个平台的稳定、安全、快速地运行，为我们共同的客户提供最好的服务。

二、应用上线流程
1、上线申请
由应用开发者提交正式的申请文件，包括产品说明书，技术设计概要，运营计划。产品方面主要说明产品的需求概要，用户使用指南，以后上线后的改进计划，技术方面主要说明针对安全和压力的考虑，还有投入运营方面主要说明，产品上线以后，是否有安排监控人员，客服人员，并且提交相关人员的联系方式。产品上提供收费服务的应用，还要提交产品版权所有人的详细信息，个人需要提交身份证件，真实照片，地址电话，企业则需要提交营业执照副本，以及公司负责人的身份证件，真实照片，地址电话。（表格下载）
（应用开发者所提交的所有信息，51.com公司负有保密义务，保证不用于除审核外的其他任何用途。）
2、产品技术初审
51.com公司收到开发者提交的正式文件后，在5个工作日内完成初审工作，对于通过初审的应用，我们会提出改进意见，对于不通过审核的应用，注明理由。51.com由产品和技术主管级以上人员组成多个审核小组，负责确认哪些应用的产品设计和技术设计符合51.com开放平台的上线要求。
同时建议开发者提供电信、网通双网顺畅访问，确保所有用户都能正常使用。
涉及收费的项目应该还进行财务审核。避免出现财务问题。
3、测试审核
另外上线前制定一套第三方的测试规定。 第三方上线经过测试部测试达到这个测试标准才能上(这个标准当然不会和我们自己产品一样的严格，但是也必须符合最基本的功能测试，甚至包括部分内容的审核工作)。
4、正式上线审核
开发人员根据初审意见，进行改进后，再次提交正式上线申请。这个阶段，会主要审核应用的安全性，技术架构的合理性，以及产品设计是否符合政府的有关规定。上线审核由51.com公司产品、技术总监以上人员负责。正式上线审核时间也在5个工作日以内。
产品技术初审

三、 运营监控及管理
51.com公司会24小时对开放平台上的应用进行监控，一旦发现有非法内容，侵害用户利益，技术上存在明显的安全漏洞，系统运营长期不稳定（缓慢或者不能访问半小时以上）。我们会暂停应用的运行，要求开发者进行相关改进。
建立类似的信用评估系统。按照具体的规定标准(标准要本着公平公开)对每个提供商进行评估(比如一次30分钟的事故扣分，稳定运营一周加分，及时通知问题及时反馈加分等)。对于评估度不好的公司，个人。以后的应用审核需要更加严格或者直接不予受理。评估好的可以有一些优先权利(比如优先展示，以后应用审核简化等)。总之要让每个开发者都有类似的意识：损失用户体验就是损失自己的利益。保证用户体验就是保护自己的利益。让所有人把51的用户当成自己的用户一样保护。增加他们的服务意识。

以上流程和规定，马上开始试运行。我们会根据大家意见不断改进，其目标只有一个，就是更好地为应用开发者，为51.com平台上的所有用户提供更好的服务。不便之处，还请大家谅解。

6条评论, 立即发言 | 本文关键词: 51, 51.com, API, SNS

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1488

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

<err_response xsi:schemaLocation="http://api.hainei.com/1.0/ http://api.hainei.com/1.0/hainei.xsd" list="false">
<err_code>101</err_code>
<err_msg>Invalid API key</err_msg>
<request_args/>
</err_response>

我仔细地研究了一下才发现已经发布了（海内长期只有单调的几个应用，导致我都遗忘那个“编辑应用”的按钮了……），目前有两个应用，吃豆豆和圈猫：

http://www.hainei.com/apps?a=browse

吃豆豆这个应用是由Relazy用JavaScript开发的，圈猫则是直接引用一个著名的Flash游戏。

一些截图在这里：

4条评论, 立即发言 | 本文关键词: API, SNS, 海内

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1447

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

我在2年前、2006年的时候发布了一个小玩意，叫做“软骨钟”。基于Flash8的好友陈郎（网名CG）的一款时钟代码，进行了修改而发布。代码的出处，包括CG的链接，我清楚地表明在了原文中。

结果前几天，新浪负责奥运项目的一位好友告诉我，现在有一款叫做“会伸懒腰的钟”与我的这个Flash特别类似，并且成为了MySpace的头号应用。我无从去考证这玩意是不是成了头号应用，但据我观察，这个Flash的确颇受欢迎。

当然，如果也是基于CG开发的时钟，那么我没什么话可说，顶多让CG去观察观察。可是据我观察，在这款“会伸懒腰的钟”的SWF文件后面加上我制定的参数，居然也能进行背景变色，这无疑是直接破解并抄袭了我的ActionScript代码！（CG的原版代码仅仅是一个时钟的变形算法和渲染器）

检测地址（你们自己改最后的ff0000可以调处各种颜色）：

http://b0.ac-images.cdnmyspace.cn/cnimages01/2/l_df3ad89aaf19b12286cd47f47c0a232e.swf?c=0xff0000

截图：

开发者是国内某Widget提供公司，目前这款插件也进入了校内网。好在我认识这个网站的CEO，目前已经联系了对方的CEO，无论如何，希望能给我一个明确答复。至少要在插件本体注明我的链接。

无论这位CEO和我私交如何，维护个人作品的权益，是每一个劳动者有义务去争取的。希望每一位原创程序设计师和开发者也能尊重自己的知识产权，维系行业的公平和公正。

32条评论, 立即发言 | 本文关键词: API, Myspace, SNS, 会伸懒腰的钟, 伸懒腰, 抄袭, 时钟

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1390

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

看看截图吧：

导航：

侧边栏：

内容栏

说实话，我真的不知道这张图上把咱们第三方App搁哪了……

6条评论, 立即发言 | 本文关键词: API, Facebook, SNS, xiaonei.com, 校内

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1385

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

使用这款应用，可以方便地处理主流网站的profile图片，看这张截图：

选择响应的区域

点一下这个按钮：

就可以下载或者将图片发送到自己的邮箱了：）

我认为这款应用还有很大的提高空间，例如大头贴制作，在线录制等等，如果用户基数大，利用SNS的API，甚至可以考虑推出收费服务。

6条评论, 立即发言 | 本文关键词: API, mypictr, profile, SNS, web2.0

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1378

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

Youtube视频增加了“Annotatiions”（标注）之后，大幅提高了视频内部的转换率。这与Youtube自身相关视频的推荐完全不同。今天看到一则Featured Video被浏览55,000多次，而它最后的一个通过Annotation加注的视频也被浏览了37,000多次，这种极高的转换率(70%)，是平台将决定权交给用户的一个有趣缩影。相信Youtube的算法再好，也很难推荐一个转换率高达70%的视频。

校内的开放平台，协议交给法务部门而不经过技术部门的重审，我认为这是一次内部的决策失误。从意识形态来讲，IT行业的法务部门多的是在解决传统软件产业的版权纠纷、利益争取等问题。我并不对“法务部门”的合理性和贡献有意见，然而，针对API这种开放意识形态的创作型工作，全盘交给法务部门，难免会引发冲突。

事实证明，冲突的确存在，开发者对校内法务部门的条款非常的不满意（在校内内部开发者论坛陆续有抗议声音），而校内本身作为新媒体新社区的一种新力量，也招来大量媒体的质疑。更是有竞争对手（其他SNS平台）大力网络开发者阵营。

我作为校内的老用户，当然希望校内能够尽快完善条款（校内的管理层以及技术团队已经在争取，感谢校内负责人朝军、技术负责人黄晶和API项目负责人忠杰），拿出做平台的心态来与大家分享成果；同时，作为实名类SNS应用的坚决支持者，当然也希望平台之间能有竞争以便让开发者不至于太“弱势”。

回顾Windows成功的历程，我觉得从3.x到95的过渡，就是一次成功的平台式成型：

在Windows3.1时代，几乎没有什么第三方应用，蹩脚的DOS引导和复杂的安装让你时刻感觉到，Windows只不过是一款抛在DOS平台上的“图形软件”而已。安装Windows的过程，也是安装软件的过程一般（当时是8张软盘），我只是想尝试它的新颖和别致。Windows3.x系列给我留下的印象，甚至也只有那个“鼠标入门教程”最深刻。

然而，进入95之后，我们完全不难发现，Windows之所以是Windows，是因为它让你丝毫察觉不到“自己”的存在：无论是使用微软开发的Office系类，还是第三方开发的应用、游戏。除了开机和关机的时候你要注意到“Windows”之外，你根本察觉不到它的存在。之后Windows 98、XP、Vista的陆续推出，伴随着在Windows上大量的应用软件爆发出来（当然，也有大量公司与个人受益了），很难有人能离开Windows进行“电脑操作”：Windows作为“平台”，当之无愧。

从决策权上看，安装什么软件，禁止什么软件，Windows将权利充分交给用户：微软的Outlook不好，我可以用Foxmail或者ThunderBird；微软的Office不好，我可以不用；甚至许多热心开发者连代替Windows资源管理器的应用都开发出来了。

即便如此，微软还是迎来了Linux的竞争以及对“抵制IE捆绑”的打击。但我个人虽然也非常不喜欢IE（我是IE5-IE7的用户），也非常尊重Linux在特殊领域（例如我每天都要用到的Web服务器）的杰出贡献，但这仍然无法掩盖Windows作为“平台”的成功。

如果有一天，人们在校内（或者某一款SNS）上不仅仅是打个招呼、交个朋友，而能够方便地约情人、打游戏并互相竞争、分享照片、分享视频、组织活动、查找各类信息（等各类社会化活动），那么，用户也许从开始上网到登出都不会离开这个平台了。

8条评论, 立即发言 | 本文关键词: API, SNS, Windows, xiaonei.com, 校内

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1377

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

除了我这款游戏之外，更是有更多千奇百怪的校内应用程序纷纷出炉，新鲜事里面颇有当年Facebook爆发的风采。相信校内自己也能从API的开放感受到“开发者”的力量所在：

遗憾的是，校内的开发文档，还非常的不健全，我这个应用几乎是参照着Facebook的文档在做。期待他们能逐渐把Wiki完善起来，让更多的开发者（因各种原因无法阅读Facebook Wiki）来参与到这“百家争鸣”之中。

我相信，API的开放和第三方的疯狂涌入，一定会给校内的团队带来极大的冲击。无论是好的、还是坏的，无论是善意的玩笑，还是恶意的攻击，陈一舟和他的校内，也许会有许多“意想不到”的收获。

开放、透明、分享（不仅仅是信息，更是利益），这才能推动一款互联网产品的继续健康发展，希望校内能再接再厉。

PS：7月8日凌晨1：00了，用户数已经有一百多人了，平台的确是个好东东：

PS2：最新消息，海内也推出了一个游戏：

看校内什么时候出“买卖好友”吧……

10条评论, 立即发言 | 本文关键词: API, SNS, xiaonei.com, 校内

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1369

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

不妨就来看看目前两家微妙的关系：

Netvibes是当之无愧的最优秀的（综合）个性化主页，同时基于Tabs和Widgets的理念，进行社会化分享和延伸；另一方面，Facebook目前是绝对权威的（综合）社会化门户，而近日Facebook新Profile页面则开始与Netvibes提供的功能非常的接近。

Netvibes的UWA虽然设计的非常巧妙而且上手极快（我也基于它做过应用），然而，Ginger项目以及早先推出的UWA（Universal Widget API）就我观察，在放开之后并没有引起轰炸效；Facebook的API虽然上手复杂（我搞FBML就摸索了好久），但基于强大的SNS网络和有效的分发（Distribution，我个人觉得也可以理解为“病毒传播”），的确带起了一条产业链（或者说Ecosystem，生态环境，生态圈）。

有趣的是，Ecosystem这个概念最早又是Netvibes提出的。

这场博弈，我认为，我个人喜爱的Netvibes并不占上风。

简单把原因总结如下：

1. Netvibes强调API和Widget这个概念，却忽视了SNS的本质，那就是人与人的关系。在Netvibes一边，SNS体系推动太晚，因而UWA并不能给开发者真正带来优势（巨大的流量收入和分发抵达）。而且，Netvibes本身的使用门槛就是一个工具类型的门槛，这导致许多人不能理解他们为什么一定要使用Netvibes；
2. Facebook刚开始并看不出有平台的特征，更让普通用户感觉不到API的存在。因为Facebook首先是社区，其次才是工具。社区的门槛，比工具类网站要更低，因为，与人交谈并不难，但使用一个工具，创建模块、编辑主题，这些是普通人难以做到的；
3. 对平台来说，开发者的决策，显然是非常有力度的一个“判决”。微软之所以能获得如此的成功，是因为有大量的开发者开发基于Windows的应用。
4. 工具可以被模仿、被复制，而且基于一个强大的社会化平台，分发成本极低；而社会化关系则很难撼动，哪怕再多人责骂腾讯（的某些不妥之举），你也很难保证从此之后就再也不用QQ了。这也是为什么百度贴吧、空间、IM紧跟其后的原因；

欢迎批评、指正。

5条评论, 立即发言 | 本文关键词: API, Facebook, netvibes, SNS

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1368

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

1. 如何上手
   首先，我建议使用PHP的开发方式。没错，既然你是一个对服务器端编程一点都不懂的前端工程师，为什么要去花时间折腾文档和Demo较少的其他服务器端语言呢。我并不是PHP的“粉丝”，但范例最多、配置最快并且有Facebook官方支持的，似乎只有PHP了。
   然后去官方看这些内容，非常详细（但不太容易找到）：
   《App所具备的一些要素》
   《手把手叫你开发一个App》
2. Callback到底是什么
   Callback URL和ActionScript中的Call Back函数还是不太一样的。
   CallBack URL说白了，就是你自己的服务器的一个URL，比如，我的awflasher.com/someurl，在这个URL上，输出一些“相关内容”给Facebook的Canvas来进行渲染。关于这一套流程，强烈建议看这篇（翻到下面），也是在Wiki里面藏的特别深很难找到的：这么重要的问题，居然藏在一个“Random Questions”里面。也可以看这张“图”

                           +------------------+
                           |   BROWSER        |
                           |                  |
                           |   +-------------+|
                           |   |Application  ||
                           |   |Canvas       ||
                           |   |             ||
                           |   |             ||
                           |   +-------------+|
                           |                  |
                           +---+----------+---+
                               |          ^
             1) Browser makes  |          | 5) Facebook Renders FBML to
                      request  v          |    HTML
                         +-----+----------+-----+
                         | FACEBOOK SERVER      |
                 +-------+                      |
                 |       |                      |
                 |       |                      |
                 |       |                      +<-------------+
                 |       |                      |              |
                 |       |                      |              |
                 |       |                      |              |
                 |       |                      |              |
                 |       |                      |      4) App Server
        2) FB Server Calls                      |       Returns FBML
          out to App Server---------+-----------+              |
                 |                  ^                          |
                 |                  | 3) App calls FB API      |
                 |                  v                          |
                 |        +---------+------------+             |
                 |        | YOUR APP SERVER      |             |
                 |        |                      |             |
                 |        |                      |             |
                 |        |                      |             |
                 +------->+    2.5) App server   +-------------+
                          |       composes API   |
                          |       calls          |
                          |                      |
                          |    3.5) App server   |
                          |       generates FBML |
                          |       from API results
                          +----------------------+

3. 官方提供的PHP client包存在的一些细节问题

   我到现在也不知道官方提供了多少个PHP版本。似乎在Developer的App页面（简写为：apps.fb.com/dev和dev.fb.com）和Developers的Wiki页面有许多不同的范例。这其中有很多不规范的地方，例如：

   把<?php echo getFriends();?>写为<?=getFriends()=?>之类的“简写”。这对于刚配置好的PHP环境实在是让人无从调试（因为你想不到官方提供的代码可能有问题）

4. PHP开发中常遇到的问题

   前端开发者的思路似乎更“粗糙”一些，我就有这个毛病。我在开发Facebook App的时候经常犯的错误就是把HTML和PHP内容混到一起了，例如：

   <?php echo ‘<p>test’.$somevar.’</p>’;

   <br>

   ?>

   这样的写法乍一看没问题，但实际上中间的<br>是PHP根本看不懂的。在大多数配置下，这个错误根本看不到（不像Flash那样会有一个Compliler帮你报错），遇到这种情况，如果是少量HTML，就给它echo出来；否则，就将PHP标签结束再输出，例如：

   <?php echo ‘<p>test’.$somevar.’</p>’;

   ?><br><?php … ?>

5. FBML的设置

   最关键的setFBML是把FBML显示到用户个人主页的函数。在使用这个函数的时候，一定要确认用户已经“同意改变profile box”，这是安装App的几条协议中的一条。如果你自己调试期间不希望被别人看到而当时没选中，那么很可能是导致你多次无法看到相关内容出现的主要原因。

此文仅是抛砖引玉之文，因为也许我遇到的错误其他人又很容易地解决了，欢迎补充，我会保留链接。

7条评论, 立即发言 | 本文关键词: API, Facebook, Web前端工程师, 前端开发

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1367

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

之前的SNS 28日开发者聚会，我已经汇集了一些资料，在这里可以看到。昨晚更新了校内的资料，现在，大家都可以上手一试了：）

另外，今天校内在个人页面，也就是Facebook“对应”的profile页面作了一些调整，我们大致已经可以看到未来校内API应用的界面样子了，profile box被剥离到第二个tab，据David介绍，如此剥离，将使相关App损失50%的流量。

点击应用标签，进入一个新界面：

Facebook也Launch了新界面，又见Tab，但Facebook的Tab与校内的Tab无论是层级还是逻辑都是有很大的区别的。我个人认为，这种Tab的出现，对Netvibes构成了一定威胁（以后将提到）

校内的开放平台距离Facebook的F8还有相当一段距离，但我认为，已经做的非常不错了（他们的API团队似乎没有投入太多兵力）。让我们拭目以待7月8日的发布会吧，如果不出意外，我会去“找他们麻烦”，嘿嘿：）

不过，Facebook在中国内部命运多舛，这也许是马克同学不曾遇想到的吧，他在哈佛（抱歉，之前记成Stanford了）学不到的知识，还有很多很多呢：）

6条评论, 立即发言 | 本文关键词: API, Facebook, SNS, xiaonei.com, 校内

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1358

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

目前北京SNS API Developers Meetup活动在和谐和友好的气氛中告一段落。

我作为最初这个“小活动”的发起人，真的是感到非常的抱歉：到场的朋友非常多（超出了我的预料），天气也很热，尤其是坐在后面的朋友都比较辛苦。许多提前报名的朋友最后却没有座位，实在是令我感到很对不起。

也请大家通融没有报名而来到现场的朋友，毕竟活动没有sponsor（本活动全部由我个人发起，David给了我很大的帮助和指导，其他运营商、公司的人并没有参加赞助），而且API本身也是一个开放的理念，我不打算对任何人做任何限制，因此也没有任何权力去“拒绝、要求”任何人。SNS API的开放，意味着无论是平台运营商还是开发人员，每个人都是朋友！最终最低消费也“轻松完成”，这也要感谢大家对我的信任和支持！

以下是活动相关资源：

【活动资源】

相关资源由于网络问题可能无法第一时间上传（有一些Presentation的size在10M以上，所以……）

Presentation的演讲资源：

• 《SNS应用的小生意经》
  来自42friend的David（PDF）
• 《MySpace Developer Platform简介与实例》 （PPT）
  来自Myspace的Sam Wu
• 《51.com开发平台介绍和示例》、《51.com简介及用户数据分析》（非常宝贵的资料）（PPT）
  来自51的张长永
• 《Hello World @ xiaonei.com》 （PPT，正在联系中）
  来自校内的李福松
• 《OpenSocial 简介》 （Google Docs在线看！）
  来自Google的Jacky Wang
• 《zend framework 在 Web services 中的应用》（Sorry, only RAR available）
  来自PHP开发爱好者王承石

目前由Google的产品经理杨巍介绍OpenSocial……

【相册】

来自Google的杨巍；补充中……

【视频资源】

【通信录】

【博客、媒体报导】

稍后会陆续上传现场视频、演讲者的Presentation以及通信录。

大家有任何意见或者建议欢迎在这篇文章后面留言，URL: http://www.awflasher.com/blog/archives/1350

17条评论, 立即发言 | 本文关键词: API, SNS

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1350

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

【活动Logo】

【最新公告】

报名已经结束。对于希望过来却没有在第一时间报名的朋友，作为活动发起者，我向你们表示诚挚的歉意。因为考虑到活动的初衷是一个开放、平等的主题，这次参与还是以开发者的技术交流为主，并不寻求赞助。希望下一次能有大公司牵头来举办更有趣的活动。

对于未能列举在名单上的朋友：我已经与场地提供方联系，对方表示挤一挤没关系，因此，对于有非常强烈意愿来与大家交流的朋友，完全欢迎你们的到场。（如果您不介意没有座位的话）

聚会之后，所有到场者的名单我都会公布，通信录将会共享于docs.google.com（如联系方式不愿透露请提前联系）。如果您希望在这篇日志公布联系方式，请通知我一声（默认不公开联系方式）。

按照名单上签到的时间顺序入场，为了公平，以下两种类型可能没有座位：

1. 名单上未列出者；
2. 名单上列出，但迟到者。

解释一下：也就是，名单上列出者如果迟到，也可能没有座位。为此，非常抱歉，这边只有我一人安排，肯定有许多让大家麻烦的地方，希望多多理解。

【活动时间】

2008年6月28日，周六。15：00 – 20：00（请尽量不要迟到）

【活动地点】

对外经贸大学西门对面“上岛咖啡”（原定地点雕刻时光空间不够、没有投影屏）

（大图、清晰的Mapbar地图）

如果不明确，只要到了对外经贸大学西门，就很容易找到了（随便找个美女搭讪问路吧^_^）

【活动费用】

总共消费额度3000，如果现在报名者全部到现场，人均只需60左右即可。

这个我着重解释一下：这个价格当然不是我定的（我也不认为这是一个reasonable的价格），而是活动地点提供方，上岛咖啡厅的店长一再坚持最低消费要3000（最后交涉，同意将时间稍作延长）。注意，早些时候联系的提供方“SIT Coffee”无法提供投影条件和足够的作为。所以价格有所变动，如果您对此有不同意见，可以不参与本次活动，我对这个不合理的价格也深表歉意。当然，希望您请发信告知我。

总之，上岛的这一价格虽然很贵，但是场地毕竟不错，而且有投影空间，再加上周六下午到晚上是对方的“黄金时段”。因此，希望大家多多理解。个人建议大家在这里吃晚餐。（现在绝大多数参与者都表示了理解和支持，因此决定不更改地点了，如果不能来，最好提前说一声）

【设备支持】

• 现场提供免费Wifi接入、投影仪（感谢Myspace的Sam提供）
• Twitter直播（不确定）

【主题提议】（排名不分先后）

• 第一部分、嘉宾主题演讲

【Presentation Title】MySpace Developer Platform简介与实例
【Speaker】吴洪声 张启智 / MySpace China
【演讲长度预期】30m

【Presentation Title】51.com开发平台介绍和示例
【Speaker】张长永 / 51.com (五一网)
【演讲长度预期】20m

【Presentation Title】Open Social 简介
【Speaker】Jacky Wang / Google
【演讲长度预期】30m / 基于Open Social开发的一些简介和实例。

【Presentation Title】zend framework 在 Web services 中的应用
【Speaker】王承石 / Web Developer 开发者
【演讲长度预期】20m

【Presentation Title】Hello，校内开放平台
【Speaker】李福松 / 校内网
【演讲长度预期】30m / 简单演示如何基于校内API开发SNS应用

【Presentation Title】SNS应用的小生意经
【Speaker】李大维 / 42friends
【演讲长度预期】10m

感谢以上嘉宾为我们带来精彩的演示，所有演讲的PPT和视频将在活动结束后于本文地址提供下载（我们争取也能上传到Youtube等视频网站以方便大家在线观看）。

• 第二部分、平台问答
  现场参与者以及网友可通过IM（Twitter？）对平台供应商发问。
• 第三部分、分组自由讨论

分组自由讨论，根据诸位参与者发给我的提议，我列几个关注度比较多的话题如下：

1. 开发者对API有什么要求？
2. 各平台的代码编写细节（从入门级的“Hello World”到复杂的交互应用）
3. SNS平台提供商从丰富多彩的应用中如何获益，会有何种限制
4. 开发者、开发团队从SNS的社会化资源中如何利用丰富多彩的应用程序获益
5. 产品质量和用户体验参差不齐，平台提供商如何权衡
6. 用户最关心的是什么？SNS平台提供商和App开发者如何与用户沟通

【参与者名单】（6月27日更新）

注：由于收到的GMail邮件中有一些并没有发到指定地址，而未能被我的Filter顺利“捕捉”，因此如果您发了邮件却不在这份名单上，请尽快与我联系，直接在下面留言即可，谢谢。

【后续报导】

我会在博客进行输出RSS的报导和Review，各位speaker也会提供相应的资源；

国内一家知名的网络媒体可能会进行视频报导（目前DV已经联系好了，应该没有问题）

其后本日志历史内容，不输出RSS。

17条评论, 立即发言 | 本文关键词: 51, API, Facebook, google, Myspace, open-social, SNS, xiaonei.com, 校内

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1334

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

（http://survey.xiaonei.com/）

这个调查类似我博客右侧的投票功能（这里可以看到我之前发布的一些投票结果）。只不过，每一个用户都可以创建自己的“调查问卷”，如图所示：

然后，可以选择希望来参与这个投票的好友（和Facebook基本一致）：

最后，就可以发布投票了。

统计方面用Flash实现，可以依照年龄和性别得出一些统计结果，还是非常有趣的。

我看了一下，发现这个功能未来可能可以将投票公开化，进行“海量投票”。也就是说，我出的题目可以共享给整个校内网的用户进行投票。这样的话，对于一些我关注的话题，就可以得到很好的结果了。比如我很关心，到底有多少人知道RSS，他们是否使用RSS阅读器；到底有多少人在使用Firefox，是否真的有很多人认为Firefox等同于流氓软件，等等。

现在校内的API还是针对一些第三方的组织开放，而并没有公开接口，希望公开接口的那一天早日到来。

最后：发一张图，啥也不说了，嘿嘿：

17条评论, 立即发言 | 本文关键词: API, xiaonei.com, 校内

©aw's blog 姿态永恒 1984-2008 | 链接地址 - http://www.awflasher.com/blog/archives/1311

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

http://labs.digg.com/arc/ – 如果这都不算艺术，那……

这款叫做“ARC”的Flash应用是基于AS3，利用digg.com的API开发而得的。其衍变而生的界面、由数据而得到的曲线和填充区域再一次将技术与艺术的结合推向了一个新的高潮！

如果你喜欢，建议下载一个客户端版（Windows平台|苹果平台），然后开着全屏好好欣赏全世界的人们共同digg所带来的视觉艺术。

我认为，国内的Web2.0圈子与国外的最大差距，莫过于提供优雅的API和基于API之上做二次开发的个体、团队了。

2条评论, 立即发言 | 本文关键词: API, digg

©aw's blog 姿态永恒 1984-2007 | 链接地址 - http://www.awflasher.com/blog/archives/990

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

在这样一个大趋势下，API的意义越来越明显，我个人也开始用ActionScript3玩弄一些简单的API。很巧合今天在这里看到一篇美文《设计”性感”API的十条准则》，结合我自己的理解，重现出来（并非简单翻译），转载请保留出处：http://www.awflasher.com/blog/archives/941

1. API是接口 – API本身并不实现任何功能，它只是一个接口定义（想想ActionScript中的Interface）。这是API最重要、最明显的特点，也是API的目的所在。无论何种情况，请将这一点牢记于心
2. API不是代码库 – 一个好的API一定有明确的功能目的。它绝不是一堆函数（function）原型（prototype）的集合
3. 公开的API能不改变则不改变 – 当这些API对外发布之后，要想改变是非常痛苦的（你必须通知所有的使用者），因此在设计之前，一定要三思，例如方法名、参数类型，返回类型，等等。
4. API是神秘的 – API应该把所有对外不必知道的信息全部封装起来。例如使用者向我提问：”你是一个天才么？”，我应该回答”我是一个天才”，但不要回答”我为什么是一个天才”。
5. 关注你的API的使用者 – API真正投入应用才是健康的。要关注那些应用你的API开发各种有趣应用的代码。
6. 不要迷信文档 – 好的API是一眼就能看明白的，不要指望那些渴望利用你的API做些小应用的开发者会耐心地花几个小时在你的文档上
7. 文档、存档很重要 – 虽然刚才提到不能依赖与文档，但是作为API本身的开发者，一定要重视，因为你自己必须搞清楚内部的机理，这样便于日后的维护和扩展
8. 要讲诚信 – 不要为了取悦一部分人而让另一部分人不知情，这是非常可怕的。我们越来越生活在一个开发、自由、透明的时代。有任何问题，就坦诚说出来。
9. 没必要来什么”惊喜” – 优秀的API一定是”可预见的”，也就是说，开发者在阅读你的API说明时，就已经知道哪些应用可以做，哪些应用不可以做了，不要让开发者开发到一半突然发现有一个新的应用。那不是对开发者的肯定，反而是对这套API的讽刺。
10. 要快乐 – API的工作是需要付出责任心并且逻辑严谨的。但是千万不要丧失一个最重要的原则：”快乐”！要快乐，要认识到你这套API能给你带来的快乐和成就感！

3条评论, 立即发言 | 本文关键词: API

©aw's blog 姿态永恒 1984-2007 | 链接地址 - http://www.awflasher.com/blog/archives/941

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo

经常会在技术论坛里面看到类似这样的帖子：“什么是 SDK？”，“请高手讲一下 SDK 是什么东东？”……

其实很简单，SDK 就是 Software Development Kit 的缩写，中文意思就是“软件开发工具包”。这是一个覆盖面相当广泛的名词，可以这么说：辅助开发某一类软件的相关文档、范例和工具的集合都可以叫做 “SDK”。具体到我们这个系列教程，我们后面只讨论广义 SDK 的一个子集——即开发 Windows 平台下的应用程序所使用的 SDK。

呵呵，其实上面只是说了一个 SDK 大概的概念而已，理解什么是 SDK 真有这么容易吗？恐怕没这么简单！为了解释什么是 SDK 我们不得不引入 API、动态链接库、导入库等等概念。^_^，不要怕，也就是几个新的名词而已，我也是到了大学快结束的时候才体会到其实学习新知识就是在学习新名词、新概念和新术语。

首先要接触的是“API”，也就是 Application Programming Interface，其实就是操作系统留给应用程序的一个调用接口，应用程序通过调用操作系统的 API 而使操作系统去执行应用程序的命令（动作）。其实早在 DOS 时代就有 API 的概念，只不过那个时候的 API 是以中断调用的形式（INT 21h）提供的，在 DOS 下跑的应用程序都直接或间接的通过中断调用来使用操作系统功能，比如将 AH 置为 30h 后调用 INT 21h 就可以得到 DOS 操作系统的版本号。而在 Windows 中，系统 API 是以函数调用的方式提供的。同样是取得操作系统的版本号，在 Windows 中你所要做的就是调用 GetVersionEx() 函数。可以这么说，DOS API 是“Thinking in 汇编语言”的，而 Windows API 则是“Thinking in 高级语言”的。DOS API 是系统程序的一部分，他们与系统一同被载入内存并且可以通过中断矢量表找到他们的入口，那么 Windows API 呢？要说明白这个问题就不得不引入我们下面要介绍得这个概念——DLL。

DLL（又是一个缩写，感觉 IT 这个行业里三字头缩写特别多），即 Dynamic Link Library（动态链接库）。我们经常会看到一些 .dll 格式的文件，这些文件就是动态链接库文件，其实也是一种可执行文件格式。跟 .exe 文件不同的是，.dll 文件不能直接执行，他们通常由 .exe 在执行时装入，内含有一些资源以及可执行代码等。其实 Windows 的三大模块就是以 DLL 的形式提供的（Kernel32.dll，User32.dll，GDI32.dll），里面就含有了 API 函数的执行代码。为了使用 DLL 中的 API 函数，我们必须要有 API 函数的声明（.H）和其导入库（.LIB），函数的原型声明不难理解，那么导入库又是做什么用的呢？我们暂时先这样理解：导入库是为了在 DLL 中找到 API 的入口点而使用的。

所以，为了使用 API 函数，我们就要有跟 API 所对应的 .H 和 .LIB 文件，而 SDK 正是提供了一整套开发 Windows 应用程序所需的相关文件、范例和工具的“工具包”。到此为止，我们才真正的解释清楚了 SDK 的含义。

由于 SDK 包含了使用 API 的必需资料，所以人们也常把仅使用 API 来编写 Windows 应用程序的开发方式叫做“SDK 编程”。而 API 和 SDK 是开发 Windows 应用程序所必需的东西，所以其它编程框架和类库都是建立在它们之上的，比如 VCL 和 MFC，虽然他们比起“SDK 编程”来有着更高的抽象度，但这丝毫不妨碍它们在需要的时候随时直接调用 API 函数。

暂无评论, 立即发言 | 本文关键词: API, SDK, 教程, 编程

©aw's blog 姿态永恒 1984-2006 | 链接地址 - http://www.awflasher.com/blog/archives/394

@awguo （新浪微博） | @awguo （腾讯微博） | Twitter: @awguo