Alvan - From the Hermit to the World

先是IPhone，然后是Microsoft Surface，最近又看到Sony的多点触摸LCD显示方案，这不是一个巧合。多点触摸技术的出现，就像是当年鼠标和Windows的出现一样，会为未来的IT产业带来深刻的影响。

首先是硬件厂商，多点触摸屏技术也许会成为显示设备的标准配置。Sony的这个LCD方案现在最多只支持5个点，以后的技术必将会支持10个点，100个点，甚至无限多的点。触摸屏的精度与触摸点的数量都会成为各个厂商技术竞争的标准。

其次是操作系统。微软与Apple以及Linux阵营很快会跟进多点触摸，新设备对应的新驱动也会层出不穷，这种基础的支持相信即使一名普通的黑客也能做到。竞争的焦点或许会延续到多点触摸支持的SDK上面，新的概念，新的开发技术，新的工具包会带来新的市场与新的竞争。

再次是浏览器。多点触摸不会局限于桌面应用，只有能被浏览器接受的，才是能被大众接受的。IE，Firefox，Safari，Opera……每个都会跟进支持多点触摸。HTML和JavaScript标准或许会需要一些改变才能适应这种变化，即使是插件，也需要这种最基本的支持。

最后是编程思想的转变。无论是form还是page，当pointer从一个变成多个，所有的User Experience都跟过去不同了。鼠标在哪里？焦点在哪里？——过去有答案，现在没有了，因为他们无处不在。

这一天会在什么时候到来？两年之内吧，我估计。

如果一定要我用一句话来描述Farelog的目标，那就是——改变人类提供信息的方式
好吧，这句口号是有点大了，不过相比Google的那个“改变人类获取信息的方式”来说还算正常
这个好高鹜远的目标也基本解释了为什么demo迟迟难以出炉

其实呢，更直接的原因是……
（此处省略几个字）

今天把nick改成“良好的结束是成功的100%，50%没有意义”，作为鞭策吧。

一、Youtube

最近养成一个习惯，听音乐的时候不再是打开Winamp或者WMP，而是直接点击Links中的Youtube链接，然后选择一个playlist播放；搜音乐的时候不再去百度，而是在youtube上先搜索一下，找到的话直接就可以播放。虽然有一些视频今天还能播放，明天就可能会因为版权原因被删除，但是那些音乐总是在的，即使不是官方的MV，也能在某个个人视频的背景音乐中找到；最妙的是你还能找到这首歌的各种版本，原唱、翻唱、Live、Remix、搞笑版……除此以外还有这个歌手的其他曲子，以及许多音乐背后的故事。
MP3是有版权的，但是MP3附加到视频里就没有了，这是多么奇妙的事情～

Youtube就这样成为我的一款网上播放器。唯一美中不足的就是网络有时会有点卡，不过自从Google收购了Youtube以后，这个问题似乎已经大为改观。还有一点不便就是从Youtube主页到我的playlist还需要2下点击，如果是Steve Jobs，一定会把它变成一步点击:P 

这个体验忽然让人觉得web 2.0仍然是一件很有搞头的事情，因为那些基因良好的站点是会进化的。简单的说，创始人想把它设计成一个样子，但是用户却能把它变成另外一个样子！这真是个令人兴奋的发现。

写到这里，不同的人已经可以看出不同的意思了。那么是你用户还是商人呢？

二、一些琐碎但重要的问题

昨天洗澡的时候在想分割数据表的方案，我不是这方面的专家，Jeff在用Hibernate做数据层的也有诸多限制，但是这仍是个必须要解决的问题。一方面扁平化设计会导致某些数据表容量过大，从而降低了查询效率，另一方面，考虑到不同的企业级用户可能会要求各自的数据独立，所以拆分数据表势在必行。

剩下的问题就是技术细节了。我查阅了一下网上的资料，Oracle和SQL Server 2005都提供数据库表拆分的支持，或许会比我之前考虑的应用程序级别拆分要容易一些。不过我想，如果在一个良好的MapReduce框架下实现应用程序级别的拆分，或许可以保持更佳的灵活性和扩展性。更何况，在整合分布式文件系统以后，整个系统的数据层的复杂度会远远超过一个数据库。数据库？那个时候恐怕都要成为toy了……

至于最后找谁来做这件事，我还没想好。我自己可以做，但是我希望可以找到更合适的人选。

三、更加琐碎但是更加重要的问题

从我有一个“大想法”开始，我不得不随时关注着Google的动向。这个著名的web 2.0 killer总是在凭借着她的资本和技术实力扼杀一个又一个独立创业者，所以起初，我总是想着如何找到一个idea是他们那群人想不到的。直到后来，当我看到Google黑板报的一个系列以后才恍然大悟——这种“另辟蹊径”的想法其实是没有必要的。

再强的强者也是有弱点的，而且越是相似的强者就越是有相似的弱点，这就是为什么Microsoft可以在IBM的淫威下崛起，Google又可以在Microsoft的淫威下崛起的原因。说的简单一点，船大难调头，说的晦涩一点，他们早在上市之前就已经成功了。《浪潮之颠》的第一章《帝国的余辉(AT&T)》生动的诠释了资本运作的双刃剑效果。换个更加鲜明的说法吧，上市的本质就是用资本活力取代创新活力。除了风投，没有任何资本会喜欢创新的高成本与高风险。可悲的是没有谁能走出这个怪圈，可喜的是Google也没能幸免。:P

1、以邮件方式写Blog会慢慢的成为主流
当初甚至考虑为了这个idea买下mailog.com的域名，不过当我还在研究mail service的时候，M$ Live Space就推出了这个功能的试用版。过了一年多时间，现在网易也跟进了。其实技术实现并不复杂，只是需要对Mail Server进行稍许改进。当然，仅凭借这一个idea是不可能支撑起一个创业计划的，幸而后来意识到这点，及时砍掉了这个想法。

2、SNS社区在中国必将式微
虽然Facebook是越来越红，但始终是墙外开花墙内香。这种东西必然是南橘北枳，因为这类网站对“人”，对“文化”，对“习惯”都很挑剔，这种环境中可以大红大紫，换种环境就可能奄奄一息。简单的说，在那种走在街上都会有陌生人友好的打招呼的国度，用网络来建立人际关系是简单的；而在那种做了好事都会被法庭判罚赔款的国度，人与人之间的信任与友好已经落到底限，期待用网络来改善这种现状不是痴人说梦么。

3、E-Toy的崛起
人有很多东西需要渲泄，欲望、愤怒，同样也包括想象力。有人在我之前提出过Game 2.0的概念，让人们除了能体验虚拟世界还能创造虚拟世界。有人正在做这样的事情，但是我认为困难重重。除了技术上的障碍，最大的阻碍还在于如何能设计一个系统，复杂到能构造一个世界，又简单到让5岁的儿童都能学会。因为5岁的孩子不会玩的东西，谁也学不会。大道至简，这个东西本就存在于世，悟到的人可以开始做了。

4、Who is the next ”The One“
”近一百多年来，总有一些公司很幸运地、有意识或者无意识地站在技术革命的浪尖之上。一旦处在了那个位置，即使不做任何事，也可以随着波浪顺顺当当地向前漂个十年甚至更长的时间。在这十几年间，它们代表着科技的浪潮，直到下一波浪潮的来临。从一百年前算起，AT&T 公司、IBM 公司、苹果公司 (Apple)、英特尔 (Intel) 公司、微软 (Microsoft) 公司、思科公司 (Cisco) 公司、雅虎 (Yahoo) 公司和谷歌 (Google) 公司都先后被幸运地推到了浪尖。……“ ——Google研究员 方军
谁将是下一个"The One"？
它是互联网的操作平台。不同于公开用户数据的Facebook，或者公开数据与接口的Google Map，它所能提的服务能让每个有着伟大创意的人不再操心数据的储存与检索的细节，不再担心服务器当掉或者撞墙，不再为购置硬件或者租用域名空间耗费大量的成本，构建一个web服务就像注册一个blog一样简单。这个技术已经成熟，可以说是M$的灵魂与Google的基因共同的产物，但是还未有人涉足。不过，Neo还在Matrix中因为每日迟到而被老板训斥，所以等到他变成The One还需要假以时日……

前面一篇说到“数据为王”的观点，zzj提到为什么google video打不败youtube，索性这次就再深入讨论一下“数据从哪里来”的话题。

既然web 2.0都已经2了这么久了，这件困扰了无数站长的问题已经有一个非常确定的答案——让用户来创造数据吧。
但是这件事说起来容易做起来难。记得一两个月前有一次给Kathy做了一个问卷，问题只有三个：
“你喜欢看其他人的旅行游记么？”——喜欢
“文字、图片与图文并茂，你更喜欢那种形式？“——图文并茂
”你自己喜欢去经常写这样的游记么？”——不经常
最后一个问题的回答就是问题所在。让用户来创造数据吧，可是愿意创造数据的是那少数派，剩下的大多数都只愿意点点鼠标，看看文字，看看图片，看看视频。于是，对于那些想跟着web 2.0一起2的创业者来说，重中之重不是做界面做功能以留住那些提供浏览量的大多数，而是做环境做服务以留住那些提供内容的少数。Google显然只擅长前者，而更多的国内效仿者，恐怕连前者都做不到……

我相信youtube创始之初一定有这样一群少数派，确切的说每个成功的网站创始之初都有这样一群少数派。他们是提供内容的少数，他们像游牧民一样在互联网上四处寻找一块安身之所，当他们终于找到一块这样的土地时，他们会留下来精耕细作，他们中的一些人不仅生活在这里也试图改造这里，为网站的创建者提供各种意见与建议。有一天，当beta标签终于从网站logo上撤下的时候，这块土地也迎来了它的丰收日。

这样的故事不会发生在Google身上，因为他们甚至连”客服“都没有。当你想给Google提意见的时候，你知道能给哪个Email写信么？当你遭遇某些问题而想和Google沟通的时候，你知道该用哪个号码播电话么？这就好像你打算耕种一块土地的时候，上帝对你说，“你不需要这么做，你也不能这么做，你唯一能做的就是将就一下，然后祈祷，也许某一天我有空的时候会替你改造那里的。”
如果Google Video能这样打败youtube，那才是见鬼了。

Google也许有世界上规模最大的cluster，功能最强的crawler，水平最高的技术人员，所以他们可以不依赖用户积累起庞大的数据。即使碰到视频这种只有用户才能做的事情他们也不用担心，因为他们有钱，打不赢你我还买不了你么？
但是Google不操心这些用户，不代表你就可以不操心。除非你的网站也能像Google一样，所有内容都从别的地方拿来……

just kidding

几天前与zzj进行了一次简短的交谈，期间有一句话可以成为真理：
网站的价值和它的数据成正相关

从这个角度审视那些成功和不成功的网站，似乎一切结果都变的很合理
那些曾经的标准，诸如点击量、用户数量、成交额，
还有那些难以量化的东西，诸如服务质量、用户体验之类，
都是在直接或者间接的影响这网站存储的数据。

当然，这句话还可以深入研究，
诸如数据的数量和质量，数据的时效，数据的获取速度……

点到为止。

代码一：
    var Parent = new Object();
    Parent.name = "parent";

    Parent.Child = function() {
        this.name = "child";
    }

    这里的this指Parent还是Parent.Child？
    答案是both。

    情况一、Parent.Child用作构造函数的时候，this指向Parent.Child对象
    var child = new Parent.Child();
    alert(Parent.name + “ / " + child.name);
    输入结果是: parent / child

    情况二、Parent.Child用作普通函数调用的时候，this指向Parent对象
    Parent.Child();
    alert(Parent.name);
    输出结果是: child

    这个逻辑还是很合理的。当然，最好是避免这样用，毕竟不是每个人都能很清楚这其中的区别。
    特别注明，Parent.Child不是Parent的子类。

代码二：
    var Parent = function() {
       this.name = "parent";
    }
    Parent.Child = function() {
       this.name = "child";
    }
    对于这种情况，两个this的指向就非常清晰，前者指向Parent对象，后者指向Child对象。
    这种用法其实很不错，可以避免类名冲突，起到了namespace的作用。
    当然，Parent.Child也不是Parent的子类。

代码三：
    var Parent = function() {
       this.name = "parent";
    }
    Parent.prototype.Child = function() {
       this.name = "child";
    }
    这几行语句，那是相当的清晰易懂。
    但是，如果有足够的好奇心也许会写下var child = new Parent.prototype.Child(); 这样不可理喻的代码，
    结果当然是非常确定的，child是存在的，child.name也是存在的，
    只是这个child究竟是谁的孩子呢？……天知道。
   
  代码四：
    var Parent = function() {
       this.name = "parent";
    }
    var Child = function() {
       this.name = "child";
    }
    Child.prototype = new Parent();
    这就是所谓的JavaScript的继承(inheritance)，也是这四段代码中唯一能找到亲生父母的子类，上面三个都是”领养的“。

我又开始厌倦yculblog了。
编辑界面感觉很难受，鲜红的一条横线加上win2000的那种难看的蓝色，每次有点写东西的欲望也顿时思路全无。
HTML编辑器load很慢，常常打不开。如果切换成简单文字编辑器，那所有的换行都会消失，出来密密麻麻的一坨字……
模板也没有一个感觉特别好的，只能众多模板里面找一个相对能看着顺眼的。
稳定性尚可，偶尔会无法访问，偶尔会出现模板错误。

话说Live Space虽然饱受诟病，不过现在看起来，似乎速度提升了很多，页面布局也漂亮了很多。最让人舒服的功能是mail blog——用特定的email给特定的地址写信，就会自动把内容post到space上。这个功能曾经有一些bug，不过现在工作非常良好。毕竟是我曾经日夜期盼的功能啊。

最看好的是blogbus，界面从flickr借鉴了很多，看上去很舒服，用起来也很舒服，速度很快，也有很漂亮的模板。

现在的问题是：一、要不要再次搬家呢? 二、如果搬家搬到哪里呢？

补充一句，最近看星盘的结果是，我的月亮落在12宫，说明无论我搬到哪里，都不会写很多或者说很多，八卦例外:D

下午14点39分，收到一个亲戚从msn上发来的photos.zip文件，由于缺乏警惕，结果中招，
随后Messenger疯狂打开窗口向其他人发送病毒包，幸好手快，杀掉了msn的进程

经过初步研究，这个病毒是前段时间流行的“性感相册”病毒的变种，以下为查杀方法：
第一步：关闭MSN
第二步：到windows目录下，搜索所有zip结尾的文件，删除
第二步：回到桌面，点开始>>运行>>输入regedit >>回车，在左边的树状目录中依次寻找
HKEY_LOCAL_MACHINE>>Software>>Microsoft>>Windows>>CurrentVersion>>ShellServiceObjectDelayLoad
在右边的列表中找到其中的“pinters"这个键，把这个键值记录下来，比如： {7665D4B4-1F62-4459-AFFF-258E30BDB44D}
然后删除这个键值
再在左边树目录Ctrl-F搜索这个键值（ {7665D4B4-1F62-4459-AFFF-258E30BDB44D} ），将找到的目录删除
第四步：重启电脑
第五步：到windows\system32目录下面，找到msn.exe和 libcintles3.dll，删除
第六步：到C:\Document and Settings\当前用户名\ 目录下面，显示所有隐藏文件和系统文件，把后缀名为.exe的全部删除
第七步：重启电脑

到这里，这个病毒基本上是移除了，还有任何的问题的话，就及时联系我email: alvansea@gmail.com

PS：这个方法可能只对我收到的病毒源以及我扩散出去的病毒源有效，其他人也可以尝试一下

又一次睡到下午才上班，还是不要隐瞒比较好。

在办公室开始重新设计Navigation的Library，这次精简了架构，把过去的VerticalContainer, HorizontalContainer, FormContainer和乱七八糟的这个Container那个Container精简成两个，SimpleContainer和GridContainer。
Simon问我为什么设计还没结束就开始代码了，我告诉他那个UML图就是设计，虽然他仍然觉得那个“设计”太简单了，我还是坚持简单的东西就是好东西。只要确定了各个模块之间的独立依赖关系，我就可以把功能比较独立的部分交给其他人做。至于具体每个模块之内如何设计，以及模块与模块之间的交互——坦白的说，我还没想清楚，也想不清楚，这个项目不是用来解决已知问题的，所以还是自由度越大越好，不做过多约束，只要在开发阶段不断进行审核就可以了。OK，这也算是我对“面向进化”的一个实践吧。

关于JavaScript的继承，本来已经没有太多的问题，但是“如何在子类中调用父类引用”这个问题，却把我硬生生的绊住了。我查阅了很多资料和文章，解决方法有很多，但是没有一个可以让我满意。好吧，我最后决定放弃这件费力不讨好的事情。本来的目的无非是为了代码复用，不过代码复用的途径有很多，也许调用父类引用是最差的一个。以后我会专门开贴讨论这个问题。

在3个小时的工作后，GridContainer的核心代码已经基本可以运作了。So far, so good.