Leegorous | 我的梦想飞行器

Archive for February 2010

Feb/10

11

指标透视眼镜

乱贴图:我在看着它,它也在看着我

乱贴图:我在看着它,它也在看着我

看到了一死党在公然展示他的能力,不谈那些高高的 IQ,EQ,MQ 指数,光那么一个公开透明的行为就已经让我十二分的佩服。

为了不被公然鄙视,我还是保持低调吧……

然而我在想,为什么人和人之间会有那么一些差距存在,而那些差距是怎么形成的,如何衡量,怎么拉大或者减少差距,可以通过主观能动性来调整差距等等。我突然想起了龙珠里面的撒亚人戴的可以显示对手各项指标的眼镜。

如果真有那么一种眼镜,可以实时的看到一个人的各种指标,如上学之前,先看看 IQ,EQ,体格等等指数,再决定到底该如何去开发一个人。事实上已经有一些机制,例如进大学前别的不考,就考英语,用于区分快班,慢班,我记得当年好像是因为慢的太多了,于是就不必分了……假如那样做的话是基于什么样的理由呢?资源的合理分配?但是这样同时又必然面临一个机会均等的问题。

再进一步,除了一些性能指标,如果还可以显示一些情感指数,例如,看见她对一件礼物的欢喜程度,对方对自己的依恋指数,对他人的倾情指数,那又会出现什么样的结果呢?现在的我们肯定对于这种想法有点意见,但是未来就说不定了。就现在来说,发起个约会,谈个恋爱,特别是对于新手,很可能都不晓得应该如何去应付的,所以朋友的亲身示范,大量的电视剧,电影,MTV,电台,同伴之间的亲密交谈就成为了他们学习的渠道。这儿插一句,特别想鸣谢一下《一些事一些情》。如果有一系列的情感指数作为参考,那么情况又会如何呢?不过我想,就算那么一种技术诞生成型了,也不会用于帮助恋爱新手处理那些必须自己亲身试一试才好的问题。它可能会用于处理更多需要考虑情感需求的问题,例如,新的游戏产品的推出,需要测量统计玩家的愉悦指数,沉迷指数用于改善游戏;一些医疗项目的推出,除了基本的药物质检,过程质检,还可以加入痛苦指数的计量,一方面帮助改善医疗过程,另一方面也方便患者可以根据自己的情况选择医疗方案;当然反向也可以用来研制非人道用途的无比痛苦药物;用于自杀高危者的监测;家庭尖锐矛盾的协调解决;战斗中可以监测敌人的情绪,研究不战而屈人之兵的战术……

实时监测的眼镜现在看来可能有点不靠谱。不过如果衡量的尺度能制定出来,已经是进了很大的一步了。如果还能收集到有效的数据,再配以足够强大的数据分析处理,那眼镜还远吗。

不过计量尺度和数据采集的确是一个问题,不见现在,那些咨询顾问就是靠着那么几个数字在大捞特捞么?

大众只是那些指数的数据来源,而很多指数并不能方便地为大众所用。希望也相信未来,许许多多的指数都可以方便地为营造美好生活服务。到那个时候,指数高低并不再是用来制造人与人之间的差异(就像 IQ 在区分白痴与天才),而是更多地用于引导人们更好地组合资源,发挥最优性能取得更好的成绩。

Feb/10

10

呼之即来 挥之则去

乱贴图:没呼也来,挥之不去的大雾,笼罩着一切,让我看不清到底通向什么地方

乱贴图:没呼也来,挥之不去的大雾,笼罩着一切,让我看不清到底通向什么地方


如往常一样,一周到了某个时候,就会打开下载站点,寻觅是否有感兴趣的新资源下载,通常是美剧。与之相对,我亲爱的同事们都流行直接在线看,只要网速足够。另外花时间下载,要关心下载进度,还要关心资源下载好之后的存放等一个一个事情,虽小,但是与在线观看相比,还是显得那么的多余。

呼之即来,挥之则去的感觉是挺爽的。

我也一直在思考那么一种构建方式,Web 应用程序由模块组成,页面上运行的脚本可以按需加载所需要的模块,不过暂时只是在某个程度上实现,还未达到所想要的效果。想要呼之则来,还是没那么容易的,更别谈挥之则去了,幸好目前还没有那样的需求。

可以想象,如果可以稳定地实现按需加载(不仅仅是脚本,所有页面上需要用到的资源),很多有趣的功能都变得有可能了。看来要好好地做做研究,看看现在到底在处理这方面问题时有什么样的方案,什么样的技术来支持。

什么时候才能达到想要的效果呢?或许还需要浏览器进一步进化,增强脚本的功能。

想吧,想吧,继续想吧。

Feb/10

4

说得到,才好做得到

标题有点那个了,意思是能清楚地说出来的,实现起来就靠谱了

乱贴图:无言而对——另类交流

乱贴图:无言而对——另类交流

最近老在思考这么一个问题,写程序的时候,总会遇到一种“瓶颈”叫做不知道该怎么写。别人问我这种问题的时候,第一反应都是很彷徨和无辜,首先不清楚是个什么任务,而且凭什么认为其它人就知道怎么解决呢?

我观察了一阵子,发现其实大多数情况都是可以自己解决的,解决的方法就是要将这个问题清楚地说出来。好,这个听起来很简单的,只是做起来却不是那么容易。

将问题说出来不难的,就是比较零碎,多数情况下,当问问题的开头总会试图组合出一个画面,嘴巴通常已经开始零零碎碎地将涉及到的部件抛出来,如果接收者有点心不在焉的话,通常表现为要求再说一次,当再次表达时,会发觉这个问题可以表达得更加好,更流畅了,接收者不再是接到一堆零散的部件,而是一部分场景。如此反复表达几次之后,问问题的人自己也许已经知道怎么解决了,不过那不是多数,多数情况下是在混合了几个人的资讯之后得出的方案,通常也比较靠谱。对话过程中,如果有实际的代码的话,效果更佳。

如果还是清楚地说出来了,还是不知道怎么写,那么先搁一下吧……
doubanclaim5745b3dc39b95f4e

·

Theme Design by devolux.nh2.me