PHP Integer 的最大值

剛剛查了官方文件，實際測試過，PHP 在 32 位元的版本，最大值為「2147483647」，而到了 64 位元的版本，則變成「9223372036854775807」，差距還滿大的。

也許乍看之下沒有什麼特別的，但是只要是使用時間戳記(timestamp)的人都知道，整數是最常用來記錄這個資料的方法，但是「2147483647」這個數字代表的是 2038 年 1 月19 日，使用它難保不會遇到下一個類似百年蟲的東西。

現在好啦！官方文件提到只要使用 64 位元版本的 PHP ，整數就如同 MySQL 的 BIGINT 型態一樣的「9223372036854775807」。不單單是時間戳記，許多使用流水號的使用也可以用它，不需要使用浮點數或是字串處理，節省系統處理需要花費的效能。

升級 PHP 從 32 位元到 64 位元，總比要一行一行改寫程式好得多。看來只要把資料庫的欄位由 INT 改成 BIGINT ，其它的不敢說，至少在我有生之年，時間戳記都能夠順利正常的運作。

Android 的程式基礎(一)

看了部分官網的說明，在這裡寫寫筆記，複習、也加深自己的印象。 使用者清單


Android 是一個以 Linux Kernel 2.6 為基底的作業系統，由 Kernel 、函數庫、 Runtime、 框架以及應用程式所組成。一般軟體程式的寫作人員所開發的，就是應用程式層。了解其底下各層所負責的項目和協作方式，對於程式的了解有很大的幫助(個人一直這麼認為)。

由於是以 Linux Kernel 所發展，所以許多函數庫是以 C 或 C++ 寫成。不過中間經過框架和Runtime，實際上撰寫應用程式時，是以 Java 程式進行。由其它地方看到的訊息，那是一個由 Java 分支於 Apache 的專案衍生出來的，不過由於授權模式並不是很清楚，就演變成之前買下 Sun 的甲骨文公司告 Google 侵權的狀況。

除了部分 Java 核心的類別之外， Android 也加入了許多自己的函數庫，總體而言帶有很重的 Java 風格。但一些差異點，仍然會讓考過 SCJP 的我，搞不清楚狀況。又從頭開始看起 Google 的官方文章。

和 Java 程式中會有 main 啟始函數不同，在 Android 的應用程式都不算是「獨立」的程式，而是作為被另一支程式所呼叫，所以 Android 應用程式，實際都是繼承於 Activity 類別而來，我個人覺得把它翻譯為「活動」類別比較貼切，而不是其它中文書中叫它「機動程式」，一整個很彆扭，讓我一開始一直陷入「它到底哪裡『激動』了」的問題。

Java 程式語言是一個多執行緒的語言，在 Android 也承習了這個概念，當一支程式將被啟動， Android 就建立一個新的執行緒，並且啟動對應的程式。這個時候繼承於 Activity 的效果就出現了，啟動器只知道啟動了一個 Activity 類別，並不在意實際被執行的是哪一個子類別，只要利用父類別(Activity)提供的方法，就可以控制程式的啟動、暫停、終止…等。一個程式設計原則「對父類別撰寫程式」被應用的實例。

在 Android 平台中所不同的地方，在於程式並不單只是不同執行緒，而且在運作的過程中，也配給不同的 User ID，這是利用 Linux 作業系統多用戶的特性。利用 Linux 檔案權限的控管，加上不同應用程式帶有不同 User ID，就可以保護不同的程式彼此之間不會互相干擾，修改到其它程式的檔案，也能夠保護重要的系統資源不被破壞。

在某個特殊的狀況下(還沒看到是什麼狀況)，兩支帶有相同驗證資料的應用程式，可以帶有相同的 User ID，待在同一個執行緒中，享受到資源共享的方便。不然就得依照 Android 的規則，開出能夠被其它程式存取的介面，來分享或傳遞資訊。

另外，像是藍牙、Wifi、GPS、SD記憶卡以及通訊錄、電話…等，也是可以被應用程式存取。不過必需要在安裝的時候，提供使用者，取得同意後才能夠進行存取。

cURL 模組

較傳統的網站間驗證帳號方式，是利用表單將帳號密碼傳到對方的網站，當驗證成功則回到原來網站。如果失敗，則停在對方的網頁，或是導向錯誤訊息頁面。利用瀏覽器轉向(redirect)的方式，甚至可以讓使用者沒有發覺自己曾經連到其它網站。

最近製作的專案，就是為了串接這種模式的帳號驗證，不過這次使用的平台是 AIR 應用程式，無法使用瀏覽器的轉向功能。所以只用其它方式，在 server 端把原來表單資料傳遞的行為重現出來。

和同事討論過可能的作法，他建議使用 PHP 的 cURL 模組。它是用來可以作為要發出 HTTP 要求的工具，和其它人可能會想到的 fopen 方法不同之處，它可以帶著 POST 以及 COOKIE 設定資料，這是 fopen 所作不到的(它頂多只能傳遞 GET 數值)。另外，它也能接收由對方傳回來的 http header，也就是可以收到對方傳來的 COOKIE 設定。

講了那麼多 COOKIE ，是因為我這次需要模擬的，就是利用在瀏覽器中記錄 COOKIE 的方式達到驗證的行為，有 COOKIE 資料，才能合法的取得使用者相關資料。

在介紹程式碼之前，要先說明的是 cURL 並不是大部分 PHP 預設啟用的模組，所以使用前要先檢查已經安裝及啟用。可以由 phpinfo() 輸出的結果得知。

網路上有不少資料可以參考，這裡只拿我所使用的程式片斷為例子說明︰

// 和 fopen 類似，首先要先建立連線，以傳回來的資料作為後續操作之用
$ch = curl_init();

// 使用 curl_setopt 來設定連線參數
curl_setopt($ch, CURLOPT_URL, '連線目標網址');  // 設定連線目標
curl_setopt($ch, CURLOPT_POST, TRUE);              // 使用 POST 傳遞資料
curl_setopt($ch, CURLOPT_POSTFIELDS, 'username=name&passwd=pass'); // POST 資料
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE); // 當設定為 true 表示要接到網頁內容
curl_setopt($ch, CURLOPT_COOKIEJAR, 'cookie 存放檔案位置'); // 設定儲存 cookie 資訊

// 發出要求
$result = curl_exec($ch);
// 由於在 CURLOPT_RETURNTRANSFER 設定為 TRUE ，所以我會收到網頁內容，否則只會依要求成功與否傳回  TRUE/FALSE 資料

// 用完的東西關閉是好習慣 ^ ^
curl_close($ch);

關於 cookie 的部分，花了滿多時間在找資料，沒有看到任何不經過檔案直接取得變數的管道，所以最後還是只能乖乖的把檔案打開，裡面的格式是用 Netscape 格式來儲存，前面幾行註解，在一個空行之後，以 "\t" 的方式，一個變數一行來宣告。相信對字串處理熟悉的人，把 cookie 值抓出來不是困難的事。

至於怎麼送出  cookie 資料呢？可以在設定參數的時候加上︰
curl_setopt($ch, CURLOPT_COOKIE, 'key=value');
來作設定，不過我還不了解的是，這樣要怎麼設定 cookie 所屬的網域(domain)勒？
不過實際測試，收到要求的網站好像依然讀得到，很順利的讀出來。

另外一種方式，則是可以用之前提到的 cookie 檔案來傳，只要使用︰
curl_setopt($ch, CURLOPT_COOKIEFILE, '檔案路徑');
感覺起來，這算是比較保險的作法。

至於 curl 裡面還有另個 multi 系列的函數，似乎是一次可以對不同對象網址發出要求，不過因為已經超過我這個專案的需求了，時間因素就沒有再研究下去了。

Cassandra 筆記-環境需求

Cassandra 是一個以 Java 撰寫的服務，所以理論上只要有 Java Runtime 的環境就可以運作。在 Linux 上進行測試的結果，發現以往某些 Java 程式不支援的 OpenJDK 也支援。

安裝的方式，只有下載和解壓縮。在 Linux 的環境下，只要執行 cassandra 檔案就能啟動服務，而官網是建議一開始使用「cassandra -f」的方式在前景執行，可以看到服務所輸出的訊息，也可以直接使用「Ctrl + C」的方式結束服務。

據公司 MIS 的同事評價，Java Runtime 的記憶體管理不好，常會吃掉很多記憶體並且放不掉，導致程式執行一段時間可能需要重開程式或是重開機才能找回這些記憶體。同樣的他也懷疑 Cassandra 也是如此。估且不論是不是因為 MIS 同事不夠熟悉 Java Runtime 不清楚記憶體使用的設定，至少可以知道的一點是，在沒有特別調整的情形下，Java 服務是很吃記憶體的。

經過測試推測， Cassandra 一啟動要佔用約 256 MB 的記憶體，這是花了半天的時候，不斷嘗試才發現到為什麼架設的測試機(128MB)服務老是死掉。因為目前還搞不定把資料塞進去的技術，所以沒有測試當有許多的資料時，所需要用到的記憶體。

總之沒有 256 MB 以上，就暫時先打消架設的念頭吧！

至於設定的部分，0.7.x 版似乎只有官方有放文件出來，得花時間 K 英文，等到試出心得再寫筆記上來。

Cassandra 吉與凶?

Cassandra 在字典裡查到的意思是「卡珊多拉(人名)」，特洛伊女預言家，也被解釋為凶事預言家。我的英文不好，查到的中文資料並不多，只能大概的知道這個人是何方神聖。

特洛伊，就是那個木馬屠城的那座城。其中一種說法，在神話裡面， Cassandra 是個美人，被太陽神阿波羅所喜歡，阿波羅送給 Cassandra 「預言能力」作為禮物，後來不知道是什麼原因兩個人吹了，不爽的阿波羅沒有收回 Cassandra 的能力，但是讓所有人都不相信 Cassandra 的預言，所以 Cassandra 只能目睹特洛伊被大火焚城，因為沒有人相信她所看到(一說是聽到)的預言。因此 Cassandra 又被引申為悲劇或凶事預言家。

在資訊界這則是一個很紅的資料庫平台，由 facebook 開發，後來釋出給 Apache 團體的一個免費 NoSQL 平台，用來處理傳統關聯式資料庫不容易應付的龐大資料。它的圖示是一隻發亮的眼睛，不曉得和 Cassandra 在神話裡的預言能力是否一樣，表示著未來資料庫的主流應用。

網路上大多能找到的資料是 0.6.x 版的資料，不過最新的版本已經到 0.7.3 了，聽說原來 twitter 想使用 Cassandra 取代原來部分系統，後來又不知什麼原因放棄了，算算時間可能就是在 0.6.x 版本左右，所以讓人心生懷疑不敢再用 0.6.x 的版本。

不過紅歸紅，但是資料依然很缺乏，官方文件關於安裝也只有短短幾句話，讓我的測試研究陷入很大的困境。不知道 Cassandra 這次預言是未來它的成功，還是我不斷陷入研究的困境。