満足せる豚。眠たげなポチ。

Ruby で手抜きテンプレートを使う

たまに手抜きで使うコードをなんとなく載せてみる。テンプレート使いたいんだけど、ちょっとしたスクリプトだしそもそも ERB の API どんなんだったか覚えてないし、リファレンス引くのもちょっとした手間だし。てなときに使ってる。(ERB くらい覚えろよ。という話もある。覚えてもすぐ忘れるんだよなぁ。)

sample_template = Proc.new do |param1, param2|
%Q!
とまぁこんなかんじで始まったわけですが、
この辺はぜんぶテンプレートなんですね。


だから、どんな風に何を書こうが自由なんです。

パラメタについても記法に迷うことなく
いつもの形で出力することができます。
たとえば、
 #{param1}
こんな風に。

文中にあっても#{param2}なんだか見慣れた形式で安心です。

かんたんですね。
!.lstrip
end

# 使うのも簡単。API を調べたりする必要もまずありません。
puts sample_template.call(p1, p2)

こんなん。邪道？ lstrip で最初の改行を消しているあたりもださい。

ちなみにコードジェネレータのテンプレートをこれで書いていて、いつのまにかコード行数が育ってきてそろそろちゃんとテンプレートエンジン導入しないといけないなーと思ってるのは内緒。

結論としては require 'erb' と ERB.new(text).result だけなんだから覚えろよ。と。

2009年春オブヒロ＆オブラブ合同イベント「田町deナイト～SAMURAI meets VIKING～」

このイベントへ行ってきたので、遅ればせながら感想とか。

自己紹介とパネルディスカッションという構成で事前に準備された質問に各国、各開発スタイルの立場から意見を答えていくというスタイルで進行していた。

イベントとしてのわくわく感がとても高いものだった。会全体の雰囲気による部分が大きいと思う。

細かい話はいろいろあるんだが、とりあえず受け取った大きなメッセージを二つあげると、

顧客に価値を提供しろ: 最終的には顧客に価値を提供できたかどうかだけが意味を持つ。そして顧客に価値を提供するためには、顧客が得たいものを正しく見極めなければならない。ソフトウェアに価値はない。ソフトウェアを通して、何を実現したいのか。それを顧客と共に発見することが大切だ。「顧客が言うことを正しく聞きとってそれを間違いなく作る」というのはゴールじゃない。顧客の本当の課題を理解しそれを解決して顧客が価値を得るためには何ができるのか。それをゴールにするべきだ。
values と principles を基に行動せよ: アジャイルかどうかはプラクティスでは計れない。values と priciples を理解し、それを規範にチームの行動を進化させるのが一番大切なこと。そのための基本的なツールは、フィードバックとレトロスペクティブ（ふりかえり）。やってみて結果を受けて次の行動を変える。それを繰り返してチームを成長させる。

こう書いてしまうと当たり前すぎるのかもしれないけど、実際にそれをやっていて体験として語れる人たちが言うと説得力が違う。

あとは細かい発言からいくつか拾う。『』は発言を意訳したもの。

アジャイルは「変化に柔軟に対応する」「変化を許容する」というところから、むしろ「本質的に変化が必要な状態なのだから、変化を促す。変化を通じて結果を求める。」というスタンスに進んでいる気がした。(アジャイル門外漢の単なる感想ね。)
『レトロスペクティブ、レトロスペクティブ、レトロスペクティブ。』
『一番大切だと感じるのは「顧客に価値を届けるまでの時間を０に近づけること」。これは大野耐一氏の言葉から学んだ。』
契約に銀の弾丸はないらしい。

いろいろあるけど、とにかく顧客と信頼関係を結んで合意したところでスタートしているよ。というのが実情っぽい。
どの話がフックになって顧客はハンコ押してくれるのかを聞こうと思ったけど、聞きそびれた。

『アジャイル開発に個人の資質は必要。でもそれは先立つチームの文化がないときの話。チームに文化があれば個人の資質をこえてチームに受け入れることもできる。』

懇親会への移動の際、ゲストに会を欠席して帰るという人がいたので、田町の駅まで案内した。道中に SCRUM の話をいろいろ話していて、この間の話もとても楽しかった。「イテレーションの期間は変えてはいけないよ。あれは期間を固定してチームにリズムを作って、違いが出たときに気づきを得るためのものだから。」とか。「東京駅まで行けたらあとはホテルまで帰れるから大丈夫なんだ。あーっと、ハママッチョーとかいうとこ。」「それ隣りだよ。」とか。

懇親会はあまりアジャイルの話はしていなかった気がする。ウォーターフォールプロセスはどう評価している？とか聞いてみたりしたかな。

最後に懇親会の雑談メモ。

音楽とサッカーの話は国境を越えやすい。
MUSE が好き。デペッシュモードが好き。とか、ふつうに理解できるし話ができる。「MUSE は最初はよかったんだけど、どんどん方向性に同意できなくなってきた。」「あー、わかる、わかる。」
「サッカー好きだよ。」「おー！好きなサッカー選手は？」「ミカエル・ラウドルップ」「(爆笑)」みたいな。(昔日本に居たんだよと説明したり。)
「じゃあじゃあ、イブラヒモビッチ知ってる？」「当然でしょ」とか。
「『乾杯』てどういう意味なの？」「make your glass empty.」これもえらい喜ばれた。

「ソフトウェア開発はカオスであり、かつフラクタルである」

ということで、戦術的ピリオダイゼーション理論(以下、PTP)に夢中な今日この頃です。先に言っておくと今日の話は強力に電波なので気をつけるように。(PTP がではなく、ソフトウェア開発の類似性を云々しているこのエントリが。)

PTP というのは要約すると、「フッボールの本質は予測不可能性にある。だから様々なレベルでの状況判断(=戦術)を強化することでフッボールが上達する。」(フッボールという表記はネタ元の村松さんブログの表記に合わせた。まぁ、サッカーです。)というコンセプトだと理解した。ポイントは状況判断が予測不可能性を押さえ込んでねじ伏せる道具ではなく、柔軟に状況に応じて自分が変化し対処していくための道具と位置づけられているところ。

つまるところ、村松尚登さんのブログを読め。と。

で、これが(というか、村松さんがというべきか)いろいろ良いこと言ってる。

戦術の基本はチーム戦術
「個を育てる」というコンセプトはありません。あくまでも『トレーニングはチームプレーの改善のために存在する』というコンセプト
フッボールの本質が“テクニック”ではなく“カオス”だとすると、フッボールにおける最重要課題はボールと友達になることはでなく“カオス”と友達になることなのではないでしょうか。
“カオス”は混乱です。そして、混乱の中で闇雲に戦っていては敵を倒すことはできません。その混乱の中に存在する小さな法則（＝定跡）をなるべく多く見つけ出し、混乱により良い形で適応できる術を身に付けることが、混乱の中での戦い方なのではないでしょうか。
つまり、カオスと友達になるということは、「他人の指示の声さえもがカオスに影響を及ぼす可能性がある」ということをしっかりと認識し、他人の指示やアドバイスに耳を傾けつつも、自らの判断でその瞬間の状況に合わせてジャズピアノ的に即興演奏を続けて行くこと
カオスと友達になるというのは、途絶えることなく続くカオスの変化に柔軟に適応することを可能にするために武士のようにニュートラルな姿勢と心をキープすること
その証拠に、リフティングをしている子供の邪魔をしようとすると「邪魔をするな！」と怒られます。予期せぬ変化（＝邪魔）を許容していない時点で、彼がしているリフティングは“カオス”ではないのだと思います。

言いたいことは伝わる人には伝わるだろうから、こんなもんでいいか。

あとは、この文章なんて「あれ、どっかで読んだな」とか思ってしまって、読み返してもやっぱり同じようなことを言っているとしか思えない。

だって、フッボールの原型は試合なのですから、明日の試合に直結するチーム戦術の方が１対１の間合いの取り方よりもよっぽど大切だと思うからです。

これも村松さんのブログで見つけた引用。元はここの文章らしい。

学校を代表とする教育の一般的な方法は、完全な部分を積み上げていけば、完全な全体ができ上がるというものです。極端な場合は完全な部分が出来ないうちは、次の部分を見せない、あるいは学習者が漠然とした全体も掴めないうちに、完全な部分の習得を求めるというようなこともあります。

しかし学びの自然な姿は、大まかな全体が大まかな部分の総体へ少しずつ割れていき、部分が総体的に深まっていくというものです。つまり「大まかな全体から細かな全体へ」ということです。決して「細かな部分から細かな全体へ」ではありません。

もはや何を言いたいか、解説はいらないはず。完成に至るまでの学習と理解のプロセスだという視点で見たときには、「あー、あのことか」と。

神々の開発はまた別なのかもしれないけど、普通の人が普通の人とチームを組んで働いて、結果を求めるというのは、結局そういうことなんじゃないかなぁとしか言えない。

「守備も攻撃もテクニックもフィジカルも切り離してはいけない。
　それぞれの要素を切り離してトレーニングしても各要素が上達するだけで
　サッカーは上達しない。サッカーの上達はサッカーのトレーニングからしか
　生まれない」
via フットボールはフットボールをトレーニングすることによってのみ上達する

では“戦術的ピリオダイゼーション”では「個の成長」をおろそかにしているかというと決してそうではありません。“戦術的ピリオダイゼーション”では『フッボールチームが成長する過程でこそフッボール選手個人が伸びる。なぜならば、フッボールはチームスポーツであり戦術だからだ。このような特徴を持ったフッボールの世界で活躍できる優秀なフッボール選手は、チームが成長する過程でのみ成長する』と考えているのです。
via 戦術的ピリオダイゼーション哲学の概要

あまり一般化するのも危険なので、深入りはしないけど、いろいろヒントをもらった。

勢い余って本も買ったけど、値段分以上に得たものは大きい。フラクタルの話なんて読みながらその類似にニヤニヤしたくなる。(あ、でも本は PTP に割いているページ数は少なくて純粋にサッカーのトレーニング方法に割いているページが多いから、ソフトウェア開発的視点での興味であればまずブログを読むべき。)

FCバルセロナスクールの現役コーチが教えるバルサ流トレーニングメソッド

posted with amazlet at 09.04.21

村松尚登
アスペクト
売り上げランキング: 1171

Amazon.co.jp で詳細を見る

ジョゼ・モウリーニョ

posted with amazlet at 09.04.21

ルイスローレンスジョゼモウリーニョ西岡明彦
講談社
売り上げランキング: 10281

Amazon.co.jp で詳細を見る

「あとで書く」と言いつつまだ感想書いていないけど、この本も同じメッセージを受け取った。個より全体。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

posted with amazlet at 09.04.21

Mike Cohn マイクコーン
毎日コミュニケーションズ
売り上げランキング: 5078

Amazon.co.jp で詳細を見る

お疲れ様でした。

チームに今月末で退職する方がいたので、送別会でした。

前の職場を自分が辞めるときにも強く感じたことですが、本当に自分はチームで働くということと、単純にそのチームの人たちがすごく好きなんだなぁと感じました。

「初めてのRuby」勉強会継続中なので、また会う（のだろう）けど、その一風変わったセンスでこれからも活躍してほしいです。

# といいつつ、このブログ職場ばれしてないから読まれないな。うん。

Ruby で 50 行ほどのルールエンジンを書いてみた。

drools の記法が DSL らしくて「へー、いいなー」と思ったりしたので、なんとなく書いてみた。バックトラックを考慮していない(最初の答えを見つけたら break する)うえに速度が速いわけでもないので記法の違う if 文と言われると返す言葉もない。

要は rule, when, then のブロックでルールを定義するというのをやってみたかったということで。

when と then はメソッド定義まではできるんだけど DSL 風なアクセスをうまいこと API として定義できなくて _when と _then で妥協した。残念。

class Rrools
  class Rule
    def initialize
      @rule = {}
    end

    def _when &condition
      @rule[:condition] = condition
    end
    alias on _when

    def _then &consequence
      @rule[:consequence] = consequence
    end
    alias run _then

    def pack context
      instance_eval &context
      @rule[:context] = self
      @rule
    end
  end

  def self.describe &block
    rools = self.new
    rools.instance_eval &block
    Proc.new {|&context| rools.valuate &context }
  end

  def initialize
    @rules = []
    @description_context = Proc.new {}
  end

  def rule &rule_block
    rule = Rule.new
    rule.instance_eval &rule_block
    @rules << rule.pack(@description_context)
  end

  def context &context # rule の生成時に都度評価される
    @description_context = context
  end

  def valuate &context
    @rules.each do |rule|
      rule[:context].instance_eval &context
      if rule[:condition].call
        break rule[:consequence].call
      end
    end
  end
end

使い方はこんなかんじ。

rule = {}
rule["入場料"] = Rrools.describe do
  rule do
    _when { @people > 4 }
    _then { 5000 * @people }
  end

  rule do 
    _when { @people <= 4 }
    _then { 6000 * @people }
  end
end

people = 3
puts rule["入場料"].call { @people = people }  # => 18000

people += 1
puts rule["入場料"].call { @people = people }  # => 24000

people += 1
puts rule["入場料"].call { @people = people }  # => 25000


# やってみる。
# http://amateras.sourceforge.jp/cgi-bin/fswiki/wiki.cgi/free?page=Drools

class User
  attr_accessor :age, :name
  def initialize name, age
    @age = age
    @name = name
  end
end

is_adult = Rrools.describe do
  rule do
     on { @user.age >= 20 }
    run { puts "#{@user.name} is an adult." }
  end

  rule do
     on { @user.age < 20 }
    run { puts "#{@user.name} isn't an adult." }
  end
end

is_adult.call { @user = User.new("Bob", 21) }
is_adult.call { @user = User.new("Amy", 17) }