JJUG Cross Community Conference 2008 Fall レポート3

Monday, October 20th, 2008 | Tech

DOMパフォーマンスチューニング入門

講師: amachang

JavaScript は遅い遅いといわれているけど
ベンチマーク取ってみると Rerl とか Ruby 並みの速度
遅いのは DOM 関する処理

DOM 関連の処理を分解してみると、

コンポーネントとの通信
DOMノードの追加
スタイルの再計算
レイアウトの再計算

となる。

1 コンポーネントとの通信
XPConnect や COM との通信
IE が特に遅い
無駄なプロパティアクセスを減らすと良い
変数に入れるなどして

2 DOMノードの追加
ノードに「変更されたフラグ」が立つ
「parent.appendChild(child)」とすると parent と child にフラグが立つ

（DOM に対する処理をすぐに実行するのではなくて後でまとめてやるためにマークを付けとく、みたいな感じですかね。）

3 スタイルの再計算
スタイルの再計算が行われるタイミングを把握しておく必要がある
スタイルの再計算はどんな時に行われるか

変更フラグが立っているノードがあるまま JavaScript が終了した
変更フラグが立っている状態でスタイルの再計算が必要な処理を行った
offsetWidth プロパティの値を取得したり

処理の順番を意識する必要がある
スタイルの再計算が行われるエレメントを意識する必要がある
子ノードとか下にあるエレメントとかもスタイルの再計算が行われる

4 レイアウトの再計算
要素の幅、高さ、位置の計算がここで行われる
激しく重い
→ 親ノードにも影響を及ぼすことがあるので
基本、スタイルの再計算に気をつけていればいい

プロファイラのデモ
各メソッドの実行時間とか、呼び出し回数なんかが簡単に調べられる
（safari 4 にはプロファイラが搭載されるらしい）

質疑応答
Q: 再計算のタイミングを知るには
A: Webkit をデバッガで起動。ログを仕込んだりして調べる。

Q: Webkit のソース解読 Tips
A: Webkit IDL ファイルを見ると良い

ギークなお姉さんができるまで

講師: べにぢょ (アルカーナ株式会社), purprin (エスカフラーチェLLC)

メモ取ってません。。
個人的にはあまり興味がわかない内容でした。
ただ、べにぢょさんがどんな人なのか見てみたかったんです。。
purprin さんの話がもうちょっと聞けたらよかったかもしれません。

『JavaからRubyへ』・アンド・ナウ

講師: 角谷信太郎 (株式会社永和システムマネジメント), 高井直人, 和田卓人

EJB から Rails の流れの裏にどのような歴史があるのか、というようなお話
ちょっと僕にはうまくまとめられる自信がないというか、以下の記事に書かれていることがそのものずばりな感じなので、そこから一部を引用してお茶を濁すことにします。

JJUG CCC 『JavaからRubyへ』・アンド・ナウを聞いてきました - yuum3のお仕事日記

新しい技術が次々と現れるIT業界ですが、新しい技術はある日突然に発明された訳ではなく、そこには歴史や必然があります。

Ruby on Rails も天才プログラマーの DHH がある日突然発明したわではなく、前世紀(^^)にオブジェクト指向というソフトウェアの革新があり、そのムーブメントに集まった人たちの中から、デザインパターンやリファクタリング、テスト駆動開発、アジャイル開発などの手法が生まれました。また、それを実線することを広めた「達人プログラマー」のなどの影響のもとに Ruby on Railsは生まれているのです。そういう意味でDHHは天才というようり歴史に学び、それを統合した秀才型の人だと思いました。

YET ANOTHER GREEN IT

講師: 和田卓人, 角谷信太郎 (株式会社永和システムマネジメント)

ライブコーディングのデモンストレーションをやっていました（なので文章に起こすの難しい。。）。

Java 界隈では以前から開発手法に関する議論が盛んでした。
ペアプログラミングとかテスト駆動開発その中から生まれた手法です。
（手法というか命名することによって広く認知されるようになったというか）

ペアプログラミング
ペアプログラミングとは、二人でプログラミングする手法です。
一台のマシンを使ってコーディングします。
なので同時には作業できません。
ペアプログラミングの何がいいかというと、仕様やプログラム等の情報を二人で共有できることです。
開発と平行してコードレビューも行える、というふうにもとらえることができます。
いいことずくめですね。
ただ、二人の相性が合ってないとやりづらいと思います。
あとは、それぞれが使っているエディタが違うとか、キー配列が違うとかいうことがあると面倒なことになります。
そんなにいいことずくめでもないですね。

テスト駆動開発
テスト駆動開発とは、実際に動くコードを書く前にテストコードをまず書いて、その後にそのテストに対応する実装部分のコーディングを行っていく手法です。
（わかりにくい文章ですみません）
例えば、あるライブラリを使おうと思った場合、そのライブラリのテストケースを作ります。
こういうメソッドを呼び出したらこういう結果が返ってくるだろう、という情報をテストケースとして残していく感じです。
テストケースを書くのはなかなか面倒ですが、ちゃんと作っておけば後で修正を行ったりする際に非常に役に立ちます。
（って、僕は最近あんまりテストケース作ってませんが。。）

Agileは現場に適用できるのか？　～オンナだらけのパネル・ディスカッション～

講師: 片山智咲子 (Java Edge), きたむら (日本XPユーザグループ), 柳本芙友子 (要求開発アライアンス)

パネル・ディスカッションってメモ取ったり記事にまとめたりするの難しいですね。。

なにかこう、釈然としないディスカッションでした。
アジャイルという言葉の意味が人によってまちまちだなぁ、とすごく思いました。

片山智咲子さんの意見が地に足がついている感じで良かったです。
アジャイルとかあまり気にせず、常に問題の本質をとらえようとしているように見えました。

kono@d4k

有限会社第四企画のプログラマー kono のブログ