Amazon EC2/S3クラウド入門

Amazon EC2/S3クラウド入門

posted with amazlet at 09.02.19

学びing
秀和システム
売り上げランキング: 862

Amazon.co.jp で詳細を見る

去年ぐらいからクラウドと言うキーワードが注目されるようになって来ています。
この本は題名どおり、クラウドコンピューティングを紹介する記事でよく事例として紹介されるAmazon EC2/S3というサービスについて扱った本です。
学びing株式会社が｢けんてーごっこ｣というWebサービスの提供にEC2/S3を使った経験を元に書いた本ですので、導入に当たって検討したことや実際のサービスに導入してからの話も書かれており、抽象論から始まるいわゆる入門本とは違って具体的な話から入っているところが特徴だと思います。そのため、非常に読み始めやすいです。

内容

1章がEC2/S3の体験記、2章がEC2/S3の使い方について、3章が運用上の注意、4・5章ではクラウドとはどういったものかという解説と具体例の紹介、6章がクラウドを利用する上でのメリットの解説、7章がクラウドの今後という内容になっています。

どういう人向けの本か

この本では、2章ではEC2/S3の登録方法から使い方まで写真入りで解説してあるので、これから始めてみようと言う人は参考になると思います。EC2/S3の周辺ツールも紹介されているのもよいです。
クラウドって何なの？って人は4〜6章辺りを読めば大体把握できます。
この内容であれば1500円ならば結構お徳かもと思いました。

個人的に面白かった部分

特に面白かったのは、1章と3章です。
学びingではスタートアップで専用サーバ1台を使っていたそうなのですが、アクセスが増えるにつれて専用サーバの台数を増やしていき、検討した結果Amazon EC2/S3にサーバの引越しをすることを決めました。
どういう構成でサイトを運営しているのかという話から、専用サーバを借りたら初期コストと運用コストはいくらぐらいかかるのか、EC2/S3に移ってからはどのくらいのコストで回るようになったのかと言うことが具体的に数値でも書いてあったので自分自身での導入のイメージもしやすいのです。
本番環境と同じ構成のグローバルIPアドレスを持ったサーバをすぐに立ち上げができるということは開発において非常に助けになると思います。
1章もそうですが3章の運用の注意事項は少しEC2/S3を触った人では書けない話だと思うので、非常に参考になります。

Amazon EC2/S3を導入すべきか

EC2/S3には、サーバの物理的な位置の関係上転送速度が遅い、運用方法に癖がある、といったようなデメリットもいくつかありますが、それを補って余りあるメリットがあります。
この本の内容を元に、どういう人・会社がAmazon EC2/S3を導入したほうがよいのかを考えてみました。
EC2で1台を1月起動しっぱなしだと大体7000円ぐらい*1になるそうです。なので、単純に値段だけ見れば専用サーバに比べると安いといえます。
しかし、いわゆるレンタルサーバや専用サーバを使う場合と違い、Webから簡単にサーバ管理ができるツールなどは用意されていません。つまり、サーバをある程度運用する知識のある人がいなければEC2/S3を導入はできないと思います。運用知識がある人がおらず、ある程度のサポートが欲しい場合はレンタルサーバか専用サーバを洗濯するほうが良いと思います。
個人でちょっとしたWebアプリケーションを公開するぐらいの負荷であれば、さくらインターネットやXREAのような格安のレンタルサーバで十分です。
個人やスタートアップの企業であればサーバを1台買って運用するほうが安く上がるように思われると思います。しかし、最初に買うコストも結構かかりますし、サーバを起動しっぱなしにすると電気代が結構馬鹿になりません。台数が増えてくるとネットワークの管理やサーバを置く場所をどうやって管理するのかと言う問題もあります。個人の場合だと部屋においておくと夏場は暑くて死ねます。こういった物理的な問題をクリアできる環境であればEC2/S3を導入する必要はないかもしれません。
急成長が見込まれるサービスや一時的にアクセスが増えることがわかっているときなどにはEC2は有効だと思います。物理的な導入には時間がかかりますし、そのサーバ台数が一時的に必要なだけであればあとからサーバが無駄になってしまいます。EC2の動的に台数を増減できることがこういう状況にマッチしています。
同様に、大学の研究室などで一時的に大量の計算機が必要になったときにも有効ではないかと思いました。

id:amachangがちょっと前のGoogle Adsenseの件で

ウェブはスピードが命だ、腰が重いことが命取りになることが多い。
即行動できることが、技術よりも重要なことが多い。
12 月までの自分だったら、広告を出すという選択肢を選ぶのに 1 日かかったかもしれない。
今の自分なら 10 分で広告を出せる

Google Adsense の件について - IT戦記

と言っていましたが、今回のEC2/S3についても同じことが言えるのではないかと思います。近いうちに自分で試してみようと思っています。

*1:今は円高なのでもっと安いかも

個人で運用するWebサービスの限界を考える

個人が作成したWebサービスの数はここ数年で爆発的に増えています。
サーバ自体の導入コストも低下してきており、レンタルサーバでもPHPのようなスクリプト言語が使えるものが珍しくなくなり、Ruby on Railsのような開発速度を向上させるフレームワークも登場してきて、今後も個人が運用するWebサービスは増加をしていくでしょう。

個人Webサービスの寿命

今回考えたいのは、そういった個人で運用するWebサービスの終了するときについてです。
Webサービスは作ってからが本当のスタートで、開発者は開発にかかったコスト以上に運用するために時間的・金銭的・精神的にコストを負担していくことになります。なので、自分の払うコストに見合わないと思ったらサービスの終了を考えるのは当然だと思います。
つまり作った人一人がやる気をなくしてしまえばどんなにいいサービスでも一瞬で消えてしまうということです。
最近上場したGREEですが、当初個人で運営していたときに｢管理人さんが死んだらサービスはどうなるんですか？困ります！｣的なコメントをユーザからいただいたと言う話を聞いたことがあります。極端な話になりますが、作った個人が事故や病気で亡くなったりしてしまってもそのサービスは終了してしまいます。
開発者である個人が自分のサービスへ関われなくなったそのときがWebサービスの寿命となっていしまうということ。これが個人で運用するWebサービスの限界なのではないかと考えます。

止めるのは作った人の自由？

個人で作ったものなのだから好きなときに止めてもよいではないかという意見もあると思います。
ちょっとした検索サイトやジェネレータやマッシュアップのようなサービスであれば人気があれば代替となる似たサービスはあると思いますので、それもありだと思います。そもそも、そういう系のサービスだとサーバさえ確保できればメンテナンスはほとんどいらない場合もありますのでただ放置しておくという選択肢もあるかもしれません。
ただ、CGM的な要素やコミュニティ要素を持ったサービスにおいては、それまでサービス内でユーザが作ったものやそのコミュニティは立派な財産だと思うので、作った人の一存で終了させてしまう前に、どうにか延命の方法を考えて欲しいと個人的には思います。

ひろゆきが2ちゃんねるを譲渡したって話も今回書いたようなことを考えて決定したのかもしれないなと思ったり。とはいえ、2ちゃんねるの場合は複数人が運用に関わっているのでどうとでもなりそうですが。

たくさんのユーザがいるサービスを止めてしまうと、ユーザはサービスを使えなくなると言う不利益をこうむりますし、開発者としてもこれまで成長させるのにかけたコストがもったいないと思います。

サービスを延命する

個人が運用を止めようと思ったときにサービスを延命するために選択可能な方法で、私がぱっと思いついたものは3つあります。
一つ目は、先ほど話したGREEのように起業すること。ビジネスとして成立しうるサービスまで成長させられるのであればこの選択肢もありだと思います。でもそこまで収益性の見込めるサービスは大量には生まれてこないし、起業することを面倒に思う人も少なくないでしょう。
二つ目は、カヤックでは作ったサービスの売却ページを作ったりしていますが、こんな感じでサービスの売却を考えるのも一つの手だと思います。数年前だとライブドアなどに買収されるのがサービス開発者としての一つのゴールのように思っていましたが、現在は個人が作ったものを買ってくれる企業はあまり見かけなくなった気がしますね。
三つ目は、誰かにサービスの管理を譲ること。熱心なユーザであればボランティアでもいいのでサービスを手伝いたいと思ってくれるかもしれません。

どの方法でも言えることは、一人でやることには限界があるので誰か他の人を巻き込もうとすることがサービスの寿命を伸ばすことにつながるということです。
OSSの隆盛により、ソースコードのレベルでは他の人とコストを分かち合うことが一般的になってきましたが、サービスのレベルで他の人とコストを分かち合うことが今後一般的に見られるのかどうかが気になるところです。

MySQLのMyISAM形式のテーブルで｢Incorrect information in file: *.frm｣エラーが出たときの修復方法

先日ファイルシステムを復旧した際に、MySQLのあるテーブルでSELECT文などを実行すると以下のようなエラーが出るようになりました。

ERROR 1033 (HY000): Incorrect information in file: *.frm

今回の対象のテーブル形式はMyISAMだったのですが、エラーメッセージでググって見てもInnoDBの場合の記事ばかりで参考にならなくて困りました。偶然MySQLリファレンスのテーブルの修復方法で該当しそうな項目を発見し、うまく修復をすることができました。
滅多にない話のようですが、エラーメッセージと修復方法を結びつける記事がないので、後々に誰かの参考になるかもしれないので記事にしておきます。
MySQLのバージョンは5.0です。

frmファイルとは何か？

MySQLは一つのデータベースを一つのディレクトリとして扱います。
テーブルを作成すると、データベースのディレクトリ以下にテーブル名 + MYD、MYI、frmという拡張子を持つ3つのテーブルを構成するファイルが生成されます。

MYD	データ本体
MYI	インデックス
frm	テーブルの構造

frmファイルの修復

frmがテーブルの構造を持つファイルだとわかったので、同じテーブル構造を持つfrmファイルで上書きしてやれば修復ができそうなことが推測できます。
バックアップがある場合は、そこのfrmファイルをコピーして修復したいfrmファイルに上書きすればOKです。
バックアップがない場合、以下のような手順で行います。

1. 別のデータベースで同じ構造を持つテーブルのCREATE文を実行する
2. MySQLサーバを停止する
3. 別のデータベースのディレクトリ以下にあるfrmファイルを、直したいデータベースのディレクトリへ移動して上書きする*1

上記の手順を終えた後に、MySQLを起動して該当テーブルでSELECT文を実行するとエラーを出さずに実行できるはずです。frmのコピー元のテーブルはもう必要ないのでDROPしてください。
うまく動かないときは、frmファイルのパーミッションが適切でない場合があるので変更してみてください。
frmファイルを上書きするだけでうまくいくと思いますが、MYIファイルのコピーも必要な場合があるようです。その場合はREPAIR TABLEでインデックスを再生成してください。

参考

• http://dev.mysql.com/doc/refman/5.1/ja/repair.html
• http://d.hatena.ne.jp/koziy/20070911/1189472682（InnoDBの場合）

*1:Windowsの場合は"C:\Program Files\MySQL\MySQL Server 5.0\data"以下、Linuxの場合は"/var/lib/mysql"以下にデータベースのディレクトリがあります

｢薄い｣JavaのO/Rマッパーの紹介 - DbUtils、Persist、Butterfly Persistence

Hibernate、ActiveObjects、S2Dao、Apache Cayenne、iBATISなどORMフレームワークが群雄割拠状態なJavaですが、使い方を勉強したり設定ファイル書いたりするのが少し面倒かなと思っている人がいるかもしれません。
特にちょっとしたアプリケーションを作るならば、素のJDBCを使うのは嫌だけど、それに近い形で使えるORマッパーが欲しいと思うことがたびたびありました。
ということで以下の条件でJDBCを薄くラッピングしているJavaのライブラリを探して発見したものを紹介します。

• レコードをオブジェクトに自動的にマッピングしてくれる
• できるだけSQLを書く量を減らすことができる
• いざとなったら生SQLを書くことができる
• 導入が簡単である
• 依存ライブラリが少ない

以下に挿入、検索、更新、削除を実行するコードを書いています。
今回はDBがMySQLだったので、MySQL Connector/J 5.1を使っています。
http://dev.mysql.com/downloads/connector/j/5.1.html
今回使用するUserクラスとuserテーブルの定義は一番最後に書いてあります。

DbUtils

http://commons.apache.org/dbutils/
DbUtilsはApache Commonsプロジェクトの一つです。厳密に言うとDbUtilsはO/Rマッパーではない（と公式サイトで書いている）のですが、今回の要望に近いものなので取り上げました。
Connection、Statement、ResultSetを隠蔽してくれて、検索した結果をオブジェクトにマッピングしてくれます。
33KB程度のファイルサイズで、非常に軽いライブラリです。

import java.sql.Connection;
import java.sql.DriverManager;

import org.apache.commons.dbutils.QueryRunner;
import org.apache.commons.dbutils.ResultSetHandler;
import org.apache.commons.dbutils.handlers.BeanHandler;


public class DbUtilsTest {

	public static void main(String[] args) throws Exception {
		Class.forName("org.gjt.mm.mysql.Driver");
		String url = "jdbc:mysql:///test?useUnicode=true&characterEncoding=UTF-8";
		Connection con = DriverManager.getConnection(url, "名前", "パスワード");

		User user = new User();
		user.setName("Kishi");
		QueryRunner qr = new QueryRunner();
		//挿入
		qr.update(con, "INSERT INTO user(name) VALUES(?)", user.getName());
		//検索
		ResultSetHandler h = new BeanListHandler(User.class);
		List<User> users = (List)qr.query(con, "SELECT * FROM user WHERE id=?", 1, h); 
		for(User u : users)
			System.out.println(u.getId() + ":" + u.getName());
		user = users.get(0);
		//更新
		qr.update(con, "UPDATE user SET name = ? WHERE id = ?", 
				new String[]{"Shiki", Integer.toString(user.getId())});
		//削除
		qr.update(con, "DELETE FROM user WHERE id = ?", user.getId());
		con.close();
	}
}

QueryRunnerのコンストラクタにDataSourceを渡すこともできます。
Handlerを切り替えることで、返ってくる値をMapやBean単体に変更することができます。
JDBCに比べると大分マシになりましたが、更新系の処理が少し面倒です。

参考

• DbUtilsめも
• [ヅラド] Apache Jakarta Commons DbUtils を試す

Persist

http://code.google.com/p/persist/
Mr.Persisterというライブラリの情報を検索しているときに、｢http://cappuccino.jp/keisuken/logbook/20081026.html｣のコメントでmesoさんに紹介されているのを発見して知りました。
非常にシンプルなAPIなので、クイックスタートを見ればすぐに使い方がわかると思います。
何気にDbUtilsよりもファイルサイズが小さいですので、ソースコードに目を通すのが簡単です。
アノテーションやジェネリクスを使っているのでJava5以降でしか使えません。

import java.sql.Connection;
import java.sql.DriverManager;
import java.util.List;

import net.sf.persist.Persist;

public class PersistTest {
	public static void main(String[] args) throws Exception {
		Class.forName("org.gjt.mm.mysql.Driver");
		String url = "jdbc:mysql:///test?useUnicode=true&characterEncoding=UTF-8";
		Connection con = DriverManager.getConnection(url, "名前", "パスワード");

		User user = new User();
		user.setName("Kishi");
		
		Persist persist = new Persist(con);
		//挿入
		persist.insert(user);
		//検索
		List<User> users = persist.readList(User.class,
				"select * from users where id= ? ",
				1);
		for(User u : users)
			System.out.println(u.getId() + ":" + u.getName());
		user = users.get(0);
		//更新
		user.setName("Shiki");
		persist.update(user);
		//削除
		persist.delete(user);

		con.close();
	}
}

更新系でテーブル名をしていませんが、Userクラスの場合だと、userあるいはusersテーブルを自動的に推測してくれます。@Tableアノテーションで直接指定することもできます。
依存ライブラリはないのですが、Log4Jを入れるとデバッグ情報を表示させることができます。
ジェネリクスをうまく使っているので戻り値をキャストする必要がないところや簡単な更新系ならばSQLを書く必要がないのがよいです。
APIもいけてるので、今回取り上げたものでDB簡単なプログラムを作るのであれば個人的にはおすすめです。

Butterfly Persistence

http://butterfly.jenkov.com/persistence/index.html
Butterfly Persistenceは先ほど名前が挙がったMr.Persisterの後継です。
上記二つよりも扱う範囲が非常に広く、コネクションプーリングやトランザクションを扱うこともできるようです。

import java.sql.Connection;
import java.sql.DriverManager;
import java.util.List;

import com.jenkov.db.PersistenceManager;
import com.jenkov.db.itf.IDaos;


public class BetterflyPersitence {
	
	public static void main(String[] args) throws Exception{
		Class.forName("org.gjt.mm.mysql.Driver");
		String url = "jdbc:mysql:///test?useUnicode=true&characterEncoding=UTF-8";
		Connection con = DriverManager.getConnection(url, "名前", "パスワード");

		User user = new User();
		user.setName("Kishi");PersistenceManager manager = new PersistenceManager();
		
		IDaos daos = manager.createDaos(con);
		//挿入
		daos.getObjectDao().insert(user);
		//検索
		List<User> users = daos.getObjectDao().readList(User.class, "select * from user where id = ?", 1);
		for(User u : users)
			System.out.println(u.getId() + ":" + u.getName());
		user = users.get(0);
		//更新
		daos.getObjectDao().update(user);
		//削除
		daos.getObjectDao().delete(user);

	}
}

IDaosから取得するDaoの種類によってMapにマッピングすることもできます。
Persistと同じくテーブル名を推測してくれます。
Webアプリケーションなどを作るのであれば、今回紹介したライブラリの中だとこれを使うのがベターだと思います。
日本語の情報が増えてくるともっと利用が増えそうです。

終わりに

どのライブラリも柔軟性が高く学習・導入コストもそんなにかからないので時間があったら是非試してみてください。

おまけ：Userクラスとテーブルの定義

public class User {
	private static final long serialVersionUID = 1L;
	private int id;
	private String name;

	public int getId() {
		return id;
	}
	public void setId(int id) {
		this.id = id;
	}
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
}

CREATE TABLE `user` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(255) default NULL,
  PRIMARY KEY  (`id`)
)

グラフを扱うJavaライブラリ「Jung」の紹介 - Twitterのグラフ構造を視覚化

java-ja 第12回のLTで話そうと思ったのですが、出番がなかったので資料をブログで公開しておきます。
Jungは研究などでグラフ構造が出たときに、理解しやすくするために可視化するのに使っています。他にもいくつかグラフを扱うライブラリは存在していますが、日本語の資料があったのと拡張可能なことが多かったのでJungを結果的に使うようになりました。
以下はそのJungについての簡単な解説です。

Jungとは

Jungの正式名称はJava Universal Network/Graph Frameworkで、ネットワーク(グラフ) 構造の分析や視覚化を行うためのJavaのOSSライブラリです。グラフ理論、データマイニング、ソーシャルネットワーク分析のアルゴリズムを数多く実装しています。
安定バージョンは1.7.6で最新は2.0betaで、BSDライセンスで使用できます。
http://jung.sourceforge.net/

グラフって何？

ここでいうグラフは棒グラフや折れ線グラフではありません。
数学の一分野のグラフ理論におけるグラフは点（ノード）と辺（エッジ）の集合で構成され、現実のある要素の関係性を点と辺に抽象化してその性質の分析をするのに使います。
データ構造・アルゴリズムなどに広く応用されています。
有名な例：

• 巡回セールスマン問題
• 4色定理

グラフの例

Jungで簡単なグラフを作成する

Jungを使ってグラフを生成する手順は以下のようになります。

//グラフの作成
Graph graph = new UndirectedSparseGraph();
Vertex[] vertices = new Vertex[5];
// ノード作成
for (int i = 0; i < vertices.length; i++) {
　　　　vertices[i] = graph.addVertex(new UndirectedSparseVertex());
}
// エッジ作成
for (int i = 0; i < vertices.length; i++) {
    for (int j = 0; j < vertices.length; j++) {
        graph.addEdge(new UndirectedSparseEdge(vertices[i], vertices[j]));
    }
}
//描画ための処理
Layout layout = new CircleLayout(graph);
Renderer renderer = new PluggableRenderer();
VisualizationViewer viewer = new VisualizationViewer(layout, renderer);

VisualizationViewerはJPanelを継承しているので、JFrameにaddすれば簡単にGUIで表示することができます。

実行結果

グラフの種類

Jungのグラフは大きく分けると、方向を持つ有向グラフと、方向を持たない無向グラフに分かれます。
それぞれで使うノードやエッジにクラスや適応可能なアルゴリズムが異なるので注意が必要です。

Jungで作ったグラフ例：Twitterのリプライ関係のグラフ

フォロー関係より面白そうだったのでやってみました。今回のjava-jaの参加者でTwitterを使っている人のリプライ関係をTwitter検索（http://pcod.no-ip.org/yats/）から取得してきて、以下のような行列を生成して、グラフとしてJungで描画します。

	yoshiori	lalha	yamashiro
yoshiori	0	1	2
lalha	1	0	1
yamashiro	2	1	0

描画結果

リプライの多さでエッジの太さを変えています。

グラフレイアウト

グラフはノードの位置によって印象が大きく異なってくるのでどのようにノードを配置するかが非常に大切です。自動でノードを配置するアルゴリズムはばねモデルをはじめとして、さまざまなものがあります。JungではLayoutインターフェースを実装したクラスを切り替えることでレイアウトを変更することができます。
上記のリプライ関係のグラフ描画には自己組織化マップを使ったレイアウトを利用しています。
以下の図はjava-ja参加者のフォロー関係について円環レイアウトで表示したものです。

クリックしたノードにつながっているエッジを強調しています。青が片思いで赤が両思いを表しています。これだけ密なグラフだと普通に描画しても見づらいので、このような表示方法のほうがわかりやすいのではないかと思います。

関連

• グラフレイアウト

分析をしてみる

ただグラフを描画するだけだと他にもいくつかライブラリが存在するのですが、グラフの構造の分析を行うことができるのもJungの特徴です。

中心性を求める

ネットワークの特徴を知る上で、中心的なノード（＝そのグラフにおいて重要な位置の行為者）を求めることは重要です。中心性を求める方法はいくつか存在しますが、Jungでは媒介中心性、マルコフ中心性、PageRank、HITSなど多くの中心性を求めるアルゴリズムを利用可能です。
以下は与えられたグラフのPageRankを求めるソースコードです。

PageRank rank = new PageRank((DirectedGraph)graph, 0.5);
rank.evaluate();
List<NodeRanking> rankings = rank.getRankings();
rank.printRankings(true, true);

以下はリプライ関係のグラフのページランクを求めた結果です。

ID			Score
cactusman:	0.09556843685176082
yuripop:	0.08203343054586779
yamashiro:	0.05518103427914454
yoshiori:	0.05266528819081352
bose999:	0.041731677983314314

クラスタリング

ノードの類似性によって，複数の対象をグループ化する方法をクラスタリングと呼びます。
以下はBetweennessクラスタリング*1という手法を実行するソースコードです。

EdgeBetweennessClusterer clusterer = new EdgeBetweennessClusterer(10);
VertexClusterSet clusters = (VertexClusterSet) clusterer.extract(graph);
System.out.println("community count = " + clusters.size());

その他の機能

• ランダムグラフの生成
• ネットワーク距離や最大流の計算
• 統計解析

など。

Jung2 comming soon

近いうちにJava5に対応したJung2が出ます。
Genericsへの対応やアニメーション機能など多くの機能追加と改善が行われているらしいので期待です。

日本語で参考になるサイト

｢Jung-TECHSCORE-｣
http://www.techscore.com/tech/Others/Jung/index.html
｢Jung｣で日本語のページをぐぐったら一番上に出てくるはず。

｢Jungで相関行列のグラフ化｣
http://txqz.net/blog/2008/10/25/1155
Jungの実践的な使い方。

*1:媒介性の高いエッジを取り除いていく手法

JJUG Cross Community Conference 2008 Fall行ってきた

前日に別の勉強会に参加していた関係で前日の上京が無理だったので、午後からの参加になりました。
JJUGのページに載っていた地図に従って行けば開催地までたどり着けたのですが、その場所のどこの建物で実施されているのかが書いていなかったので若干迷いました。他のイベントもいくつか行われていたようで、それっぽい人についてそのまま違うイベントの会場に行くところでしたｗ

DOMパフォーマンスチューニング（id:amachang）

• javascriptは遅い遅いと言われるけど、ベンチマーク取るとPerlとかRubyより速くてPythonよりは遅いぐらいで十分速い
  • Javaを計測するのを忘れてた
• よく遅いと言われるDOM
• DOMをフェーズに4つの分けて考える
• 1. javascriptとコンポーネント（C++）との通信
  • XPConnectやCOMとの通信
  • 単純なオブジェクトへのプロパティアクセスの数十倍かかるが、気ににならない程度
  • JSとC++の通信は単純に.（ドット）の数を数えればよい
• 2. DOMノードの追加、値の変更
  • ノードに変更したフラグが立つとJSの処理が終わったあとに計算が行われる
  • JSの処理が終わった後なので単純なJS内でのベンチマークやプロファイリングツールが役に立たない
• 3. スタイルの再計算
  • .の数を減らすのが一番効果的
  • スタイルの再計算が行われるタイミング
    • 1. 変更フラグが立っているノードがあってJSが終了したとき
    • 2. offsetWidthなどの変更フラグが立っている状態でスタイルの再計算が必要な操作が行われたとき
  • 属性値やclassやidを変えたら兄弟や子孫も再計算される
  • styleプロパティを直接書き換えたら書き換えたプロタティを継承している要素だけ再計算される
  • styleプロパティはclassプロパティの書き換えより速い
• 4. レイアウトの再計算
  • 幅や高さや描画位置などの計算
  • どういうときにレイアウトの再計算が行われるかをWebkitのWebCoreRenderStyle::difを参照
• プロファイラを使うとJSで何の計算に時間がかかったかわかる
• WebKitが速い
• 最近ブラウザのC++のソースを見るようになって、ドキュメントを読むよりソースを信じるようになった

id:monjudohのエントリがわかりやすいです。
The Performance of Dynamic Site (id:amachang) - monjudoh’s diary
レイアウトの再計算されるタイミングなどについては全然知らなかったので非常に参考になりました。
amachangのjavascriptの話はamachangがどんどん細かい実装や挙動について詳しくなっていっているのがわかるので、毎回聞いていて面白いです。

ギークなお姉さんができるまで（べにぢょさん、purprin）

• purprinさん
  • http://www.escafrace.co.jp/
  • Webデザイナー
  • ○ぷるぷりん×ぱーぷりん
  • サイトやロゴの作成（パストラックなど）
  • 特急でXHTML＋CSSコーディングを行うサービス
  • 現場のプロから学ぶXHTML+CSSという本が出る
• べにぢょさん
  • DOMAIN ERROR
  • 好きな男性のタイプ：Geek!ギーク！ぎーく！
  • 好きな言葉：コンパイル
  • 好きなネットゲームが終了→自分で作ればいいじゃん→結構大変そう→来月作るって言ったけどごめん無理
  • その辺りからギークへの憧れ
  • ｢geekDB - geek Daisuki Benny's lovecall｣をやっている
• デザイナとの協業の話
  • 優秀なデザイナーには理由がある
    • なぜその色を選んだか？
    • 他の色では駄目な理由がある
  • purprinさん｢プログラマからガンガン突っ込んでもらったほうがよいものができる。｣

デザイナーさんの話を聞く機会がなかなかないので参考になりました。

『JavaからRubyへ』・アンド・ナウ（角谷さん、高井さん、和田さん）

• お金を持っている上司にどうやって新しい技術を説得するか
• Rubyが流行り始めた頃はPHPやってた人がもっとよいPHPを求めてRubyにやってきていた
• Java→Rubyはニッチでいいかも
• Rubyそのものが使いたいと言うよりもそれを使ってどう開発するかに興味があった
• DHHがやってる会社のフレームワークからRailsは出てきた→Javaの対抗ではない
• Railsは突然出てきたものではなくて、オブジェクト指向や達人プログラマなどの歴史の流れの延長から出た
• DHHはOO厨（もちろんいい意味で）
• フレームワークを作るときにSmalltalkが選択肢に入っているのがOO厨の証明*1
• PofEAAのActiveRecordパターンをそのままライブラリの名前にしちゃってる→OO厨極まれり
• Railsはバージョン管理や自動化など、『達人プログラマ』に書いてあることをそのまんま実装してみましたということを突き詰めていったフレームワーク
• JavaのEJBから軽いものを探していたらRubyを発見した
• 『JavaからRubyへ』は実際は『EJPからRailsへ』 = 新しい技術を組織へ
• 今のJavaは｢軽快なJava｣
• 2年前はXMLとかでつらい時期だった
• Javaの人の視点は、インディアン（Rails）発見→インディアンすげー→インディアン終わったという一方的な視点
• EJBとRailsはある範囲では重なるところがあるけど、もっと広い範囲ではぜんぜん違う領域のもの
• 背後の文化や歴史的な立ち位置を見ると面白いかも

パネルディスカッションのような形式だったのでメモしきれていなくて意味が違っているかもしれませんので、その際は適当に突っ込みをください。
今回のセッションの中では個人的に一番面白かった内容でした。
いくつか本が取り上げられていましたが、1冊1冊で見ると読んでいるものもありますが、歴史的な背景とかその辺の知識がないのでそういう視点を持って勉強してみたいと思いました。今回の話に出ていた書籍は高井さんのブログで紹介されています。（http://recompile.net/2008/10/jjug-ccc-2008-fall.html）

YET ANOTHER GREEN IT（角谷さん、和田さん）

• TDDとペアプロをすると持続可能なソフトウェア開発可能
• 和田さんと角谷さんとペアプロ
  • RESTfulな世界設計
  • Ruby+Emacs
  • ペアプロの雰囲気を
• WEB+DB 42号の世界時計をRESTで表現する話を今回はRubyで
• TDDの進め方は大きく二つになる
  • 大きくこうしたいというトップダウン
  • 部品部品を積み上げていくボトムアップ
• ペアプロで言語のデフォルトでできなさそうだったら、それを補うライブラリを調べる
• テストをグリーンにするために一時的にプログラムの挙動を書き換えることもある
• 落ちるのがわかってるときにはペンディングにする
• 実装方法でもめ始めたらとりあえず書く
• 設計と単体テストと機能テストと受け入れテストがペアプロに含まれている

大半はペアプロのセッションだったので、実際に見てみないと雰囲気が伝えきれないですね。
「ペアプロでもライブラリの調査などの時は別々にやったほうがいいのでは？」という質問をしたかったのですが質問時間がなかったので、懇親会が終わった時にid:t-wadaさんに聞いてみたところ、そういう時は別々にやるべきと教えていただきました。

ここで小腹がすいたので一旦会場を抜けました。

CubbyでRESTfulなWebアプリを（縣さん id:agt）

• CubbyはStrutsなどと同じレイヤのフレームワーク
• Ruby on Rails、Struts、Webwork2、Teeda、S2JSFなどのWebフレームワークの戦国時代
• 自分にとってぴったりのフレームワークがない
  • ○JSP2.0　×HTMLテンプレート
  • ○クールなURL　×拡張しつきURI
  • ○設定ファイルレス　×XML
  • ○名前がかわいい　×名前がかわいくない
• 最初は社内案件をさくさくこなすために作っていた
• Newsgraphyなど面白いサイトで使われ始めている
• みんなフレームワーク作ればいいと思う
  • ○○しかできないはエンジニアとして危険
  • 抽象化やデザインパターンを知ることができる
  • フレームワークに使われるのか乗りこなすのか
• HTMLのレンダリング結果となるべくマッチするようなカスタムタグに
• RESTfulなWebアプリケーションの美しさ
• URIに正規表現の指定も可能
• 現在はseasar2がないと動かない

名前だけは知っていたCubbyですが、初めてどういう設計なのかをしることができてよかったです。
｢みんなフレームワーク作ればいいと思う｣という発言には同意です。以前、小規模なフレームワークを作ったことがあるのですが、他のフレームワークの良いところを真似したり、自分で考えるわかりやすいと思う設計を考えてみるのは非常に勉強になりました。また、出来上がったフレームワークを見れば、そのときの自分の知識の限界を知ることができると思います。

エンジニアのためのキャッチコピーの作り方（岡崎さん）

• コピーライター養成講座を半年受講しての発表
• キャッチコピーの目的
  • 注意をひきつける
  • 商品やサービス、企業の良いイメージを植えつける
• キャッチコピーの作り方：表現を作りこむのではなくて、発見することを大事にする。
  • 作りこんでいくと押し付けがましくなってしまう
  • テンプレート化されたありきたりの内容に陥りがち。
• どういう風に発見するか
  1. ターゲットを設定する。
  2. ｢何を伝えたいのか｣整理する。
  3. とにかくいっぱい考える。（100個を目標に）
• 決める方法
  • 共感できるのはどれか？
  • インパクトのある表現はどれか？
  • 伝えたい内容と会っているか？

自前のサービスのリリース時などはキャッチコピーに悩むので、非常に参考になりました。
客観的な視点から見たキャッチコピーの陥りがちな罠にも触れられていてよかったです（25年後の磯野家はインパクトがあるが、なんの商品がわからないなど）。

100行ぐらいで書く分散検索エンジンHadoop＋Lucene（太田さん）

• PFIの人
• UNIX系の日本語入力環境を
• iPhoneでAAが見えるのは僕のおかげ
• 個人でも大規模な検索エンジンがさくっと作れる時代
• Lucene
  • Javaで作られたOSSの全文検索エンジン
  • 100万件程度のデータなら1台で余裕
• Hadoop
  • Nutchのサブプロジェクト
  • MapReduceやGFSのクローン
  • Yahoo,incでの実績だと4000ノードぐらいまでは運用可能
  • テラバイト規模のデータのソートなどが可能
• HadoopのMapではなにもせずに、ReducerでLuceneを使ってインデックス作成
• クエリを投げる部分はまた今度

HadoopとLuceneともに以前からちょくちょく触っていたので内容自体は目新しい話ではなかったですが、LuceneとHadoopの利用の仕方の説明としてわかりやすかったです。
ソースは｢http://kzk9.net/blog/2008/08/hadoop_lucene.html｣で公開している模様。
太田さんがHadoopについてCodeZineで記事を書いていますので、興味のある方はそちらも一緒に見ると参考になると思います。

java-jaプレゼンツ・第十一回 第2回チキチキ JJUG だよ全員集合 ライトニングトーク大会

上記3つのプレゼンと時間が被っていたので途中から。聞けなかった発表も感想を見ると面白そうだったので残念でした。

遠恋と何か（id:Ewigkeit）

札幌-東京間での遠距離恋愛について架空の人物の話。
飛行機の利用の話や手紙もいいよ泣いたよという話がありましたが超スピードだったのでメモりきれませんでした＞＜
いつかプレゼン資料が公開されることに期待しましょう。

【作ってみた】niconico4jを作ってみた【Java】　〜はじめてのライブラリ公開〜（id:celitan）

• ニコニコ動画APIで取得可能なデータ
  • 再生画面のほとんどのデータ
  • ランキングデータ
  • 動画詳細データ（要ログイン）
  • 時報データ
  • ニコニコニュースデータ
• 開発のきっかけ
  • 仕事中にうっかり初音ミク動画を見て上司にばれた
  • 仕事中にいじれるようにJavaで作った
• Rubyにも同じようなライブラリがあります

こういうライブラリはLLの特権のような感じがしていたので、Javaでもどんどん出てくるようになるとよいですね。

継承だろJK（露木さん）

• Django-jaの人
• テンプレートの重複について
• includeで共通化して読み込んでいてもincludeが重複している
• djangはテンプレートで継承可能
• Javaでもそろそろ作るべきだろ

includeがあればついつい妥協してしまう点ですが、やはりテンプレートも継承ができたほうがいいですよね。Wicketで継承ができたのはうれしかったです。

ActionScript3のススメ（富永さん）

• AIRでWassrクライアントを作ったりしてる
• JavaとFlexは親和性が非常に高い
• まだまだFlexに業務で使われる処理系のライブラリやフレームワークが不足している
• どんどんライブラリやフレームワークをもっと増やそう

AS3とJavaの親和性が高い話は実際に言語を触ってみると実感ができると思います。
｢Spark project｣がライブラリ等の公開は頑張っていますが、今後業務よりな方面のものも今後増えていくとFlexの業務利用も増えていくのかな。

懇親会

• 全体で60人以上集まったので、急遽java-jaは別の店へ
• java-jaでは呑み会にキャビアが出てくるのは常識
• おもむろにモンスターハンターが開始される

以前私がwicket-jaで話したのを覚えていてくれた人が結構いたので嬉しかったですね。
Twitterでしか知らない人とも話ができました。
次の日が休みじゃなかったので早めの解散でしたが、楽しかったです。

*1:OO厨はSmalltalk大好き

プログラマの実力を測る3つの指標

「こいつ･･･できる！」と思わせるプログラマにたまに会うのですが、その実力の評価の指標が必ずしも一つではないなー、というのを常々思っていました。この評価指標を言語化できないかと考えていましたが、はてなインターンに行ってたときにいろいろなタイプのプログラマに会って、この指標で評価可能なのではないかと思いついたものを3つ書いてみます。
私の観測範囲内から考えたことなので、「こんな指標もあるよ」という意見がありましたら是非是非ご教示ください。
ちなみに指標と言っても、数値化可能なものではなくて、この人はなんとなくこの指標の能力が高そうだなーと考えるのに使うためのものです。

指標1. アルゴリズム思考能力

数式からプログラムに落とし込む能力や最適なアルゴリズムを考えることができるかという指標。ちゃんとコンピュータサイエンスを学んできた人が強い指標になります。
この能力の高度な活用が求められる場面は実は少ないのではないかというのが私の感覚ですが、必要になった時に勉強して一朝一夕で身に付けられるものではないので、この指標が高い人は貴重だと思います。
ただ、この指標の評価が高い人がアルゴリズムをプログラムに落とし込むときに綺麗なコーディングが行えるかは別問題で、研究機関の人が書いたコードを読むと結構汚い書き方をしていることもままあります。*1

指標2. やりたいことを表現できる能力

やりたいことに対して、どんな書き方をするか、どんなライブラリを使うかといったときの自分なりのベストプラクティスをどれだけ持っているかという指標。
いわゆるtipsとして公開できる話が多いですが、Webにある玉石混交の中から適切なものを選択するのは容易ではありません。同じググるにしても、具体的に何をすればいいかわかっている人とそうでない人では効率に雲泥の差があります。
｢〜をやりたいと思ってるんですけど｣といった大抵の質問に対して即答できる人がこの指標が高い人です。この指標が高い人は、個人としての生産性が非常に高いことも特徴と言えるかもしれません。
指標1と同様に、この指標が高い人が必ずしも綺麗なコーディングができるわけではありません。

指標3. クールな設計をする能力

いわゆるほかの人から見てもわかりやすく拡張しやすいクラス設計などを行うことができるかという指標。言語を問わないものもあれば、その言語特有の設計方法があると思います。
漫然とコーディングを行っていても身につかない能力で、いい実装のソースコードリーディングや実践を通じて鍛えるものだと思います。
ブログの記事などでは書ききれないことが多いので、その人のソースコードを読んだりペアプロする機会がないとこの指標の正しい評価は難しいかもしれません。
アルゴリズムなどの高度な知識を持っているわけではありませんが、個人的には一緒に仕事をしたい人の指標です。*2

指標2に関してはいろいろな仕事をこなしていった結果能力が高まるかも知れませんが、指標1、3は意識的に勉強しないと鍛えるのは難しいです。

*1:以前アルゴリズムを研究にしている人は「速度の検証だけなので動けばいいという考え方で書いている」と言っていました。

*2:こういう人とペアプロをしたりするとものすごく参考になります。