這兩天出差到蘇州，工作進展的比較順利，否則我今天也回不了南京。工作有些體會，在候車和乘車途中也難得看了好久沒看的書《程式設計珠璣》（為什麼選這本書帶著出差，有這本書的肯定知道這本書區區200多頁）；也思考了一些問題，忍不住記錄下來。

   第一天9：00趕到火車站，大家都知道火車站買票是需要排隊的（廢話！其實有些人不知道。），9：15終於排到了視窗，這時候擠過來一個胖子（沒有侮辱的意思）也要買去蘇州的票。售票員說，你怎麼不排隊呀？他叟地一下掏出一個證件很拽地說，行了吧？售票員一看說，記者證就可以不排隊了麼？胖子看記者證嚇不住人，立馬換了語氣，我趕時間嘛。售票員說，如果他們同意就可以。然後大家的意思都是算了，售票員說9:30到蘇州的票是無座的。那胖子說，那晚一點呢。售票員說，10：40有座，你不是趕時間嘛？真是奇怪了。胖子買票成功，離去。我買了9：30去蘇州的無座票，售票員對旁邊的同事說：%￥@拿個記者證就能插隊了，以後什麼證都能插隊了。看來這位記者兄弟認為這個佇列是優先佇列，他的優先級別很高。

   無座票的價格和有座票的價格是一樣的，這個大家都知道，所以無座的意思不是真的無，是讓你自己去找空座，至於為什麼會有空座？要看到你目的地途中有幾個停靠站點的上下車旅客情況了（大家都想過這個問題吧？）。上車後換了幾個座位都有人，算了，找個舒服的地方先呆著吧，畢竟換來換去很不好受。下一站丹陽再碰碰運氣，20分鐘就到了。一部分旅客下車了，又有一部分上，換了一次座位後火車啟動了，終於安心坐好。下一站無錫，又換了一次座位，順利坐到蘇州。全程1小時30分鐘，站立25分鐘，坐1小時5分鐘。所以下次大家平時出差趕時間時買無座也不用害怕。這一小時的時間看了《程式設計珠璣》第五章：程式設計中的次要問題，其中有個找bug的軼事挺好玩的：       一位程式設計師最近安裝了一個新的工作站。當他坐下時一切正常，一旦他站起來就不能登入系統了。而且此bug有100%可復現：坐下可以登入而站起來時重來不能登入。大家可以想想原因，給大家1分鐘。好了，可以看下面了。大家肯定開始懷疑地毯下的電線是否鬆了？存在靜電？最後，一個機靈的同事最後問對了一個問題：程式設計師站著和坐著時分別是如何登入的？伸出手再試試。問題就在鍵盤上，兩個鍵的鍵帽鬆動了。坐下時是觸控打字；但是站起來時，在尋找和敲擊鍵盤，它就不行了，最後拿來改錐擰緊了兩個晃悠悠的鍵帽，一切正常了。    芝加哥的一個銀行系統正常運行了幾個月了，但是第一次處理國際資料就掛了。程式設計師花了幾天時間查程式碼也不能找到任何停止改程式的原因。當更仔細觀察這個問題時，發現輸入有關厄瓜多的有些資料時程式停止。更加仔細的檢查顯示當用戶輸入首都（Quito，基多）時該程式退出。   呵呵，是不是很有意思。總結：無論在什麼情況下，恰當的提問都會引導聰明的程式設計師迅速找到令人討厭的bug。

    到達蘇州，天熱得跟蒸籠似的，好不容易到了我要安裝新系統的地方，和另一位做工程的同事一起安裝，除錯一次性成功，沒有問題。坐車準備去另外一個地方升級下那邊的版本，但電話聯絡說那邊沒人開門，只好坐車去住的地方，下午5點多了，幸虧它沒開門，要不還不曉得幾點能回來。這段時間在車上沒看書，第三次來蘇州，抓緊時間打量這座城市，樹挺多的，美女挺多的，不過估計又沒時間去看看仰慕已久的園林了。
     第二天一早就直接奔到另一個點，三下五除二搞定系統升級，一切正常；電話跟領導彙報，領導讓我可以回南京了。直接又奔到火車站已經是上午11點了，最近一班動車去南京的是12：56分的，去候車室等吧。候車的過程中看了“珠璣”中的第七章：封底計算。就是一種快速估算的方法。比如問你長江一天流入大海的水量是多少？之類的。大家有興趣的可以估算下。這裡總結下這章裡面的幾個原則：1.“72原則”假如你投入1000美元，時間是12年，利息是6%那麼屆時你將得到2012美元，6×12=72；而9年的時間，利息8%你將得到1999美元，9×8=72；聰明的你肯定總結出了規律：假如你投入一比錢時間是y每年利率是人r%那麼你想使你的錢翻番，需要滿足r×y=72。如果你要翻10倍呢？我們知道2^10=1024，10翻就相當於1000。比如一個指數函式花了10秒來解決一個規模為n=40的問題，且n每增加1就增加12%的執行時間，根據72法則，n增加6執行時間就翻番，n每增加60，執行時間上漲1000倍。如果n增加到160呢？時間會增加到10^7秒，這是多少時間呢？可能很少有人記得一年是3.155×10^7秒，但是Tom Duff總結了一個經驗‘∏秒是一納世紀’，所以10^7秒大概是4個月。   2."安全係數法則"，納羅斯海峽大橋在1940年的一次暴風雨中斷裂了。在這之前8年中，有幾座懸浮橋也遭受了同樣的命運。這是氣動力上升的原因。如果要計算這個問題需要對漩渦進行建模。當時沒有人知道怎麼建模。那麼，為什麼布魯克林大橋至今沒有斷裂呢？那是因為設計師John Roebling充分意識到了自己的無知，他將橋上的鐵索強度設計成基於已知的靜態和動態負載的常規設計要求的6倍。所以，在我們對我們的實時軟體系統進行效能計算時，我們必須按照2，4或6的係數降低效能，以補償我們的無知。據悉，在美國，迄今還沒有Roebling同時代的其他人所建築的吊橋還未垮掉。   3.“利特爾法則”比如：你要進入一個很火爆的酒吧，酒吧可以容納60人，平均人們在裡面的停留時間是3小時，所以進入率是20人。佇列上已經排了20人，那麼我們可能還要等1個小時。利特爾法則闡述到：系統中物體的平均數量就是系統中物體離開系統的平均比率和每個物體在系統中所花費的平均時間的乘積。   總原則：當你使用封底計算時，一定要回憶一下愛因斯坦的名言：“任何事都應該做到儘可能的簡單，除非沒有更簡單的了。”我們知道，考慮安全係數以彌補我們估計的不足，簡單計算也將不再是一件很簡單的事情。

    好了，候車結束，檢票上車，這次我是有座票哦，所以沒來的時候那麼浮躁。坐過“和諧號”動車的人肯定知道中途停靠的站停車時間是很短的，短到什麼程度，可以說蘇州站大概有300多人上車，停車時間是2分鐘。有人要說了，那怎麼會來得及。好，我們運用下上面封底計算的知識。如果一個人上車時間是2秒的話，300人上一個入口需要10分鐘，顯然不夠；幸運的是入口有13個（13列車廂前門下，後門上）；在乘務員和乘客的共同努力下，佇列排成整齊的L型，每個佇列不超過30人，這樣1分鐘足夠了，而且考慮了安全係數，以2的係數降低效能。車來了，順利上車，坐下，感受到了“和諧號”的舒適，抱歉來的時候坐的也是和諧號，只是一直在換座位不是很安心。在腦中回憶這次出差的收穫，思考，1個半小時的車程很快就過去了。思考了很多東西，生活，事業，在此就不一一贅述了。

    有耐性的人可以看看下面幾個有趣的封底計算的問題：

    1.在多遠的距離下，騎自行車的郵差傳送可移動媒介的速度可以比高速資料線傳遞的更快？

    2.請問通過打字填滿一張軟盤需要花費你多長的時間？

    3.聯合國1998年統計世界人口為59億，年增長率為1.33%。這個增長率會持續增加麼？到2050年時，人口數量會達到多少呢？

    4.請估計下你的城市的死亡率（用每年人口的百分率度量）。

    （完）