pear-devでよく議論になっているのが、BC breakに関して。昨日まで、BC breakってなんなん？って思っていたけども、親切なNohnさんが教えてくれたよ。
BCって言うのは、Backward Compatibilityで、後方互換性ってやつね。そして、PEARでは、PHP4のパッケージからPHP5のパッケージに移るに関して、BC breakがあって、そこでは、連番が降られている。。。
例えば、XML_RPCが、XML_PRC2へ。PHPUnitがPHPUnit2へ、と。
確かにこの管理の方法は嫌だなー。なんかもっといい方法はないものか。。
今日は、元同僚とXP祭に行ってきた。
勉強会は、Rails勉強会に参加させてもらって、なんとなくイメージが掴めていたのだけど。。。「祭」のためか、最初思い描いていたものとだいぶギャップがあった。まぁ、こういうものなのね。
そのためか、一番私がよかったと思ったのは、C言語で組み込みをTDDで行こうってな内容のものだった。構造体をクラスの型として、その構造体のメンバをフィールドとして、OOPっぽく書こうというもの。メソッドは、その構造体のポインタを渡して、フィールドをごにょごにょして返したりするって感じ。なんか、PerlとかPythonは第一引数がそんな感じがするね。ほとんど書いたことがないからあってるかどうかは知らないけど。
まぁ、XPはコミュニケーションを積極的にしていかないといけなさそうだということはわかってきた。TDDだけじゃなくてね。
そう言えば、今日来ていた本間さんは、昔NHKのビジネス英語を担当していた本間さんの兄弟の方でしたね。その番組は、私が英語に狂っていたときにビデオで録画してよく見ていた。で、そこで、「相手との商談、もしくは上司を説得させるときの一言」として、彼が言っていた「Say, YES!」の言葉が忘れられない。言い方がね。「セイ、イエース！」って。ははは。
まつもとさんの講演は。なるほど。勢いのある方ですね。ってのが率直な感想だ。キャズムの話をしていたけど、普通のプログラマのためのRubyをアピールしていたことに、「へー」って感じだ。アーリーアダプターだけでいいような気もするけど、好きなことで飯を食っていこうと思えば、やっぱりマジョリティを引きつけることも大事なのかな。
あぁ。XPに関して一つ気になるのは、就業時間についてかな。XPは実践することが大事だと言われているし、思うのだけど、その実践の中に、週40時間？50時間？ってのがあったと思うんだよね。飲み会に参加しなかったから、そのことを聞くことができなかったけど、実際にXPを実践している人ってどうなんだろう。「みなさんは、忙しい。」とか、「徹夜」ってことをよく聞いたけど、実際問題、XPを実践することにおいて、就業時間はどうなっているのかなーなんて思ってみたりした。私は勝手に、XPをするってことは、徹夜で作業をすることの、反対にあるものだと思っていただけに、ショックだった。
確かに、私が最近遊びでプログラムが書けるのもデスマーチなプロジェクトにいないからで、仕事で、徹夜の連続だったら、創造性も何もないと思うのが率直な感想。つーか、冗談抜きで、それは鬱になるな。あ。あと、最後にコミュニケーションが大事で、連番で付けようというときに、「いや、それはまずいだろう」と思って、話し合いで一発で解決しなければ、やっぱり私は引いちゃうなー。使う言語によるけど、その言語がオブジェクト指向言語であれば、「そのくらい察してくれ！」と思ってしまう。そうでない人であって、一言言って変わらない人だったら、諦めそう。。
あ。あと平鍋さんのプレゼンは良かった。40歳とはとても思えないな。見た目はかなり若い。今日何度もあがってきた言葉の「ふりかえり」は、なんだかメタ認知的活動みたいね。でも、自分がふりかえるだけではなく、チームがふりかえるということが必要なんだろうね。
で、XPに関して個人的に思ったこととして、実践共同体、正統的周辺参加、メタ認知的活動といった言葉が合いそうでした。って、私が学生のときにやっていたテーマじゃん。こんなところで「こんにちは。」ですか？
最近やけにkernel panicが起きて、嫌になる。
で、ウノウラボさんでbadblockについて書かれていたので、チェックする。つーか大丈夫だった。
で、前から気づいていたのだが、DVDROM Driveを認識するときとしないときがあるので、/var/log/messegeを洗っていると、やはり。。。
Sep 23 08:52:09 muse kernel: hdc: status error: status=0x00 { }
Sep 23 08:52:09 muse kernel: hdc: status error: error=0x00
Sep 23 08:52:09 muse kernel: hdc: status error: status=0x00 { }
Sep 23 08:52:09 muse kernel: hdc: status error: error=0x00
Sep 23 08:52:09 muse kernel: hdc: status error: status=0x00 { }
Sep 23 08:52:09 muse kernel: hdc: status error: error=0x00
Sep 23 08:52:09 muse kernel: hdc: status error: status=0x00 { }
Sep 23 08:52:09 muse kernel: hdc: status error: error=0x00
Sep 23 08:52:09 muse kernel: hdc: DMA disabled
Sep 23 08:52:09 muse kernel: hdc: ATAPI reset complete
.. snip..
Sep 23 08:58:30 muse kernel: Unable to handle kernel NULL pointer dereference at virtual address 000
00000
Sep 23 08:58:30 muse kernel: printing eip:
Sep 23 08:58:30 muse kernel: c016f6e7
Sep 23 08:58:30 muse kernel: *pde = 00000000
Sep 23 08:58:30 muse kernel: Oops: 0002 [#1]
Sep 23 08:58:30 muse kernel: Modules linked in: i2c_dev i2c_core arc4 ieee80211_crypt_wep ds ipt_REJ
ECT ipt_state ip_conntrack iptable_filter ip_tables button battery ac yenta_socket pcmcia_core uhci_
hcd ehci_hcd hw_random snd_intel8x0m snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm s
nd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore ipw2100 ieee80211 i
eee80211_crypt e1000 floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
Sep 23 08:58:30 muse kernel: CPU: 0
Sep 23 08:58:30 muse kernel: EIP: 0060:[
Sep 23 08:58:30 muse kernel: EFLAGS: 00010287 (2.6.9-42.0.2.EL)
Sep 23 08:58:30 muse kernel: EIP is at create_empty_buffers+0x14/0x127
Sep 23 08:58:30 muse kernel: eax: 00000000 ebx: c131f680 ecx: 00000000 edx: 00000000
Sep 23 08:58:30 muse kernel: esi: 00000000 edi: 00000000 ebp: c131f680 esp: dee4dd18
Sep 23 08:58:30 muse kernel: ds: 007b es: 007b ss: 0068
Sep 23 08:58:30 muse kernel: Process hald (pid: 3342, threadinfo=dee4d000 task=df0c8700)
Sep 23 08:58:30 muse kernel: Stack: 0000000c c17e3934 c016fff6 00000220 00000220 00000001 c14db900 0
0008000
Sep 23 08:58:30 muse kernel: 00000046 c17e3938 00000000 00000000 c01e848c c17e3854 c0174789 c
131f680
Sep 23 08:58:30 muse kernel: 00000000 c17e3938 c17e3934 c131f680 00000000 00000010 c014b0a7 c
131f680
Sep 23 08:58:30 muse kernel: Call Trace:
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: [
Sep 23 08:58:30 muse kernel: Code: 89 f0 e8 03 ff ff ff 89 44 24 04 8b 44 24 04 83 c4 0c 5b 5e 5f 5d
c3 56 89 ce b9 01 00 00 00 53 89 c3 e8 08 f7 ff ff 89 c2 89 c1 <09> 31 89 c8 8b 49 04 85 c9 75 f5 8
9 50 04 8b 4b 10 81 79 6c 3c
Sep 23 08:58:30 muse kernel: <0>Fatal exception: panic in 5 seconds
となっていた。で、例によってググってみると、DVDROM Driveのエラーっぽい。そりゃあ、最近CDROMブートしようとしてもできんわけだ。どうやらハードが逝っている。というわけで、とりあえず外すか。。
ところで、4日間実家に行ってきます。ネットのない環境で4日間。Services_YouTubeのドキュメント書いていますので、もう少しだけ待ってください。。すいませーん。
もちろん、アウェーなわけだ。
XPは、前から興味があると言っているわけだが、どうもその機会がない。まぁ、何を持ってXPという言うかにもよると思うのだが。。。確かにユニットテストは、余裕があるときや、リファクタリングするときは、するのだが、どうも時間がないときとか、一生懸命作ったところが、「あ。ごめーん、やっぱこうして！」なんて言われてしまうと「クソー！」なんて思って、テストを作るのが嫌になるときがある。
先日、私の唯一の同期が東京からオフィスに来て、ソースレビューをしていたのだが、突っ込まれてしまった。「この1, 2, 3, 4って何ですか？コメントに『後で外に出す』って書いてありますが、それはいつですか？」って。そこで、苦し紛れに、「前は数で管理するものでなかったんだ。そして、今回がんばって作ったところだったんだけど、鶴の一声で変更がかかってしまって。。。」と言ってしまう。いや、わかっている。私がいけないのだ！横着をしてしまった私がいけないのだ！早速、今日その、マジックナンバーを外に出した。
今回は、こうやって突っ込まれて修正したのだが、これってペアプログラミングの真骨頂じゃないの？つまり、横着な行為に対して、突っ込み合うということ。その結果、一人で作るものよりも質の高いものができあがると思うんだよね。
というわけで、XP祭り関西2006に行ってみる。しかし、ワッハ上方って。。。ドーンセンター。とか。。大阪はネーミングセンスが一味違うな。。
昨日、会社の帰りに烏丸三条の大垣書店に寄った。
特に用事は無かったが、コンピュータのセクションに行くと、pythonの書籍を発見した。
今まで、pythonはやったことなかったけど、どうなんかなーなんて思って、よく見てみると8/26発売と。
そして、よく考える。買うのはいいけど、本当にやるのか？そして、この「みんなのpython」はいい書籍なのか？と。
とりあえず、家に帰って調べる。なるほど。待望されたpython入門書のようだ。というわけで、今日また、大垣書店に行き、購入。値段は、2800円か。まぁ、安いものだ。「たのしいRuby」も、第二版が出たときに買おうと思っているわけだが、まだかなー。それまで、python本でも読んで遊んでいようかなーなんて思う。
ぜんぜん関係ないが、PEARのcall for voteに行こうと思った。待つのに疲れた。pythonやrubyやりはじめちゃうぜ。と言いつつ、昨日は、Cを勉強していたし。本業はPHPなんだけどなー。
最近は、もっぱらSeleniumのことを考えているのだけども、ドキュメントに不備があることを発見した。日本語のドキュメントもおかしいところが多々あるが、英語の方も間違っているっぽい。
たとえば、storeSelectedが普通に書かれているが、実はこれないっぽいのだ。
私も、なんか与える引数が三つあるんだけど、どうするのかなぁ、と考えていてフォーラムを探していたのだが、同じことを考えている人がいて、実は、storeSelectedってないんだよね。。。といったことが書かれていた。
http://forums.openqa.org/thread.jspa?messageID=6042រとか参照。
まぁ、XMLで書かれた内容をXSLTでよろしく変換かけて自動生成しているっぽいんだけど、それがうまくいってないのね。
むー。Selenium.prototypeから始まるもので、doXXXってのをよろしく、XXXだけとって、AndWaitを全部付けて、そして、(is|get)系は、verify, assert それぞれの Not版などを自動的に割り振ればいいやって思っていたけど、それではうまくいきそうにない。
他にも、assertFailureOnNextや、assertErrorOnNextとかが書かれていないし。。。
うーん。PEARにがんばって載せようと思ったけど、どうやらSeleniumの方をもっと理解しないとね。。
ちなみに、日本語のリファレンスでは、storeSomethingSelectedとか書いているけど、おそらくないし。英語の方のドキュメントでは存在しない。まぁ、見ている英語のリファレンスが間違っているのだから、頭が混乱してくることは、確かだ。。。
うーん。うーん。うーん。
Selenium RCのPHPクライアントを書いたときは、JettyのHTTP Connectionを切ってくれない問題でうまくいかないし、SeleniumのHTMLを自動生成しようとしたときは、間違ったコマンドがあるし、なんだかなぁ。つーか、ヲイラもSeleniumの開発に入るように努力すればいいのかな。JavaScriptは嫌いじゃないし。ソースを見た感じでは結構きれいだし。
railsの勉強会に行ってきた。私は、普段rubyも使わなければ、railsも使っていない。それでもrailsの考え方は、アジャイルでいいよなー、と思っているので参加してきた。
そして、一つ疑問に思っていたところが解決された。それは、テーブルの制約に関してだ。私は、体系的にDB設計を学んだわけではないが、DBの設計はガチガチにやるのが普通だと前まで思っていたのだ。普段は、PostgreSQLを使っているからなのかもしれないが、外部キーや、文字数チェックなども、スキーマに定義している。いや、するべきだと思っている。逆に，外部キーとして扱っているのに、REFERENCEを貼ってないと、「誰だ！こんな設計したやつは！」と思ってしまう。
しかし、今日聞いた話だと、外部キーも、文字数チェックとかもモデルで全部やるべきだというのだ。つまり、今まで私は、この辺の制約は、DBのレイヤーで制御するべきだとずーーーーーっと思ってきたのだが、そうではないらしい。その代わりに、アプリケーションのレイヤーで制御するべきだと言うことだったのだ。なので、手動でDBを触るこはしないというのが前提なのであう。DHHもこれを推奨していると聞いたが、本当にカルチャーショック。ただ例外として、他のシステムと連携する必要がある際などは、ちゃんと外部キーとかも指定する必要があるとのこと。
確かに、DBの方で制約をつけて制御することと、バリデーションで制御する二度手間はうまい連携ではないよなー。DBの制約をつけたからって、入れるの失敗することは確かだけど、どうせバリデーションでかけるのだから一緒なような気もしてきた。なるほど。。。。
でも、なんかDB屋に言わせたら「ありえん！」と言いそうだなぁ。私が言ってしまったくらいだから。
このカルチャーショックを知ることができたことは、とてもよい収穫だったと思う。
今月のSoftware Designの巻末にYahoo! UI Libraryが載っていた。
最近、phpspotのYahoo! UI Libraryにあるサンプルたちを一覧にして載せていた。そして、そのリンクがはてブの注目記事に載っていた。
私も実は遊んでいたりするのである。でも、特に実践で試す機会がないので、理解はイマイチ。前回のMapQuestのお遊びは、遊びと言いつつ、ちょっとした頼まれごとから、ついでに使ってみようかなー的なノリから始めたので、ちょっと理解度が高い。つまり、実践で使用したDriving Directionに関しては一応詳しくなった。Yahoo! UI Libraryに関してはGrid以外のJavaScriptライブラリは実践で試してないからわからないけども。
Gridに関しては実は、MapQuestのお遊びで使ってなるほどねって感じで、試してみた。
で、実践でYahoo! UI LibraryのDOMを使おうかなぁ、と思ったけども、prototype.jsのInsertionに対応する機能がなかったので、採用しなかった。ただ、ライブラリとしては結構いいと思う。DOMのライブラリにInsertionができるAPIさえあれば、使っていたと思うから。
あぁー、でも、Yahoo! UI Libraryを使うとYAHOO.Utilとか書かなくていけないから、ちょっと抵抗あるなぁ。yuiならまだいいんだけど、そんなにYAHOOってアピールされると逆に引いちゃう。あと、ドットでくっつけすぎているのは、マイナスね。確かにOOPっぽくていい感じなのだけど、JavaScriptの処理系を遅くする原因だからね。と言いつつ、私レベルが作る可能性のあるものってパフォーマンスに関係ないので、こういうことを言っているのは良くないような気もする。今のPCのスペックだったら、問題なく動きそうだから。
prototype.js + script.acul.usとYahoo! UI Libraryのどちらが好きか、という個人的な感想としては、後者かな。まぁ、中身を読んだときの好き嫌いである。でも、先ほども書いたけども、YAHOOってアピールが強すぎるのは嫌。まぁ、しょうがないんだけどね。ところで、なんで、Yahoo! UI Library/方が好きなのか、と言うとドキュメントがキレイだから。そして、Yahoo! Design Pattern Libraryは確かに洗練されており、ソリューションとして素晴らしいことが大きい。このソリューションができるのも、今までのYahoo! のノウハウが詰まっているからこそである。このソリューションから、Webサイトを作る際にいろんな要素が使えると思う。あっ。でも、使ったことないけど。。。機会があったら使いたいなぁと思っている。おそらくYahoo! UI LibraryとYahoo! Design Pattern Libraryは連動しているしね。
yuiblogはチェックしているけど、こういうのもいいね。MLにも入ろうかしら。
今度は、これでお遊びかなぁ。ちょっとDrag and Dropで楽しそうなことができそうな気分だ。もちろん自分のためのツールとしてね。
世間は、Google様のAPIで遊んでいるところ、私は、MapQuestのAPIで遊んでいた。
今のGoogleMapには無くて、MapQuestにはある機能があって、それをどうしても使いたかったのである。将来的にGoogleMapが、その機能を実装したらMapQuestは企業として成り立たなくなるだろう。一般的なMapのAPIだけでは、すでにGoogleMapかYahooMapの方が上だと思うからである。
さて、話を引っ張ってしまった。そして、そのMapQuestのAPIとは。。。。Driving Directionである。出発と到着の住所、もしくは、郵便番号を入れることによって、その道を教えてくれるのである。詳細に、ここで、何番の道に乗り換え、とかね。そして、それぞれの乗り換えまでの時間も出してくれる。
残念なのは、日本にはこのサービスがない。アメリカとカナダかな。最近では、ヨーロッパも対応しはじめたようだ。
で、アメリカでこのDriving Directionって何がいいの？って思うかもしれない。しかし、考えてみたまえ、ワトソンくん。アメリカの社会とは、車社会なのである。確かにニューヨークや、ロスなどの大都市では、電車で移動ができる。しかし、ちょっと都心から外れたところに行こうと思うと車がないと生きていけない。さらに、多くの人がその都心には住んでいないのだ。
いやいや、カーナビがあればいいじゃないか！と思うこともあるだろう。しかし、これはなぜかは知らないがアメリカではカーナビが日本ほど普及していないのである。私は、未だアメリカにおいてカーナビが付いている車を見たことがない。技術的には可能だからそのうちに一気に普及するかもしれないが。
というわけで、MapQuestで調べることができるDriving Directionがとても約に立つのである。よくよく考えればインターフェースもいいかも。慣れているブラウザで出発点と到着点を入れればいいので、自分のブラウザでチョイチョイってやる感じでできちゃう。
で、使ってみた感想。
嫌なところ。
いいところ
日本でやるなら。。。。やっぱり、電車のDirectionかな。つまり、ekitanね。なので、ekitanが公開APIをフリーで出してくれるとうれしいなぁ。自分専用として、常に出発駅を自分の登録場所にしておき、到着駅と時間を入れるだけ。そうすれば、自分の移動手段の調べかたがより簡単になってうれしいからね。
使う用途としては、やはり、レストランのホームページとかかなぁ。つまり、訪問をねらうビジネスに向いていると思う。例えばレストランのチェーン店があって、それがマップかリストかは知らんが、適当に表示されていて、ホームページを見ている人が自分の郵便番号が入力できるようにしちゃうの。そしたら、びゅーんってDriving Directionを出しちゃったりするわけだ。そして、そのDriving Directionが出した結果になんかしらの関係のある広告なんて載っちゃったらGoogle様と同じビジネスモデルになるってわけ。全然話は違うけども、個人的に広告なんてWeb2.0なんかじゃないと思うけども。バナー広告だろうが、キーワード広告だが、違いはないと思えてしまう。
まぁ、そろそろ飽きてきたので、MapQuestのAPIのお遊びは、終了かな。
そいえば、MapQuestのForumで、公開APIを使うと必ず呼びだされるCSSファイルとJSファイルがあったので、それについて発言しちゃった。「みんな、CSSファイルとかJSファイルってこうなっているけど、話してないじゃん。ハックしようぜ−」みたいな感じで。
そういうところで発言するのは、初めてなので、レスが少しばかり楽しみ。既知なことでなければいいが。。。
(続きを読む…)
会社に入るまで全く知らなかった言葉、 XP。エクストリームプログラミング。最近、それを実践したいなぁ、と思っている。
きっかけは、次の三点からか。
１．やっぱり仕様変更が多い。
お上の一言で、すでに決まっている仕様やリリースしてしまっているものに変更を加えることになる。毎回そのためのテストをしていたんじゃ、プレッシャーの中で生きているような感じでビクビクしている自分がいた。
２．Rubyの影響
Railsの本を買って、自分の環境でテストしているわけだが、前から気になっていたユニットテストについて述べてあって、「ユニットテストは、当然だよねー」的なノリで書かれているので、ヲイラもユニットテストに憧れを持っていた。あと、Ruby勉強会に参加したときもテストファーストで書いているよって言う人が多かったので、これにも影響受けた。
３．自分の作ったものに対して自信を持ちたい！
まぁ、やっぱりテストな訳だけども、私もリリース後に見つかるバグとかも出しちゃっていたりするので、われながら、自分の品質管理に嫌になるのである。普段は楽観的にプログラミングをしているわけだけども、だいたいバグは潜んでいる。このバグに対して１と同じようにビクビクしているのである。
というわけで、これからはXP。まだ実践していないけど、先週からユニットテストを書いてからものを作るようになった。もう少し続けていけば、きっと私もテスト熱中症になるに違いない！
