2007年5月28日星期一

学术活动日历

学校的学术活动日历的确给了我们很大方便,很早以前就想有这么一个应用程序,可以把每天校园里发生的活动提前发布出来,现在有了内容发布功能和相关邮件列表,的确很方便。
2003年的时候,最早的活动日历发布在内部学生网站中,团委为此还组织了单独的学生组织来维护。那时候活动很少,大家也很少用;
2004年以后可以通过在校内办公系统订阅学术活动的邮件列表,虽然只能发到服务质量很一般的校内邮箱;
2004-2005年有了"学术活动发布与订制系统",具有了基本内容发布的功能,这时候我在系里开发的综合信息服务系统里的学生工作模块有了个小小的"学术活动"功能,为此在那一大堆平台技术细节中开发出这么一个基本上没有人用的dd真是划不来;
2006年4月有了google calendar.经过这么长时间的进化,有了Atom支持和比较全面的用户访问支持。每次把邮件列表里面的邮件内容搬到另一个表单,手工复制粘贴,只是利用大脑分析下语义然后做些字段映射,这些活动只需要一个有语义支持的Atom服务就搞定的。
2007年,不知道什么时候Atom feed这样的dd可以在学校普及,然后大家可以在Atom feed和REST serivices的世界中根据自己的喜好发明各种各样的视图,或者直接扔给google services

有时间的时候可以自己做一个这样的Semantic Atom Service

2007年5月20日星期日

“我看不懂”

这是最近在线下听到我blog观众最多的回答。
也许计算机和Internet的内容让大家看了觉得没劲,同事和领导看了肯定会有些不同的观点,幸好这些观点都可以讨论和交流,但是听到"我看不懂",的确是最大的失败。就好比我们做出来的产品拿到市场里交给用户,收到更多反馈的声音是"我不会用","你们的产品可以做什么?","这个东西是什么意思?"……

昨天晚上在看 Basecamp,想看看37signals.com坚信的用户需求到底是否可以满足我的需要,一想起即将毕业的兄弟姐妹们需要一个网络家园,索性就用这个项目管理的服务来试试好了:有日历、文件仓库、todolist、项目和协作功能等基本功能,在桌面都可以找到相应的应用程序,只要Basecamp提供REST Service,为我的用户们开发更为定制化的服务就成为可能,甚至将newsmth.net xiaonei.com、msn messenger和TencentQQ之类的东东mashup到一起,再映射到googlemapsecondlife之类新的虚拟世界,使得我们这些互联网的种子更加茁壮的成长,而不用去管什么分布式计算或者信息系统。但是最大的问题在于,有多少用户理解这些工作的价值呢?至少我觉得还需要一段时间才能说服我的亲人和朋友们接受。

我们可以把中国移动提供的cmwap代理通过蓝牙和Thinkpad连接到一起,但是有多少用户接受通过修改浏览器的user-agent绕过代理服务器的过滤并且只能接受无状态的HTTP通信?上次和移动的客服较劲45分钟,除了让他知道移动提供的网络服务毫无质量可言和一张30元的充智卡之外毫无结果。

我是不是又犯用复杂方法解决简单问题的老毛病了?

2007年5月9日星期三

来自Gmail

me:"大家为什么用live.com的spaces写博客啊?"
saveMyColor:"要不是MSN(Messenger),谁用spaces啊,那么慢……"

第一次用Gmail写blog, 不需要登陆blogger.com ,仿佛 Compose Mail 变成了blogger.com的 创建 标签,唯一不足的便是文本编辑器的工具栏少了几个有趣的按钮,尤其是HTML编辑功能没有了(记得去年听 Bob Sutor的报告时,他自己写blog的时候最喜欢直接编辑HTML),少了很多乐趣,但是多了自动保存功能,这个还是不错滴。

有时候将我们平时使用的这些Web应用程序拿出来晒晒,有不少有趣的地方:hotmail和gmail的邮件有了日历集成,Spaces和blogger.com变成了个人内容发布的阵地,gmail 甚至还集成了GTalk, 至于邮件本身(这篇文章的确应该读一下),tag或者label这样的小功能的确方便,再配合邮件过滤器实现自动分类,有时候真的觉察到SaaS为软件带来了无穷的创新空间,这背后,也许是还未被细致化的RIA 编程模型吧……

有一点非常重要,google.com的这些个应用程序都提供Atom服务,包括日历、博客、邮件、相册……其背后的GData API也许应该拿下一次的Jolt数据库大奖,从而标志着Atom时代的到来,那时候我们就可以说:互联网世界也是由"Atom"组成的。

那么,接下来这些Feed门户哪一个将成为明星呢? 有时候观察着netvibes.com逐渐壮大完善,不仅钦佩起这些富有创造性和艺术性的法国人,而且在最初阶段毫不保留的贡献了其全部脚本,后来也只是去掉了缩进和注释,有时候觉得奇怪:难道这些人不懂得用混淆器可以大幅度减少脚本网络传输的时间成本么?难道不知道自己的竞争对手都用各式各样的混淆技术么?可能自己的软件生产方式不够先进吧……

写完日程记录,看看时间――10:30PM,我那些日程紧的朋友们在咖啡店讨论完工作,还得赶回研究院照看独自运行的程序;也许努力的同事们还在加班;一同为毕业奋斗的同仁们正在思考论文;校园里一路上遇到的都是晚自习归来的学生……现在渐入梦境,是最幸福的吧:〉

2007年5月5日星期六

折叠凳和棍棒

第一次听说Rails还是在去年年初,霏昀同学告诉我,他准备用Rails完成毕设课题,本来导师要求用java的。
“为什么?”
“开发起来特别快。”

求职的时候"Rails"赫然在目,感兴趣的web开发职位都有这么个名词,不禁感慨世界变化之迅速:两年前还在用差不多10年前的ASP技术,到后来用10岁的Java,如今Ruby也有10多岁高龄了。(有没有Z开头且超过10岁技术?)

经理给我了一项任务,不带偏见地学习Rails. 后来我告诉他Rails很简单,但是Ruby不是那么容易。比如Rails里面支持Ajax只是用了Helper和rjs作脚本模板,对REST的支持还只是url routing+xml resource等等。待到今天看来,这些简单的地方不在于用较少的时间完成了一定需求的功能,更重要的在于,为什么Rails这样做?为什么Java不这样做?

有一天同事问我:
“去哪里找Web services provider?”
"Amazon的AWS啊,或者自己写一个。"
后来想了想,用Axis写一个sample需要多久?用Eclipse+Geronimo为一个Web应用暴露Web service Endpoint需要多久?用Rails呢?计时过后发现,原来用最后这个开发以mysql为后台的Web service provider,只需要差不多5分钟而已……而这个时间和在Eclipse里面重启几次Geronimo服务器的时间差不多。

看到Rails中scaffold的实现,不禁惊呼:“原来是这样!我怎么没想到。。。”有时候这种“固执己见”的开发框架的确有可爱之处:最重要的问题是,Rails告诉了我们,如何去理解“简单”这件事。
这些神奇的软件背后是一个叫做37signals的公司,37只是一个质数而已(用质数命名的网站),但我们从中获取了无尽的想象力:“这么小的一个团队是怎么完成这么多项目的?五个产品、一本书、Rails(译者注:ruby的web框架),还有一个颇受欢迎的博客。我们比你们拥有多得多的钞票、人力、硬件资源和技术,但是我们好像什么事也完不成?秘密是什么?”

有时侯不得不承认,勺子比手提钻要有用的多;再想想香港暴力电影,折叠凳要比砍刀棍棒强多了。