2012-01-24
■[読書] IBM 奇跡の“ワトソン”プロジェクト: 人工知能はクイズ王の夢をみる

学生の頃はクイズ研究会に所属してたので、「ワトソン、アメリカのクイズ王に勝つ」の一報にはマジかよ!?と驚いたものです。図書館に寄った時にたまたま見かけたので借りて読みました。ドキュメンタリー仕立てなので読みやすいです。
IBM 奇跡の“ワトソン”プロジェクト: 人工知能はクイズ王の夢をみる
- 作者: スティーヴン・ベイカー,金山博・武田浩一(日本IBM東京基礎研究所),土屋 政雄
- 出版社/メーカー: 早川書房
- 発売日: 2011/08/25
- メディア: 単行本
- 購入: 2人 クリック: 39回
- この商品を含むブログ (18件) を見る
この本を読むと、相当ワトソンさんに有利なルールだということが分かり、かなり納得。日本の早押しみたく問題の途中で押される訳でなく、問題文全部を見て聞いてから、よーいどんで早押しの模様。入力に関しても音声認識をしてる訳じゃなくてテキストで渡してるようだし、単純なQA(QuestionAnswering)に問題を落としこんでたようです。早押しボタンくらい?
このルールなら確かに勝てそうな気もするなーと今なら誰でも思いそうですが、プロジェクト開始時には相当厳しい感じだったんじゃないかなと思います。自分も学生時分に自分の研究そっちのけでよくTRECのpaperを読んでたものですが、当時は人間相手のクイズ大会などとてもとてもお話しにならないレベルだったはず。確かprecisionが野球の打率くらいだったような。どちらかといえばrecallの方に重きを置いた方向性だったような。
そういう意味では後書きに書いてあるように、問題設定の勝利という感じがします。なんとかなるかギリギリの線で、かつ分かりやすい目標。
相当有利なルールでその上結構いい勝負だったことからすると、日本の早押しクイズでこの手のシステムがクイズ王に勝つのはまだまだ無理っぽい気はします。が、これは多分Deep Blueがチェス王者に勝った時に「将棋ではまだまだだよねー」と言われてたのと同じで時間の問題なのかもしれません。アタック25にワトソンさんの弟子達が出てくる未来がくるのか楽しみです。
2012-01-08
■[Jenkins] 「Jenkins実践入門」を読んでみた

ようやく読み終わりました。
大変よくできた入門書です。既にバンバン使っててwikiを自力で読みJenkins勉強会に出たりしてるような人には少々もの足らないくらいですが、入門という意味ではとてもよくできてるような気がします。バランス良く「広く浅く」書かれています。一通り使う部分には触れられており、それでいて深入りしすぎていません。良い意味で「教科書っぽい」感じとでもいうのでしょうか。
これまで Jenkins を使ってるところは、ソフトウェア開発に苦労してる現場の人間がボトムアップの形で導入してきたケースが多いと思います。ただCIはこれから新入社員教育とかそのレベルからやってくべきモノだと自分は思っています。誰が言ってたのかは忘れちゃいましたが、「読み書きソロバンならぬ、ソフトウェア開発の基礎知識としてのVCS、ITSそしてCI」が必須の時代にもうなっているんじゃないかな。そういった「これから」の人用にとてもよい一冊だと思います。
2011-12-20
■[Jenkins] リモートAPI で Jenkins さんとお話をする

Jenkins Advent Calender 2011 20日目担当の akihirox です。名古屋が誇るリア充&イケメン&うさみみ*1な kyon さんの 「JenkinsでRedmineプラグインつくってみた(公開は来年になりそう) #jenkinsja - うさぎ組」 に続いて、一宮(愛知県の北の方)が誇る非コミュ以下略な私の出番であります。
そんな私ですが、最近金の力で jenkins さんのお友達になりました。友達が本気で少ない私にとっては貴重なお友達です。やったね!みなさんも是非お友達になるとよいと思います。
さて、真面目にコツコツとお仕事をしてくれる Jenkins さんですが、お仕事の最中でも話しかけると丁寧に答えてくれます。それが今日のお題のリモートAPIです。
とりあえずどんなものかは実際にAPI叩いてみた方が分かりやすいと思うので、jenkins自体をビルドしてるjenkinsさんにモルモtじゃなくて友情出演していただきます。
リモートAPIを叩くとここのjenkinsさんの情報が出てきます。URL の最後の xmlの部分がAPI形式で、xml、json、pythonがあります。
また、API形式を指定せず、/apiだけのURLを叩くと、リモートAPIの説明が出てきます。
リモートAPIで取得できる情報は、基本的に画面上で得られる情報ばかりですが、スクリプトなどからはとても使い勝手が良いです。ここでは簡単なサンプルとしてジョブの総数を求めてみましょう。
>>> import urllib.request >>> url = 'http://ci.jenkins-ci.org/api/python' >>> jobs = eval(urllib.request.urlopen(url).readall())['jobs'] >>> len(jobs) 313
コードは Python なので、python形式のapiを叩いています。それにしても313個ものjobが動いているとはさすが働き者ですね。
でこのリモートAPIはいろんなところで取得できます。
- ノードの一覧: http://ci.jenkins-ci.org/computer/api/xml
- Job: http://ci.jenkins-ci.org/view/Plugins/job/plugins_analysis-collector/api/xml
- Build: http://ci.jenkins-ci.org/view/Plugins/job/plugins_analysis-collector/312/api/xml
- テスト結果: http://ci.jenkins-ci.org/view/Plugins/job/plugins_analysis-collector/312/testReport/api/xml
いろいろ探索してみても面白いかもしれません。
depth と tree
リモートAPIで取得できる情報は、クエリパラメータのdepthを利用することでコントロールできます。
depth指定の無いものよりも多くの情報が取得できるようになります。しかし調子にのってdepthを深くすると、山程返ってくるようになるので、これまたクエリパラメータのtreeを利用して必要なものだけを取り出します。
以下はanalysis-coreの歴代ビルドの中で一番時間がかかったものを取り出してる例です。
>>> import urllib.request >>> url = 'http://ci.jenkins-ci.org/view/Plugins/job/plugins_analysis-core/api/python?depth=1&tree=builds[number,duration]' >>> builds = eval(urllib.request.urlopen(url).readall())['builds'] >>> max(builds, key=lambda x: x['duration']) {'duration': 102000455, 'number': 2644}
treeは上記のように、子供[孫[ひまご[...] ] ] と掘り下げるように指定し、兄弟はカンマで列記することで、必要なものだけを取りだすことができます。depthを指定しはじめると転送量がえらいことになりがちなので、treeとの併用がオススメです。
xpath
もう少し複雑なデータの取捨選択には xpath が利用できます。例えば、analysis-core-pluginで先週一週間に行なわれたビルドの平均所要時間は以下のように求めることができます。
>>> import time >>> import urllib.request >>> import xml.etree.ElementTree as etree >>> f = int(time.mktime((2011,12,11,0,0,0,0,0,0))) * 1000 >>> t = int(time.mktime((2011,12,18,0,0,0,0,0,0))) * 1000 >>> url = 'http://ci.jenkins-ci.org/view/Plugins/job/plugins_analysis-core/api/xml?depth=1&xpath=//build[timestamp%%3E%d%%20and%%20timestamp%%3C%d]&wrapper=builds' % (f,t) >>> res = urllib.request.urlopen(url).readall() >>> node = etree.fromstring(res) >>> n = len(node.findall('build')) >>> sum(int(x.text) for x in node.findall('build/duration')) // n 59465
ざっと60秒くらいといったところでしょうか。
日時の指定が面倒ですしxml形式でないと利用できなかったりしますが、範囲を指定できるのがありがたいです。日報週報の類の自動生成に強みを発揮しそうな予感です。
まとめ
以上、さらっとリモートAPIについて触れてみました。リモートAPIは他にもできることがありますし、Jenkinsはどんどん新機能が追加されるので、wikiや/apiをときおり眺めてみてはいかがでしょうか。Jenkinsさんとさらに親密になれること間違い無しです!
てことで明日は ikasam_a さんです。よろしくお願いします。
*1:直接の面識は無いのですが、伝聞によるとそんな感じの模様
2011-12-06
2011-12-01
■ 「デザインのためのデザイン」を読んでみた

気を抜いてたら二ヶ月くらい日記書いてませんでした。あわわ。
- 作者: フレデリック・P・ブルックス Jr.,松田晃一,小沼千絵
- 出版社/メーカー: ピアソン桐原
- 発売日: 2010/12/17
- メディア: 単行本(ソフトカバー)
- 購入: 5人 クリック: 82回
- この商品を含むブログ (18件) を見る
ようやく読み終わりました。後半がちょっとダルい感じですが面白かったです。
特に序盤のウォーターフォール批判が非常に納得のいくものでした。自分は普段一人開発で、お仕事でも趣味の延長みたいな感じだったりするので、かっちりとしたウォーターフォールというのは、適材適所できちんとやれば言うほど悪くないんじゃないの?とか思ってましたが、そういう問題では無いみたいですね。
支配的モデル、ということで、
- よく分からんけどウォーターフォール
- 何も考えてないからウォーターフォール
という事になりがちであるのが問題であると。そして、
- 管理やら契約やらで都合がいいから(開発には都合が悪いけど)、ウォーターフォール
との組み合わせが悲劇を招くと。なるほど。
頭使っていない以上なにをやってもダメなんでしょうけれども、ファーストオプションはもうちょっとマシなのにしとこうや、という話みたい。体系化/共通認識/教育 のためになにかしらモデルはいるのだけれども、それがウォーターフォールなのが問題。とっとと一番手から引きずり下ろすべきと。なるほど。
てことで、今後は「ウォーターフォールは有害である」に宗旨替えすることにしましましょう。

