Facebook新设计，一个Web OS的雏形
传闻Facebook的新设计今天（星期一）就要正式发表，在其正式发布前相当一段时间已经可以用www.new.facebook.com预览了。
facebook自己早在5月宣布这个预览版本的时候声称其目的是构造一个更简洁的用户体验和让开发者可以更容易在用户页面上有发挥空间。 Techcrunch对新设计的评论是 “Fiendfeedization”, 也就是说其和friendfeed长得很像, 认为新设计更加多地强调了类似friendfeed的activity stream的设计，因此讽刺其为friendfeedization.
对任何设计都会仁者见仁，智者见智，而一个设计最终的成败，有时会出乎所有人意料之外。 我看facebook的新设计和其最初宣称的目标是很接近的，而且尤其注重给developer更多的空间。
在新的设计下，首页如同techcrunch的评论，变得愈发friendfeedization了，但此外所有的东西被归类到4个tab下： 自己、朋友、inbox、应用。 “应用”是个下拉菜单，列出了用户安装的所有应用，值得注意的是，facebook自己提供的功能，例如相册、活动等和其他第三方应用完全平等地在那里 （老版本也就如此了）。 在“自己”的页面上，原来的应用的一席之地被归类到”boxs”下去了，用户可以自己添加新的app专门的tab. 这个设计可能是一种折中方案，我并不认为这是个好的设计，但可以看到app的重量进一步提高了。
Facebook已经越来越变得接近一个web os的雏形，他提供的是一个透过浏览器进入sns世界的基本框架，框架本身的功能是有限的，而这个框架上的应用却是可以不断扩展的。 facebook app的发展速度是惊人的，差不多一年前才推出，现在已经有了相当丰富的规模，光我现在team的同事，就有两个人业余开发了自己的facebook应用 (My City, Adopt a man)，用户发展得红红火火的。
目前facebook上的应用还是以“小应用”为主，但从热门应用的发展来看，趋势是应用越来越复杂，并且以多用户之间交互的通信为主。其实另外一 个更早的小应用框架是netvibes, netvibes表面看来是个个人网络桌面，更加容易被人理解为web os或者web desktop, 然而我觉得netvibes和facebook比较一个巨大的缺失就是不同用户之间的互动关系，netvibes很早就提供了可以让我把我的 desktop share给别人的功能，但是谁高兴整体对着别人的desktop呢？ 从这个角度比较，netvibes更像个早期一些的操作系统，虽然可以有多用户，但各个用户之间的联系很有限。 facebook更像具备了基本终端之间通信能力的联机系统，用户不但可以自己用，还可以互相通信。 他们的共同点是，都已经摆脱了专用系统的局限，可以安装application了。
如果把眼界放得更广阔一些，可以发现另外一个类似的先驱是Salesforce, 我相信facebook平台的开发者应该从salesforce那里找到了“底气” — 企业应用都可以，sns为什么不可以？！ Salesforce的apps exchange平台早在两年前就勾勒了一幅今天在facebook上可以看到的前景，不过由于其面向企业应用因此并没有那么火。 然而，saleforce的平台设计可能比facebook具有更好的参考意义， 如果纯粹从技术角度和面向未来的角度去看的话。
尽管如此，facebook仍然只是处于一个初级阶段， 但有些时候想法太超前未必是件好事，做事的角度来看，要在恰当的时间有恰当的想法和恰当的执行才行。看到facebook，salesforce，以及 Microsoft, Amazon, Google鼓吹的Clound computing这个趋势, 其实有大量的创新机会摆在眼前，这个机会并不亚于互联网出现的早期年代，这个趋势的成长过程也许还需要5~10年的时间甚至更长 （想想当初NC的红火到没落的过程以及其概念在今天的体现！），可能会有很多先驱/先烈为此奋斗很久，有人会在此浪潮中大获成功，也有大量的资金和人力会 化为灰烬。 呵呵，正所谓：
滚滚长江东逝水，浪花淘尽英雄。是非成败转头空。青山依旧在，几度夕阳红。
白发渔樵江渚上，惯看秋月春风。一壶浊酒喜相逢。古今多少事，都付笑谈中
Popularity: 7% [?]
解读 Mixi.jp 的成功之道
早在两年前，HUNG 曾看看 mixi.jp，而两年来，mixi.jp 在社会化网络市场中的进步与成功，已经成了又一个标杆。昨天， TC 的 Serkan Toto 对 mixi.jp 做出了详细的分析，解读其成功之道，以下为全文译文：
Mixi 于 2004 年 2 月上线，目前自称会员人数已超过 1500 万，约占日本网民的五分之一。该网站在 Alexa 日本地区的排名为第6位，每月页面浏览量逾 140 亿次。通过 Google Trends 可以看出，专注日本市场的 Mixi 的用户数甚至超过了英国的社会网络 Bebo 在全球的用户（后者为每天 230 万）。
差异化策略
与英美等主要社会化网络不同， Mixi 并不擅长利用丰富的功能取胜。但是，该网站针对日本网民推出的差异化服务，却让MySpace、Facebook和Bebo等在日本胜出无望。
• 限制会员以提升安全级别： Mixi 网站要求每个会员必须超过18岁，新会员都必须借助当前会员的邀请并需使用日本的手机邮箱地址注册。
• 注重社区与博客： Mixi 会员使用率最高的是引用外部博客文章，其次是发表和分享所谓的”日记”。与其他社会化网络提供信息传递、会员状态更新以及内容源不同， Mixi 着力将自己打造成为日本最大的博客平台之一。此外，该网站还提供了250多万个用户自建的论坛。
• 高度固化设计与结构： Mixi 几乎不允许用户自行改变网站的结构和外观，也不允许使用外部应用程序，并只提供日文版本，该网站最显著的特色就是没有特色且功能单调。
• 高度匿名： Mixi 允许用户设置为完全匿名，因此该网站采用真实姓名和照片的会员比例不足5%。 Mixi 提供的”足迹”功能对于会员非常重要，这一功能可以让用户跟踪到访用户的个人信息页面，从而增加用户的安全感。
• 手机定制：自去年7月以来，通过手机访问 Mixi 的用户超过了通过PC访问的用户。3月份来自手机和PC的浏览量分别占总浏览量的60%和40%。
盈利可观
Mixi 在提供服务的同时也可获得丰厚的收入。 Mixi 是全球最早上市的Web 2.0公司，2006年9月在东京证交所公开上市发行，目前市值达9.7亿美元，逼近LinkedIn 10亿美元的估值。
Mixi 母公司旗下的网络招聘网站Find Job!也有可观的盈利，该网站主要面向IT行业提供求职与招聘服务。在截至3月底的财年中， Mixi 网站的销售额由去年同期的3650万美元大幅增至 8240万美元，而Find Job!的销售额则为1160万美元。 Mixi 母公司的净利润也比去年同期增长了79.9%，达1900万美元。
虽然绝对用户数量和财务数据仍无法与英美等领先的社会化网络相提并论，但考虑到仅依靠日本市场生存， Mixi 的业绩仍让人印象深刻。 Mixi 的每用户收入(ARPU)为5.46美元，是Bebo的13倍多，是Facebook的3倍多。如果将Find Job!计算在内， Mixi 的每用户利润为1.26美元，而Bebo只有0.1美元。根据”每用户网络广告支出”这一指标计算， Mixi 在 Techcrunch最有价值社会化网络排行中名列第八位。
商业模式
Mixi 的成功在于采用了整体水平化及底层垂直化发展的商业模式。例如，用户每月付费3美元即可成为付费会员，可以获得额外的存储空间等服务。会员付费在 Mixi 总收入中所占比例为7%。
Mixi 还通过其他渠道获取收入。借助 Mixi 的音频播放插件，用户可以通过iTunes共享或者购买 Mixi “音乐”区中的歌曲，也可以直接访问网上零售商店订购CD。另外， Mixi 还在本月推出了部分付费音乐服务” Mixi Radio”。
在 Mixi 的”评论”区用户针对图书、CD和DVD所发表的成千上万篇评论中，都包含有相关网络商店的链接。通过将流量导向雅虎日本的搜索服务、目标广告和文本广 告， Mixi 还能获得一笔额外的收入。此外， Mixi 还经常与日本公司合作，在网站上举办促销活动。
尽管MySpace和Facebook分别于2006年11月和2008年5月推出了经过翻译的日文网站，但这些网站并没有实现本地化。 Mixi 成功的代价正是在于扎根日本市场，因此其进军海外几乎没有成功的希望。最近， Mixi 宣布进军中国市场，然而对该公司而言，也许继续耕耘日本市场会过得更好。
Popularity: 8% [?]
13个代码注释的小贴士
原文作者：José M. Aguilar
原文链接：13个代码注释的小技巧
译者：薄荷脑
本文由José M. Aguilar用法语发布在他的博客Variable Nod Found上，由TimmMartin翻译并受权发布。
下面的13条小贴士可以帮助你写出更规范、更容易维护的代码注释。
1、逐层注释
使用统一格式对每一个语句块进行注释，如：
- 类：简单描述、作者、最后修改时间等
- 方法：关于该方法的目的、函数、参数、返回值的描述
在团队工作中，使用统一的注释规范显得尤为重要。当然，也推荐使用一些专门用来添加代码注释的工具，如C#中的XML、Java中的Javadoc等。
2、使用段落型注释
将代码分割成能完成独立任务的段落，并在其前后添加注释，告诉读者程序将要做什么。
// 检查所有的记录是否正确
foreach (Record record in records)
{
if (rec.checkStatus()==Status.OK)
{
. . .
}
}
// 现在开始进行事务处理
Context ctx = new ApplicationContext();
ctx.BeginTransaction();
. . .
3、对齐连续的行注释
若对多行添加行末注释，应将注释进行对齐，以便于阅读。
const MAX_ITEMS = 10; // 数据包的最大数量
const MASK = 0x1F; // TCP标志位
有些程序远使用制表符来进行对齐，有些则使用空格。建议使用空格来对齐，因为不同的代码编辑器对制表符的处理会不一样。
4、不要侮辱读者的智商
不要用这样的注释：
if (a == 5) // 如果a等于5
counter = 0; // 就将counter的值赋为0
这样做只会浪费你的时间，而且读者的注意力会被从代码中转移。
5、注意礼貌
避免使用无礼的注释，如：注意有些蠢蛋会输入一个负数；这修复了程序最初版本遇到的问题，那个无个救药的笨蛋。这样的注释会反映作者的素质，而且你不知道将来谁会读到你的程序：你的老板、顾客，或者是你刚才辱骂过的那个程序员。
6、讲重点
不要在写冗余的注释，也不要用所谓的字符艺术、玩笑、小诗等。总之要保持注释的简单和直接。
7、坚持统一风格
有些人认为代码注释应该简单到让不会编程的人也能看懂，另一些人则认为代码注释只要让程序员看懂就可以了。不管怎样，正如《撰写代码注释的成功策略》中所提到的，代码注释的风格应该是固定的，是为同一个观众准备的。而且我个人认为不太会有非程序员来阅读代码，所以代码注释应该只是针对其他程序员的。
8、使用内部统一规定的标签
在进行团队开发时，可以在注释中使用一些特殊的标签。比如在一些团队中使用“TODO:“标签来表示这里还需要完成其他的一些任务。
int Estimate(int x, int y)
{
// TODO: 实现这项计算
return 0;
}
这里所使用的标签注释并不是用来解释代码，而是引起读者注意并传递一些信息。如果你的团队确实在使用这类注释，就要保证会依此进行作业。
9、边写代码边注释
在写代码的时候，乘脑中记忆还清晰，及时写上注释。如果你想在程序编写完之后再添加注释，也许就会花费你两倍的时间。“我没有时间添加注释”、“我很忙”、“这个项目已经有所拖延了”都将会是你的借口。有些程序员认为你应该在编写代码之前就写好注释，以为你的最终方案作出计划。如：
public void ProcessOrder()
{
// 保证这些产品是可以购买得到的
// 检查用户时候合法
// 向商店发出订单
// 生成账单
}
10、就当是为自己写注释（事实上的确是让你自己看的）
在添加代码注释时，要想到这些注释不仅是为将来维护代码的程序员而写，也是为你自己而写。用伟大的Phil Haack的话来说：“当一行代码写好并出现在屏幕上时，你就变成了一名维护人员。”所以，我们自己将会成为代码注释的第一个受益人或受害者。
11、更新代码时同时更新注释
如果注释不随着代码的改变而修改，那在准备的注释也是没有用的。代码和注释应该始终保持同步，否则这些文不对题的注视将使维护人员摸不着头脑。对于那些自动添加注释的工具要格外注意，不要让它忽略更新注释。
12、黄金准则：写可读的代码
有一条基本准备叫“让代码解释它自己”。虽然有人认为这个倡议是由一个懒得写注释的程序提出的，但不可否认的是一条可以自我解释的代码可以让其变得更为易懂，并让注释显得不那么重要。如，在我的Fluid Interfaces文章中有一些可以自我解释的代码的例子：
Calculator calc = new Calculator();
calc.Set(0);
calc.Add(10);
calc.Multiply(2);
calc.Subtract(4);
Console.WriteLine( “Result: {0}”, calc.Get() );
在这个例子中，代码不需要注释，否则会违反本文的第四条贴士。要写出可读的代码，你应该考虑使用恰当的名称（在Ottinger’s Rules中有所叙述），确保标识正确，并根据代码规范来撰写。如果没有遵循此条建议，注释可能会被看作是代码的一种“道歉”。
13、和你的同事分享这些贴士
虽然第10条贴士说我们自己将是代码注释的第一个受益者，但如果把这些贴士分享给你的同事，尤其是在同一个团队中工作的同事，你就会发现你们写出的代码注释会更为易懂和易于维护。
Popularity: 7% [?]
Protocol Buffers概览
原文作者：Google
原文链接：Protocol Buffers Docs
译者：sevenever
开发向导
欢迎来到protocol buffers的开发者文档，protocol buffers是语言中立，平台中立，易于扩展的结构化数据序列化方法，它可以用在通讯协议，数据存储等方面。
这份文档的目标读者是试图在应用中使用protocol buffers的Java, C++或者Pytho开发者。这份概览告诉你如何开始-然后你可以去教程或者深入到protocol buffer编码。API参考文档同样以三种语言提供，包括编写.proto文件的编程语言和代码风格指导。
什么是protocol buffers？
Protocol buffers是一种可伸缩，高效的，自动化的结构化数据序列化机制，它比较像XML但是更小，更快，更简单。定义好你的数据结构，然后你就可以使用生成 的特殊的源代码读写你的结构化数据，数据来源可以是各种数据流，也可以使用各种编程语言。你甚至可以在不破坏使用旧格式编译并已经部署的程序的情况下更新 数据结构。
他们如何工作的？
通过在.proto文件中定义protocol buffer消息类型，说明需要被序列化的信息需要保持什么样的结构。一个protocol buffer消息是一小片信息的逻辑记录，包含一系列的名称-值对。这里是一个非常基础的例子，他定义了包含个人信息的消息：
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
repeated PhoneNumber phone = 4;
}
可以看到，消息格式很简单 - 每个消息有一个或多个编号的字段，每个字段有一个名字和一个类型，类型可以是数字（整形或浮点），布尔，字符串，原生字节或是其他protocol buffer消息类型（如上例）。你可以指明可选字段，必选字段和重复字段。关于编写.proto文件的更多信息请见Protocol Buffer语言指导。
定义好消息后，就可以运行针对你的程序语言的protocol buffer编译器来编译.proto文件。这些类对每个字段提供简单存取器（例如query()和set_query()）和序列化整个结构到原生字节 或从原生字节解析结构的方法的。然后你可以在程序中用这个Persion类生成，序列化或者从protocl buffer消息中取得Person对象。你可能写这样的代码来操作：
Person person; person.set_name("John Doe"); person.set_id(1234); person.set_email("jdoe@example.com"); fstream output("myfile", ios::out| ios::binary); person.SerializeToOstream(&output);
然后你可以马上读回消息：
fstream input("myfile", ios::in| ios::binary); Person person; person.ParseFromIstream(&input); cout <<"Name: "<< person.name()<< endl; cout <<"E-mail: "<< person.email()<< endl;
你可以在消息中添加新的字段而不破坏向后的兼容性。老的程序在解析时简单的忽略新字段。所以如果你使用protocol buffers作为你的通讯协议的数据格式，你可以扩展你的协议而不用担心破坏既有的代码。
你可以在API参考找到使用生成的protocol buffer代码的完整的参考，在Protocol Buffer编码有更多关于protocol buffer消息如何编码的信息。
Why not just use XML?干嘛不直接用XML？
相较于XML，Protocol buffers在序列化结构化数据方面有许多优点。它:
- 更简单
- 3至10倍小
- 快20-100倍
- 更少的模糊性
- 对编程来讲，生成数据访问类更容易使用。
比如说，你想建模一个person，它有name和email。如果用XML，你需要写：
<person>
<name>John Doe</name>
<email>jdoe@example.com</email>
</person>
然而对应的protocol buffer消息（ protocol buffer 文本格式）是这样：
# Textual representation of a protocol buffer.
# This is *not* the binary format used on the wire.
person {
name: "John Doe"
email: "jdoe@example.com"
}
当这个消息被编码为二进制格式（文本格式）后，可能只有28字节长，并且解析只需要大约100-200纳秒。XML的版本至少69字节不包括空格，需要花费5,000-10,000纳秒解析。
Also, manipulating a protocol buffer is much easier:同样，操作protocol buffer也容易得多：
cout <<"Name: "<< person.name()<< endl; cout <<"E-mail: "<< person.email()<< endl;
而用XML你得这样写：
cout <<"Name: " << person.getElementsByTagName("name")->item(0)->innerText() << endl; cout <<"E-mail: " << person.getElementsByTagName("email")->item(0)->innerText() << endl;
然而，protocol buffers并不总是比XML好 - 例如，protocol buffers就不适合建模基于文本的有标记文档（如HTML），因为你很难在文字中插入结构信息。另外，XML是可读的并且易于手工编辑 的；protocol buffers，至少在原生格式上不是这样。XML还是（某种程度上）自描述的。而protocol buffer仅仅在你有关于它的定义文件（.proto文件）的时候才有意义。
听起来对我有用！我怎么开始用它？
下载软件包 - 它包含了Java, Python, C++的protocol buffers编译器的所有源代码，还有用于I/O和测试的类。构建和安装它的方法请参见附带的README。
这些准备好以后，你就可以试试看针对你使用的编程语言的教程，它将带你一步一步创建一个使用protocol buffers的简单应用。
一点历史
Protocol buffers最初是在Google开发出来处理一个索引服务器的request/response协议的。在protocol buffers以前，有一个手动marshalling/unmarshalling请求/响应的处理格式，结果是看起来非常丑陋的代码，就像：
if(version ==3){ ... }elseif(version >4){ if(version ==5){ ... } ... }
显式的格式化的协议也会把新版本协议的发布搞的很复杂，因为开发者必须保证在请求发起者和实际处理者这两端启用新协议之前，它们之间的所有的服务器，都必须理解新版本的协议。
Protocol buffers被设计来解决许多这样的问题：
- 新的字段可以很容易被引入，不需要检查新增数据的中间服务器可以像之前一样解析原有数据并一起传输他们，不需要知道新的字段。
- 格式是自描述的，可以被广泛的编程语言处理（C++, Java, 等）
然而，用户仍然需要手写他们自己的解析代码。
随着系统的进化，它已经有了一些其他特性和用途：
- 自动生成的序列化和反序列化代码，用户可以不用手工编写解析代码了。
- 除了被用作短期的RPC（远程过程调用）请求，人们开始用protocol buffers作为一种便利的自描述格式来持久化存储数据（比如Bigtable)。
- 服务器的RPC接口开始声明成为protocol文件的一个部分，还有protocol编译器生成的类，用户可以用实际的实现重写他们。
Protocol buffers现在是Google交流数据的主要交际语 - 撰写本文时，Google的代码树中有12,183个.proto文件，包含有48,162个不同的消息类型定义。它们被用在RPC系统和各种存储系统的数据的持久化的存储。
Popularity: 7% [?]
专家
一、不管别人提什么千奇百怪的问题，你都要回答：“这很正常。”这样做的好处是，既说明了自己见多识广，又能说明别人少见多怪，从而确立自己的专家地位。例如：有人问“为什么汶川地震，我们国家的地震局，没有任何的预测？”你可以说：“这很正常，地震预测是世界性难题。”有人问：“为什么地震中学校的校舍倒塌的那么多。”你可以说：“这很正常，地震的强度超过八级，所有的房屋都有倒塌的可能。”有人问：“为什么中国足球，搞了这么多年改革，现在连伊拉克都踢不过？”你可以说：“这很正常，因为足球比赛中有很多不确定因素。”有人问：“你为什么老是说这很正常？”你可以说：“这很正常，因为我是专家。”
二、要与正常人的见解有区别。专家之所以称为专家，就是要见人所未见，言人所未言。例如：有人说：“物价涨的太厉害了。”你要说：“不是物价涨，是中国的东西太便宜。”有人说：“股市跌得太厉害了，政府应该救市”你要说：“不行，要坚持中国股市的自由市场经济地位，避免政府对股市的干预。”有人说： “CPI增长了8.4%，活不了了。”你要说：“这样的物价水平，大多数人都能接受。”有人问：“你为什么我说东时，你总是说西？”你可以说：“这很正常，因为我要是也说东，你会要我说吗？”
三、分析问题原因的时候，要分出一二三四。这一点很重要，就算是一个原因，你也要分出一二三四来，这样做，才能显示你对问题确实有研究，不愧对专家的称号。如果说一二三四的同时，你还遵循了先世界后中国的顺序，那么你就可以成为著名专家了。例如，你可以说：“我分析汶川地震中校舍大量倒塌主要有三个原因：一从世界范围上来说，都存在地震中校舍倒塌的问题。例如美国……二是校舍倒塌，主要是因为地震的强度比较大。三校舍倒塌，也存在建筑不合格的可能。”你还可以说：“我分析这次发改委提高油价有三个原因：一主要是受国际上油价上涨的影响。二人民群众对柴油的求量增加。三石油生产企业的供应量减少。” 有人问：“你为什么总是用一二三四？”你可以说：“这很正常，你看到任何人用四三二一吗？”
四、要说那些别人听不懂或者听完之后就迷糊的话，而且自己懂不懂没关系。例如有人问：“中国平安为什么会推出如此庞大的融资计划？”你可以说：“股市最重要的功能之一就是再融资，从经济学的角度讲#￥……。”有人问：“你觉得中国楼价这么高正常吗？” 你可以说：“我们必须一分为二的看问题，虽然从某个角度来说，不正常，但是从社会学上来讲……”有人问：“为什么听完您的讲话，我有点困，还是不明白。” 你可以说： “恭喜你，犯困是正常的，表示你开始听懂我说的东西内其中的奥妙了，不明白是正常的，否则我还能算是专家吗！”
五、有两个最重要的原则，是保证你成为专家之后能在国家媒体上保持上镜率的关键：一要有大局观念。例如，你可以说：“虽然我们的法制法规还不太完善，但是目前我们国家在这一方面已经有了长足的发展……”你还可以说：“虽然地震不可预测，但是我们国家对于地震的科研工作还是相当的重视……”你甚至可以说：“虽然中国的专家都是事后诸葛亮，但是我们国家在这个问题上看到了许多打马后炮的优点……”二善于顾左右而言他。例如，你可以说：“对于你提到中国看病难的问题，美国也存在这样的问题。我记得德克萨斯州……”你可以说：“警察打人这样的事，只是警察队伍中个别人的个别问题，日本也有这样的情况，我记得在东京……” 有人问：“你为什么总是拿别国说事？”你可以说：“这很正常，你听过外国月亮比较圆吗？”
六、最后这招，是大家都熟悉的绝招了，那就是：只要在正常的浮动范围内、与世界接轨和中国特色。因为这是绝招，大家又是耳熟能详，所以在此，不再赘述。只举些例子：你甚至可以说：“一般而言，一个预测分析的可信度有三个看点：一从世界范围来看，专家的预测通常都有盲点，只要在正常的浮动范围内。二人民群众的智商明显提高，使得预测盲点有连成线的趋势，只要这个线的摆动在正常的浮动范围内。三有些个别专家，为了讨好人民需要，又将盲点由线扩大成面，别看这么大片面积，只要这个面在正常的浮动范围内，这些现象都算是正常的，这些预测都算是可信的。”碰到有人问：“你的这些预测跟我吓懵的有什么不一样，为什么你的工资这么高？”你可答：“ 与世界专家接轨。”那人再问：“为什么别的国家专家的预测和你的不一样？”你可答：“这是中国特色。”
综上所述，有此六技，则专家头衔可得矣！但是预防有人来踢馆时说：“你这专家狗屁不通。”你要会说：“起码我是吹牛皮，牛狗不同体，不通也是天然形成的，证明我是不可能放狗屁的。
Popularity: 8% [?]
one winged angel
The Black Mages系列，很强。
Estuans interius
Ira vehementi.
Estuans interius
Ira vehementi.
Sephiroth!
Sephiroth!
Estuans interius
Ira vehementi.
Estuans interius
Ira vehementi.
Sephiroth!
Sephiroth!
Sors immanis-
Et inanis.
Sors immanis-
Et inanis.
Estuans interius
Ira vehementi.
Estuans interius
Ira vehementi.
Sephiroth!
Sephiroth!
Veni, veni, venias,
Ne me mori facias.
Veni, veni, venias,
Ne me mori facias.
Veni, veni, venias,
Ne me mori facias.
Veni, veni, venias,
Ne me mori facias.
((At the same time, some others are singing:))
Gloriosa Generosa…
Gloriosa Generosa…
Gloriosa Generosa…
Gloriosa Generosa…
SEPHIROTH!
下载：Nobuo Uematsu - One-winged Angel
Popularity: 8% [?]
全国政协委员刘梦熊严正问责财政当局
我为人民鼓与呼
作者：香港特区全国政协委员刘梦熊
美国两家「巨无霸」抵押机构房利美和房地美崩盘引致的金融风暴震撼全球，各国股市插水式下跌。见惯风浪的金融大鳄索罗斯也惊呼是他「一生中最为严重的金融危机」。
令 人震惊的是，据通讯社报道，中国竟然是「两房」名列榜首的外国债权人，一共持有涉及该两间公司约三千七百六十三亿美元（相当于二万九千三百二十八亿港 元） 债劵，约占中国外汇储备总额百分之二十一！是另一个亚洲大国印度「两房」债劵持有量的一万六千倍！这简直是一件匪夷所思的天大丑闻！
笔者谨以全国政协委员和金融界人士身份质问中央财金当局有关拍板人：你们这班败家子哪里来这么大的胆子拿国家人民的钱，来买天文数字的「两房」股票！现在「两房」基本上已破产，你们如何向全国人民交代？
一个国家的外汇储备，并非这个国家的净资产，当外资热钱流走之时，外汇储备就会下降。所以外汇储备公认的投资原则是安全第一，分散为宜。由此观之，中国财金当局将外储的百分之二十以上浪掷于美国「两房」，是极其严重的错误：
第 一，十年前的亚洲金融风暴,香港和东南亚楼市崩溃，还闹出过「负资产」，业主和银行齐遭殃，说明房屋按偈本身风险很大，其衍生债劵更是「危险品」。中国竟 然将五分之一以上外储如此集中投向美国「两房」，谈何安全？谈何分散？第二，由于美国外贸赤字、财政赤字严重，美元长期处于弱势，此已属常识。而中国光是 向「两房」已投下相当于海内外给四川地震捐款一百多倍的外储，如此侧重美元资产，依据何在？眼光何在？如此离谱决策有没有黑幕，人大常委会应立即组织特别 调查组应予彻查，追究责任！
文章刊登于18/07/2008 东方日报 龙门阵 及 太阳报内。
Popularity: 8% [?]