Protocol 是 Delegate 的介面，定義了 Delegate 必須實作什麼，用其他語言的概念來說明，Delegate 就像是 Callback。Delegate 不一定需要 Protocol，不過最好是要有，程式看起來會比較清楚。
Block 是 iOS 4 以後加入的 Syntax Sugar，它其實就是 anonymous function，我覺得這應該可以用來取代比較沒有復用性的 Delegate，有的時候採用 Block 的寫法能讓程式更清楚易懂，例如 UIView 的 beginAnimation vs. animateWithDuration 兩種寫法我就覺得 Block 方便太多了。
Block 的缺點是有時候不能下中斷點，例如 iPhone Simulator + GDB 的情況，Debug 起來比較不方便，不過我猜也有可能是我沒設定好之類的。
Notification Center 就是 Event/Listener，iOS 中共有四種 Notification Center，分別是 NSNotificationCenter、NSDistributedNotificationCenter、DarwinNotificationCenter 及 TelephonyNotificationCenter。這很適合用來處理全域事件、降低物件耦合性，例如在自定類別中呼叫 UIViewController 更新畫面。
Base SDK 是你的 App 可以支援的最新 SDK 版本，而 iOS Deployment Target 是你的 App 可以支援的最老 SDK 版本，所以 Base SDK 最好設定為 Latest SDK。
它不是 UUID，雖然在 Simulator 中它是，但是在 Device 中則是 UDID，也就是你在 Xcode Organizer 看到的 Identifier。
Coding Style 有兩份文件可以參考，Apple 的 Coding Guidelines for Cocoa 以及 Google 的 Objective-C Style Guide。
要自動整理程式碼，可使用 Uncrusitify。使用前必須先有一份設定檔，Tyler Neylon 提供了他的 Uncrustify 設定檔。Tony Arnold 提供了給 Xcode 4 使用的 Automator Service，可以更方便地在 Xcode 中執行 Uncrustify。
開發 iOS App，使用實機來測試是必須的。以下列出將 App 放到 iDevice 上的操作流程。
應該就這樣。
當發生 EXC_BAD_ACCESS 時（程式試圖存取不應該存取的記憶體），通常 Debugger 會直接死掉，什麼訊息也沒有。啟用 NSZombie 能夠提供更詳細的 Callstack，迅速找到問題。啟用方法為：
NSZombieEnabled，值為 YES。Xcode 的自動完成功能很方便，但是只能列出一個近似的選項，是這樣嗎？其實按 Esc 就可以列出所有可能的選項。
雖然 Objective-C 2.0 加入了 Garbage Collection 機制，但是 Mac 才有，iOS 沒有，iOS 只有 Reference Counting。
Reference Counting 的運作是基於 ownership。當程式要使用物件時，必須取得物件的 ownership，一個物件可以有很多 owner；而當程式不再使用物件時，則需要放棄 ownership。直到物件沒有任何 owner 時，物件就會自動被 dealloc。
取得物件的 ownership 的方法可分為兩種，其一是透過 alloc、new、copy 產生出物件。如果物件是從其他來源獲得，而不是由 alloc、new、copy 產生的話，則可以使用 retain 來取得物件的 ownership。要放棄物件的 ownership，則使用 release，雖然非 owner 也能呼叫這個 method，但這樣相當容易發生問題，請不要這樣作。
我們希望 owner 自己 release 自己的 ownership，但如果物件要作為函式回傳值的話，物件就必須要等到對方接收到物件並取得 ownership 之後才能 release，物件若在函式內就 release 掉，對方就可能收不到物件。為了解決這個問題，可以使用 autorelease1，讓函式只暫時地擁有物件的 ownership，在 event 結束以後的某個時點，物件會自動被 release。對方接收到物件後，必須用記得 retain 取得 ownership、或是用 copy 複製一份物件，以免未來物件 autorelease 後發現沒有 owner，就會被 dealloc。
另一個更好的解法則是不要使用 alloc、new、copy 產生物件，例如使用 NSString 的 stringWithFormat、NSArray 的 arrayWithObjects。以這種方式產生出的物件本身就已經是能夠 autorelease 的，好處是可以節省一些 code。
Nib 檔 是由 Interface Builder 產生的文件，內容包含了介面的描述。過去 Nib 檔的副檔名就是 .nib，分為一個 XML 檔及一個二進位檔案，而 Interface Builder 3 以後預設改為使用一個 .xib 檔案的格式，實際上最後仍然會編譯成 .nib 檔。雖然副檔名變更了，不過 Xcode 介面中許多地方仍然採用「Nib 檔」這個名稱，對於剛接觸的開發者可能會造成誤解。
Cocoa Framework 有個 NSAutoreleasePool 類別，使用方法很簡單，首先要 init 出一個 NSAutoreleasePool 物件，最後 release 這個物件，這時在 init 到 release 之間如果有可以 autorelease 的物件，他們就會自動被 release 掉，另外如果程式執行途中想要命令 NSAutoreleasePool 自動釋放目前不再使用的物件的話，則可以呼叫 drain。不過許多教學是說要 release 掉現有的 NSAutoreleasePool 然後馬上重新 init 一個，我不知道原因是什麼？
如果你使用 Xcode 提供的專案範本的話，它會在 main() 裡面使用這個類別，而由於 main() 是程式的進入點，所以這個 NSAutoreleasePool 會自動釋放掉程式中「幾乎」所有的物件佔用的資源——之所以說「幾乎」是因為如果物件是由 alloc、new、copy 產生出來或是有 retain 過這個物件，就不會自動被釋放 1，必須使用 release 或 autorelease 來釋放，慣例上 release 或 autorelease 必須由物件的 owner 來呼叫。
如果要手動釋放的話，則可以呼叫 release，但如果函式要回傳一個物件，這個物件就不可能由函式來 release，而需要在呼叫此函式的對方取得物件後才將它 release，以上是 C 的慣例。Objective-C 的慣例則是在函式回傳物件以前，先呼叫 autorelease 標示物件可以被 autorelease，然後再將物件傳遞出去，這樣對方就不需要管理記憶體。當下次 NSAutoreleasePool 執行 drain 或 release 時，已經不再使用的物件才會被銷燬。
這樣子好像幾乎都還是要自己釋放嘛… orz ↩
其實以下這些 Mac Programming 應該也適用，都是很基本的東西，只是作個筆記。
Static Analyzer 可以用來抓出潛在的記憶體洩漏風險、多餘的變數等問題。Xcode 有內建一個 Static Analyzer，是基於 Clang Static Analyzer 修改來的。直接就能使用！或者也可以照著 Clang Static Analyzer 網站上建議的，手動安裝他們提供的最新版。
執行的方法為 Build / Build And Analyze。
意思就是說在丟出 Exception 的時候中斷程式，光用想像的就覺得超實用的啊！
新增的方法是到 Run / Show / Breakpoints，在 “Double-Click for Symbol” 上點兩下，然後填入 objc_exception_throw12。
Warnings 表示沒有 Compile Error，但是卻有 Runtime Error 的風險，所以建議勾選這個選項。
這個選項的位置在 Project / Edit Project Settings，Build 頁籤當中。
LLVM 編譯器在 Xcode 3.2 當中已內建，穩定程度已經足夠，並且預期能夠產生比 GCC 更小的可執行檔、更快的執行速度，不過實際效果仍然要以測試為準。LLVM GCC 是 GCC-compatible 的 LLVM，若無必要可以直接選用 LLVM compiler。Xcode 3.2 內建的 LLVM compiler 同樣比較舊，需要的話也可以自行編譯最新版 LLVM compiler 來使用。
這個選項的位置在 Project / Edit Project Settings，Build 頁籤當中，名稱叫做 “C/C++ Compiler Version”。
Instruments 是包含於 Xcode 之中的一個 App，它可以用來記錄、分析程式的運作，有助於最佳化程式效能。3
根據 Node.JS 的文件，Node.JS 載入模組的方法有兩種，一種是從相對路徑中載入，另一種則是從 require.paths 尋找。
如果想要在專案中維護一份模組，以利於隨時隨地 clone 下來就能開發，不用分別在不同機器上安裝模組，依照 Python 的慣例我們會直接修改 sys.path，但在 Node.JS 中並不建議修改 require.path，未來版本的 Node.JS 可能會拿掉 require.path，取而代之，可以採用這樣的方式：
其實 require('http') 這樣的 require 會首先嘗試搜尋目前路徑下的 node_modules 資料夾，例如以下的資料夾結構：
|
1 2 3 4 5 6 |
app.js node_modules/ connect/ index.js express/ index.js |
如果要在 app.js 中使用 express 模組，直接寫 require('express')，就會載入 node_modules/express/index.js。express 模組中使用了 require('connect')，由於 express 是 node_modules 下一層資料夾，所以它會自動搜尋它自己旁邊的資料夾。
其實我還試過這樣的架構……
|
1 2 3 4 5 6 7 8 |
app.js node_modules/ vendor/ node_modules/ connect/ index.js express/ index.js |
這樣我就可以在 app.js 中寫 require('vendor/express')，而 express 中仍然可以繼續寫 require('connect')，但後來我覺得這樣的結構有點惡搞 XD
目前 Node.JS 執行的方式不像常見的 Script 語言，如 PHP、Python、Ruby、Perl 那樣，修改程式後，只要重新整理瀏覽器就能看到結果，而是必須關閉 Node、重新執行。
開發中必須不斷重複重新啟動的動作實在是很苦，本來我是想用 watchr 來輔助，後來發現其實已經有人寫好了模組：node-supervisor。
|
1 |
npm install supervisor |
以下只記錄 Mac 的情況。
實際安裝的位置會因為執行指令當時的位置而有所不同，例如我在 /Users/bcse 安裝，最後會安裝到 /Users/bcse/node_module/supervisor。
接下來為了可以直接執行 supervisor，不用執行 node path_to_supervisor，還要執行
|
1 |
sudo npm link |
這句指令要在安裝目錄中執行才行，例如 /Users/bcse/node_module/supervisor。
|
1 |
supervisor myapp.js |
基本上都照預設值就好，不用多設定什麼參數。
解析 XML/HTML 的 Library 有很多，但大部份都只支援 Well-formed XML，遇到 Mal-formed XML 就無法解析，Standard Library 裡面的都屬於此類。可以接受 Mal-formed XML 的 Library 則有以下這些：
所以解決方案有這些：
目前我是用 Beautiful Soup。最後我決定在本地端 parse 完再丟上去… XD
Google App Engine SDK 1.5.5 以後的版本新增了 Python 2.7 的支援，如果指定使用 Python 2.7 的話，就能使用系統提供的 lxml。 ↩
html5lib 的原理是由它來處理原始資料、製成 DOM、ElementTree 的格式，然後再用 DOM、ElementTree 來查詢，所以解析時間並不會比 Beautiful Soup 快。 ↩
ElementTree 1.3 版以前還不支援對屬性查詢，而 Python 是在 2.7 版才將內建的 ElementTree 更新為 1.3，不過我們可以從 Python SVN 取得最新版的 ElementTree，放到 Google App Engine 上使用，缺點是速度沒有 cElementTree 快。 ↩
在 Android 手機安裝自製 APK 有兩種方法。
第一種方法太簡單了，這裡只介紹第二種方法。
C:\Program Files (x86)\Android\android-sdk\extras\google\usb_driver。C:\Program Files (x86)\Android\android-sdk\platform-tools\adb install path\file.apk。