流れるような Java が Ruby ぽい件

by tanabe on October 26, 2007

それ、どこの Ruby? と思った。

思考を中断せずに流れるようにコーディングができるかどうかが重要なんだ。そして、よくできた流れるようなインターフェースは、可読性が高い。
流れるようなインターフェースとメソッドチェーンは違うもの

本文の主旨は言語がどうこうっていう話じゃなくてスタイルの問題だって話ね。念のため。

「流れるようなインターフェース」は、RSpec とかを見ても最近のコーディングスタイルのトレンドとして感じるし、よい名前も付いたし、来年あたり力強いコンセプトとして広まりそう。数年前の CoC のように。

上記のひがさんのエントリは誤解を解くための良い指針として押さえておくべき。そして、猫も杓子も流れるインターフェースと言い出して、珍妙なインターフェースが続出する未来はぜひ避けたい。

あと、コードの見た目は Ruby ぽい以上に Rails ぽい。手続き的でなく、よりメッセージ的なのかな。(OOP の文脈でメッセージという言葉を使うと誤解を招くが、ここでは読み手へのメッセージ性が強いということが言いたい。)

最後に、「Piers Cawleyから、いいフォローが入った。」の先から引用。

Think really hard about names.

名前重要。脳みそ振り絞って考えよう。

  

[Ruby] DecisionTable を簡単に作る

by tanabe on October 25, 2007

DecisionTable を書くのに全パターンを書くのはとても面倒。面倒なことはコンピュータにやらせよう。

ということで、Ruby で書いてみた。


class DecisionTable
  attr_accessor :patterns

  def initialize(patterns = [])
    @patterns = patterns
  end

  def horizontal
    rows
  end

  def vertical
    rows.transpose
  end

  def table
    format_table vertical
  end

  private
  def rows
    pattern_map(1, @patterns.dup)
  end

  def pattern_repeats(patterns)
    return 1 if patterns.empty?
    patterns.map {|r| r.size }.inject {|r, n| r * n }
  end

  def pattern_map(repeat, patterns)
    return [] if patterns.empty?
    pattern = patterns.shift
    return pattern.map {|p| [p] * repeat }.flatten * pattern_repeats(patterns), *pattern_map(repeat * pattern.size, patterns)
  end

  def format_table(table)
    table.map {|r| format_row r }.join("\n")
  end

  def format_row(row, separator="\t")
    row.map {|c| "\"#{c}\"" }.join(separator)
  end

end


if __FILE__ == $0
  patterns = [
    %w{m f},
    %w{5 10 15},
    %w{5 10 15},
    %w{0-10 11-45 45-60 60-65}
  ]

  dt = DecisionTable.new(patterns)
  puts dt.table
end


出力を Excel に貼って、各パターンの結果を書けばルールテーブルのできあがり。

  

Sun Tech Days 2007

by tanabe on October 22, 2007

すっかりスルーしてたのですが、Sun Tech Days 2007 に James Gosling が来るんですね。最近の Gosling の言葉として記憶にあるのが、http://www.rubyist.net/~matz/20060127.html#p01だったりするのがちょっとアレですが、それでも2時間のボリュームで、しかもヘタな真似はできない場での基調講演となれば見逃すわけにはいかないところ。

あとは時間作れるかだなぁ。

  

Jeff Bezos が語る Amazon は何を考え続けているのか?

by tanabe on October 19, 2007

Harvard Business Review October 2007 に Amazon の創業者 Jeff Bezos のインタビュー (The Institutional YES) が載っている。Amazon の文化、戦略の生まれる背景を解き明かそうとした良インタビューだった。

かつて梅田望夫さんは「コンピュータ産業のパラダイムシフトを象徴するアマゾンの戦略」という良エントリで「アマゾンがテクノロジー企業に変貌しようとしている」と指摘していたが、このインタビューを読むとそのテクノロジーの取り込みも手段の一つでしかなく、Amazon はあくまで「Amazon の顧客は誰か?その人たちは何を求めているか?」をひたすら考え、忠実に実装していく企業であることが読み取れる。これはいわゆる「ネット企業」「テクノロジー企業」に特異な視点だろうか?むしろ、古典的といってよい王道の視点だろう。

そして、そこで語られる基本哲学は変化が激しいと言われる Web を舞台にビジネスをするからこそ、特に気をつけるべき視点が大いに含まれている。

まずは、Amzon では、ビジネスを長期的な視点で見ており、短期的な考えに捉われることを避けている。それはたとえば種を植えて木へと生長するのを待つようなことである。という文脈での質問から。

Do you know when you're planting of those seeds that it's, say, an acorn and it's going to turn into an oak? Do you have a stron vision of how things will materialie? Or does the shape emerge along the way?

We may not know that it's going to turn into an oak, but at least we know that it can turn out to be that bin. I think you need to make sure with the things you choose that you are able to say, "If we can get into this to work, it will be big." An important question to ask is, "Is it big enough to be meaningful to the company as a whole if we're very successful?"

Amazon で重視されるのは、うまく行くかどうかという姿勢ではない。それが本当にうまくいったとしたら、ビジネスになるのかどうか? Amazon に対して与えるインパクトは十分に大きいものなのか?その質問が重視される。

Amazon が手がけるビジネスを見た外部の人は最初の頃、「なぜそんな新しいことをするのか?」という感想を抱く。なるほど。それは正当な疑問だろう。それに対して Bezos はこのように語る。

But they all have at their heart one of the reasons that it's so difficult for incumbent companies to pursue new initiatives. It's because even if they are wild successes, they have no meaningful impact on the company's economics for years. What I have found - and this is an empirical observation; I see no reason why it should be the case, but it tends to be - is that when we plant a seed, it tends to take five to seven years before it has a meaningful impact on the economics of the company.

そのようなことを言う人たちは、新しい挑戦を恐れるから会社を助けるような大きな成功ができないのだ。Bezos はこれまでの経験から断言する。「なぜかはよくわからない。でも、これだけは言える。企業にとって有意義な結果が出るまでにはたいてい着手してから5〜7年は必要だ。」

That does require people, inside and outside, to keep the faith. How do you have the confidence that the investment will ultimately pay off?

It helps to base your strategy on things that won't change. When I'm talking with people outside the company, there's a question that comes up very commonly: "What's going to change in the next five to ten years?" But I very rarely get asked "What's not goning to change in the next five to ten years?" At Amazon we're always trying to figure that out, because you can really spin up flywheels around those things.

ただ、そのような長期的な視点での挑戦を続けるのは内外が信念を持ってあたる必要がある。Amazon では変化するものではなく、変化しないものを対象に戦略を立てることで短期的な心配に振り回されないようにしている。問い続けるべきは、「この5〜10年で何が変わるのか?」ではなく、「この5〜10年で変化しないものがあるとしたら、それは何か?」なのだ。

では Amazon はいったい何が変化しないと考えているのか?それが続いての質問だ。

What are some of the things you're counting on not to change?

For our business, most of them turn out to be customer insights. Look at what's important to the customers in our cunsumer-facing business. They want selection, low prices, and fast delivery. This can be different from business to business: There are companies serving other customers who wouldn't put price, for example, in that set. But having found out what those things are for our customers, I can't imagine that ten years from now they are going to say, "I love Amazon, but if only they could deliver my products a little more slowly."

Amazon はコンシューマビジネスであり、つまるところ「顧客についての深い理解」こそがコアとなる。「顧客が何を重視するか?」に焦点をあてればいい。10年後の顧客もけして「Amazon は嫌いじゃないんだけど、もう少し配達が遅ければいいのに。」なんて言いだすことはない。

Another thing that we believe is pretty fundamental is that the world is getting increasingly transparent - that information perfection is on the rise. If you believe that, it becomes strategically smart to align yourself with the customer. You think about marketing differently. If in the old world you devoted 30% of your attention to building a great service and 70% of your attention to shouting about it, in the new world that inverts.

そして、もう一つ変化しないものがある。「世界は見通しやすくなっていく」という傾向だ。これからも情報はより手に入れやすくなっていく。そこから考えると、そこそこのサービスを作ってそのすばらしさを喧伝することに力をそそぐよりも、本当にすばらしいサービスを作りこみ、それを少しだけ宣伝してやるほうがいい。あとは顧客がそれを理解し広めてくれる。

A lot of our strategy comes from having very deep points of view about things like this, believing that they are going to be stable over time, and making sure our activities line up with them. Of course there could also come a day when one of those things turns out to be wrong. So it's important to have some kind of mechaninsm to figure out if you're wrong about a deeply held precept.

Amazon の戦略はすべてこのような基礎的で深い洞察から始まり、それが長期的に続くと信じ、プランを立て実行する。ここで重要なのは、最初の視点が誤っていた場合には途中で気が付けるような仕組みを作っておくことだ。

本文はここからさらに API 提供をしている理由や、なぜマーケットプレイスや代理店としての販売を手がけるのか、顧客中心主義という Amazon の文化についてのさらに詳しい質問へと展開される。

部分部分でおもしろかった発言をピックアップしてみる。

But I thought to myself, we don't make money when we sell things; we make money when we help customers make purchase desicions.

これは今後の Amazon のビジネス領域を見極めるうえで極めて重要な視点だろう。この時点で販売を「物を売ること」とは捉えていないことがわかる。「(たとえば Web というインターフェイスを使って)顧客が『これを買おう』と思う手伝いをすること」をビジネスの目的としているのだ。この文脈だとネット直販をしている小売が商売敵ではないことも納得がいく。むしろ雑誌通販などをしているところや店舗を持っていて品物を体験できるところのほうがベンチマークの対象となるのだろう。

What would you say has been the nature of your biggest strategic mistakes?

I think most big errors are errors of omission rather than errors of commission.

「一番大きな戦略上の過ちは?」という質問に対して「やってしまったことじゃなくて、やらなかったことこそが一番大きな過ちになると思う。」という答え。挑戦すべきだという考えは徹底している。日本語で言うなら「やらずに後悔するよりやってから後悔するほうがいい」といったところだろうか。

「そのような文化を維持するために何をやってるの?」という質問については、

you will always get asked the question, "Why? Why do that?" But "Why not?" is an equally valid question.

やらない理由(やるべきでない理由)がないならやっちゃえば?という考えを浸透させるためには、「なんでやっちゃダメなの?」と聞くのは有効だそうだ。

きりがないのでここまでにしておこう。ここで取り上げたのは象徴的な発言ばかりだが、実際にインタビューではそれぞれについてのもっと具体的な話も語られている。わずか 7 ページ程度のインタビューなので、読む機会のある方はぜひ目を通してみることをお勧めする。

ついでに、Jeff Bezos についての過去のインタビューなどの一部は下記へ集めている。ご参考までに。
http://del.icio.us/zep716/bezos

  

Jeff Bezos のインタビューがすばらしい件

by tanabe on October 17, 2007

DIAMOND じゃない原書の方の Harvard Business Review 2007.10月号にJeff Bezos のインタビューが載っている。これがもうすばらしい内容すぎる。

Amazon の Jeff Bezos だからといって、インターネットの行く末は?というような内容中心ではない。HBR だからというわけでもないだろうが、地に足のついた真摯な受け答えでありながら、かつ内容は示唆に富むというもの。Web をインターフェイスに販売をしているというビジネスの視点で非常に中身のあるインタビューになっている。

Amazon.co.jp でも見つからず、一冊単位で買うことはむずかしそうなので、面白かったところを訳してエントリしてみる予定。

追記。書いた。http://blog.hacklife.net/archives/51224167.html

  

Asianux Road Show 2007 まつもとゆきひろさん、基調講演のメモ

by tanabe on October 16, 2007

2007/10/16 Miracle Linux 社開催の Asianux Road Show 2007 へ行ってきた。そのうち、まつもとさんセッションのメモ書き。急いでメモったので、理解が違っているところや聞き漏れ、聞き間違いがありえる。読まれる方は、そこを理解したうえで読んでください。

タイトル
Ruby からのメッセージ

自己紹介
  • プログラマ
  • オープンソース開発者
  • 言語デザイナ

世に言語の種は尽きまじ
  • 一説には数千とも数万とも
  • ほとんどは消えていく
  • アイディアの具現化
  • いつか自分の言語を
  • 言語を作りたい人は一定数いる
  • Ruby という名の言語も3つ存在する
  • ただ、ほとんどは寿命が短く使われない
  • 作者しかユーザがいない、とか

先端言語と普及言語
  • 言語における対立軸
    • 一般向け/学術向け
    • 最新技術/枯れた技術

先端言語
  • 特定のアイディアに深く依存
  • 応用範囲が狭い
  • アイディアの実用性を証明(検証?不確か)

先端言語
  • 論理プログラミング: Prolog
  • 関数プログラミング: FP (functional programming/ジョンバッカス), huskell, erlang, ...
  • オブジェクト指向: Simula (Entity のデータ構造をADTで表現), Java, C++, Smalltalk, 各種Lisp, Perl, Python ...
  • イテレータ: CLU (繰り返しの抽象化 MITバーバラリスコフが開発, OOPに近い考え方)
  • ゴール指向: Icon (バックトラッキングが組み込まれている)
  • 玉石混交で他の言語の礎となることが多い
  • 概念が形を変えながら取り込まれる

例外的先端言語
  • Lisp
  • Smalltalk
熱狂的ファンを獲得。実用性もある。が、広まることはない

普及言語
  • 先端から学ぶ
  • 枯れた機能優先
  • 実用的
  • だが、面白みは少ない # 言語で冒険しないから
Java でOOPを知った人は多いだろうが、実際は60年代に考え方は発生している
  • ガベージコレクションも普及した が、 Lisp によって 60 年代頭に登場
  • 先端言語の概念が普及言語に取り込まれるまで30年くらいかかる

普及言語
  • Fortran
  • C
  • C++
  • Java

先端から普及へ
  • 再起
  • 抽象データ型 # データのカプセル化を行う
  • オブジェクト指向
  • 関数指向 # 関数そのものをデータとして扱い、関数そのものをデータとして適用する.
Javascript なんかはオブジェクト指向と関数指向の両方を備えている。化粧し損ねて顔がくずれた Lisp とでもいうか。。 ← 素材は良いという意味だと思われ。

先端技術とはなにか
  • より抽象的
  • より簡潔
  • より生産的
  • より変化に強い

先端的普及言語
Ruby
普及言語でもっとも進化したもの

Ruby の特長
  • オブジェクト指向プログラミング言語(下とかぶってる。写し間違ってる?)
  • 純粋オブジェクト指向
  • 高階関数

純粋オブジェクト指向
  • 文字列
  • 数値
  • 配列
  • その他すべて

文法
  • Lisp: S式
  • Smalltalk: メッセージ
  • Python: インデント
  • Ruby: 保守的
外見がふつう。ブロックを閉じる end は algol からもらった。

DSL
  • Domain
  • Specific
  • Language
  • 専用言語風汎用言語

DSL
Rakefile
Rake = Ruby Make
task :default=>[:test]
task :test do
  ruby "test/unittest.rb"
end
一見すると専用の言語のようだが、実は単なる Ruby のプログラムなので、やろうと思えばなんでもできる。

DSL
単純な文法だと
→ 複雑。(コード省略)
Ruby のような言語の力がなく単純な文法で DSL ぽいものを書くと、括弧などの記法上の制限が多くて複雑な見た目になる。DSL ぽく見えない。

高階関数
  • クロージャ
  • ブロック

Ruby の特徴
  • ブロック 
  • Duck Typing
  • メタプログラミング

ブロック
  • コードの塊
  • メソッドに付加
  • 拡張可能な制御構造

ブロック
  • 繰り返し
  • 条件判断
  • データの加工
  • など

繰り返し
 3.times do
    puts "hello"
  end
  a = [1,2,3]
  a.each do |i|
    puts i
  end 
ブロックを導入することで、ループのための文法を定義しなくても繰り返しを実現できる。文法を変えることなく、制御構造を拡張することができる。

条件判断
 a = [1,2,3,4]
  a.detect {|x| x % 2 == 0}
  a.select {|x| x % 2 == 0}
  a.reject {|x| x % 2 == 0}
ループや制御構造を使って実現するようなことが、簡潔な表現が可能になる。意図をそのまま表現することが可能になる。

データ加工
 a = [1,2,3,4]
 a.collect{|x| x * 2}
  a.sort_by{|x| -x}

スコープ制御
 open(path) {|f|
     ...
  }
  # ブロックを抜けたらファイルが close されるので意図が明確に表現できる

  catch(:foo) {
    throw :foo
  }
  # 専用の制御構造を導入しなくても、単なるメソッドで実現できる

動的型
  • 変数・式に型なし
  • 実行時に型が決まる
  • エラーチェックも実行時
  • 型の宣言不要 → 簡潔
  • 型に束縛されない → 柔軟

Duck Typing
アヒルのように鳴き
アヒルのように歩くのは
アヒルに違いない
ほんとは何かわからないけど、振る舞いからアヒルだとして扱っていい という考え方。オブジェクトの型情報よりもオブジェクトのインターフェイスを重視する。

Duck Typing
型よりも
インターフェイスを重視
メソッドを満たすもの

Duck Typing
StringIO
  • 文字列への入出力
  • 継承関係なし
  • 実装共有なし
  • 外見は同じ
Ruby のプログラムで IO を期待しているところに StringIO を渡すとほぼ間違いなく動く。これが醍醐味であり強み。Java だと型の宣言と一致しないと受け付けない。共通 interface が必要になる。interface がなければ wrapper が必要だったりする。 → 面倒。事前に考えないと分岐ができない。Ruby ならだいたい問題ないよ。

メタプログラミング
  • プログラムを操作
  • 情報取得
  • プログラムを変更

メタプログラミングの力
  • ActiveRecord
    • Object-Relational
    • DBスキーマのみ
    • クラスはスキーマから
オブジェクトのアトリビュートなどはスキーマ情報から取得し、直接書き換えちゃう。

ActiveRecord
クラス定義これだけ
class User < ActiveRecord::Base
end
中身はスキーマから
設定ファイルをいじったりが必要ないので、メンテの負荷が減る。

この辺からかなり速度がアップ。メモの精度がさらに微妙なことに。

メタプログラミング
  • DBスキーマを読み
  • 属性を自動定義
  • 人手いらず
メタプログラミングの力。他の言語でもできるけど、結構面倒。Ruby はメタプログラミングに最適化されているので便利。人手が省ける。

メタプログラミング
真の違いは
哲学に基づいたバランス
他にもできるのはある。

Ruby の哲学とは?
  • 簡潔さ
  • 書きやすさ
  • 単純さを追求しない

簡潔さは力なり
by Paul Graham
  • Fred Brooksの法則
  • 簡潔さ ≒ 効率
あるプログラマが一定期間に生産できるプログラムコードの量は一定。だから言語の力で生産性の勝負が決まる。

書きやすさ
  • 少ない記述
  • 少ないタイプ量
  • 実行可能擬似コード
教科書に出てくるような擬似コード(細かい記法や規則を省略してアルゴリズムだけを表現した簡易コード)を書くと、それが動くというのが言語デザイナの一つの目標。Ruby は良い線いっている。

サンプル:階乗
  • Java で
  • Lisp で: コードが減る
  • Ruby で: もっとコードが減る。読みやすい。
  • Ruby with inject
  • Ruby with inject on Ruby 1.9 # inject(&:*)
コードは写せなかった...

サンプル:ネットワーク
一行で書けちゃいます。これも写せず...

 

続く二枚は気になるスライドだったけど、タイトルだけでほとんどスルー。細かい項目は写せず。読み取れず。

単純さを追求しない
人の好みは単純じゃない

どうでもいいことだけど、写したメモを見たら「人の交尾は単純じゃない」と typo していた orz

Ruby on Rails
web development that doesn't hurt. # 痛くないWeb開発

opinionated software ソフトがプログラミングに影響を与える
自己主張のあるソフトウェア。自分の意見を持ってる/押し付ける。

sapir-whorf仮説
  • 言語は施行に影響を与える
  • 制約を与える
  • (?)

バベル17
言語が思考に影響を与える
バベル17表紙画像。

言語からのメッセージ
メッセージが含まれている

Ruby が与える影響とは
  • プログラミングは楽しい # 昔は楽しかった。仕事でやると面白くない。楽しさを思い出したい。
  • プログラマは素晴らしい
  • プログラミングはわくわくする
  • 苦労はコンピュータへ
  • 人間は楽を
  • 記述は関係
  • 生産性は高く
  • 変化に強く
→ Enjoy Programming!
これが Ruby に振りかかった魔法。

Ruby の今後
  • 趣味から仕事へ
  • スケーラビリティ 
    • データ量
    • アクセス数
    • プロジェクト規模
テラバイトのデータを扱いたいとか、極端に大きなアクセス数をさばきたいとか、Rubyで百万行とか、今後はサポートしていかないとなぁと思ってる。

Ruby 1.9
  • 12月リリース予定
  • 新機能(M17Nなど)
  • パフォーマンス向上

ruby 2.0(2010年?)
  • 未来のいつか
  • より冒険的な機能
    • traits
    • パッージシステム
    • アスペクト指向 など

他のセッションも含めて、とても面白い内容でした。どうもありがとうございました。

追記。Asianux Road Show へのリンクを追加。資料を頂いたので、こちらは特にメモしていませんが、よしおかさんのセッションも非常にためになりました。福岡・大阪の方はチャンスがあるのでぜひ。あと、インテルのアーキテクチャの話も普段あまり触れない分野なので興味深かったです。

  

衝動が正しいものなら調整して実施。独りよがりでないかは要確認。

by tanabe on October 13, 2007

個人的には

この一行がどうにも読みにくくしている。
via 教えながら学ぶRuby: 言語を拡張したくなる衝動に関して
という程度の問題意識に対してオーバースペックな解法を取っている気がするなぁ。

この件については、意図がコードに反映されていない(Ruby に慣れていないと本当に必要なのかが読み取れない)というなら、

next if invalid?(r)
とかしてやれば済むだけの話だと思う。入力パラメータのバリデーションがしたいなら、バリデーションとして明示したほうがわかりやすいよ。という業務システムプログラマ脳の意見。

ただ、オープンクラスな Ruby だとこういうことが誰にでも可能で、いつどこでどういうプログラマが働いているかわからないと影響が大きいよね、という論点には異論ない。そして、多かれ少なかれ、これはコミュニケーションの問題だと思う。密なコミュニケーションが取れていないと言語によらずプロジェクトとしては同種のリスクを持つという意味では、そこをことさら言語の問題として取り上げる必要はないように思う。知らないうちにあっちのチームと仕様がずれてました!みたいな話と一緒じゃないかと。(ビジネス仕様は暗黙的に共用されるグローバル変数。あ、これも業務システム脳かも。)

たとえば今回みたいに

  • NilClass 拡張しようと思います。
  • 理由はこうです。
という話があれば、上記のような理由でぼくは反対するだろうから、それで問題ないんじゃないかなぁ。仮に NilClass が拡張されることになっても、それは(たとえば ActiveSupport のように)周知のことになるからやっぱり問題ないし。

参考リンク。
「Rubyのオープンクラスってば大規模ソフトウェアに不向きじゃない?」という話。

  

あれ、HBR 予告と違ってない?

by tanabe on October 10, 2007

HBR 11月号が来たんだけど、前号巻末の掲載論文予告と大部分が違っているような気がする。

野中郁次郎さんとか門永宗之助さんとかのを期待してたんだけど、アテが外れたなぁ。まぁ、今号読む限りじゃ、過去記事の再編集ばっかりみたいだからどうでもいいけど。いずれにせよ、定期購読者泣かせの回なのは間違いない。

  

さくさく Smalltalk

by tanabe on October 10, 2007

いかんせん、Smalltalk さぱーりわからん。ということで、某 Smalltalker の教えのままに、「さくさくSmalltalk」購入。

今、読んでいるところなんだけど、これ良本ですね。教えてもらえてよかった。感謝。

サクサクSmalltalk―オブジェクト指向のアートとサイエンス
サイモン ルイス Simon Lewis 水口 朗 梅沢 真史 増田 英孝 今野 睦
東京電機大学出版局 (1996/08)
売り上げランキング: 206538