Alvan - From the Hermit to the World

一、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)，也是这四段代码中唯一能找到亲生父母的子类，上面三个都是”领养的“。

下午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.

网上在MSN上碰到了田欣，讨论了关于网站推广的一些事情。
他创业也有两年多，现在的发展状况良好，据说马上就要搬家，因为要发展到20多个人的规模。
他为我提供了独立的服务器和100G的空间，足够我的网站一年之用，无以为报，就在这里介绍一下他的网站吧：
www.buyest.com

虽然我不常去买衣服，不过还是友情支持一下~~

下班前完成了RSS-TV Client的release，2个月的开发终于告一段落，开始进入QA阶段。

晚上卧谈到凌晨4点，累死，以后不谈了。

刚刚洗澡的时候一直在想关于“进化"的一些事情，当然，头绪很乱，还不足以组织成文字，所以我决定说点别的。

如果说什么东西可以在最短的时间内提升一个blog的关注度，那或许就是”图文并茂“。
我没有研究过人类的阅读习惯，但是很小的时候就知道一句话——千言万语不及一幅画。很抱歉这里我没有配上任何插图，因为我实在是太懒了，也许以后会补上吧。是的，画面总是有更强的表现力，整页的文字往往会令人望而生畏。当然，情况并不总是如此，读小说、散文的时候人或许有更多的耐心，不过，显然那是因为读者已经在内心描绘出一幅图景，所以成功的小说与散文总是有很强的场景感。
图画的表现力很强，但是单纯的图片也有缺陷。当我第一次去Flickr上看图片时，兴奋是难以言表的，但是当我尝试一幅一幅的浏览下去的时候，却发现很难坚持下去。Because there's no story。阅读需要同时满足眼睛与大脑的饥渴，我想这就是原因。从这个角度讲，视频与电影有更强的表现力，因为不仅有图画有故事还有声音，假如能搭配嗅觉与触觉（触觉……），那就更好啦。
恩，这里还是要说博客。国内曾经出现过几个非常著名的博客，包括毒、Keso、老徐等等，除了Keso是以IT评论为主，其他几个都是写一些随笔之类的东西，不同是常常都会搭配上丰富的照片。我们不期待每个人都能像韩寒那样凭借文字就能吸引众多的眼球，所以有图片的blog总是会弥补博主文字上的缺陷。后来有一类咨询类blog也开始流行起来，比如Engadget，网不易等等，几乎每篇文章都必配图片，比起干巴巴的Digg来说更有亲和力。后来连google也把新闻页面从过去的文字索引改成了图片索引。

这个时候，你也许会想，如果允许博客留言也能贴图，会是怎样的一个结果。其实……我也很想知道。