吉野家抽奖得了“中牛肉饭＋中可/汤 ¥15.5”来兑奖，原来是以¥15.5买中碗牛肉饭＋可乐。没什么好解释的，这是我最后一次吃吉野家，永远不会再吃这家店了。
2010年4月7日星期三
如何利用google buzz作为blog服务器
如何使用google buzz作为blog服务器
可实现的功能：
1。email发贴
2。feed的无缝切换
3。twitter提醒操作过程中需要翻墙操作
step1. 申请一个全新的gmail帐户：https://gmail.com
step2. （此处需要翻墙）新的gmail帐户申请开通一个blogger帐户。https://www.blogger.com
step3. 从gmail帐户中选择buzz的设置，帮定blogger帐户
step4. （此处需要翻墙）从一个常用邮箱申请一个posterous.com的帐户
step5. （此处需要翻墙）绑定posterous.com和blogger帐户
step6. 获得buzz的rss: http://buzz.googleapis.com/feeds/{username}/public/posted
可实现的功能：
1。email发贴
2。feed的无缝切换
3。twitter提醒操作过程中需要翻墙操作
step1. 申请一个全新的gmail帐户：https://gmail.com
step2. （此处需要翻墙）新的gmail帐户申请开通一个blogger帐户。https://www.blogger.com
step3. 从gmail帐户中选择buzz的设置，帮定blogger帐户
step4. （此处需要翻墙）从一个常用邮箱申请一个posterous.com的帐户
step5. （此处需要翻墙）绑定posterous.com和blogger帐户
step6. 获得buzz的rss: http://buzz.googleapis.com/feeds/{username}/public/posted
比如我的http://buzz.googleapis.com/feeds/goldengrapeblog/public/posted
step7. 使用feedsky或者feedburner烧制feed
step8. （此处需要翻墙）将烧制好的feed自动导入到twitter中
step9. 用自己常用的gmail帐户follow这个blog gmail帐户。这是一个最为繁复的过程，其实中间有多个步骤是多余的，只是为了满足我的洁癖而已。新建一个gmail是因为我希望把blog和日常生活分开。通过email转发发贴，是因为在同一台电脑上反复切换gmail帐户很麻烦。发贴过程可以通过常用的email客户端向post@posterous.com发送email即可。比如手机或者台式机上。之所以通过一次posterous中转，是因为这样把邮件地址放置在手机地址簿中也不会暴露任何密码字。 buzz上的内容虽然是从blogger中导入的，但是烧制的feed中指向的是buzz的地址，而不是blogger的地址，于是可以不用翻墙就可以访问。同时由于需要翻墙才能去blogger上留言，所以大多数人会在buzz上留言，使回复趋于集中。虽然posterous能够同时绑定twitter，但是那样的话短链接是指向posterous的，需要翻墙才能访问。在twitter上的更新通知还是用最终烧制好的feed比较好。 新申请的blog gmail帐户基本上可以不需要登陆察看。是一个只进不出的帐户。buzz提供的rss不具备全文输出。一定程度上不友好，但是同时也保护了feed服务商，因为面向读者的是不变的feed地址。一旦这个被关掉，最主要的读者群就要重新联系了。
step7. 使用feedsky或者feedburner烧制feed
step8. （此处需要翻墙）将烧制好的feed自动导入到twitter中
step9. 用自己常用的gmail帐户follow这个blog gmail帐户。这是一个最为繁复的过程，其实中间有多个步骤是多余的，只是为了满足我的洁癖而已。新建一个gmail是因为我希望把blog和日常生活分开。通过email转发发贴，是因为在同一台电脑上反复切换gmail帐户很麻烦。发贴过程可以通过常用的email客户端向post@posterous.com发送email即可。比如手机或者台式机上。之所以通过一次posterous中转，是因为这样把邮件地址放置在手机地址簿中也不会暴露任何密码字。 buzz上的内容虽然是从blogger中导入的，但是烧制的feed中指向的是buzz的地址，而不是blogger的地址，于是可以不用翻墙就可以访问。同时由于需要翻墙才能去blogger上留言，所以大多数人会在buzz上留言，使回复趋于集中。虽然posterous能够同时绑定twitter，但是那样的话短链接是指向posterous的，需要翻墙才能访问。在twitter上的更新通知还是用最终烧制好的feed比较好。 新申请的blog gmail帐户基本上可以不需要登陆察看。是一个只进不出的帐户。buzz提供的rss不具备全文输出。一定程度上不友好，但是同时也保护了feed服务商，因为面向读者的是不变的feed地址。一旦这个被关掉，最主要的读者群就要重新联系了。
2010年4月5日星期一
清明节的生命力
一个节日的生命力，其中之一要看以它作为题材能够带动多少消费。比如圣诞节，美国圣诞节大街上冷冷清清，堪比中国大年初一，在中国圣诞节则是购物狂欢party，过圣诞节的人远远要多于信耶稣的人，仅仅是因为那是一个购物打折的题材。 清明节就显得很尴尬。清明节的购物仅仅是些冥币纸钱之类，最多不过是鲜花。人们也不会互祝清明节快乐，毕竟是一个寄托哀思的日子。我估计清明节放假的规矩坚持不了几年。很可能会被母亲节或者父亲节所替代。 清明节之所以能够维持，重要的原因是因为它起到联系家族的作用。人们祭祀共同的祖先，不到的会受到来自家族的压力。 可以看出推动人类行为周期进行的两大动力：商业活动和人际关系。要使一个活动传播开，一方面要让大家借这个活动有钱赚，另一方面要把更多的人拉入到这个活动中。 清明节作为一个怀念的日子，除了怀念亲人，许多历史事件也会产生出许多被怀念的人们。纪念这些人，也就意味着不去忘记那些历史事件。历史事件的日子往往随机分布于各个日期，导致很多日期已经从日历上被划掉了。显然，每划掉一个日期，这个日期无处安身，就会躲到清明节这一天。 所以，清明节一是不能用来赚钱，二是会引起一些纪念活动。所以清明节是长不了的。清明节就快死了。
2010年4月1日星期四
将buzz作为新的blog服务器。
我又更换blog了。https://www.google.com/profiles/goldengrapeblog#buzz
其实就是一个叫做goldengrapeblog的google buzz页面 我又重新申请了一个google buzz账户，专门用来贴blog。你可以选择关注我。我只用这个buzz发布blog，一个月也不会超过5－6篇，还是在勤快的情况下，应该不会对您造成太大的阅读压力。有啥想在blog里说的，你还可以在buzz上直接说。不用太担心墙的阻隔，因为你可以在gmail中用https来访问。日后有大量api发布时，应该还可以通过第三方的软件或者网页访问。 去年自己购买了一个域名：http://goldengrape.org 借助数字游牧的帮助，建立了自己的独立blog。用起来真是感觉非常自由。可惜好景不长，过了大半年，就被挡在墙外面了。 一开始倒是并不在意，不就是翻墙么，反正看我blog的人大多把翻墙当做跨个台阶而已。 慢慢的，发觉不是这样，一方面翻墙的动作越来越复杂。一方面，持续性的一个小障碍使我的惰性增长起来，加上twitter的协同作用，blog逐渐开始荒废起来。对作者是如此，对读者亦是如此，反正在google reader之类的地方也可以看，谁会为留个言而专门架起翻墙工具呢。缺乏读者的反馈，我这个作者的动力也有所降低。 实际上，看我blog的人，大部分不是直接去网页上看，而是从rss阅读器中阅读，那么更换个blog服务商对我的读者而言影响并不大。我只需要在后台把rss地址修改了就是了。在rss阅读器中基本是无缝连接，顶多是在切换的时候可能突然出现过多的未读条目。如果这次也有的话，致歉。至于文章的备份，一般我会在email或google docs中撰写，至少近半年的会有备份。 但是更换blog服务商最麻烦的就是丢失了读者的留言。每一次更换服务商就丢失和读者的互动，虽然不多，但却是读者存在的证明。 之前的方案是自己把blog贴到各处：自己买的独立blog，blogbus上，甚至开心网。当然这个过程是有选择的，有些文章放在独立blog上，有些放在国内。所以有“金色葡萄的精华区”和“金色葡萄的国内精华区”之分。 然后，在google reader中我会再推广一下我的文章，现在由于blogger和reader都与buzz相关联，于是这些blog又会出现在buzz里。 不过我不喜欢这样。buzz里更多的联系者是比较熟悉的人。我觉得还是把网络身份与实际身份分开比较好。blog没人理不好，说点什么身边的人都在讨论也不舒服。 我又重新申请了一个google buzz账户，专门用来贴blog。你可以选择关注我。我只用这个buzz发布blog，一个月也不会超过5－6篇，还是在勤快的情况下，应该不会对您造成太大的阅读压力。有啥想在blog里说的，你还可以在buzz上直接说。不用太担心墙的阻隔，因为你可以在gmail中用https来访问。日后有大量api发布时，应该还可以通过第三方的软件或者网页访问。 慢慢的，技术的进步就会保护我们的言论自由。甚至，没有人需要去冒任何风险来捍卫我说话的权力，因为我的话语已经不可能被阻挡。
其实就是一个叫做goldengrapeblog的google buzz页面 我又重新申请了一个google buzz账户，专门用来贴blog。你可以选择关注我。我只用这个buzz发布blog，一个月也不会超过5－6篇，还是在勤快的情况下，应该不会对您造成太大的阅读压力。有啥想在blog里说的，你还可以在buzz上直接说。不用太担心墙的阻隔，因为你可以在gmail中用https来访问。日后有大量api发布时，应该还可以通过第三方的软件或者网页访问。 去年自己购买了一个域名：http://goldengrape.org 借助数字游牧的帮助，建立了自己的独立blog。用起来真是感觉非常自由。可惜好景不长，过了大半年，就被挡在墙外面了。 一开始倒是并不在意，不就是翻墙么，反正看我blog的人大多把翻墙当做跨个台阶而已。 慢慢的，发觉不是这样，一方面翻墙的动作越来越复杂。一方面，持续性的一个小障碍使我的惰性增长起来，加上twitter的协同作用，blog逐渐开始荒废起来。对作者是如此，对读者亦是如此，反正在google reader之类的地方也可以看，谁会为留个言而专门架起翻墙工具呢。缺乏读者的反馈，我这个作者的动力也有所降低。 实际上，看我blog的人，大部分不是直接去网页上看，而是从rss阅读器中阅读，那么更换个blog服务商对我的读者而言影响并不大。我只需要在后台把rss地址修改了就是了。在rss阅读器中基本是无缝连接，顶多是在切换的时候可能突然出现过多的未读条目。如果这次也有的话，致歉。至于文章的备份，一般我会在email或google docs中撰写，至少近半年的会有备份。 但是更换blog服务商最麻烦的就是丢失了读者的留言。每一次更换服务商就丢失和读者的互动，虽然不多，但却是读者存在的证明。 之前的方案是自己把blog贴到各处：自己买的独立blog，blogbus上，甚至开心网。当然这个过程是有选择的，有些文章放在独立blog上，有些放在国内。所以有“金色葡萄的精华区”和“金色葡萄的国内精华区”之分。 然后，在google reader中我会再推广一下我的文章，现在由于blogger和reader都与buzz相关联，于是这些blog又会出现在buzz里。 不过我不喜欢这样。buzz里更多的联系者是比较熟悉的人。我觉得还是把网络身份与实际身份分开比较好。blog没人理不好，说点什么身边的人都在讨论也不舒服。 我又重新申请了一个google buzz账户，专门用来贴blog。你可以选择关注我。我只用这个buzz发布blog，一个月也不会超过5－6篇，还是在勤快的情况下，应该不会对您造成太大的阅读压力。有啥想在blog里说的，你还可以在buzz上直接说。不用太担心墙的阻隔，因为你可以在gmail中用https来访问。日后有大量api发布时，应该还可以通过第三方的软件或者网页访问。 慢慢的，技术的进步就会保护我们的言论自由。甚至，没有人需要去冒任何风险来捍卫我说话的权力，因为我的话语已经不可能被阻挡。
2010年3月31日星期三
旧文重贴，测试新blog空间用，《CODE WAR》
节选自《未来计算机史，GFW CODE WAR卷》 前言： 史学界常把公元2009年作为GFW CODE
WAR的起点。在此之前，虽然对抗GFW的行动从来没有停止过，但基本上是依靠比较大型的商业软件或者开源软件，个人仅作为使用者参与。而从这一年起接连涌现出的多种工具，例如GAppProxy,dabr,twit
api等，使个人依照简单的教程就可以搭建私有的抗GFW工具。个人不但能够简单的获得抗GFW工具，也同时能够向周围的人提供这些工具和服务。即所谓用户创造服务，UCS。 GFW所面对的不再是一个网站或者IP，而是一类云计算服务，基于这样云计算的服务器却是去中心的分布的。从某种程度上来说，GFW作为墙（wall）已经开始失效。 英雄们手中拿着的不再是弓弩，而是键盘，发出的不再是利箭，而是代码。博客们代替了诗人传诵他们的故事。曾经的同门可能站到了墙的两侧。曾经的师生可能成了对手。矛盾以新的形式展开了，这就是代码战争。 。。。。。。 … “随着第一次GFW code war的进行，网络中逐渐出现了API层，为后来…的发展打下了基础” 并不是所有的网站都提供了API，其实所谓的API就是应用程序的界面，是通过程序来访问网站进行操作。那么既然网站都是设计给用户进行操作的，只要通过程序模拟用户的操作过程，就成了API。 … “API层的出现模糊了调用函数时本地和云端之间的差别，但同样由于GFW，API的地址经常变化，深入程序内部更改并不经济，因此出现了API
host list从外部映射API函数名和地址” … “只要有模式就可能被识别，虽然api层使api级连无处不在，但api必须和本地相交互，于是模式出现了，GFW开始派出自己的爬虫，新的战役打响了” … “只要有模式就可能被识别！需要隐藏的模式必须和其他模式相似。拟态！镜像、API甚至代理都是URL的拟态。为了拟态各种API逐渐相似起来。因此正是GFW
code war促成了API形式标准的统一。。” … “api的自我保护起始于门锁机制，只有用私钥事先打开才能接触到其后的api层。于是api层的模式被隐藏了起来，但门锁本身也是很显眼的，没有什么比一个wordpress的登陆界面更合适的伪装了。。”
。。。。。。 技术本身无所谓善恶。战争本身就是科技发展的动力之一。 ===2010年更新===
西厢计划的出现是具有标志性意义的。
WAR的起点。在此之前，虽然对抗GFW的行动从来没有停止过，但基本上是依靠比较大型的商业软件或者开源软件，个人仅作为使用者参与。而从这一年起接连涌现出的多种工具，例如GAppProxy,dabr,twit
api等，使个人依照简单的教程就可以搭建私有的抗GFW工具。个人不但能够简单的获得抗GFW工具，也同时能够向周围的人提供这些工具和服务。即所谓用户创造服务，UCS。 GFW所面对的不再是一个网站或者IP，而是一类云计算服务，基于这样云计算的服务器却是去中心的分布的。从某种程度上来说，GFW作为墙（wall）已经开始失效。 英雄们手中拿着的不再是弓弩，而是键盘，发出的不再是利箭，而是代码。博客们代替了诗人传诵他们的故事。曾经的同门可能站到了墙的两侧。曾经的师生可能成了对手。矛盾以新的形式展开了，这就是代码战争。 。。。。。。 … “随着第一次GFW code war的进行，网络中逐渐出现了API层，为后来…的发展打下了基础” 并不是所有的网站都提供了API，其实所谓的API就是应用程序的界面，是通过程序来访问网站进行操作。那么既然网站都是设计给用户进行操作的，只要通过程序模拟用户的操作过程，就成了API。 … “API层的出现模糊了调用函数时本地和云端之间的差别，但同样由于GFW，API的地址经常变化，深入程序内部更改并不经济，因此出现了API
host list从外部映射API函数名和地址” … “只要有模式就可能被识别，虽然api层使api级连无处不在，但api必须和本地相交互，于是模式出现了，GFW开始派出自己的爬虫，新的战役打响了” … “只要有模式就可能被识别！需要隐藏的模式必须和其他模式相似。拟态！镜像、API甚至代理都是URL的拟态。为了拟态各种API逐渐相似起来。因此正是GFW
code war促成了API形式标准的统一。。” … “api的自我保护起始于门锁机制，只有用私钥事先打开才能接触到其后的api层。于是api层的模式被隐藏了起来，但门锁本身也是很显眼的，没有什么比一个wordpress的登陆界面更合适的伪装了。。”
。。。。。。 技术本身无所谓善恶。战争本身就是科技发展的动力之一。 ===2010年更新===
西厢计划的出现是具有标志性意义的。
订阅：
博文 (Atom)