練英文最好的理由

許久沒有更新自己Blog，都差點忘記自己還有這一個紓解自己情緒的地方。最近發生一些事情實在是不吐不快。

話說中國人長久受到儒家思想的薰陶，或者應該說是遺毒。通常做十分說七分，對人不吐惡言，對自己或是底下的人的要求標準嚴格。但是我發現在一個與許多不同國家的同事一起共事的環境裡，這未必是件好事。或者說應該適時的調整一下自己的態度。不卑不亢是美德，但該出來Fighting的時候還是不能讓。

事情的緣由是我親愛的以色列同事在過微軟WHCK認證的進度太慢，老闆Push他們總有一堆的理由。搞到對手公司的認證都過了，每次業務去拜訪客戶都被洗臉，業務的處長實在受不了，希望我能在IC回來的空檔，能夠幫忙加速認證的速度。大家都在同一艘船上，雖然不是我分內的事我也答應下來。有趣的事情在後頭，當我拿回來Source Code一看，才發現和我去年11月移交給以色列的版本並無太大的差異，很多認證的部分卡關只是HID的ID不符，修改Bios的設定就可以通過許多項認證。這下子我老闆氣得不得了，為什麼台灣的RD不到一個月時間就通過驗證而以色列不行，想直接把驗證Report寄給以色列的RD Team，質疑他們工作的能力，在我好說歹說總算把這封信壓下來。更有趣的事情在後頭，業務的處長突然打電話問我說問什麼以色列的RD Team說他們已經過了WHCK的認證了?我把mail拿來看，竟然把我reply給我老闆的report原封不動貼到他們的週報上，當場我就跳了起來質疑，反而換我老闆和業務處長安撫我，畢竟同一個產品線，IC賣最重要，大家心知肚明是誰做的就好。我和Team的表現不會因為這樣就被抹滅。

事後我平心靜氣地想，其實我並不在乎要去跟人家爭什麼功勞，而是我這次學到一個教訓。那封質疑以色列表現的信是應該要發出去的。畢竟大家公事公辦，有record事後也不會有這些鳥事發生。我當下選擇息事寧人除了想顧及以色列同事的顏面外，最主要的原因是我不想引起一場e-mail大戰，往返的e-mail除了吵架外，對我來說只是浪費我的時間去回那些官場上的英文書信。只能說怕熱就不要進廚房。這次我真的覺得練英文最大的好處就是吵架不能吵到詞窮，你要打官腔我就奉陪到底。親愛的小乖，爸爸已經決定要從小訓練你的英文，至少吵架不能吵輸喔。

Brandson Sanderson

Brandson Sanderson一直是我最喜歡的一個奇幻作家之一，有興趣的人可以去看看他的website，相當具有奇幻風格的網頁排版方式，而且可以下載他一些作品來看。最近App的工作算是完成了一個階段，趁空閒之餘，啃完了他另外兩部已有中文翻譯的作品，諸神之城伊嵐翠與破戰者。

這兩部作品依然維持他最令人稱道的風格，就是不抄襲現有的奇幻作品的奇幻元素架構(托爾金魔戒奠定了奇幻文學的框架，想要擺脫他的設定並不是件簡單的事)。迷霧之子的鎔金術與血金術，伊嵐翠的符文描繪，與破戰者的識喚術、駐氣與身體彩氛都是相當創新與有趣的設定。(我強烈懷疑Sanderson的老婆有色彩學的背景，破戰者中奇幻元素用到的名詞，有些沒念過色彩學還不容易翻)。另外Sanderson對於人性的描寫也極其深刻與細膩(與我另一個喜愛的作家R.A. Salvatore一樣)，你可以看到故事中的主角們在思考與自省上的成長。伊嵐翠故事中 Derethi的樞機主教，一直對於自己的信仰，與讓亞瑞隆王國皈依Derethi所採取的手段上，無法獲得邏輯上辯證的一致而困擾不已，而發生在其他國家的慘劇更是他心中一直無法抹去的陰霾。破戰者中Vivenna因為自身的傲慢而一直被玩弄於股掌之間不自知，Siri因為旁人的刻意誤導再加上義卓司對於虹譜宗教的刻板印象，而一直對支撐國家與信仰的祭司們有所偏見。這些角色並不是神，但藉由一次次失敗與挫折，更讓讀者對書中人物產生共鳴。

Sanderson也是多重人物分鏡述事的寫作方式的好手。說到這種寫作方式，似乎因為冰與火之歌實在是太紅了，最近看到的某些作品都喜歡用這種方式來敘述小說，不只從單一主角的觀點來敘事的寫作方式，可以讓我們用不同角度來看同一件事，更可以用同理心去探究所謂正派、反派角色的心路歷程。但用不好的話容易失焦，簡單的來說，就是一個緊湊的氛圍好不容易鋪陳起來，就硬生生地被砍斷，分鏡到另一個角色去，而等到焦點再回到這個主角的時候，很多讀者早就忘記上次的劇情進行到哪了。但Sanderson的分鏡角色很少會超過三個，而且起碼都會圍繞在同一個敘事的焦點上，讀起來通順多了。至少比冰與火之歌的後幾部曲好，當初看冰與火第四部A Feast for Crows時，我是跳著章節看的，要不然實在很難想起來這個章節的主角上次到底發生什麼事。

最後，我個人認為看Sanderson作品最大的享受，就在於推理解謎的過程。自認為推理能力不錯的我，也是看到故事快結尾的部分才約略猜出來結局。到底伊嵐翠城為何會在十年前發生崩壞，虹譜的宗教信仰究竟從合而來?我相信這是每個正在看Sanderson書的人，如同上了癮般，欲罷不能地翻著書頁的最大原因。

MediQ 醫療輕鬆排!

自己的第一個App經過一個禮拜總算上架了，而且還在上架當日衝上醫療排行榜第一名。由於是免費的軟體，收入主要為廣告和掛號的抽成。我跟小君說就算是在做功德吧。讓每天忙碌的年輕爸媽能少一點排隊的時間，或是讓行動不便的老人家不用一大早就在醫院枯坐著，那這隻App就有意義了。

畢竟自己也是新手爸媽，每次帶小乖去小兒科門診時，看到不舒服的小朋友們坐在門診診間前的坐位上，既無聊又怕在醫院交叉感染，如果這軟體能讓小朋友在快到自己的號碼再去醫院就診，既可排解看診的人潮和減少交叉感染的機會，我想這是我做這隻App最大的收穫 :)

關於iOS ARC三兩事

在iOS5引入ARC之前，舊的記憶體管理機制倒是很直覺。譬如每一個NSObject都擁有一個名為"retainCount"的變量，它表示該Object有多少個引用:

example 1:
NSObject *obj = [NSObject alloc]; //alloc會將obj的retainCount+1
[obj retain]; //retainCount++ 通常在Object賦值之後這樣做，代表它多了一個引用。
[obj release];//retainCount-- 通常在使用完該Object的時候這樣做
而當retainCount為0時，運行時環境會通過調用[obj dealloc] 來釋放obj佔用的記憶體。

example 2:
Test *t1 = [[Test alloc] initWithNum:12];//創建了一個物件,t1是該對象的引用，
//由於調用了alloc此時retainCount為1
Test *t2 = t1;//此時t2也要使用該物件
[t2 retain]; //t2要使用物件 就必須要retain，此時retainCount為2
[t1 release];//t1這時不用該物件了 就release了，也就是放棄了物件的使用權,
//此時retainCount為1
[t2 release];//t2使用完了 就release 此時retainCount為0，立刻會調用dealloc來釋放內存

而關於autorelease的用法:
iOS在global的空間中其實維護了一個型別為NSMutableArray的autoreleasey pool物件。可以利用[[obj alloc] autorelease];
這個函式將把obj加入到autorelease pool的Aarray中(此時obj的retain會+1)

autorelease pool會在系統閒置時，會給在Array中所有的Object發送release(retainCount-1)並從Array中移除物件，如果該物件 原本的retainCount為1，則會因pool呼叫release使retainCount為0，進而呼叫Object的dealloc，以此來實現 Memory釋放。
而obj在執行autorealse後，請不要再次執行retain，使得obj的reatinCount為2，在之後autorelease pool發送release時，obj的retainCount會為1，則會發生memory leak問題。

在iOS5引入ARC後，只要使用alloc來創建物件，則它的刪除與釋放就可以交於系統來處理 (retain release 交由compiler判斷)。ARC多了兩個修飾詞strong,weak來描述物件的指標:

strong :
(擁有該物件，即負責該物件的生命週期)
strong所代表的就像是我們所熟悉的retain-->確保這個成員變數在它的母物件尚未被釋放前都是依然有效的

example 3:
@interface DoctorEntity : NSObject
@property (nonatomic, strong) NSString * docName;
+(DoctorEntity*) doctorWithName:(NSString*) docName;
@end

@implementation DoctorEntity
@synthesize docName = _docName;
+(DoctorEntity*) doctorWithName:(NSString*) docName
{
    DoctorEntity* doctor = [DoctorEntity alloc]; //doctor.docName retainCount = 0;
    doctor.docName = docName; //doctor.docName retainCount = 2
    //與外部生成docName的共享物件
 
    return doctor;
}
在DoctorEntity被解構時，會將doctor.name設為nil 一併釋放

但如果強制將doctor.name設為nil
譬如
example 4:
+(DoctorEntity*) doctorWithName:(NSString*) docName
{
    DoctorEntity* doctor = [DoctorEntity alloc]; //doctor.docName retainCount = 0;
    doctor.docName = docName; //doctor.docName retainCount = 2
    //與外部生成docName的共享物件
    doctor.docName = nil;
    //不管doctor.docName retainCount為多少，retainCount一律清為0
    //進而釋放該物件在heap的記憶體
    return doctor;
}
@end

weak:
(不負責其生命周期，純粹使用指標)
weak修飾的指標純粹就是一個指向在Heap物件的指標,但是在物件被釋放後會自動設為nil。

如果不宣告，iOS5預設值都是使用__strong來定義變數，由編譯器幫你在適當的地方加上retain和release(與 autorelease)，如果要改變預設指標的修飾詞的話，可以在變數前加上__weak。就像是之前所說的weak，也就是說如果之後沒有其它人再參 照它，它就會被設定成nil。

因此一般的堆疊變數(local variables)如果你把它設定成__weak，而且之後也沒有其它的strong pointer指向它，則它就是一被生成就會自動被回收。

example 5:
__weak NSString name = @"My name is Franky";
NSLog(@"%@",name);
執行的結果會顯示為空白(因為這時name已經被設為nil了)

ARC大大簡化了原本使用MRC所需要的程式碼，但凡事有ㄧ好就沒兩好。ARC在程式有使用Block時，如果不小心，很容易引起retain cycle。
關於這個，又可以再寫一篇文章來論述了。

未來日記

一切都是由神對秋瀨透露出他乃是神的分身"觀察者"的這句話開始。倘若假設位於上界還有所謂這整個世界是由眾多伺服器所組成，人乃是位於上界櫻島市伺服器的AI，而神則是具有supervisor權限(具有改變伺服器運行的時間與空間能力)的人，則這一切故事都合乎邏輯，合乎程式設計的邏輯。

故事的一開始便是由乃(女主角)在Master的主支線上(一周目)，贏得了生存遊戲並殺死了所有的參賽者，取得了神的身分後，將整個世界(伺服器)的時間推回了一年前，藉由殺死了一年前的自己，引發了伺服器Create New Branch(這是版本管理的專有名詞，不知道該怎麼翻)的事件，也就是二周目分支世界的建立，未來日記的主要內容便是發生在這個支線上，藉由這個事件影響了在櫻島市伺服器上的所有人(AI)。

在7月28日世界的毀滅日，雪輝(男主角)知曉了由乃的真實身分之後，身為一周目神的僕人姆魯姆魯便將世界的時間推回了兩年前，藉由雪輝救了被自己父母關在牢籠中兩年前的雪乃，又觸發伺服器建立了三周目的分支，而故事的結局Happy End，就是繼承了一周目神的記憶三周目由乃，打破了三周目與二周目的藩籬，很像版本管理的Merge，將二周目與三周目的分支Merge起來，並成為主版本的運行。就如同神所說的，"人死不能復生"，這可能是在這殘酷的設定底下，所能想到的最好的結局了。

先不論我這個偏執的版本管理假設是否正確，這部在前年在日本造成轟動的漫畫，紅到富士電視台已經要在這個月推出日劇，我是直到最近才看動畫認識的。我一直很喜歡科幻類的小說與動畫，尤其是日本的科幻類動畫。其實許多優秀的科幻世界idea始祖都是由日本的動畫來的。士朗正宗的攻殼機動隊，電子腦連上網路的架構，其實就是駭客任務世界的基礎。但是像未來日記這樣結合科幻，推理與黑暗特色的好動畫並不多見，也無怪會在前年造成這樣大的轟動，尤其是黑暗這部分的描寫(我一直認為這是日本人的強項 XD)，讓我看完後胸口總覺得悶悶的，有一種說不出來的失落感。

圍繞小乖行星的小呆衛星與小君衛星

算一算時間過得真快，從小乖出生到現在不知不覺地已經過了三個多月了。在這段期間，我和小君就好像軌道上的衛星般地繞著小乖這顆愛哭的小行星團團轉，小君沒日沒夜地擠母奶想要讓小乖的抵抗力能好一點，臉上的黑眼圈因為睡眠不足變深了。而平時有事沒事就要求載她去去竹北的俏媽咪報到，次數多到讓我覺得俏媽咪應該搬個『惠我良多』匾額給她。我則在小君在坐月子中心時，就乖乖地將PS3封印了起來，凍結所有買遊戲和娛樂的預算。在公司只要是有空閒的時候就會偷偷開FB，看看我放上網小乖的照片和學游泳的影片，嘴角便不自覺地微揚了起來。每天下班回家的路上，我們倆的話題總離不開小乖，『小乖今天吃了多少?，在台北有沒有讓媽媽添麻煩?，他今天有沒有好好睡覺?』。

說真的，小乖的報到事前並不在我們的規畫之中。去歐洲度完蜜月後沒多久的一天晚上，小君便打電話跟我說，她懷孕了。剛聽到那句話的時候，其實當下的情緒並沒有太大的起伏，談不上很興奮或是激動。只是呆呆地說『很好呀』，接著就腦筋一片空白地一直傻笑。隨著日子一天天地過去，看到小君的漸漸脹大的肚子，突然覺得生命誕生真的是很奇妙，在媽媽小小的肚子裡竟然能裝下一個活蹦亂跳的小Baby。而隨著預產的日子越來越接近，胎動的次數就越頻繁，晚上夫婦倆的樂趣便是盯著媽咪的肚子，深怕錯過小乖踢小君肚皮的那一瞬間。而小乖的出生，照例地也不在醫生的預期之中，前一天才照過超音波檢查，隔天就比預產期提早了三個禮拜，選擇和小君農曆生日的同一天，來到這世界。剛出生時我抱著哭腫了雙眼的他，對著體重才2900公克的小乖說，『你知道媽咪生你很辛苦嗎?』，小乖沒有回應我，只是哭累了躺在我懷裡，睡的好香好甜。

最近這幾周星期天的傍晚，我和小君準備要從台北回新竹時，小乖都會好像是剛做了 一場噩夢似的，突然驚醒大哭。尤其是這個禮拜，他在小君的懷裡醒來後，就莫名其妙地哭的嘶聲力竭，餵母奶和吃奶嘴等平常會讓他安靜下來的方法都不奏效，我只好把他抱過來不斷地拍背，鼻涕和眼淚流地我的肩膀都是，過了幾分鐘後，大概是哭累了，才趴在肩膀上沉沉地睡著了。我小心翼翼地把他放回嬰兒床上，躡手躡腳地離開房間，生怕發出聲響又把他吵醒。回到新竹後，我打電話給高雄的爸媽，問老媽說『是不是小乖知道我們要回新竹了，捨不得我們走才大哭』，我老媽潑了我這自戀的老爸一頭冷水，『兒子，是你自己想太多了』，ㄟ~~對啦，當父母的誰不是無時無刻為兒女想太多 XD。

Qt與Nokia漸行漸遠?

從最近Qt 5 的Roadmap我們可以看出，Qt的野心相當大，lighthouse底下platform包含了除了以前就支援了Windows,Linux,MAC，Symbian之外，還新加入了Android與iOSX。等等，Android與iOSX??，Qt要造反了嗎??，既不提N9的Meego系統(其實還是舊系統Maemo)就算了，竟然冒大不諱去擁抱對手的OS陣營。

不可否認地，QT在NOKIA注入整個集團的資源的這兩年中，有很多驚人的發展與進步，LPGL授權吸引了世界各地開源的高手共襄盛舉，sourcecode一年有150萬次的下載記錄，Linux Embedded Device的GUI系統幾乎是QT的天下了(之前去拜訪電子書OEM廠商，也確定放棄自己發展的GUI系統轉而使用Qt)。但自從今年二月NOKIA擁抱WP7，而WP7不支援Qt決策確定後，就註定了兩者漸行漸遠的命運。

Qt的未來在於跨平台的OS數目越多越好，吸引使用者在開發桌上電腦與行動裝置的AP，能夠做到他們所強調的Qt Everywhere。而NOKIA希望QT只在Symbian或是Meego的平台上，幫助仍忠於其平台的開發者就好(難道自己花大錢把Qt扶植起來，卻被對手公司所用嗎?)，這兩家公司的商業利益已經不再一致，即使許多新的技術目前還只是支援Symbian，但是在forum上卻不少開發者成立自己的社群，將Qt延伸到他們所鍾愛的平台上。從Developer自動自發將Qt porting到Android與iOSX上的速度來看，許多開源的Programmers對NOKIA已經失去了耐心，NOKIA將Qt賣給Digia應是遲早的事情了。