聽從Clara的建議，讓自己放慢生活的腳步(其實我自己覺得我過的不快)，有很多問題可以討論，我想等到過幾天再說吧。
今天藉由閱讀來放慢自己的生活腳步，於是我選擇"重構-改善既有的程式設計(Refactoring - Improving The Design of Existing Code)"，在p.61 "間接層和重構(Indirection and Refactoring)" 文中提到
計算機科學是這樣一門科學：它相信所有問題都能藉由多一個間接層(indirection)來解決。 - Dennis DeBruler
看到時雖然驚訝，但是不失望，因為我在很早之前就對ycma提出了這樣子的想法，不過總覺得有很多需要思考的地方，但是這篇文補足不齊之，大都是物件導向軟體工程看法，ycma曾跟我提過，在硬體上多一層就會多很多麻煩，不過看這種書，就多多思考吧。
---
事實上，我不太知道如何休息，就讓閱讀取代休息吧。
先對祥龍說聲抱歉，我晚一點才會寫生日文，真的是太忙了...
真正想要下筆的時候卻不知道要寫什麼，有時候唯一能做的事，就是讓自己埋頭於螢幕前努力工作，直至累趴，習慣了，很多事其實都一樣的。
---
C'est la vie
由於不怎麼念的下書，最近做的事又乏善可陳，只好寫點這樣子的文章來欺騙社會大眾XD
這兩天把Peopleware看完一次，頗有心驚的感覺，原來以前做對了很多事，但是也做錯不少，寫成文章有一個好處，讓你能夠不會再犯錯，也由於蠻感動這本書所寫的，想要買一本英文版回家K，但是天瓏說缺貨中，無妨，再等等看吧。
最近由於寫程式的關係，常常需要看相關資料，這部分的心得，我引用Jserv's blog: 對自己好一些：談技術手冊閱讀來作結，他寫的很好，我實在是不需要重寫一篇。沒有人可以否認，從Google上得到的資料相當的片段(不過能找到整個上課投影片也是一個不錯的選擇)，如果自己手上沒有一本技術手冊，無法從該技術做一個全覽是一件相當可惜的事，除非只是即興寫作，抑或是應付了事，不然我覺得，擁有該領域的一本良好技術手冊，是相當必要的。
但是在學習時發現，現代人的心態，有時候習慣於補習班的教育，有人教最好，沒人教就跟老師橋，過度習慣別人給你資訊，如果能力不足，尚可原諒，如果志不在此，也可理解，但是天生就是要走一行飯的，實在是得把"看技術手冊"和"Googling"兩件事並列首位，而不是不會就問人，拖到會為止，這樣子顯得相當奇怪。我問人頂多問到keyword或者是該領域的技術手冊，剩下的自己來。通常這樣子的學習，幾個round下來，對於學習能力大有幫助，久而久之也習慣了這樣子做，方能讓自己成為獨立學習的人。有人問過我，為什麼人會產生如此的局面，我只能說，當人越來越懶的時候，是沒有理由的。
---
嚴肅快筆書寫
在接觸過那麼多programming language之後，到現在我還是感嘆於C/C++的美麗，精簡的語法建構一個又一個美麗主題，太漂亮了。
---
真想用C++開發出一個美麗的東西，會有機會的XD。
在大部分的linux下，是可以從"/var/run/utmp" 這個路徑得知現在使用這台伺服器的使用者資訊，資訊是開放任何人可讀，不過在Mac OS 10.5以後不支援這個檔案，而改採用NetBSD的utmpx，故資訊可從"/var/run/utmpx"這個檔案讀到。寫了一小段測試碼如下
#include <stdio.h>
#include <utmpx.h>
int main(){
struct utmpx utmpx_entry;
FILE* fp = fopen("/var/run/utmpx", "r");
while(fread(&utmpx_entry, sizeof(struct utmpx), 1, fp)>0){
printf("%s\t%s\t%s\n", utmpx_entry.ut_user, utmpx_entry.ut_id, utmpx_entry.ut_line);
}
return 0;
}
事實上我覺得使用起來沒什麼差別，不過細細比較utmp.h和utmpx.h之後，會發現struct utmpx記載了更多資訊，可能更符合現在的作業系統設計，畢竟現在的作業系統不是只有單純的command line了，而一個xwindow也是一個terminal，所以我覺得新增這些資訊還算蠻合理的。
---
事實上這篇重要性不大XD
今天中午醒來，思考，如果unix system call都是C 寫成的，是否有辦法用class包起來呢，於是寫了一個小小的class測試一下。
class FileAttribute{
public:
FileAttribute(const char* dir, const char* file){
name = string(file);
path = string(dir) + "/" + name;
stat(path.c_str(), &buf);
};
FileAttribute(string& dir, string& file){
name = file;
path = dir + "/" + file;
stat(path.c_str(), &buf);
};
const char* ab_file_path(){ return path.c_str(); };
const char* file_name(){ return name.c_str(); };
bool is_file(){ return !S_ISDIR(buf.st_mode); };
bool is_dir(){ return !is_file(); };
unsigned int size(){ return buf.st_size; };
private:
string path;
string name;
struct stat buf;
};
看起來成效不錯，其實效率很差，多一層包裝，就要浪費掉很多時間在此包裝上，不過如果在發展大型程式時，還是有其包裝的必要。
---
我真無聊，不過我喜歡XD
這段文字很早很早之前就想寫了，不過總是沒有一個好的著力點，不過我得先聲明，我數學和英文都不好XD。
我朋友問過我一個問題，為什麼總是有人要把一個很簡單的問題變的很複雜。此外也有等價的問題，有人跟我說過，要證明1+1=2是數學家無聊做的出來的事。
先回答第二個問題，因為比較簡單，在普遍狀況下，1+1=2是成立的，問題，我們如何證明+這個元素存在，又如何證明兩者等價，這在高等微積分好像有解答(我不會也沒修過，不要問我XD)。而且證明1+1=2的人是Bertrand Russell和另外一個人，花了320頁證明，他是用邏輯證明的，千萬不要小看這個證明，這個證明讓數學與哲學有了連結。他是一個哲學家。數學家和哲學家並不無聊，為了讓整個理性的社會存在，他們可是花了不少的功夫。
那麼為什麼總是要把一個簡單的問題變成很複雜。好問題，這對我學英文時也造成不少的困擾，雖然我英文從來沒有好過。我在用英文的時候想過一個問題。為什麼不能用簡單的字，而是要學很多很複雜的字。(這或許造成我某程度懶惰不背單字的原因XD)，在這些等價描述下，唯一要做的解釋就是...
嚴謹是一件非常重要的事。
人類之所以發明文字，發明思考方式，一切只是為了知識累積，讓後人可以站在先人的智慧上，做出更多的開展。人類的學習就像一個超高速齒輪一樣，剛開始會很慢很慢，到最後會越轉越快。於是，怎麼把知識做一個正確且快速的傳遞，變成一個很重要的事。於是乎，寫作要求嚴謹是一件很重要的事，那麼怎麼讓嚴謹做一個最好的呈現?
發明符號和語言變成相當重要，數學對於大部分的人可能落於算術這個部分，但是數學最迷人之處就是，如果你能夠用數學語言看到這個世界，很多事是垂手可得的，你用邏輯語言看懂了另外一個世界，就會發現，原來還有很多很多思考的方式。
不過最不幸的是，符號和語言是先人制定的，這兩件事往往成為門外漢(如我XD)學習最大的門檻，那麼為什麼要用最嚴謹的符號和語言來定義呢? 因為在知識的累積和展現上，不太能容許出錯或定義不明之處，這會讓承先啟後的人們顯的相當無助(發明人都做古時，去那問啊XD)，然而這在一般的狀況下卻不是很大的問題，因為肯在某個領域學習的人，往往可以很快的適應。如果學的會這些東西，可以為自己打開一扇窗，快速的學習與探索自己想要學習的東西，可謂是相當的快樂。
而我呢，大概只會程式語言吧，只是剛好有所機會看到一些東西，算是蠻幸運的XD
---
因為幸運所以偷懶嗎XD
前幾天Mac OS X被我搞的並不是那麼穩定，所以今日重灌，還蠻便利的，選擇清除重新安裝後，再用TimeMachine復原資料，但是留下一個乾淨的系統，有些command line底下的東西要重灌，不過正符合我意，因為我前陣子一直在測試，重灌過程相當愉快。
---
在這方面Apple做的真的是蠻不錯的。
這陣子作業著實不少，不過都是小作業居多就是了，昨天使用Visual Studio .net 2008 Team Suite 的測試程式是否正確否，簡單而言，就是存在一個function，給予一個input和 excepted output，而軟體會自行幫你比較程式輸出結果是否正確(不過只有C#有...Orz)，這對大型專案應該是一個蠻有用的工具。所以我寫了一個簡單的測試碼
public static int[] BubbleSort(int[] u){
/* ... */
return u;
}
public void BubbleSortTest()
{
int[] u = { 3, 5, 2, 4, 1 }; // TODO: 初始化為適當值，此行為自行輸入
int[] expected = {1, 2, 3, 4, 5}; // TODO: 初始化為適當值，此行為自行輸入
int[] actual;
actual = Program.CountingSort(u);
Assert.AreEqual(expected, actual);
//Assert.Inconclusive("驗證這個測試方法的正確性。");
}很可惜的，這個測試結果會告訴你，永遠是錯的，expected 永遠不會等於actual，我起初還蠻天真的認為說應該會等於，其實不會，因為AreEqual對於此型別的比較等於C++中的int* == int*，只要兩個存在指向不同記憶體之處，其值就不可能相等，而我移到AreEqual的程式碼定義處一看，哇，什麼都有，似乎沒有針對這個狀況所解決的方案。其實這算是一個小問題，而C#也支援Generic，稍微改寫一下即可支援，但是這樣子的問題出現在一個這樣子的軟體上，似乎不太對勁，當然，也可以跟我說我的使用方法不當，或許我真的不太會用這套軟體吧。
C#是MS發展算蠻成功的語言，雖然抄襲自Java，隨後又用了一堆C++的概念，導致我遇到錯誤時，兩個語言的思維都套上來試試看，大部分的問題都會有解，但是很難免的都遇到現存高階語言存在的一個問題，發展的過於龐大而難以維護(我得說C++算漂亮的，以發展library來降低整體複雜度)，現在的C#，沒有VS.net就很難開發，而這個語言沒有一個統一的思維，也是一個很有趣的問題。
算了，如果用以前MS的東西恐怕會更糟。
---
發個牢騷XD
我大概跟一般人相反，我只有看過小說沒有看過電影XD 或許回校時會借來看看。
文學和電影最大的不同是，由於電影要給大家看，不太能敘造太多悲劇或結局，而且文學的美感，轉換成影片時會有一定量的失真，所以因應這種媒體的轉換，改寫是必然的。
這本書是暢銷書，跟電影有很大的關係，不過我得說，除了這篇小說，後面所書寫的小說就略嫌老套，抑或是說，這本書出來甚久，在當今的時代，這樣子的寫作方法已經非常常見了。
等電影看完再一次寫心得吧
---
寫這篇是騙文章數的嗎XD