學海無涯

如同 Steve Jobs 所說過，「不要什麼」比「要什麼」還重要。

若妄以為自已什麼都要學會，未免太太太太過自大！！！

謹記

寫點東西？

常看到叫人「寫點東西」的這種建議，突然對於背後的道理有點感覺

寫東西出來除了分享，也會希望有些回應。如果希望有高品質的回應，心態就不能是一副我超強的樣子在寫，也要有一種「隨時會被打臉」的心理準備

所以寫作也算是在培養「謙受益，滿招損」的認知吧？

在對的時間做事

這個標題可以說得很大，不過這裡只是有幾個小感想而已

最近越來越感覺到時間不夠用，想做的事情太多卻沒時間，而人說的「限制更會帶來進步」（差不多是這樣講吧...(汗)）倒是真的，所以開始發現一些我早該領悟到的時間使用方式，其中之一就是標題

時間的使用效率是一個關鍵就沒什麼好說的，在錯的時間做事，真的很浪費，例如：

1. 在上班時間補充新知或讀RSS。 如果看得東西跟工作直接相關的還好，但如果看的是離得有點遠的主題，怕被看到還要遮遮掩掩，真是沒自尊又浪費切換時間的事。而且公司通常會鎖某部分網站，根本打不開，麻煩的要死。更別說分散了本該專注的注意力。
2. 在通車時間上網看文，尤其是用手持裝置。雖然可以盡量利用3G連線的方便性，但是一定會碰到連線不穩或等待，還要算上螢幕較小和裝置處理速度較慢，如果要再處理（轉寄、收錄）也很苦手。也許ReadItLater這類軟體可以減緩這問題，但是我不太確定效果。這個時間比較推薦睡覺和看書。
3. 在可以睡床上的時候不睡，拿去做其他事，反而是通車或在公司睡，導致睡眠不夠好。還不如交換，床上多睡一點，通車拿來做事看書。

現在想到的大概是這些，雖然說我現在應該在睡覺...但是我真的很想講，我有多白痴~

A book a day, keep the stupid away

Thanks :)

閱讀Joel對軟體考績制度的想法

 

先提一下，這篇同樣充滿對職場上的臆測。一個不想面對論文的學生通常會開始思考一些奇怪而且還不會碰到的議題。

我想寫一點對公司考績制度的疑惑，疑惑開始於在噗浪上看到 @avhacker 的公司(後來知道是鼎鼎有名的...(消音XD))有所謂的「依程式行數」之類的評比制度，和在PTT programming版看到的「有BUG就扣考績」這兩件事。

然後ddavid@PTT提到 Joel 的三篇文章：

Ch21 激勵是有害的(2000)
Ch28 測量(2002)
Ch32 兩則故事(2000)

（我開始懶得幫文章上連結了，原諒我...）

先抄幾句來當大意，混個篇幅

第一篇，Joel講了一個他認為是污辱人的獎勵制度（在微軟），然後說，有些人的貢獻不一定會被看出來，所以有負面考績，導致士氣下降。有趣的是，就算給某人正面評價，但是如果不如那個人的預期，一樣還是士氣下降。更有趣的是，就算有一個公正的考績系統（而且這很難做到），大部分的人還是會失望，因為每個人都覺得自己應該有更好的考績。總之都會讓士氣低落、憂鬱、離職、嫉妒...甚至導致所謂的團隊自殺。他建議軟體經理在考績上做做樣子就好，如果沒有其他選擇的話。

第二篇，大意就是當管理的人想要測量知識工作者的績效時，總是下有對策。下面總是有辦法變出花樣來迎合測量系統就對了，而實質的工作品質可能還因此變得更糟。這裡有好幾個例子不只是軟體領域的。

第三篇說了兩個故事，描述管理良好的科技公司和一團亂的公司的差別。微軟在這裡是好的，「在微軟這家公司裡，如果你是Excel巨集策略的專案經理，即使來公司還不到半年也不要緊，你就是Excel巨集策略之神，連員工代碼六號的老員工也不能擋你的路。事情就是這樣。」另一家風格是「不管你多麼努力工作又有多聰明，也不管你是否在「負責」，你對再微小不過的事都沒有權力。把你該死的點子訓練以及聰明睿智放一邊...」Joel認為「最終的差異在於相信員工並讓他們把事情做好，還是把他們視為作業員對待，必須不停監視控制以免偏離主題並造成破壞。」

ddavid說：

「簡單的結論是，不要想用某種死板固定的規則來打程式人員的考績並做獎懲，只
會造成上有政策下有對策的反效果。你該做的事是一開始就選到對的人（在其它篇章
中有清楚的說明），然後讓他們有真正能做好事情的環境（同樣在其它篇章中有清楚
的說明），而不是用他們寫了多幾行程式或改了幾個Bug就獎勵他，反之就處罰。」

我自己看完三篇的感覺是，我認同Joel說的，但還是不禁冒出一堆疑問，所以不用打考績了嗎？主管只要「找對的人+能做好事的環境」就夠了？那台灣的軟體管理大多是什麼方式？我想，對於這些問題我實在是素材不足無法思考，還是要等真正進了業界才會有更進一步的想法吧？有什麼想法歡迎討論 :p

今晚的旅程

晚上走了一趟很意外的旅程。
原本為了標錯價的mac mini server，隨意在google reader裡以這關鍵字搜尋，想找是否要買或是買了之後如何用的文章，而在當中包含了vgod一篇關於為什麼用Mac的文章，這篇雖然之前看過也大概了解其論點，但以這篇又連到另外兩篇大陸人寫的Mac相關文章，於是這兩篇變成旅程的起點。

• vgod: 為什麼我用Mac
• 為什麼我認為每個程序員都應該用Mac OS X？
• 開發人員為何應該使用 Mac OS X 兼 OS X 小史

這三篇文章都在討論程式設計在Mac上開發的好處和其原因，但我反而有其他無關的想法跑出來，例如：

1. 對台灣的軟體業感覺：要討論這麼大的題目，我實在是沒什麼能力，身為一個技術不精也還沒上班的學生，見解絕對不會高明到哪裡去。只是身為一個目前對軟體還算有憧憬而且徬徨的米蟲，總是會想東想西希望能找到一條相對正確的路來精進自己的實力，所以特別注意這類話題。好，廢話講完想說一下我的感覺（臆測），就是台灣軟體應該是他媽的玩不起來吧。當然玩不起來要看怎麼定義，只是我會有這種（絕望的）感覺，就是因為看到文章在介紹到Apple/OSX的發展史時，那種一路發展和架構出來的層級根本不可能在台灣發生...這麼說吧，隨便舉例，歐美有人做出UNIX，有人做出Linux，有人做出smalltalk，有人做出C，有人做出obj C，Java/.NET/各種GUI的IPC標準...，軟體架構完整的從下而上堆疊，開發的軟體等級都是深刻影響整個世界的，而我們做出了...防毒軟體和DVD軟體。不是我們的東西不好，純粹只是等級差太多而已。我們只有用的份，沒什麼偉大的創造。所以突然覺得，與其怪老闆沒做軟體的遠見，不如說根本沒環境吧？我覺得到我退休前應該還看不到像Apple這種可以說是偉大的公司在台灣出現吧。結論：沒結論。以上算是近乎哀號的論點而已，「軟體業」本身就是一個複雜多元的名詞，所以台灣軟體業可否興盛要先看怎麼定義何謂「軟體業」。
2. 大陸的IT寫作：好東西越來越多了，常看到不錯的Blog有不錯的長文，另外也翻譯了不少經典的好書，有幾本還比正體的好。怎麼會這樣呢？
3. pipe/D-bus/Cocoa：pipe是UNIX精神的其中一個體現，我也深深的為這種運作模式著迷，被我視為增進工作效率及有效學習的一環。而當application以GUI呈現時，D-bus就是其中一種IPC的方式，Apple則是發展出Cocoa。感覺是，發展這些技術背後的精神和思想真是不簡單啊...。

至於我認為該不該在Mac上開發程式，等之後有機會再寫一篇文章來討論看看吧 :D

GDB中如何存取不在current context的static variable

下午和 型男hasashi 討論一個malloc/free的問題，他寫了一個小程式來驗證malloc是否會自動free這件事，但是會 segmentation fault，我就想說開GDB來debug，同時練習GDB的用法。(自從上次在元智大學聽 變態 高手 Jserv 講解過GDB就一直在找機會練習 :D)

雖然說事後想一想這小程式其實意義不大，所以這程式邏輯是什麼也就不是重點了XD 但是碰到一個很有趣的GDB問題，所以想筆記一下。

這程式中，main會call一個function，裡面建立一個 static variable叫xxx，我想監看這個變數，不過如果程式離開這個function回到main了，我們在gdb裡要p(print)這個變數會出現：

No symbol "xxx" in current context.

所以我知道這個static variable其實存在，但是我看不到。雖然發現用把xxx加到display卻可以印出，我也不知道為什麼？(補充一下display的作用：每次breakpoint被觸發的時候，有被加到display裡的參數會自動被gdb print出來，就不用手動print。) 而且，只有display並不夠，因為有時會想存取這個變數來複製、assign給別的變數或做別的動作。

於是我先去 stackoverflow 找，但並沒有找到相關討論；接著我去google "gdb static variable No symbol  in current context"，發現答案就在 gdb manual 裡；在 "Examining Data" 這一章的 "Program Variables" 這一節提到：

...If you wish, you can specify a static variable in a particular function or file, using the colon-colon (::) notation:

file::variable
function::variable

Here file or function is the name of the context for the static variable....

所以就可以很快樂的用 function::xxx 這種方式來存取不在current context的static variable了！

ps. 也許這就是沒先k過manual的報應啊…可是 gdb manual 有整整 32 章耶(不含一堆附錄)！？而且又不是只有gdb要看，想看的文件太多了，要怎麼取得平衡對我來說還是一個未解的問題…。

ps2. 在使用"gdb --tui"時曾經碰到好幾次上方視窗的source code會突然亂掉，發現別人也有碰過這個問題，但是暫時不知道解法，也許要找一個好的front-end來用。

新竹清夜的乾杯(ComeBuy)與零錢

一直以來都滿喜歡這家飲料店。

這家有很多特殊而且好喝的茶，例如有些微酒味的白蘭地奶茶和其他店比較沒有的花草茶；然後在去年低潮的時候，常常離開實驗室已經很晚，心情都不會太好，那時候就常午夜去買一杯，加上店長和店員比其他店都還親切，感覺很溫暖；而且記得以前在東吳的時候，偶爾會被現在已經是波麗士大人的威志帶去當時還沒轉型的乾杯買喝的，有點懷念。

最近突然想喝焦糖奶茶，昨天去全家沒看到，剛才去85度C也沒看到，去乾杯果然找到了，小小的開心一下。

買完之後，剛好有看到乾杯的義賣活動，+10塊可以買一杯桂圓八寶茶而且乾杯會把義賣所得全數捐出去當營養早餐基金，於是就買了一杯然後把身上剩下的零錢都丟到伊甸的零錢箱。開心又加了一點。

我偶爾會丟零錢到便利商店或飲料店的零錢箱，想到就會丟，其實不多，每次也才幾十塊，而且又簡單方便。我發現我丟的多寡會跟我對那家店的喜好有關係，像乾杯就比較常丟，而且會多一點。

故事就這麼結束了，沒錯…這是一篇很雜的雜記。大三元新開的燉飯很好吃，剛點的是奶油雞肉燉飯。下次我想吃中央羊肉 :D

什麼叫豐盛的早餐！(rock)

昨天自己把很多事情做到一個段落覺得很開心，包括論文看的paper還有看很久的金字塔原理，而且最近都堅持沒吃宵夜加上昨天只吃一餐有夠餓，所以決定要吃個豐盛的早餐激勵自己一下…睡覺前一直在想要吃以下哪一個：

• 摩斯
• 小麥
• 拉亞

所以今天早上就全部都吃了（爆）

科科…既然決定不了就通吃XD 真是有史以來最誇張的早餐

比較可惜的是到摩斯時剛好過了早餐時段，所以只好自己升級成冰鱈鱈魚堡，沒達到三家早餐大聯合。而且付賬才發現儲值卡不見了（驚）還好之前是掉在這家店，囧…

下次要吃新竹著名的饅頭肉排蛋+蔥抓餅 :D

腦海裡，滿滿的 盧廣仲 - oh yeah!!!

只要大聲說～OH YEAH！！！

為什麼不該看「圖解金字塔原理」

(台灣出的圖解)	(原作)

我實在對這本書太失望了，才特地把原因寫出來。 
這本的原作「金字塔原理」是一本從外文翻譯成中文，還算有名的書，如同這本書的副標，是在介紹一種思考、寫作、解決問題的邏輯方法。
而「圖解金字塔原理」是台灣人寫的，因為原作有點複雜而且冗長（簡單講就是很搞話），作者希望用圖解的方式來讓讀者加快理解原作的內容。
我就是因為啃原作啃的很累，知道有圖解這本後，在網路上找了一些書評，如aNobii和豆瓣，看起來還不錯。於是很開心的跑去交大圖書館借來看，想說可以加快自己理解原作，結果讓我大失所望，原因如下：

1. 圖的組織亂七八糟：這是最大的問題！也許作者很用心的在畫圖，但是以我看過原作再去看圖解的圖，竟然很多還看不太懂，常常不知道圖要用哪種方式解讀，圖的符號也用的紊亂，想表達的東西太多但卻沒有一個統一的表達方式，讓圖失去價值。…一本「圖解」書的圖畫不好那還要看什麼？
2. 要「圖解金字塔原理」卻沒有照「金字塔原理」去安排章節：作者想用自己的方式表達，但卻正好打破的原作的邏輯，我不覺得是這一個好的trade-off。原作的鋪陳是一步步的介紹概念，但圖解卻跳來跳去，會讓人不知道在講哪一部分，觀念沒有連貫，看的反而更累。

雖然這本還是有優點，但是光這兩大缺點就不值得看。絕對不建議在看原作之前就先看圖解這本。如果說可以用借的，來配合看原作倒還有可能小有幫助。希望作者能夠更用心一點，讓台灣能有更好的圖解好書可以看呀…。
抱怨完畢…寫論文去！

UPDATE: 有一個專門代讀商管書的部落格也認為這本書不值得讀。