馬克雜想...

在ARM上寫了幾年的程式, 今天第一次de到一個關於Portability的bug... 問題出在一個叫libmimic的library裡, 同樣的一段程式, 在x86/Linux上跑, 結果是正確的. 但是在ARM上跑, 畫面就會出現很多奇怪的黑白線條. 原本以為是在ARM上面, floating point變數運算時精確度不足, 所以某個table的值會算錯. 結果trace了半天, 發現裡面所有的table都是正確的, 是到最後產生圖片的的一個填顏色的地方才出錯... 搞了很久才知道原因. 下面這個網址有答案... http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html 原來在ARM上gcc它似乎是不支援signed char這種type, 像下面這短短兩行code, 在ARM跟x86上結果就不同: signed char c = 0xFB; int i = c; 在x86裡, i = 0xFFFFFFFB, 而在ARM裡, i = 0x000000FB 就是這個原因, 造成libmimic做出來的結果, ARM跟x86上會不一樣...

今晚在車上聽Johnny的節目, 他問了一個問題, 到底是"How is your day?"正確, 還是"How was your day?"正確... 兩個答案都有聽眾認為正確, 我覺得是前者, Fiona覺得是後者. 以前我會想很多, 覺得只有一個是對的, 腦子裡這樣想來想去, 最後就不會開口說出來. 後來跟幾個老外接觸過之後, 就覺得這兩種說法應該都OK, 怎麼說都可以. 不會在意去追求那"正確"且"唯一"的答案... 因為這個世上不需要那麼精確, 而且大多數的情況下都是在"不確定"的狀態下反應的. 最後的結果也不會太差. 這樣想想, 就覺得現在的我在工作上還是非常不成熟. 還在追求那"正確"且"唯一"的答案. 希望能有非黑即白, 清清楚楚明明白白的指令, 沒有明白的指令就要求上級或同事給一個明白的答案, 不然沒法做事. 原來我還是幼稚地沒有認清這個社會這個環境是由人組成的, 因為人性而很難給一個明確的答案或作法. 一個Project難也難在處理這些不確定性, 如果全部的事情都能這樣按部就班地規畫好, 那也算不上是個新的, 或是有意義的Project.

Apple這個公司真是amazing!! 昨天發表的iPhone想必大家都想要一隻, 我的MSN的contact list上已經一大堆的人在哈這隻手機了... 恰巧前幾天買了一本叫"The Apple Way", 介紹Apple這家公司的書, 裡面談到了一些十分有趣的歷史... 其中有一件是提到在1985年前, Gates寄信給Apple的President Sculley, 希望Apple可以把MacOS license給大家. 網址在這兒

為了振興部門的運動氣氛( 睜眼說瞎話, 公司最不運動的大概就是我了... )以及融洽部門情感, 又去打了一次保齡球. 因為時間的關係, 依照往例只有打兩局, 第一局熱身, 第二局就正式比賽啦. 上次我在這種制度之下, 在第二局打出166分的滿意成績. 想不到這次在還沒熱身的情況下, 就打出178分的生涯新高! 還有兩隻火雞哩! 我以後打不出這麼高的成績怎麼辦啊!?

現在想想, 我的個性跟小時候已經很不一樣了... 在小學的時候, 我最討厭的是說話課(不知道現在還有沒有, 在課表上就叫"說話課"). 這門課要小朋友輪流上台去說一小段笑話, 或是故事. 我很難把一個故事很詳細地背好, 然後一字不漏的說出來. 所以我很討厭它, 甚至害怕它... 這其實是一件很好笑的事, 因為上台報告, 何必要把每一個字先想好, 背起來, 然後在上台的時候照本宣科呢? 我當時不能接受這種作法, 甚至到研究所報paper我都還會這麼做... 上到國中, 高中... 即使曾經做過高中社團的社長, 還是不太習慣在台上講話, 友社社慶要我上台講幾句恭禧的話, 我也說的面紅耳赤. 到了大學, 一定沒有幾個人知道, 大學四年以來, 我最擔心的課居然是做專題. 倒也不是專題本身有什麼難度, 而是最後也是要輪著上台報告. 總而言之, 在我前二十幾年的歲月中, 我是害怕在大眾面前說話的. 直到最近, 我覺得我的這個症頭應該是有好轉的跡象. 至少在最近幾次咪挺中, 我把我的意見說出來了. 即使這個意見不見得好聽, 但是我還是得說... 在以前, 我應該會把話吞下來吧...

星期六晚上要參加朋友的婚禮, 因為要當招待, 下午就潔身沐浴, 穿戴整齊兩點半就打算出門... 才一出門就怔住了, 鄰居的綠Corsa正正地停在巷子口, 後面三台車全被他擋住了. 好吧, 因為巷子小, 大家又都有車, 這樣併排無可厚非, 有留電話就好. 那就打個電話去吧... 我: 拍謝, 麻煩移車好嗎? 老伯: 蝦咪? 我: 樓下移車... 老伯: 害囉... 我滴呀陽明山上吶... 我: $#%@^% @# 你媽的咧, 最好車子這樣停, 敢從基隆跑去陽明山上玩, 還不留鑰匙什麼的替代方案... 最後就花了四百塊坐計程車去台北了... 花錢事小, 後來兩天沒車過的實在很痛苦, 去擠台鐵極不準時, 上面又有怪味外勞的火車回家... :(

人月神話這本書已經上市超過30年了, 大多數的人總還是認為在一個軟體Project裡加人, 可以縮短需要的時間. 而事實上, 除了低技術的勞力密集工作之外, 在這個時代裡, 很少有工作可以符合這種依人數變多而時間可以縮短的期待了... Wiki有人月神話的 link Adding manpower to a late software project makes it later. 他所持的道理很簡單, 只有兩條... 加人進來, 新人是需要學習的, 在學習的時候是沒有生產力的, 且必然地會拖累老手的生產力. 所以在Project的愈後期加人, 不但沒有幫助, 反而是一種拖累... 人愈多, 所需要的溝通就愈多. 兩個人之間只有一條channel, 三個人就有三條了, 四個人就六條, n個人就n(n-1)/2條channel, 人愈多, 這中間的over head就愈高. 就我來說, 還有一個原因, 那就是做軟體並不是一個線性的生產線, 就算是一條生產線, 也不代表可以走捷徑. 一個小程式要經由ABC三個步驟來達成, 就一定得先完成A, 才能做B, 做完B, 也才能做C. 不可能說給三組人同時做A, B跟C. 最後再同時組起來, 結果就只需要1/3的時間... 就像蓋房子, 1個人蓋100天的房子, 絕不是100個人一天就可以蓋起來. 這樣的神話, 已經被點出了30年, 為什麼還沒有辦法變成資訊界的Common Sense呢?