JJUG Cross Community Conference 2008 Fall行ってきた
前日に別の勉強会に参加していた関係で前日の上京が無理だったので、午後からの参加になりました。
JJUGのページに載っていた地図に従って行けば開催地までたどり着けたのですが、その場所のどこの建物で実施されているのかが書いていなかったので若干迷いました。他のイベントもいくつか行われていたようで、それっぽい人についてそのまま違うイベントの会場に行くところでしたw
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さん
- べにぢょさん
- 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とペアプロをすると持続可能なソフトウェア開発可能
- 和田さんと角谷さんとペアプロ
- WEB+DB 42号の世界時計をRESTで表現する話を今回はRubyで
- TDDの進め方は大きく二つになる
- ペアプロで言語のデフォルトでできなさそうだったら、それを補うライブラリを調べる
- テストをグリーンにするために一時的にプログラムの挙動を書き換えることもある
- 落ちるのがわかってるときにはペンディングにする
- 実装方法でもめ始めたらとりあえず書く
- 設計と単体テストと機能テストと受け入れテストがペアプロに含まれている
大半はペアプロのセッションだったので、実際に見てみないと雰囲気が伝えきれないですね。
「ペアプロでもライブラリの調査などの時は別々にやったほうがいいのでは?」という質問をしたかったのですが質問時間がなかったので、懇親会が終わった時にid:t-wadaさんに聞いてみたところ、そういう時は別々にやるべきと教えていただきました。
ここで小腹がすいたので一旦会場を抜けました。
CubbyでRESTfulなWebアプリを(縣さん id:agt)
- CubbyはStrutsなどと同じレイヤのフレームワーク
- Ruby on Rails、Struts、Webwork2、Teeda、S2JSFなどのWebフレームワークの戦国時代
- 自分にとってぴったりのフレームワークがない
- 最初は社内案件をさくさくこなすために作っていた
- Newsgraphyなど面白いサイトで使われ始めている
- みんなフレームワーク作ればいいと思う
- HTMLのレンダリング結果となるべくマッチするようなカスタムタグに
- RESTfulなWebアプリケーションの美しさ
- URIに正規表現の指定も可能
- 現在はseasar2がないと動かない
名前だけは知っていたCubbyですが、初めてどういう設計なのかをしることができてよかったです。
「みんなフレームワーク作ればいいと思う」という発言には同意です。以前、小規模なフレームワークを作ったことがあるのですが、他のフレームワークの良いところを真似したり、自分で考えるわかりやすいと思う設計を考えてみるのは非常に勉強になりました。また、出来上がったフレームワークを見れば、そのときの自分の知識の限界を知ることができると思います。
エンジニアのためのキャッチコピーの作り方(岡崎さん)
- コピーライター養成講座を半年受講しての発表
- キャッチコピーの目的
- 注意をひきつける
- 商品やサービス、企業の良いイメージを植えつける
- キャッチコピーの作り方:表現を作りこむのではなくて、発見することを大事にする。
- 作りこんでいくと押し付けがましくなってしまう
- テンプレート化されたありきたりの内容に陥りがち。
- どういう風に発見するか
- ターゲットを設定する。
- 「何を伝えたいのか」整理する。
- とにかくいっぱい考える。(100個を目標に)
- 決める方法
- 共感できるのはどれか?
- インパクトのある表現はどれか?
- 伝えたい内容と会っているか?
自前のサービスのリリース時などはキャッチコピーに悩むので、非常に参考になりました。
客観的な視点から見たキャッチコピーの陥りがちな罠にも触れられていてよかったです(25年後の磯野家はインパクトがあるが、なんの商品がわからないなど)。
100行ぐらいで書く分散検索エンジンHadoop+Lucene(太田さん)
- PFIの人
- UNIX系の日本語入力環境を
- iPhoneでAAが見えるのは僕のおかげ
- 個人でも大規模な検索エンジンがさくっと作れる時代
- Lucene
- 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で取得可能なデータ
- 再生画面のほとんどのデータ
- ランキングデータ
- 動画詳細データ(要ログイン)
- 時報データ
- ニコニコニュースデータ
- 開発のきっかけ
- Rubyにも同じようなライブラリがあります
こういうライブラリはLLの特権のような感じがしていたので、Javaでもどんどん出てくるようになるとよいですね。