活著~~

活著是由大陸的作家 余華 所著。
本書主要在講述主人翁福貴的一生。他如何從田僑仔，然後敗光家產，接著被抓去當兵，
後來又怎樣回到家中，直到最後剩下的孤單一人。

在敗光家產後，他想著如何養活自己母親和妻兒，於是向地主租了五畝田地來耕作。
在被抓去打國共戰爭時，他想著如何活著回家，於是在槍林彈雨中搶著小米及大餅。
在中國解放後，回到家的他，想著如何在超英趕美的大躍進中取得食物養活一家人。
在家人一個一個經他手落土於西村後，最後想著的只是如何單純的讓自己不會餓死。

這樣簡單、深刻的描述了福貴這一個小人物的一生，雖沒有引人入勝的精采情節，
但卻讓人愈讀愈無法釋手。

花了幾天時間看完後，在看完的當下讓我想起了雷洛探長最後在劇末問家僕的問題。
｢人這麼辛苦是為了什麼？｣
｢為了吃飯。｣

粗心可以殺死一條狗~~

這幾天發生一個事件，因為我的不細心及不夠完整的思維，讓我所屬的開發團隊，遭到二線人員的質疑，說我們的程式沒有quality。這讓我對我的團隊感到很抱歉，尤其是我的leader，因為他是首先第一個被質詢的人。

這件事情是這樣的，我們從B系統移植一個X功能到A系統中，負責人就是我。我在移植的過程中犯了一些過失：

1. 系統中提示文字的顯示迷思

因為A系統和B系統處理顯示的文字是使用不同的動態連結檔，剛好A系統的某個設定有問題，使得A系統會連結到錯誤資料夾中的檔案，也連帶讓X功能可能存在顯示不正常的機會。只是剛好我的電腦在那個錯誤的資料夾中，存在了對的檔案，所以移植到A系統的X功能，在我的電腦可以顯示正常，但測試人員的電腦就出現問題了。

è 我應該更細心的檢查程式碼，發現他們是使用不同的DLL，並檢查出A系統呼叫到錯誤資料夾中的檔案。這樣我就可以修改它，使其可以永遠顯示正常的文字。

2. 忽視一個重要錯誤的不應該

因為我的開發環境是Win7，而使用的開發語言是VB6，所以常常在發生由Win7建構出的程式，在執行時會造成一些錯誤。而我卻把這次的一個錯誤，誤認為是由於Win7所建構造成的，結果最後被發現其實是程式的bug。

è 我應該要用另一台XP電腦來建構這個程式，然後再加以測試。這樣就會發現到這個問題並不是由於win7的建構環境所造成，而是我乎叫某個函式的先後順序有誤所產生。

3. 忽視測試過程中每個數值變化的情況

在執行我想得到的測試案例時，我沒有注意到所有使用到的數值的變化，使得我沒有發現到，在寫入歷史紀錄時會誤用到預設的帳號，而不是真正當時在操作的使用者帳號。

è 我應該要更細心的查看每個數值得記錄與更動，只要稍微把每個資料都看過一遍，就一定會發現這個錯誤，但我沒有。

4. 思考到的使用案例不夠全面的後果

在測試的過程中我只著重在X功能本身的測試，沒有思考到與這個X功能有相關的其他功能。根據原本的設定，在X功能中設定某些資料後，啟動Y功能時，Y功能應該要讀取在X功能中設定的資料，並用這些資料來更新資料庫的數值。但因為我不夠全面的思維，沒有發現到Y功能這樣的行為沒有被啟動。

è 我應該更主動去瞭解X功能及與X功能相關的其他功能，並盡可能的找出這些功能的所有使用案例，如果可以依循使用案例來測試，這樣就可以避免掉產出半殘的X功能。

總結：

雖然大部分的問題，很多是由於我對於整個系統的架構和機制還不是很了解所造成，但這不應該作為藉口，因為現在負責的人是我。我應該要想辦法去瞭解，不過我卻沒有做到，只有簡單的測試一下，然後覺得看起來很OK應該沒問題了，這真的是要不得的想法。這些天來我也看了許多測試的書籍，發現上面我犯的許多錯誤，其實書中都有提到，也註明了這是許多測試人員會犯的通病，沒想到就真的發生在我身上了(雖然我是開發人員)。最後，這次的事件對我來說真的是一個很好的教訓，但也是一次很好的學習機會。希望這次的學習，可以讓我更加的成長，並在下次或將來開發時都能更加注意、更加細心地去思考及處理。

曾遇到的DB問題 (一)

三個跟DB相關的問題，兩個是我還在寫android時遇到的；一個則是在我開始寫VB6以後看到的。

(一)

當時是有一個ANR(Application Not Responding)的issue，後來根據log發現是因為發生DB lock，結果造成等待DB等到發生了ANR。那為什麼會發生DB lock呢？我記得當時我跟一位同事看code看了很久，看起來好像都沒有問題，直到一直查到源頭，另一個同事寫的存取DB的library，終於讓我們發現了一個問題。原本library的設計概念是把存取DB的類別使用singleton模式來實作，但是卻沒有將建構子的存取權限設為private，使得在開發Provider時誤用new來實體化DBHelper。

所以當多執行緒操作DB時，就可能發生new兩次實體的狀況。也就是說當A物件先使用DBHelper，然後B物件又使用DBHelper，接著就會發生DB lock。使得B物件無法使用DBHelper，於是他只好等待到天荒地老到發生ANR。發現了這個root cause後，我們便將建構子的存取權限設為private，並把要使用到DBHelper物件的程式碼，改為以getInstance來獲取實體，這個issue也就這樣解了。

(二)

第二個也是DB的問題，這個問題是在第一次使用該AP時才會發生的issue，而且還必須依照某一特定的步驟才會發生。問題是這樣的，有一個應用程式A，還有一個應用程式A的外掛程式B。當使用者還沒第一次執行過A之前，先使用了B就會發生B無法外掛到A的問題。這個問題很特殊，而且可能跟上面DB lock問題一起發生。我試了很久才終於找到這個issue的重覆產生步驟，因為它只會發生在A從來沒有執行過的情況下，而這個情況通常只會發生在剛刷完新ROM的機子中。

主要的原因是這樣的：

1. 在第一次執行A之前，A所需要用到的資料庫是完全不存在的(我想這應該只會發生在Android吧)。

2. 目前實作的機制是將可以外掛到A的來源資料儲存在DB中。因此，資料庫在創建時必須自動加入A可以接受外掛的來源，否則外掛程式皆無法外掛到A之中。

當A從沒被執行過，DB還沒產生出來時。在執行B的時候，B會透過一些機制來使用A的Provider，接著A會發現沒有DB存在，然後開始create一個DB。當DB建好後，再透過一些機制將外掛來源寫進DB中。也就是說，這是一個兩步驟的動作，所以當A只做到第一個動作時，B便開始想外掛進A，然後就會出現A發現DB中並沒有B可作為外掛來源的資料，於是拒絕B的外掛，並造成B外掛失敗。這個問題簡單來說，其實是因為多執行緒的時間差造成的問題。最後的解法是，當A確定DB建好且外掛來源也已經寫進資料庫中時，再發送一個訊息給B，讓B再做一次外掛即可解決。

我的成功可以複製 － 唐駿

Today, I read a book "My success can be replicated".
It is a biography for Jun Tang(唐駿), one of the best CEOs in China.
I think it is a good book for everybody, whatever you are students, engineers or managers.
I summarized some contents as follows:


1.成功的秘訣是什麼？做人簡單，做是勤奮。成功4+1：4分別代表智慧、勤奮、激情和機遇；1代表性格。

2.能考入重點大學固然很好，但是並非進到重點大學就可以解決你的問題，也不意味著到了非重點大學你的人生就缺少機會。

3.只有勤奮才能真正引領以實現人生的目標。其實每個人的智商都差不多，每天我比你多工作20%，也許就意味著我成功的機率多了50%。

4.大學裡的學習絕不只是簡單地把書本讀會。讀什麼專業固然重要，但是比這更重要的是培養自己學習的能力。

5.當周圍人沉迷於溫飽時，你應該去發現新的機會所在。如果你在一家公司裡感覺工作很安逸，你就需要尋找新的發展空間。

6.在一個人具備相當的經濟基礎、管理經驗、對未來方展的預見能力、對公司業務模式的深入理解和對市場的全面了解之前，個人創業並不是一種可取和可行的選擇。

7.每一個看似低的起點，都是通往更高峰的必經之路。任何時候都沒不能放下的成就。這種心態可以使人無往而不利。

8.第一份工作不是選一份好職業、不是選一份好薪水，而是一定要選一家好公司。因為一家好公司可以在各方面奠定你的職業基礎。

9.每個人的職業生涯一定要有良好的規劃，不能盲目努力。沒有目標地工作，在勤奮也沒有用，而且5年、10年以後，你會發現你還在原地踏步。

10.一個成就事業的人，最重要的素質是對工作的激情，而不是能力、責任心或者其他東西，雖然他們也不可或缺。

11.我們在企業裡要做得不是抱怨、不是提意見和建議，而是真正的對公司做一些實質性的改進。能提出問題，又能提出解決方案，且還能論證出方案可行性的人才會真正的被重用。

12.不僅做好自己的本職工作，還要替公司考慮哪些做的不合理或者不夠完善的地方。與上級長官溝通的規範，應該先和直屬長官溝通，在一級級地向上匯報。

13.真正的創新必然是基於對市場的了解，對客戶反饋的觀察，開發出來的產品一定要適應市場，提出的模式一定要能解決實現的問題。

14.一定要做自己最內行的東西，一定要在自己本身的職位上來提升自己。從技術做到管理，角色的轉變首先是一個學習的過程，其次是一個潛移默化、循序漸進的實踐過程。

15.許多了不起的成功，其實都靠點點滴滴的細小努力積累而成，作人就是這些細小努力中最重要的部分。向上、感恩、關心－這三種性格是做人最需要的。如果一個人能力不錯、性格又好，想不成功都很難。

如果我看得比別人遠，是因為我站在巨人的肩膀上~~

在｢上帝是數學家？｣的書中，有這樣一個可能的真相。
希望不會破壞大家對牛頓的尊敬(不過說不定大家已經因為微積分而恨透他了)。


在牛頓那個年代，有一個被牛頓視為頭號死敵的對手：多產的物理及生物學家羅伯特‧胡克。胡克曾指控牛頓數度剽竊他的構想（先是光的理論，後又加上萬有引力）。

一六七六年一月二十日，胡克在寫給牛頓的私人信件上宣稱：｢我想你和我（在光的理論方面）的構想都是針對同一個目標，亦即事實的發掘，我想我們也都可以忍受別人的反對。｣

而牛頓在一六七六年二月五日回給胡克的信中寫道：｢笛卡兒的成就是很大的一步（指笛卡兒對光的概念）。你已經增添了多種方法，特別是將薄板的顏色納入哲學考量。如果我看得比別人遠，是因為我站在巨人的肩膀上。｣

然而，胡克不但不是什麼巨人，還是個嚴重駝背的矮個子。
由此可見，牛頓這句流芳百世的名言可能只是想要嘲諷胡克，
並說明他覺得對胡克毫無虧欠的一句話而已！

一周七書 - 楔子

一周七書的連載終於開始了，希望不會在楔子以後就斷尾了~~


楔子

為什麼會有這次一周七書的計劃呢？這一切都是出自某一天的一個巧合，請聽我娓娓的道來。某個周末（其實也就前幾周而已），我從PPT上的一個板連到了Youtube上的一個影片：｢王道還：百年千書的科普與武俠｣，這是因應百年千書計畫的推廣所分享的影片。不過重點不是這個影片，而是Youtube會在正在撥放的影片旁邊列出相關的、你可能有興趣的影片。當時正好有一個相關影片吸引了我的注意，於是我在看完科普與武俠這個議題前就轉台了，真有點對不起王道還老師。雖然我也不清楚王道還老師的生平，但在幾天後的一個機會，我在書櫃中發現了一本書：槍炮、病菌與鋼鐵，正巧這本書就是由王道還老師所譯著。好，廣告結束，回到那個關鍵的影片上。

究竟是什麼影片的呢？就是｢台灣啟示錄 謝哲青｣。我想看過關鍵時刻節目的人應該都不陌生這個看起來斯文、講話謙虛有條理的文史工作者：謝哲青。我花了點時間看完了這個影片，也讓我更瞭解了一些關於謝哲青的生平，影片中他寫出了一句我很喜歡的語句：

每個人心中都有一方沃土　一畝荒蕪
唯有透過不斷地探索與追逐
我　才能填補內心那份巨大的虛空 － 謝哲青

除了這些內容外，哲青還介紹了他的書房，因此讓我有機會一窺他所收藏的千萬(元)書籍。此外，他也很大方的分享他寶貴的藏書與他看過的一些印象深刻的書籍。其中他提到一本書：｢在自己房間裡的旅行｣，而這本書也正是我這整個一周七書計畫的根源所在。由於對這本書內容的好奇心，我上了博客來網路書店查詢打算購買。有瀏覽過博客來網站的人應該都會發現，它常常會有很多促銷、折價活動、書展與贈品。剛好當時再送一個贈品【繆思十年‧經典再現】A4文件夾（一組四款），結果我完全被吸引了，於是很用力的湊出了｢陰陽師 瀧夜叉姬（上、下）｣及｢星塵｣。陰陽師，我想大家都很瞭解夢枕模老師的說故事能力；而星塵，則是在幾年前有改編成電影｢星塵傳奇｣，就這樣我的購物車裡有三本書（實際上是四本）。

一般來說，除了這些新加入到購物車的書外，通常我都會有幾本上一次沒有購買卻想看的書放在購物車中，打算下次購買。結果，想當然爾的結帳價格超過了兩千塊以上，於是｢零與無限大：許文龍幸福學｣、｢建築家安藤忠雄｣和｢蒼蠅王｣就默默的被我下放到｢下次再買清單｣。最後就剩下：｢國姓爺的寶藏｣、｢鬼太郎之妻｣和｢從謊言開始的旅程｣，但還是超過一千塊很多。於是我便在｢鬼太郎之妻｣和｢從謊言開始的旅程｣之中開始猶豫，但兩本真的都很想看，突然我豁出去了，我不管三七二十一就猛然的按下國內訂購按鈕，直接訂購了。很快的，一天後我拿到了我朝思暮想的【繆思十年‧經典再現】A4文件夾（一組四款），喔！不是，是六本書（其實是七本書）。

在自己房間裡的旅行　　　　　　－ 薩米耶‧德梅斯特
從謊言開始的旅程　　　　　　　－ 喜多川太
國姓爺的寶藏　　　　　　　　　－ 蘇上豪
星塵　　　　　　　　　　　　　－ 尼爾‧蓋曼
鬼太郎之妻　　　　　　　　　　－ 武良布枝
陰陽師　瀧夜叉姬（上）、（下）－ 夢枕模

我看的第一本書是，在自己房間裡的旅行。當時還沒有一周七書的計劃，不過當這本書看到三分之一左右的時候，我突然覺得，作者因為被禁足在自己家裡四十二天，所以有了這本書的出現，那我為什麼不能一口氣看完這七本書，然後寫出一本書來分享呢？就這樣我那從星期日到星期六，一周七天，漫遊於七本書中的旅程便如火如荼的展開了。

工作滿一年回憶錄之台積電篇

終於寫完了，沒想到寫得比宏達電篇還多，而且到後面很多都變心得分享了。反正就當作是自己的工作紀錄吧，因為很多部分應該都是蠻有用的，如果將來自己徬徨或疑惑時，看一看說不定可以引領我到另一片的海闊天空。


工作滿一年回憶錄之台積電篇
從宏達電到台積電，這中間的間隔只隔了一天，這也就表示我繳了一天的國民年金，不過這不是重點。不免俗的來描述一下到職的第一天。記得那天，我騎著車到了台積七廠的側門門口，然後停下車拿出公司寄給我的地圖，確認一下地點，接著就騎進了停車場內，直奔學習中心報到。跟到宏達電第一天一樣，人資先簡單的介紹公司，再來上一些人資安排的課程，中午則是吃便當，然後最重要的來了，上完課差不多六點，人資就說：｢今天就到這邊，大家可以回家去了，報到資料有缺繳的明天記得帶喔｣，聽完我就乖乖的回家了(原來下班後回家吃飯的感覺是這樣的啊！)。

到台積電沒多久我就發現了一件事，原來待在”辦公室”跟待在”公司”是差這麼多的啊！另外讓我很驚訝的是，我這個課竟然有舉辦樂活日的習俗，就是每個月找一天樂活一下，整個課一起出去玩。雖然才到台積電五個月，不過已經玩過不少地方，像是觀音鄉騎腳踏車之旅、到山上人家半日遊、到中秋內灣烤肉行等等。還有就是，每個新人都要在部門會議的時候準備PPT上台做自我介紹。當時還有一個比我早到的新人，因為我們兩個都會彈吉他，結果就被要求要在部門會議的自我介紹時上台表演。記得當時我彈了一首Drifting。

一開始到台積電其實很不習慣，因為早上八點半左右就要到公司，跟我在宏達電十點才到公司的習慣差很多。所以一開始我都會不小心在公司打起瞌睡，雖然說現在還是會但次數少很多了。另外還有一個很不習慣的是，要學習很多關於半導體製造流程的知識(domain knowledge)，這個真的讓我吃足苦頭，因為本科不是念電機沒有足夠的基礎知識，很多根本就是有聽沒有懂。不過慢慢的還是有些瞭解了，雖然現在還是不能完全瞭解，但我想總有一天應該是可以克服的。

此外，由於工作的時程往前推到八點半開始的緣故，我現在幾乎天天都可以回家吃晚餐，而且還有大把的晚上時間讓我消磨。除了偶而上網查一下半導體的一些知識(偶爾真的是偶爾)，剩下的時間則是跟在宏達電一樣看書學習，雖然現在看小說的時間比較多。另外，偶爾的上網查資料其實幾乎都查不太到，因為很多都是還在發展中的技術，且在公司也幾乎都算是機密，查得到才有鬼。不過真的要提一下現在的下班時間，因為提早的下班時間，讓我可以跟同事一起去報名公司開的風景畫課程或是騎車衝到台元科技園區聽謝哲青的演講。

至於在台積電學習到的內容，除了上面提到的domain knowledge外，在技術的部分倒是學得不多的，因為我分配到的工作主要是使用VB6，沒錯你沒看錯就是VB6，所以學好VB6還是可以吃的開的喔！其實還有Flex跟J2EE，不過我不負責寫這方面的程式，只是跟著隔壁的同事一起學而已。另外，由於VB6很容易上手，所以我常常會把空出的時間拿來學習Ruby、Javascript和Python，說是學習，其實也只是熟悉一下他們的語法，及試圖瞭解一些與JAVA和C很不一樣的設計概念。不過同時看三種語言，真的很容易把語法互相搞混，常常在寫Javascript時不小心寫成Ruby的語法，還會覺得很奇怪怎麼會無法執行呢？我想還是一次專注一種語言會比較好吧！

另外在在台積電還有一種技能是被非常重視的，就是軟實力。舉凡與user的溝通、和其他部門的協同合作、PPT內容的製作、上台報告的技巧 (下面我會稍微舉例說明) 等等，我想這些是我在台積電最大的收穫。雖然目前這些能力還不夠熟練，但我相信在這樣的環境下，一定可以愈來愈好的(其時是被多K幾次就會慢慢的好起來的)。

在台積電常常會有user來跟IT提需求，因此我們常常就需要跟他們一起討論，說是討論其實有點想吵架。不同於宏達電的工程師，我們可以很大聲的拒絕user的一些需求，或將其導向對IT較有優勢的局面。所以必須要有良好的domain knowledge及溝通能力才能不被user牽著走，甚至主導需求的走向。另外當user的需求有跨到不同部門(也就是跨系統)時，常常就必須要與其他部門的開發者一起開會討論實作的方式：你需要支援什麼部分；我需要提供什麼服務等。因此就必須要學會預約會議室、發會議通知(Meeting Notice)和會議記錄(Meeting Minutes)和主持會議等。

至於報告目前的工作進度的部分，這個是最困難的。你必須要製作PPT和練習報告，不然你可能很容易的就會跟報告論文一樣被釘在上面，更甚者可能直接下台一鞠躬。其中尤以PPT的製作最不容易，你不能只是描述性的或條列式的來撰寫，必須要附上很多圖來說明，因為這樣主管才可以比較快的瞭解你的狀況跟問題，如果都是字的話主管可能會看不下去。還有在問題的描述部分，最好要先說明現行的做法(AS-IS)是什麼、有什麼問題；未來解決以後(TO-BE)是怎樣的情況。另外，千萬不能只帶著問題去報告，不然你一定會被K到死，一定要連解決方案一起帶去，最好要有兩三種。而且在報告的時候，一定要提出你自己的想法及觀點(Pros. & Cons.)，然後說明你偏好的是哪一個解決方案，以及選擇的原因是什麼。

總結這個在宏達電和台積電的一年：在宏達電我得到了在硬實力方面的啟發，而在台積電則讓我得到了軟實力方面的啟發。有了這兩方面的啟發，讓我可以更有方向的來加強自己的能力。最後，很感謝宏達電和台積電的同事在這一年中的幫忙與照顧，尤其是宏達電的同事，有手機員購的時候記得通知一下，還有可以進場的時候也不忘提點一下小弟；至於台積電的同事，我想我們應該還有很長的路要一起走下去，彼此都要好好的加油囉！

工作滿一年回憶錄之宏達電篇

昨天11/1是我工作滿一年的日子，為了紀念它想說寫一個工作滿一年回憶錄，結果一不小心就寫了一大篇，索性將它分成宏達電篇和台積電篇。宏達電篇如大家所見的已經完成，希望我可以很快的完成台積電篇。


工作滿一年回憶錄之宏達電篇
不知不覺從開始上班(2011/11/1)到現在已經一年了，雖然不是都在同一間公司，但收穫一樣都很多。短短的一年我在宏達電待了七個月，在台積電待了五個月，很多人可能會覺得怎麼這麼沒定性不到一年就換工作了，關於這個部份我想之後可能會說明一下。

宏達電是我的第一份工作，也是第一個拿到offer的公司，雖然拿到offer後還是到處去面試，說是面試其實是順便去到其他地方晃晃、看看。結果這個舉動反而為難了我自己，在玩玩的過程中殺出了台灣網路認證這個程咬金，真的讓我左右為難了好一陣子，因為都是很不錯的公司。最後我還是因為地點的原故，放棄了位在台北的台灣網路認證，選擇了就近的宏達電。現在想想，用地點作為考量好像不那麼的明智，不過也很難說是好還是不好了。

我記得在宏達電的第一天，我一早七點多就坐火車到桃園總部報到，上了一些人資安排的課後，下午就坐計程車回到竹北辦公室。報到第一天雖然沒做什麼事，但我還是在公司待到了晚上九點，因為其他跟我一起進去的人(當時包含我有三個人一起到這個Team)都沒人提早下班。很快的在一個月內，我們三人組有一個人離職了；又很快了，在試用期內又有一個人離職了(至於他們離職的原因我就不詳述，因為每個人都有自己的規劃)。突然以前的三人組瞬間就剩下我一個，雖然我撐了很久，但還是在半年多一個月後，離開了我的第一份工作、我待的第一間公司。

雖然只有短短個七個月，但過很愉快，也學到很多知識與技術，而我學習到的這些東西，其實是等我到了台積電且多看了幾本書後才慢慢感覺出來。遙想當初，在剛到宏達電的前幾個月我還蠻焦慮的，因為很多東西都不會也不懂，當時每天八九點下班回家後，還會繼續的念書充實自己，不過愈念愈焦慮，愈念愈覺得自己什麼都不會。在這一段的鬼打牆後，我突然想通了，幹嘛囫圇吞棗的念一堆不知道在幹嘛的書。我應該踏踏實實的學習與累積經驗來充實自己，因為這樣才是真正最快的捷徑；而不是想著靠亂七八糟的方法在短時間內追上別人幾年的經驗，我想這樣的最終結果應該只會自取滅亡吧！(其實也沒這麼嚴重啦)

除了晚上的自我學習外，在宏達電我還學到了很多Android的開發技術，舉凡效能的改進、安全漏洞的填補等。還有就是公司要求使用的許多系統，像是公司自行開發的用來build整個ROM和用來prebuild apk(使用hudson系統)的持續整合系統、控制apk版本的Release系統、ITS(Issue Tracking System)系統、程式碼版本控制系統等等，我想這些系統很多在一般的小公司應該很難看到。除了這些系統外，還有主管推薦的兩本參考書：深入淺出物件導向程式設計和深入淺出設計模式。雖然在離職前我還是都沒有看完它們，但還是讓我學到了不少的觀念。最後很感謝就是讓我有機會一個人負責GoogleTask plugin這個AP，雖然在過程中發生了不少事，像是資料儲存機制的打掉重練、重建消失的刪除功能和實踐app update的機制等，不過真的讓我成長不少。

即便生活得很愉快也學到了很多東西，但我還是轉換了跑道到了台積電。會有這樣的轉變，其實都是一些因緣巧合所促成的，這大約是在我到宏達電已經五個月左右發生的。一天我在Facebook上看到當兵的同梯post一則台積電徵才消息，而一切的開始就是我在上面留了一次言，然後就被鬼上身的抱著玩玩的態度(因為之前已經被拒絕過一次)將履歷給了我的同梯去內薦。結果過了一個月竟然接到了面試通知，沒辦法，於是就請了一天假去面試，至於面試的過程我之前已經有寫過分享心得。其實真的就是一堆的巧合，要不是那一天我運氣很好的英文考得還不錯，要不是那天我運氣很好的遇到很不錯的面試官、要不是我運氣很好的又拿到一個很不錯的單位的offer，如果沒有以上的這些"要不是"，我想我現在應該還會在宏達電吧！

那究竟是什麼原因讓我決定到台積電呢？當時的情況是這樣的，大概在GoogleTask plugin完成的差不多以後，每天到公司都覺得很無趣，都是解一些奇怪的issue，過著解issue為生的日子，沒有issue就沒什麼事，有issue就加班到比較晚(當然沒有加班費，無敵的責任制)，這個時候就已經開始讓我萌生去意的種子。不過突然的一個機會，讓我換去負責另一個跟Verizon合作的AP，於是我堅持了下來。但過沒多久，我發現又是一樣的生活，只是issue比較少了；但卻多了另一件事，就是要看NewBay(另一個參與Verizon專案的公司)嘴臉來跟他們要API，這個部份其是也還好，因為協同合作本來就不容易，更何況是跨國的(對方是在美國的公司)。就在這個時機點我拿到了台積電的offer，不過我還是思考了很久，打聽了很多消息，才做了這最後的決定，至於這個決定是好還是不好，可能還要往後幾年看才會知道。所以就如大家所知的，我現在在台積電了。

贏在測試－曹向志 摘要

軟體測試經驗的體會：
1.做事要認真，有耐心。當時大家的學習熱情都很高，如學習程式設計語言、學習硬體及業務知識。
2.測試要注意變換思考的角度。當時我們大概測試10輪左右，如果不轉變思考的角度，越到後面就越發現不了問題，因為思維已經形成了定勢。
3.當時因為使用的是編譯，進行白箱測試，使我對作業系統、語言本身都有了深入了解，這位我以後的工作打下的堅實的基礎。

作為一名軟體測試工程師，知識面應該更加寬廣，這樣才有利於測試工作。

教材編寫的流程：
1.確定教材編寫規劃
2.編寫具體的某一本教材的大鋼
3.大綱評審
4.編寫PPT
5.試講
6.改進，通過後開始編寫教材正文
7.課程評審
8.校對
9.編寫任課老師使用的教案
10.出版

如何做好專案管理：
1. 要做好時間管理
2. 要做好品質控制
3. 要有良好的溝通能力
4. 要做好風險管理

測試 vs. QA
QA主要負責品質確認、審計，控制研發過程和測試的品質。可以用一句簡單的話總結：測試是對階段成果品質把關，而QA應該是對過程品質把關。

外包測試團隊執行專案的主要流程和做法：
1. 學習軟體需求
先派出骨幹人員，跟蹤軟體需求的形成過程，對需求文件進行審查，嘗試找出需求中的問題，以促進需求的完整性、正確性和可測試性。
2. 提取測試需求
要把業務需求轉換成測試需求，這一步是很重要的。有了測試需求，我們就知道測試要做什麼工作。
3. 設計測試案例
用幾個測試案例來驗證一個測試需求。透過一個管理工具，我們把測試需求和測試官連起來，從而方便查看和評審。
4. 作評審(Review)
測試需求和測試案例評審，根據評審意見，進行相應的改進。
5. 煙霧測試(Smoke Testing)
指驗證軟體是否符合測試執行入口標準(1~2天)。通過標準是，其功能要90%都工作正常。標準要在前期各方討論確定。如果不進行煙霧測試，很難判斷軟體功能完成情況，將來很可能導致測試和研發交叉在一起，很難分清楚到底是開發方的問題還是測試方的問題。
6. 整合測試
這個階段的重點是測試個子系統的介面，整合測試週期比較短，基本上每週進行一輪(有時3~4天就一輪)。此階段主要是要看整個系統相關子系統介面是否正常工作，資料能否正常地輸入/輸出，並不驗證功能的正確性。
7. 功能測試
測試工作中最重要的是在整合測試階段活動的基礎上，進行更深入和更全面的測試(包含正常、異常的情況、帳務、介面等)。因為是全面的測試系統，所以每一輪週期要10多個工作日，但隨著熟悉程度的增加，會進行的愈來愈快。
8. 統計分析
對測試工作中的各種資料(包含測試需求數、測試案例數、bug發現/修復數、缺陷原因、投入工作量等)進行統計，這會外包測試更重要，因為客戶也希望看到量化的測試結果。
9. 性能測試
理論上可以和功能測試並行，但通常都會稍晚一點啟動。性能測試有三個重點：
a. 設計性能測試場景
b. 確定性能測試設備(需客戶去商量及準備)
c. 構建歷史資料/基礎資料(可透過寫一些儲存過程或借助一些工具產生)來測試3~5年後的性能表現
10. 測試報告
整理匯總各種測試資料，編寫測試報告，並做好測試報告的評審準備。
11. 接受度測試
專案測試和公司軟體產品測試是有一定差別的，專案是定制的，產品是通用的，要求不一樣。專案測試，與專案有關的連絡人的溝通要多一些；而進行產品測試，與內部的溝通要多一些，且這種溝通中阻礙和問題也比較少。

贏在測試 － 劉宇：測試的一個循環週期

原本想說要把在這本書看到的一些內容整理一下，然後覺得不錯的分享出來，不過才節錄了兩個人的內容就打字打得很累而放棄了。今天看到最後一個人，提到了一個測試的週期，我覺得很棒，所以又手癢稍微整理一下打了出來，以下就是書上的內容：

測試的一個循環週期

1.測試需求分析 (業務需求->測試需求)
首先，測試團隊需要結合產品定位、產品規格、典型應用，以及累積的經驗來確定需要測試哪些內容，這個過程稱為“測試需求分析”，即解決測什麼的問題。

2.測試設計
其次，需要考慮使用什麼樣的測試方案，採用什麼樣的測試步驟來驗證這些測試需求，這個過程成稱為“測試設計”，即解決怎麼測試的問題。在測試之前，還需要根據產品品質情況和程式碼變更情況，明確哪些內容可以不測，哪些內容需要重點測試，各個測試內容的時間和人力安排等等，以確定“測試策略和測試計畫”的過程。

3.測試執行
最後，就是分階段，利用已有的測試設計對產品實施測試，查看產品品質到底如何，這個過程就是“測試執行”過程。

4.測試分析
在計畫的測試任務完成之後，我們需要進行測試過程度量和缺陷分析，對產品的缺陷趨勢、測試人力投入、測試執行合理性，以及缺陷分佈給出合理的評估；並結合經驗資料，判斷產品是否達到了我們的品質目標，測試是否可以結束。而且透過對測試過程的分析，我們還能知道在哪些方面，我們需要繼續改進，為下一次測試提供優化依據。

只有完整經歷過上述不斷優化的循環，你才能說你做了一次完整的軟體測試。

贏在測試－陳紹英 內容摘要

測試的要點：方法、技術和溝通
1.測試方法。應該知道如何進行測試。
2.測試技術。應該知道如何去實現，並能解決各種技術難點，這樣才能更好地勝任測試工作了。
3.溝通與協作。只有善於溝通與團隊協作的人，才能做好測試工作。

對於測試工程師而言，好的技術背景非常的重要，尤其是開發能力。如果沒有良好的開發能力，往往在測試方面不能走得長遠，即使轉做管理也一樣。

Leader應該滿足的要求：
1.要有熱情與責任心，否則即使個人能力再強，你把他放到Leader的位置上也很有可能做不好工作。
2.要有夠硬的技術，因為需要帶領自己的小組攻破各種難關。
3.要有一定的個人威信，能夠團結人，你的話別人願意聽。
4.要有很好的溝通與協調能力，因為經常會與其他團隊進行溝通。良好的溝通能力保證自己能夠很好地去處理與開發小組，以及其他測試小組的關係，保政測試工作的順利進行。
5.要有大局觀，不應該只考慮自己小組的利益。好的Leader應該積極地配合測試經理做好整個測試部門的工作。
6.Leader對自己的工作應該有一個正確的定位。Leader不要把自己定位為經理，經理相對來說管理協調工作的時候多一些，側重於管理整個團隊，而Leader則是要解決問題的，主管別人去做好專案，很多工作要親自動手。如果Leader只是讓別人去做，自己卻僅僅在一旁“吆喝”，這就失去了Leader存在的意義。

如何做好軟體測試：
1.無論專案大小，要做好規劃。什麼時間，完成什麼任務，都要有規劃。
2.確定好測試流程。好的流程可以提高效率，降低溝通成本。
3.要做好測試案例的設計。測試案例是測試工作的靈魂，因此一定要設計好測試案例，以指導後面執行工作。
4.要做好缺陷管理。缺陷是開發與測試之間的橋梁，也是測試的直接目的，因此一定要跟蹤好每一個發現的軟體缺陷。

做職業發展規劃時，首先應該全面地分析自己的長處和不足，然後確定把什麼作為自己的核心競爭力。核心競爭力很容易理解，也就是那些不太容易掌握或者有一定技術成分的技能。確定核心競爭力後，接下來就是選擇行業，再選擇一個企業來培養自己的核心競爭力。

贏在測試－崔啟亮 內容摘要

學校學習和企業要求之間的差距
1.在學校的時候沒有團隊意識，常常是一個人單打獨鬥。
2.在學校的時候沒有專案的概念，沒有工程的概念。
3.在學校的時候沒有客戶的概念，程式只要能寫出來，能畢業就可以。

新人如何融入公司：
1.主動問。一定要把自己當作一個新人，有問題就主動及時問，不然誰知道你有問題呢？當然，不要總問一些弱智的問題，有了問題以後先自己找答案，現在網路也很發達，先到網路上找找解決的辦法。自己沒有辦法解決的，要主動問。不恥下問，這是很有道理的。
2.要總結。專案執行過程中自我總結，專案結束後總結，給個月自我反省和總結。
3.要有時間概念，按時完成，無法完成要及早提出來。例如，一項工作的安排，如果你覺得無法完成，就主動提出來，不要拖到最後，這樣會影響別人和大家的進度。例如，如果5點交付，你4點半才去告訴主管無法完成，他也沒有辦法幫你解決。
4.主動學習。到一個新環境，新專案，先去看測試用範例，然後看相關的資料，看書，上網查背景資料，都要主動學習。
5.要吸取教訓，不重犯錯誤。犯了錯誤以後，吸取教訓，避免再犯。
6.做事要符合規範。比方說，客戶要求附件用ZIP壓縮，而你用了RAR。你這個看似沒有什麼的舉動，卻會增加客戶的負擔。工作做得怎麼樣，很多都在細節上。因此，在做事之前，要先瞭解和掌握規範，我要做什麼，要求是什麼，以及什麼時候交付。

如何學習軟體測試：
1.找入門的、基礎的、簡單的書來看，先看前3章。不要一開始就去看厚厚的枕頭書，效果不好。現在軟體測試的書很多了，最好先看中文的。
2.現在有一些免費的測試交流會，去聽一聽，即使收一個場地費，也值得。
3.多瀏覽論壇。在論壇上，不要光發文章問別人要範本，而要多看文章，多發表問題。
4.如果經濟條件允許，可以報培訓班。
5.有機會的話，到一個公司進行實習。

工作經驗總結：
1.勤奮。我不是聰明的人，但我是個勤奮的人。我可能比別人慢一點，但我勤奮，也願意問問題，我相信“勤能補拙”。
2.開放。多交流，多交朋友，以開放的心態待人接物。
3.善於總結。遇到問題不可怕，要把經驗和教訓總結出來。

真夏方程式~~

兩三個月前看完寫的心得，剛剛在寫我的夢的時候看到，順便貼上來~~


花了兩天的時間看完了東野圭吾的最新作：真夏方程式結局真的很出乎意料，湯川說的很多話也很值得玩味。

這是一本述說 偵探伽利略－湯川學 與 一個小學生 一起度過暑假的故事只是在其中發生的有人死亡的事件，而且那個人是一個退休的刑警我並不想描述太多關於這本書的內容，只是想討論一些湯川說出來的我覺得是圍繞在整個故事的一句話：恐怕會使得某個人的人生嚴重扭曲。很多殺人事件，每一個人的想法都是一定要找出兇手，釐清事實，雖然這樣並沒有不對但這樣的事實卻可能使得某個人的人生嚴重扭曲。

最近看了不少的推理日劇，其中有一個故事是：一個只相信自己的女生，也是所有事件的主謀，但她卻非常的相信男主角(刑警)但最後男主角發現自己都被這個女生主謀給騙了，於是他整個爆發要討回來，並設下陷阱抓到了那個女生也許看起來好像是解決一個案件，但卻毀了一個人的人生，就是那個女生因為從小的一個人，女生誰都不相信，只相信自己，連很崇拜自己的跟班，也只想著利用而已而那個刑警是他第一個相信的人，但最後還是欺騙了她她非常的難過，並且封閉了自己這樣的結果，讓她無法去體會與瞭解，她身邊其他的人對她的關心，尤其是那個跟班女生

也許有人會覺得那個女生活該，因為她是直接犯案人，但她還是人~~

柯南的故事中也有提過類似的劇情，並不是所有的事情都要全部說出來的~~

而這次書中的故事，就是那個小學生：恭平因為大人的欺騙使他成了共犯，但他完全不知道，直到故事結尾時，他也慢慢的發現也許湯川可以全部都說出來，讓所有的真相還原但，他知道這樣做將使得 恭平 剩下的人生造成嚴重扭曲

於是最後他對恭平說了這段話：任何問題一定都有答案，但答案不見得能立刻導的出來。換成人生也是一樣的。今後你會碰到很多無法立刻提出答案的問題。每一次煩惱都有價值。但沒有必要焦急。想要找出答案，很多時候自己必須成長才能找到。所以人一定要學習，要努力，要不斷磨練自己。這次的事件，到你能找出答案那天為止，我會和你一起抱著同樣的問題，繼續煩惱下去。千萬不要萬記，你不是孤單一個人。

看完之後，我能不斷的咀嚼這段話，其實人生很多事情都是這樣的也許故事中這段話是說給 恭平 的，但在現實中，這段話是可以說給每個人的大家都是經歷這樣過程而成長：疑問，煩惱，學習，瞭解

或許這整篇文章，只是想跟自己說：也許你現在身邊就圍繞著很多沒有答案的問題，但不要焦慮、也不要急躁慢慢來，突然有一天，所有的事都會豁然開朗的~~

一個奇怪的夢~~

好幾天前的一個夢，是午睡 還是 早宸 清醒時的夢 我已不復記憶

它是這樣的一個背景

我好像是一名軍人樣子

當天我沒有班要值 可以輕鬆的度過

不過 突然一個同儕來找我希望我幫他代班值勤

因為他的母親病危 所以他一定要去看她

可是我覺得難得可以優閒的度過剩下的半天

我拒絕了

於是他默默的邊掉眼淚 邊走了

那個時候的我  突然覺得自己好像壞人

怎麼會這樣拒絕別人這樣的要求呢

不知過了多久

我放棄了

我通知他說  你可以去看你母親了

然後 畫面一轉

一個病床  以及  那個在床邊的同儕

當時看了心裡很感動我最後能認輸去代替值班

距離值勤時間愈來愈近  我打聽了一下工作的內容

聽說是要保護一個很難搞的老婦人

然後一個認識的長官  過來找我

要我準備一下 帶上步槍準備要去執勤了

接著我們來到一個老房子

裡面好像有幾個老婦人 但我們最主要是要保護裡面最老的那一個

至於是什麼身份 我有點忘了  好像類似是天龍人那種感覺的人吧

那時她們剛好準備要吃飯

一看到他們的餐點我就嚇呆了

真是極盡豪華的一餐

那個老婦人突然出聲要我們一起吃

我的長官說他不餓 要去門外看看

於是我就跟著老婦人一起吃飯

過程中

她好像有問我一個問題 有點忘了 好像是為什麼來當兵吧？
(因為夢中的我好像是一個職業軍人，我猜)

記憶中  我好像有回答 而且回答得很有意義的樣子(自以為有義意)

我不是很有印象的，不過可能是
：我不知道我要作什麼，所以我想透過當兵來找到我人生的路之類的

接著我們又繼續聊其他的話題

突然

我感覺到牆上的吊燈晃了一下

接著又感覺到有七個人(還是五個人，我忘了)迅速的靠近我們

已經到門口了

我馬上衝到門口

在跨出門前時迅速的那出我的手槍(剛剛不是拿步槍嗎)殺了左邊的三個人

那時長官剛好站在我前方不遠處

出門口後我又迅速的瞄準右邊三個

當那三個都一一倒地後

我轉頭一看

中間的敵人 正拿個槍瞄準著我 蹦的一聲

我的長官一個踱步 閃的我身前

接著我看到他往後倒下

但我知道我不能遲疑 馬上開槍 打死了中間的那個敵人
(很奇怪，手槍不是都六發嗎，為什麼可以打死七個人呢)

然後我才看到了 另一個長官帶著其他人來援助(跟電影一樣，事情都解決的他們才會來)

不過已經都結束了

我抱著倒下的長官

看著另一個長官走過來

這兩個長官一直都是很好的朋友

然後那位長官對著倒下的長官說
：以前都是我躲不過，怎麼現在換你躲不過了呢？

接著畫面好像就切換到葬禮吧  不太記得

然後我好像就醒來了

剛醒來的時候  我就想我一定要把這個夢寫下來

但是很懶  結果一拖拖了好幾天  很多細節都忘記了

不過最終  我還是把它寫下來了~~

讀松本行弘的程式世界之突發奇想~~

最近看在松本行弘的程式世界這本書，裡面提到一個他大力提倡的繼承方法：mix-in。
書中討論了很多關於單一繼承、多重繼承及mix-in繼承的方法。

單一繼承：單純的繼承關係，不過限制太多有什會產生不直覺的繼承方式。
例如：


因為沒有辦法多重繼承，使得ReadWriteStream只能繼承於其中一個類別。
也因為只能繼承於單一類別，另一個ReadStream中的功能就只能用複製的方式移植到ReadWriteStream中。這樣會使得程式碼重複，而程式碼重複會產生難以維護及擴充的缺點(DRY，Don’t repeat yourself)。

多重繼承：可以同時繼承好幾的類別，就像是一個人可以同時是爸爸，也可以有老公和員工的其他身分。不過可能導致複雜的繼承關係圖及優先順序的問題。
例如：



不同於單一繼承，ReadWriteStream可以直接繼承ReadStream及WriteStream，減少程式碼的重複。
不過ReadStream及WriteStream重複的Stream的功能，可能會讓ReadWriteStream搞不清楚要用哪一個繼承下來的功能。

Mix-in：類似多重繼承，不過在第二個之後的父類別，必需是要滿足下列兩個條件的類別。
1. 不能獨自建立實體的抽象類別
2. 不能繼承自不是mix-in類別的類別
透過mix-in的方法就可以將原本多重繼承的架構簡化，並避免掉鑽石問題。
例如：


其實我重點不是要談繼承這個議題，只是想要把mix-in這種的繼承方式帶出來，因為我接下來是像要對這樣的架構作討論。
根據上面的mix-in的圖，可以發現每個子類別都繼承於Stream這個抽象的類別，在混入Read和Write這兩實作功能的類別(或稱模組)。
這樣的架構，讓我想到設計模式中的橋接模式。

橋接模式：在於將抽象與實現分離，使兩者都可以獨立地演化。這邊所謂的抽象，指的是指應用程式行為定義的演化，而實現指的是應用程式實作時，所需使用的特定API或平台。(出自良葛格筆記)

以ReadWriteStream來看，就會像下面的圖一樣。


透過橋接模式，就可以在原類別用composite的方式混入想要的功能了。

好吧，其實以上都是我自己胡思亂想的~~

我這個妳不愛的人~~

一天夜晚，我打開KMPlayer 點選之前亂湊的播放清單
點擊了Play的按鈕，接著它響起了過去的、久違的一首歌
我這個妳不愛的人－迪克牛仔

曾經，幾年前的一個夜晚
我在新綠園(嘉義大學的BBS)的不知道什麼版中看了一篇故事
以後，只要我聽到這首歌就會讓我想到這個故事，一個真實的故事
故事中的角色只有三個人，一個好人和一對吵架的男女朋友
之後，我曾試著回新綠園找這篇文章，但找了很久都一直都沒找到
最後我終於決定自己把它重寫下來
根據我久遠的記憶來寫
不過寫出來的故事，可能已經不這麼終於原著了~~

=============================================

這天夜晚，外面飄著細雨。
剛結束一場三國，正準備要去洗澡。
手機突然等~等~等~~的震動了起來。
看了一下來電訊息，是她，我馬上接了起來。
我沒出聲，她也沒出聲。
慢慢的，我聽到了微微的吸氣聲，
她開口用著好像剛剛才哭過的聲音說：｢我在車站 可以來接我嗎？｣

她，一個我曾經深愛過的人，即便如此依然還是分開了。
我從沒去探究過原因，
因為我怕這樣做會讓自己更難過、更難忘懷。
她突如其來的一通電話，卻勾起了我內心深處中塵封的回憶。
匆忙間，我抓了鑰匙，快步通過門口。
在機車上，我沒有去思考任何的事情，也許是因為害怕吧！
只任由雨水不斷的敲打在我身上。

車站的牌子出現在我的眼前了，
我看見一個滿身濕淋，低著頭的她。
我分不清那是雨水還是淚滴，
緩緩的流過她那曾經充滿著歡笑的臉頰。
剎那間，萬語千言湧上心頭，但我卻說不出口。

她默默的坐上車，沒有一句話語。
慢慢的，她靠在了我的背。
輕輕的，她傳來了哽噎的聲音。
在這樣靜謐帶有淅瀝雨聲的夜晚，
沒想到這樣細微的聲音，卻顯得特別的清晰。

她，依然沉默。
我，不知所措。
時間慢慢的流逝，車站漸漸的遠去。
我心想：｢幾分鐘的車程，怎麼這個時候卻顯得特別漫長呢？｣
一個轉角，兩個街口，三個紅綠燈，
我終於看見了自己所住的公寓。

｢到了。｣
她依然不發一語。
停好車，我帶著她上樓，回到了自己的房間。
看著整身溼淋淋的她。
｢去洗個澡吧！不然要感冒了。等下我拿瓶啤酒讓妳暖暖身。｣
我拿了件衣服及毛巾給她，她說了聲謝謝，走進了浴室。
看著她走進浴室後，突然之間，我好像有口氣鬆了下來的感覺。
我從冰箱中拿出了啤酒，打開收音機轉到自己平常喜歡收聽的頻道。
此時，它正好響起了熟悉的旋律，接著傳出了低沉的歌聲：

　很黑的深夜，電話響起
　沒有睡的我，猜想是妳
　也許他傷了妳的心，也許妳懷疑他的情
　這曾導致，我們分離
　太多愛聚集，在一時激情
　太多人放手，在一時任性
　誰又真的瞭解自己
　誰又真的問過自己
　需要跟什麼樣的人在一起
　我這個你不愛的人，還單身一個人
　守在感情門外，撐了又撐
　妳又何必來敲打我不安的心門
　我這個妳不愛的人，還單身一個人
　沒日沒夜心和回憶抗衡，妳就不要來觸碰我的疼
　讓我一個人，穿過愛背後的傷痕

喀啦一聲，她走了出浴室，
她依然不發一語。
我示意要她先坐下來，然後打開了一罐啤酒。
｢先喝一點暖暖身吧！｣

她用左手接過了啤酒。
我自己也為自己開了一瓶。
我看著她喝了一口、兩口。
終於，她哭了出來。

我讓她倚靠在我的肩上，
使她不會接觸到我的眼神，可以盡情的流淚。
我想她真的忍太久了。
慢慢的聲音愈來愈小，她哭累了。
我扶她上了床，讓她能好好的休息。

而我又坐回到剛剛的位置，
拿起那剩下半瓶的啤酒。
想著今晚發生的事，
還有她在那之後不知道過得怎樣？
怎麼會突然出現在這裡？
整個晚上都不發一語，不知道發生了什麼事？
這許許多多的疑問都圍繞在我的腦中。
不過在酒精的催化及疲累下，
漸漸的我還是闔上了我那沉重的眼皮。

恩~原來已經早上了啊！
她呢？沒在床上。
我環視一周，只發現自己身上蓋了一條被子。

突然，門打了開來，她邊走進來邊說：
｢我買了早餐回來，等一下一起吃吧！你趕快去洗把臉。｣
我匆匆忙忙的刷牙洗臉出來後，
看到放在桌上的早餐，以及坐在昨天那個位置的她。
而我也一樣坐回了我昨天晚上的那個位置。

我看著她，吃著早餐，心想：｢看來她好像已經好了很多。｣
｢我剛剛在買早餐的時候接到了他的電話，
他說要來接我，所以等一下可以請你送我去車站嗎？｣
｢好啊！｣ 我百感交集的回答。

之後，她又說了一些剛剛買早餐遇到的事。
昨天晚上的事就像從來沒有發生過一樣。
就這樣我們在閒聊中結束了早餐。
同樣的路線，不同的方向，載著她，我這樣的想著。
車站到了。
離開時，她輕輕的說了一聲：｢謝謝。｣
而我轉頭回了一個｢笑容｣給她..........

上班後看完的、目前在看的及之後要看的書~~

1.最後期限：專案管理101個成功法則
2.上帝是數學家
3.雪中足跡
4.哪阿哪阿－神去村
5.加護病房裡的選擇題
6.數學少女
7.真夏方程式
8.遺憾，擱淺了未滿的愛情
7.神秘島
8.流浪鼠之歌
9.諾亞的魔幻旅程
10.推理要在晚餐後
11.漫畫-微積分
12.輕鬆Scrum之旅
=======(未看完)=======
13.發現我的經濟天才
14.程式揭秘：從C/C++程式碼探索電腦系統的運作原理
15.編程的頂尖對話：閱讀15位軟體大師的核心思維
16.贏在測試：軟體測試專家之道
17.編程之魂：與27位編程語言創始人對話
18.代碼整潔之道
19.敏捷開發法的逆襲
20.漫畫-傅立葉解析
21.數學女孩-哥德爾不完備定理
22.詩經是一枚月亮
23.槍砲、病菌與鋼鐵
24.看得到的世界史
25.Peopleware

當兵前、期間、現在看了哪些書呢？

非專業類：
1.遇見未知的自己
2.遇見心想事成的自己
3.於是，天使來到身邊
4.於是，上帝派來天使
5.追尋失落的玫瑰
6.宇宙新事實！新太陽系全解
7.地心旅遊記
8.如果高校棒球女子經理讀了彼得杜拉克
9.夜譚十記
10.一點小信仰
11.香格里拉
12.支撐你的，往往也是讓你崩潰的。
13.不只是件白襯衫-商學院裡沒學到的策略實戰
14.漫畫-線性規劃
15.漫畫-宇宙(未看完)
16.王永慶全傳(未看完)
17.數學女孩(未看完)
18.黑夜裡的送行者
19.和女兒談戀愛
20.不乖
21.帶我去月球
22.胡立陽出人頭地100招(未看完)
23.禁咒師全集
24.走出軟體工廠(未看完)
25.日光旋律

專業類(幾乎都沒看完)：
1.深入淺出設計模式
2.程式設計師的自我修養-鏈結、載入、程式庫
3.Google Andrioid 3 手機應用程式設計入門
4.深入出 Andrioid 遊戲程式開發範例大全
5.深入淺出物件導向分析與設計
6.敏捷軟體開發-原則、樣式及實務
7.大話設計模式

總結：真是一個沒事就看書的阿宅

貧民百萬富翁~~

問題：孟買2006年，傑瑪˙馬利克還差一個問題就能得到兩千萬了，他是怎麼做到的？
A. 他作弊
B. 他運氣好
C. 他是天才
D. 命中注定

在這部電影中，完全顯現出來沒有什麼東西是沒有意義的
有多少個問題的答案，都是在他發生屬於他生命中的苦難時得到的
如果沒有這樣的人生，他根本無法答對問題晉級到只差一題的情況
所以最後的結局，他是命中注定

也許每個人的命運都不一樣，但好像真的很多東西都是註寫好的
在人生中的每一個漣漪或是小石頭都是組成人生中的一個因素

在這部片中，也表現了人生真的是自己走出來的

如果主角的個性不是這樣
如果沒有那個女主角
如果沒有他那個哥哥

他經過的人生一定會是完全不一樣的
但他持續的走下去，才使得他有機會得到這樣的命運
不過這也只是其中一個人生
自己的人生 還是要自己走的
也許就像等公車一樣
不知道自己什麼時候會等到
但沒有人能知道 繼續等還是放棄哪個好
唯有自己決定 照著自己的內心走
不論是怎樣的結果 自己都是能坦蕩 快樂的走下去


March 14, 2009

夜行~~

有多久沒有這樣在接近半夜的時間點走路回家了

有一年了吧

每次會有這樣的經歷都是因為車壞掉

不過也因為車壞掉 才有這樣的機會

在半夜走在沒有什麼車的路上

回顧過去 也感受夜晚

記得去年走路回家的情景

我都會邊走邊感受著寧靜的夜晚

思考著一些總是困擾的問題

還有一次 半夜則是走路回學校

記得那天 因為很晚了 大概凌晨兩三點吧

她們家的地下停車場很恐怖 因此我載她回家

但是有些事還沒弄完 所以要回學校

走出她家樓下的鐵門時 結果還被警衛念了一下 有點小不爽

然後就走回學校

已經忘記那天我是不是在學校過夜了

這些都已經是過去 未來也不會有這樣的機會

走在回家了路上 回想著過去大學的荒唐生活

其實還蠻有趣的

夜晚真是一個特別的時刻啊

該睡了 大家晚安~~


February 10, 2009

再世情緣~~

終於看完了再世情緣

這是一部由星雲法師的原著玉琳國師傳改編的

看完之後感觸很多

因果之事在當中表露無遺

讓人感覺到因果跟業力的可怕

縱使是得道高僧、佛陀等等 也都逃不過

更何況是平凡人的我們

雖然 再世情緣把玉琳國師傳 愛情小說化

不過反而更讓人看到人心的貪嗔痴愛

格格對玉琳的癡

順治對太后的嗔

天仁對玉蓮的愛

吳成對錢財的貪

一切的一切 都上演在故事中

讓人刻骨銘心 深印腦中

真的是讓人非常喜歡的一部劇啊~~


July 7, 2008

命運好好玩~

最近看了一部電影，命運好好玩。

讓我有很多的感觸，很多人都不斷的在追求金錢跟地位。

結果就像電影中的劇情一樣，忽略生命中許多精彩的每一刻，最後才讓自己感到後悔。

反觀現在的自己，雖沒有追求金錢跟地位，不過好像跟家庭愈來愈遠。

亞當山德勒在劇中說了一句，到現在我還是印象深刻，"Family comes first."。

不過，沒有真的親身經歷，很難真的去珍惜。

可是，當真的經歷時又已經來不及，也許這就是人生啊。


August 10, 2008

交錯效應~~

看完這部電影 到結尾震撼了我

雖然沒有"西線無戰事" 以一聲槍聲結束來的震撼

但讓我很有感觸

不管事你認識人 還是你不認識的人

人跟人之間都是彼此牽扯的

就像前常聽到譬喻

人們就像是螺絲交互作用 維持整個世界

人跟人之間的牽扯性真的很大

劇中有了一個有趣的比喻

有一種情況：一個女生 天生就是鼻子長歪 沒有人跟他約會 沒有人分享她的初吻
她很可能會去追求你 但你不會理她最後，那個女孩子寫了一封遺書給她的貓然後跳樓了

同樣一個女孩如果運用一點小魔術
她將不會在寫那封信
因此 救了她的命

人生中真的很多事情只是小小的一點

結果可能嚴重影響到別人

就像蝴蝶效應一樣

而這部電影把它擴展開來

每個人都是每個人的在遠方的蝴蝶

但都彼此影響著

也許我現在寫著這篇網誌

我就救了一個人也說不定~~

Scars are the roadmap to the soul~~


September 5, 2008

挑戰奇蹟~~

昨天看了一部電影

挑戰奇蹟

這部電影也給我了一些影響

雖然故事的主人翁

只活了23歲

但在他的人生中 卻留下的璀璨的回憶

在他開始在大學打橄欖球 不到三年的時間

他讓他們校隊得到全國第一

他成為第一個得到海斯曼盃的黑人

他也成為了許多人的偶像

這句中他的教練說了一些話

他並不是要主角成為第二個吉姆˙布朗(也是一個很厲害打橄欖球的黑人)

真的是讓人當頭棒喝的話

在現在這個環境中

大家都希望自己的孩子能跟誰誰誰一樣

或是期許自己

成為第二個蓋茲、第二個巴菲特還是第二個郭董

但這些都是不可能的

因為對於這些人 我們只有兩種可能

第一個就是超越他

第二個就是跟現在一樣

永遠不可能跟他人一樣


蜀道行說過：人生只有比較就失去自己的意義了

還說過你就是你 是別人所無法取代的


February 5, 2009

鹹蛋超人之星~~

鹹蛋超人 一部我很喜歡的特攝片

從小時候開始就很喜歡 即便是到了現在也一樣

看了很多部 很多集的鹹蛋超人

在這麼多劇集中 都一直在宣傳一個信念

不管是再怎樣艱難 困苦 甚至是絕望的環境中

只要人們心中有光明

回憶起已失去的夢想 懷抱著想保護自己需要守護的人

希望永遠都會存在

但現在的人們都已經忘了過去的初衷

在電影當中 鹹蛋超人 總是會拉回人們的心


也許在這麼平行宇宙中真的存在著鹹蛋超人

但並不一定要變成鹹蛋超人 對抗怪獸

才可以稱作英雄

只要人們心中存在著希望

在灰暗的絕望中都會透出一抹光芒

成為英雄 對抗所處的黑暗

重新為自己及人們帶來光明


February 5, 2009

靈異航班~~

靈異航班

一部既不恐怖 也不驚悚的鬼片

一部思考著某些問題的電影

劇中所有的人都是已經過世的人

只有在最後主角的姐姐才是真人

這部描述著一群已經死於空難

但卻不自知

整部戲圍繞著這些不知自己已經死掉的人

在過去的親戚 朋友 甚至是過去養過的寵物

個個都用自己的方法

希望自己重要的人

可以得知自己的死訊

一個不知道自己已經死去的靈魂

是幸運 還是悲慘呢

因為我不是死去的人

無法得知他們的想法

也許每個死去的人

都要面臨這個階段

接受自己的死亡

反過來說

我們也要接受自己的活著的

可以做的事情很多

應該要更加努力 往前進

剛看完這部電影時

腦袋都是混亂的 希望能從中得到這部電影所要表達的東西

結果最後發現知識+才是最強大的


February 10, 2009

天涯俠醫~~

最近看玩天涯俠醫這部港劇

讓我一直再思考一些事情

貫穿整部戲的中心是 珍惜生命

劇中他們是當醫生的 生死之事常在生活周遭發生

因為瞭解生死 所以他們都很珍惜生命

接近結尾時 也是勇敢的面對癌症

劇中還有一個重點就是 生命動力(無國界醫生)

讓人看得很感動 即便是現在這樣的世代

依然存在著許多熱心的義工

看完之後 真的覺得

我們應該要更珍惜身邊的事物

在劇中張家輝說過一些話

有些事如果你想做不去做 將來可能會沒有機會
有些事要珍惜 否則將來只會變成自己的遺憾

真的很值得去深思


February 13, 2010

超級星光大道~~

超級星光大道 一個選秀節目

有時會看 有時候不會看

會想看 除了聽音樂 看正妹外

還有一個很重要的

但不知道有多少人會注意到

就是看到許多不同的人生

從一開始的初選到後來的總冠軍

每個人的成長 改變 及想法

對於我都事一個很好的借鏡

有人傷心絕望

有人失去自己

有人徹底改變

有人....

每個人都是一個人生百科

在剛剛的星光大道中 有一個

因為生了大病 雖然目前看起來還蠻健康的

他瞭解了人生的短暫 去做自己想去做的事

這讓我耿耿在心中

知道自己想做什麼 又能去做真的是很幸福的事~~


April 4, 2009

秒速五厘米~~

好久之前看過的一部新海誠的卡通電影而這部電影有一首很好聽的主題曲One more time, one more chance

今天晚上在學校跑數據的時候，突然想到這首歌所以在youtube找了一下並放出來聽而搭配這首歌的MV就是卡通中的部分畫面其中最令人印象深刻的就是主角會後的回頭、等待、放棄及一抹微笑

首先大約回憶這部卡通主要是有兩個人，一個男孩及一個女孩小時候他們擁有著純純的愛，但沒有人說破後來他們因為距離慢慢的分離了，但在各自的內心深處，依然都存在共同的回憶及情感然而隨著長大及距離，男生開始不停的工作變的像行屍走肉失去了心的彈性於是他辭職休息最後，在某一天 經過小時候常常走過的平交道擦身而過一位似乎一直存在內心深處的女生但當回頭想看是誰時，火車來了，或去了一列又過來了一班當火車都消失時，什麼都不存在了只剩男孩一個

以前都覺得這幕好美很有想像空間不過今天一看有了另一個想法，如果女孩留了下來，他們中於再看見了彼此會怎樣了雖然感覺好像也是不錯的結局但好像可能存在著很大的問題可是這一切都不可知

以下是自己的看法：感覺上看到了彼此，只是悲劇的開始女孩已經有婚約，且要結婚了而男孩種是耿耿於女孩再他心中的回憶在這樣的條件下可能會有幾中情況

1)勾起彼此內心深處的感情，女孩離開未婚夫跟男孩在一起，結果可憐了未婚夫. bad ending
2)女孩回憶起，但那只是十幾歲女孩的傻心思，而男孩還是有感情於女孩結果，女孩還是跟未婚夫結婚，男孩則耿耿於懷，最後可能導至三個人生的失敗. bad ending
3)女孩勾起兒時的情感，但男孩豁然開朗沒有要跟女孩一起的想法，結果女孩耿耿於懷於男孩而未婚夫也失去的感情的依靠，最後就是女孩夾雜其中，瘋狂.... bad ending

綜合以上，想想還是原本的結局最好女孩跟未婚夫結婚，男孩看透一切，了卻內心的禁錮，露出發自內心的微笑大家都過著幸福快樂的日子. happy ending

很多事用不同角度去看，真的很有不一樣的收穫即便只是那淡淡的微笑~~


May 7, 2010

天使眷顧的孩子~~

這是一部當兵到現在我在莒光園地中看過最印象深刻的單元劇

裡面描述一位軍官 時常在抱怨 覺得自己是世界上最不幸的人

他說過一句話 生命就是一連串的苦難

然而在一次的機遇中他看到了 同片名得一本書

我有上網查過 應該是沒有這本書 是劇中為劇情而創造的

這本書描述一個父母雙亡的女孩 阿芬 她兼職了很多工作來維持生計 照顧弟妹

因為這本書 以及 一個夢 他改變了

變的完全不一樣 也使得他的人生活了起來

這個劇中最讓我印象的是

劇中的阿芬 總是帶著笑容 我覺得這是非常不容易的

很多人遇到困難時 總是會帶著鬱悶 及 不愉快的心情

她的笑讓我印象深刻

也讓我深信 很多事情只要帶著微笑去面對

即使是在艱難的事情 都一定可以通過的~~


December 12, 2010

我要高飛~~

今天 我重看了一次 我要高飛的漫畫

這部漫畫還有另一個翻譯 奧運高手

這是一部描述 一位少年 追求夢想 到獲得 奧運體操金牌 的故事

裡面有很多發人深省的語句

當人們在追求自己夢想的時候 都會擁有天使之翼

依靠這個天使之翼往自己的夢想前進

夢想

一個充滿希望的字詞

每每看到夢想兩個字就會思考自己的夢想是什麼

但在尋視自己的內心後 依然找不到

也許是因為害怕自己的努力沒有結果

使自己不趕去尋找及發現自己的夢想吧

內田 雖然沒有像其他人的天資

但他永遠都是朝著目標努力向前

不問結果 只求全力以赴

這份勇氣 就是我所缺乏的

也許是因為我對任何事都可以 抱持著無所謂的心態

使得很多事情 自己缺乏追求的動力

不過我的人生真的就要這樣過了嗎

還有時間 我能夠找到自己的夢想嗎

找尋自己 快樂玩體操 的精神 吧


April 28, 2011

Re: Dear future me & Dear future me

當兵放假 突然興起 看起了過去自己寫過的文章 也把一些封鎖的文都打開了

看著看著 看到了這一篇 也許未來的我應該要回信給過去的自己了

Dear past me,

我很抱歉 有太多的事情 我都沒又遵守約定 也沒有做到我沒有考上交大 但我還是研究所畢業 現在在當兵了我沒有在她沒有男朋友的時候 說那句話 而且也沒有去找一個自己喜歡的人奶奶過世的事 還是時常會想到 現在的我 也比較常常待在家中陪家人不過好像還是說不出愛他們的話至於真心的好朋友 其實已經存在了 我想應該就是他了雖然有時候還是有很多事不好意思跟他說 可是人不是本來就應該要有秘密的嗎回信至此感到有點慚愧 因為三年了 自己有這麼多事都沒做到真的很抱歉 過去的我我想我會好好加油的 在一次的寫信給未來的我

最後記得一定要好好愛自己喔想清楚自己所要的勇敢的去面對、生活吧加油!!!

最愛的你~ 哲

2011/5/22

=========我是分隔線=========

Dear future me,

哈囉你還想著她嗎你還喜歡她嗎如果是且她還沒有男朋友的話請你再跟她說一次"我愛妳"吧如果沒有勇氣那就趕快忘記她吧再去找一個你愛的而且也愛你的人吧

你現在在念研究所了嗎還是你在當兵了希望你現在是在念研究所而且是交大好好享受自己剩下不多的學生生捱如果還是沒有女朋友就去把一個吧

你還記得奶奶過世的難過嗎如果是的話趕快再去看看她吧你有跟家人說愛他們嗎如果沒有也一樣快去跟他們說吧不要再讓自己後悔了好好把握現有的家人吧

你有沒有交到一個真心的好朋友是男的還是女的呢如果沒有拜託趕快去找一個真正真心的好朋友吧不要讓自己遺憾

最後記得一定要好好愛自己喔不要再讓自己難過也要好好的面對一切加油!!!

最愛的你~ 哲

2008/1/20

夜雨~~

今天的夜晚，外面下細細的雨，而我聽著flyradio的廣播

思考著自己的未來，在最近找到的工作中反覆躊躇，舉棋不定

我不知道自己想要的是什麼

怎樣的工作 怎樣的薪水 怎樣的同事 怎樣的未來

我很怕因為走錯這一步 有無法掌握的未來

一前的我無憂無慮 事事順心來

不過年紀愈大 思考的東西愈多 反而愈放不開去作決定

雖然經過理性的分析得到結果 但感性的部分卻又開始拉鋸

猶豫不決

這樣的個性在我身邊開始慢慢的放大

沒有選擇很可憐 但選擇太多又引起不必要的憂慮

思考了很久

其實我只是不想面對自己真實的內心

至於為什麼 我也不清楚

也許是對於未知的害怕

導致我時常無法很果決的決定一些事

其實我內心已經決定了 但有不想放棄其它的可能

魚與熊掌不可兼得啊

也許如果我可以確切的決定最後的選擇

我想我又成長了一步吧~~


October 10, 2011

小當家~~

中華一番，這是一部關於料理的卡通

因為大部分都看過了，所以每次回味時都會挑一些比較有印象好看的片段

其中一個章節就是 神秘的鍋巴料理

這個故事幾乎每次回味時都會再看一次

主要是因為 小當家 在沒有任何資源的情況下

重現五十年前 賈雄大師的 鍋巴料理

這樣的困難 這樣的努力 這樣的巧思

在在都顯現出 熱情的重要

我一直都記得當中說過的一句話

只要心中常保永不熄滅的熱情，總有一天也會贊放出光芒來

每次想到、看到、聽到

都讓我重新去思考 我自己的熱情呢


July 14, 2011

相片~~

剛剛看了一下自己之前的相簿

跟妹的照片裏面有一張

是在成大的醫學院那邊跟一個成大的學生合照

回想當初 當年大吉盃是由成大主辦

我已經忘了我有沒有參賽了

不過在那次 我跟不少人拍了照片

也繞了一下醫學院

看了一下這邊的環境 感覺還不錯

當時我突然想到高中一個同學

在當時大家的志願都是交大和清大

不過他卻是成大

當時我並不明白

但在這次的兩日遊

稍微了解了一些 然後也有了一個念頭在心中

就是 其實來成大念書好像也不錯

沒想到過了一年 真的讓我不小心考上了

現在想想 真的是有點命運的感覺

現在已經畢業快一年了

回想到當初的無心之思 現在都還會會心一笑呢~~


September 11, 2011

如果高校棒球女子經理讀了彼得杜拉克~~

最近看了這本書

大概的內容就像標題所說的

一個高校棒球隊的女子經理 如何透過彼得杜拉克的管理方法 讓球隊打進甲子園

看完這本書的時候 感觸很多

不論是對於之前亂讀的管理學

還是在經營社團方面

回想起來，當社長時

自己真的蠻失敗的

沒有留住社員的能力

沒有提高社員的演奏能力

沒有團結社團的能力

整個只有一個爛字可以形容

虧我還是管理學院的

看了這本書 回想了很多 當社長時發生的事情

如果我也能夠這樣的管理我的社團

不知道會有怎樣的結果

雖然都已經過去了 也算是一種學習吧

書中的理論與棒球實務 搭配過去的社團經驗

好好的思考一番 真的讓我學到不少的東西

這真是一本很有趣的書啊~~


July 14, 2011

海潮之聲~~

如果有一天有人問我：宮崎駿這麼多部卡通，你最喜歡哪一部呢？
我想我會回答：海潮之聲。

因為我覺得這是一部最貼近現實，也最能觸動我的心的卡通吧！

它沒有鬼怪、神秘、昆蟲、黑暗面等等的負面因素
也沒有對生命的執著、對大自然的愛護等等這些偉大的正向意念

只有淡淡的、單純的故事及
好像有又好像沒有
不確定又確定
彼此喜歡的感覺

也許就是因為這樣
所以它才會是我最喜歡的一部宮崎駿卡通吧~~~

回憶錄之聽說~~

吃晚飯前，轉到電影台，剛好正在播放｢聽說｣
雖然我從來沒有真正的看過這部電影
但它卻跟我過去的記憶有所連結，不知道有沒有記錯
就在我其中一頁的碩班回憶錄中~~

大概是我在準備口試之前的日子吧
那天是一個很歡樂的夜晚，大家晚上都還留在LAB
然後有一台投影機，不過我已經忘記它是為什麼留在這邊，沒有歸還
於是將它架設起來，連上電腦，打開播放器
接著遇到了一個很困難的問題，就是要看哪一部電影呢？
過了好幾分鐘的挑選，終於選定了，就是 " 聽說 "
大燈關掉，零食上手，準備開播~~
然而
我並沒有參與其中，當時我正看著跟投影屏幕垂直的電腦螢幕
點擊滑鼠打開 ultraedit 開始編寫我的論文草稿
所以我說我沒有真正看過，因為我只有 聽 說 過
在那之後，不知不覺已經過了兩年，依然沒有完整看過
其實當天我跟著其他人一起看 聽說 也沒什麼不好啊
你說是不是呢~~

台積電面試 - 半年後的第二次面試~~

=====考試及第一關面試=====

面試時間 :15:30 (三) 

因為是上班日，偷偷的請了一個假去面試，科科~~

首先到七廠做一般性的測驗 

就是人格特質的測驗跟一分英文測驗 (寫人格特質測驗差不多需要半小時，英文測驗在半小時)

不過上次考過適性測驗了，這次只有考英文，所以很快就考完了

原本想說要上 global english 練習一下，因為上次考的不太好，結果在我登入global english系統後

讓我發現一個驚為天人的事實

就是免費試用的方案已經沒有了，正好，那就去碰碰用運氣吧

結果最後好像有560幾分，比上次高了一百多分(上次400出頭)，運氣真的很不錯，科科

面試的地點一樣在另一個廠，2&5廠

因為這次只有考英文，考完還有大概一個小時才要面試，所以我就在2&5廠看我的小說：流浪鼠之歌

結果看的有點過頭，剛好IT助理的手機又沒電，所以櫃檯5快點才連絡到人

因此到面試場所時有一點遲到

上次的面試官 分別是北中南資訊部門製造資訊處的主管

而這次我就不清楚了 不過因為有一個比較忙，所以只有兩個主管

一開頭他們就問說 你從台南來的喔(因為碩班是念成大的關係)

結果我說不是，我在上班了，在HTC

他們才恍然大悟般，原來我已經在上班了

這件事讓我覺得，面試官好像真的很少會有人事先看面試者的履歷

打完招呼

一樣先自我介紹，結果還不到一半

他們就按耐不住，開始問為什麼我想要換工作

而且還工作不到半年

結果我就開始說 我在家想了很久的藉口 而且還在腦中練過幾回

這個故事就要從去年面試TSMC後，卻沒有任何的回音開始說起

說到一半，他們就開始好奇另一個點

就是去年為什麼沒有錄取我

因為從履歷上看起來 成績還不錯，又有社團經驗，而且英文也考的不錯

結果兩個主管就開始想知道 上次面試我的是哪些人，還查詢人事系統問我是不是這些人

他們還很熱烈的討論及回想 去年10月多的情況

後來下了一個結論 10月以後 人事凍結，如果我早一個月去面試就會錄取了

不過這也只是他們的猜測

接著又聊了一下 製造資訊處 值班星人的作息

並介紹一下各IT處的工作內容

然後很開心的就結束了

最後作交通車回七廠時，還跟其中一個面試官一起做，雖然在車上沒對話

後來有提到可能還會有第二次的用人單位的面試

應該下個星期就可以知道結果

面試結果：再等一個星期吧

=====隔天=====

在公司接到了用人單位主管的電話面試

不過大部分是他直接問問題，然後我回答

為什麼想來TSMC，為什麼想換工作，有什麼社團經驗，英文考的還不錯喔，有沒有想問的問題 等等的

還說明了一下他是在做MES系統的核心程式部分，而且要用C/C++寫

如果沒問題 那我要往上送了喔   然後電話面試就結束了

這次的電訪，我瞭解到了一個真相，就是上次真的是因為人事凍結

就......了

不過最後我還是不知道用人主管的姓到底是林還是倪 (最後根據我的打聽，其實是姓倪)

=====過了一個周末，星期一到了=====

換HR打電話來，很不巧的，剛好我在上廁所，所以要他10分鐘後再打

還蠻準時的，我接到了點話，不過不好意思說太大聲，因為同事就在我身邊

所以說的蠻小聲的，而且還花了很多心思 想我的遣詞用字，不要太露骨的讓人很容易聽出來我要跳槽

一樣先問一下目前上班的情況，然後為什麼想要到TSMC，怎麼會知道到TSMC會比HTC好

還有社團的經歷，論文的內容 等等的

最後就是重點，什麼時候可以到職

結果我在跟她鬼打牆

她說大概兩周差不多 一般人都可以到職

因為我問她常見的情況是多久到職 

她又一直說每個人會不一樣，要跟據前一份工作的交接情況，離職手續的辦理流程

不過我覺得有點短，所以有問了一下大部分人是多少時間

她又說跟據前一份工作的情況

我又說因為我不確定公司的規定，不過最晚七月以前

結果，她說太久

我又問那可以建議一個時間嗎

她又說跟據前一份工作的情況

鬼打牆幾次後，我說可能要查一個公司有沒有什麼規定，那就先訂在6/1吧  有問題再跟妳說

終於 她說好 會請小人資在跟進

於是結束了這次的人資電話面試~~

再來可能就要等5/1過才會有消息吧~~~~

=====5/4=====

經過一次的電話漏接，其實是因為在睡覺所以沒接到

今天接到人資恭喜的電話，並確認到職日期(6/4)

Welcome to TSMC.

那些年，我們一起寫的BUG－Primitive VS. Wrapper Class

人生只有比較，就失去自己的意義了。
                                                                                           － 俠刀 蜀道行


這個bug是實際發生在我身邊的，事情是這樣的：
有一天，我的兩個同事拿著兩支手機在測一個行為，很簡單的行為。就是從資料庫中抓一個整數值，再用現存的值跟資料庫得到的值做比較，如果一樣就顯示結果A；否則就顯示結果B。
但是兩個人卻測出不同的結果，然後又試了好幾支不同的手機後，結果發現偏偏只有那一支有不一樣的結果，真的是非常的奇怪。然而，在經過我同事細心的測試和追查後，終於找到原因，原來那支手機剛剛被我用過，結果被我搞爛了。

可是為什麼會這麼容易被我搞爛呢？其實是因為程式有bug，在因緣巧合下讓我把它從潛在的狀態中解放出來，所以並不是我的錯喔！而那段程式片段概略如下：

int getFromDB() {
        //do something
        return value;
}

Integer value1 = mValue;
Integer value2 = getFromDB();
if (value1 == value2) {
        System.out.println(“A”);
}
else {
        System.out.println(“B”);
}

根據正確的邏輯，我們要得到的結果是A，而不是B。也就是說，在一般情況下value1和value2會擁有相同的值。上述的程式碼乍看之下，好像沒有什麼問題，但它還是造成了兩個不一樣的結果。我想，眼尖的人也許已經發現到問題在哪裡。問題就發生在if條件判斷式的部分。value1和value2是物件而不是基本型別的變數，如果直接用==比較，比較的是物件的記憶體位址而不是它們實際的值。既然比較的是記憶體位址，兩個不同的變數，應該存在於不同的記憶體位址，應該永遠只會走到B的路線。可是弔詭的事發生了，大部分的手機走的都是A路線，只有那個被我搞爛的手機走到了B路線。

其實這個現象是由於Java中wrapper class和autoboxing的機制所造成。在解釋原因前，首先介紹Java中的wrapper class。wrapper class的出現是因為，Java裡面提供的許多API只能針對物件(例如，Collection)，無法適用於基本型別(即int, long, char, boolean等)。為了使這些基本型別也可以適用，所以Java創造了與這些基本型別相對應的wrapper class。

boolean ＜－＞ Boolean
byte ＜－＞ Byte
char ＜－＞ Character
short ＜－＞Short
int ＜－＞ Integer
long ＜－＞ Long
float ＜－＞ Float
double ＜－＞ Double

至於autoboxing，就是自動的把primitive轉成wrapper的機制；而與unboxing就是自動把wrapper轉成primitive的機制。例如，在Java中如果直接將基礎型別的值或字面常數(例如，1, true, ’a’, “ABC”)賦值給wrapper class的話，Java就會啟動autoboxing的機制，產生一個屬於該型別的物件，並把該值存到該物件中，讓基礎型別變成物件。再深入一點探討的話就會發現，這些自動產生的wrapper class物件其實會構成一個pool。當autoboxing再度發生時，Java就會先檢查pool中是否有相同的值，有的話就直接回傳有相同值的物件；否則的話，就會再產生一個新的物件來存這個值。

因為這樣的機制，當value1和value2值一樣的時候，就會指向同一個記憶體，使得流程往分支A地方走。既然是這樣的話，怎麼會導致另一個同事出現往B走的現象呢？其實這又牽扯到autoboxing的另一個重要的部分。
Autoboxing的原意是要減少實體化的物件數，因此透過建立了一個pool來儲存這些物件，但這也造成另一個問題，也就是這些物件不會隨便被刪除掉。如果沒有限制的建立這些物件，記憶體一定很快就會用光的，所以Java給每個wrapper class的pool設立了最大值的暫存限制。也就是說，當要賦予的值超出某個範圍的話，就會以一般物件建立的方式建立(ex. Integer I = new Integer(321);)。

Boolean：  (全部暫存)
Byte：         (全部暫存)
Character：    [0, 127] 暫存
Short ：         [-128, 127] 暫存
Long：           [-128, 127] 暫存
Float：        (沒有暫存)
Double：     (沒有暫存)

因此，當value1或value2的值超過127時，value1和value2就會指向不同的記憶體位置，使得程式往分支B的部分走。到此我們就可以清楚的了解到，造成我的兩個同事測出不同結果的關鍵原因。

透過這個例子，我們可以體悟到一個重要的原則：只要操作到物件之間的比較，盡量使用equals或是compareTo的方法，而不要直接＞, ＜, ==等運算子來比較，除非有特殊的需求。

//Fixed
if (value1.equals(value2)) {
        System.out.println(“A”);
}
else {
        System.out.println(“B”);
}

有這樣的一個故事(二)~~

太空戰士九中的主角很喜歡說故事，
這個故事除了他在述說外，還有聽眾(就是女主角)的反饋，故事是這樣的：


很久很久以前，有一個人
一個不知道他自己從哪裡來的人

這個人在他還是個小孩的時候，就很渴望找到他的出生地
他的出生地，一個他只在夢裡見過的地方
＜為什麼呢？＞
他想知道更多，自己的身世，自己的父母，還有他出生的那棟房子

一天，他離開了，為了找出答案
但他的線索只有在夢裡看到的藍色的光
＜藍色的光？＞
對，他想這也許是他對故鄉的一點印象，或許是一片海洋？

＜他找到了嗎？＞
不，他一直沒找到
他怎麼找得到呢？他只記得那藍色的光
所以他又回去他養父的家

你猜當他回家的時候他養父做了什麼？
＜歡迎他回家？＞
想得美咧！
他養父舉起拳頭打了他這個辛苦工作賺錢養大的兒子。
＜為什麼？＞
我不知道

接著還有讓他更驚訝的事
他養父在打了他之後又笑了！
你相信嗎？
他才剛剛打了他兒子一頓
但是當他看見他養父的笑容時，他在想
這就是我家。一個叫做家的地方
這個人仍然在找他的故鄉
不過他已經有一個家了
也許. . .

偽技術文章 - 重構

看那看不到的東西，聽那聽不到的聲音，知那不知道的事物，才是真理。
                                                                                             － 達摩


繼數學女孩系列(*1)後，結城浩的第三本書(其實應該是第四本)終於入手：Java 重構。這本書除了翻譯有些怪怪的、程式碼部分的單字大小寫有些有問題；其餘都還不錯，範例淺顯易懂，而且重要的一些重構手法都有提到。

最近時間比較多一些，於是開始K這本書，看了大約一半，突然有了一些心得。書中常常重複的提及：
1. 重構，在不改變外部可見的程式行為的前提下，將程式內部的結構進行改善。
2. 重構一定要Step by step。
3. 重構過程中，需讓現存及新的方法同時並存，再用新的取代現存的。
4. 重構每一步都要經過仔細的測試(一般會撰寫單元測試搭配重構)。

這樣的定義，讓我想到前幾個月我在修改負責的AP時所做過的事。由於leader的一些疑問，因此要求我將使用SharedPreference(*2)儲存的機制，修改成使用Database來儲存。

這個問題困擾我很久，因為SharedPreference幾乎跟整個AP交纏在一起，我想這就是鮑伯大叔提到的僵化性(Rigidity)(*3)，也就是牽一髮而動全身，修改一部分全部的地方就要跟著改。

過了幾天，我還是想不出一個簡單可以修改的方法，於是突然想到：不動手，想太多都是沒有用的。於是我開始動手改，果然隨便改一下就編譯不過了，過了幾個小時，整個code終於被我改爛了，YA！然後我又默默的從Codebase中下載一份全新、未改爛的程式碼。

有了上次的經驗，經我反思後，想到了一個方法：就是讓現存的方法和新的方法同時並存，然後再去比較使用新方法獲得的值是否跟現存方法的一樣，如果不一樣就表示新方法有bug。於是我依循著這個原則，開始了我的修改程式大作戰。

一開始因為怕改爛，所以一次改一小小的部分，然後測試了一下好像OK耶，於是就繼續改下去。慢慢的愈改愈有自信，就想說一次改多一點吧！結果，又被我改爛了，害我花了點時間Rollback到沒改爛的進度。這讓我學到，真的還是要一步一步的修改，確認無問題再繼續往下走。

終於，兩種儲存的方法終於並存且可以獲得相同的值。接著，我慢慢的將判斷式中有使用到值，從由SharedPreference獲得的方法改成由Database獲得的方法，改好一小部分就測試一下。慢慢的改慢慢的測，終於SharedPreference已經不被原來的程式所使用到。於是我就忿忿然將所以存取SharedPreference的方法砍掉，真的是超爽的。

回到開頭提到的Java重構原則，恰恰都跟我在修改程式的過程中所體會到的不謀而合。
1. 在替換Database的儲存方法後，使用者使用的功能要跟原來的一樣。
2. 讓SharedPreference和Database的儲存方法並存，再慢慢的替換它們。
3. 急躁的修改易造成失敗。
4. 不斷的測試這兩種方法獲得的資料是否相同。

經過書籍的閱讀及這次的經驗，我覺得重構只是一種系統化的流程，只要根據這個流程並小心的修改，應該都不太容易失敗；反而是為什麼要重構，重構前後對開發者或現存程式碼有什麼影響才是最重要的。如果只為了重構而重構，只會讓程式變得更加複雜與難以維護；適當的考慮每個環節，評估現有程式的結構性，找出重構與不重構的平衡點，我想才是重構真正的原意吧！


莫名其妙寫了一堆，其實自己也不是很懂，果然資管的就是愛嘴砲。

註：
*1. 結城浩所編寫的關於數學的高校愛情小說。
*2. SharedPreference是android提供的一種儲存機制，可以將資料存成xml的格式，並寫入到磁碟中。
*3. 僵化性：系統難以修改，因為每一個修改都會迫使系統其他部分也要變動 (出自：敏捷軟體開發 - 原則、樣式及實務一書) 。

偽技術文章 - assert

最近空閒的時間比較多一些，所以萌起了寫技術文章的念頭，這一部分是我在公司寫的關於Java中assert的介紹與使用。

Assert is a keyword in java, just like for, if, switch, etc. It means assert is a native function in java.
Usage:
        int x = 5;
        assert x > 4;

If the condition is true, it will do nothing; Otherwise, it will throw java.lang.AsserError and then crash the process.

Note that assert will always be compiled in byte code. It means more you write, then the larger byte code you obtain.
By the way, the assertion mode is disabled in default java command. We need to use parameters to enable it.
Usage:
        javac Test.java
        java -ea Test   ＜= enable assertion mode
        java -da Test   ＜= disable assertion mode

In android, we can use adb command to open assertion mode:
        adb shell setprop debug.assert 1   ＜= enable assertion mode
        adb shell setprop debug.assert 0   ＜= disable assertion mode

Using assert instead of comments is a common way. But we need to be careful not to change the original data and function.
Furthermore, it cannot be used to do error handling because behavior would be changed if assert is disabled.
Example 1：
        x = getValue();
         /* 20 ＜= x ＜= 50 */

Using assert instead of comment：
        assert isBetween(x, 20, 50);
        private boolean isBetween(int value, int lb. int ub) {
                if(value ＞= lb && value ＜= ub)
                        return true;
                else
                        return false;
        }

Example 2：
        x = 19;
        if( x＞=20 && x ＜= 50 )
                doSomething(x);
        else
                throw new Exception(“Not between 20 and 50.”);
Bad codes
        x = 19;
        assert isBetween(x, 20, 50);
        doSomething(x);

The example of snippet shows that if x is not between 20 and 50, it will throw an exception and doSomething(x) is unreachable.
In bad codes, using assert instead of comments will change the original behavior. The function doSomething(x) will always be reached whatever x value if assert is disabled.

As mentioned above, it may obtain the larger byte code because of more assert. However, we can use the if-condition to make assert unreachable in order to avoid this problem.
Usage：
        private static final boolean DEBUG = false;
        int x = 24;
        if(DEBUG) {
                assert isBetween(x, 20, 50);
        }

Per this method, assert will be removed by code optimization in compilation process.

P.S. We also can use junit assert api for debugging.
http://developer.android.com/reference/junit/framework/Assert.html