C1G军火库

2. iostat 结果解析

# iostat -x
Linux 2.4.21-9.30AX (localhost) 2004年07月14日

avg-cpu: ％user ％nice ％sys ％idle
3.85 0.00 0.95 95.20

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm ％util
/dev/hda 1.70 1.70 0.82 0.82 19.88 20.22 9.94 10.11 24.50 11.83 57.81 610.76 99.96
/dev/hda1 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.00 12.92 0.00 10.77 10.77 0.00
/dev/hda5 0.02 0.00 0.00 0.00 0.03 0.00 0.02 0.00 6.60 0.00 6.44 6.04 0.00
/dev/hda6 0.01 0.38 0.05 0.03 0.43 3.25 0.21 1.62 46.90 0.15 193.96 52.25 0.41
/dev/hda7 1.66 1.33 0.76 0.79 19.41 16.97 9.70 8.49 23.44 0.79 51.13 19.79 3.07

rrqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s: 每秒读扇区数。即 delta(rsect)/s
wsec/s: 每秒写扇区数。即 delta(wsect)/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。
wkB/s: 每秒写K字节数。是 wsect/s 的一半。
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。即 delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
％util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。
即 delta(use)/s/1000 (因为use的单位为毫秒)

如果 ％util 接近 100％，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘
可能存在瓶颈。

svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，
svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多
也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及
I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明
I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用
得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑
更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。

队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是
按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。
3. I/O 系统 vs. 超市排队

举一个例子，我们在超市排队 checkout 时，怎么决定该去哪个交款台呢? 首当
是看排的队人数，5个人总比20人要快吧? 除了数人头，我们也常常看看前面人
购买的东西多少，如果前面有个采购了一星期食品的大妈，那么可以考虑换个队
排了。还有就是收银员的速度了，如果碰上了连钱都点不清楚的新手，那就有的
等了。另外，时机也很重要，可能 5 分钟前还人满为患的收款台，现在已是人
去楼空，这时候交款可是很爽啊，当然，前提是那过去的 5 分钟里所做的事情
比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。

I/O 系统也和超市排队有很多类似之处:

r/s+w/s 类似于交款人的总数
平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
I/O 操作率 (％util)类似于收款台前有人排队的时间比例。

我们可以根据这些数据分析出 I/O 请求的模式，以及 I/O 的速度和响应时间。
4. 一个例子

# iostat -x 1
avg-cpu: ％user ％nice ％sys ％idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm ％util

/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

 

上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: delta(io)/s = r/s +
w/s = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。

平均每次设备 I/O 操作只需要 5ms 就可以完成，但每个 I/O 请求却需要等上
78ms，为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个)，假设这些请求是
同时发出的，那么平均等待时间可以这样计算:

平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + … + 请求总数-1) / 请求总数

应用到上面的例子: 平均等待时间 = 5ms * (1+2+…+28)/29 = 70ms，和
iostat 给出的 78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。

每秒发出的 I/O 请求很多 (约 29 个)，平均队列却不长 (只有 2 个 左右)，
这表明这 29 个请求的到来并不均匀，大部分时间 I/O 是空闲的。

一秒中有 14.29％ 的时间 I/O 队列中是有请求的，也就是说，85.71％ 的时间里
I/O 系统无事可做，所有 29 个 I/O 请求都在142毫秒之内处理掉了。

delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =
78.21 * delta(io)/s = 78.21*28.57 = 2232.8，表明每秒内的I/O请求总共需
要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23，而 iostat
给出的平均队列长度 (avgqu-sz) 却为 22.35，为什么?! 因为 iostat 中有
bug，avgqu-sz 值应为 2.23，而不是 22.35。
以下为服务器情况

bbs(scsi 74G)
top - 17:06:00 up 61 days, 11 min,  3 users,  load average: 3.98, 3.72, 3.53
Tasks: 250 total,   3 running, 247 sleeping,   0 stopped,   0 zombie
Cpu(s): 15.4% us,  3.7% sy,  0.0% ni, 74.6% id,  6.2% wa,  0.1% hi,  0.0% si
Mem:   2073976k total,  1922724k used,   151252k free,    36372k buffers
Swap:  2040244k total,    46416k used,  1993828k free,  1007456k cached
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          15.17    0.00    3.65    6.21    0.00   75.02
 
Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.13    55.67   12.19   30.50   215.93   690.06    21.22     0.17    3.93   5.22  22.30
search1(sata 80G)
top - 17:06:32 up 4 days,  4:31,  2 users,  load average: 1.02, 1.31, 1.19
Tasks:  86 total,   1 running,  85 sleeping,   0 stopped,   0 zombie
Cpu(s): 32.3% us,  0.9% sy,  0.0% ni, 62.2% id,  4.2% wa,  0.2% hi,  0.2% si
Mem:   2074476k total,  2060532k used,    13944k free,   260740k buffers
Swap:  4096532k total,    16264k used,  4080268k free,   159984k cached
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.00    0.00    1.62    5.80    0.00   84.02
 
Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
hda               0.05    35.22   18.19   12.87   189.80   384.73    18.50     5.59  179.86   7.44  23.12

search2(scsi 74G *2 )
top - 17:07:15 up 17 days, 21:34,  2 users,  load average: 2.21, 2.78, 2.82
Tasks: 155 total,   1 running, 154 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.2% us,  4.7% sy,  0.0% ni, 77.7% id,  4.0% wa,  0.0% hi,  0.3% si
Mem:   2074936k total,  2003708k used,    71228k free,    74260k buffers
Swap:  2031608k total,   342032k used,  1689576k free,   197840k cached
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          21.67    0.00    6.25    4.39    0.00   67.94
 
Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.03     6.66    1.77    2.68    86.44    75.11    36.32     0.13   29.63   4.83   2.15
sdb               0.29    69.29   29.10   13.90   340.41   665.65    23.40     0.62   14.43   4.33  18.64

www (sas 15K 146G *2 raid 1)
top - 17:07:56 up 17 days, 20:33,  1 user,  load average: 0.16, 0.27, 0.26
Tasks: 161 total,   1 running, 160 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.1%us,  0.2%sy,  0.0%ni, 98.2%id,  0.4%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   8174384k total,  8113268k used,    61116k free,   277316k buffers
Swap:  8191992k total,      140k used,  8191852k free,  6900728k cached
 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.00    0.00    0.79    0.22    0.00   97.09
 
Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.13    31.81    0.41    8.54    19.85   322.79    38.32     0.58   64.46   2.50   2.24
dm-0              0.00     0.00    0.01    3.92     0.40    31.39     8.08     0.19   47.19   1.44   0.57
dm-1              0.00     0.00    0.46   34.35    18.40   274.76     8.42     1.14   32.63   0.53   1.85
dm-2              0.00     0.00    0.00    0.23     0.00     1.82     8.00     0.01   31.41   8.79   0.20
dm-3              0.00     0.00    0.06    0.57     1.00     4.53     8.89     0.02   35.87   3.40   0.21
dm-4              0.00     0.00    0.00    0.00     0.01     0.02     8.00     0.00   15.83   0.35   0.00
dm-5              0.00     0.00    0.00    1.28     0.04    10.27     8.00     0.16  125.45   0.08   0.01

参考:http://blog.chinaunix.net/u/27493/showart.php?id=498055

via Tsung’s Blog

从 Tsung’s Blog 上看到这篇东西，发现里面的一些格言实在太经典、太贴切了！我觉得这个应该是和技术相关的，贴在这里，估计有共鸣的人应该很多。:)

先摘录几个经典的（做了小幅修改，替换了一些繁体术语）：

要殺一個程式設計師不需要刀，改三次需求就好

程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者，不可能以這樣的工期實現這樣的需求。
修改需求是對奇蹟吐槽的亵渎行為。
而追加修改則是相信奇蹟還會重現的無謀行動。

追加需求確定後交貨期限就無法確定，
交貨期限確定後追加需求就無法確定。
這稱為「追加需求與交貨期限的測不準原理」。

原文出处：程式設計師的格言 « but, or bug
——————————————————————————

程式設計師的格言（盜作不少）

譯自

* プログラマーの格言（盗作多し）
* http://mixi.jp/view_community.pl?id=1772737

(版本2 2008/10/12更新)

譯註

* SE是日本軟體公司裡程式設計師的頭子。自己不太寫程式，主要工作是跟客戶確認規格。
* 程式設計師多半自己不面對客戶。
* 跟PM又不一樣。（有什麼比較貼切的職稱翻譯嗎？）

1. 每天有24小時。
所謂的「今天之內」，是指到明天早上為止。
2. 程式不會照自己所想的跑。只會照所寫的跑。
3. 需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。
4. 我對軟體設計的方式導出的結論，有兩種方式。
一是把軟體設計得單純到很明顯不會有缺陷，
不然就是把軟體設計得複雜到沒有明顯的缺陷。
- C.A.R.Hoare
5. 程式碼不要在開發現場寫！ 去客戶那寫！
除錯不要在期限前做！ 上線後再做！
6. 畫面是藍色的！
(國際太空站太空人重新安裝 Windows NT，日誌中的名句)
7. 先說「沒辦法」的人贏。
8. 有意見的話你寫
9. 要殺一個程式設計師不需要刀，改三次規格就好
10. 首先要先懷疑別人，被懷疑的人或許會把問題解決掉。
（註：通常會「先懷疑自己」）
11. 開發沒有終點。只有釋出(release)。
12. 無論規格多晚才能確定，結案期限永遠不會變。
這是所謂的「期限守恆定理」。
13. 客戶總是覺得水跟追加需求是不用錢的。
14. 付錢愈計較的客人愈囉唆。
15. 在排定開發行程時，總是視而不見一些連小學生都會的算數。
業務部門總是一堆不知道1+1=2的人。
16. 一個人掛了大家都掛了。
17. bug過了一晚可能就變成規格了。
18. 好的規格找一個天才不如找三個凡人。
爛的規格找一百個凡人不如找一個天才。
19. 客製軟體中30%的價格用在確認規格上。
30%用在修改規格上。
30%用在找bug。
結果初期規格反映在價格上占的比例只有10%。
20. 對客戶來說SE是部下，程式設計師是家畜。
對SE來說客人是錢，對程式設計師來說顧客是看不見的病毒。
除了弄完程式以外，沒有其他驅除的辦法。
21. 顧客想受SE喜歡，要自己了解到系統開發需要時間與金錢，早點確定規格。
SE想受顧客喜歡，則要讓程式設計師討厭自己。
22. 很多SE跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做，
不過都沒這種機會。
23. 品質的劣化程度依規格改變的次數與規模而定。
24. 業務是認為空想能夠實現的夢想家。
SE則是深信任何障礙都能突破的冒險家。
程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。
25. 有才能的程式設計師第一次看到設計細節時，要先理解程式的目的。
接下來要設法讓SE了解到以指定的方法、工時並無法完成這個工作。
26. 程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者，不可能以這樣的工時實現這樣的規格。
修改規格是對奇蹟吐槽的褻瀆行為。
而追加修改則是相信奇蹟還會重現的無謀行動。
27. 程式設計師聽了「把自己當作顧客去著想！」而開始思考。
啊，像夢一樣。
28. 對於因為興趣而寫程式的人來說，所謂的技術是程式語言能力。
對於因為工作而寫程式的人來說，所謂的技術是邏輯思考能力與人際溝通能力。
程式語言可以看著手冊溝通，客戶不行。
29. 程式系統在交貨之前會不斷縮小。
先用元件定義取悅老闆。
再拿經費概算要部長妥協現實的方案。
在運用會議中，課長會嘗識減少自己責任範圍。
在細節會議中，負責人會把範圍縮到自己記得的部分。
30. SE需要持久力，程式設計師需要爆發力。
31. 準時離開公司，工作會變多。
32. 完美的程式需要完美的時間與金錢。
聽說揮霍著美國的國家預算的NASA，也覺得時間跟錢不夠。
33. 詳細設計要在程式碼的註解裡做完。
註解是唯一的自衛手段，至少要讓自己看懂。
34. 還有時間看程式碼的話就執行他。
CPU跑得比腦細胞快。至少這時候可以休息。
35. 程式的異常該稱為「bug」還是「規格上的限制」是看期限還剩多久決定的。
36. 所謂便服日，好像社會上把他叫做假日
(註) 日本有些公司會有所謂便服日（不用穿西裝的日子），通常是星期五，但…
37. 地獄持續一段時間後，充滿殺氣的怒吼會變多。
再持續一段時間，說話會變少但牢騷會變多，壟罩在凝重的氣氛裡。
再持續下去，反而會海闊天空，四周洋溢充滿活力的聲音。
這種狀態稱為「Programmer’s High」，也是倒下來的人開始出現的時候。
38. 遠處的火災一定燒到這裡。
39. 禱告，然後 “工作” 吧。(修道院的標語)
40. 程式不是用腦記的，要用身體記住。
41. 明天能放假的話死了也罷。
42. 外面有下雨耶，昨天開始下的嗎？
43. 心若不廢掉(消極)，身體會廢掉。
若不讓自己殘忍，自己會被殺。
44. 客戶會說謊，業務會作夢，SE會做白日夢。
程式設計師則惦惦。（愈來愈自言自語）
45. SE總是不講理的(unreasonable)說「沒有辦不到(impossible)」，
業務總是沒辦法(impossible)說「沒道理(unreasonable)」。
46. 規格書就像航海圖，客戶則是洋流。洋流陰晴不定，航海圖就變垃圾。
程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。
47. 再嘮嘮叨叨下去也是要付錢的。
48. 多想個10秒鐘，你可以不說「嗯，這個做得到」。
49. 人是無法從別人失敗記取教訓的動物。
砍成本、改規格、加需求、趕上線，從來沒有人從眾多失敗中記取教訓。
50. 老手用來提振精神的魔法格言：
「不過比起以前來說算是…」
新人用來提起幹勁的魔法格言：
「把這件工作做完的話…」他們還不知道工作是沒有終點的。
51. 所謂交案期限，是指開發現場從公司換到客戶那裡的日子。
52. 程式、SE、經理不是職種。是職責。
53. 業務是最難搞的客戶。
54. 能夠迅速想到解法的程式設計師太多了。
他們能用一分鐘想到方法，用一天去寫程式。
不需要花一小時想到解法，再用一小時去寫程式。
- Jon Bentley
55. 漂亮的規格，可以從沒有bug出現看出來。
明明爛的就是設計，為什麼是這樣…
56. 上線後的除錯才叫做bug。
57. 追加需求確定後交貨期限就無法確定，
交貨期限確定後追加需求就無法確定。
這稱為「追加需求與交貨期限的測不準原理」。
58. 除三個錯就會冒出一個錯。
這稱為bug的無窮迴圈。
59. 不祥的預感總會實現。
不過程式設計師不會去煩惱不祥的預感，那是SE的工作。
60. 要解決地獄的辦法，就是客戶把錢交出來。
61. 不懂電腦的操作者是發現bug的天才。而且無法重現。
62. 每次開會就更改規格的客戶，
他的操作手冊要等到操作寫好的程式後才能寫出來。
63. 搞不懂的時候，Currency（長整數）比Interger（整數）好用。
Variant（字串、數字都能存的萬能變數）又比Currency（長整數）好用。
安全第一。
（VB程式設計師如是說）
64. 啊，那是微軟的規格。
65. 程式設計師所不滿的規格也一定會讓客戶不滿。
（這是說程式設計師覺得難寫的地方常常是SE溝通有落差）
66. 程式設計師需要的技能，
包括交涉、時程管理、業務分析、提案、設計、程式語言、架構、維護、使用。
SE需要的技能則減掉程式語言、架構、維護與使用。
專案經理需要的能力則再減掉業務分析、提案與設計。
業務需要的能力再扣掉時程管理。
67. 正因為健康，才能做不健康的事。
68. (這個不是 bug 嗎？)
規、規格、是規格啦。不過有一點跟規格不太一樣啦。
69. 那是你說的規格。
70. 開發室沒有窗戶，那是因為以前…
71. 即使爛了也是規格。
72. SE: 真沒辦法。
PG: 也沒註解。
（碰到不知道是誰寫的程式，大家都束手無策的狀態）
73. 為什麼你不能兩三下解決掉他啦。
因為之前兩三下搞定的東西也被你兩三下就否定了。
74. 不會動的bug就只是普通的bug。（會動的bug則能視為規格）
75. 今天好好清理bug，bug應該死光了吧。
咦？Windows也死了唷。
76. 客戶不會去想最壞的情況。要他面對最壞的情況，他會認為是漫天開價。
SE則會顧慮最壞的情況，準備應付最壞的情況。
程式設計師比誰都早預料到最壞的情況，而無視最壞的情況。
77. 唯一不產生bug的方法，就是不寫程式。
第二好的方法，就是在時程跟人員確定之後的每次改規格，都重新檢視過整個專案。
78. 共同責任是程式設計師的責任。
管理職？那是啥？好吃嗎？我沒吃過耶。
79. 如果可以改行的話，想找個準時下班不叫「逃跑」的工作。
80. 對職業程式設計師來說，漂亮的程式是單純而自然的邏輯、簡單而基本的指令、豐富的註解，
也就是新手程式設計師也能馬上動手改的程式。
而要寫出這樣的程式，需要單純、簡單、美麗的規格。
但可惜客人總是喜歡搞很複雜。
81. 設計者應該是不該要求製作者製作出超過設計以上內容的吧…
82. 無論是做的比規格書裡的多，還是只照規格書裡的寫，SE都會找程式設計師的碴。
所以程式設計師只做規格書裡的寫的內容。
83. SE對程式設計師說的「常識」每三小時變一次。
84. 自己看規格書。不能跑的是規格。
85. 「沒辦法」是要看把一天當多少小時來算。
一天常常指的是3人日，一個月常常是指4.5人月喔。
86. 工時要減掉一半的單體測試與一半的系統測試，
而交貨期則要另外加上上線後的兩個月。
87. 能拿到錢的規格變更稱為「受理項目」，
拿不到錢的規格變更則稱為「SE的規格確認失誤」。
程式設計師是這麼看的。
88. 累了。我想睡了。可以回家嗎。
（累了吧，我也累了。好累喔怎麼了。反正就是規格啦，管他的）
89. 試圖降低成本的話，為了配合預算，品質會下降，不過漫天開價做出來的品質也不見得好到哪裡去。
90. REDO到底該怎麼唸一直搞不懂。是利斗嗎、李度嗎、R E D O嗎，難道是 red 零 嗎？ 拜託加上注音吧。
（譯註：我比較煩惱 Linux）
91. 有人在程式碼註解裡寫日記。像「今天是雨天…」，「想回家…」之類的。甚至還有「修改日: 2003/10/10 不能同意你更多」這種註解出現。說到這個，好像也看過「吃大便」這樣的註解。
92. 小學生時第一次看到電腦
國中時第一次學會怎麼用
高中與大學學會程式語言
出社會後才發現自己走錯路
93. 「不要讓老闆當業務比較好」
94. 說來說去，要去研究根本不知道為什麼會動的東西為什麼不會動了，找拿破崙來也沒搞頭。

ex 系列

1. 就算程式裡沒bug，編譯器會有bug。
就算編譯器沒bug，OS會有bug。
就算一切都沒bug，客戶會決定什麼是bug。
2. 規格與規格書是不同的東西。
3. 比期限更重要的是靈感與睡眠。
4. 比知識與經驗重要的是手冊與時間。
5. 能動就好了，能動的話…
6. 過了三天就是別人寫的程式碼。
7. (大搜查線系列)
規格變動不是在會議室裡發生的！是在現場發生的！
8. (大搜查線系列)
異常不是在模擬測試時發生的！是上線後才會發生的！
9. 漂亮的設計三天或許就膩了
骯髒的設計三天就習慣了
10. bug與規格是一體兩面
11. 電腦裡沒有bug，bug常在人心。
12. 無論怎麼檢查，不管怎麼確認，上線前一晚就是睡不著。(RFC968)
13. 估價需要1%的經驗與99%的直覺
14. 沒有什麼事情比直接讓找不到任何bug的程式直接上線還要可怕的了。
15.
* 『程式設計師』＝能將SE條理不通的說明翻譯成程式碼的高手
* 『SE』＝與客戶討論改寫規格書、與程式設計師討論後再改寫規格書，程式出貨後還要繼續改寫規格書的人
* 『PM』＝每天修改自己定下的行程表的人
* 『業界老鳥』＝臉色蒼白缺乏表情的人
* 『外包』＝幫不會寫程式的正職員工寫程式的人
* 『coding』＝複製貼上的工作
* 『單體測試』＝指開始寫程式
* 『除錯』＝把程式碼註解掉的工作
* 『新同事』＝在火燒屁股的專案火上加油的人
* 『出貨日』＝把只完成一半的系統上線的日子
* 『末班電車』＝業界平均的下班時間
* 『颱風假』＝一年一度可以準時下班的業界假日
16. 當誰寫的程式碼跑出bug時，那個人大概都不在了（墨菲定理？）
17. 最終手段
「重開機」
意外的常常都很有效
18. 最強藉口
以前「那是硬體的極限」
現在「那是Windows的規格」
19. 「程式碼的可信度，不會比寫的人還可信。」

举例有html内容如下
<table class=”data”>
<tr   class=”abc”>
<td class=”row1″>abc</td>
<td  width=”200″ class=”row2″>abc</td>
<td class=”row3″ style=”padding:5px” >abc</td>
</tr>
</table>

需将<td >中的内容清空.
用editplus打开，shift+H.
查找内容：<td[^>]*
替换内容：<td
勾上使用正则表达式
解释：查找以“<td”开始的字符,下一个或第N个字符不为”>”的行

也可以这样
查找内容：<td(.*)>(.*)</td>
替换内容：<td>\2</td>
解释：查找以“<td”开始，以</td>结束，中间以”>”分成两段，最出只输出第二段。

 

http://www.google.com/a/help/intl/zh-CN/admins/editions_spe.html

专业版为US$50.00美元/用户帐户/年。
免费版支持100个账号的7G邮箱，支持pop、smtp、imap，中文界面。
带Google Talk， Google 日历， Google 文件， 初始页， 移动访问 ，Google Page Creator 等免费服务。

中文界面到了第二步填写信息的时候，总是会提示你选择的国家（中国）”Google 企业应用套件目前不支持该国家/地区的域名。”

这里有个问题： 最重要的是要通过美国的代理服务器访问；
1 申请的域名必须是.com域名的邮箱：如果有.cn com.cn域名需要申请，可以先申请一个.com域名的，然后设置另外的.cn .com.cn域名为相应的.com域名的别名即可；
2 申请的国家填写美国： 注册页面是有IP对应国家的校验的，所以要通过美国的代理服务器才能提交通过；
可以使用putty
 登录设置中配置tunnel，目标设置为Dynamic，添加一个端口7070，再按Add，一个动态转发端口就实现了；
然后用相应帐号ssh登录后：除了登录的终端窗口意外，本地的7070连服务器的22端口之间就有了一个SSH加密的转发通道了。

为了方便切换，可以使用FireFox的SwitchProxy tool插件，设置socks代理通过本地的127.0.0.1:7070 进行传输。
3 电话号码填写一个合法的美国电话号码：555 222-2222；

注册后：
1 会有域名拥有者校验：
在网站根域名的目录下，上传一个带有校验码的googlehostedservice.html文件；
2 域名MX记录修改等，基本上按照提示修改即可

ASPMX.L.GOOGLE.COM. 10
ALT1.ASPMX.L.GOOGLE.COM. 20
ALT2.ASPMX.L.GOOGLE.COM. 30
ASPMX2.GOOGLEMAIL.COM. 40
ASPMX3.GOOGLEMAIL.COM. 50
ASPMX4.GOOGLEMAIL.COM. 60
ASPMX5.GOOGLEMAIL.COM. 70

如果域名mx解析不够，可以只用ASPMX.L.GOOGLE.COM.

邮箱服务的入口：https://mail.google.com/a/c1gstudio.com/
初始页的入口：http://partnerpage.google.com/c1gstudio.com

客户端收发邮件

1. 登录到您的 Gmail 帐户。
2. 点击任一 Gmail 页顶部的设置。
3. 点击橙色框邮件设置中的转发和 POP。
4. 选择针对所有邮件启用 POP 或者针对从现在起开始接收的邮件启用 POP。
5. 使用 POP 访问 Gmail 邮件后，选择您要对邮件采用的处理方式。
6. 配置 POP 客户端* 然后点击保存更改。

在客户端设置
POP服务器：pop.gmail.com 995
SMTP：smtp.gmail.com 25

用户名：你的企业邮箱邮件地址(包括@c1gstudio.com)
密码：你自己的企业邮箱密码

需要启动SSL（可参考gmail相关页面）

 

参考：
 免费企业邮箱： Google企业邮箱的申请

美国的代理服务器

404记录

/_vti_bin/owssvr.dll		-
/MSOffice/cltreq.asp

此及IE工具栏上的”讨论”按钮产生(需ms office)

说WAP是无聊经济，一点也不为过。在使用WAP的原因分布中，“在移动状态下（如上下班途中等）使用”的比例超过了一半，选择“在无聊的时候，打发时间”的比例也超过1/3，而“在一些突发需要上网的时候只能使用WAP”的比例也超过1/4，因此可以发现WAP的移动性即不受地理条件的限制是其吸引用户最主要的方面。此外“包月资费便宜”和“对新技术比较好奇，尝试一下”的比例分别为18.5%和17.0%。

WAP是被迫使用，用户只有在特定情况下，主要是在没有电视和电脑上网等替代品的情况下才使用WAP。据调查，用户一般在以下情况使用WAP：在车上，上课时（无聊时），等车中，临睡时床上，出差途中。

很少有人主动要使用WAP。与游戏相比较，游戏有瘾，人们会去想主动玩游戏，很多人买电脑是为了玩游戏；而很少有人为了上WAP而买手机的。WAP就如同最早的黑白屏幕的286电脑一样，早期只有技术狂热性的和非用不可的人群才会使用。WAP复杂的输入操作，缓慢的速度和内容的单调性等都是限制其发展的因素。

对于数字音乐产业来说，研究WAP用户其实是研究未来音乐消费者的特征。目前是铃声业务业务，接下来是全曲下载业务。未来手机会代替MP3，就如同手机会替代寻呼机一样。这里面会有一部分人会是使用免费的音乐，但仍然有一部分人会付费下载音乐。这个时候，了解什么样的用户会在什么特定情况下会为手机音乐付费，是我们要早做准备的事情。

WAP用户的特征：

WAP用户分布很广，也会有高低用户之分，例如有大城市用户和中小城市的用户；有高端机型用户和低端机型用户；有白领用户和农民工用户。但是，WAP仍然有一个主要消费人群。一般来说，低端用户虽然收入很低，但是却为WAP业务（图铃等）付费的主要人群；高端用户（高端收入、高端机型、大型城市）虽然是WAP的浏览用户，但是他们很少会为WAP业务付费（例如付费图铃业务等）。

高端机型用户一般为白领，销售人员，还有部分大学生，这一类人群中技术发烧性用户比较多；WAP的低端机型的用户一般为务工人群，例如广东外来务工人群，他们住集体宿舍，没有电脑上网，没有电视。

WAP用户有一个共同特点是：群居；在公司和公车上，外地出差中使用WAP；其中学生和打工仔都是没有电脑和电视的宿舍中使用，一般会集中在晚上临睡前上下班的公车上（铃声下载类的操作一般不会在地铁里，因为信号不太好）使用业务。

WAP用户在以下七个方面有鲜明的特征，并且都和“无聊经济”有着关系

1、用户的地域分布

WAP主要分布在广东、北京、上海、江浙等发达省份和城市。广东最多，广东WAP 用户数约为970 万人，占到了全国WAP 用户的1/4，北京和上海的WAP用户数量分别为170 万人和130 万人。

WAP 用户的地域分布集中在我国东部经济相对比较发达的东部地区，这些地方工厂、公司、学校比较集中。但是WAP却不属于最高端人群的业务，而是这些地方的中低端人群消费的业务。以广东为例，广东WAP用户占1/4，但是WAP业务规模却占全国一半以上。这是因为广东外来务工人群居多，一般都是封闭式的工厂，工人住宿舍，WAP是这个人群特有的消遣方式，是一个专门为低收入人群服务的市场。

2、上网条件

之前说过，WAP是无聊经济，是在没有电视和电脑上网的情况下才被迫使用的。根据WAP用户的使用动机，用户通常都会在闲暇无聊的情况下浏览WAP门户网站，拥有无聊闲暇时间最大的是经常跑外的销售人员，以及公车上班一族，以及上课时无聊的学生一族。在上下班高峰，以及夜间临睡前WAP的使用比例最高。

WAP用户与互联网用户重合度也低，估计在30%以内。WAP用户不是你我这样人手一台电脑的人，很多人都是没有接触过电脑而直接成为WAP用户的。

3、性别

WAP用户中，男性占到了8成，女性仅为2成（目前有调查说女性WAP用户在增加的趋势），而传统互联网网民中男性的比例为58.3%，女性为41.7%，可以发现WAP用户男性用户的比例更高。这和WAP的主要群体的职业也有关系。例如男性对技术性更敏感，愿意探索新事物。而女性一般会选择其他消遣方式，例如与人聊天、电话以及看电视等方式。

4、年龄

WAP 用户中，年龄在18～24 岁的比例超出了一半，为51.6%，年龄在25～30 岁的比

例也超出了1/4，为27.8%，31～40 岁的比例为13.1%， 40 岁以上的比例仅有2.2%。值得

一提的是，“80 后”的用户占到所有用户的73.2%。与传统互联网网民相比，WAP用户的年龄更加年轻，也更加集中于18～30 岁年龄段。年轻人更易接受新鲜事物，对技术性产品学习和掌握也更快。

5、职业

WAP 用户中，学生和基础职业（保安、军人、工人）占大部分。其中学生的比例超过了2 成，企事业单位普通员工的比例约为1/4，企事业单位的管理人员的比例也达到了10.8%，专业技术人员的比例也达到了16.2%，农民工虽然在这里面的比例不是太大，但是农民工却是WAP付费业务消费的中坚力量。

WAP 用户中，文化程度为高中的比例最高，为35.8%，文化程度为大学本科和大专的比例则分别为27.1%和21.7%。

6、收入

WAP 用户的个人月收入在1000-2000 元的比例最高，达到了29.5%，2000-3000元的比例为16.2%，而无收入的比例达到21.1%是由于学生用户占有相当的比例。WAP用户中月

收入在3000元以下的比例达到了78.1%，月收入在3000元以上的比例仅为21.9%。

WAP中高收入的人群是白领阶层，属于技术发烧型的人群。他们无论是电脑还是手机，还是其他数码产品都比较精通。WAP中的中收入人群可能是销售人员，上网条件不太便利。

WAP用户中，每月话费消费在100元以内的占56%。这也证明WAP是为特定的低收入用户服务的业务，他们钱不多。但是有闲，并且很少有其他可替代的娱乐项目；而高收入用户一是时间比较繁忙，有钱无闲；二是有其他的可替代WAP的娱乐项目。

7、PC以及手机操作水平

很多用户都是没有接触过互联网而直接使用WAP的。WAP用户的PC操作水平分三部分人，一是技术型用户，玩家级别的；二是初级水平；三是不会上网的。除了少量技术型用户，大部分用户对PC的操作水平都不是太高。

对于手机操作水平，无论用户使用高端机型还是低端机型，无论是高收入用户还是低收入用户，只要不是属于技术性的用户，对手机操作水平都不是太高。

例如，年龄在30岁以上的领导阶层，尽管使用高端机型，尽管收入也很高，但是他们的PC和手机操作能力都不高；另外是低收入使用低端机型的务工人群，PC和手机操作能力都不高；只有中间的白领和学生，操作能力比较高，他们一般是属于技术行用户。

所以，WAP网站和WAP业务在考虑业务设计时，一定要处处想着WAP用户这些人群的特点。懒人推动技术进步，为了他们着想的人才会赢得先机。

附：其他一些数据（以下数据来自互联网，仅供参考）

1、WAP用户形象目前手机上网的形象目前被认为是时尚一组。即便是农民工兄弟的使用，其形象也是在农民工群体中相对时尚新潮一组。

目前使用群体特征：时尚、对新鲜事物感兴趣、容易接受新事物，对资讯需求大，对技术感兴趣的男性年轻用户居多。

和彩铃业务一样，WAP初期的用户是第一批追求新事物的年轻时尚人群。随着业务的成熟，逐渐会扩散到大众用户市场。

2、WAP内容单调。内容方面是导致使用者放弃手机上网的原因。

内容上的单调、匮乏致使目前使用者新鲜感逐渐消失，导致每次上网都是无特别目的，而内容或服务的介绍文字非常古板，千篇一律缺乏特点与个性。内容更新慢，主要从铃声图片感觉明显－－1－2个月才有些变化。

用户对全曲下载的内容要求比彩铃要挑剔的多。使用频率更活跃，也更容易退订因为彩铃用户听不到自己的歌曲，所以很容易沉默。全曲用户需要天天有新东西，因为近半数的用户会天天浏览。

3、WAP 上网的使用特征分析

WAP 用户中新增用户的规模较大，一年内的新增用户占到所有用户的47.5%；6成的用户使用WAP的频率不低于每周一次，平均每次使用WAP的时间以10～30 分钟最多，重度用户占所有用户的40.4%；有54.3%的用户只上或者尽量选择免费的网站，31.6%的被访者表示无所谓收费和免费，14.2%的被访者表示只上手机内置的网站。

WAP 用户认知WAP 站点主要通过三大途径：手机内置、口碑相传和传统互联网；用户使用较多的WAP服务有手机图铃下载、WAP 搜索、在线游戏、在线音乐和在线图书；WAP 用户对目前手机上网的意见主要集中在速度和资费方面。

4、WAP 用户使用频率

对WAP的使用频率分布中，每天使用多次的比例为13.8%，每天一次的比例也有15.3%，

每周至少一次的比例为28.3%，这三者汇总的比例占到了57.4%，这说明WAP用户对WAP

的使用频率较高，近6 成的用户使用WAP的频率不低于每周一次。学生用户的使用频率略

高于非学生用户。

WAP 用户平均每次使用WAP 的时间以10～30 分钟的比例最高，为31.8%，在5～10 分钟的比例也超过了两成，总体上看WAP 用户每次的使用时间都不长，平均在30 分钟以内的比例为64.7%，在1 小时以内的比例为80.9%。非学生用户平均每次使用时间要略高于学生用户。将WAP使用频率与每次使用时长交叉可以发现，使用频率较高的用户平均每次的使用时间长度也比较长，这是由于用户的使用习惯受到惯性影响。

5、WAP 用户对站点选择的态度

27.5%的被访者表示只上免费的WAP网站，还有26.8%的被访者表示尽量选择免费的网站，此两者占到了所有被访者的54.3%。有31.6%的被访者表示无所谓收费和免费，只选择上自己喜欢的网站，此外还有14.2%的被访者表示只上手机内置的网站。调查结果显示，免费网站更受欢迎，但收费网站如果能提供有吸引力的内容也会有相当的市场，还有部分用户由于操作等方面的原因只上手机内置网站，表明手机内置对WAP用户尤其是新用户是一个非常重要的渠道。

6、使用WAP 的平均每月花费

WAP 用户使用WAP 的平均每月花费在11～20 元间的比例占所有用户的1/4 强，在21～50 元间的比例超过了1/5，6～10 元的比例也达到了1/5，超过2/3 的用户每月花费在WAP上的费用在6～50 元之间。

手机图铃下载使用状况：最近半年内使用过WAP 下载手机图铃的比例占到了所有WAP 用户的63.0%，那么意味着半年内使用WAP下载图铃的用户约为2460万人。调查发现通过WAP下载手机图铃的用户典型特征为男性、24～30 岁、月收入为1001～3000 元的企事业单位普通员工。

WAP 音乐使用状况：最近半年内通过WAP 在线试听/下载音乐的比例为40.2%，那么意味着半年内通过WAP玩在线试听/下载音乐的用户约为1570 万人。文化程度为高中及以下，年龄在18～24 岁之间的用户更倾向于通过WAP 在线试听/下载音乐。

7、用户经常访问的WAP站点

WAP 用户经常访问的WAP 网站中，排名前十名的网站为（以下排名不分前后，按照中文名称拼音排序）：

n 移动梦网

n 3G 门户

n 空中网

n 乐讯网

n 手机百度

n 手机搜狐网

n 手机腾讯网

n 手机新浪网

n 网易WAP

n 易查搜索

UIer

Dooky http://www.exdooky.com/main.phpbaidu
Hiboo http://www.hiboostudio.com/Blog/default.asp
Jimmy http://aqua2run.com/microsoft
OnLing http://www.onling.net/blog/
Rokey http://www.rokey.net/v2/blog.aspmicrosoft
水水 http://www.6style.com/blog/snda
潇潇 http://hi.baidu.com/lanx1983
一翔 http://www.uilook.com/blog/
刘毅林 http://www.rainshow.net/weblog/microsoft
王心磊 http://www.pinnawhite.com/weblog/microsoft

UEer

Angela http://www.ucdchina.com/angela/
Moond http://www.moond.com/lab/sony
Panda http://www.aliued.com/pandaalibaba
Ryana http://www.uxstudy.com/
Windy http://dedream.blogbus.com/
白鸦 http://uicom.net/blogbaidu
臭鱼 http://www.chouyu.com.cn/tencent
大智 http://hi.baidu.com/interaction_design
郭宇 http://hi.baidu.com/guoyubaidu
张亮 http://blog.sina.com.cn/uiexpert
李雪明 http://blog.sina.com.cn/cognitive
吴隽辰 http://www.junchenwu.com/

UCDer

Ami http://www.amizhang.com/blog
BanLon http://www.uesee.com/
Dte http://www.dtell.net/
Freeman http://www.uistudio.cn/blog/alibaba
Iqst http://www.iqst.cn/blog/sohu
Jary http://jaryxie.blog.sohu.com/
Sarah http://uisasawork.blogbus.com/
Seven http://hiseven.net/tencent
Todd http://www.todd-lee.com/blog/sohu
大萬 http://evstudio.net/adamwan/
九月 http://www.jiuyue.org/sina
何萧 http://hi.baidu.com/askhexiao/baidu
空格 http://www.esunweb.com/
麦兜 http://www.maidow.com/
赖正 http://www.5qer.com/blog/
奇遇 http://www.ui123.com/blog/
思域 http://hi.baidu.com/myey8
西贝 http://www.xibeidesign.cn/
谢巍 http://blog.d8in.com/
杨朔 http://www.yangsu.cn/
子条 http://hi.baidu.com/ui88baidu
刘云天 http://blog.xiaoxiao.com.cn/tencent

W3Cer

Realazy http://realazy.org/blog/yahoo
嗷嗷 http://www.loaoao.com/
怿飞 http://www.planabc.net/
小毅 http://www.andymao.com/andy/
张建斌 http://www.jluvip.com/blog/

Teams

Alibaba UED http://www.aliued.cn/
Alipay UI http://www.ucdchina.cn/
Taobao.com UED http://www.uiplanet.com/blog/
以用户为中心的设计 http://ucdchina.com/blog/
优势可用性博客 http://www.understandusability.com/blog/

Firefox 浏览器的 Tamper Data 扩展
可以在日志中记录 Web 浏览器发出的每个请求，并显示每个请求所用的下载时间。使用这个扩展的方法是，选择 Tools > Tamper Data 来打开 Ongoing requests 窗口。装载要考察的页面，然后就会看到浏览器发出的每个请求的状态和装载每个元素所用的时间。
图 1. 用于装载 blog.c1gstudio.com 主页的请求细目

每一行描述一个元素的装载情况。显示的数据包括发出请求的时间、装载所用的时间、大小和结果。Duration 栏列出装载元素本身所用的时间，Total Duration 栏列出所有子元素所用的时间。在图 1 中，装载主要页面所用的时间是 2734 毫秒（ms），但是装载所有东西并显示整个页面所用的时间是 4547 ms。

Tamper Data 扩展有一种有用的模式，将页面装载数据的输出绘制成图形。右击 Ongoing requests 窗口上半部分的任何地方，并选择 Graph all。图 2 显示图 1 中数据的图形化视图。

图 2. 用于装载 blog.c1gstudio.com 主页的请求的图形化视图

在图 2 中，每个请求的持续时间显示为深蓝色，并相对于页面装载的启始时间显示。所以，可以看出哪些请求使整个页面的装载变慢了。

YSlow

https://addons.mozilla.org/en-US/firefox/addon/5369

YSlow 是YAHOO提供的性能分析工具，它会分析页面加载的所有内容，然后根据加速站点的13条军规来给站点页面评分并给出建议。另外还集成了一些小工具。详细请见 YSlow官方站点。

今天改了模板
采集了大量数据
目前收录情况
baidu:2020
google:18900
yahoo:3580
sogou:4762
soso:334

 

2007-5-28

0

15500 / 0

856 / 34

2890 / 2900

8210 / 25

0 / 1

0 / 0

0 / 0

0 / 0

0 / 0

0 / 0

0 / 0

0 / 0

 

不过google的中文收录只有8百多页码