前一段时间一直在研究ROR，就想开发一些小应用，简单记一下这段心路历程：

1. 想做一个部门内分享资讯的webapp，用来分享图片、网页、文字，基本是想做个简单的twitter类应用。
2. 鉴于我本人对Ruby On Rails很感兴趣，twitter就是用它开发的，而且好像可以快速开发，就决定用它实现，版本是1.2.6。
3. 不动手不知道，ROR表面的地方真是很简单，可以快速做出一个原型，但是越深入越复杂，想全面点实现出来需要注意的地方还真不少。
4. ROR的学习资料还算挺多的，就是高质量的中文内容太少，我其实不是做技术的，只能用部分业余时间写代码，连学带练的拖拖拉拉写了1个多月才像点样子。
5. 就像《用户体验的要素》里提到的”永远不能发布的项目”一样，因为前期缺少足够的用户分析和功能需求，过程中还过分修改细节，不断加入特性，导致该项目一直不能正常使用。
6. 看到xdite用ROR快速开发Facebook App，使用CSS库做界面布局，心又乱了，想拿进行中的项目改。殊不知，需要做的事情很多，要装rfacebook的gem和plugin，要到Facebook申请key，又要熟悉Facebook专用的标记语言FBML，很多设置需要在虚拟主机上调试，Dreamhost又诸多不便，最后只能作罢。
7. 注意到Joyent提供免费的Facebook App空间，就去申请，若干天后通过审核。进入管理界面，傻眼了，超级复杂（如果有人觉得Dreamhost的panel已经很复杂就不用去试了），虚拟服务器配置好后，开始调试FBML。
8. 没有将现有进行中的小项目转换成Facebook App，只是简单测试了下，做了一个显示所有好友的列表，发现Facebook提供的接口很有限，同时也推翻了我的一个设想”开发通用应用，分别用Facebook、Google等开放平台优化，做成跨平台的应用”，因为有很多功能（如邀请、好友搜索/选择等）只能通过FBML实现，除非其他平台也有对等的实现，否则这个应用只能是FB专用，不是我需要的通用了。
9. 还是回到我想做的webapp上，考虑到时效性和同事的用户习惯，最后决定还是使用QQ群解决，之后公司又推广wiki协作方式，这个东东就不了了之了。
10. 我最后把这个webapp发布在Dreamhost上了，没人知道，也不打算公开，也许下次再想做什么的时候可以先看看这个，作为警示自己的工具。

是我太随意，总想用复杂的方式解决本来很简单的事情，好像是挑战自己的极限其实最多算没事找事吧。

其实还没有结束，这件事情的后传是这样子地：

• 想在公司的Wiki里发网摘，觉得每条链接又要拷贝又要手写代码太麻烦，就用ROR做了个抓Google Reader阅读共享feed并转换成wiki格式的小应用。
• 结果Google用的是Atom，只能引入了Feedtools，结果页面编码出了问题，绕了个弯子才知道是Feedtools本身的问题，手动打补丁后，终于解决。
• 其实这个功能完全可以用PHP的lilina或MagpieRSS解决，我又多此一举了~
• Ruby On Rails 2.0.2出来了，颠覆了1.2系的很多用法，很多特性更加吸引我，又想以后都把小工具用2.0去写，先从这个功能开始，有点无法自拔……

Technorati : FBML, facebook, ror, ruby on rails, twitter, webapp

您可能也喜欢：
昨日收集 – 用户群多大才算大	开放平台还是开放应用，这是个问题	Prism，WebRunner及WebApp专用浏览器	研究笔记：Twitter的简单分享体系	昨日收集 – 谁来完成Web 2.0的未竟事业
无觅

我在上篇Blog里曾表述过”单纯应用类和社区类的网站，现在有且仅有两个选择，要不自己做大做平台，要不就做成适合开放平台的纯应用“的观点（除上述类型网站外其实还包括资讯类的），大多数网站现在都面临同样的问题： 开放平台还是开放应用？

随着最近Facebook Platform、Google OpenSocial、搜狐博客开放平台等的出现并逐渐发展，Slide、Rockyou!等应用提供商的崛起，网站运营人员不得不去面对上述的问题。

后Web2.0的思想，使资讯类、应用类网站在逐渐增强社区氛围，社区类网站在不断增强互动资讯部分，趋势是互相融合的，成为趋向交互的网站。

这也造成网站系统的重复劳动过多，几乎每个网站都有自己单独定制开发的用户系统 、好友系统、交友网络等等，使得网站操作复杂，用户永远需要去适应体验上的差异。

不管开放平台还是开放应用，都可以解决很多问题，同时精简自己的应用结构，根据网站定位更好的发挥自己的特长。

当然，开放平台并不那么好做的：

• 首先平台网站需要有颗包容的心，允许别人的应用借你的平台发展。
• 需要提供功能全面的接口，让应用可以很容易结合到平台上。
• 需要有良好的用户基础，用户数量级够大且用户素质有一定保证，要不没有应用会来。
• 像Facebook、Google这样本身就很强大的平台并不在多，还没有跳出来的也屈指可数了。
• 用户数据的所有权成了最大的死穴，平台如果不能照顾应用的利益，早晚被应用放弃。
• 受应用欢迎的平台标准也会逐渐提高。
• ……（想到再补充）

开放应用稍微容易实现一点，但也有好处有坏处：

• 最大的优点，可以跨平台吸收用户，让不同平台的用户存在于同一个应用下。
• 不影响现有网站运行，可以为特定平台开发定制应用。
• 因为要适应各平台接口特点，用户体验可能与源网站不统一，或各平台间体验存在差异。
• 应用的模块化标准有待整合，现存标准缺乏通用性。
• 怎么将平台用户转化为应用用户将成为网站运营的主要研究课题。
• ……（想到再补充）

话说回来，不管开放什么，多平台鼎立的形势已经出现，在应用数量相当的情况下，主要看用户对平台的喜好，而应用已经不能再左右用户的选择了。

对个人用户而言，在熟悉的平台下使用感兴趣的、新的应用，将成为平台网站的主要体验，哪个平台相关方面做得好就可以脱颖而出。

还有一个可能发展的方向，用户基于现有个人网站（Blog）自建平台，维系用户的（社交）关系，将开放应用自行整合。用现有工具已经可简单实现，例如OpenPNE等开源软件、老冒的OPSN项目（我最感兴趣~）等等。

最后，借用一句互联网的名言收尾：未来是如此的不可知，互联网的发展更是如此，也许事与愿违，就当是2008年第一个月的某个白天的胡思乱想吧~

最最后，洋洋洒洒的写了一大片，一篇东西居然写了几个小时，中间经过很多琐碎的事情，可能会觉得驴唇不对马嘴，我还是感谢您能坚持看到本文的最后~^_^~

Technorati : Application, Facebook, api, google, opensocial, opsn, 开放平台, 用户体验, 网站应用

您可能也喜欢：
近期流水账：我和ROR的简单接触	Prism，WebRunner及WebApp专用浏览器	门户网站的RSS应用猜想	昨日收集 – 用多种方式备份Blog	昨日收集 – 网站推荐机制中的艺术、科学与商务问题
无觅