JAN

30

Sun

Author:EMINARCISSUS

被拍砖4次,接着砸!

先说正文。4天前用PYTHON写完了JSMC抓取链接的脚本,东西比较简单。不过自己对于PYTHON的开发库并不熟悉,核心部分用了2个小时就搞定了,不过有关用户界面却花费了将近4天时间,都迟迟拿不下来。很大一部分原因就是因为KDE和QT的关系让我不曾考虑用PYQT去尝试开发,转而走上了WXWIDGET的路子。不过WXWIDGET开发起来调试问题又有不少,对于我这种PYTHON初心者来说就比较麻烦了。于是最后还是用CMD把剩余的部分完成了(WIN下的GBK默认编码害死人,2套系统,一套JIS,一套GBK,LINUX下是UTF-8,太坑人了)。

不过这个真的只是个过渡产品。本来想补充图形的,受村汗哥启发,最后重新把脚本用GM写了出来,正当自己准备测试并编译写成FF插件的时候,功夫网发威了,TORA或许有可能塔布嗯莫西卡西呆,从此就成为了一个传说,成为了一个记忆,就算脚本没用了调试过程中的经验还值得的,嘛嘛,让他去吧,自己也就先把这东西放出来好了。

http://misuzi.org/files/fetchurl.user.js

简单说明下使用环境:FF3.6+GM 0.91。

简单总结下脚本开发中的遇到的种种问题。

1:GM_XMLHTTPREQUEST的延迟WRAPING。这个问题记得曾经在DIVEINTOGREASEMONKEY中看到过,不过这次在开发还是碰到了。因为安全性的问题,非沙箱对象在调用该方法的时候会报错,需要在调用前加上setTimeout(function(){GM_xmlhttprequest{....}},0)来调用,或者加上GM_WAIT来调用.

2:沙箱内外的JQUERY版本,GM内重新REQUIRE回来的JQUERY不会和页面中的JQUERY冲突,所以不用担心版本冲突.

3:有关跨域请求的问题。在写脚本前想到了3种实现方案。不过最后发现只有2种有效。其一:IFRAME或者AJAX的GETSCRIPT,其二:YQL语言,其三:GM或者FF插件。

其中2,3方案是有效的,不过其实YQL语言相当于介入一个SERVER作为代理来返回跨域请求数据,而实际操作中,自己并不希望有三方PROXY介入,因为这样的做法会损害到安全性,所以最后采取了GM的解决方案。除此之外,FF插件,也可以通过PYCOMET等工具来利用自己已经写好的PYTHON的脚本作为中介,不过鉴于太麻烦,也没有最终采用。

4:GM脚本的调试问题。之前花过大量的时间来研究如何最高效地开发GM脚本。因为GM是完全沙箱操作,所以也不能像开发外挂JS那样,边通过控制台操作,边书写脚本。不过也有这种方案,就是采用独立命名空间后,将命名空间赋值到unsafeWindow下的某命名空间,从而可以通过CONSOLE在加载GM脚本后进行一部分调试工作,对于排错来说可以带来极大的便利。最后吐槽一声,FF下的FIREBUG的CONSOLE,总会莫名其妙的加载不能。除此之外,GM的错误信息,多数情况是导出到FF的JS控制台中的,而非FIREBUG的控制台中。所以在加载过程中,即使手动指定了GM_log=unsaeWindow.cocnsole.log的前提下,倘若脚本中有语法错误的话,脚本未能成功加载,错误信息还是会输出到JS控制台中,盯着FIREBUG的控制台只会浪费自己更多的时间。

嘛,菜鸟一只,能想到的目前也只就这么多了,其他的以后想到再说了。

下文则是对TORA作为一个目标盈利的公司的抱怨了。不喜的可以跳过了。

事情到现在这个地步,也就出来唠叨两句,自己也希望TORA能够渡过这次危机,毕竟能够做到今天这个地步,也是十分不容易的,不过在此事件上,还是有一些自己的怨言的,无意的已经可以离开不看下文了。

TORA现在被墙了,自己也做出了一些东西,但是这个都不是关键,关键是TORA官方对于被墙后的反应却是非常的微妙。

先说下实际情况:应该是28号下午6点后开始,TORA的IP被墙,之后大概3个小时后,TORA.TO成为关键字,正式确定是墙的问题。但是从6点到凌晨0点,TORA就已经开始有动作了。虽然动作详情并不清楚,不过可以肯定的是,TORA在DNS上做了一些文章,重定向TORA.TO的链接到了TORA日志上,然后在今天凌晨关闭了MC的服务器。之后貌似又转移了IP,不过如果真是TORA.TO成为关键字的话,想必换IP也不是最终的解决方案。后续并没有什么新的变化,奇怪的是今天晚8点后开始,OPENDNS记载的TORA的IP已经转移到了某未开启HTTP服务的IP上,或许这几天就要大规模迁徙了?

情况就是这样。或许不是什么大不了的事,有可能几天后就会解决掉,也有可能从此JS不再。不过这里想说的是JS官方的态度。无论是什么原因,作为一个收费提供服务的“企业”,在出现这么大的危机的前提下,是否应该有一些官方的声音?最起码应该说清楚到底发生了什么,会怎么解决,哪怕是不打算解决,也应该有一些对公的声明吧?!即使能够不留痕迹地解决掉这些问题,事后想强调是自己的服务器维护,也不应该在出现这种问题的关键时候缩掉吧?!这就是一个想做长远载点的企业的对公态度吗?

说出来感觉都是废话,JS免费服务提供了这么些年,或许我们就应该去感激,不该发出这么些怨言,不过这个怨言并不是对JS说的,而是对国内企业说的,出了问题企业要做的是面对,这么一声不响默默地在幕后解决这些问题虽然值得鼓励,不过对于以盈利为目标的企业来说,这种对用户的隐瞒情报的行为,最后或许真的就会出卖掉自己。

周围有一些JS的核心用户,在转移MC后已经纷纷离开了JS。原因很简单,JS在出卖自己曾经的诺言。早期的JS也有DONATE,来换取不限速的下载,而后升级到NEXT,取消了DONATE的权限,换来了不少骂声,却引来了新的永久空间的概念,而后转移MC,则对于之前相信这所谓永久空间的人来说,则是莫大的背叛。即使MC再试图去解释,MC会永久存储系统中的数据,实际情况,却也很难认同其可行性,毕竟永存存储和永久可下并不是一个概念。

说了这么一篇。我并不想说JS骗了大伙。JS也需要盈利,也需要改变。不过改变的过程是否应该这么激进,是否应该丢弃曾经用户的承诺,这个则仁者见仁,多数健壮的跨国企业,在转型过程中,成功解决新老用户的矛盾的实例也比比皆是。不过这对于陶瓷国企业来讲,这次改变作为一个参照的MINIATURE,所谓的用户是上帝,仅仅存在于实体商品经济市场的运营过程中。在这样一个以免费和服务为主题的网络这个平台上,一切的承诺无异于一张废纸。

试问这样发展下去,本当に大丈夫か?

smiley