•
进大学前对元旦没什么感觉，小学、初中生活在农村自不消说这些，高中是在一个小县城读的，但也不记得这一天有什么特别的地方，在大学的时候因为每年的元旦各学院都有活动所以想不感受到元旦的氛围都不行，不过那时读书不用功，平时也跟元旦差不了多少。工作后才发现你的时间都不再是你的了是公司的，法定的几个假日才是可以自由支配的时间，于是有人就产生了要好好怜惜一翻的感觉，但真到了那一天他多半躺在被窝里，美滋滋地补上一觉。
看到一个广告上面写的是“Happy 牛 Year”(很有创意)，不知道今年是牛年还是2009年才是，或许在看完春晚的那几天会记得，但现在真的搞不清楚。吃午饭回来的时候问同事这个问题，他们的答案是今年是牛年，如果今年是牛年为什么要在快结束时而庆贺呢？！想不明白。
2008年的藏独、圣火、奥运什么的似乎离我很远，只有 5.12汶川大地震有切身体会，那时大家都惨兮兮地，睡过篮球场，躺过足球场，下雨把被子打湿了，实在没法睡，半夜一个人爬起来围着学校转了一圈，结果发现绝大部分都睡的很死，也有一部分人没得去处只好躲在食堂的屋角下，有一个男生裹着被子在那里借着路灯看书，相当震惊的一个场景。后来在食堂的另一角看到一个女生哭着蹲在一堆炭灰前面取暖，炭灰一点火星都没有，只冒着一串被雨打湿后的白烟，好在天快亮了，这两个场景是5.12给我留下的最深印迹。
记得当时获取信息很不方便，还办了一个短信小报向几个地震中的朋友介绍最新进展，这份小报大约持续了一周，记得有记录的，不知道放在什么地方去了。
六月份毕业了，七月份来了成都，进了现在的公司，然后是工作，周末，周末，工作，偶尔余震也会光顾一下，不过已经被毫不客气地无视了。本来计划年内DIY一台服务器的，一直未能实现，希望09年能把服务器置办了，当然前提是PanGu能够执行成功。至于其它什么对朋友、家人的祝福啊我不会写，不说、不写并不代表我没有祝福，现实主义一个，放在心里好了。
有一个特例，哥哥的儿子—乐乐，虽然才几个月大小，不过幺爸希望你人如其名，要知道你出生后那几天家里人都替你担心，而且你还要继承你爸未能实现的理想（他自己可能都不记得了），他影响了我，也希望他能影响你。在你爷爷的要求下，幺爸过年必须给你买礼物，买什么呢？买什么呢………..
•
原文标题是“PHP之父的开发秘诀”，改成了现在的。这篇采访是公司的邮件，在网上没搜到，看上去也不是那种不可以拿出来分享的公司资料，说来也巧，上次Twitter说到的哪本《构建可扩展的Web站点》也正是主讲可扩展性网站的架构，个人对采访中Rasmus Lerdorf对于框架的态度甚表赞同。
要让网站具备扩充性，必须建立分离、模块化的独立端点，而不是全部放到同一个大篮子里。
PHP语言的创始者Rasmus Lerdorf认为，程序不用写得完美，而是要简单有效，这是最重要，也是最困难的事。
PHP是全世界上使用率最高的网页开发语言，台湾每4个网站，就有1个用PHP语言开发。1995年发明PHP语言的Rasmus Lerdorf，也是打造出Yahoo全球服务网站的架构师之一，他首度来台分享如何架构网站扩充性、安全性和效能的秘诀。
Q：越来越多Web 2.0网站走向应用平台，你认为打造这类平台的关键为何？
A：简单来看，应用平台就是API，任何Ajax或 Web 2.0类型的网站，都是在应用平台上运用了API来创造出视觉接口的互动效果。例如Yahoo Mail，透过简单的Request呼叫，来读取后续的信件。打造这类网站，如何规画解决问题的方式，会决定了网站未来的扩充性 （Scalability），而非效能决定网站的发展。
Q：如何规画网站架构，才会具有扩充性？
A：将一个网站应用，分成几十个独立小程序，前端透过 API提供服务，后端是应用程序引擎，这样做自然会有扩充性。因为应用的每一个部分，都有不同等级的使用方式，需要有不同的扩充程度（scaling level），需要不同的机制来处理。以开发Yahoo Mail而言，是要开发一个地址服务程序、一个读信服务、一个送信服务，而送信程序完全和读信程序无关。以Yahoo的规模而言，需要让这些工作完全分 离，才有扩充性。
Q：这种规画网站的方式，什么是最重要的关键？
A：关键是你必须建立分离、模块化的独立端点，而不是全 部放在同一个大篮子里。大多数现今MVC架构（MVC framework）的开发框架（Framework），使用所谓的前端控制器（Front Control），每一次浏览器提出Request请求时，就会呼叫这个前端控制器，再由前端控制器来分辨，使用者想要执行哪一支程序。这样做，一点意义 都没有。
在浏览器层次，程序完全能知道用户想要做什么事情，例如使用者只是要读信，程序就不用再把需求送到服务器，让服务器判断使用者要读信还是送信。 将这类决策工作拉出浏览器，由服务器处理，就会浪费大量服务器资源，来处理那些对用户没有实际功用的工作。扩充性来自架构，很多开发框架，将所有事情绑 在一起，限制了架构。选错开发框架，你就没有扩充性。
Q：你是说MVC模式不利于网站扩充性？
A：MVC模式比较适合用在网页控制器（Page Control）的层次。基本上，每一个网页控制器都是独立模块，读信和查地址是不同的网页控制器，所以，读信程序就不会干扰到查地址程序。所以，在每一 个端点使用MVC模式来打造小型的网页控制器，是不会有问题。但是，大多数采用MVC模式的框架，默认在网站中采用前端控制器，而非用网页控制器的方式， 这样的MVC模式，只适合在小型或单一服务器的网站。
Q：你会如何选择开发框架呢？
A：一个框架都不要用。但是，我会从这些开发框架中，找出我需要的功能，拿出那个我需要的程序模块来用，或者参考其中的设计想法，而不是套用整个框架。我所看到的大多数框架，都没有专注在打造有效能的扩充性和可模块性。
Q：难道开发者不需要框架或架构吗？
A：网站的确需要有架构，每一个人都需要框架，框架是一 种解决问题的方法。但是你并不需要通用型框架，用一个前端控制器，来解决所有问题，这样通常没办法成功。每一个问题都不同，你需要引导框架，使用正确的设 计模式，直接解决真正要处理的问题。只生产一款汽车，怎么可能满足全世界人的需求！
用框架开发雏形系统就好，但真正的产品就不要全部套用。从框架开始比较容易，但你要拆开全部的框架，移除Runtime检查、拿掉不需要的功能，只留下你会用到的程序模块。你不需要一个通用型框架，因为它无法提供未来的扩充性，但也不用重头写起，你需要的是介于两者之间。
Q：网站需要规画到多久以后的扩充需求？
A：我总是痛恨要帮未来考虑太多。当你无法预测未来，你就无法帮未来作决定。
网络变化太快，我通常只规画半年内的事情。现在决定半年以后的事情，可能会做出错误决策，反而让事情更糟。如果你没有解决当下的问题，而是想象未来会发生的问题，我认为不值得，我宁可解决眼前看得到的问题，真正聚焦在当下需要的产品。
Q：那么，有任何准则是架构人员可以遵循的吗？
A：最主要的原则是，仔细考虑如何分配程序模块，尽可能将程序拆解成更小的组件，调校出适当的API，你应该规画的是使用者端点的事情，例如浏览器请求的类型是什么？应用程序要如何响应？是否可以切割？是否可以把这些工作分配到完全分离的服务器上执行？即使是在同一台服务器上，你也能从使用者端点的角度来架构应用程序，有一天，当你的规模变大后，就可以很容易 加入第二台服务器，只要在前端服务器不储存任何数据，就能进行流量分担。一般开发者最大的错误是，让程序代码之间的交互关连（interrelation）太深，每个不同的组件都需要和其他外组件沟通，这样做很难调校出很干净的API。开发者会无法抽离出效率慢的API放到辅助服务器中，而让主服务器只执 行必要API。
Q：切割服务、拆解程序的难度是什么？
A：必须在开始之前，就要非常了解问题。当你写完第一个版本的程序，才着手拆解问题，那几乎是不可能，很难事后处理。这的确很难，因为问题会一直改变。但是，若你从简单的架构开始，并且保持这个精神来区隔程序 模块。每次当网站发生变化时，问题的变化也只会影响到一小部分，你就能够非常清楚那个地方，能够直接解决问题。就好像乐高游戏一样，盖好每一个小块积木， 哪边还有不足，就只需要再补上一小块就好，不用对整体改变太多。
Q：除了扩充性以外，如何提高网站效能呢？
A：要提高效能，得先知道每一支程序花了多少时间。我会问，使用者送出Request请求后，要多久才会收到第一个Byte的资料？很多开发人员不晓得这个时间（First Byte Latency）是多久，不晓得自己的程序代码用掉多少时间？可以透过Profile来追踪效能，画出可视化的效能流程图，来了解瓶颈在哪。
甚至要考虑到单一机器上的延迟，透过系统层级的追踪程序，知道程序执行的每一个系统呼叫（System Call）耗费多久。还要考虑浏览器中的延迟，从用户实际感受的速度来改善网页执行方式等。
每次你增加一个新功能，要能计算出新功能会增加多少毫秒，想一想这么做值不值得。
Q：那么，网站的安全性又需注意哪些原则？
A：基本精神很简单，只要用数据防火墙的概念来设计网站。网络防火墙会严密监控每一个通讯端口，只让没有安全疑虑的封包通过，但网站开发者刚好相反，只挡掉自以为有危险的内容。开发者不能信赖任何从外部取得的数据，借用防火墙概念和手法，建立数据防火墙，就能提高网站安全性。
Q：好的架构师需要什么样的条件？
A：必须非常了解技术，了解每一个细节，例如设计数据储 存机制，要了解哪种数据可以储存、可以存多大的档案，放多少数据、每秒钟可以放多快？如何复制数据？前端必须使用哪种数据格式等。架构师可以不用像 DBA，知道如何修复Oracle数据库的错误，但是要能够了解Oracle数据库拥有的能耐。这种人很难找，必须要失败过很多次，才会有足够的经验。
Q：台湾还有不少旧网站使用PHP 4，他们应该现在升级到PHP 5吗？还是等待PHP 6？
A：尽快升级到PHP 5。只要作一些测试和修改，就能得到更好的效能和安全，为什么不做？不需等待PHP 6，开源社群的运作方式，无法承诺推出时间。很多新功能已经放到PHP 5.3版中，赶快从4升到5最重要
•
很难说清每天的阅读给我带来了什么。
从cnBeta开始，接着看鲜果热榜，再看译言，最后看GoogleReader中的订阅，看完这些后，2个多小时也就过去了，再浏览一下CSDN，有时候还会关注一下凤凰、新浪（很少去了）上的时事，有时候会被引到环球网，Twitter上有人发了一些有趣的链接，点进去，又花了一阵子时间…..
即使很努力地阅读，想靠快速地阅读而缩短所消耗的时间，结果却是徒劳，新文章总是在不断地冒出来，你总是能发现那些能引起你兴趣的文章，于是时间在不断地被占用，自己却好像陷入了一个泥潭—拔不出来(也没打算要拔出来！)。
以前看到过一个医学术语叫“强迫症”，说的是一个人强迫自己做这做那(更好地描述看百度百科的描述)，我把自己的这种情况和它上面的描述仔细比对了一下，觉得离“强迫症”还有一断差距，还没被它“临幸”。
阅读带来的直接效益几乎看不见（这句话未免太功利了一些！），一天不去浏览这些新文章又会产生一种被21世纪抛弃的感觉，仔细追究起来又找不到一个非读不可的理由，简单地把这种行为归结为纯粹是自己在寻长“精神食粮”好了（饿死了）……如果真有必要，就“戒读”。
•
“元数据”是什么？简单地说就是构成数据的有意义的词组数据。
比如这样一条信息：“张朝阳是腾讯的董事长，这句话是错的”，其中有意义的词组是“张朝阳”、“腾讯”、“董事长”，这三词是描述数据情况的数据，当然“这句话是错的”让上面这条信息表达的更有意义，但我们没有办法继续对它作出有意义的分解，“话”和“错”解释出来有什么意义吗？
从上面看，元数据一般有两个特性：1，有意义，可以进一步描述或定义；2，偏名词性。分解元数据的过程和搜索引擎分词的过程几乎是一致的，但又有所不同，搜索引擎强调的是自己的词库与用户输入的词之间的匹配，它对不同的词分配了不同的权重，“元数据”不应该有权重的概念在里面，它偏向于对该事物进行描述或解释。
元数据的应用范围：很广、很广
某个品牌下某个特定的型号（这里强调型号而不是子品牌）的电脑的物理参数总是一致的，比如：CPU、内存、电源、显示器等都是一致的。
同样，某款手机的物理参数也是一致的；某型号的汽车的物理参数也总是一致的；某书籍的作者、目录、出版社绝大部门的物理参数也总是一致的；某专辑的演唱者、曲目、发行社这些参数与总是一致的；一个人他的某些参数也总是固定的……..
但是我们发现，即使同一款电脑在泡泡、it168、淘宝或百度有啊这些网站的参数情况也不尽相同，因为这些参数需要他们各自去收集，一些小网站就更别想调用这些数据了。
既然这些参数是统一的，完全可以建立一个大型数据库来收集它们，其它应用只需要到这里调用这些元数据就行了。
维基 、百度百科 、互动百科 的数据都没有统一的格式，这么做一方面简化了数据的存储管理难度，另一方面最大化地方便用户随意编辑，但带来的问题是无法把这些数据分解成有用的元数据供别人调用，FreeBase 就将类似维基的数据格式化处理，可以分解成元数据供别人调用，可惜几乎都是英文的，不知道中文类似的服务什么时候才会出来（越来越觉得某些方面世界统一比较好：语言？文字？）。
