Programmers Office

ブロックと手続きオブジェクト クロージャ、やっぱり良く分かっていませんが、10章で、手続きオブジェクトという名前で出てきました。 何でメソッドを使うだけではいけないのでしょうか？それは、メソッドでは出来ないことがあるからです。特に、ひとつのメソッドを他のメソッドに渡すことは出来ません(手続きオブジェクトなら可能です)。そして、メソッドは他のメソッドを返すことは出来ません(手続きオブジェクトを返すことは可能です)。これは単純に、手続きオブジェクト(proc)がオブジェクトであるからで、メソッドはそうでないからなのです。 この説明はなかなか良いと思います。ちゃんと名前を付けてメソッドを作ればいいじゃんと思っていたのが、ちょっとだけ解消されました。 そして、以下この2点から説明が続きます。 (1)手続きオブジェクトを受け取るメソッド その手続きを、どうやって、どんな時に、何度、呼ぶかのコントロールが可能になります。 ここでAOPの匂いをちょっと感じるわけですが、それは後ほど改めて。 (2)手続きオブジェクトを返すメソッド もうひとつ、手続きオブジェクトを使ってできるとてもクールな技は、それをメソッド内で作成して返すということです。これによって、 (遅延評価 とか、無限データ構造 とか、 カリー化 とか)といったあらゆるクレイジーなプログラミングパワーを得ることができます。 遅延評価[たらいを後回し]とつながりました。そもそも遅延評価という言葉になじみがないために分かりにくかったのですが、andalsoのことだと考えれば分かったような気にはなりました。 さて、最後に、(1)の省略形として、メソッドに対して(手続きオブジェクトではなく)ブロックを渡すことも可能だよという話が出てきます。その例は、プロファイラで、メソッドの最初に時間を覚えて、最後に時間差を取ってかかった時間を出力することができるという例です。プロファイルメソッドに本来の処理のブロックを渡せばいいので、本来の処理のコードを汚さなくてよいということです。出ましたね。最後の練習問題はロガーです。出ました。 練習問題の解答はこんな感じだと思うのですが（多少アレンジ）、やはり「log」という記述は、ログ出ししたいところに埋め込まないといけないのですよね。ブロックを渡せるので、開始・終了という出し方をできるのは良いのですが、やはりすっきりしない気はします。じゃあやっぱAOPじゃないのと考えてみるわけですが、しかし、アスペクトを織り込めるのはせいぜいメソッドのbefore/afterだろうと考えると、同等のことをやろうとしたらやはり同等以上の記述が必要になってしまうのだろうと、ちょっとクロージャの存在価値に納得したりしています。 — $nestingDepth = 0 def log descriptionOfBlock, &block puts (‘ ‘ * $nestingDepth) + ‘開始 ‘ + ‘”‘ + descriptionOfBlock + ‘”‘ $nestingDepth += 1 block.call $nestingDepth -= 1 puts (‘ ‘ * $nestingDepth) + ‘…. “‘ + descriptionOfBlock + ‘”‘ + ‘ 終了’ end

昼飯を津田沼シャロームで。ケーキもおいしいですし、おすすめですよ。 で、上に本屋があって、そこと連携して、雑誌がいくつか置いてあるのですが、日経エンターテイメントを見たら、好きな芸人嫌いな芸人みたいな特集で、タカアンドトシのインタビュー。 「ネタは半年作っていない。でもどんなに忙しくても作らないとダメ」 え・・・ 作る気はあるけど、作っていないと。これから察するに、作る気さえなくす人たちが大勢いると。 いじったりいじられたりも必要なのはわかるけど、プロとして漫才を極めたのかな？ そして、僕はちゃんとプログラマを極めていってるのか・・・？

プログラミング入門 – Rubyを使って を題材に、オンラインで勉強会をしようというナイスな社内企画に参加中。 0. はじめに まず、何をどうインストールしようか悩みましたが、最終的にはRailsもやるだ ろうということで、WindowsVistaでInstant Rails 1.7。 http://rubyforge.org/frs/?group_id=904 pathは手動で通す必要があります。 ついでにSciTEを使うこともないと思うので、エディタとしてRDEもインストール。 http://homepage2.nifty.com/sakazuki/rde/index.html Editor Propertyで文字セットを日本語にする必要があります。 が、3章までやってから、やはりmac側も環境を作っておこうと思い、Eclipse3.3 + DLTKをインストール。しかし、なぜかConsoleに出力されないので、さらにAptana + RadRailsを入れてみました。RadRailsによりRDTも入ったということになるのですかね。 入力補完が効きませんが、そのうち何とかなるでしょう。 なお、DLTKはちょっと分かりにくかったのですが、 http://ftp.jaist.ac.jp/pub/eclipse/technology/phoenix/europa/AddingFeatures/ これが分かりやすかったです。 4. 数と文字列の変換 標準入出力を使うプログラミングは普段しないので、chompとか新鮮。

Agile Estimating And Planning (Robert C. Martin) Mike Cohn by G-Tools <p> 第4章は、「Estimating Size with Story Points」。Stroy Pointsは相対的なサイズで決めるんですよというお話。<br />第5章は「Estimating in Ideal Days」。冒頭の「大きなことを達成するには二つのことが必要だ。計画と、十分すぎない時間。」ちょっとカッコイイですね。 </p> <p> で、第6章「Techniques for Estimating」がちょっと面白い。1,2,3,5,8,13というのは、フィボナッチ数列で、前の二つの和が次の数になるというやつです。大まかな見積もりをする時に、どのレベルで数字を出すかという問題があると思いますが、それにフィボナッチ数を使ったらよいのではということです。<br />概算は概算であることを示す必要があり、たとえば、これは40Hで、これは41Hだと言ってしまうと、1Hのレベルで違いがあるように見えてしまうわけですが、そうではないことが多いでしょう。逆に、10の倍数とかにしてしまうと、1Hと10Hが両方10Hになってしまいますが、そこは誤差が大きすぎるでしょう、ということで、フィボナッチ数列をアレンジした0,1,2,3,5,8,13,20,40,100を使うとちょうどよいのでは、という話は結構納得です。<br />0が入っているのも味噌で、30分以下の作業は0にしてしまい、ただし、0は本当は0でないことを共通認識として持っておくと、細かい作業の漏れもなくなるという感じです。 </p> <p> ちなみに、40とか100とかはちょっとした危険信号ですね。私もそんな見積もりをすることが多いですが、こういう作業はもう少しブレークダウンした方がよいのでしょうね。40Hを一つの作業としてしまうと、本当の意味での進捗確認も1週間できないということですからね。 </p>

昨日は、社内ライトニングトークス大会、AKIBA LT。自分の発表のことは記憶から抹消しました。というか、ごめんなさい、ごめんなさい。社内ブログではフォローします。 あまのりょーさん、ご参加ありがとうございました。 http://mugiwara.jp/ki2/wifky.pl?p=%282007.07.13%29#p1 そもそも行動力がすごいと思いますが、今回実感したのがマインドマップ力。参加していた女子ほぼ全員りょーさんの周りに集合（笑）。いや、そこではないですが。でも、そこのような気もする。もう一人、自分の趣味の格闘技を前面に出して発表されたOさんも、懇親会では格闘技ネタが尽きず、最後は体を触られてたりしましたが、自分というものをいかに表現するか、5分間プラス懇親会でそれができる力というのはすごいなと思います。そして、普段から思考を広げて自分を広げるツールとして、あるいはその成果物としてのマインドマップ力というものがあるような気がしました。 オブラブのネタを詰める際に、Buzan’s iMindMapをトライアル使用したのですが、気づいたら期限あと1日。最後に偏愛Mapを作ってみました。

ジョナサンのレッドアイは妙にきれいな色をしてますね。 で、飲みながら読んでいた本は。 JavaからRubyへ ―マネージャのための実践移行ガイド Bruce A. Tate 角谷 信太郎 オライリー・ジャパン 2007-04-21 売り上げランキング : 18262 おすすめ平均 マネージャを口説き落としたいRubyプログラマに Amazonで詳しく見るby G-Tools <p> 金曜日のLTに向けて、ネタを厚くするぞと。 </p> <p> そんな矢先、グループ会社内SNSでRuby勉強会の話がでておもしろそうだと思っていたら、一気に立ち上がってしまいました。スピード重要！勢い重要！ついて行くぜと思いながら、今週はちと無理なのですが、週末から始めますよ。 </p> <p> というわけで、一気にRuby熱沸騰中です。 </p>

先週、「議事録を集めてテキスト化」して内容をカウントしたらおもしろいかも、と書いたら、絶妙なタイミングで、Yahoo!デベロッパーネットワークから日本語形態素解析Webサービスが公開されました。素晴らしい。 実は、話の発端はこの辺のお話にあります。 http://d.hatena.ne.jp/habuakihiro/searchdiary?word=%cf%c3%a4%f2%ca%b9%a4%ab%a4%ca%a4%a4 （すごい検索の仕方してしまってすみません・・・） 人の話を聞く目的は何か。 誰かの意見に従おうと思って、自分が従うに値する意見を探す、ということがあるか。少なくとも建前上はあまりないように思います。（しかし、本音がそうだと、後で「誰々がこう言ったから」ということにはなると思います。） そうでなくて、ふつうは自分の意見を構築するために、参考として聞くのではないかと思います。で、上記ブログではそれを「ヒヤリング」としているわけです。 （もちろん、雑談から生まれるアイデアみたいなこともありますが、それは目的に向かうプロセスとは違う話なので、ちょっと置いておきましょう。） で、そういう目的で話を聞くのであれば、自分が参考にしやすい形で聞くべきであり、ただ「何でもいいから聞かせてくれ」と言って聞いてもだらだら時間ばかりが過ぎることになってしまうのではないかと思います。まず必要なのは、こうじゃないかという推論。話を聞き始めたところ推論がまったく違っていたというのであれば、もう一度やり直すしかない。次に必要なのが、議論をデータ化するための方向づけ。そのためにアジェンダを作ったり、参考情報を提供したり。 逆を言えば、自分が話をする時に、どうすれば聞き手の参考になるのか、相手はどんなデータをほしがっているのか、ということを考えるのが、大人の前向きさでしょうかね。

まだまだ若い（青い）ので、テクニカルな話もないと気が済まないのですが、今回最大のヒットはこちら。 CSS Dock Menu

こんな感じです。

いろいろあった一週間。 なんと言ってもオブラブで初スピーチ。 自分のしゃべりのひどさは、この際置いておいて、皆さんからの反応がうれしかったです。 こんな機会をいただけて、本当にありがとうございました。 さて、イベントと言えば懇親会。 若くて熱い人と話していると、ついつい興奮してしまういつもの癖が今回も。 Kさんと話しているときにメモしてもらったのが「『こうだと思う』がなくても、『こうしている』を話して、感じてもらえばいいんじゃないか」。自分自身も、「こうしている」を聞きたい。 今回の発表で前置きで話そうと思っていたのを削ったのですが、僕にとって、モチベーション=目標-現実。目標を高めるのも、現実を見据えるのも、人に押し付けられるものではないのは当然として、一人だけで生み出せるものでもなくて、刺激によって変化させるもの。事例という刺激はとても有効で、だからカイゼン事例発表会は多くの人に刺激を与えていて、その刺激を受けて新たな事例を生み出した一例として社内LTを一生懸命紹介したかったのです。 また興奮してきた。

やっと発表資料送付。自分的には力作です。練習では目標時間１５分ちょうど。がんばりま～す。 さて、土曜日はこんなイベントに参加してきました。 筑波大学大学院ビジネス科学研究科オープンキャンパス これから学校に通うのは無理だと思うのですが、お目当ては模擬授業「インターネット時代のマーケティングとデータマイニング」（吉田健一教授）。 ネタの一つが、テレビ番組でどのタイミングで何に注目されているかをどう判断するか。 普通に考えると、機械の力を借りるにしろアンケーをとるにしろ、時間ごとの視聴数を取得して、それぞれのタイミングで何をやっていたかと突き合わせる。 それぞれのタイミングで何をやっていたかは、各時間にアノテーションを付ける。すなわち、○時○分に何をやっていた、というコメントをどんどんつけていく。ただ、さすがにそれをビデオを見ながら人手で付けていくのはつらいので、料理番組ならレシピがあればだいたい付けられるし、ドラマならシナリオからつける。これが従来型。 これに対して、2chの実況板は、人気番組だと1時間に2万とかレスが発生するので、簡単な言語解析をして言葉を数えると一気に相当精度の高い分析ができる。そんな話でした。 まず一つ思ったのは、普段の仕事でこれを生かせるのは何か。すなわち、類似データが大量に集められて、それをカウントすることで分析できることは何か。 例えば、新しいサービスを考える際に、その分野で経験のある社員を集めて何をやったらよいかを聞いたりすると思います。しかし、そこはバイアスがかかり過ぎるというのは事実。自分が直接言われたことがある等主観が強すぎるわけです。 そうではなく、たとえば、関連プロジェクトのすべての議事録を集めてテキスト化し、「できない」「やりたい」みたいな単語をカウントすると、客観的に求められている事実が抽出できるのではないか。そんなことを考えました。 もう一つ思ったのがニコニコ動画の存在。面白いと思わせる仕組みがあれば、人は勝手にアノテーションを付けてくれるわけですね。 あとは、今回知った言葉として、10–fold Cross Validation。工学としてのテスト、みたいなことを今後考えていく場合、経験だけではだめで、知識としてこの辺も必要なのかななんてことを思いました。 http://q.hatena.ne.jp/1131250565