Developers Summit(デブサミ) 2008

この歳になって初めて参加…とは言っても諸般の事情で申し込みは本日のみ。しかも午前中に出勤したせいで生 Joel を見逃したのが悔しい。何でも立ち見が出る程の大盛況だったとか。

マインドマップを午後いっぱい一所懸命取っていたせいで、久しぶりにペンダコが出来る位置が痛くなった。以下、マインドマップに書いたモノを元に記憶を再構成してみようと四苦八苦した結果を挙げておく。

【13-B-3】ふつうの Ruby プログラマに贈る Ruby プログラミング講座

Ruby プログラマじゃないけど聴いてきた。で、Ruby プログラマじゃなくても楽しかったし参考になった。

全体を通じての最大のヒットは「意図を明確にすべく適切な制御構造を使え」ところ。これ重要だと思う。アホな連中に「コーディング規約」とかを作らせると、真っ先に出てくるのが「解りにくくなるから if / while に限定汁」ってモノ。でも実際にはそうじゃないと思うんだよなぁ。until とかが読めないプログラマってそもそも使いモンにならんだろって思うし*1

プログラミングのツボの話
  • Ruby の protected は不要。
    • 使われているのはその 95% が間違い。Rails の中でも間違った使われ方してる。
    • Ruby の場合は継承先で private も見えるから使うトコないよ。
    • あるオブジェクトで、「同じクラスの他のインスタンスのフィールドを見たい。でも public にはしたいない」ってケースが protected の出番。「==」の定義などで使えばいい。
  • p と pp
    • p はデバッグ用。puts で stdout に出力。
    • pp は Pretty Print。import しなくちゃなんないけど強力。みんなもっと使え。
    • to_s と inspect の違いって話もあった希ガス
  • unless とか until の話
    • if や while で表現出来るからって unless や until を使わないというのは勿体ない。
    • unless や until のような制御構造はもっと貪欲に使え。但し redo 以外(redo はよく分かんないから)。
    • 様々な制御構造を適した場所で使うことによって、コードの意図を明確に示すことが出来る。
    • unless は「前提条件」の言明に最適。「この条件を満たさなければダメ」という意図を表せる。
    • until は「終了条件」の言明に最適。「この条件を充足したら終了」という意図を表せる。
    • もし「if や while で表現出来るんだから全部それを使うべき。なぜならそのほうがシロートにも分かりやすい」とか言うヤツがいたら、「全ての制御構造は goto で表現できるわこのボケ」と言え。
  • モジュールのネスト
    • 名前空間の分割に使う。Java の package みたいなイメージ。
    • 分け方は「アプリケーション名と同名」「その中のクラス」って感じ。
    • 最大でも 3 段まで。それ以上だとネストが深くなって読んでられない。っつーか美しくない。
  • ファイル名の話
    • 基本はクラス名の downcase。
    • ネスト時はクラス階層をディレクトリ階層と対応付けて。
    • Java じゃないんだから、どんどん複数のクラスを一つのファイルに突っ込んじゃえ。
  • Ruby は大クラス主義
    • 例えば Array は Queue / Stack / 配列を併呑してるよ。
    • でも大クラス主義でいいの? → いいんですよ!!
    • 喩えて言うなれば「monolithic kernel VS microkernel」。昔は microkernel のほうがエレガントに見えたけど、monolithic でもちゃんと綺麗に作れるじゃん。
    • クラスを細分化すると、クラス間の関係が複雑になって大変だよ。microkernel だってそうでしょ。
    • 1 クラスが複数の仕事を担当するのは問題ない。でも最終的に大切なのはバランス。
実装の裏の話
  • Visitor パターンがウザい話

「動物が鳴く」場合、通常は「動物」のサブクラス「豚」「牛」「鳥」を作って、「動物」クラスのメソッド「鳴く」を各サブクラスがオーバーライドする。これがポリモーフィズムによる対応。でもこの場合、「鳴く」という概念が複数のクラスに散らばって悲しい。

これを避ける手段として Visitor パターンがあるけど、Visitor パターンは純粋に実装するのが鬱陶しい。そこで send を使って…っていう話。Ruby プログラマでない私には細かいとこまでマインドマップに書ききれなかった(っつーかマインドマップ上のキーワードから記憶を再構成出来なかった)。

  • 1.8.x と 1.9.x の差をリフレクションで乗り越えるような話

1.9.0 で様々な非互換性が出たけど、それをどう乗り越えるか、という話。単純に対応しないっていうのは簡単だけど、それじゃあまりにも弱い。

例えば send は 1.9.0 で仕様が変わったので、これまで使われていた「private のメソッドを send で呼ぶ」っていうのが使えなくなった(代わりに funcall を使う)。それを乗り越える一例として「alias funcall send」ってすれば良くね? というオチだった気が。っつーか Ruby でも funcall なんだなー、って変なトコロで感じ入った私。いやだからホントーに Ruby よく知らねーんですよ。

もう一つは動的にメソッドを追加する方法。「もし send がなければ send を実装汁」とかそんな感じだったと思う(ここもマインドマップから記憶を再構築出来ない部分)。オープンクラスの真価爆発って感じだなぁ。

このセッションと殆ど関係ない、どうでもいい話

セッション冒頭に出た「Korn Shell で 2 万行」、その LOC はちょっとスゲぇ。

古いトコだとアホみたいに csh とか使うけど、私自身が一番好きなシェルは今でも ksh で、出来ればシェルスクリプトksh で書きたい。勿論 bash でもいいけど、原初体験として「ksh サイコー」ってのが刷り込まれているので、やっぱり ksh がいい。啓学出版が倒れたせいで絶版になっちゃった Korn の『Kornシェル―コマンド言語とプログラミング言語』も後生大事に持ってるし、この本からは実際に色んなことを学んだなー、って。でも今じゃ bash でばっかりだから、ksh もちょっと忘れちゃってるかも。

【13-E-4】継続的インテグレーションとテストによるソフトウェアリリースの迅速化

まー、アレですよベンダセッションですよ。CI の話でしたが、正直なところちょっと通り一遍な話だよね…って、数年振りに再会した知人と話してた。

  • What is CI?
    • CI server builds whole software.
    • 開発者が早期に問題を解決出来るように、CI サーバからメールを送れ。
    • CI のタイプとして「開発者によるマニュアルの CI」と「自動化された CI」。もちろん自動化汁。
    • CI のゴールは「failure によるコストを下げること」。
    • CI によってチェックインの失敗を検出しろ。
    • CI でシステムテストインストーラの構築、デプロイメントまでやれ。
  • ベストプラクティス
    • テストに投資せよ。決して実現出来ない「完璧なテスト」よりも、「不完全なテスト」を頻繁に実行するほうが良い。
    • quick なビルドの実現。コンパイルと高速なテストで 10 分以内に開発者に問題を通知出来るようにせよ。
    • CI によるシステムテストでは、1 時間以内に結果をフィードバックせよ。
    • QA に対して継続的なリリースが出来るようにせよ。
    • visual feedback: Lava lamp(information radiator) + eXtreme feedback monitor.
    • personal feedback: CruiseControlFirefox プラグインやデスクトップウィジェットを使え。

【13-D-5】次世代ウェブフレームワークの幕開け〜ステートフルはじめました/君が僕を望むなら僕は君を忘れない〜

「ステートフルな Web フレームワークというものの存在を押さえておけ」及び「物事は抽象的に理解せよ」というメッセージ。個別のフレームワークについての詳細な説明はなかったけど、参加者の胸にはそのメッセージはしっかりと刻み込まれたと思う。

Wicket の話がちょっと熱かった。Wicket はいいと思うし結構気にはなってるんだけど、実際にチームで使おうと思うと教育や何やらの部分でものすごい不安。特にチームのメンバのレベルが担保されない場合だと。

セッション中の質問では予想通り「そんなメモリをガンガン使うようなモノなんて怖くて使えないよ」的な質問が飛んでたけど、実際にはセッションにバインドするオブジェクトなんてたかが知れているから、そんなに気にする必要はないよってフォローが入ってた。個人的には「2GB のマシンで運用してたけど問題なかった」という体験談が有り難かった。でもセッションリプリケーションはちょっと心配だよなー(「そんなにコストかかんないよ」って言ってたけど、コスト高いと思うんだよなぁ)。

  • HTTP はステートレスだけど Web アプリケーションはステートフルだよ
    • HTTP はプロトコルレベルではステートレス。
    • でも Web アプリケーションとしては擬似的にステートフル。
    • 「ステートフル」の実現方法としては cookie、GET パラメータ / POST パラメータ、独自のヘッダを準備など、様々な方法があるよ。
  • 実際の Web アプリケーションでは?
    • ステートレスで全部やるのは辛いよね(特に利用者側の利便を考えると)。
    • Web フレームワークプロトコルの上に薄い層を作ってステートフルを実現してるよ。
    • でもセッションへデータを設定するなんて本来は不要な作業のはず。
    • この「本来不要」っていうのって、メモリ管理とか GC とかの局面で出てこなかった? つまりステートフルへの移行は正常な進化なんだよ。
    • これまでのフレームワークは色々と面倒が多かった。例えば…
      • セキュリティ担保のためのヴァリデーション(ミスがあると大変なことに)。
      • 「戻る」ボタンへの対応。
      • double submit(所謂「二度押し」)。
      • 複数ウィンドウを開かれた場合の対応。
      • F5 連打(リロード)。
    • でもステートフルな Web アプリケーションフレームワークなら、こんなの最初から全部対応してますから。
    • つまり上記のようなアレコレを開発者がいちいち気にしなくたって、「フツーに書けばフツーに動く」んですよ。
  • JBoss Seam
    • JBoss が初めて作った Web アプリケーションフレームワーク
    • Gavin King が lead だよ。
    • JSR-299(WebBeans)として JEE にも入るよ。
    • JSFEJB 3 の glue。
    • JSF って所詮はまだ JSP だよね。
    • EJB は 3 になってから使いやすくなったよね。
  • Wicket
    • Swing like に Web アプリケーションが作れちゃう。
    • View と Controller がその対象範囲。
    • 来日時に Gavin King に「Wicket どうよ」って話したら、飲み会の席で「Wicket なんて View しかステートフルにしてねーじゃん」って dis られた。
    • でも WicketSeam と組み合わせた事例とかもあるよ。他と組み合わせやすいのが Wicket の魅力の一つかも。
    • XHTMLJava だけで作れますから。っつーかむしろ Java だけで作れますから。
  • ステートフルな Web フレームワークのコストとか弱点とか
    • まず学習コストがかかるよ。
    • 当然ながらメモリは喰うよ。
    • 負荷分散とかは注意が必要だよ。
    • まだ数が少ないから、選択肢そのものが少ないよ。
    • っつーかセッションをガンガン使っていいんですか? → いいんですよ!!
      • 今だとメモリも安いよ。開発費のほうが高いよ。
      • メモリ 32GB くらい乗っけたマシン使ったほうがいいよ。
      • ステートレスで頑張ってアレコレするほうが開発コスト掛かるよ。
      • お前ら Gavin King よりいいコード書けるってか? だったらステートフルのほうが安全だし安上がりだよ。
    • セッションを使うことによる問題の一つは「セッションの消し忘れ」だけど、そこをフレームワークが担保してくれるよ。
    • Wicket を使った ASP ではアプリケーションサーバマシンのメモリは 2GB しかなかったけど、それでも大きな問題はなかったよ。
  • じゃあいつ移行するよ
    • ステートフルな Web アプリケーションフレームワークはまだ枯れていない。だから基幹システムなどでいきなり使うのはリスクが高い。
    • 移行して OK なシステムなら移行しちゃえば。
    • Rails はある意味「枯れた技術の集大成」。対してステートフルな Web アプリケーションフレームワークはまだまだ枯れていない。

【13-E-7】CodeZineスペシャルセッション みんなまとめて面倒見よう〜真のDBエンジニアになるために必要なこと〜

「どうせみんな Matz の話聴きに行ったんだろー」って勘ぐっちゃいたくなるほど空席が目立ったセッションだったけど、個人的には本日のセッションの中で一番興味深く、また一番勇気付けられたセッションだった。確かにこの時間帯って裏番組がどれも強力だったけどね。

良かったっていうのは、私自身の中のもやもやの一つに光明が見えたこと。私自身が後輩を指導出来るテーマなんてそんなに多くないけど、とりあえず RDB についてはそれなりに何とかなるんじゃないかなー、とか思っている。でも、RDB を支える考え方をどうやって理解してもらうか、っていうのには色々と悩まされるトコロが多かった。

前回のプロジェクトでは「神」とまで呼ばれたベテラン DA / DBA(このセッションで言うトコの「上級者」ですな) に参加して頂いたお陰で彼の持つ様々な知見、そして「集合として考えろ」という大きなテーマもメンバに周知出来たと思う。私自身も「『Database in Depth: Relational Theory for Practitioners』嫁」*2、「『プログラマのためのSQL 第2版』嫁」「『アート・オブ・SQL ―パフォーマンスを引き出すSQLプログラミング手法 (Theory in practice)』嫁」*3ってさんざん周りに言ってきた。でも「RDB を支える考え方」そのものについては、具体的にどうやって指導していけばいいんだろう、っつーか皮膚感覚で実感してもらうにはどうすればいいんだろう…っていうのがやっぱり悩みのタネだった。でも今回のセッションで、手続き型に慣れた人間に対するモノの伝え方のヒントが得られたような気がする。

っつーか、『SQLパズル 第2版~プログラミングが変わる書き方/考え方』を持ってくるのを忘れた自分のアホさに腹が立つ。

以下、配布資料になかった内容をメインに。

  • 日本の DB 界
    • 上級者(RDB が日本に紹介されてからずっと使っていたような人々)は多い。
    • 初級者は毎年一定数入ってくる。
    • 問題は、中級者の層が薄いこと。
    • ベテランは今後どんどん減っていく(あと 10 年もすると引退などでいなくなってしまう)。
    • 「花瓶の背が縮む」現象が起こる。「団塊の世代の退職による技術継承の断絶」が言われているが、DB 界ではそれより酷いことが起こることになる。
    • DB の存在意義は今後もっと大きくなる。それは我々の業界だけでなく、社会全体として。
    • しかし日本の DB エンジニアのレベルは低い。
    • 中級者を伸ばしていくための方法論が確立されていない。上級者向けの書籍は最近様々なものが出版されるようになった(Date や Selko など)し、初級者向けの書籍には様々なものがある。しかし中級者向けの書籍がない。
    • 今回上梓した書籍は、中級者を伸ばすことを目的にしたもの。
  • SQL の原理
    • 集合論と述語論理。どちらも普通に使われる概念なのに、きちんと学んだことがないために RDB の原理を知らない人が多い。手続き型から入ったエンジニアには、RDBSQL は混乱を来す存在になってしまっている。
    • 最近はこの 2 つ真正面から教えるのではなく、手続き型にもある概念を使って教えることにした。つまり…
      • 「述語論理」は「(特性)関数」。特性関数とは評価結果が 1 又は 0 となるもの。
      • 「集合」は「特性関数」によって決まる特性範囲。
  • 考え方
    • 集合の組み替え。
    • 木構造は、手続き型なら pointer chain として考える。RDB でも無理矢理このように表現することが普通だった。
    • しかし近年ではノードを集合にした「nested set」という考え方もある。XML の利用範囲が広まったためか、海外ではこの手の要望が増えた。日本ではまだ広く知られてないけどね。
    • SQL に手続き型の考えを持ち込む「ハイブリッド」な考え方が今後は増えてきそう。
    • スライドにあったテーマ: 学生 ID がないと失敗するケースがあるよ。何故だか考えてみてね。
  • アメリカ主導のアレがアレな限り DB はアレだよ
    • アメリカ人はマーケティングが大好き。
    • アメリカ人はデータマイニングも大好き。
    • 意思決定にはデータを統計分析した結果が必須になっている。そのためには大量のデータが必要。
    • 「人間の判断よりもデータに基づく分析」が重視されるようになってきた昨今。この流れに反する人間は、産業革命に反対した人間みたいなものだよ…とまで言う見方も出てきている。
    • 「数値より判断を重視する」というのは勇気を必要とすること。データに基づく分析結果を重視するのは、ある意味逃げではないか…という批判もあるよ。
    • いずれにせよ、日本では幸か不幸かまだこういう局面には入っていない。
    • 但し、米国主導のビジネスが大きな力を持つ限り、DB の重要性はこれからも大きくなる。それが良いかどうかは別にしても、まずは花瓶を何とかする必要があるよ。

セッションの後で翔泳社のブースに言ったら、『達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)』が一冊だけ残っていたので速攻 get。その前に見たときはなかったような気がしたのになぁ…。帰りの電車の中で少し読んだけど、内容も平易かつ具体的、しかも興味深いテーマが様々取り上げられていて、万人にお薦め出来る書籍になってる。must 買え。

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

*1:関係ないけど、Java が「?」演算子を残してくれたのは本当に英断だったといつも思う。

*2:邦訳はご存知『データベース実践講義 ―エンジニアのためのリレーショナル理論 (THEORY/IN/PRACTICE)』。っつーか日本語訳出るなんて予想してなかったから原著で買っちゃったよウワァァン

*3:台湾では日本より先に『SQL 之技芸』ってタイトルで出版されていて正直ショックだった