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)，讓我看完後胸口總覺得悶悶的，有一種說不出來的失落感。