データフロー並列性

by tanabe on December 31, 2007

コンピュータプログラミングの概念・技法・モデル」を読んでいて、データフローという概念がおもしろかった。複数スレッドを走らせたときに、各スレッド間で変数の束縛が行われるまで互いに評価を待つというモデルのようで、シンプルな考え方で並列処理の恩恵を受けられる。関連して検索した結果をメモ。

現在のコンピュータは、大半がフォン・ノイマンモデルと呼ばれるアーキテクチャに基づいている。演算部、制御部、記憶部、出力部があり、命令を順番にフェッチし、実行していく。命令の実行順序をあらかじめ定め、各命令に必要なデータを集め、処理を行うという、命令を中心とした処理体系だ。ところが、データフローマシンでは、データの依存性に着目し、トークンをやりとりする形で演算を行っていく。トークンは、行先ノード、ポート、データからなり、行先ノードの指定のポートにデータを届ける。そのノードにおいては全てのトークンが揃ったところで発火し、次のノードに結果としてのトークンが転送されていく。データフローアーキテクチャはデータの流れに着目した、コミュニケーションベースの処理体系なのである。

超並列アーキテクチャとディペンダビリティ - プロセッサ開発の今後

コンピュータプログラミングの概念・技法・モデル」は、翻訳がちょっとアレなところはあって、明らかに何か内容が欠落しているような部分があったりするんだけど、それを差し引いても良い内容だと思う。

コンピュータプログラミングの概念・技法・モデル(IT Architect' Archiveクラシックモダン・コンピューティング6) (IT Architects’Archive CLASSIC MODER)
セイフ・ハリディ ピーター・ヴァン・ロイ Peter Van-Roy Seif Haridi 羽永 洋
翔泳社 (2007/11/08)
売り上げランキング: 25497
  

ギークがどうとか。

by tanabe on December 28, 2007

ギークのイメージはささださんやまつもとさん、高林さんのような人たちで、憧れの対象でこそあれ、虐げられた者たちというイメージがピンとこないぼくは、何か根本的なことを理解していない可能性はあるな。下請け構造最下層のプログラマだったくせに、自覚が足りないのかもしれない。

あと、SI とパッケージ開発の話なんかもそうだけど、あえて議論をごっちゃにした方が釣り要素が増えるというブロガーとしての基本作法にも則った方がいいのかもしれない。

  

スーツは着てても心はギーク。またはスーツとギーク話のモデルについて。

by tanabe on December 28, 2007

スーツもギークも仮にもソフトウェアをつくる人なのであれば、もう少し言葉の意味に敏感である必要があるんじゃない?

スーツとギークが云々っていうときは、主に議論は二つの別の話をしている。そして、どっちの話をしているかがわかれば、議論の先は見えることが多い。

一つは、ロールの話。スーツという役割とギークという役割があって、それぞれが協調してソフトウェアに関与しますよ。って文脈で使われるケースだ。

この場合、お互いのロールに対して何を言っても、自分の狭量さか無知をさらすだけ。必要な役割があって、それぞれ違う立場から働きかけているだけなんだから、そこは「問題vsわたしたち」の形にする力量があるかどうかという問題があるだけ。何を主張しようと力不足をアピールするだけになっちゃう。ロールなんだから、一人の人が両方のロールを果たすことは当然あるし、実はどちらの役割も果たせてない人だってきっといる。

もう一つが、価値判断を含んだレッテルの話。あいつは忌々しいスーツで、ぼくらは賢くすばらしいギークたちという構図から議論がスタートしているケースだ。

これはもう何を言っても仕方なくて、そもそも話は虐げられた、あるいは正当な理解は得られない「ぼくら」(別にギークかどうかは本質じゃなくて、どこにでもある話しだよね)というところからスタートしているんだから、議論の余地はない。本当に何かを伝えようと思ったら、議論をしたって意味はない。「それでギークたるあなたの主張は何?話のゴールは何にしたいの?」と突き詰めて、本当は何を聞いてほしいのかはっきりさせるしかない。

あとは、日本のSIer商売に多く見られる重たく付加価値の少ない仕事の仕方がどうこうという議論がトッピングで混ざってたり、レッテルとしてのスーツが営業もマーケもプロマネも何もかもを含んだボク以外でしかなくて単に世間が狭いだけじゃないと感じることが多かったり、あまり建設的とは思えない。

ぼく個人は Dave Thomas や Kent Beck のように(ロールとしての)スーツは着てても心はギークで。(DRY 的な意味で。)

  

ぜひ、また飲みましょう。

by tanabe on December 21, 2007

フライングでエントリしてしまってけど、今日は Smalltalk 本を教えてくださった方と小さな忘年会をした。

人づてにアンチ Ruby と聞いていたのでじっくりその辺の話を聞いてみたかったのだけど、全然そんなことはなくて、むしろ好みには合うくらいらしい。Ruby 好きとしては歓迎すべきことだけど、実力者の Ruby についての批評というのを楽しみにしていたので、ちょっと残念。

でも、その流れで静的な型と動的な型での開発についての話を聞けたりして、非常に楽しい時間を過ごせた。それなりの規模の業務システムを作るのには、動的型言語を使いたいとは思わない。とか。

今度は人数も増やしてまた飲みに行こうということになったので、次回も楽しみにしてます。

  

「意図と表現」

by tanabe on December 21, 2007

今日、とある人から教えてもらった言葉。ユーザからのヒアリングをするときに、「なぜそうしたいのか。」と「なにをしたいか。」を意図と表現という言葉で伝えるとよいらしい。

同じテーマについて以前、「お客さんのホントの気持ちに迫るための一言。」というエントリで書いていて、ぼくは「何に困ってますか?」(人によっては「解決したい課題は何ですか?」)と質問してきたけど、今度、意図と表現も使ってみよう。「そうそう。困ってることがあるんだよね。」という点では同じ意見だったので、それこそ、”表現”が違うだけなんだけどね。

  

ドキュメントは重要ではない。なんて言わない。

by tanabe on December 21, 2007

「(相対的に)ドキュメントは重要ではない。」と考えていたけど、改宗する。「そのドキュメントが何を表現するかを考えずに、ドキュメントを作る」という行為が無駄なのであって、「設計を文書にして残す。それをレビューする。」という行為はけして無駄じゃない。やるべきなのは、「何をドキュメントにするか、何をドキュメントにしないかを判断すること」と、「レビューして、設計での一定レベルの合意を形成すること」だ。そして、その目的は「品質の高いインターフェースを持ったコードを共有し、スケールさせることができるようにする。」という点に尽きる。

ふつうのプログラマで成り立つプロジェクトだからこそ、上記を徹底しないといけない。詳細設計として程度の悪い擬似コードを日本語で書いたようなドキュメントを受け取る必要は当然なく、その分、たとえばビジネスルール単位で、それをどのように設計するのかを検討する必要がある。これをコードに近い表現でやってもいいし(TDD のようになるだろうけど。)、文章とインターフェース定義でやってもいいけれど、ドキュメントとして受け取ることとレビューをすることは省かないようにする。

以上、Google のソフトウェア開発についての興味深いエントリ「いいアジャイルと悪いアジャイル」を再読してみて、最近の考え続けていたことに出した結論。

彼らはユニットテストや設計ドキュメントやコードレビューといったことを、私が聞いたことのあるどの会社よりも真剣にやっている。彼らは自分たちの環境が常に整理されているよう熱心に働いており、どこかのエンジニアやチームが自分勝手な方法でやらないようにする厳格なルールやガイドラインが実施されている。結果として、コードベース全体が同じように書かれ、チームを変えたりコードを共有したりすることが、他の会社でよりもずっと簡単なことになっている。

安易にまとめてしまったけれど、上記の文章はさらに深い含蓄がある気がしている。もう一度、自分の直面している課題と照らし合わせて、なぜそれをするのか(あるいは「なぜあえてそれはするのか」)を考えてみようと思う。

  

[Ruby] 二時間の仕事を一秒で片付けてくれる(かもしれない)三行スクリプト。

by tanabe on December 12, 2007

「テキストファイルの各行に一括で同じような処理をして、その結果を得たい」というようなことはよくあります。特に職場が Windows な環境だと CUI のツールが貧弱で、ついエディタでやってみたりしてしまって、半分くらいやったところで睡魔に襲われてどこまで作業したかわからなくなって全部やり直したり。

こんなコードを PATH の通ったところにおいただけで、非常に重宝しているのでご紹介します。はまったときには、笑っちゃうくらい作業効率が上がるかも。

script = ARGV.shift || ''
lines = $stdin.readlines.map {|li| li.chomp}
puts eval(script)

ファイル名に firter とでも名付けてやって呼び出してみます。

たとえば、c:\ruby\bin\rake ファイルからコメントで始まる行だけを抜き出したいときはこんなかんじ。

type c:\ruby\bin\rake | firter "lines.select {|s| s =~ /^#/}"

lines という変数名で標準入力の各行にアクセスできます。

各行に対して、前後の空白とか除去して、重複を除いて、ソートして、空行は除外した結果がほしい、なんてときも、これだけ。

type test.txt | firter "lines.map {|s| s.strip}.uniq.sort.delete_if {|s| s == ''}"

Ruby の強力な Enumerable モジュールと String クラスと正規表現で、大抵の用事は片付きます。

元々すぐコード書いちゃう人はちょっと手間が省けるくらいなんじゃ、とか、それ per(ry とか、それ aw(ry とか、ありますが、慣れると手放せません。

あと、

@ruby "c:\ruby\bin\firter" %* 

とか書いたファイルを firter.cmd として置いておくとうれしいかも。(c:\ruby\bin は適当に調整してください。)

s/firter/filter/ という指摘は受け付けませんのであしからず。  

システムを扱う者としてどう考えてもありえない障害の言い訳。

by tanabe on December 07, 2007

発生した障害に関する当社の見解。

「システムを扱う者としてどう考えてもありえない内容で、事実無根。当社がテスターとコンタクトを取る前・5日夜に、テスターが保護者同伴で当社を訪れ、『単なるいたずらで嘘を書き込んだ』と謝罪に来た」

これだ!
本番だったらテスターをコールセンターに変えれば OK という汎用性もすばらしい。

参考資料。http://www.itmedia.co.jp/news/articles/0712/06/news036.html

  

[Ruby] 海外の「Ruby で GoF のデザパタを実装してみた」が必見

by tanabe on December 06, 2007

Ruby でデザインパターンをやってみたよ、というのはそれほどめずらしくはないと思うけど、これは GoF の元ネタに引きずられず Ruby らしいコードで書かれていて、とても勉強になった。

もちろん、そこ、method_missing でやるのはどうなの?とか、自分なら違う形にするな、とか思うところはあるわけで、そこも含めて非常にためになる&おもしろかった。
読みたい人は、The GoF patterns implemented in Ruby から。

オブジェクト指向における再利用のためのデザインパターン
エリック ガンマ ラルフ ジョンソン リチャード ヘルム ジョン ブリシディース Erich Gamma Ralph Johnson Richard Helm John Vlissides 本位田 真一 吉田 和樹
ソフトバンククリエイティブ (1999/10)
売り上げランキング: 27191
  

XHTML+CSS 化に抵抗する上司はどう説得するか。

by tanabe on December 04, 2007

リファラ経由でXHTML+CSS 化に抵抗する上司はどう説得するといいでしょう?という内容の質問を読んだ。

顧客に「今どきテーブルタグでレイアウトしてるようなところに発注したくない」と思われるので営業面で致命的。仮にそんな顧客が10人に1人だとしても、そこから口コミで悪い噂が広まるリスクと良い噂が流れていれば得られたはずの営業機会の喪失コストを試算してみる。ほぼ仮説づくしにはなるけれど、そこは「パラメータは仮置きですよ」と言い切ってしまえばいい。ロジックに納得してもらえれば、主旨は伝わる。

そしてもう一つ。採用コストにも影響がある。Web の技術者なら転職先のサイトのソースくらいは必ず見るはず。現状を見ても入社を希望する人が優秀な技術者だと思いますか?と。採用にコストをかけておいて、さほどかからないであろうサイトのリニューアル費用を渋って人を逃すというのははたして効果的でしょうか?

技術的優位性を説いてもいいけれど、それ以上にたった今、デメリット垂れ流しなんですよ!ということを教えてあげた方がいい。その上で、「もちろん技術的には不安がありますよね。そこは私が皆を教育して乗り切ります。そのためにこのようなサポートをお願いします。」と不安点へのケアと実現可能だとイメージが湧くような提案も忘れない。てなところでどうでしょうか。本当は不安点の掘り下げから始めた方が早道なんだけどさ。

まぁ、「どうでしょうか。」などと言われても質問は締め切られているので困るだろうが、勢いだけで書いてしまった。Livedoor でブログやっているやつに言われてもとか、そんなことよりここのレイアウトずれをどうにかしろよとか、ツッコミどころは多いが受け付けない。

  

Exerb に D&D でパラメタ引数とするファイルを渡したいときの Tips

by tanabe on December 04, 2007

コメントで教えて頂いたとおり、ExerbRuntime の filename, filepath で対応する方が正しいです。便利!

Exerb は Ruby スクリプトを Ruby のインストールされていない環境でも実行可能な exe ファイル化することができるという、仕事で Windows 環境を避けられない Ruby ユーザにとって最高に便利で足を向けて寝られない品の一つ。

その挙動で、軽くはまったのでメモ。(考えてみれば当たり前の動作なのだけど)

Exerb で作成した exe ファイルに対して、引数にしたいファイルを D&D で指定した場合、実行時パスがユーザのホームディレクトリに設定されてしまう。そのため、File.expand_path などで期待したパスを得られなくて困ることがある。

File.expand_path(__FILE__).dirname Pathname.new($0).expand_path.dirname で期待するパスを取得したいときなどは、exe のショートカットを作成し、作業フォルダを exe ファイルのあるフォルダに設定。(デフォルトでそのようになる。)その上で、exe にファイルを D&D したい場合はショートカット経由で利用するようにすると、期待どおりの動作になる。

ついでに、もう一つの注意点として、$0 や __FILE__ で得られる値は rb ファイル時点の名称となる。仮に exe ファイルを作成した後に名称を変更したりした場合も、やっぱり Exerb によって exe 化した際の rb ファイルの名前を維持する。実行中の exe ファイル名を取得する方法は不明。

D&D はドラッグアンドドロップね。念のため。