Hadoop and HBase vs RDBMS メモ

Hadoop and HBase vs RDBMSの超適当翻訳メモ

---

Hadoop/HBase vs. RDBMS

December CTO Forum

Jonathan Gray
Streamy.com

-1-

プロフィール

・Streamy.comの共同創業者
・経歴（経験）：コンピュータエンジニアリング、分散／耐障害性アプリケーション、リレーショナルデータベース、Linux
・2008年6月にStreamy.comのバックエンドをPostgreSQL からHadoop/Hbaseに移行に成功

-2-

なぜHadoop/Hbaseなのか

・データがペタバイトまで大きくなった
・従来のデータベースは拡張するのにお金がかかるし、本質的に分散化が難しい
・一般的なハードウェアは安くてパワフル
- 1000ドル（？）で4core/4GB/1TB
- 300GB 15k RPM SAS が500ドルぐらい
・ランダムアクセスとバッチ処理が必要
- Hadoop はbatch/streamingのみサポート

-3-

Hadoop/Hbaseの歴史

・ Googleは拡張性の問題を解決した
- “The Google File System” 2003年10月発表
　- Hadoop DFS
- “MapReduce：大規模クラスター構成での簡略化されたデータ処理” 2004年12月発表
- Hadoop Map Reduce
- “Bigtable：構造化されたデータのための分散ストレージファイルシステム” 2006年11月発表
- HBase

-4-

Hadoop の紹介

・2つのメインコンポーネント
- Hadoop DFS
　　- 一般的なハードウェア上で動作する、スケーラブルで障害耐性の高い、高性能分散ファイルシステム
- Hadoop Map Reduce
- 分散コンピューティングのためのソフトウェアフレームワーク
・採用実績
　- 多くの組織で製品として使われている
　- Yahooはプライマリースポンサーとして何万ものHadoopのアクティブノードを動かしている

-5-

HDFS: Hadoop Distributed File System

・数千のノードにペタバイトのデータを複製
- データは64MBのブロックごとに分割され、それぞれのブロックが3回複製される
・マスター／スレーブアーキテクチャ
- マスター NameNode はブロックの位置情報を含む
- スレーブ DataNode はローカルのファイルシステムのブロックを管理する
・一般的なハードウェアで組み立て
- 15k RPM diskもRAIDも不要

-6-

HDFS の例

・１テラバイトのテキストファイルを10ノードのクラスター上に展開
- Java APIか、コマンドラインが使える
./hadoop dfs ?copyFromLocal ./srcFile /destFile
- ファイルは64MBのブロックに分割(合計16,384ブロック)
- それぞれのブロックは3つのノードに送られる(合計49,152ブロック、3テラバイト)
- 異なったクラスター／地理的な位置にレプリケーションが保障される

-7-

MapReduce

・ペタバイトのデータを確実にローカルファイルのように扱うための分散プログラミングモデル
- JavaとＣが最初から使える
- HadoopStreamingを使ってどんな言語も使える
・ 関数型プログラミングのmap/reduce関数に触発された
　入力 -> Map() -> コピー/ソート -> Reduce() -> 出力

-8-

MapReduce の例

・ WordCount の例をHDFS上の1テラバイトのファイルで動かす
- 各ブロックファイルでMapタスク起動
- それぞれのタスクの中で、Map関数がそれぞれの行で呼ばれる：Map(LineNubmer,LineString)
- LineStringの中のれぞれの文字→Output(Word,1)
- Mapの出力はソートされ、グループ化され、reducerにコピーされる
- Reduce(Word,List)がそれぞれの文字で呼ばれる
- Output(Word,Length(List))
- 最終的に、それぞれの文字の合計数が出力される

-9-

Hadoop…

　 - Hadoopは、大規模なデータを”バッチ”で保存したり、ストリーミングするように設計されている
- Hadoopは、リアルタイムでクエリーを流すのには向いていない
- Hadoopは、ランダムアクセスをサポートしない
これがHbaseがある理由。

-10-

Hbaseとは？

・分散、
・列指向、
・多次元、
・高可用性、
・高性能
・ストレージシステム
プロジェクトゴール：
数十億の列行×数百万の列×数百のバージョン
の数ペタバイトデータが数千の一般的なサーバに載る

-11-

HBase でできないor不得意なこと

・SQL データベース
- joinがない、クエリーエンジンがない、型がない、ＳＱＬがない
- トランザクション、副次索引はできるけど、未熟
・ＲＤＢＭＳの当座の代用品
・ＲＤＢＭに対しての非スキーマ構造
- 非正規化データ
- 分散してコマ切れのテーブル

社内のＤＢＡなら“ＮＯ”って言うでしょう

-12-

HBase のアーキテクチャ

・テーブルはいくつもの領域(regions)からできている
・領域は”startKey”と”endKey”によって特定される
- 空のテーブル：
(Table,NULL,NULL)
- ２つの　領域のテーブル：
(Table,NULL,”Streamy”)と(Table,”Streamy”,NULL)
・それぞれの領域はＨＤＦＳ上の各ファイルやブロックとして違ったノードにあるかもしれない。
それぞれの領域はHadoopによって複製される

-13-

HBase アーキテクチャ（つづき）
・２つのタイプのHbaseのノード
・特別テーブル ? ROOT ? と META。スキーマ情報と領域の位置を保存
・マスターサーバーは領域サーバーの監視に責任を持ち、領域のロードバランシングにも責任を持つ

-14-

HBase のテーブル

・テーブルは行によってソートされる
・テーブルスキーマは”column families”によってのみ定義される
- それぞれのファミリーはいくつもの列から成る
- それぞれの列はいくつものバージョンから成る
- 列はinsertされた時のみ存在し、NULLの入力は自由（できる？）
- ファミリーの中の列はソートされ、また、お互いにソートされる
- テーブル名を除くすべてはbyte[]
(Table,Row,Family:Column,Timestamp)→値

-15-

HBase テーブルのデータ構造

SortedMap(
RowKey, List(
SortedMap(
Column, List(
Value, Timestamp
)
)
)
)
SortedMap(RowKey, List(SortedMap(Column, List(Value, Timestamp))))

-16-

Web クロールの例

・webクロールデータの保存
- “crawl”テーブルと “content” ファミリー
- 列の中にＵＲＬの行
- content:data 加工していないクロールしたデータを保存
- content:language HTTPのLanguage ヘッダーを保存
- content:type HTTPのContent-Typeヘッダーを保存
- もしハイパーリンクや画像などのために未加工データを処理するのであれば、”links”ファミリーと”images”ファミリーを加える
　 - links: それぞれのハイパーリンクのための列
- images: それぞれの画像のための列

-17-

RDBMSでのWebクロールの例

・一般的なＤＢだとどうなるのか？
- “crawl”テーブルの中に”url”,”data”,”language”,”type”列
- “links”テーブルの中に”url”と”link”列
- “images”テーブルの中に”url”と”image”列
・どのぐらいの規模？
- 1000万ドキュメント w/avg 10リンクと10イメージ
- 合計2億1000万行に対して合計1000万
- links/imagesテーブルでインデクスが膨れ上がる

-18-

HBaseへの接続

・ネイティブ Java クライアント/API
- get(byte[] row, byte[] column, long ts, int versions)
・非ネイティブ Java クライアン
- Thrift server (※)(Ruby, C++, etc)
- REST server
- Native C/C++ client scheduled for 0.20 release
・MapReduce用TableInput/TableOutputFormat
- HBase が MapReduce の元データ
・Hbase Shell
- データ取得、追加、スキャン、管理用Jruby シェル

(※「Threift server」:Thrift is a software framework for scalable cross-language services

-19-

HBase 拡張

・Hive, Pig, Cascading
- 次期Hbase統合のHadoop用のMapReduceツール
・Pigi
- Hbase ORM はindex、join、検索、ページング、順序付けを含む
・subRecord
- ストレージと統合されたインフラを提供。セキュリティ、ロギング、評価指標、Hbaseのモニタリング
・ Hbase-Writer
- Heritrix はHbaseテーブルを直接クロールする

-20-

HBaseの歴史

・2006年11月
- GoogleがBigTableの論文を発表
・2007年2月
- 最初のHbaseのプロトタイプがHadoop contribとして作成される
・2007年10月
- 最初の利用可能なHbase
・2008年1月
- Hadoop がトップレベルプロジェクトになり、Hbaseがサブプロジェクトになる
・2008年10月
- Hbase 0.18.1 リリース

-21-

現在のプロジェクトステータス

・最新リリース：HBase 0.18.1 on Hadoop 0.18.2
- 8番目のHBaseリリース
- スケーラブルで安定なバージョンリリース
・もうすぐリリース：HBase 0.19.0 on Hadoop 0.19.0
- マスター障害時に小さなデータの消失もない機能をHDFSに加える（最大100この編集ミスに対して3万の履歴)
- メモリ利用の効率化とリソースモニタリングについての大規模な改修
・その次のリリース: HBase 0.20.0 on Hadoop 0.20.0 (March 2009)
- 新しいHDFSファイルフォーマット「TFile」
- SPOF(Single Point of Failer)をなくす：ZooKeeper がマルチマスターを実現
-大量のランダムアクセスに対する改善
- インメモリー、キャッシュ容量の拡張

-22-

HBase の使われているところ

・Streamy
・Powerset
- Birthplace of HBase
- Home of Michael Stack, project lead
・Mahalo
・The Shopping Engine @ Tokenizer.org
・Advanced Threats Research @ Trend Micro
・Wikia
・Multilingual Archive @ WorldLing
・Also being used in some capacity at:
- Yahoo, Last.fm, Videosurf, and Rapleaf

-23-

Hadoop/HBase > PostgreSQL,MySQL,SQLServer2008,Oracle

質問ある？

-24-

比較１

・ショッピングカートを保存するシステム
- 顧客、製品、注文

-25-

シンプルなSQLスキーマ

CREATE TABLE customers (
customerid UUID PRIMARY KEY,
name TEXT, email TEXT)

CREATE TABLE products (
productid UUID PRIMARY KEY,
name TEXT, price DOUBLE)

CREATE TABLE orders (
orderid UUID PRIMARY KEY,
customerid UUID INDEXED REFERENCES(customers.customerid),
date TIMESTAMP, total DOUBLE)

CREATE TABLE orderproducts (
orderid UUID INDEXED REFERENCES(orders.orderid),
productid UUID REFERENCES(products.productid))

-26-

シンプルなHbaseのスキーマ

CREATE TABLE customers (content, orders)
CREATE TABLE products (content)
CREATE TABLE orders (content, products)

-27-

SQL、HBaseへのクエリ

・顧客用：name,emal,orders取得
・製品用：name,price取得
・注文用：customer,stamp,total取得
・注文用：productのリスト取得

-28-

SQLが得意なこと
・join
- 1つのクエリですべての注文した製品と製品情報を取得
・ 副次索引
- e-mailからのcustomerid取得
・参照整合性
- 注文を策することで’orderproducts’も削除される
- IDをupdateする際の伝搬
・リアルタイム解析
- GROUP BYやORDER BY は簡易統計解析ができる

-29-

Hbaseが得意なこと

・データスケール
- 100万顧客と100万製品
- 製品情報は大きなテキストデータシートかPDFファイルを含む
- 顧客が製品ページを見た毎回のトラッキング
・Read/Writeスケール
- テーブルはreads/writesノードに完全に分散される
- 書き込みは高速におこなわれ、インデックスのアップデート不要
・レプリケーション
- 自動的に行われる
・バッチ解析
- 大量の複雑なクエリーが連続して効果的にMapReduceの分散ジョブになり、並列して実行される

-30-

結論

・小さなインスタンスのシンプルなシステムであれば、リレーショナルデータベースは構造やデータアクセスのための方法を提供する
- トランザクションやクエリーエンジンンのほとんどの働きはアウトソースできる
- Hbaseはアプリケーションレイヤーに複雑さをもたらす
・ 拡張の必要があれば、HBaseの特性と柔軟性は、RDBMSでのスケーリングでの悩みを取り除いてくれるでしょう

-31-

比較２

・比較の鍵となる要因
- ハードウェア要件
- 拡張性
- 信頼性
- 使いやすさ
- 費用

-32-

ハードウェア要件
・RDBMSは入出力バウンド
　 - 通常は高速で高価なディスクの大きな配列を必要とする -小さな本番環境は単一ノードで15-30の15k RPMドライブで、16コア、
16?64ギガバイトのRAMが必要かもしれない - 同様の仕様では、バックアップサーバが必要
・Hbaseは一般的なハードウェア用に設計されている
- 最大のパフォーマンス要因はノードの数
- 小さな本番環境では、10-20ノードでそれぞれで2500GB 7.2kRPMのでドライブで、4コアで4GB
- RAIDの１つのマースターノード、デュアルPSU(電源ユニット)、その他、最近ではSPOF

-33-

拡張性

・RDBMSのスケールは以下のもので実現される
- Memcachedによるキャッシング
- パーティショニングは多くの場合アプリケーションか外部ツールに委ねられる
- レプリケーション機能は組み込まれているか、または、有名なRDBMSではアドオンとして提供される
- スケールのメカニズムであるにもかかわらず、アーキテクチャ上効果的なマルチマスターサポートを許容しない
・Hbase はbox外でスケールする
- ランダムアクセスはMemcachedに似た気候によって高速化される(0.20からビルトイン)
- 低速から高速まで同時並行して一定のパフォーマンスを保つ
- 書き込みは分散んされ、インデックスは存在しない
- RegionServerの追加によってスケールがプラグインされる

-34-

信頼性

・RDBMS
- スレーブレプリケーション
- ワーム／ホットバックアップ
- 単一ノードの故障はたびたび致命的となる
・Hbase
- レプリケーションは組み込まれている
- バックアップはできるけど不要。

-35-

使いやすさ

・RDBMS
- 洗練された数100万のSQLとリレーショナルデータモデリング
- 正規化されたスキーマはわかりやすく、予測通りのパフォーマンスを発揮する
- しかし、スキーマはたびたび制限され、変更しにくく、拡張しにくい
・HBaseとMapReduce
- 重要な学修曲線
- 初期の苦労を緩和するため、優れたコミュニティといくつもの使い勝手を良くするツールが増えてきている
- スキーマは緩く定義されているので、データ構造は変更しやすく、パフォーマンスも一定

-36-

その他の要因

・ＯＳ／アーキテクチャ
- RDBMSはターゲットのアーキテクチャによって大きく変わる
- HbaseはLinux用に設計されて、SolarisやWindowsで成功している例もある
・費用
- HbaseはFOSS(Free and Open Source Softuare)
- たくさんの成熟したFOSSのRDBMSはあるが、企業で多く使われているものは高価
・広範な使用
- RDBMSは実証済みである
- HadoopとHbaseはまだ開発中で、まだ本番での広い利用には至っていない

-37-

結論

・2番目と1番目は同じ（？）
・RDBMSは強力な機能を提供しますが、拡張する費用はとても高いです
・Hbaseは必要最小限の機能しかありませんが、少ない費用で拡張できます

-38-

Ubuntu 8.04 LTSでhadoop環境構築

■javaインストール

$ sudo apt-get install sun-java6-*

■javaのバージョン確認

$ java -version
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

■sun java使う設定

$ sudo update-alternatives --config java

■phpインストール(hadoop streamingでphpを動かす場合)

$ sudo apt-get install php5 php5-cli

■ユーザー追加

$ sudo adduser hadoop

■ssh_configが変だったので修正（なぜ?）

$ sudo vi /etc/ssh/ssh_config
PermitRootLoginをコメントアウト

■hadoopユーザ設定(パスなしユーザ設定)

$su - hadoop
$ssh-keygen -t rsa -P ""
$cat .ssh/id_rsa.pub >> .ssh/authorized_keys

■パスなしログイン確認

$ ssh localhost

■hadoopダウンロード、展開

$ wget http://www.meisei-u.ac.jp/mirror/apache/dist/hadoop/core/hadoop-0.20.1/hadoop-0.20.1.tar.gz
$ tar xvzf hadoop-0.20.1.tar.gz
$ ln -s hadoop-0.20.1 hadoop
$ vi hadoop/conf/hadoop-env.sh
export JAVA_HOME=/usr/lib/jvm/java-6-sun
$ cd hadoop

■hadoopテスト(シングルモード)

$ mkdir input
$ cp conf/*.xml input
$ bin/hadoop jar hadoop-*-examples.jar grep input output 'dfs[a-z.]+'
$ cat output/*

■hadoopテスト(疑似分散モード)

$ cd hadoop

☆以下のファイル編集

<configuration>
<property>
 <name>fs.default.name</name>
 <value>hdfs://localhost:9000</value>
</property>
</configuration>

conf/hdfs-site.xml:

<configuration>
<property>
 <name>dfs.replication</name>
 <value>1</value>
</property>
</configuration>

conf/mapred-site.xml:

<configuration>
<property>
 <name>mapred.job.tracker</name>
 <value>localhost:9001</value>
</property>
</configuration>

■フォーマット

$ bin/hadoop namenode -format

■起動

$ bin/start-all.sh

■動作確認

NameNode  :http://localhost:50070/
JobTracker:http://localhost:50030/

■起動確認

$ jps
3815 DataNode
3964 JobTracker
4059 TaskTracker
3894 SecondaryNameNode
3736 NameNode
12858 Jps

■テストデータ作成
・サンプルデータ

$ cat /home/hadoop/sample/sample.txt
a b c d e f g
a b c d e f
a b c d e
a b c d
a b c
a b
a

・phpでmap処理：標準入力の文字列を空白で分割して、タブ区切りの行として出力

#!/usr/bin/php
while ( !feof(STDIN) ) {
    $line = trim(fgets(STDIN));
    foreach ( preg_split('/\s+/', $line) as $word ) {
        if ( $word !== '' ) {
            echo "${word}\t1\n";
        }
    }
}
?>

・phpでreduce処理：標準入力の文字列を数え上げる

$ cat /home/hadoop/sample/reduce.php
#!/usr/bin/php
$value ) {
 echo "${key}\t${value}\n";
}
?>

■テスト
・テストデータ登録

$ cd hadoop
$ bin/hadoop fs -put /home/hadoop/sample/sample.txt input

・実行

$ bin/hadoop jar contrib/streaming/hadoop-0.20.1-streaming.jar \
-input input/sample.txt \
-output output_sample \
-mapper 'php /home/hadoop/sample/map.php' \
-reducer 'php /home/hadoop/sample/reduce.php'

・結果表示：単語ごとに出現回数表示

$ bin/hadoop fs -cat output_sample/*
a       7
b       6
c       5
d       4
e       3
f       2
g       1

■ストップ

$ bin/stop-all.sh

クラウドの種類

パブリッククラウド
サード・パーティー (ベンダー) によって提供されるクラウド・サービス。パブリッククラウドは企業のファイアウォールの外側にあり、クラウド・プロバイダーによって完全にホストおよび管理される。
・メリット
リソースのアウトソース、オンデマンド利用
・デメリット
事業者のインターフェースにあわせる必要性、ガバナンスが効かない

プライベートクラウド
企業内部に提供されるクラウド・サービス。これらのクラウドは企業のファイアウォールの内側にあり、企業によって管理される。
・メリット
リソースの一元化、オンデマンド利用、パブリッククラウドに比べて細かな制御
・デメリット
リソース管理は自社内、運用コストが大きい

ハイブリットクラウド
パブリッククラウドとプライベートクラウドを組み合わせたクラウド。ハイブリッドクラウドは企業が作成し、その管理責任は企業とパブリック・クラウド・プロバイダーとの間で分担される。ハイブリッドクラウドはパブリック・スペースとプライベート・スペース両方のサービスを利用する。
・メリット
パブリッククラウドとプライベートクラウドを適材適所に適用
・デメリット
パブリッククラウドとプライベートクラウドを組み合わせることでの実装、管理の難しさ

バーチャルプライベートクラウド
パブリッククラウド内にプライベートな専用領域を作り出すクラウド。パブリッククラウド内に仮想的な占有領域を作成し、ユーザー企業内の情報システムをVPNで接続する。
・メリット
プライベートを構築できない中小企業でもプライベートクラウドのメリットを享受できる
・デメリット
実験段階で商用事例がない、VPNの提供など事業者の協力が必要

クラウド・コンピューティングの提供形態

アプリケーション・サービス(SaaS)
ソフトウェア（主にアプリケーションソフトウェア）をネットワーク経由のサービスとして提供・販売。
（例：Gmail 、Yahoo! メールなど）
プラットフォーム・サービス(PaaS)
ソフトウェアを構築および稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供。
（例：Amazon Webサービス、Google App Engineなど）
インフラストラクチャー・サービス(IaaS)
コンピュータシステムを構築および稼動させるための基盤（仮想マシンやネットワークなどのインフラ）そのものを、インターネット経由のサービスとして提供。
（例：Amazon EC2、Amazon S3など）

JUnit A Cook's Tour 「4. Conclusion」まとめ的な何か（自分めも）

・パターン使うとフレームワーク開発とか人に説明するのにベンリだよ！
・パターンが密集してると使いやすいけど、変更しにくいよ！
・でもよくできたフレームワークはパターン密集してるからそっちの方がいいかもね！
・他人に使わせる前に自分で使ったらいいと思うよ！
・フレームワークはシンプルなのが使いやすくていいよね！
・どうしても機能追加したくなったら拡張パッケージにしたらいいと思うよ！
・コード書くよりいっぱいコード読んでね！
・リファクタリング大事だよ！

JUnit A Cook's Tour 4. Conclusion翻訳メモ

JUnit A Cook's Tour の「4. Conclusion」を雰囲気でほにゃくしてみる。
☆はよくわかんないところ。
ほんやくこんにゃくホシイ。

----

4. Conclusion
4.結論

To conclude, let’s make some general observations:
結論として、全体を見てみましょう

Patterns
パターン

We found discussing the design in terms of patterns to be invaluable, both as we were developing the framework and as we try to explain it to others.
設計をパターンの単位で議論することは、フレームワークの開発とフレームワークを他者に説明する上で有益であることが分かりました。

You are now in a perfect position to judge whether describing a framework with patterns is effective.
あなたは、現在、あるフレームワークが効果的なパターンで記述されているか判断できる最適な立場にあります。

If you liked the discussion above, try the same style of presentation for your own system.
もし上記のような議論が好きなら、自分のシステムのために同じスタイルのプレゼンテーションを試してみてください。

Pattern density
パターンの密度

There is a high pattern "density" around TestCase, which is the key abstraction of JUnit.
TestCaseのまわりには高いパターンの「密度」があります。そして、それはJUnitの鍵となる抽象概念です。

Designs with high pattern density are easier to use but harder to change.
高密度なパターンによる設計は、使いやすいのですが、変更が困難です。

☆We have found that such a high pattern density around key abstractions is common for mature frameworks.
成熟したフレームワークではそういった鍵となる抽象概念による高密度なパターンは一般的であることがわかりました。

☆The opposite should be true of immature frameworks - they should have low pattern density.
反対に、未熟なフレームワークではパターンの密度が低いはずです。

☆Once you discover what problem you are really solving, then you can begin to "compress" the solution, leading to a denser and denser field of patterns where they provide leverage.
いったんあなたが本当に解決したい問題を発見したら、あなたは解決策を圧縮して、パターンが提供する、より高密度な領域に導いてくれます。


Eat your own dog food
あなた自身のドッグフードを食べてください(他人に提供するものはまず自分で試してみましょう)

As soon as we had the base unit testing functionality implemented, we applied it ourselves.
我々は基本単位のテストが機能するところまで実装したらすぐに、我々自身でそれを適用しました。

☆ A TestTest verifies that the framework reports the correct results for errors, successes, and failures.
TestTest(Testインターフェースのためのテスト？)は、フレームワークがエラーや成功、失敗などの適切な結果をレポートすること検証しています。

We found this invaluable as we continued to evolve the design of the framework.
我々がフレームワークのデザインを発展させ続けたので、こういった内容は非常に貴重であるとわかりました。

We found that the most challenging application of JUnit was testing its own behavior.
JUnitで最も挑戦的なアプリケーションは、JUnitがJUnit自体のふるまいをテストしていることであることを見いだしました。



Intersection, not union
交差、結合ではなくて。

There is a temptation in framework development to include every feature you can.
フレームワーク開発では、できるだけいろんな機能を取り込みたいという誘惑があります。

After all, you want to make the framework as valuable as possible.
結局、あなたはフレームワークをできるだけ価値のあるものにしたいのです。

However, there is a counteracting force- developers have to decide to use your framework.
しかし、開発者があなたのフレームワークを使うことを決心させなければならない反作用（ジレンマ？）があります。

The fewer features the framework has, the easier it is to learn, the more likely a developer will use it.
機能が少ないフレームワークは、学習が容易で、開発者に使われやすいでしょう。

JUnit is written in this style.
JUnitは、このスタイルで書かれています。

It implements only those features absolutely essential to running tests- running suites of tests, isolating the execution of tests from each other, and running tests automatically.
JUnitはテストを走らせるために厳選された機能だけを実装しています。それは、テスト１式を走らせること、お互いに独立したテストの実行、自動的にテストを走らせることなどです。

Sure, we couldn’t resist adding some features but we were careful to put them into their own extensions package (test.extensions).
もちろん、私たちは若干の特徴を加えることを抑えることができませんでした。しかし、それは拡張パッケージ(test.extensions)の中に、注意深く取り込みました。

A notable member of this package is a TestDecorator allowing execution of additional code before and after a test.
この拡張パッケージで特筆すべきクラスはTestDecoratorで、TestDecoratorはテストの前後に追加コードを実行できるようにしています。


Framework writers read their code
フレームワークの記述者は、自分のコードを読みます

We spent far more time reading the JUnit code than we spent writing it, and nearly as much time removing duplicate functionality as we spent adding new functionality.
我々がJUnitのコードを読んでいる時間は、JUnitのコードを書いた時間よりも遥かに多くの時間を費やしています。
そして、新しい機能を追加している時間とほとんど同じくらいの時間を重複機能の除去に費やしています。

We experimented aggressively with the design, adding new classes and moving responsibility around in as many different ways as we could imagine.
我々は新しいクラスを加えたり、想像できるあらゆる方法で責務を移動したりして、積極的に設計を試しました。

☆We were rewarded (and are still being rewarded) for our monomania by a continuous flow of insights into JUnit, testing, object design, framework development, and opportunities for further articles.
JUnitへの洞察、テスト、オブジェクトデザイン、フレームワーク開発、そしてさらなるものへのチャンスといった、我々の執拗で継続的継続的なフローによって、我々は恩恵を受けています。（そしてこれからも）



The latest version of JUnit can be downloaded from http://www.junit.org.
JUnitの最新版は、http://www.junit.org.からダウンロードできます。

vmwareでubuntu linuxの設定めも

windows ホストのvmwareでubuntu linuxをインストールしたました。
ほとんどの設定についてはコチラのサイトがとても詳しいです。
で、java の設定はコチラで。

その他設定メモ

• sshは２がデフォルトらしいので、ttsshは使えない(PuTTY ごった煮版を利用)
• sshの設定はrootログインだけ拒否して、認証はとりあえずパスワード認証で。
  
• SDカードに入れたのでShrinkは40分ぐらいかかった
• ターミナル上はディレクトリ名は日本語よりもやっぱり英語にしといた方が楽
• windowsで作ったソースは文字化けするのでiconvで変換とかが必要そう
• ファイル転送はとりあえずwinscpで。（sambaはめんどくさそうなので後でやる)