OAuth报了一个协议的漏洞,存在一种session fixation的攻击方法。
之前Twitter莫名其妙中断OAuth服务的原因。
新闻链接见这里,不过比较这篇比较歌颂。。。囧。。。
抓紧时间撇几句。这个东西还蛮值得一提的,当然更重要的不是Java on GAE,而应该是JVM on GAE。
于是反而得归功到M$当年搞了.net clr,这逼着sun这边应对出了JRuby、Groovy等等。
现在jvm一上gae,很容易就可以联想出GRails on gae(进行中),Rails on gae(这个相对难一些,因为gem等等)。总而言之,对于诸如我这种非专业pythoner,生活一下幸福多了。
当然,对于像我一样的半专业javascripter,其实还应该记得伟大的Rinho~ 所以Helma(以及同质物) on gae应该没准已经可行了吧~ 等我熬完论文一定要试一下,囧~
——–闲着没事备忘下,完全是因为在windows上装couchdb失败后无聊所致——–
其实3年多之前还挺瞧不起js的,结果这几年混下来,糊里糊涂js就成了自己第一称手的语言。
用得顺了也就喜欢起来,而且很多时候js的表达力也挺强的。所以虽然RoR也一直在手边没放下,但是也挺留意用js写server端的项目。毕竟短期来看无论flash还是sl都不能让browser是逃不出js的掌握,如果有特别合适的js写server的东东,我就可以把RoR扔了,完成自己的语言大一统,XD——当然到现在也没看到特合适的,囧。
归正传,题目所谓Pure-js Web App就是只用js这一种编程语言通吃Server和Client端。目前这种项目数量倒是挺多的,不过粗劣分一下类的话,大面上也就两类种东西:一个是维持现在Client-Server-DB这种3-Tiers的体系结构,只是把Server端的编程语言从java、php等等换成js;另一类相对好玩一点,这类基本上抹掉了Server这层,体系结构变成了Client-DB,而全部所谓的业务逻辑代码全都移动到了browser的html页面中。
先说第一类,这类我最早关注的一个是helma——这个是最纯粹的用js写server。我还比较喜欢这个项目:部署简单,内置了jetty,默认情况解压直接跑(其他很多项目需要部署到其他的http或者servlet server中);内建了一个基于xml的对象数据库,不用一开始就配mysql(也可以用mysql);server和app管理和调试工具;文档全;良好的MVC支持。不过helma也有这类的server-side js的通病,他的定位是用js替换php、java、ruby等等server-side语言,这结果是虽然听上去使用这类项目后client和server端代码都是用js写,但是其实这两个地方写出来的js完全不一样。
相对来说,虽然同是server-side js,Aptana旗下的jaxer看上去漂亮得多。jaxer给html中的script标签加了一个runat的属性(M$好像搞过类似的东西?),通过将runat属性设置为server(提供一组用于访问db、调用远程service的api)、both或者client(default),可以决定js运行的位置。而通过一个runat=”server-proxy”的特殊标记,client可以很容易调用server的功能。这样理想下开发人员只需要写包含js的html再部署到jaxer server上就行——咋一看用同一语言同一编程方式挺好的整合了server和client端。不过仔细一想,我还是挺怀疑的。虽然代码文件的区分基本没有了,但是物理上server和client的界限还是存在的。结果就是用helma这类东西,开发人员必须在项目中来回切换server代码和client代码。而用jaxer,开发人员必须在脑子里来回切换server代码和client代码,囧……而且jaxer文档里的例子大多是inline js,真正开发谁这么写呀……一旦外联js,因为这些js文件是区分server和client的,所以很直觉就分到不同的目录,然后……鉴于jaxer并不内建支持mvc,于是我猜会很像js版本的php。补一句,我并没有真正用过jaxer,可能有点信口开河,有兴趣的最好还是去自己看看,如果有jaxer大规模开发经验的,欢迎留言~
第一类我看得多一些就是这两个,另外还有很多在servlet server上跑rinho以及在apache、lighttd上跑spidermonkey的项目。但是总得来说大同小异——我见过比较另类的是把extjs跑到asp服务器上增强jscript能力的,据说很好用,而且鉴于国内虚拟空间的国情,这做法还真挺实惠的。
直接用js作为server side脚本的问题是因为体系结构不变,server和client的区分还在,结果client js和server js完全是不同编程方式。如果只是想用js写server也没什么问题,不过总会觉得有点不优雅。
于是第二类的方案本质上是修改了我们传统中的3 Tiers体系结构。这类方案里,client端直连db。server端基本不再运行任何业务逻辑代码,变成了单纯host html和js的静态服务器。
这类解决方案,我现在知道的就是OpenResty、Couchdb和dojo的Perservere,应该还有其他的。
OpenResty是yahoo一帮人搞的,现在还不开放注册,账号可以发信索要。这个项目提供一组REST和json访问PostgreSQL的接口。用了这个东西,开发的模式变成了,开发人员在前台写html+js客户端,直接操作后台数据库的内容。所有的业务逻辑代码都统一在前端的js代码中。openresty这个作者的blog据说就是用这种模式搭建的。
Couchdb和Perservere从思路上和OpenResty没有区别。前者是很热的erlang项目。文档数据库,加之erlang这个东西,传说水平伸缩性无敌。这个项目一直很贴js,view直接用js写,访问走rest和json,包括他自己的管理界面也是直接用html+js做的。这里还有一个用js操作couchdb的例子(windows装couchdb失败的我,没有试……)。后者是dojo的一个子项目,也是对关系数据库的一个包装,好处是与dojo紧密集成。
当然用这种提供REST和json接口的Storage,前台并不一定是js+html,任何通用语言都可以。但是看上去这些项目都很往js贴(比如json而不是xml),毕竟browser上js独大,而现在在desktop上又有了air——air的跨平台还是很诱人。
如果扯大词的话,这种Client-DB直连的模式还可以扯到“云”中。比如OpenResty的服务也可以看成云存储的一种。于是后端用云做存储,前端在浏览器中做计算,大家还真是省事了,XD。(写到这,忽然想起来su27同学写过这么一个东西,gae的js interface。恩,好吧,多么的云计算呀)
不过目前看上去这种模式也有几个问题,一是代码安全,如果全是html+js,那就真是什么秘密都没有了。虽然可以做混淆,但不是万全之策;二是安全性,比如连接远程Storage的用户名和密码总不能放到js中吧?三是跨域,如果用第三方的Storage,这个问题也挺不好解决。综合2,3的话,至少目前来看想完全只用静态服务器也不太可能,还得搭一个Proxy中转。
最后,wiki上还有一个关于Server-side Javascript很完整的列表,可以参考。
虎头蛇尾的结束~
续前,于是准备自己DIY一把,需求也简单:能列出所有已打开的ppt;能放能停;通过滑动来前后翻页
从来不指望自己的C(Objective-C)有什么成就,所以昨天一开始的目标就是Jiggy之类的用js写iPhone App的东西。不过最后转了一圈发现,以我的要求好像不怎么需要一个native app。所以最后祭出半年多没怎么用过的RoR,一天时间搞定。
中间有两个地方可以提一下的。一是ruby的为win32ole库,让我悟到了VBA的用处。不过office vba的文档在哪里?知道支会我一声,完全没找到。。。二是mobile safari里的dom节点,有几个专用于手势的事件,touchstart、gesturestart等等,如果发现mousedown之类的不好用,考虑用这个。
ok,废话完毕。
源代码在这里(RoR Application,需要RoR环境) :http://code.google.com/p/ppt-iphone-controller/
另外玩性心起,上午录了两段视频(一手相机,一手iphone,手酸。。。-________-|||)
ps. 总得来说,通过这件事我学到了,有个好老婆才是最重要的。
正好是豆瓣API发布一年的时间。之前有打算写一点总结性的东西,可最近很不在写字的状态里——有好几篇东西都是开了头就进行不下去了,所以这里也就只能流于简短。
过去
写这种东西,往往都脱不了回顾过去展望未来的路子。回顾来说,过去一年里,还是很happy的看到豆瓣API从一开始比较简陋的书影音只读接口,到现在基本上覆盖豆瓣主要功能的很成型的东西。
这里必须要感谢大头鱼、davies和subdragon在Server和Client两端工作,没有这些努力,所有东西都只能是纸面上的空中楼阁。
还要感谢所有关注豆瓣API的豆友们。特别是其中那些使用API的开发人员,Meaglith、wu yuntao、Livid、刀马、EmilMatthew、MJiA、Hooopo、tsing、14、狮兄、bc1998,排名不分先后。我相信我一定忘了谁的名字,不过一定原谅我,因为这绝对是我越来越老,记忆力越来越差的缘故,我对所有人的感谢是一致的,因为没有你们的应用,API的工作没有意义。
接着说一点遗憾的事,虽然从06年刚接触豆瓣的热情,到07,再到08一路经过,我自己对于API的预期和动力都已经消磨了很多,但即使在这种情况下API流行程度还是低于了我的预期。这一部分是源于我们工作的不成熟,比如API入门门槛还是有点高,虽然我们也进行了一些工作试图改变,但总得来看降低API的上手难度仍然是有很大空间来做的事。另外不得不说在这块神奇的土地上,大家的生存压力如此之大,比之海外无偿的第三方开发工作需要更多的付出。理解这些,我也就更加感谢现在这些开发人员。
未来
即使在寒冷的冬天,未来仍是让人向往的。豆瓣API的第二年,依照自己的想法,希望豆瓣API会在以下这些方向上继续前进。
首先是开放更多可以通过API使用功能,包括相册、豆列、留言这些功能,而online、artist这些还在演化中的工作,随着他们的完善,也会早日将他们纳入API的范畴。总之为开发人员提供能力更强,更能激发创意,更有施展空间的接口。
其次是API的推广,这个可做的事情很多。而我目前最想做的是提供更好的应用展示平台。如今的豆瓣API还是有一些很“产品级”的应用的,然而因为现在缺少展示平台 ,应用的传播走的还是小组推荐这些很豆瓣很草根的方式。并不是说这样不好,不过既然大家在这么大的生存压力下辛辛苦苦花了很多时间来做应用,那么专门的页面总是应该有的吧~~
最后,我个人的希望是可以把API更好地适用于插件小组。API小组和插件小组基本集中了意愿为豆瓣做第三方开发的全部草根力量。然而插件小组从我建组,到NP同学接手过去,一直在fx gm的路线奋勇前进,大部份工作和API全不相交。这有点脱离我当初希望做API来帮助插件开发的本意,接下来的一年里我希望这两个小组可以有更多的交集。
结语
说是流于简短,写起来真是很多废话。其实文字絮絮叨叨是我的特质,难免让大家厌烦了。
总之最后还是要说很感谢所有人对于豆瓣API的努力和关注,真的很感谢。
题外话是2009年,我要好好读博,天天向上,努力在2011年毕业,囧~~
研究flex有一段时间了,一直想写一点比较实在的东西。然而真到动手的时候往往又被困住了。
我现在真的懒了,过了原来学js时不用任何framework裸奔干活还不忘了写得很oo的年纪了(其实那时候我在做js方面的intern)。每次在脑子预构要做的时候,发现自己不得不做这么多“dirty work”,重新发明那么多轮子,一下就把我给吓住了(如果有钱发什么也吓不倒我)。
结果是,我什么大东西也没编,倒是一直幻想一个好用的RIA框架应该是什么样子(也就不限于flex了,如果gear、sliverlight、java fx方面上能用类似的东西我会考虑立马转向)。所以就随便写一点想法在这里,没准这种东西已经有了也可能的说,如果这样的话,麻烦在回复里推荐给我吧
—懒懒的分割线—-
这里先撇清我说的RIA是带着Server端的(不然怎么叫Internet App),所以题目中说的是Client Framework(不过很多东西还是要server配合才能搞)。Server端提供Service(RESTful、SOAP、AMF或者什么都行)。Server和Client之间传递xml、json或者什么编码的value object。
接着看客户端,MVC是必须的。不过这部分已经从Framework角度讲已经没问题了,无论是PureMVC还是Cairngorm都已经够用了。所以我就每一个部分的说
Model部分:
1. 统一的model class。指的是server端和client端model的统一,现在一般得搞两份,实在没必要。理想状况下用同一份model,server或者client专用的属性或者方法用继承或者annotation说明。
2. 考虑server端代码不可见的情况。至少可以通过server返回的vo生成model的桩(soap没有这方面的问题,但现在restful居多)。
3. 对本地数据库管理的封装。air和gear都支持sqlite,在本地缓存数据的好处是显而易见的。但是现在开发人员需要事无巨细地处理这个功能。理想情况下,首次创建数据库,client升级时数据库的升级,等等这些常用必要操作,框架应该封装好。开发人员提供必要的sql script即可。
4. ORMapping。这个不废话了。
5. 离线支持。Client数据同步到Server,参考greader离线阅读的方式。这个能力应该被框架支持,开发人员需要说明那些操作可以离线处理,如何在本地缓存操作结果,同步时机即可。
6. Server更新的处理。用于处理在本地缓存数据之后,server端数据更新的情况。需要server和client统一的方案。最理想情况下是应该有一种开放、通用的协议被广泛支持。大概思路是client提供时间戳和资源类型,server返回时间戳之后更新的资源。
Controller部分:
一句话就是更强的Comet。现在的观点Comet是server push data。考虑Rich Client,可以换一种观点,变成server调用client的功能,原来push的data只是参数(所以放到controller部分)。其中现在Comet谈到传输协议一层,但是之上还应该又一层互操作协议以及对应实现。这里:
1. 首先是让server和client很好地相互理解。至少也是一个类似xmlrpc的东西,从发起调用到调用成功,中间打包、拆包、client上的method dispatch之类全部透明。
2. 其次是对常用功能的封装。连接,断开等等。也要透明。
3. 最后考虑server和client不是同一方开发的情况。不同于client invoke server的调用,这里的反向调用是从层级结构上讲是下层调用上层。IoC原则,server方提出接口描述,client实现。接口描述语言肯定是互操作协议的一部分,但是扮演的角色和传统稍有不同。
View部分:
这里我能谈的不多了。只随便说一两句flex。
1. 需要一个更好的中文默认skin。现在的默认skin完全不适用于中文。
2. 更容易地借鉴(抄袭)设计。好吧,我到底不是一个设计人员。如果不是网上有那么多“免费”的css,我估计连勉强看得过去的html页面都写不出来。flex这方面门槛太高了。联合上面那点。业余开发人员很受打击。
—-又是分割线——
信手写了一大篇,半是存底备份,怀疑中间有一些点还是很有意思可以做一做玩一玩的。不过原来胖客户的时候以及现在在一些c/s体系结构的应用领域里(例如网游、数据库),估计类似的东西或多或少都解决了一些。
所以很多东西也许只要有对应的走http的轻量级版本就好了。
花了一天多的时间写了一个可能是“符合规范”的豆瓣秀 OpenSocial Gadget。然后零零碎碎合起来花了大概两天的时间试着把它提交到各个号称支持OpenSocial的容器里,均不成功,目睹怪现象若干。。。陈列于此:
1. iGoogle:iGoogle提供了一个可用于调试OpenSocial的Sandbox,这个Sandbox是Google在各次宣传OpenSocial活动中展示的工具。不过当本猫在iGoogle Sandbox中调试好gadget,然后提交到iGoogle的App Directory中安装之后发现,iGoogle非Sandbox的普通用户使用的版本不支持OpenSocial,囧。。。(今天参加Google Devfest的时候又试了一下,结论上Sandbox也不支持OpenSocial了,而今天Google自己的演示也全是Orkut了)
2.Orkut:Google的当家SNS。另一个Google在活动中展示的Sandbox。首先Orkut中文版里提交gadget的文件总是显示“抱歉,XXX错误”。。。切换到Orkut英文版,暂时可以用了。不过gadget的标题里的中文字符,会被莫名其妙的Url Encode。。。不管怎么说,勉强可以用吧,调试完毕,欣欣然然submit。显示“审核”,等了整整一天(时差,时差问题),一封拒信打回来,说只接收够“production”的gadget。。。老大们好歹给点线索哪里不够吧。。。自己猜了半天,东改改西改改。然后再去提交,提示“这个url不能提交,因为已经提交过了”。。。囧,暂时放弃中。。。(p.s. Orkut的opensocial实现里有bug,一些时候会出现取不到UserPrefs的问题,不过和之下的比这不算什么。。。)
3. Myspace中国:好大一个SNS,好多用户,然后基本上认为开发人员都是超人。。。首先花了几分钟没在页面上找到进入developer页面的链接,结果只能google “myspace developer”(不愧和google是合作关系,帮他增加了2个pv)。。。进入页面创建一个gadget,提示我输入一个email地址,输了自己的email,提示“已经被用了”。。。我靠,仔细看提示,要是输入不能和任何注册用户和提交Gadget重复的唯一标示gadget的email地址。。。What the hell is that… 帮助“合作伙伴”增加gmail注册数?通过给gmail加"."的方式通过。。。下一步上传gadget图标,提示"16×16",我上传了一个64X64的,提示“尺寸不对”。。。ok,开ps,我是前端、后端、技术、美工全能猫。。。最后终于可以开始弄代码了,把在orkut下测试过的代码粘过去,运行。想设置自己的豆瓣用户名,找不到设置的地方,囧。。。仔细找了半天,未果,上“合作伙伴”搜,发现原来Myspace的opensocial根本不支持Google gadget那一堆xml标签——有一个大哥说得很直白,“MySpace has a different development pattern”。。。
4. Hi5:另一个好大的SNS,然后被盾了。。。搜了,偷偷发现,原来sandbox的链接还可以用(呀,是不是又犯法了)。不过上去一试,毫无疑问的也不支持gadget的标签。。。
5. YiQi:填完表单,点提交按钮。我点呀点,我点呀点,它就是没反应。。。看代码,按钮onclick了一个叫applyapp之类的函数,然后页面load的js里没有这个函数。。。
6. 51:原来5不仅可以1ml,还可以1OpenSocial。ok,创建,又开始填表。第一个就让我填“真实姓名”,而写明了不能改,以后要想分钱(51B,啊,不是,是51币)全靠这名字了。。。填了,接着,让我填身份证号,囧。。。嘿咻嘿咻终于快填完了,忽然出现一个“添加应用通知地址”,后面跟着一个链接“详细说明”。没禁住诱惑,偷偷一点,页面跳转,再后退,强制不缓存,什么都没了。。。T_T。。。最后,弄好之后,毫无疑问的,显然也不支持gadget规范里的标签。
好了,上面是一大堆没什么意义的吐槽,下面写一点点稍微有点小价值的建议。
1. 如果你去看opensocial的文档,里面的例子都会是gadget的例子。如果你真的打算做跨container的opensocial应用,就忘掉gadget裸用html+js吧,因为除了orkut之外,没发现哪个container支持gadget规范。
2. 如果你是基于兴趣爱好想写opensocial的应用,有点心理准备。各个container都假设你是领工资或者是为了发大财才用这个container。既然你是为了钱或者为了理想做这个,那么无论用户体验多差、系统多难用,你还是会坚持用下去。而如果你是凭爱好,嘿嘿,嘿嘿嘿嘿,嘿嘿嘿嘿嘿嘿。
在实验室就总是看一些估计这辈子都不一定用得上的东西。所以基本上3年没碰过JavaEE的我,被发去看JSR 299,然后做ppt……
看了1天多,重新梳理了一遍诸如JSF、EJB3.0、Seam的相关技术,最后算是把JSR 299理顺了。
然后,结论的个人感觉就是,我tm总觉得用Java Web开发这块,这么多年的发展就一直是在为Sun当年一开始搞出来的那个最不靠谱的J2EE体系结构埋单……比如说,当初花了几年的时间,最后用hibernate把那个快把人给弄死了的EJB2搞掉了。而现在其实就是在用Seam搞掉也是相当不靠谱(不得不说Lazy Initialization Exception真是一个奇迹)的Servlet Container和EJB Container的严格界限——merge掉JSF managed bean和EJB session bean(这么多bean,囧……)。
总的来说,最开始的J2EE就是一帮不编程的大佬们说“要有光”,所以最初版本的J2EE最大的用处是方便公司对开发部门进行职能划分。可惜大佬们话一出工业界就开始大量投资给“光”,于是即使发现“光”很靠谱也不能推倒重来,只能在现有基础上慢慢改。加上JCP这个官僚系统,基本上就是现在这个结果了。
ok,完全是自说自话,不能寄希望我用2天就搞清楚java近2-3年的发展。
"We knew we had to break her, burn her straight down, or she might come after us." – William Gibson, "Burning Chrome"
珂萝米,不知道为什么是这个名字,不过这个名字在Cyber空间里是个坏角色。
如果这不是另一个不合时宜的愚人节新闻,那么大概在24小时之内我们就可以下载到这个Google的新浏览器,Google Chrome。
目前比较完整的消息都来自这个漫画(题外话,很难适应美漫,一点代入感都没有地难读)。要点是这样子的:
仔细看一下,其实新东西不多,三个值得提一下的。
第一个是每tab每进程的架构。这方面其实不了解,所以不多说。总之漫画里google讲了一些多进程非常通用的好处。而具体效果,包括速度、内存的使用等等,还要用实物测试才知道。
第二个是v8,新的js引擎。基本上所有做前端的人的想法是一致的,标准的反派形象。因为不管新引擎有多好,很直观的一点是,调试兼容性的工作量的又增加了。对于开发人员来说,最邪恶的事莫过于此,因为这是让已经混乱的世界更加混乱。虽然在测试之前一切结论都是草率,不过肯定的是一旦v8的兼容性表现不好,而chrome又占据一定的市场份额的话,那么这对所有前端开发人员来说都是噩梦。(另外,值得注意的是fx3.1的js引擎也是新的——TraceMonkey)
第三,在比较high level的层面值得注意的是Gear的集成。所以chrome的目的大概并不是浏览器市场。对于浏览器市场,和mozilla有良好关系的google大可不必扮演一个坏人来搅局。但是如果是作为RIA的最后一块的拼图,chrome是合适的。至此,google有了浏览器+插件+web应用的完整RIA方案,结果是google得到了将web应用的功能和体验再进一步发展的可能性。这一点是ms、adobe、mozilla、yahoo和apple都比不了的。长久以来Google Gear一直是一个低估的角色,也不普及。然而从上次google developer day上的演示来看,gear还是具备相当能力。相对与flex和sliverlight来说,gear具有的无可比拟的优势,因为gear可以从google自己的web应用那里获得进化的方向。相对与flex和sliverlight,gear避免了高大全而是切实地在实用性上下功夫——这恰恰也是google的特长。所以google是不是可以借chrome的东风,彻底改变RIA的局面,这个也算值得大家仔细观看的事情吧。
最后,不得不说,历史真的总是惊人的相似。又一个新浏览器~如果有一天,我们发现chrome之外的浏览器无法获得google系列应用的全部功能和最好的用户体验,我们会不会又一次扔掉手头习惯的浏览器而转向chrome呢?所以呢,开篇的那句话就让ie、fx、opera、safari、flex、sliverlight等等的大家们共勉吧~
花了两天研究了一下Ajax based AIR实做,和想象的复杂度差不多,不过没怎么用到高级功能。顺手试了一下mootools和git,全都是复杂的东西。。。还是jquery大爱。。。
个人收藏浏览。纯粹学习加演示,没什么实用价值。
前提需要装Adobe Air Runtime才能用(到这里装:http://get.adobe.com/air/ )
程序下载在这里:http://douban-collection-explorer.googlecode.com/files/Douban%20Collection%20Explorer.air
https://github.com/sakinijino/douban-collection-explorer/raw/master/bin/Douban%20Collection%20Explorer.air
程序源码在这里:http://github.com/sakinijino/douban-collection-explorer/tree (Git好复杂……)。比较有复用价值的就是OAuth认证的部分,自以为我封装的还可以,两个页面加一组js类,有需要的可以直接拿去用。(经27同学提醒,想起来其实还没搞定sha1加密,所以最后用的Plaintext,囧。。。)
图和真相在这里: