安裝jdk
add-apt-repository "deb http://archive.ubuntu.com/ubuntu hardy main multiverse"
add-apt-repository "deb http://archive.ubuntu.com/ubuntu hardy-updates main multiverse"
add-apt-repository "deb http://archive.canonical.com/ lucid partner"
apt-get update
apt-get install sun-java6-jdk
設定環境變數
export JAVA_HOME=
export CLASSPATH=
export PATH=
安裝ssh server
apt-get install ssh
設定key
ssh-key-gen -t dsa -P '' -f ~/.ssh
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
下載hadoop並且解開
我用的是1.2
找到WordCount範例，網路上很多，已經是hadoop基本的hello world了
編譯方式javac WordCount.java -classpath ~/hadoop-1.2.0/hadoop-core-1.2.0.jar
打包jar -cvf wordcount.jar -C wordcount/ ./
準備input檔案
echo "hello world bye world" >file01
echo "hello hadoop bye hadoop" >file02
~/hadoop/bin/hadoop dfs -mkdir input
~/hadoop/bin/hadoop dfs -put ~/file0* input
執行
~/hadoop/binhadoop wordcount.jar WordCount input output
=============
hadoop基本有兩部分dfs以及map-reducer
因為要分散式計算以及顧及到容錯，所以採取dfs
跟著map將輸入分散，然後再由reduce整合，map分散的時候輸入一組key1,value1，map運算完畢則是輸出另一組key2,value2，reduce則是根據key 2, value 2做資料整合，接著輸出key3, value3
從word count來說，key1可能是jab id或者hadoop產生的key，value則為一串文字，跟著將字串分解成單字，寫出的(key2, value2)可能是(hello,1)，接著reducer收到後會把這些數值加總起來，跟著輸出(key3, value3)可能為(hello, 2)
2013年5月27日 星期一
2013年4月17日 星期三
system call open()
今天review linux character driver的時候，發現往往定義的file_operations的.open成員，參數擁有file以及inode參數，可是這個參數哪邊來的?
其實會對open()有好奇，主要也是之前一直在trace linux kernel source內一些socket的東西，socket本身由sockfs支援，不使用open()而用socket()來開啟inode，所以想說兩者的區別是?
kernel內用 inode 結構體用來表示data。因此，它和 file structure 用來表示一個打開了的fd並不相同。對於一個inde，可能會有多個 file structure 對應著多個已打開的多個fd，但是這都只能指向同一個 inode 結構。
回頭看open()，大多數的system call使用interrupt 0x80，所以很快地追蹤到sys_open()是理所當然的入口
簡化整個call stack為sys_open()=>filp_open()=>dentry_open()=>dentry_open()
在呼叫register_chrdev()的時候將有覆寫的file_operations賦予device
底下是一些重要的工作，完整的source code就不列了
sys_open() : 配置fd
filp_open() : 依賴路徑取得nameidata結構，跟著呼叫dentry_open()取回file instance
dentry_open() : 配置file instance，nameidata結構內包含了inode instance，此時將一些必要資料由inode拷貝到file instance，f->f_op = fops_get(inode->i_fop);，此時f->f_op->open(inode,f)就是當時register_chrdev()所註冊的file_operations。
參考資料:
http://hi.baidu.com/potyzhang/item/ae9993a919e86f17a8cfb793
http://hi.baidu.com/heiyebujianwo/item/fa7fe543d99b73ab61d7b9cb
其實會對open()有好奇，主要也是之前一直在trace linux kernel source內一些socket的東西，socket本身由sockfs支援，不使用open()而用socket()來開啟inode，所以想說兩者的區別是?
kernel內用 inode 結構體用來表示data。因此，它和 file structure 用來表示一個打開了的fd並不相同。對於一個inde，可能會有多個 file structure 對應著多個已打開的多個fd，但是這都只能指向同一個 inode 結構。
回頭看open()，大多數的system call使用interrupt 0x80，所以很快地追蹤到sys_open()是理所當然的入口
簡化整個call stack為sys_open()=>filp_open()=>dentry_open()=>dentry_open()
在呼叫register_chrdev()的時候將有覆寫的file_operations賦予device
底下是一些重要的工作，完整的source code就不列了
sys_open() : 配置fd
filp_open() : 依賴路徑取得nameidata結構，跟著呼叫dentry_open()取回file instance
dentry_open() : 配置file instance，nameidata結構內包含了inode instance，此時將一些必要資料由inode拷貝到file instance，f->f_op = fops_get(inode->i_fop);，此時f->f_op->open(inode,f)就是當時register_chrdev()所註冊的file_operations。
參考資料:
http://hi.baidu.com/potyzhang/item/ae9993a919e86f17a8cfb793
http://hi.baidu.com/heiyebujianwo/item/fa7fe543d99b73ab61d7b9cb
2013年3月30日 星期六
UP與Agile process的比較
以個人經驗提出兩者的差異
- agile使用user story捕捉需求，UP使用use case(文件，不是diagram)
- agile工程師往往一人身兼多職，從design architecture、designer、programmer
- UP並沒有強調是否一人身兼多職，但是往往將腳色獨立出來
- agile很強調Test，不是只有Unit Test還包含ATDD、BTDD
- agile認為文件必須要很精簡，UP則是比較鉅細靡遺
- agile很重視客戶合作，強調客戶需要配合軟體開發
- agile將"關係"維護在人之間，UP則是將關係落實到文件內
- Iterative方式
- 重視User Feedback
- 重視需求文件
- Risk driven
- 重視Architecture
- 重視business goal
agile實施起來未必比UP容易，agile裡的programmer往往一人身兼多種腳色，因此agile的programmer往往能力需要比較強，這也是為何早期XP強調pair programming的方式，一方面可以有feedback，另外一方面可以帶起新手
如果今天團隊內有人離職，UP因為將所有內容都記錄在文件上，理論上只要詳讀文件就可以理解，但是agile則是將一些隱含的關係放在人之間，一個programmer離職，恐怕新手只有user story以及code/test code可以讀取，有沒有design...等等的文件，則是看當時狀況
agile將某些資訊放到人之間，有個好處，由於資訊是共享的所以可以減少誤解，同時人在資訊上的更新，某種程度是比文件來的有彈性以及快速
agile最核心的難度恐怕在於改變人，因為過去客戶往往不瞭解他們的需求，同時也不了解軟體開發的一些資訊，客戶認為軟體專案如同販賣機一樣，只要錢投下去，軟體就會跑出來，agile正嘗試改變這一點
最後補上一個軟體工程的V-mode，由於agile很重視test，同時如果理解的話，應該就知道CMMI的 V&V在要求啥了。也就是只要了解軟體工程，自然可以滿足CMMI的Level 2, 3(除了4個跟organization相關的GG之外)
Specification by Example 書摘 (1)
這是一本不錯的書籍，雖然作者整理了一套需求捕捉的方法，但是如果沒有agile process的背景，可能會有點難以理解
Chapter 1.
一個好的需求文件，應該具備底下的優點
作者推崇一種稱為Living Documentation System的工具，也就是維護需求捕捉文件的系統概念，不管是word files或者web page...任何其他方式，這是一個要具備以上特色的系統
Chapter 2.
整本書的的需求捕捉架構大體上就被他的圖一言以蔽之，後面都是章節是一些實用技巧
Chapter 3.
作者注重Living Documentation System，他建議必須可以執行ATDD以及BTDD，因為一致性在文件系統很重要，作者使用Testing來維護系統的一致性，做這建議從一開始，需求就必須可以執行(executable)
書中也提到一個普遍性的誤會就是agile process不需要文件!其實這是根本上的錯誤。其實另外一個更廣泛的錯誤就是，開發人員認為環境一直改變，不需要維護需求，這才是更嚴重的問題，所以這樣的開發人員會把agile process當藉口
Chapter 1.
一個好的需求文件，應該具備底下的優點
- 眾人一致同意的功能
- 精確地描述
- 已完成此功能為目的
- 文件容易改變跟維護
- 避免太過詳細且浪費的需求描述
- 文件必須易懂
- 文件必須可以驗證
- 文件要具備一致性以及低成本的特性
- 文件必須符合process的iterations
作者推崇一種稱為Living Documentation System的工具，也就是維護需求捕捉文件的系統概念，不管是word files或者web page...任何其他方式，這是一個要具備以上特色的系統
Chapter 2.
整本書的的需求捕捉架構大體上就被他的圖一言以蔽之，後面都是章節是一些實用技巧
Chapter 3.
作者注重Living Documentation System，他建議必須可以執行ATDD以及BTDD，因為一致性在文件系統很重要，作者使用Testing來維護系統的一致性，做這建議從一開始，需求就必須可以執行(executable)
書中也提到一個普遍性的誤會就是agile process不需要文件!其實這是根本上的錯誤。其實另外一個更廣泛的錯誤就是，開發人員認為環境一直改變，不需要維護需求，這才是更嚴重的問題，所以這樣的開發人員會把agile process當藉口
2013年3月28日 星期四
新的語言特色!!??
java從java 5(or 6)?開始引入一連串的特色，讓我覺得這個語言愈來愈難掌握，愈來愈像是C++翻版:P
從annotation開始，annotation是類似comment，卻可以指使compiler去做一些處理，如果使用過hibernate的人就知道，可以連hibernate原本用來對應DB與java物件之間的xml檔案，全部寫入annotation上
跟著為了溶入generic programming，也就是在C++的template以及STL like的函數，引入了<?>這個符號，generic programming本人可是對他又愛又恨阿，他是非常的powerfull，但是又非常的難以maintain以及extend(對了，有時候還非常難以debug，visual c++ 6.0，光compiler吐出來的message，就根本不能看，更遑論runtime了)，只敢使用STL或者Boost之類，其他人寫出的template lib，我可是十分警戒
後來因為其他需要，我開始使用python之類的語言，好處是十分快速的可以開發出一些prototype，來驗證自己的演算法，即使python的速度大概只能達到C++的1/10，不過如果我用C++開發大概要一個月，python我只要一個星期就搞定了XD 在驗證想法上，python有很大的優勢，只要把速度的問題交給機器去克服:P
在使用python之後，突然我想到了一個問題，為何PHP/Python這類不純粹是OO的語言，可以發展得如此之好，甚至於好過原本Java，不是一直在說OO可以幫忙處理、分析複雜的問題嗎??為何感覺PHP/Python愈發興盛?這意味著有某些是我們沒考慮到的!?這個問題似乎還沒有個終極的答案，我只有把它留在心裡
最近看了一下，java 8的新特色，OMG，開始支援一些PHP/Python的特色，比方說lambda的特色，讓java感覺又為了相容一些functional programming的特色以及generic的特色，"走回頭路"，整個語法亂到了一個極致。在此同時，已也已經披露了OO的一些極限，比方說，在以前(java 6)，你想弄個類似function pointer(C/C++)，必須定義一個介面，走template method或者其他pattern的模式，光為了一個function pointer，必須多出一個interface再多出一個implementation，當然在OO上面有好處，但是在code上面可是多了不少阿
另外上面這些java的新特色，有個幾乎千篇一律的特色就是.....全部是在compiler的時候做手腳，也就是在.java轉換成.class的時候自動產生一些額外的code
回到核心的問題，是否一個語言在與時俱進的時候，必須要弄出一些"不倫不類"的特色，弄了一些code sugar，但是降低了原本的簡潔性?我倒是覺得java乾脆弄出個新的關鍵字，不要再把一些舊有的模式跟新的模式作一種奇怪的搭配，然後用compiler去處理這件事情。我只能說，我對這些新特色十分感冒orz
從annotation開始，annotation是類似comment，卻可以指使compiler去做一些處理，如果使用過hibernate的人就知道，可以連hibernate原本用來對應DB與java物件之間的xml檔案，全部寫入annotation上
跟著為了溶入generic programming，也就是在C++的template以及STL like的函數，引入了<?>這個符號，generic programming本人可是對他又愛又恨阿，他是非常的powerfull，但是又非常的難以maintain以及extend(對了，有時候還非常難以debug，visual c++ 6.0，光compiler吐出來的message，就根本不能看，更遑論runtime了)，只敢使用STL或者Boost之類，其他人寫出的template lib，我可是十分警戒
後來因為其他需要，我開始使用python之類的語言，好處是十分快速的可以開發出一些prototype，來驗證自己的演算法，即使python的速度大概只能達到C++的1/10，不過如果我用C++開發大概要一個月，python我只要一個星期就搞定了XD 在驗證想法上，python有很大的優勢，只要把速度的問題交給機器去克服:P
在使用python之後，突然我想到了一個問題，為何PHP/Python這類不純粹是OO的語言，可以發展得如此之好，甚至於好過原本Java，不是一直在說OO可以幫忙處理、分析複雜的問題嗎??為何感覺PHP/Python愈發興盛?這意味著有某些是我們沒考慮到的!?這個問題似乎還沒有個終極的答案，我只有把它留在心裡
最近看了一下，java 8的新特色，OMG，開始支援一些PHP/Python的特色，比方說lambda的特色，讓java感覺又為了相容一些functional programming的特色以及generic的特色，"走回頭路"，整個語法亂到了一個極致。在此同時，已也已經披露了OO的一些極限，比方說，在以前(java 6)，你想弄個類似function pointer(C/C++)，必須定義一個介面，走template method或者其他pattern的模式，光為了一個function pointer，必須多出一個interface再多出一個implementation，當然在OO上面有好處，但是在code上面可是多了不少阿
另外上面這些java的新特色，有個幾乎千篇一律的特色就是.....全部是在compiler的時候做手腳，也就是在.java轉換成.class的時候自動產生一些額外的code
回到核心的問題，是否一個語言在與時俱進的時候，必須要弄出一些"不倫不類"的特色，弄了一些code sugar，但是降低了原本的簡潔性?我倒是覺得java乾脆弄出個新的關鍵字，不要再把一些舊有的模式跟新的模式作一種奇怪的搭配，然後用compiler去處理這件事情。我只能說，我對這些新特色十分感冒orz
2013年3月21日 星期四
軟體設計與開發之野人獻曝(2)
我一直在想我有沒有資格寫一篇如何熟悉軟體開發過程的地圖，一直誠惶誠恐，覺得自已不夠資格，不過我換個角度來想，我把我自己的過程寫下來，或許對一些新踏入的人，可以有一些參考作用，就比較釋懷了
誠如會寫軟體未必需要懂得軟體工程，但是軟體工程可以幫助提綱挈領，統籌資料
個人認為的次序是 "軟體工程"=>"軟體流程"，需求捕捉以及分析的工具，還需要"設計工具"(UML/Design pattern/Architecture Design)，最後是"程式工具"(Refectoring)，但是這裡缺乏了專案管理的工具，畢竟市面上太多，懂得流程後，尋找工具或者手動應該會輕鬆得多
軟體工程(統合概念的書籍)
軟體開發流程的書籍 (UP, RUP, agile, scrum)
設計工具 (UML, design pattern, architecture design)
需求捕捉與管理
程式(Code)工具
其他(CMMI)
個人經驗，我是從RUP/UP入手，其實學習過程中，剛好另外一套稱為XP (eXtrem Programming)的學說興起，我個人在心理上比較認同XP(或許是自己是個programmer吧:-> )。使用RUP/UP的過程中，真的開始覺得他非常heavy，每件事情都快要鉅細靡遺，但是我也了解到了一個軟體開發過程中應該要有的大多數的成果(artifacts)
跟著也是一般人都會有的疑問，就是需求捕捉，之前寫得"從user case裡面直接分析出名詞跟動詞接著進入到設計階段"<=這絕對是簡化到誇張的講法，因為一般需要從需求裡面分析出domain model跟著才進化到desgin model
需求分析設計，一個講求what to do，一個講求how to do，但是在what to do之前呢?如何讓人們懂得溝通?一個是住在火星的programmer，一個是住在水星的客戶(business man)，一個只認得code，一個只會寫的一嘴好程式(最常見的需求，我要做的跟XXX網站一樣，XXX請自行帶入yahoo, amazon, 淘寶...)，在上面幾本書有很好的解析，writing effective use cases比較偏重UP/RUP的模式，Sepcification by Example, User Stories Applied則是Agile
至於設計工具GoF的design pattern就不用說了，真的是很多OOD的工具，另外一本Pattern Oriented Software Architecture(簡稱POSA)則是講究Architecture，如果懂得Architecture以及Pattern中間模糊的差異(其實有時候蠻難切開的，比方說broker有時是architecture有時又是pattern)，另外一本Patterns of Enterprise Application Architecture則包含了許多web based的pattern跟架構
其他常用的code工具refatoring則是如何改善code工具，除了改善，我覺得後面另外一個很重要的精神是，不要隨便拋棄code(約爾趣談軟體有提到類似的精神)，但是refactoring有個天生的缺點，很繁瑣，如果沒有自動化工具，我建議把一些類似rename等等太低接的動作捨棄，專注界面的改善比較好
最後是CMMI，CMMI這東西抽象化程度不輸給軟體工程，完全只有給出what to do(工程/流程面相)，沒有how to do(實際執行)，不妨將軟體流程的成果對應到CMMI上面去，因為軟體流程幾乎可以cover CMMI的Level 2跟Level 3，但是很不幸Level 3有四個SG (special goal)是屬於組織流程的，軟體工程無能為力，說實話Level 4跟Level 5我也很難領悟
誠如會寫軟體未必需要懂得軟體工程，但是軟體工程可以幫助提綱挈領，統籌資料
個人認為的次序是 "軟體工程"=>"軟體流程"，需求捕捉以及分析的工具，還需要"設計工具"(UML/Design pattern/Architecture Design)，最後是"程式工具"(Refectoring)，但是這裡缺乏了專案管理的工具，畢竟市面上太多，懂得流程後，尋找工具或者手動應該會輕鬆得多
軟體工程(統合概念的書籍)
需求捕捉與管理
其他(CMMI)
個人經驗，我是從RUP/UP入手，其實學習過程中，剛好另外一套稱為XP (eXtrem Programming)的學說興起，我個人在心理上比較認同XP(或許是自己是個programmer吧:-> )。使用RUP/UP的過程中，真的開始覺得他非常heavy，每件事情都快要鉅細靡遺，但是我也了解到了一個軟體開發過程中應該要有的大多數的成果(artifacts)
跟著也是一般人都會有的疑問，就是需求捕捉，之前寫得"從user case裡面直接分析出名詞跟動詞接著進入到設計階段"<=這絕對是簡化到誇張的講法，因為一般需要從需求裡面分析出domain model跟著才進化到desgin model
需求分析設計，一個講求what to do，一個講求how to do，但是在what to do之前呢?如何讓人們懂得溝通?一個是住在火星的programmer，一個是住在水星的客戶(business man)，一個只認得code，一個只會寫的一嘴好程式(最常見的需求，我要做的跟XXX網站一樣，XXX請自行帶入yahoo, amazon, 淘寶...)，在上面幾本書有很好的解析，writing effective use cases比較偏重UP/RUP的模式，Sepcification by Example, User Stories Applied則是Agile
至於設計工具GoF的design pattern就不用說了，真的是很多OOD的工具，另外一本Pattern Oriented Software Architecture(簡稱POSA)則是講究Architecture，如果懂得Architecture以及Pattern中間模糊的差異(其實有時候蠻難切開的，比方說broker有時是architecture有時又是pattern)，另外一本Patterns of Enterprise Application Architecture則包含了許多web based的pattern跟架構
其他常用的code工具refatoring則是如何改善code工具，除了改善，我覺得後面另外一個很重要的精神是，不要隨便拋棄code(約爾趣談軟體有提到類似的精神)，但是refactoring有個天生的缺點，很繁瑣，如果沒有自動化工具，我建議把一些類似rename等等太低接的動作捨棄，專注界面的改善比較好
最後是CMMI，CMMI這東西抽象化程度不輸給軟體工程，完全只有給出what to do(工程/流程面相)，沒有how to do(實際執行)，不妨將軟體流程的成果對應到CMMI上面去，因為軟體流程幾乎可以cover CMMI的Level 2跟Level 3，但是很不幸Level 3有四個SG (special goal)是屬於組織流程的，軟體工程無能為力，說實話Level 4跟Level 5我也很難領悟
訂閱：
文章 (Atom)