Pair Programming心得

在上個禮拜之前，寫程式對我來說，大部分都是一個人單打獨鬥的事情。

學校作業、碩士論文，一人一份，時間到了記得交出來。
工作時期，接案Case，一人一份，老闆覺得兩個人接同一個案子太浪費成本了！

以上的種種，讓寫程式都大部分為一個人做的事情，頂多就是問問資深人員一些架構問題等等…

最近到了新環境，採用了Pair Programming，真是令我既期待又怕受傷害阿阿阿阿～

什麼是Pair Programming?

Pair Programming來自Extreme Programming，它是Extreme Programming裡的其中一項作業。 (Extreme Programming是一種軟體開發模式，我也才剛接觸所以不太熟)

簡單來說，就是兩個人坐在一起，配備
- 兩個螢幕
- 兩個鍵盤
- 兩個滑鼠
- 一台主機

沒錯！一台主機，就是兩個人coding同一份程式碼！

雖然以前有聽說過這種開發方式，但也只是聽說…

第一次參與Pair時，就是一直看一直看，一直看Senior以飛快的速度寫程式….
然後換我寫時，慢的跟新手一樣，還常常打錯字，鍵盤都握不好啦…0rz

沒想到在coding時，旁邊有人監督竟然這麼有壓力，怕變數名稱取的不好，怕打字速度太慢，怕誤會剛剛的演算法。讓我一開始pair時coding速度變很慢…。

Pair的好處

1. 品質

程式的品質真的好很多。

從最基本的變數名稱，邏輯判斷，演算法等等。一人寫程式，一人監督的概念，讓程式不會亂寫。

該抽出來的function就抽，該定義constant就定義，該寫的註解不會漏掉，不會有多餘的if else，可讀性提高許多，而且Bug真的變少了！ (很明顯感受到程式Compile執行後就正確無誤，真是太神奇啦！)

2. 專心

Pair互相監督討論，根本無法打混(除非兩個人一起打混…XD)。
這陣子下來發現，Pair時會超級認真的，討論很起勁還會忘記吃飯！
(因此Pair完也會有用腦過度的感覺…)

3. 維護

Pair雙方都對程式架構有相當程度的了解，因此不用擔心交接問題。
這對小公司來說應該算是最實用的地方了，不會產生爛攤子而沒人收拾。

對我而言，從pair上可以更快了解此專案內容。透過不斷的思考、討論、問與答，比起一個人慢慢的看code，效率要好上十幾倍呀！ 而經由senior的在旁指導，讓我學習到更多軟體開發的技巧，也少走很多的冤枉路，真是太值得了。

Pair的困擾

Pair時也有幾個會困擾開發者的事情：

1. IDE的選擇

有人習慣用XCode，有人習慣用Eclips、Notepad++等，這些IDE的熱鍵有時都不同，當兩個人湊在一起時，就必須向某一方妥協，總不可能一直切換IDE寫吧。 為了有共識，我們公司統一Pair開發用IDE，也統一了熱鍵，方便開發。

2. 查資料時效率不好

寫到一半卡住，要google時，會發現兩人用一台電腦真是不好查資料…因為每個人的閱讀習慣不同， 因此常常會一個人在查，另一個人就在發呆…。為了克服這個問題，我們還是會另外放一台筆電在旁邊，做為查資料時使用。

3. 作息要一致

若Pair的作息不同，Pair的時間就會變少了，我想這也是Pair的宿命吧。

4. 學習時間變少

我們公司是full time pair，這有一個意想不到的缺點，就是沒有自己的時間呀。
上班就是pair到下班，想要學新技術，就必須自己找時間學習。 不知不覺壓力就變大了哈哈哈
(不過這或許是好事吧XD)

總結

我覺得pair programming真的還蠻適合用在規模不大專案的開發上。 不僅程式品質變好，開發速度其實也是變快的(Debug時間大大變少…XD)。

可惜pair programming在台灣老闆耳中聽起來就很像是一種增加成本的開發方式…0rz。

如果有時間的話，就來試試Pair Programming吧。

reference : http://ch8908.github.io/blog/2012/11/18/pair-programmingxin-de/

DNS設定專用名詞

反解
Domain Name TYPE Record IP Address
blogger.com PTR mail MailIP

網域
Domain Name TYPE Record IP Address
blogger.com A www ServerIP

Google Mail
XXX.com.tw MX ASPMX.L.GOOGLE.COM. 優先權:1
XXX.com.tw MX ALT1.ASPMX.L.GOOGLE.COM. 優先權:2
XXX.com.tw MX ALT2.ASPMX.L.GOOGLE.COM. 優先權:2
XXX.com.tw MX ASPMX2.GOOGLEMAIL.COM. 優先權:3
XXX.com.tw MX ASPMX3.GOOGLEMAIL.COM. 優先權:3
XXX.com.tw MX ASPMX4.GOOGLEMAIL.COM. 優先權:3
XXX.com.tw MX ASPMX5.GOOGLEMAIL.COM. 優先權:3

YYY.com.tw MX ASPMX.L.GOOGLE.COM. 優先權:1
YYY.com.tw MX ALT1.ASPMX.L.GOOGLE.COM. 優先權:2
YYY.com.tw MX ALT2.ASPMX.L.GOOGLE.COM. 優先權:2
YYY.com.tw MX ASPMX2.GOOGLEMAIL.COM. 優先權:3
YYY.com.tw MX ASPMX3.GOOGLEMAIL.COM. 優先權:3
YYY.com.tw MX ASPMX4.GOOGLEMAIL.COM. 優先權:3
YYY.com.tw MX ASPMX5.GOOGLEMAIL.COM. 優先權:3

什麼是UTF 8

以前電腦剛開始發展時，每一個國家都各自發展自己的文字系統，所以就會有中文系統日文系等，可是大家在發展的過程中並沒有相互參考文字在電腦裡的編碼方式，所以同一個碼在不同的地區文字系統裡並不代表同一個字，例如台灣使用big5碼大陸使用gb碼，所以台灣的big5編碼文件拿到大陸用gb編碼系統打開，就是一片亂碼，這個問題在有網際網路以後情況就變得更嚴重，所這時就有一個單位www.unicode.org，就提出一個構想，就是何不把全世界的文字作一個統一的編碼，讓全世界的電腦都可以用，如果這樣的話，就不會再發生中文的文件拿去日本的電腦打開是亂碼的情況，這就是unicode了，現在unicode編到第8代，就utf-8





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

為了讓軟體產品支援多種語系，就必須讓軟體認得各種語言的不同編碼表，但卻為軟體開發帶來更多的複雜性與不便。Unicode 是一套能夠解決這個問題的世界性編碼標準，它為每一個字元提供與作業平台、程式、語言相獨立的單一編碼。簡言之，Unicode 詳列了世界上所有使用到的字元，並且為它們各自編派一個獨立單一的號碼。Unicode 出現之前，有多達好幾百種不同的編碼系統，試圖分派這些編號，但沒有單獨一種編碼包含足夠的字元。舉例而言，歐盟就得需要數種不同編碼，以便廣納其所有語言。對於單一語言，如英文，也沒有單一種編碼可以充份表達其所有文字、標點，以及共通的專門符號。更糟的是，這些編碼系統彼此衝突，兩套編碼系統會在兩個完全不同的字元上，使用相同的編號，或反之亦然。對於有必要支援多種不同編碼的電腦系統，不同編碼或平台上的資料交換，都將面臨資料失真的風險。
Unicode 已受到產業的廣泛接受，如 Apple、HP、IBM、JustSystem、Microsoft、Oracle、SAP、Sun、Sybase、Unisys 等多家領導廠商都表明支援。Unicode 更受到 XML、Java、ECMAScript （JavaScript ）、LDAP、CORBA 3.0、WML 等標準的採納。支援 Unicode 的作業系統與瀏覽器等產品也為數不少。Unicode 標準的興起，加上支援工具的推波助瀾，成為全球化軟體技術趨勢中相當顯著的光芒之一。

Unicode 的最初目標是希望採用 16 位元編碼指定超過 65,000 個字元，然而要讓現存所有軟體適應 16 位元資料，必須花費可觀的重新開發成本。Unicode 於是發展出三種不同的編碼形式 UTF-8、UTF-16 和 UTF-32，這三種格式針對同樣的共同字元加以編碼，允許相同的資料以位元組、字組或雙字組形式傳送，並且可在無資料損失下轉換成其它格式。

UTF-8 最常見於 HTML 與相關協定中。此一格式有趣的地方是原先存在於 ASCII 的字元和 UTF-8 中的同一字元，擁有同樣的的字元值。例如，A 在 ASCII 和 UTF-8 中都是 0x41。大多數現有軟體不需重新撰寫，便可使用轉換成 UTF-8 的 Unicode 字元。UTF -16 使用在需要同時考量字元存取效率和儲存空間的環境。對於一些無須考慮記憶體空間，但要求字元存取必須是固定長度且佔用單一編碼單位（single code unit）的環境，UTF-32 則是最佳的選擇。

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

1. UTF-8 只是編碼演算法，他用來對 UNICODE 編碼規則的字及進行編碼。
2. UNICODE 的 code point 有 256*256*256*256 個字，涵蓋全世界幾乎所有國家的語言文字，中文的部分是其中 CJK 的子區段。
3. BIG-5 是台灣地區自己的標準，他是一個簡單編碼演算法，也是一個編碼規則。
4. BIG-5 使用兩個 byte 的固定長度編碼， UTF-8 使用 1 到 4 個 byte 的浮動長度編碼 ( 例如字母 C ，在 UTF-8 只會用一個 byte ，中文字大部分會有3 個 byte ， 也會有2或者4個byte的機會。 Big5 對英文字母沒有編進去 )
5. 使用 UTF-8 編碼，軟體處理文字會很方便，因為不用同時判斷到底字串哪一部分是ISO8859-1 的編碼，哪些是 Big5 ，這樣會讓軟體處理字串變的非常慢，而UTF-8 的設計，把同一個 code point 的編碼 byte stream 透過前幾個 bit的規則換算，可以讓軟體馬上知道到底這個 byte 是屬於一個 code point 編碼的第幾個 byte ，而可以很快的處理字串的單字切割，同時也讓字串的處理變的更快更有效率。 換句話說，使用 UTF-8 (應該說 UNICODE)軟體就不用在處理字串的時候去不斷的判斷，這個字是不是 Big5 或者其他編碼，這個字與其他字該怎麼切割，因為所有字都在 UNICODE 。
6. 因為顧及資料儲存體的使用要節省，同時也因為可以跟現有的電腦系統已 Byte 作為字串處理的基本單位做法相容，所以 UTF-8 目前最好的使用方法。 但是根據 ISO10646 的制定概念，如果儲存體不是考量重點的話，而且作業系統可以支援，使用UTF-16 甚至 UTF-32 是效率更好的選擇。

政府不出面整合，那是因為我們沒有能力引導， UNICODE 是國際標準，他要作到的是全世界的共同整合，而我們的 Big5 只為我們自己設計。 字碼不會混亂下去的，因為UNICODE 已經是趨勢， Windows XP 已經採用 UNICODE 作為系統的處理模式，你看到的 Big5 只是顯示的時候幫你轉的， XP 的核心根本就是使用 UNICODE 了。 現在的混亂只是因為舊的系統幾乎採用 Big5 ，為了向前相容，所以得混在一起用。 將來一定會慢慢走向 Unicode 的。

摘自:http://isochen.pixnet.net/blog/post/25668746

FTP傳輸模式

Ftp傳輸有兩種mode 一種是Active mode 二是Passive mode
要了解這兩個模式的不同﹐先得了解 FTP 的連線是怎樣建立的﹕

1)
在Active 模式下﹕
1﹐FTP client 開啟一個隨機選擇的高於 1024 的 port 呼叫 FTP server 的 port 21
建立連線﹐這是命令通道的建立。
2﹐client 用一個 port 命令告訴 server 另一個高於 1024 的 port 做數據通道。
3﹐然後 server 用 port 20 和剛才 client 所告知的 port 建立數據連線。請注意﹐
這是從 server 到 client 的連線﹐TCP 封包會有一個 SYN 標籤。
4﹐client 會確認數據通道連接﹐這個封包會有一個 ACK 標籤。
5﹐開始數據傳送。

2)
在 passive 模式下﹕
1﹐FTP client 開啟一個隨機選擇的高於 1024 的 port 呼叫 FTP server 的 port 21
建立連線﹐這是命令通道的建立。
2﹐client 送一個 PASV 命令給 server﹐要求建立 passive 模式。
3﹐server 然後像上面所述的正常模式第 2 步驟那樣﹐挑一個高於 1024 的 port 告
訴 client 做數據通道。
4﹐然後 client 用另一個高於 1024 的 port 呼叫剛才 server 告知的 port 來建立
數據通道。此時封包帶 SYN 標籤。
5﹐server 確認後回應一個 ACK 封包。
6﹐開始數據傳送。

通常從 FTP 下載檔案的時候，會使用兩個連接。一個是命令用，另一個是檔案，命令是由本地端設定，資料是由伺服器設定。在一些防火牆或代理伺服器會使兩個連接都在本地端設定。而當本地端送出 PASV command 時，伺服器便必須使用 passive mode 來接收。

如果您發現您的FTP程式可以連上FTP server，卻無法檢視server內的檔案與目錄，請您先確認一下您的FTP程式相關設定是否正確。特別提醒您，您必須勾選FTP程式的passive功能，這樣才可以正常連線。（如果您的FTP本身沒有支援此功能，建議您更新版本即可）。

[名詞解釋]sandbox / 沙盒 / 沙箱

sandbox / 沙盒 / 沙箱在英語當中的含義原是指家庭當中給小孩子用於啟蒙教育的箱子，裏面有沙子和水，可以任由孩子發揮想像力塑造自己想要的世界。後來延伸成為系統設計當中用於進行試驗的組成部分。它的意思是你可以在裏面充分試驗，而不會對箱子外面的世界造成破壞和干擾。