パタヘネ? いや、ヘネパタか
本日翔泳社の方から実際にお話を伺って知ったのだが、パタヘネ第 4 版の邦訳が今月出版されるとのこと。これは何があっても買わなくちゃですよ奥さん!!
最近の IT Architects Archive シリーズは本当に凄い。日本じゃ採算取れないんじゃないの? 本当にこんな翻訳出しちゃって大丈夫なの?(商業印刷としてちゃんと儲けが出るの?)ってこっちが心配になるような書籍がバンバン出ますよ。
私達に出来ることは出して頂けることに感謝をしつつ、このような良書を少しでも実際に購入して「日本でもこういう書籍を出しても大丈夫」と出版社に確信して貰えるような環境を作ることだけしかない。でも、それこそが世の中を変える一歩になるんだと信じたい。翔泳社ガンガレ!!
![コンピュータアーキテクチャ 定量的アプローチ 第4版 (IT Architects’ Archive) コンピュータアーキテクチャ 定量的アプローチ 第4版 (IT Architects’ Archive)](https://images-fe.ssl-images-amazon.com/images/I/51DEX2TC20L._SL160_.jpg)
コンピュータアーキテクチャ 定量的アプローチ 第4版 (IT Architects’ Archive)
- 作者: John L. Hennessy,ジョン・L・ヘネシー,デイビッド・A・パターソン,David A. Patterson,中條拓伯,吉瀬謙二,佐藤寿倫,天野英晴
- 出版社/メーカー: 翔泳社
- 発売日: 2008/02/21
- メディア: 大型本
- 購入: 6人 クリック: 207回
- この商品を含むブログ (26件) を見る
Developers Summit(デブサミ) 2008
この歳になって初めて参加…とは言っても諸般の事情で申し込みは本日のみ。しかも午前中に出勤したせいで生 Joel を見逃したのが悔しい。何でも立ち見が出る程の大盛況だったとか。
マインドマップを午後いっぱい一所懸命取っていたせいで、久しぶりにペンダコが出来る位置が痛くなった。以下、マインドマップに書いたモノを元に記憶を再構成してみようと四苦八苦した結果を挙げておく。
【13-B-3】ふつうの Ruby プログラマに贈る Ruby プログラミング講座
Ruby プログラマじゃないけど聴いてきた。で、Ruby プログラマじゃなくても楽しかったし参考になった。
全体を通じての最大のヒットは「意図を明確にすべく適切な制御構造を使え」ところ。これ重要だと思う。アホな連中に「コーディング規約」とかを作らせると、真っ先に出てくるのが「解りにくくなるから if / while に限定汁」ってモノ。でも実際にはそうじゃないと思うんだよなぁ。until とかが読めないプログラマってそもそも使いモンにならんだろって思うし*1。
プログラミングのツボの話
- Ruby の protected は不要。
- p と pp
- unless とか until の話
- if や while で表現出来るからって unless や until を使わないというのは勿体ない。
- unless や until のような制御構造はもっと貪欲に使え。但し redo 以外(redo はよく分かんないから)。
- 様々な制御構造を適した場所で使うことによって、コードの意図を明確に示すことが出来る。。
- unless は「前提条件」の言明に最適。「この条件を満たさなければダメ」という意図を表せる。
- until は「終了条件」の言明に最適。「この条件を充足したら終了」という意図を表せる。
- もし「if や while で表現出来るんだから全部それを使うべき。なぜならそのほうがシロートにも分かりやすい」とか言うヤツがいたら、「全ての制御構造は goto で表現できるわこのボケ」と言え。
- モジュールのネスト
- ファイル名の話
- 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?
- ベストプラクティス
- テストに投資せよ。決して実現出来ない「完璧なテスト」よりも、「不完全なテスト」を頻繁に実行するほうが良い。
- quick なビルドの実現。コンパイルと高速なテストで 10 分以内に開発者に問題を通知出来るようにせよ。
- CI によるシステムテストでは、1 時間以内に結果をフィードバックせよ。
- QA に対して継続的なリリースが出来るようにせよ。
- visual feedback: Lava lamp(information radiator) + eXtreme feedback monitor.
- personal feedback: CruiseControl の Firefox プラグインやデスクトップウィジェットを使え。
- ツールセット
- CruiseControl
- Agitor の AgitorOne
【13-D-5】次世代ウェブフレームワークの幕開け〜ステートフルはじめました/君が僕を望むなら僕は君を忘れない〜
「ステートフルな Web フレームワークというものの存在を押さえておけ」及び「物事は抽象的に理解せよ」というメッセージ。個別のフレームワークについての詳細な説明はなかったけど、参加者の胸にはそのメッセージはしっかりと刻み込まれたと思う。
Wicket の話がちょっと熱かった。Wicket はいいと思うし結構気にはなってるんだけど、実際にチームで使おうと思うと教育や何やらの部分でものすごい不安。特にチームのメンバのレベルが担保されない場合だと。
セッション中の質問では予想通り「そんなメモリをガンガン使うようなモノなんて怖くて使えないよ」的な質問が飛んでたけど、実際にはセッションにバインドするオブジェクトなんてたかが知れているから、そんなに気にする必要はないよってフォローが入ってた。個人的には「2GB のマシンで運用してたけど問題なかった」という体験談が有り難かった。でもセッションリプリケーションはちょっと心配だよなー(「そんなにコストかかんないよ」って言ってたけど、コスト高いと思うんだよなぁ)。
- HTTP はステートレスだけど Web アプリケーションはステートフルだよ
- 実際の Web アプリケーションでは?
- ステートレスで全部やるのは辛いよね(特に利用者側の利便を考えると)。
- Web フレームワークはプロトコルの上に薄い層を作ってステートフルを実現してるよ。
- でもセッションへデータを設定するなんて本来は不要な作業のはず。
- この「本来不要」っていうのって、メモリ管理とか GC とかの局面で出てこなかった? つまりステートフルへの移行は正常な進化なんだよ。
- これまでのフレームワークは色々と面倒が多かった。例えば…
- セキュリティ担保のためのヴァリデーション(ミスがあると大変なことに)。
- 「戻る」ボタンへの対応。
- double submit(所謂「二度押し」)。
- 複数ウィンドウを開かれた場合の対応。
- F5 連打(リロード)。
- でもステートフルな Web アプリケーションフレームワークなら、こんなの最初から全部対応してますから。
- つまり上記のようなアレコレを開発者がいちいち気にしなくたって、「フツーに書けばフツーに動く」んですよ。
- ステートフルな Web フレームワークのコストとか弱点とか
- まず学習コストがかかるよ。
- 当然ながらメモリは喰うよ。
- 負荷分散とかは注意が必要だよ。
- まだ数が少ないから、選択肢そのものが少ないよ。
- っつーかセッションをガンガン使っていいんですか? → いいんですよ!!
- 今だとメモリも安いよ。開発費のほうが高いよ。
- メモリ 32GB くらい乗っけたマシン使ったほうがいいよ。
- ステートレスで頑張ってアレコレするほうが開発コスト掛かるよ。
- お前ら Gavin King よりいいコード書けるってか? だったらステートフルのほうが安全だし安上がりだよ。
- セッションを使うことによる問題の一つは「セッションの消し忘れ」だけど、そこをフレームワークが担保してくれるよ。
- Wicket を使った ASP ではアプリケーションサーバマシンのメモリは 2GB しかなかったけど、それでも大きな問題はなかったよ。
【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 の原理
- 考え方
- アメリカ主導のアレがアレな限り DB はアレだよ
- アメリカ人はマーケティングが大好き。
- アメリカ人はデータマイニングも大好き。
- 意思決定にはデータを統計分析した結果が必須になっている。そのためには大量のデータが必要。
- 「人間の判断よりもデータに基づく分析」が重視されるようになってきた昨今。この流れに反する人間は、産業革命に反対した人間みたいなものだよ…とまで言う見方も出てきている。
- 「数値より判断を重視する」というのは勇気を必要とすること。データに基づく分析結果を重視するのは、ある意味逃げではないか…という批判もあるよ。
- いずれにせよ、日本では幸か不幸かまだこういう局面には入っていない。
- 但し、米国主導のビジネスが大きな力を持つ限り、DB の重要性はこれからも大きくなる。それが良いかどうかは別にしても、まずは花瓶を何とかする必要があるよ。
セッションの後で翔泳社のブースに言ったら、『達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)』が一冊だけ残っていたので速攻 get。その前に見たときはなかったような気がしたのになぁ…。帰りの電車の中で少し読んだけど、内容も平易かつ具体的、しかも興味深いテーマが様々取り上げられていて、万人にお薦め出来る書籍になってる。must 買え。
![達人に学ぶ SQL徹底指南書 (CodeZine BOOKS) 達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)](https://images-fe.ssl-images-amazon.com/images/I/51CGypjLrvL._SL160_.jpg)
達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)
- 作者: ミック
- 出版社/メーカー: 翔泳社
- 発売日: 2008/02/07
- メディア: 単行本(ソフトカバー)
- 購入: 54人 クリック: 1,004回
- この商品を含むブログ (78件) を見る
今日の頂き物
書籍を購入したら、オライリー・ジャパン様から『Unixバックアップ&リカバリ』の表紙をデザインしたバッグを頂きました。夫婦揃ってガビアル大好きな我が家には最高のプレゼントです。かわいい。早速妻にあげました。
![Unixバックアップ&リカバリ Unixバックアップ&リカバリ](https://images-fe.ssl-images-amazon.com/images/I/51HBFNYT4EL._SL160_.jpg)
- 作者: W. Curtis Preston,W・カーティス・プレストン,田和勝,長原宏治
- 出版社/メーカー: オライリー・ジャパン
- 発売日: 2001/08/16
- メディア: 単行本
- 購入: 1人 クリック: 45回
- この商品を含むブログ (15件) を見る
原著 1999 年、邦訳 2001 年のかなり古い書籍ですが、システム管理者を名乗るなら本書は是非一度手に取って頂きたい書籍の一冊だと思う。っつーかシステム管理者を名乗ってて dump / restore や cpio を知らないなんてあり得ないだろ…って思うのは、私が古い人間だからか? 技術的な説明もさることながら、バックアップにおけるリスク分析やバックアップの実装 / テストの説明は、今でも十分に有効な内容のはず。
個人的には
- dump の細かい解説
- 「13.5 データベース構造」
あたりもお気に入り。