公式ページ http://www.takaotozan.co.jp/index.htm
其實是個還不錯的景點啦，山不高，只不過天氣實在太熱了...光在平地走就已經滿身汗，爬點小山就更慘了。
基本上來這裡一定要搭的是日本最陡的cable car，最大坡度有31.XX度!
不過山上景致還是不錯啦，天氣不熱的話可以去走走。
星期五, 9月 03, 2010
東京七日遊 - 高尾山
高尾山算是這次唯一的景點吧，對我來說。
公式ページ http://www.takaotozan.co.jp/index.htm
其實是個還不錯的景點啦，山不高，只不過天氣實在太熱了...光在平地走就已經滿身汗，爬點小山就更慘了。
基本上來這裡一定要搭的是日本最陡的cable car，最大坡度有31.XX度!
.......好，其實是我偷懶不爬山，搭了這個就可以到半山腰了，然後往上爬大概30~40分鐘就可以到山頂。
雖然說當天天氣很好，熱的要命，但是從山頂看下去遠處還是白茫茫的，看不到什麼，本來看官網說可以看到富士山還有東京市區，結果都看不到....
不過山上景致還是不錯啦，天氣不熱的話可以去走走。
公式ページ http://www.takaotozan.co.jp/index.htm
其實是個還不錯的景點啦，山不高，只不過天氣實在太熱了...光在平地走就已經滿身汗，爬點小山就更慘了。
基本上來這裡一定要搭的是日本最陡的cable car，最大坡度有31.XX度!
不過山上景致還是不錯啦，天氣不熱的話可以去走走。
東京七日遊 - Animelo Summer Live 2010, part 2
兩天live加起來超過11小時，而且兩場幾乎都是讓人完全燃燒，根本沒有坐下來的時間，兩天live結束隔天都是睡到不行，本來早上有排的行程都cancel掉了....哈哈
上面這張是結束散場的時候從我位置往舞台拍的，基本上除非artist有走過來這邊，要不然其實角度很大，都是看到側面。
不過這位置跟舞台差不多高，整場UO亮起來的時候往觀眾席看過去真的很漂亮，很令人感動。
然後這次也讓我感受到田村國的威力，除了田村國人民在會場到處都有之外，喊call喊到我根本不知道田村ゆかり在唱什麼Orz，實在是太可怕了。
P.S.說明一下，其實散場也是不能拍照的，開場前也不行，不過我看我身邊一堆日本人也在拍(開場前也有人在拍)，索性就...小朋友不要學。
不過這位置跟舞台差不多高，整場UO亮起來的時候往觀眾席看過去真的很漂亮，很令人感動。
然後這次也讓我感受到田村國的威力，除了田村國人民在會場到處都有之外，喊call喊到我根本不知道田村ゆかり在唱什麼Orz，實在是太可怕了。
P.S.說明一下，其實散場也是不能拍照的，開場前也不行，不過我看我身邊一堆日本人也在拍(開場前也有人在拍)，索性就...小朋友不要學。
東京七日遊 - Animelo Summer Live 2010
基本上是去參加8/28, 8/29兩天的アニメロ Summer 2010
會場照往例 -- さいたまスーパーアリーナ
兩天埼玉的最高氣溫都是37度，實在是熱死人，完全放棄那個要排三小時以上的物販，外面隨便看看熱鬧就進去了。
會場外面除了人山人海之外，有展示artist的簽名T-shirt
這次令我很意外的是，KOTOKO竟然亂入演出，而且第一首就是あねがいティーチャー的Shooting star，整個場子真的是High到不行。
會場照往例 -- さいたまスーパーアリーナ
會場外面除了人山人海之外，有展示artist的簽名T-shirt
星期日, 8月 22, 2010
星期三, 8月 18, 2010
TM營收
以上資料來自http://us.trendmicro.com/us/about/financeinfo/reports_presentations/index.html
我不是會計專家，對於財報我只知道net income越高越好XD
從2008，2009到今年2010 Q2來看，難怪股價會越來越低...
這是要怪經營者還是要怪員工？ 若是50人以下的小公司，每年營收越來越低的話，我想員工關係可能不小，但是若是一個4000人以上的大公司...
星期五, 8月 13, 2010
星期四, 8月 05, 2010
星期一, 8月 02, 2010
約耳趣談軟體 - 附錄
本書最後有讀者問了如何估計軟體開發時程，我簡單節錄約耳的回答：
如果估計的是已經細分過的任務(每個任務長度最長是一天，否則必須再細分下去)，而且評估者要有足夠的經驗，能在估計時間內包含一切(假期、整合時間、「新功能」時間、參加愚蠢經營會議的時間、面試的時間...等)，那只需要10%的緩衝時間。
但這段緩衝時間只是讓自己心安的做法，應該要根據各種類型的緩衝，還有事情的緩急來分配時間，例如：
1. 開發過程中想到的預期外的功能，針對這些新功能的緩衝時間。
2. 由於競爭者做了某些事，為了因應競爭者所需的緩衝時間。
3. 整合各個開發者所寫的程式碼，讓結果正確運行的緩衝時間(依經驗可以是從25%~100%)
4. 在測試時發現問題並修正的緩衝時間。
5. 員工必須執行開發之外的工作，例如：training課程、公司緊急會議、火警演習、準備老闆生日蛋糕...等。
6. 預防發展不順利時的緩衝時間。
7. 因應估計時漏列事項的緩衝時間。
我之前待的TM公司，manager們在列tasks時就已經常常漏列許多tasks了，也沒有在估計"整合"的時間，也常常有高層想到新的東西就硬要加進來做，當然也沒有估計過會議等雜事的時間...
不過我想犯的最大錯誤可能是讓"沒有經驗"的人來評估時程...總之一個佔公司快一半營業額的產品就這樣被搞得亂七八糟，我想過不用多久，大家就會知道了。
如果估計的是已經細分過的任務(每個任務長度最長是一天，否則必須再細分下去)，而且評估者要有足夠的經驗，能在估計時間內包含一切(假期、整合時間、「新功能」時間、參加愚蠢經營會議的時間、面試的時間...等)，那只需要10%的緩衝時間。
但這段緩衝時間只是讓自己心安的做法，應該要根據各種類型的緩衝，還有事情的緩急來分配時間，例如：
1. 開發過程中想到的預期外的功能，針對這些新功能的緩衝時間。
2. 由於競爭者做了某些事，為了因應競爭者所需的緩衝時間。
3. 整合各個開發者所寫的程式碼，讓結果正確運行的緩衝時間(依經驗可以是從25%~100%)
4. 在測試時發現問題並修正的緩衝時間。
5. 員工必須執行開發之外的工作，例如：training課程、公司緊急會議、火警演習、準備老闆生日蛋糕...等。
6. 預防發展不順利時的緩衝時間。
7. 因應估計時漏列事項的緩衝時間。
我之前待的TM公司，manager們在列tasks時就已經常常漏列許多tasks了，也沒有在估計"整合"的時間，也常常有高層想到新的東西就硬要加進來做，當然也沒有估計過會議等雜事的時間...
不過我想犯的最大錯誤可能是讓"沒有經驗"的人來評估時程...總之一個佔公司快一半營業額的產品就這樣被搞得亂七八糟，我想過不用多久，大家就會知道了。
約耳趣談軟體 - 書中的好文節錄 part 2
軟工以及軟體公司的管理真的是很有趣的東西，PC畢竟出現時間還不長，還沒有經過時間磨練的大規模商業及管理研究，因此要從別人研究或是經驗裡學到大型軟體開發及管理實在不易。約耳這本書道出許多軟體開發及管理上的許多「事實」，真的是一本每位軟體從業人員必讀的好書。
繼續節錄裡面一些「中肯」到不行的段落。
1. 客戶不知道他們要什麼。別再期望客戶知道他們要什麼。
2. 重要推論一：把使用介面的畫面展示給非程式人員看時，如果這個介面很不好，對方會認為你整個程式也是很不好的。
3. 重要推論二：把使用介面的畫面展示給非程式人員看時，如果這個介面非常漂亮，對方會認為這個程式幾乎已經完工。
4. 重要推論四：因為政治因素要求由各技術經理或客戶「啟動」專案時，可以提供數種美術設計讓他們選擇。
改變某些元件的擺設方式，改變外觀和字型，移動標誌位置，標誌也可以變大或變小。拿些無關緊要的家家酒內容給他們玩，讓他們覺得自己很重要。這些他們就不會嚴重影響你的時程了。
5. 至少要有一個對所用的語言、類別、API以及平台有數年以上經驗的設計者，否則還是不要啟動專案吧。如果你可以選擇平台，就用你的團體最熟悉的吧，即使這個平台並不是最符合趨勢或看起來最有生產力也沒關係。另外在設計抽象機制或程式設計工具時，多做些努力讓它不會漏吧。
6. 經理人喜歡施行測量系統，而且喜歡把它和獎懲方案綁在一起。不過只要沒有百分之百的監督，工作人員就有誘因來個「下有對策」，心裡只想著那個測量系統，完全不顧工作的實際價值或品質。
7. 軟體組織通常會獎勵(a)寫大量程式以及(b)修正大量問題的程式師。想在這種組織中出頭，最好的方法就是寫一大堆錯誤百出的程式之後再全部修好，而不是多花些時間在一開始就把東西做好。
8. 除非有個程式師掌舵，否則沒有軟體公司會成功的
9. 我並不是說這是我離開Juno的原因，不過它的確解釋了我離開Juno(約耳的前公司)的理由：不管你多麼努力工作又有多聰明，也不管你是否在「負責」，你對再微小不過的事都沒有權力。把你該死的點子訓練以及聰明睿智放一邊，把那些讓我們付錢請你的一切東西通通都丟到一邊吧。而且Juno的經理很多，大概佔總員工四分之一，所以他們有的是時間可以到處亂伸手指，確定他們能掌控。在微軟卻是副總自己從九號大樓出來找你，確定你有權力能把事做完。這對比還真是強烈啊。
10.
A. 有些事需要天份才做得好。
B. 天份很難複製。
C. 有人嘗試複製天份，要有天份的人建立規則讓普通人照著做。
D. 結果所得到的產品品質很低。
「訓練」並不真的能產生一致的結果。
小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度，不過同時也會產生很多約束而激怒更多的聰明人。
11. 事實上如果你曾經把很關鍵的業務拿去外包，就會瞭解外包其實是個地獄。不能直接控制客戶服務，客服就會爛到不像話，爛到像某人在網誌上寫的，想在電話公司找個人(任何人都好)去做些最最簡單的事都辦不到。
12. 如果是核心的事業功能，不管是什麼都要自己來做。
13. 在開始行銷你的「精簡」產品時，你會告訴大家：「嘿，這東西很小，只佔1MB。」大家通常都會很高興，然後就會問你有沒有他們要的重要功能，如果沒有的話還是不會買你的產品。
14. 聰明的公司試圖讓產品的互補物普及化(commoditize)。(例如，PC硬體與軟體是互補物，PC如果賣得好，隨之軟體也會賣得好，virus與防毒軟體或許也稱的上是互補物XD)
15. 無法獲得開發者尊重的產品經理沒有作用，因為他們只會一事無成。當我還在Excel團隊時，開發者會把沒有技術底子的產品經理當作早餐吃掉。
16. 產品經理最重要的技能，就是把自己的想法塞進軟體開發人員腦子裡，讓開發人員以為是自己的點子，然後乖乖照著做。
繼續節錄裡面一些「中肯」到不行的段落。
1. 客戶不知道他們要什麼。別再期望客戶知道他們要什麼。
2. 重要推論一：把使用介面的畫面展示給非程式人員看時，如果這個介面很不好，對方會認為你整個程式也是很不好的。
3. 重要推論二：把使用介面的畫面展示給非程式人員看時，如果這個介面非常漂亮，對方會認為這個程式幾乎已經完工。
4. 重要推論四：因為政治因素要求由各技術經理或客戶「啟動」專案時，可以提供數種美術設計讓他們選擇。
改變某些元件的擺設方式，改變外觀和字型，移動標誌位置，標誌也可以變大或變小。拿些無關緊要的家家酒內容給他們玩，讓他們覺得自己很重要。這些他們就不會嚴重影響你的時程了。
5. 至少要有一個對所用的語言、類別、API以及平台有數年以上經驗的設計者，否則還是不要啟動專案吧。如果你可以選擇平台，就用你的團體最熟悉的吧，即使這個平台並不是最符合趨勢或看起來最有生產力也沒關係。另外在設計抽象機制或程式設計工具時，多做些努力讓它不會漏吧。
6. 經理人喜歡施行測量系統，而且喜歡把它和獎懲方案綁在一起。不過只要沒有百分之百的監督，工作人員就有誘因來個「下有對策」，心裡只想著那個測量系統，完全不顧工作的實際價值或品質。
7. 軟體組織通常會獎勵(a)寫大量程式以及(b)修正大量問題的程式師。想在這種組織中出頭，最好的方法就是寫一大堆錯誤百出的程式之後再全部修好，而不是多花些時間在一開始就把東西做好。
8. 除非有個程式師掌舵，否則沒有軟體公司會成功的
9. 我並不是說這是我離開Juno的原因，不過它的確解釋了我離開Juno(約耳的前公司)的理由：不管你多麼努力工作又有多聰明，也不管你是否在「負責」，你對再微小不過的事都沒有權力。把你該死的點子訓練以及聰明睿智放一邊，把那些讓我們付錢請你的一切東西通通都丟到一邊吧。而且Juno的經理很多，大概佔總員工四分之一，所以他們有的是時間可以到處亂伸手指，確定他們能掌控。在微軟卻是副總自己從九號大樓出來找你，確定你有權力能把事做完。這對比還真是強烈啊。
10.
A. 有些事需要天份才做得好。
B. 天份很難複製。
C. 有人嘗試複製天份，要有天份的人建立規則讓普通人照著做。
D. 結果所得到的產品品質很低。
「訓練」並不真的能產生一致的結果。
小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度，不過同時也會產生很多約束而激怒更多的聰明人。
11. 事實上如果你曾經把很關鍵的業務拿去外包，就會瞭解外包其實是個地獄。不能直接控制客戶服務，客服就會爛到不像話，爛到像某人在網誌上寫的，想在電話公司找個人(任何人都好)去做些最最簡單的事都辦不到。
12. 如果是核心的事業功能，不管是什麼都要自己來做。
13. 在開始行銷你的「精簡」產品時，你會告訴大家：「嘿，這東西很小，只佔1MB。」大家通常都會很高興，然後就會問你有沒有他們要的重要功能，如果沒有的話還是不會買你的產品。
14. 聰明的公司試圖讓產品的互補物普及化(commoditize)。(例如，PC硬體與軟體是互補物，PC如果賣得好，隨之軟體也會賣得好，virus與防毒軟體或許也稱的上是互補物XD)
15. 無法獲得開發者尊重的產品經理沒有作用，因為他們只會一事無成。當我還在Excel團隊時，開發者會把沒有技術底子的產品經理當作早餐吃掉。
16. 產品經理最重要的技能，就是把自己的想法塞進軟體開發人員腦子裡，讓開發人員以為是自己的點子，然後乖乖照著做。
約耳趣談軟體 - 書中的好文節錄 part 1
今天把這本書看完了，節錄一些我覺得不錯的片段下來
1. 在很多程式開發組織中，出現設計爭議時，總沒有人願意做出決策(通常都是因為一些「政治理由」)，所以開發人員只去做那些沒有爭議的項目。
2. 當你和整組人一起建立產品時，通常每個人都會各有所好，因而產生各式各樣真正或虛構的必備心愛功能，如果要將這些功能全部都做出來，恐怕永遠做不完而且要花很多很多的錢。所以你必須馬上開始刪功能，而刪功能的最佳方法就是利用規格的「非目標」章節，列出我們不打算做的東西。
3. 1980年代當微軟開始快速成長時，那裡每個人都讀過The Mythical Man-Month(人月神話，這本中文版出很久了)這本軟體管理經典。這本書的主要重點是說，在進度落後的專案中增加更多程式員，只會讓進度更加落後。這是因為當團體中有n個程式師時，溝通路徑的數量會變成n(n-1)/2，也就是以O(n^2)增加。
4. 不要把程式員升為程式經理。良好程式經理所需的技能(撰寫清楚的文章，外交手腕，對市場的察覺，對使用者的認同以及良好的使用介面設計)幾乎都不是良好程式員所需的。當然有人兩者都行，不過少之又少。
5. 別讓程式人員對程式經理報告。這是很微妙的錯誤。我在微軟當程式經理時設計了Excel的Visual Basic(VBA)策略，並且訂出涵蓋最微小細節的完整規格，詳細敘述應該如何在Excel裡實作VBA。我的規格大約有500頁。在Excel 5.0開發的巔峰時期，我估計每天早上有250人來上班，主要任務就是要實作我寫的這份龐大規格。我完全不知道這些人是誰，不過Visual Basic組就有十幾個人光是在寫這玩意的文件(更不用提寫Excel的文件或是全職負責說明檔內超連結的人了)。不過最誇張的是我位在這層層結構的「底層」。沒錯。沒有人要向我報告。如果想讓大家去做某件事，我必須說服他們這件事該做。當主開發師Ben Waldman不想做我規格定義的某個項目，他跳過不做就好了。當測試人員報怨規格中某個項目不可能做完整的測試，我就得去把這個項目簡化。如果這些人得向我報告，產品可能不會這麼好。...凝聚共識的決策型式卻是做對事的最好方法。
6. 當你一直往上把事情弄得太抽象，就會像上太空一樣沒有氧氣。有時候這些聰明的思想家就是停不下來，然後就創造出這些荒唐又無所不包的高層次宇宙景像，這些東西什麼都好，就是完全沒有實際的意義。
這種人我稱之為架構太空人。要他們寫程式或設計程式是難上更難，因為他們沒法子不想架構。叫太空人是因為他們活在氧氣層之上，我不知道這些人是怎麼呼吸的。他們通常在真正的大公司上班，只要這種公司才養得起大批不事生產，完全沒有貢獻的高學歷份子。
7. Alfie Kohn在哈佛商業評論中一篇已成為經典的文章中寫道：
過去三十年間至少有兩打以上的研究明確地指出，為了報酬而工作的人，表現不如完全不期望有報酬的人。
他的結論是「激勵(或者說賄賂)在職場上是行不通的」。DeMarco和Lister更進一步明白地表示，任何型式的職場競爭及獎懲方案，包括以前流行那種「在某人做對事時馬上獎勵」的把戲，所帶來的傷害都大過好處。給某些人正面激勵 (比如愚蠢的公開頒獎儀式)暗示他們其實只是為了拿那個壓克力獎牌才有表現；也暗示他們在工作上不夠獨立，要有甜頭才會努力；這實在是既侮辱又貶低人格。
8. QA的主管應該有否定權，可以阻止發行不合格的軟體。
9. 就個人層次來說，你曾經注意過某件事嗎？叫某人做一個工作可以做得很好，可是如果給他兩個工作，他會把其中一個做好卻忽略另一個，不然就是兩件工作都做得很慢，慢到你覺得懶鬼都比他勤勞。這是因為程式設計的工作就是需要很長的切換時間。
10. Netscape 6.0第一個公開的beta版終於出來了。5.0版從來沒出現過，最後一版重大改版是大約三年前發行的4.0版。在Internet世界裡三年的時間長得可怕。就在這段時間中，Netscape只能無望地坐看市場佔有率直線下降。...他們做了一個每家軟體公司都可能犯的一個最糟的策略錯誤：
他們決定把程式從頭重寫過。
11. 讀程式比寫程式困難
12. 新程式碼比舊程式碼好的想法顯然是很荒唐的。舊程式碼已經被用過也被測試過。很多問題都已被找出來並被修好。它並沒有什麼問題，不會因為在你的硬碟裡放久了就生出新的問題。...當你把程式碼丟掉從頭重寫時，其實是把這所有的知識都丟掉了。這所有已修正的問題，好幾年的寫程式的成果。...你會讓出市場領導地位。你會把兩三年的時間當禮物送給競爭者。相信我，軟體的一年可是很長的。...你會讓自己陷入一個極端危險的位置，到時候會有很多年都只能發行舊版程式，完全無法因應市場需求的新功能而改變策略，因為你沒有可以發行的程式。這段時期最好還是把公司收起來算了。...你會浪費大量的資金去撰寫已有的程式。
13. 你一定要記住，在要從頭重新開始時，完全沒有理由相信這次會做得比第一次好。首先你的程式團隊根本不可能和當初相同，所以並不會真的有「更多的經驗」。你其實只會把大部份的舊錯重新再犯一次，另外再多加一些舊版本沒有的新問題。
這本書實在是太精采了，一堆名言，下篇待續。
1. 在很多程式開發組織中，出現設計爭議時，總沒有人願意做出決策(通常都是因為一些「政治理由」)，所以開發人員只去做那些沒有爭議的項目。
2. 當你和整組人一起建立產品時，通常每個人都會各有所好，因而產生各式各樣真正或虛構的必備心愛功能，如果要將這些功能全部都做出來，恐怕永遠做不完而且要花很多很多的錢。所以你必須馬上開始刪功能，而刪功能的最佳方法就是利用規格的「非目標」章節，列出我們不打算做的東西。
3. 1980年代當微軟開始快速成長時，那裡每個人都讀過The Mythical Man-Month(人月神話，這本中文版出很久了)這本軟體管理經典。這本書的主要重點是說，在進度落後的專案中增加更多程式員，只會讓進度更加落後。這是因為當團體中有n個程式師時，溝通路徑的數量會變成n(n-1)/2，也就是以O(n^2)增加。
4. 不要把程式員升為程式經理。良好程式經理所需的技能(撰寫清楚的文章，外交手腕，對市場的察覺，對使用者的認同以及良好的使用介面設計)幾乎都不是良好程式員所需的。當然有人兩者都行，不過少之又少。
5. 別讓程式人員對程式經理報告。這是很微妙的錯誤。我在微軟當程式經理時設計了Excel的Visual Basic(VBA)策略，並且訂出涵蓋最微小細節的完整規格，詳細敘述應該如何在Excel裡實作VBA。我的規格大約有500頁。在Excel 5.0開發的巔峰時期，我估計每天早上有250人來上班，主要任務就是要實作我寫的這份龐大規格。我完全不知道這些人是誰，不過Visual Basic組就有十幾個人光是在寫這玩意的文件(更不用提寫Excel的文件或是全職負責說明檔內超連結的人了)。不過最誇張的是我位在這層層結構的「底層」。沒錯。沒有人要向我報告。如果想讓大家去做某件事，我必須說服他們這件事該做。當主開發師Ben Waldman不想做我規格定義的某個項目，他跳過不做就好了。當測試人員報怨規格中某個項目不可能做完整的測試，我就得去把這個項目簡化。如果這些人得向我報告，產品可能不會這麼好。...凝聚共識的決策型式卻是做對事的最好方法。
6. 當你一直往上把事情弄得太抽象，就會像上太空一樣沒有氧氣。有時候這些聰明的思想家就是停不下來，然後就創造出這些荒唐又無所不包的高層次宇宙景像，這些東西什麼都好，就是完全沒有實際的意義。
這種人我稱之為架構太空人。要他們寫程式或設計程式是難上更難，因為他們沒法子不想架構。叫太空人是因為他們活在氧氣層之上，我不知道這些人是怎麼呼吸的。他們通常在真正的大公司上班，只要這種公司才養得起大批不事生產，完全沒有貢獻的高學歷份子。
7. Alfie Kohn在哈佛商業評論中一篇已成為經典的文章中寫道：
過去三十年間至少有兩打以上的研究明確地指出，為了報酬而工作的人，表現不如完全不期望有報酬的人。
他的結論是「激勵(或者說賄賂)在職場上是行不通的」。DeMarco和Lister更進一步明白地表示，任何型式的職場競爭及獎懲方案，包括以前流行那種「在某人做對事時馬上獎勵」的把戲，所帶來的傷害都大過好處。給某些人正面激勵 (比如愚蠢的公開頒獎儀式)暗示他們其實只是為了拿那個壓克力獎牌才有表現；也暗示他們在工作上不夠獨立，要有甜頭才會努力；這實在是既侮辱又貶低人格。
8. QA的主管應該有否定權，可以阻止發行不合格的軟體。
9. 就個人層次來說，你曾經注意過某件事嗎？叫某人做一個工作可以做得很好，可是如果給他兩個工作，他會把其中一個做好卻忽略另一個，不然就是兩件工作都做得很慢，慢到你覺得懶鬼都比他勤勞。這是因為程式設計的工作就是需要很長的切換時間。
10. Netscape 6.0第一個公開的beta版終於出來了。5.0版從來沒出現過，最後一版重大改版是大約三年前發行的4.0版。在Internet世界裡三年的時間長得可怕。就在這段時間中，Netscape只能無望地坐看市場佔有率直線下降。...他們做了一個每家軟體公司都可能犯的一個最糟的策略錯誤：
他們決定把程式從頭重寫過。
11. 讀程式比寫程式困難
12. 新程式碼比舊程式碼好的想法顯然是很荒唐的。舊程式碼已經被用過也被測試過。很多問題都已被找出來並被修好。它並沒有什麼問題，不會因為在你的硬碟裡放久了就生出新的問題。...當你把程式碼丟掉從頭重寫時，其實是把這所有的知識都丟掉了。這所有已修正的問題，好幾年的寫程式的成果。...你會讓出市場領導地位。你會把兩三年的時間當禮物送給競爭者。相信我，軟體的一年可是很長的。...你會讓自己陷入一個極端危險的位置，到時候會有很多年都只能發行舊版程式，完全無法因應市場需求的新功能而改變策略，因為你沒有可以發行的程式。這段時期最好還是把公司收起來算了。...你會浪費大量的資金去撰寫已有的程式。
13. 你一定要記住，在要從頭重新開始時，完全沒有理由相信這次會做得比第一次好。首先你的程式團隊根本不可能和當初相同，所以並不會真的有「更多的經驗」。你其實只會把大部份的舊錯重新再犯一次，另外再多加一些舊版本沒有的新問題。
這本書實在是太精采了，一堆名言，下篇待續。
星期三, 7月 28, 2010
約耳趣談軟體
最近在看這本書，雖然說基本上書裡的內容都可以從約耳的blog讀到，但是有本書在手上翻感覺還是不一樣。
這本書基本上是在講一些開發及管理軟體project時的一些「實務經驗」，還有一些法則，有在軟體公司上班一段時間的看了這本書一定會會心一笑，即使是在國內數一數二的大型軟體公司，約耳所提到一些對軟體開發及管理有害的事情還是不斷再發生...
http://local.joelonsoftware.com/mediawiki/index.php/%E9%A6%96%E9%A0%81
有興趣的可以到這個網頁看看^^
貼一張一點關係都沒有的圖
這本書基本上是在講一些開發及管理軟體project時的一些「實務經驗」，還有一些法則，有在軟體公司上班一段時間的看了這本書一定會會心一笑，即使是在國內數一數二的大型軟體公司，約耳所提到一些對軟體開發及管理有害的事情還是不斷再發生...
http://local.joelonsoftware.com/mediawiki/index.php/%E9%A6%96%E9%A0%81
有興趣的可以到這個網頁看看^^
貼一張一點關係都沒有的圖
星期一, 7月 12, 2010
Trigger battle
雖然已經把整個架構改成可以支援隨時進入另一個場景，不過還沒做任何可以觸發的點，所以開始在地圖上擺些主角之外的角色...
擺了其他角色後才發現，有很多問題要解決，例如這角色只是一般NPC，不會觸發戰鬥的，和主角接觸時要有物理碰撞之類的，一大堆東西要做...
星期六, 7月 10, 2010
星期五, 7月 09, 2010
SkyX and Game state control
很久沒更新...
把SkyX給整進來了，然後主程式的架構大改，為了要能控制game的state跟flow，現在貼出來的是game其中的一個state，目前程式可以隨時切換到另一個state，例如進入戰鬥，now loading畫面等等，不過就只有主架構做好而已，還有一堆memory leak跟一堆小bug要修...
距離一個RPG還遠的很...
把SkyX給整進來了，然後主程式的架構大改，為了要能控制game的state跟flow，現在貼出來的是game其中的一個state，目前程式可以隨時切換到另一個state，例如進入戰鬥，now loading畫面等等，不過就只有主架構做好而已，還有一堆memory leak跟一堆小bug要修...
距離一個RPG還遠的很...
星期二, 7月 06, 2010
星期一, 7月 05, 2010
提離職了
結果整早都在聽老闆慰留，下午有一半時間在聽老闆的老闆慰留...
我如果還想留就不會提離職了，腦袋不知道在想啥。還有人說要升我職等到跟我老闆一樣，讓我比較有力可以做監督或是諮詢的角色，說實話，我很討厭這種角色或是位子，我並不喜歡說服別人，雖說我該講的都會講，而且半年多前project還沒開始就講完了，但是沒人聽進去，搞到現在我的"預言"一一成真才在求我留下來幫忙把下一版run得更順一些XD
這些事情應該是manager的責任吧....哈哈
平常事情我在做，會我在開，數據或是報告也都是我在弄，弄得要死要活的時候沒人摸我頭，提離職了才在強力慰留...
接下來找個符合自己興趣而且學到東西的工作吧，Trend Micro三年多，從公司那邊，比較technical的都沒學到，倒是一堆亂七八糟的process看了一堆，大公司也沒有比較厲害。
我如果還想留就不會提離職了，腦袋不知道在想啥。還有人說要升我職等到跟我老闆一樣，讓我比較有力可以做監督或是諮詢的角色，說實話，我很討厭這種角色或是位子，我並不喜歡說服別人，雖說我該講的都會講，而且半年多前project還沒開始就講完了，但是沒人聽進去，搞到現在我的"預言"一一成真才在求我留下來幫忙把下一版run得更順一些XD
這些事情應該是manager的責任吧....哈哈
平常事情我在做，會我在開，數據或是報告也都是我在弄，弄得要死要活的時候沒人摸我頭，提離職了才在強力慰留...
接下來找個符合自己興趣而且學到東西的工作吧，Trend Micro三年多，從公司那邊，比較technical的都沒學到，倒是一堆亂七八糟的process看了一堆，大公司也沒有比較厲害。
星期三, 6月 30, 2010
星期日, 6月 27, 2010
星期五, 6月 18, 2010
星期六, 5月 29, 2010
加班成常態
禮拜六又要加班了，感覺現在好像隔周假日都要加班Orz
目前這個project看來十分不妙，找來的救火隊都是一些需要人救的...感覺反而讓事情更多、更複雜。
然後上面的講話一整個矛盾，說什麼第一重要的是quality，再來是performance，然後才是detection rate，底下都在笑說最重要的是meet schedule吧，照現在的情況，「品質」跟「如期出貨」根本就是無法兩得，東西都做不出來了，還品質哩！
然後還有忽然飛進來要做的新功能，公司最上頭的只有一句話，不能delay，schedule還是照常，要多少人都給 XD
那全公司的人一起做不就可以一天就做完了嗎，這主意真棒，原來schedule其實可以用人頭乘以工作時數輕鬆的算出來！！
目前這個project看來十分不妙，找來的救火隊都是一些需要人救的...感覺反而讓事情更多、更複雜。
然後上面的講話一整個矛盾，說什麼第一重要的是quality，再來是performance，然後才是detection rate，底下都在笑說最重要的是meet schedule吧，照現在的情況，「品質」跟「如期出貨」根本就是無法兩得，東西都做不出來了，還品質哩！
然後還有忽然飛進來要做的新功能，公司最上頭的只有一句話，不能delay，schedule還是照常，要多少人都給 XD
那全公司的人一起做不就可以一天就做完了嗎，這主意真棒，原來schedule其實可以用人頭乘以工作時數輕鬆的算出來！！
星期一, 5月 17, 2010
六日加班了兩天
兩天都在公司超過10小時，雖然10小時跟別的公司比起來好像不多，但我這個人做事講求效率，基本上只要在公司，就是火力全開在做事。
大家來加班的其實也都還滿辛苦的，不過還是有人請了假，剛好也是個幾乎沒戰力但是整天都很忙的人，所以感覺沒差。
現在弊公司假日來加班不補假了，有人反映補假也休不到，說實話，我是覺得補假ok，但是自己要找時間休，有的人就是project做完或是剛開始不忙時都不休，去公司閒閒沒事做，平常project在忙就會生病請病假，特休才會積一堆啊，我每年都可以休完....去年的特休假，病假進公司快四年只請過兩次還三次。
不補假改成補薪水，不過上個月薪水入帳我稍微算了一下，竟然是月薪除以30，一個月工作天22天，除30還虧真多，不過講話比較大聲的人喜歡補薪水，所以老闆也就決定整個team都補薪水了...
難道沒有人去算一下補薪水比較虧嗎？
大家來加班的其實也都還滿辛苦的，不過還是有人請了假，剛好也是個幾乎沒戰力但是整天都很忙的人，所以感覺沒差。
現在弊公司假日來加班不補假了，有人反映補假也休不到，說實話，我是覺得補假ok，但是自己要找時間休，有的人就是project做完或是剛開始不忙時都不休，去公司閒閒沒事做，平常project在忙就會生病請病假，特休才會積一堆啊，我每年都可以休完....去年的特休假，病假進公司快四年只請過兩次還三次。
不補假改成補薪水，不過上個月薪水入帳我稍微算了一下，竟然是月薪除以30，一個月工作天22天，除30還虧真多，不過講話比較大聲的人喜歡補薪水，所以老闆也就決定整個team都補薪水了...
難道沒有人去算一下補薪水比較虧嗎？
星期四, 5月 13, 2010
週休0日
了不起的決定!
這個週末假日要泡湯了，六日都要去上班，有人看起來還很高興，高興是應該的，畢竟那傢伙有沒有去上班對project的進度沒有太大差別，加班可以多賺錢，何樂不為！
這project從還沒開始就找過我跟幾位做過前面幾版的人估過schedule，依照當時的人頭，我們都估到九月底十月初才有機會做完，但是我現在回頭看起來，我真的錯估了，現在這批人戰鬥力實在太弱，依照現在的情況雖然上面manager一直在找人進來，但都是一堆幾乎無戰鬥力甚至或拖累其他有戰力的...人頭(我實在不想罵)。
現在人頭數量夠了，但是一堆無戰力人員，我看要如期七月底結束這個project，真的只能多去燒香....
我又忘了一件事，這project其實是可以如期完成的，依照經驗，quality不夠照樣可以出貨，之後再修就好了，就當消費者是白老鼠!!
這個週末假日要泡湯了，六日都要去上班，有人看起來還很高興，高興是應該的，畢竟那傢伙有沒有去上班對project的進度沒有太大差別，加班可以多賺錢，何樂不為！
這project從還沒開始就找過我跟幾位做過前面幾版的人估過schedule，依照當時的人頭，我們都估到九月底十月初才有機會做完，但是我現在回頭看起來，我真的錯估了，現在這批人戰鬥力實在太弱，依照現在的情況雖然上面manager一直在找人進來，但都是一堆幾乎無戰鬥力甚至或拖累其他有戰力的...人頭(我實在不想罵)。
現在人頭數量夠了，但是一堆無戰力人員，我看要如期七月底結束這個project，真的只能多去燒香....
我又忘了一件事，這project其實是可以如期完成的，依照經驗，quality不夠照樣可以出貨，之後再修就好了，就當消費者是白老鼠!!
星期二, 5月 04, 2010
OGRE Addons - Hydrax
很棒的addon! 接下來看看有沒有辦法整合進來
五月七號更新：查了一下Hydrax跟SkyX的License, 結果是LGPL，看來還是不要用的好，以免以後出問題...
星期一, 5月 03, 2010
星期二, 4月 27, 2010
星期一, 4月 26, 2010
OGRE 1.7 terrain + OgreNewt HeightField
弄的差不多了，1.7的terrain + OgreNewt HeightField，接下來就可以在地形上玩各種物理碰撞了XD
不過paging的部分還沒弄，可能還要花一點功夫Orz
不過paging的部分還沒弄，可能還要花一點功夫Orz
跳針好文一篇
馬：蔡主席你們一直抹黑我們會開放農產品衝擊農業，但你們民進黨執政八年開放了936
項農產品進口，我上任後是一項都沒有開放。結果毒奶粉進口，我們卻簽好了兩岸協定
保障食品安全。
蔡：馬總統這問題你講了半年，我們回答很多次，可見你都沒有聽進去。你們執政時已經
開放四百多項，我們上任後因為要配合加入WTO，選擇四百多項對最沒有傷害的產品，馬
這些動物等等，對台灣的農業生產並沒有很嚴重的衝擊，沒有開放的都是屬於敏感項目。
蔡：我當陸委會主委時，很清楚記得很多國民黨立委絡繹不絕給我施壓力，要我開放中國
農產品，我們都擋下來了。自由貿易協定就是規定十年內要開放九成市場，將來兩千多項
農產品只能剩下兩百項在禁止清單，我們沒開放的敏感項目有六百多項都要開放了，
蔡：你怎能保障在不違反國際協定下，禁止敏感農產品開放？中國為什麼要讓利給我們呢
？其他國家競爭夥伴會怎麼想呢？
馬：很高興蔡主席剛剛終於公開承認九百多項是你們開放的，將來如果你們民進黨在媒體
上再講抹黑的話，你是不是要負責？
項農產品進口，我上任後是一項都沒有開放。結果毒奶粉進口，我們卻簽好了兩岸協定
保障食品安全。
蔡：馬總統這問題你講了半年，我們回答很多次，可見你都沒有聽進去。你們執政時已經
開放四百多項，我們上任後因為要配合加入WTO，選擇四百多項對最沒有傷害的產品，馬
這些動物等等，對台灣的農業生產並沒有很嚴重的衝擊，沒有開放的都是屬於敏感項目。
蔡：我當陸委會主委時，很清楚記得很多國民黨立委絡繹不絕給我施壓力，要我開放中國
農產品，我們都擋下來了。自由貿易協定就是規定十年內要開放九成市場，將來兩千多項
農產品只能剩下兩百項在禁止清單，我們沒開放的敏感項目有六百多項都要開放了，
蔡：你怎能保障在不違反國際協定下，禁止敏感農產品開放？中國為什麼要讓利給我們呢
？其他國家競爭夥伴會怎麼想呢？
馬：很高興蔡主席剛剛終於公開承認九百多項是你們開放的，將來如果你們民進黨在媒體
上再講抹黑的話，你是不是要負責？
星期五, 4月 23, 2010
OGRE 1.7 terrain
弄了我半天，1.6之前只要直接set 一個cfg檔就可以畫出個簡單的terrain，1.7搞得好麻煩，雖然說新增了很多feature啦。
不過沒有新的tutorial或是usage document...搞了老半天才知道怎麼用，實在好累，先把code貼上來，以免過陣子忘記...
mTerrain = OGRE_NEW Ogre::Terrain(sceneMgr);
Ogre::Image img;
img.load("terrain.png", Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME);
Vector3 lightdir(0.55, -0.3, 0.75);
lightdir.normalise();
Light* l = sceneMgr->createLight("tstLight");
l->setType(Light::LT_DIRECTIONAL);
l->setDirection(lightdir);
l->setDiffuseColour(ColourValue::White);
l->setSpecularColour(ColourValue(0.4, 0.4, 0.4));
sceneMgr->setAmbientLight(ColourValue(0.2, 0.2, 0.2));
Ogre::Terrain::ImportData defaultimp;
/*...set the ImportData information...*/
mTerrain->prepare(defaultimp);
mTerrain->load();
/*...set the blend map...*/
blendMap0->dirty();
blendMap1->dirty();
blendMap0->update();
blendMap1->update();
mTerrain->freeTemporaryResources();
這blog貼code有沒有啥好方法啊?
貼張圖，1.7的terrain有支援normal map跟light map，而且加入了paging manager，以後就可以做大型場景了，bye bye PLSM.
不過沒有新的tutorial或是usage document...搞了老半天才知道怎麼用，實在好累，先把code貼上來，以免過陣子忘記...
//這個改成non-static function了，而且如果不在create terrain前呼叫，會導致run time error，
//而且這error從message或是windbg都看不出來怎麼死的，死在singleton裡，看到的人鐵定
//覺得莫名其妙XD
TerrainGlobalOptions* mTerrainGlobals = OGRE_NEW TerrainGlobalOptions();mTerrain = OGRE_NEW Ogre::Terrain(sceneMgr);
Ogre::Image img;
img.load("terrain.png", Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME);
Vector3 lightdir(0.55, -0.3, 0.75);
lightdir.normalise();
Light* l = sceneMgr->createLight("tstLight");
l->setType(Light::LT_DIRECTIONAL);
l->setDirection(lightdir);
l->setDiffuseColour(ColourValue::White);
l->setSpecularColour(ColourValue(0.4, 0.4, 0.4));
sceneMgr->setAmbientLight(ColourValue(0.2, 0.2, 0.2));
Ogre::Terrain::ImportData defaultimp;
/*...set the ImportData information...*/
mTerrain->prepare(defaultimp);
mTerrain->load();
/*...set the blend map...*/
blendMap0->dirty();
blendMap1->dirty();
blendMap0->update();
blendMap1->update();
mTerrain->freeTemporaryResources();
這blog貼code有沒有啥好方法啊?
貼張圖，1.7的terrain有支援normal map跟light map，而且加入了paging manager，以後就可以做大型場景了，bye bye PLSM.
星期六, 4月 17, 2010
原來不用測底層
前幾天老大跟leader說我們product的QA不用測底層!!!
一般軟體有介面，產品跟底層幾個layer，拿"小算盤"來說，可能會有一個專門計算數學的底層API，然後使用者介面跟底層間可能有個產品層做些error handling之類的工作，使用者透過介面輸入1+1，產品層可能先檢查一下"1"是不是比integer最大值還大，比最小值還小，"+"是不是合法的operator，1+1這個算式格式是不是合法之類的，然後呼叫底層去算答案。
底層不用測!!!真是太棒了，所以1+1算出來不是2這件事我們可以不用理!
我真的覺得這個project前途一片光明，反正UI會work就好了，在加上測些基本的function，沒問題，絕對可以準時完成這個project!!
追加：昨天leader一早開會就生氣了，當著所有team member的面說QA們給我小心點，好好測，他昨天隨便測一下就一堆bug XD
好笑的是，那個bug跟"產品"還有"介面"關係不大...
一堆feature本來就還沒完成，而且還有一堆test case還沒執行，這個該做一年的project才開始一個月，就已經有人受不了了XD (雖然一年被壓縮成五個月不到)
況且這傢伙還把他負責的module丟給outsource的人.... 已經有人在講他什麼都沒own要他做啥了...XD
一般軟體有介面，產品跟底層幾個layer，拿"小算盤"來說，可能會有一個專門計算數學的底層API，然後使用者介面跟底層間可能有個產品層做些error handling之類的工作，使用者透過介面輸入1+1，產品層可能先檢查一下"1"是不是比integer最大值還大，比最小值還小，"+"是不是合法的operator，1+1這個算式格式是不是合法之類的，然後呼叫底層去算答案。
底層不用測!!!真是太棒了，所以1+1算出來不是2這件事我們可以不用理!
我真的覺得這個project前途一片光明，反正UI會work就好了，在加上測些基本的function，沒問題，絕對可以準時完成這個project!!
追加：昨天leader一早開會就生氣了，當著所有team member的面說QA們給我小心點，好好測，他昨天隨便測一下就一堆bug XD
好笑的是，那個bug跟"產品"還有"介面"關係不大...
一堆feature本來就還沒完成，而且還有一堆test case還沒執行，這個該做一年的project才開始一個月，就已經有人受不了了XD (雖然一年被壓縮成五個月不到)
況且這傢伙還把他負責的module丟給outsource的人.... 已經有人在講他什麼都沒own要他做啥了...XD
星期五, 4月 09, 2010
星期四, 4月 08, 2010
應該差不多了
了不起的公司策略
了不起的團隊
了不起的管理者
最近又聽到一個很重要的OEM business輸給competitor，technical跟marketing都贏不了別人，公司內部marketing又很喜歡challenge RD，完全不尊重技術人員，真的幾位懂技術的說的話上面聽不太進去，全押寶在虛無飄渺的雲端...
後面K開頭的公司快追上來，跟S開頭的距離也越拉越大，我身處這個「重要產品」的團隊也沒啥向心力，基本上這些成員的戰鬥力輸以前那些一大截。
我想今明兩年應該會是關鍵吧，T公司壓寶的地方真的可以讓一般end user買單，真的有benefit到product的performance跟detection rate上面，要不然應該會快速的往下墜吧...
不過依照目前的管理層來看....科科
了不起的團隊
了不起的管理者
最近又聽到一個很重要的OEM business輸給competitor，technical跟marketing都贏不了別人，公司內部marketing又很喜歡challenge RD，完全不尊重技術人員，真的幾位懂技術的說的話上面聽不太進去，全押寶在虛無飄渺的雲端...
後面K開頭的公司快追上來，跟S開頭的距離也越拉越大，我身處這個「重要產品」的團隊也沒啥向心力，基本上這些成員的戰鬥力輸以前那些一大截。
我想今明兩年應該會是關鍵吧，T公司壓寶的地方真的可以讓一般end user買單，真的有benefit到product的performance跟detection rate上面，要不然應該會快速的往下墜吧...
不過依照目前的管理層來看....科科
星期日, 3月 28, 2010
星期四, 3月 25, 2010
一樣是五年
俄羅斯小公司 五年進逼趨勢科技
「明年，卡巴斯基的市占率將超過趨勢科技，成為全球第三大防毒軟體公司！」十二月初，在莫斯科列寧大道、俄羅斯第一大防毒軟體公司卡巴斯基實驗室總部 （Kaspersky Lab HQ，簡稱卡巴斯基）記者會上大膽宣告的，不是粗獷豪邁的創辦人尤金‧卡巴斯基（Eugene Kaspersky），而是銀行家出身、作風向來保守謹慎的營運長尤金‧布亞欽（Eugene Buyakin）。
根據國際數據機構 IDC的統計資料，卡巴斯基目前在世界資訊安全市場中以六％的市占率排名第四，與第三名的趨勢科技只有不到一個百分點的差距。
上文轉自商業週刊（第1152期2009/12/21）--產業焦點--科技動態
http://www.businessweekly.com.tw/webarticle.php?id=38730
五年
雲端運算成利器 張明正：趨勢科技5年內成全球最大資安公司
2010/03/17-馬培治
才端出未來3年營收將倍增至20億美元增長計畫的全球次大資訊安全軟體業者趨勢科技(Trend Micro)，董事長張明正發下豪語，認為在雲端運算(Cloud Computing)潮流的帶動...
以上轉自DIGITIMES, http://www.digitimes.com.tw/tw/dt/n/shwnws.asp?id=0000174499_DCV5X1GT8Q1HSRLF5DLGO&ct=1
TM現在應該是3rd，營收還輸S廠10倍以上吧...
星期三, 3月 24, 2010
May'n live
ASIA TOUR最後一站--台北
說實在的...場地的音響有夠爛，高音出不來，低音糊成一團，完完全全糟蹋了May'n的好嗓子，以後台灣的live真的都要好好考慮一下了，我寧願飛去日本看live...
對了，這個場地是「華山藝文中心」
說實在的...場地的音響有夠爛，高音出不來，低音糊成一團，完完全全糟蹋了May'n的好嗓子，以後台灣的live真的都要好好考慮一下了，我寧願飛去日本看live...
對了，這個場地是「華山藝文中心」
星期四, 3月 18, 2010
星期五, 3月 12, 2010
人家有加薪，敝公司有加班
經理們又要求禮拜六加班了Orz
平常日就已經常常加班了，昨天也是十點多才走...我六點半下班的決心還真容易被打破
我是覺得project schedule很緊沒錯，但是要加班應該先講要補什麼吧，補休、補錢都ok啊，都不講底下的員工誰敢提，久了好像就沒這回事了！
再說，schedule會弄到這種田地基本上都是resource不會分配，錯估task跟effort，怎麼看都是管理層面出了問題，所以有經驗的才會走光光，沒人想待原部門，只剩一堆沒經驗的在撐。
廢話不多說，104有很多欄位要填...
平常日就已經常常加班了，昨天也是十點多才走...我六點半下班的決心還真容易被打破
我是覺得project schedule很緊沒錯，但是要加班應該先講要補什麼吧，補休、補錢都ok啊，都不講底下的員工誰敢提，久了好像就沒這回事了！
再說，schedule會弄到這種田地基本上都是resource不會分配，錯估task跟effort，怎麼看都是管理層面出了問題，所以有經驗的才會走光光，沒人想待原部門，只剩一堆沒經驗的在撐。
廢話不多說，104有很多欄位要填...
星期三, 3月 10, 2010
OGRE Addons
目前決定會用PLSM2，PagedGeometry跟OgreNewt
基本上PagedGeometry已經在用了，但是要把Newton這個物理引擎整進來的時候遇到問題Orz，所以決定把Terrain的Scene Manager換成PLSM2。
這問題其實是...OgreNewt沒有wrap Newton對一般HeightMap的處理，也就是說，如果只用Ogre內建的scene manager產生的terrain，ogrenewt是沒辦法對其作物理運算，要不就是自己做一個mesh假裝是terrain，要不就是用ODE這個另外的engine，第三個在forum找到的方法就是用PLSM2來取代Ogre的terrain scene manager，所以搞了半天又要多弄一個addon進來Orz
然後PLSM2這東西目前基本上已經年久失修，document是有很多沒錯，但是一堆照著做卻會有更多問題的Orz
不過還好目前都解決了，花了好大功夫，所以目前這三個Addons都可以單獨build，也都稍微弄了個可以跑的demo，不過要把這三個弄在一起可能還要些功夫...而且我猜會遇到更多問題...
基本上PagedGeometry已經在用了，但是要把Newton這個物理引擎整進來的時候遇到問題Orz，所以決定把Terrain的Scene Manager換成PLSM2。
這問題其實是...OgreNewt沒有wrap Newton對一般HeightMap的處理，也就是說，如果只用Ogre內建的scene manager產生的terrain，ogrenewt是沒辦法對其作物理運算，要不就是自己做一個mesh假裝是terrain，要不就是用ODE這個另外的engine，第三個在forum找到的方法就是用PLSM2來取代Ogre的terrain scene manager，所以搞了半天又要多弄一個addon進來Orz
然後PLSM2這東西目前基本上已經年久失修，document是有很多沒錯，但是一堆照著做卻會有更多問題的Orz
不過還好目前都解決了，花了好大功夫，所以目前這三個Addons都可以單獨build，也都稍微弄了個可以跑的demo，不過要把這三個弄在一起可能還要些功夫...而且我猜會遇到更多問題...
星期一, 3月 08, 2010
Zero
最近公司大家都流行在桌上擺一罐可口可樂Zero
因為，今年全公司分紅是...零
CEO還特別寄一封信出來跟大家說去年做的爛，所以沒分紅...
而所謂的做的爛，基本上就是沒有達到去年所訂下的成長目標，也就是說，其實有成長，但沒有大頭們想要的那麼多就是了。
前天喝春酒抽獎也是比去年縮水了很多，我看獎金獎項加起來只有去年的三分之一吧，去年光10萬元現金就抽了十幾二十個，今年只有兩個，而且10萬就是最大獎...
我想稍微有實力的人應該會漸漸留不住了吧，畢竟沒分紅，這邊的薪水就真的只有14個月，跟其他公司真的差太多了，如果是天天可以輕鬆做做六點半下班還ok，問題是我連禮拜天都被叫去加班啊~~
差不多可以準備寫履歷了，一堆莫名其妙的策略，最賺錢的project只用幾隻沒經驗的小貓就想如期完成，全公司不管你多爛或是多努力都是拿一樣的分紅，春酒還有大頭上台說去年都沒有裁過一個人(我知道就三個了，聽說裁了5%)，希望大家共體時艱，我在台下也希望大頭們能體諒大家的荷包啊，沒股票，沒分紅，只有死薪水，跟公務員一樣，誰會想賣命做事...
從今天開始我看就準時下班吧^^
因為，今年全公司分紅是...零
CEO還特別寄一封信出來跟大家說去年做的爛，所以沒分紅...
而所謂的做的爛，基本上就是沒有達到去年所訂下的成長目標，也就是說，其實有成長，但沒有大頭們想要的那麼多就是了。
前天喝春酒抽獎也是比去年縮水了很多，我看獎金獎項加起來只有去年的三分之一吧，去年光10萬元現金就抽了十幾二十個，今年只有兩個，而且10萬就是最大獎...
我想稍微有實力的人應該會漸漸留不住了吧，畢竟沒分紅，這邊的薪水就真的只有14個月，跟其他公司真的差太多了，如果是天天可以輕鬆做做六點半下班還ok，問題是我連禮拜天都被叫去加班啊~~
差不多可以準備寫履歷了，一堆莫名其妙的策略，最賺錢的project只用幾隻沒經驗的小貓就想如期完成，全公司不管你多爛或是多努力都是拿一樣的分紅，春酒還有大頭上台說去年都沒有裁過一個人(我知道就三個了，聽說裁了5%)，希望大家共體時艱，我在台下也希望大頭們能體諒大家的荷包啊，沒股票，沒分紅，只有死薪水，跟公務員一樣，誰會想賣命做事...
從今天開始我看就準時下班吧^^
星期日, 2月 28, 2010
過年加班
今年農曆年又被要求去公司加班了...
不過加班第二天，竟然被老闆叫去談去年的考績Orz，這件事說給其他不同team的同事聽，大家都笑翻天，哪有加班來做這種事的，而且去年的考績怎麼都二月中了才在談XD，我只能說沒辦法，我老闆很忙，而且大家都不知道他在忙什麼。
談考績的時候我老闆講了些更有趣的事，他說我要加強presentation跟planning的能力XD
天啊，我怎麼覺得這句話是我的台詞Orz，整個team六七個人但是有50%以上的事情assign到我這裡來，這種planning的能力實在太厲害了，present data的時候還結結巴巴說不清楚，都要我在旁邊補充說明(反正data也都是我做的，有時連投影片也是)，我常常都覺得他好可憐，我乾脆幫他講就好了...
竟然說我要加強presentation跟planning....Orz
另一件有趣的事，他說接下來這個大版本中，XXX(team leader)、YYY跟我會是key man，要好好努力，他會把事情慢慢的交給team leader，然後team leader的事交給YYY跟我...
我很想問那manager要做啥？ 已經很多人私底下跟我抱怨我老闆到底在做啥了，為什麼很多該做的事沒做，該去的會議都是我去...其實我都不知道要怎麼回答，因為我也不曉得我老闆在忙什麼XD
很多該做的事情其實我都自己做planning跟schedule，然後再給他看，而他也只會說為什麼要做這麼久，解釋他也聽不進去，總之就是要凹可以更短時間完成，然後還要時常應付他「下班前的需求」，說實在我已經快忙不過來，搞到幾乎天天都加班了...
我老闆的「下班前需求」，指的就是，他下班的時候會過來我這邊看看，然後說「你還在啊，那幫我弄這個data，弄好以後寄給我」，而這個「弄一下」，可能就要我弄到十點，然後他老大七點就下班了，隔天只會寄封信說thx，有時還什麼都沒有，不過我也不屑他謝我啦。
不過加班第二天，竟然被老闆叫去談去年的考績Orz，這件事說給其他不同team的同事聽，大家都笑翻天，哪有加班來做這種事的，而且去年的考績怎麼都二月中了才在談XD，我只能說沒辦法，我老闆很忙，而且大家都不知道他在忙什麼。
談考績的時候我老闆講了些更有趣的事，他說我要加強presentation跟planning的能力XD
天啊，我怎麼覺得這句話是我的台詞Orz，整個team六七個人但是有50%以上的事情assign到我這裡來，這種planning的能力實在太厲害了，present data的時候還結結巴巴說不清楚，都要我在旁邊補充說明(反正data也都是我做的，有時連投影片也是)，我常常都覺得他好可憐，我乾脆幫他講就好了...
竟然說我要加強presentation跟planning....Orz
另一件有趣的事，他說接下來這個大版本中，XXX(team leader)、YYY跟我會是key man，要好好努力，他會把事情慢慢的交給team leader，然後team leader的事交給YYY跟我...
我很想問那manager要做啥？ 已經很多人私底下跟我抱怨我老闆到底在做啥了，為什麼很多該做的事沒做，該去的會議都是我去...其實我都不知道要怎麼回答，因為我也不曉得我老闆在忙什麼XD
很多該做的事情其實我都自己做planning跟schedule，然後再給他看，而他也只會說為什麼要做這麼久，解釋他也聽不進去，總之就是要凹可以更短時間完成，然後還要時常應付他「下班前的需求」，說實在我已經快忙不過來，搞到幾乎天天都加班了...
我老闆的「下班前需求」，指的就是，他下班的時候會過來我這邊看看，然後說「你還在啊，那幫我弄這個data，弄好以後寄給我」，而這個「弄一下」，可能就要我弄到十點，然後他老大七點就下班了，隔天只會寄封信說thx，有時還什麼都沒有，不過我也不屑他謝我啦。
星期四, 2月 18, 2010
星期二, 2月 16, 2010
星期日, 1月 03, 2010
後遺症
這篇本來去年要發的，不過最近實在常加班，回到家又忙著玩太13，所以delay好幾個禮拜才寫Orz
果然開始有後遺症了，不過上面的大頭們好像還看不太出來問題點在哪裡...
敝公司開發了一年，即將要取代過去Px-cxllxn的產品，最近先出了個OEM版本給某家PC大廠，結果在人家工廠內測試就已經問題多多...
廢話，有Px-cxllxn經驗的老手都不見了，都是一些在這塊產品線沒經驗的人在做，今天出了問題才在檢討為什麼這些error handling沒有做進去，QA沒有測到。
在我看來，大概有百分之七十的問題，舊產品Px-cxllxn都是ok的，不會出問題，如果是換回過去那些老經驗的人來做，大概不會有這麼多問題，搞到人家A開頭的PC大廠退貨不用。
而為什麼有做過好幾版Px-cxllxn的人都一一離開了呢...?
果然開始有後遺症了，不過上面的大頭們好像還看不太出來問題點在哪裡...
敝公司開發了一年，即將要取代過去Px-cxllxn的產品，最近先出了個OEM版本給某家PC大廠，結果在人家工廠內測試就已經問題多多...
廢話，有Px-cxllxn經驗的老手都不見了，都是一些在這塊產品線沒經驗的人在做，今天出了問題才在檢討為什麼這些error handling沒有做進去，QA沒有測到。
在我看來，大概有百分之七十的問題，舊產品Px-cxllxn都是ok的，不會出問題，如果是換回過去那些老經驗的人來做，大概不會有這麼多問題，搞到人家A開頭的PC大廠退貨不用。
而為什麼有做過好幾版Px-cxllxn的人都一一離開了呢...?
訂閱：
文章 (Atom)