著作一覧 |
久々に技術ネタとエモネタのバランスが取れた良い会議だった。
イギリスでの労働ビザの話とか興味深い話題を盛り込んだ海外在留邦人のRubyライフを語る@makoto_inoueに始まり、@mrknの1.8から1.9への移行話の、ブロック変数にインスタンス変数を指定するやつとか、モンキーパッチをバージョン別に保持して初期化時に当てまくるやつでぐぐっと引っ張って、@nari3の根源的衝動の探求話で締める構成も見事だ。(asakusa.rb ninjaの構成がバランスしているのかも)
@takeshinodaのタクシーの呼び出しシステムの話は松江のトークが良かったとかで@kakutani肝入りの招待講演だったらしいけど、本質的な点を突いていて、なるほどこれは肝も入るなという講演。
少し考えれば、というよりも考えなくてもプログラムを作ればすぐわかるが、プログラムにバグがあるのは当たり前のことだ。ところが、なぜかそんな当たり前のことが理解できないプログラマが確かにいる。見かける。
WIN32サブシステムだろうがVBVMだろうがJDKだろうがLIBCだろうがLinux Kernelだろうがプログラムだ。したがって、これらにはバグがある。ところが、なぜかそれが見えなくなってしまうらしい。
そういう不思議な状態の人たちが、Ruby on Railsでアプリケーションを構築していくうちに、その当たり前のことに気付くようになり、当然のように直すようになるというのが要点だった。(オープンだからソースを直せるというのも重要なのだが、仮にクローズでソースが見られなくても回避するために頭を使うことはできるのだから、その切り替えができるようになったという点が要点だろう)
これに@kakutaniが反応したというのが興味深い。お客様-システム提供者の壁という構図は、プログラマとライブラリ(OS、ミドルウェア)の壁という構図と同一だからだ。すると両側に壁を作っている人たちというのが本当の構図なのだなぁ。で、@kakutaniは壁を壊す人だから、なるほど反応したのも当然だなぁと理解した。そこまで(両側の壁が目に入るまで)引いて考えたことはなかった。
@nari3の講演は印象的。まず、観たことある人? に対して、やたらと挙手が少ない(というか、おれも知らない)。ところが、(後で聞いたらもっと多いと思っていたらしいので、その想定で作ったらしいけど)ストーリーを換骨奪胎して位相をずらしたパロディ版のスライドに説得力があるので、観ていなくても問題なく何が論点かわかるように作られていた。
(@kakutaniも絶賛していたので映画らしい映画らしい)(今気づいたが「らしい」は確実性(前者)と憶測(後者)の相反する意味の2つの異なる言葉なのだな)
#この会議の基調には、GC.disableがつきまとっているらしい。1.8、1.9、2.0のベンチマーク(@mrkn)は@_ko1の推測と異なりGCの速度向上はまったく関係ない(GC.disableしている区間の計測)に始まって、GC.diableして動かすPerfumeで終わった(MP吸い取られる踊りの奇妙な動きの秘密を後で@nari3に教えてもらえたが、当然話の流れからGCによって引きつるのかと思ったら、まったく関係ない=GC.disableしている、とのことだった)。で、それが基調にあるだけに、JKがキャッキャッしながら、GC.disable、GC.disable_lazy_sweepと放言するのにうけまくる。
あと、おもしろかったのは、全体的にアジャイルが否定すべき古臭いもの(とまでは言わないものの、フローチャート(笑)くらいのイメージに近づきつつあるような)扱われ方で、なるほどアジャイル宣言から12年(日本の数え方で1回り)たったんだなぁということとか。
あと、懇親会の会場が、庶民のための迎賓館というかベルサイユというか、シャンデリア、長い会食用机、亀の甲羅とばっちり揃った会場で、最初、会議場からやたらと歩かされて何考えてんだとネガティブだったのが吹っ飛ぶおもしろさ。これは良い。
と、実に良い日を過ごせた。みなさんお疲れ様でした。
追記:@ogijunからシェフの話の解説を聞けた。なるほど、おもしろいと思った。
先月末から、やたらと継続買いしているマンガの新刊が出てきて、どうしてこうも時期が固まるのか不思議だ。
まず、へうげものを先月末に見つけてから、すぐに
軍鶏だ。新展開でどうも元の原作者の物語の影響を脱したらしく、軽口たたきながら、良い感じ。
で、さらに気づくと
大正ガールズ エクスプレス(5) (KC KISS)(日下 直子)
大正ガールズエクスプレスが出ていて、吹き出しの形状や引き込み線といったマンガ技法の発見をしつつ、ついに卒業を目前に社会とどう折り合いをつけるかに話が移り(そこで大正の同人誌ブームが重なるのだが、この仮想的な大正史の中で電子出版まで話が進められたらすごいけど、さすがにそれは無理だろうな)、
一体、どう話をつけるつもりか、手作りの冊子に込めた思いとデジタル化可能なテキストが干渉しあったりしているうちに、堂々たる物語の真打が2つも待ち構えていた。
さらに、別の味わいの楽しみも待っている。
と、突然の出版ラッシュなのだった。
(追記:で、もやしもんが4月の頭か)
もやしもん(12)限定版 (プレミアムKC イブニング)(石川 雅之)
(何がつくんだろう?)
ザ・ネクスト・デイ デラックス・エディション(完全生産限定盤)(デヴィッド・ボウイ)
まあ、買ってしまうことになるけど、ジャケットのセンスは最悪だよな(鋤田氏に金払いたくないとかそういう話だとまでは思わないけど、スティーブレイボーンへの金払いが悪くてツアーから逃げられたというような話を思い出したりもしないでもない)。
それにしても、『スパコンで力任せに数独の難しい問題を作る』の追記には含蓄がある。
ただ、せっかくの含蓄あるお言葉なのに、エントリーの末尾ではなく最初に置いてあるので、ちょっとがっかり感もある。
二流小説家はとてもおもしろいメタ小説なのだが、読んでいて、どうも既視感にとらわれてしょうがなかった。
題名から想起されるイメージはバラードなのだが、まったく違う。
(どうでも良いがこのての小栗虫太郎リスペクトな名前はなんなんだろう? いろいろなバリエーションを見かけるが実は同一人物なのかなぁ)
既視感があるのは、人体をばらばらに分解して再構成してオーナメントを構築するところの描写方法にある。レクター博士ではないし、もしかするとステロタイプなだけなのかも知れないけど、おれは粘液と血液がしたたるような気持ち悪いのは嫌いだから積極的にはそういう作品って読まないだけに不思議だ(つまり記憶にない)。
が、唐突に読んでいるさなかに頭の中でBGMが鳴り響いた。2人目の犠牲者がベッドの上に飾ってあるところかな? (ちょっと記憶はあいまいだ)
退屈なディストーションサウンドで、それに比べればルーリードのメタルマシーンミュージックのほうが一億倍魅力的だ。スロッピングリッスルかなぁ? でもそれにしては機材がリッチな音なのが不思議だ。
で、メロディーラインがほとんどないので特定するための手がかりがなくて、どうにも気持ちが悪かったのだが、何度か頭の中で再生しているうちにボーカルパート(というか語りだが)が入ってきて、ちょっとしゃがれた声でボウイの最もおれの好みではないアウトサイドだと気づいた。
確かに、アウトサイドの中には、美術館の入り口に死体を分解して再構成した美術品を展示するというような詩があった。
趣味の悪い作品だったうえに、音楽もつまらないから、まったく忘れていたのだった。
が、記憶の引き出しというのはおもしろいなぁと思った。
というのを、ネクストデイを見て思い出した。
アスキーの鈴木さんから頂いた本の中にSoftware in 30 Daysというスクラムのマネージャ向けの本がある。
マネージャ向けというのは僕の印象論ではなく、著者の言葉だ。『本書は、生き残りと競争力をソフトウェアに依存している組織のリーダーたちに向けて書いたものだ』。でもプレイングマネージャっているし、という前にもっと明確に『ソフトウェア開発を「しない」人に向けて書いたのは、本書がはじめてである』と書いている。さらに定義として『優れたソフトウェアを短期間・低コスト・高い予測可能性・低リスクで届けたい組織のCEO・経営者・シニアマネージャに向けて書いたものだ』としている。
まず、薄い本だ。全部で208ページだが、P.140以降は用語集とスクラムガイド、プレイブック、そして索引なので実質150ページ程度で、なるほど、この読解高速性というか即席性からしてすでに開発しない人のための本となっている。薄さにあわせて価格も抑え気味だ。
ところで、プレイブックってなんだろう? スクラムをプレイするための心構えや方法が書いてあるのだけど。シナリオっぽくもあるし、辞書をひくと脚本、計画、戦略と書いてあるから、読んで掴んだイメージ通りのものらしい。追記:アメフトらしい。
であれば、実は、この実質30ページ弱の付録C『エンタープライズアジリティを獲得するためのプレイブック』だけ読んで済ませても良いように思う。
そうではなく、まず説得されて納得したければ、本文を読めば良い。
すると、Software in 30 Daysというのは、30日で開発するのではなく、適切な区切りで(全然別の言い方をすれば)PDCAを回すと、ソフトウェアだと最大でも4週間程度が区切りとして良いという意味だということがわかる。
根拠はわからないが、30日のコストに対して2週間だと1.5倍のコストがかかり、1週間だと3倍にコストが膨らみ、30日を超えると情報が処理しきれなくなったりだれてしまうから問題外ということらしい。
根拠はわからないと書いたが、最初のほうでソフトウェア開発では経験主義が正しいとしているので、経験的にそうなるということだろう。
というわけで、本文はスクラムの概要を盛り込みながら、なぜ経験主義が正しく、そして経験に基づけばスクラムがソフトウェア開発には最適であるということが説明され、付録で用語を示し、ガイドでルールを覚え、プレイブックを参照してプランするという構成となっている。
妙に簡潔にまとまっていること、内容がこなれていることから、アジャイル15年の歴史で、ここまで洗練されたのだな、と考える。
というわけで、チームの進め方がまだアジャイルになっていなければ、とりあえずスクラム、手元にこの本、でやってみるのが良いのだろう。
Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド(Ken Schwaber)
判型は技術書の定番のサイズより一回り小ぶりで、ページ数と価格も手ごろなので、読みやすい。
イメージフォーラムでベルトルッチの分身。とりあえずメモ。
ジェズイットを見習え |
_ はら [これはスンバラシーですね。質が高い!]