The Mirages

2009年快过去了。
从年初的防止通货紧缩
到年底的通货膨胀
我也从上海来到了北京
年初冬季刚来过北京
4月就正式进驻了北京
一切变化的也太快了
从PP公司到了OO公司
一如既往的开始不适应
遥想在PP第一个礼拜
居然没有一个晚上睡好
而OO同样如此
加班从来不知道什么时候是结束
上班从来不知道什么时候是开始
貌似大家都很忙
其实装忙穷忙瞎忙
2009年房价从一个所谓的低谷到疯狂
人人都在谈论这个
其实对于我来说
无论是所谓的低谷还是疯狂
我都是三个字“买不起”
健康不健康国家会告诉你
2009年还学到了一词叫被XX
从被涨薪到被代表
毫无疑问我们生活在了被时代
好不容易到年底了
网络风暴开始了
接着扫黄打黑
我们的BT挂了
其实根本没有关系
BTCHINA只是一个供给页
BT精神是永远不会丢失的
有的只是技术的进步和提高
共享让我们提早进入了共产
4月跟着PP来到了厦门
一个美丽的海岛城市
挺好，很安逸也，只是担心台风
生活在鼓浪屿上的人们真是幸福
每年跟PP有个这样的回忆真好
只是下次只能用我的相机
或者直接上单反吧
2009年真是一个不平凡的一年
这一年我想到了要出国
还是感谢MARTIN的提醒
努力学习英文
可方法换了一个又一个
始终没办法提高
现在才明白坚持一个方法
勇敢的走下去才会成功
期待着2012年的到来
年末真的来了一部叫《2012》的片子
在第三排
看的很晃眼
希望在2012年自己真有个质的改变

《2012》看完也有一个多星期了，看的时候立刻让我想起的一首歌词是：“把每天当做末日来相爱。”
既然是最后了，那就干点自己想干的事情。
《2012》这个片子延续了导演以往的风格，当然这次加重了中国的戏份。而美国还是扮演世界警察的角色，就算他们总统不在了，任何一个美国人都能充当这个角色。《2012》不错的东西还是他的特技水平，看了这个还是之前的《后天》以及《指环王》系列，再看看国内的这些动画片，首先基本都是2D水平，其次所有动作看着都非常假，这方面我也不是太懂。但是80年代我们的《西游记》那么成功，那么有水平，难道我们现在还落后了不是。再说我们的计算机的计算能力在世界上也是仅次于美国的，按理硬件落后不是理由，《西游记》的时候我们计算机水平落后到不知道在哪里呢，但是特技效果现在看来还是非常不错。
国际分账大片在国内运营也有很多年了，从1995年的《亡命天涯》到具体也有14年时间了。我们的电影制作水平在某些方面确实有了大步的提高，基本都是大成本，大明星，大制作，高票房的模式，这个时候我们是否还要注重下低成本，小制作的片子，电影的火花应该是这种片子吧。就跟《疯狂的石头》一样。现在国产电影越来越没故事情节了，除了大波波还是大波波。
所以说无论做什么事情外部条件都不是做不完美的理由。
假如我到了最后一天，我会去做什么事情把它做完美呢，感觉工作上似乎没有我特别想做的完美了，完了这个要是让我雇主看到了，他还会要不要我呢？ 想做的事情就是陪着老婆看星星，最好能够爬到西山顶上能够守在一起看着星星。哎，经常回想起在公司望着太阳在西山落下，真是太美了，要是能够在西山顶上看着太阳落山，又能在万里无云的夜晚看到那么多星星，那真是太完美了。虽然我基本不知道大部分星星的名字，可那又有什么关系呢。

看完北京台《蜗居》已经挺久了，一直想写个观后感，但是不知道从何入手。想不到现在这个片子还听热门。
热门只是因为有个比较好的话题房子而已，而其他什么最流氓的电视剧，这些纯粹是瞎扯淡，难道是仅仅因为宣传的噱头。
这个片子我觉得最混蛋的是海藻的姐姐海萍，为了自己的房子居然把自己的妹妹最终推向了那个火坑。而等有了自己的房子后又像一个救世主一样来进行说教。房子毁了可不仅仅是2个家庭。
现在魔都和帝都的房价已经涨的没人能够看懂了，小时候我们学过国民党统治区物价飞涨，民不聊生，现在都已经活生生的出现在我们面前了。
去年年底是一个房价的低点，由于外部金融危机造成的，就是这个时候国家鼓励大家买房子，现在很多人后悔当时没听国家的没买房子，而现在又涨起来了。其实都是他们自己造成的，到今年2月临涨前其实很多KFS已经撑不下去了，可由于我们的不团结，很多看到低一点就开始抢购了，而人类的从众意识导致了这个一发不可收拾，其实要是我们再坚持1年不买，那现在估计上海内环房价已经4K-6K了。
专家每天都在说刚性需求，然后又出来丈母娘需求，现在又出来毕业生需求，其实都是政府自己定义的需求，我们这些傻蛋都被晃进去了。
所以我们千万别指望国家主动来调房价，无论哪个市长市委书记说，那都是空谈。他们都是同一链条上的。

这次饥渴大会已经是公司的第二届了，这次也是本人第一次参加饥渴大会，来了500多人，所以只能上城堡里开这种大会。
饥渴来自于英文geek，没有办法，老板喜欢geek这个单词，boss从MIT出来的，所以很喜欢当饥渴。当然这种大会感觉就是吹牛和黄色笑话大会。
2个主持人一个是鸡一个是客，老板坐飞机叫打飞机。所以你真想从这种大会学到什么的话，那就多认识点各个不同部门的人，不过很不幸，主持人种的鸡就是本来就认识的，当然几乎全公司都认识这位老兄。
黄晶黄老大介绍了一下校外网的整个架构，从硬件架构和软件架构，不过其实怎么样之前大家应该都是知道的，但是为什么选择这种架构还是想听听的。比如baidu选择了这个，为什么我们没有选择那种硬件架构，这个没有说明原因，还是比较遗憾，而且最后也没有轮到同一桌吃饭，没法更深入的探讨。
后面那位老兄的memcached的扩展其实也是挺有意思的，amazon能够发布那个paper也算是给大家普及了这个知识，但是发现mixi.jp其实很早就用了这种计算，memcached集群以及如何减少之间的开销。但是老兄的演讲很多人都明白，老兄还是得多锻炼锻炼口才才行。虽然自己明白了，但是得让大家明白了。
当然我们作为万像公司的神秘部门，很多还是需要保密的，就算去领奖也要保密在干嘛。当然虽然很多东西都是学习校外网的，但是我们其实也是开创了自己很多的内容。

以前在公司吃加班餐，总喜欢坐在朝西的一个高脚凳上吃，向西看去，群山被夕阳笼罩着，橘红橘红的。感觉这些山都被融化了一样。这种感觉真是让人向往，我不知道加入我被这夕阳笼罩的时候会是怎样。要是每天都生活在这样的场景是多好啊。
坐在300路上，这个北京最著名的公交车上，每天下班都是由东往西开着，上车时候还是夕阳笼罩，等下车的时候是夕阳伴随着橘红色的路灯。回家的路总是走的特别快。
在上海的，经常下班的时候还是天亮的，但是从地铁出来的时候天色已经黑了，也没有那么高可以远眺。在上海都是建筑森林，你根本不可能远眺。

习惯了windows上vmware server，这个东西是免费的，还是挺好用的。看了下发现vmware sever还有linux版本的。下载了vmware server2.0版本的。汗，直接下载的是tar包的，以为也是用

1

./configure && make && make install

来安装的。不过解压开来发现还是给你了一个安装脚本，是一个perl的脚本。5800多行的perl脚本，还好执行效率很高。
全部都是默认安装。安装完成后直接打vmware就可以启动了，不想用https登录，那就用 http://xxxx:8222 登录就可以了。第一次用web登录的，以前windows下都不是web方式的。这里的用户是root，如果你是默认安装的话，密码就是系统的root帐户的秘钥。
安装完成后要进行2个设置，一个是add datastore,这个最好是你自己目录下的分区。还有一个是要安装firefox插件:vmware remote console plug-in。这些设置完成后就跟普通版本的vmware相同方式使用了。
哈哈，下了个gentoo dvd版本用着，真是不错。
linux版本的vmware居然还提供了卸载脚本，真是贴心阿：vmware-uninstall.pl

在urchin显示的内容优化–最常见内容中默认是不带有域名的。例如
www.abc.com/test.html这里就只显示test.html，而万一我有test.abc.com/test.html那我就搞不清楚到底哪个是www子域名下的，哪个是test子域名下的。为了解决问题查看了urchin的帮助文档，居然还有现成的。
https://secure.urchin.com/helpwiki/cn/How_do_I_track_all_of_the_subdomains_for_my_site_in_separate_profiles%3F

 Filter Type: Custom filter > Advanced Field A: cs_host (Raw) Extract A: (.*) Field B: Request_Stem (Auto) Extract B: (.*) Output To: Request_Stem (Auto) Constructor: /$A1$B1 

但是实际使用中却始终无法正常显示出来。为了解决这个问题无奈只好一个个查看urchin各个字段的解释。在http://www.google.com/support/urchin45/bin/answer.py?answer=28623&topic=7396你可以看到所有字段的解释

因为既然urchin能够获取主机名，那这里肯定也是可以显示的。最后解决问题的方法是：

 Filter Type: Custom filter > Advanced Field A: utm_request_hostname (AUTO) Extract A: (.*) Field B: Request_Stem (Auto) Extract B: (.*) Output To: Request_Stem (Auto) Constructor: $A1$B1 

然后必填字段A 选择是，必填字段B选择否，覆盖输出字段选择是，区分大小写选择否。

在linux中我們可以設置密碼最短為多少，只需要修改/etc/login.defs文件中的PASS_MIN_LEN 參數就可以了。
但是最近我發現了另外一個問題，我明明設置了10幾位的密碼，但是最終系統登錄的時候只是查看前面的8位。查找了半天原因，原來是/etc/pam.d/system-auth的問題。
在老的版本默認password居然是使用shadow進行驗證的。而它所使用的算法是DES加密算法，這是一種64位加密算法，只能識別到前面八位。修改方法就是把system-auth修改成如下形式：

 #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session \[success=1 default=ignore\] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so 

這個修改完成后理論上是立刻生效的。但是我在實際使用過程中發現還是要把所有密碼重新設置一遍才會生效。
其實也可以通過修改/etc/pam.d/login來解決的，但是很多pam其實最終都是調用的system-auth的，所以修改system-auth還是一個比較好的方式。

最近由於升級服務並且涉及到域名的更改，架構也同時進行升級。
首先碰到的一個問題，用戶在輸入老的域名比如www.abc.com，雖然我在DNS上做了CNAME, www IN CNAME www.cba.com.
但是用戶在輸入www.abc.com后在流覽器地址欄中還是原來的www.abc.com，雖然也能正常訪問新網站，但是這樣用戶體驗并不特別好。
所以在用戶輸入www.abc.com按回車后直接在流覽器地址欄中變為www.cba.com。這樣應該是讓用戶更接受新的域名。在這之前我一般都是通過程序文件來執行的，但是這裡都是JSP

文件，對於這個實在不擅長了，所以想直接用nginx來進行實現了。結果還真是成了。
在nginx的location部份添加以下內容就可以了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

 if ( $host ~* (.*).(abc).(com)) { set $domain $1; rewrite ^(.*) http://$domain.cba.com$1 permanent; } 
```  
解釋一下 (.*)表示任何二級域名，abc.com表示原來的域名。.表示轉移為.這個標點符號。 set $domain $1， 這個$domain表示是二級域名的變量，$1表示abc.com後面接著的地址。rewrite部份就十分好理解了。需要更進一步學習就只能看[http://wiki.nginx.org/NginxHttpRewriteModule](http://wiki.nginx.org/NginxHttpRewriteModule)  
  
  
由於使用nginx作為代理轉發器，所以對nginx的upstream和proxy也更多了瞭解。在upsteam中我們可以設置多個機器的不同權重以及失效的時間。但是在實際測試中發現，由於後端機器不夠穩定，出現404或者503，502這種情況，這個時候Nginx也會轉發到這個機器上，這樣用戶體驗會非常不好。  
放狗找了下，還真給找到了解決方法。  
在location部份加上  
```c
 proxy_next_upstream error timeout invalid_header http_500 http_503 http_404; 
```  
這樣一句。這樣後端一台機器出現500，503，404等錯誤的時候也就會  
  
轉發到其他機器上了。這樣用戶體驗就會更好一點。  
  
nginx還有一個需要手動添加的模塊NginxHttpUpstreamFairModule，這個需要自己編譯的時候通過--add-module=來手動添加進來。這個模塊的作用其實可以把用戶的請求發送到後  
  
端負載最輕的機器上。只需要在upstream中這樣修改就行：  
```c
 upstream www { fair; server 10.2.9.99:9090 weight=1; server 10.2.8.227:8080 weight=5; }