Objective-C 之 日期字串格式化與轉換

在撰寫程式的時候，時常需要把日期物件跟它的字串表示式來做互轉的動作。在Java中，可以透過java.text.SimpleDateFormat來做。而在Objective-C中，也有類似的類別，叫做NSDateFormatter。

NSDateFormatter的用法其實很簡單，就是建立一個NSDateFormatter物件，然後設定需要的dateFormat。之後如果是要把日期物件轉換為字串表示法，則用stringFromDate:；反之，則是使用dateFromString:。詳細內容可以參考：Simple methods for date formatting and transcoding

Objective-C的@synchronized

在Objective-C中，也有synchronized這個keyword，也是用來作thread synchronization，正是語法是

@synchronized(id) { ... }

，其中id是只要鎖定的物件pointer。而比較常用的情況是

@synchronized(self)

有趣的是，如果@synchronized(self)語法出現在一般的instance method，則self是指該instance；但是如果是出現在static method，則self是指該class本身。

抱怨！Google的產品彼此支援度不佳....

剛剛在編輯blogger上的文章時，發現不管怎麼弄，文章內的style一直就是弄不好...最後，想到該不會是Google Chrome的問題吧...所以換到Safari 5.0.2再試一次，結果就OK了...........

其實不只這件，Chrome在某些HTML的呈現與layout效果，似乎也不是很正確，反而是Safari真的是比較正確一點，也比較沒有問題...要不是Safari的memory usage比較大，而且

這真的是一大諷刺啊...Google...

Singleton pattern for Objective-C

在Java中，要撰寫一個應用Singleton pattern的class十分容易。但是在Objective-C中，就沒這麼簡單了。原因在於物件與記憶體的配置與管理機制是完全不同的（個人見解，不見得對）。

其實原理是都很類似，就是設法讓app只產生一個object instance，而且是透過特定的static method來獲得這個instance，而不是透過constructor來建立各個獨立的instance。對於一些某些需要集中管理的資訊或是資源，singleton pattern十分有用。

在Objective-C中，因為無法宣告constructor為private，所以很難避免使用者去呼叫。另外，因為Objective-C的alloc/retain/release/dealloc的機制，所以我們也必須去處理有關instance reference count的問題，不然很容易會出現記憶體管理的問題...而造成災難。

如何撰寫呢？首先，先在header file中定義要取得singleton instance的static method，例如：

+ (id) sharedInstance;

然後，在對應的.m檔案中，添加下列內容：

static MyManager *instance = nil;

@implementation MyManager

#pragma mark Singleton Methods

+ (id)sharedInstance {

@synchronized(self) {

if(sharedMyManager == nil)

sharedMyManager = [[super allocWithZone:NULL] init];

}

return sharedMyManager;

}

+ (id)allocWithZone:(NSZone *)zone {

return [[self sharedManager] retain];

}

- (id)copyWithZone:(NSZone *)zone {

return self;

}

- (id)retain {

return self;

}

- (unsigned)retainCount {

return UINT_MAX; //denotes an object that cannot be released

}

- (void)release {

// never release

}

- (id)autorelease {

return self;

}

- (id)init {

if (self = [super init]) {

// initialize your instance variables

}

return self;

}

- (void)dealloc {

// Should never be called, but just here for clarity really.

// release your instance variables

[super dealloc];

}

@end

首先，是定義全域變數instance，用來表示此class的singleton instance。然後實作之前定義的singleton method，讓它傳回該instance variable，如此一來，只要呼叫此method，就可以取得同一個instance。其他的method都是override原本NSObject的定義。主要是用來處理reference count的問題，用來避免該instance被不小心release掉。其中，在init跟dealloc，可以對自己定義的instance variables做初始化跟回收。原則上，Objective-C的singleton pattern大概就是長這樣。

心得：比起Java，真的複雜多了...而且老實說，我也不知道這樣想是不是真的沒問題...只是目前google到的寫法，大多是長得類似這樣。

參考：Singleton Classes

檢查MacBook Pro的硬體錯誤

一般來說，當安裝了新硬體之後出現問題，通常就是得自己想辦法從混亂的情況中，找出可能的原因。尤其是安裝了像是RAM或CPU這類的東西。有時候新的RAM有問題或是不合於目前硬體，是不會造成無法開機，但是就會讓你出現很多類似靈異現象的事。

在Windows中，至少我所知道的，就是只能用自己經驗跟third-party的硬體檢測軟體來判斷。但是每套硬體檢測軟體的結果又都不太一樣。

最近，我幫我的MacBook Pro加到了8GB，本來很高興的要工作，但是卻一直有很多不太正常的事...當然，很直覺的就判斷可能是RAM的問題。但是，該怎麼確定呢？於是Google了一些軟體做檢測，但是結果也是時好時壞。

但是後來發現，原來...Apple在出廠時所附的Application installation disc中，就有「Apple Hardware Test」的程式。只要把該片放入光碟機之中，然後在開機時按住「d」，就可以進入「Apple Hardware Test」，檢測很簡單，就是「標準測試」與「延伸測試」兩種。基本上，如果連標準測試都沒辦法過，就是有很明確的問題了。而我的問題在連續三次的標準測試都指出是RAM的問題...所以當然就是去創見處理囉～

結論：再也不用為了硬體檢測問題傷神了～

在Ubuntu Server Edition上安裝GUI介面

想把server改成用Ubuntu Server，但是又不想只用command line的方式來管理與設定系統。所以就想到在Ubuntu Server上面裝上gnome...但是又不想安裝完整的gnome

在參考How to install GUI in Ubuntu Server之後，自己就試著用

sudo apt-get install x-window-system-core gnome-core

結果真的可以安裝很簡易版本的gnome...幾乎沒有任何GUI app...連synaptic都沒有，所以只好再用apt-get來安裝

DOM-based XML utility For iPhone

在Mac OSX上，分別有NSXMLParser跟NSXMLDocument來處理有關SAX與DOM方式的XML parsing。然而在iOS上的Cocoa Touch，卻只剩下SAX的NSXMLParser的處理方式。相較於DOM來說，SAX的處理方式是較為快速與節省資源的，也或許是這樣才會在iOS上只保留這種方式的parsing。

然而，如果只是簡單格式的XML讀取，用NSXMLParser來parse可能是很快速簡便。但是如果要處理的XML格式眾多或是格式複雜，那就可能不是那麼好過了...而且NSXMLParser也只能處理讀取時的parsing。如果是要將資料輸出成XML格式，那不使用DOM的處理將會變得比較難以處理。

後來在internet上，發現這篇APXML: NSXMLDocument 』substitute' for iPhone/iPod Touch，才知道有這個APXML的DOM-based簡易套件可以使用。說它是簡易套件還真不為過，含Header file在內，全部也才不過6~7個source code files，每個也都不算太大、太複雜。

既然是DOM-based parser，當然除了可以讀取，也可以輸出成為XML。使用上很簡單，只要

#import "APXML.h"

就可以使用到全部的相關類別，不必一一去import個別的class。

Parse XML：

APDocument *doc = [APDocument documentWithXMLString:xmlstring];

取得Root Element：

APElement *rootElem = [doc rootElement];

讀取所有子element：

NSArray *childElements = [rootElem childElements];

讀取element name：

NSString *elementName = elem.name;

讀取element value：

NSString *elementValue = elem.value;

讀取特定名稱之attribute：

NSString *attrValue = [elem valueForAttributeNamed:attributeName];

輸出部分則為

Create Element：

APElement *elem = [APElement elementWithName:elementName];

Set attribute & element value：

[elem addAttributeNamed:attrName withValue:attiValue];

[elem appendValue:elementValue];

Add child element：

[elem addChild: childElem];

Create XML Document：

APDocument *doc = [[APDocument alloc] initWithRootElement: elem];

Output XML string：

NSString *xmlString = [doc xml];

使用語法算是十分簡單、直覺。

其實，要自己實作DOM-based parser也不算太難，但是總是比較費工夫、品質也需要時間來鍛鍊。既然有現成又不錯的lib，當然能善加利用會更好囉～

好用的HTTP lib(for iPhone & Mac OSX)

HTTP API其實在Cocoa裡面是有的，透過NSURL、NSURLRequest、NSURLConnection等類別來達成，也分別支援同步與非同步傳輸。使用上雖然不算是太難，但是仍然有不少繁瑣的手續要做，要處理的delegate method也不算少，讓人感覺還是有點不是那麼方便。

因此，後來在internet上，找到一個叫做ASIHTTPRequest的lib，這個lib是以BSD license的方式open source的。顧名思義，這個lib的主要工作就是提供HTTP protocol的通訊機制，而且用很簡單的方式讓developer可以操作request、response，以及設定POST parameter，甚至是上下傳檔案等等。本身也內建啟用Cookie機制，所以對於一些有session tracking的web services也很方便。當然也提供有同步與非同步的傳輸。
官網位置：http://allseeing-i.com/ASIHTTPRequest/

心得：該Lib除了可以在Mac OSX上使用外，也可以在iOS上使用，而且目前已經與iOS4相容。使用上算是很簡單，也沒碰過啥大問題。如果要說缺點，就是放到project中，會導致project code在compile之後多出不少容量吧XD

動態調整TableVewCell的高度

因為工作需求，原本要使用UITextView來顯示多行文字，但是發現使用了UITextView之後，Cell可以觸發select動作的區域將變得很小（受到UITextView的區域影響）。所以改用別的方式處理。

首先，發現原來UILabel是可以顯示多行文字的，只要把property numberOfLines設為0，就可以支援多行文字，但是必須呼叫[label sizeToFit]，來調整UILabel的大小。

而預設的UITableViewCell的textLabel也可以這樣調整，所以就可以顯示多行文字。然而，UITableView還有個問題，就是有cell height的問題。因為cell height似乎是在cell顯示前就會設定好，所以即使在tableView:cellForRowAtIndexPath:這個method裡面去調整cell的高度也是無效。必須透過tableView:heightForRowAtIndexPath:來回傳特定cell的高度。

但是，對於多行文字來說，因為內容行數是不固定的，所以必須在顯示時計算實際行數文字的總高度。幸好在參考iPhone SDK: Resizing a UITableViewCell to Hold Variable Amounts of Text, Part 2 of 2這篇之後，得到解答。就是利用NSString裡面的sizeWithFont:constrainedToSize:lineBreakMode:來根據指定的字型高度跟斷行方式來計算。可以使用Objective-C的Category機制，將此method放置到NSString中。以下是參考上述文章所寫的code：

@implementation NSString (TextHeight)

-(CGFloat) textHeightForSystemFontOfSize:(CGFloat)size {

//Calculate the expected size based on the font and linebreak mode of the label

CGFloat maxWidth = [UIScreen mainScreen].bounds.size.width - 50;

CGFloat maxHeight = 9999;

CGSize maximumLabelSize = CGSizeMake(maxWidth,maxHeight);

CGSize expectedLabelSize = [self sizeWithFont:[UIFont systemFontOfSize:size] constrainedToSize:maximumLabelSize lineBreakMode:UILineBreakModeWordWrap];

return expectedLabelSize.height;

}

@end

透過此method，就可以在tableView:heightForRowAtIndexPath:中回傳正確的文字內容高度了。

DB實作心得---SQL JOIN語法

因為都是用Hibernate，所以好久沒碰這種語法了...老實說以前在學SQL的時候，也一直沒很認真的搞懂。一直到最近為了案子，才又比較認真的去看了...

找了幾篇網友分享的文章，都講得很清楚，所以就不在贅述：

• SQL Join語法筆記
• 用SQL合併資料表
• [SQL]Join的觀念

一般來說，我們通常都會儘量用一個SQL statement的方式來完成所需要的查詢。而其中都儘量可以用JOIN的方式來把所需要的資料串出來。不過我也有看到有網友發表心得，表示在MySQL上，進行較複雜的JOIN時，效率會很糟糕，甚至會造成DB table被lock過久的情況。事實上，幾年前我自己也用過MySQL，也是發現它在作較複雜JOIN時，效率真的不好...所以後來我就都改用PostgreSQL。

而在Hibernate中，我所常用的Criteria是一種物件式的查詢方式，它建立跟其他table JOIN的方式是透過createCriteria()或是createAlias()。透過這兩種method，可以把要查詢的root entity跟child entity作JOIN。在建立這種JOIN關係時，Hibernate預設是使用inner join的方式，所以在某些情況會無法正確的找到所要資料，甚至會出現LazyInitializationException。此時，可以試試看在這兩種method的呼叫時，加上Criteria.LEFT_JOIN，這樣Hibernate會以Left outer join的方式處理，也許就可以成功的找到所要的資料了。

我個人認為與其使用一個很複雜的SQL statement來增加查詢效率，未必比使用多個簡單的SQL statement來取出資料再透過自己程式邏輯作處理來的容易跟快速...

Database系統實做心得---SQL調校

做了很久跟DB有關的開發工作，但是其實後來大部分都是靠Hibernate為主。透過它，開發者不再需要傷神有關DB底層的設定與SQL語法的管理與維護。不過也變得比較偷懶，比較不會去在意SQL語法上的調校。

在網路上有許多高手有此道的獨到心得，我只也是從中獲得一點點，這兩偏是個人覺得還蠻不錯的：Database Index 筆記 與 調校 SQL 以徹底改善應用程式效能

其中有些跟DB table schema設計或是SQL語法的技巧，不過在Hibernate中，要使用這些技巧可能就不是那麼容易。Hibernate是允許使用者自行設定這些東西產生的方法，甚至可以自訂SQL statement。不過個人覺得Hibernate自己所產生的schema跟SQL statement已經很不錯了，除非真的很有特殊的需求，不然實在也沒必要自己搞（如果都要自己搞，那就失去用Hibernate的意義了）。

不過兩篇文章都有提到的一個重點：index。在Hibernate中，也有支援產生index的機制，但是只會對primary key跟unique column自動產生。雖然在Hibernate Annotation Extensions中有@index的annotation可以指定對某個property產生db index，但是這功能只有在透過Hibernate作第一次DB schema建立時有效；若是指定的index的table已經存在的話，這機制不會有作用，就必須手動產生。根據上面兩篇文章的內容，產生與刪除index的SQL DML為：

create index index_mytable_mycol on mytable(mycol)

與

drop index index_mytable_mycol

而根據上述兩篇文章的講法，幾乎都認為應該對FK也設定index比較好。當然有些但書，例如在主table資料量有到一定量以上的時候才會比較有效果等等的。

32bits vs 64bits part2, 32bits未必不好

之前就提過有關Snow Leopard的kernel mode的問題了...事實上我一直很困惑為何Apple不把Snow Leopard的kernel預設為64bit的。

當然，後來也去查過很多的文章，發現不管是國內外的一些使用心得或是報告，都是差不多的結論，就是32bit跟64bit的效能差異不大。其實我自己的感受也是一樣。而不管是使用者或是官方的說法都是說32bit kernel的相容性比較高...這點在我上次要透過iPhone來上往時也證實了...目前某些driver或是軟體可能是無法在64bit kernel下運作的。

當然，自己還是很不死心的測試了一下...用XBench...來測試32bit跟64bit的差異...結果...就分數來看兩者差異真的很小...才2~3分左右...事實上還是32bit贏的。而分項成績則是互有優勝，但是差距不大。除了在記憶體方面的項目中的allocation，64bit有大贏之外，其他的其實大部分都是差不多。而32在OpenGL跟一些圖形顯示方面是有些小贏...不管測幾次都一樣。剛好符合一些使用者的講法，目前在顯示driver上，Mac OS的32bit driver的最佳化是比較好的。

官方講法是說64bit kernel在安裝有大量記憶體（32G以上）的情況下才有需要啟動，而其他情況則與32bit無異。

不管怎樣，Snow Leopard的確讓64bit的app更加廣泛的被使用了，數量也變比較多...雖然還是不少32bit third-party app。能以32bit kernel來良好運作64bit app，apple的工程師也是夠厲害...

至於很多人都猜測，在下一版的Mac OS應該就會改變成為64bit kernel...我個人反而不是那麼看待...畢竟目前還是不少driver跟app還是32bit的...轉換為64bit kernel，對Apple來說會有好處還是壞處，還是難講...這也許也是Snow Leopard採用32bit kernel的原因。除非在新一版的Mac OS出現的時候，已經有更多重量級的driver跟軟體都轉換到64bit，否則用32bit kernel來運作應該還是必然的吧

講了一堆屁話，結論就是我又回到32bit kernel了XD

香草輸入法, 新酷音模組 & Snow Leopard

之前一直都是用Yahoo輸入法，是沒太多缺點啦...如果要說的話，就是猜字的準確度不高，而且不方便自己加詞。之前有人一直推薦我使用香草輸入法，但是Google之後，發現目前香草輸入法在0.9a1，看起來不算是很穩定的版本的感覺...而且我又是用64bit kernel，剛好又不在開發團隊有測試過的OS版本內，所以一直很遲疑...

但是，對於新酷音的猜字準確率很難忘，所以今天還是『冒險』一試了...為何說冒險...因為官網上有段話很嚇人：『請注意：輸入法屬於重要系統元件，系統可能因為輸入法軟體的bug而造成不穩或循環crash。如果發生這種情況，請以其他使用者登入後，砍掉輸入法元件檔案』...聽起來就感覺好像穩定度不高的感覺。

不過後來安裝，發現也沒想像中的難跟有問題...跟一般的Mac App安裝沒啥兩樣。不過...安裝玩香草輸入法之後，發現...沒有酷音模組...得另外下載跟安裝... 所幸官網文件還算詳盡。

試用的感覺：從活動管理員看，輸入法本身似乎所耗用的memory要比Yahoo的少蠻多，大概只有一半還不到，不過目前沒有for 64bit的版本（Yahoo的是64bit版本），所以只能用32bit啟動，但是使用上並沒有什麼問題，速度也算是很快。手動加詞的功能可以work，但是似乎只能按住shift之後，再按方向鍵的左鍵選擇詞彙長度，如果從輸入的句子中間開始往右選詞，則會失敗。至於穩定性，目前感覺不出來有啥大問題，可能要多用一陣子吧...

目前香草輸入法的進展感覺好像有點停擺了...目前的版本是2009.8月份的；而新酷音模組則更舊...感覺有點可惜就是...

Updated: 原來Yahoo奇摩輸入法也是有手動加詞功能，而且方法跟香草輸入法是一樣的

令人沮喪的事實？！Firefox的CPU 使用率問題

因為今天在公司用MacBook Pro，原本之前電池都可以撐很久的，但是今天卻只撐了3小時左右。讓我覺得有點納悶...所以剛剛查了一下...發現...Firefox會一直有CPU usage，即使只有一兩個很簡單且沒有flash的page而已...

當然，到Google上去搜尋，也是得到類似的結論...元兇的話，plugins是一大因素，但是我也用safe-mode的方式去啟動Firefox，但是還是會有持續的CPU usage，只是比有啟用plugins來的少一點。

感覺很「冏」啊...Firefox的一大優點就是有豐富的plugins來幫助瀏覽，但是...現在卻也變成CPU使用率的大怪獸...也許會有人覺得：反正只是多耗一點點的CPU usage，現在CPU都那麼powerful，沒差啦...
但是如果是在筆電尚且使用電池的環境，這可就有很大差別了...因為持續不斷的CPU usage會讓系統處於busy的狀態...CPU就無法進入比較省電的模式了，自然電池就會很快用完....

嗯...真是兩難啊....看來如果用電池模式的話，可能不適合使用Firefox吧...使用Safari跟Google Chrome倒是都沒這種問題。

P.S: 除了發現Firefox有這問題，M$的Messenger for Mac也會在沒動作的情況有CPU usage，但是沒有像Firefox那麼嚴重

Update: 後來發現原本以為應該不會有動作的Google搜尋結果頁面，其實似乎也是有javascript在背後慢慢跑？！為何這麼說呢...因為在Safari、Chrome跟Firefox都發現同樣的情況...但是，結論還是沒有變，Firefox在CPU使用上還是偏高。在改用Safari跟Chrome之後，MacBook Pro的溫度明顯降低。

Snow Leopard的Kernel mode的真相

Snow Leopard這次的賣點之一，就是64bit，強調64bit帶來的效率與好處。而Snow Leopard這次的確把大部分的內建軟體都改版為64bit了。

但是，有趣的是kernel的部份居然還是使用32bit，而更有趣的是在32bit的kernel之下，透過「活動監視器」去看，卻是會看到有軟體是以64bit來運作的。相當神奇吧？至少我是這麼認為...當然也許是我認知錯了也說不定啦

如何讓Snow Leopard真正的以64bit運作呢？也很簡單，只要開機過程時，按著6跟4就好。但是這種方式只有在該次開機有效，重開機之後，就會回到32bit了。想要永久的切換的話，可以安裝一個SixtyFourSwitcher，透過它就可以做永久性的切換了，不管是從32->64還是64->32。

切換到64bit有何好處呢？理論上是會效能更好一點啦...但是其實在Snow Leopard上面的話，感覺到不是很明顯（不過我在Ubuntu上倒是有比較明顯的感覺）。也許是目前為了兼具32與64bit共存的情況，所以還沒辦法完全發揮64bit的能力吧。不過可以在不用重新安裝的情況，就切換kernel mode，這也算是一項特點。至少在Windows跟Linux上，都必須重新安裝64bit的版本才行。

MacBook Pro + iPhone 3GS的行動上網

前天因為使用的SEEDNET數位光纖突然大斷線，導致沒辦法上網。後來想到，iPhone有「internet 分享」的功能，剛好又是3G費率吃到飽的方案，所以試了一下...

設定很簡單，只要到iPhone的「設定」->「一般」->「網路」->「internet共享」打開就好。然後它會要你選擇只用USB共享還是USB跟Bluetooth都啟用。如果有USB連接線的話，建議只開USB就好，可以一邊充電一邊上網。開啟之後，將iPhone連接到MacBook Pro，就會在Mac OSX上看到找到新的網路裝置，叫做「iPhone USB」，選擇它作為連線的網路裝置即可。

不過，實際試的時候，卻發現不能work...怎麼設定跟連結就是不能透過USB來連線...但是如果有啟用Bluetooth，則是可以透過Bluetooth來連線，但是速度就會變比較慢。後來詢問Google大神之後，發現...原來如果啟用Snow Leopard的64bits Kernel模式，就沒辦法透過USB的方式連結。所以只好先把kernel模式改回32 bit再重新啟動。果然，就可以順利連線了。

使用心得的話，3G上網其實還是蠻不錯的，雖然速度不及於數位光纖，但是也在可以接受的範圍了。不過訊號穩定性是個問題，因為有時候會有突然變慢的情況。不確定在使用「internet共享」的時候，能不能收發電話，有試過但是發現，有時候會造成網路斷線，但是有時候又不會。

不能在64bit kernel mode下使用USB的internet分享，是唯一美中不足的地方...畢竟Snow Leopard的賣點之一就是64bit~

I love Mac~

09/12/31我拿到了人生中第一台的MacBook Pro，雖然只是13吋中的最低階款，但是還是很令人興奮。

之前我就偶爾會去台中誠品B1的Apple專賣店看看，但是畢竟沒有真的很深入的用過，所以剛拿到的時候，其實有點心慌慌，不知道怎麼用。但是試了一下，慢慢就開始有漸入佳境的感覺了。讓我感到最棒的是multi-touch的觸控板，一開始我也只覺得這觸控板大概只是噱頭，要有外接滑鼠的打算。不過看了設定裡的示範，跟實際操作之後，我反而覺得Windows 7的觸控螢幕的功能是多餘的。真正的好的觸控操作不見得要在觸控螢幕上啊～這讓我對Apple更加佩服了。

在Mac OSX上面安裝程式十分簡單，用safari下載的dmg檔案會自動地掛載為安裝媒體，然後只要把程式的圖示拖曳到Applicaions圖示或是資料夾中就ok；移除的話，也只是把程式拖曳到垃圾桶就好，都十分直覺。Dock的操作也十分簡便，不過點選Dock上的圖示只能把以開啟的程式從最小化還原，而不能最小化，這點有點可惜。而沒有『剪下貼上』功能也是讓人覺得美中不足。Global menu讓一開始接觸的我很混淆，常常會找不到menu。

因為買的是新款的MAcBook Pro，是全鋁合金的，用的是新款強效電池，官方號稱可以撐7小時，實測結果的確是很久。系統在idle的時候的省電機制做的很不錯，今天在辦公室從早開機到下班，將近7~8小時，雖然中間也有不少時間是在idle，但是對於一般筆電來說，也是沒辦法撐這麼久的。而且使用電池的時候，其實幾乎感覺不到有效能下降的感覺。OS是Snow Leopard，有64bit跟32bit的kerenl模式，預設是以32bit kernel啟動，據說是為了相容性問題。但是在開機的時候可以按著6跟4就可以以64bit模式啟動。64bit模式似乎有快那麼一點點，但是其實我感覺沒有很明顯。有工具程式可以幫忙切換，而不用每次開機都要按6跟4，有興趣的人可以google 『SityFourSwitcher』。

整個系統運作的感覺只有一個字可以形容，那就是「順」；它不是讓你覺得好像飛快一樣，但是也絕對不會有卡卡的感覺，就是很平順快速的完成各種工作。它也沒有用啥獨立顯卡，跟7200RPM的HDD或是SDD，但是就是不會覺得卡住的感覺，換做是Windows Vista，可能就已經卡到罵髒話了....XD。只能說，整個硬體與軟體的搭配到了一個絕妙的地步，不是都是頂級的配備，但是最後呈現的就是高水準的表現～NB的外觀也蠻有質感的，果然不愧是NB中的跑車等級。我已經決定了下一台NB也是MacBook Pro了～

P.S：目前用的其實是公司買來要開發iphone應用的