18日から東京に来ています。今回は、21日にPHP Conferenceがあるとのことで、また、18日に東京で用事があったついで19日, 20日と開発会に参加しました。開催してくれたakkyさんとakiyanさんに感謝。

しかし、18日, 19日ってオープンソース関西が京都であったんですね。普段、京都にいるくせに、今回はそちらには不参加で、東京にいました。まぁ、縁がないものは縁がないんでね。

さて、開発会ですが、去年の12月から何度か参加させてもらっています。自分で主催したことはありませんが、akkyさんのAACamp、phaさんのもくもく会、そして今日このエントリを書いている場所を提供してくれたakiyanさんのヨセミテ開発会に参加しました。

最近は、ほぼ一人で開発をしているのですが、結構ダレてきてしまって、すぐ寝ころんでしまったり、ネットサーフィン（最近この言葉使わないね）をしてしまったりするんですね。しかし、こういう会があると、他の集中している人と一緒に緊張感を共有し集中することができて、重宝しています。

以前は図書館で開発をしていたときもあったのですが、開発会の方がいいと思うんですよね。というのも、図書館では、確かに周りに集中している人がいるのですが、開発をしているという雰囲気を共有できないからです。つまり、詰まってしまったときとか、誰にも話しかけることもできないので、結局一人となってしまいます。

しかし、開発会では同じような目的、つまり開発に来ているので、詰まったときにちょっと小話をしたりするなど、インフォーマルな会話ができるのです。このインフォーマルな会話が続いたら集中はできないと思うのですが、開発会に参加する人は、おしゃべりだけをしにきているわけではなく、開発に来ているので、それもありません。つまり、適度な量のインフォーマルな会話があるわけです。これが程よく気持ち良いです。

また、泊まり込みではなく、お酒で打ち上げるわけでもない緩い場というのもすごく気に入っています。お酒無しで解散というのが結構好きです。ときどきはお酒もあってもいいと思いますが、毎回だと疲れます。これは、旅行しているときもそうなのですが、私は、お酒無しで一緒にご飯を食べるような人間関係が好きなので、この緩い関係が激しく良いです。

というわけで、ここ1ヶ月で一番集中できているのではないか、というくらい進んで、ブログにその喜びを書いておきます。

ちょっと小ネタで、開発会で使っていたsfGuardPlugin周りのことでも書こうかしら。

ここ一ヶ月ブログを書いていなかったです。

最近は、秋元さんと一緒にならべて.com and Narabeの開発をしていました。初期のスケジュールからはだいぶ遅れてしまいましたが、リリースまでこぎつけることができました。でも、大変なのはおそらくここからなんですよね。

しかし、新サービスを開発するときに気をつけてることの記事が身に染みてわかりました。フィードバックがないとモチベーションを保つのが本当に大変です。

今回のサービスは、日本発で海外でも流行るサービス作りたいよねー、というakkyさんの第一段チャレンジとして、私もそれに便乗して、「じゃぁ、やりましょうか」といった感じになりました。なんという軽いノリ。好きな色が似ている、とか、ベトナムラブなところ、とかの技術以外の趣向が近かったのも一緒にやるきっかけになりました。

もちろん、今回のリリースは一段落ですが、まだまだタスクが残っていますので、どんどん開発していきますよー。ならべて.comをよろしくおねがいします。

問題がありましたら、メールでも、ならべて.com運営者ブログでもどんどん投げてくれるとうれしいです。フィードバックがモチベーションアップにつながりますから。

1/20 - 2/14くらいまで外こもりながら開発をしていたのだが、いくつか反省点があるのでここに上げておく。

１：田舎に行きすぎるとやはりネットワークに問題があり。

今回は、1/20 - 1/23までは、Pulau Langkawiで開発していた。Langkawiはビーチの島ではないので、ちょっと希望に沿わない。開発をするには、悪くない。Zackry Guesthouseという場所ではちゃんと無線がある。気温もいいのだけど、ビーチがなぁ。一応、第一段リリースはここでした。確かにちょっと日本のサーバへのアクセスは大変だったけど、まぁ許せるくらい。

そして1/23 - 1/31まではKoh LipeのPooh’s Bungalowで開発をしていたのだけども、ここでのネットワークはかなり難有だった。去年2日ほどいたことがあって、下調べをしていた。去年は部屋からアクセスできていたけど、今回は安定していた無線が部屋からアクセスできずに、不安定になっていた。Koh Lipeは、すごくいい雰囲気を持っているのだけど、インターネットの接続環境としてはよくない。最初は、ずっとこの島にいる予定だったのだが、計画を変更する必要があった。ちなみにこの写真がKoh Lipeでの私のオフィスw。ってかダイブショップで働いている人と仲良くなって、使わせてもらっていただけだけど。無線の設定をしてあげたり、PCの調子を見てあげたら相当喜ばれて、ビールを何本もおごってもらった。あまり、私は飲まないのに。。。

しょうがないので、2/1 - 2/13までKoh Taoに行って開発したが、ここは無線が安定している。私の中では、困ったらKoh Taoと考えるくらいだ。ダイビングの環境もバッチリだし、ビーチの質も良い。雰囲気もKoh Samuiよりも落ち着いていている。

このように一つの場所がダメだったら場所を移動できるようにしないといけない。まぁ、基準はYouTubeがそれほど苦痛なく見れる環境だったら開発ができるかな、と思う。回線が遅かったりして見えなかったら、開発はつらい。

また、インドネシアのPulau Wehにも連絡をとってみたが、無線の状況はつらそうだったので、今回は諦めた。

２：開発の初期時点とは違って、リリース時点では難しい。

上のと関係があるが、分けてみた。私の開発パソコンにはローカルで全て開発できるようになっている。普段からGNU/Linuxを使用しているため、Webサーバ等もセットアップしてあるし、必要なマニュアルは全てローカルに置いてある。ぶっちゃけ、開発するだけならインターネットにつなぐ必要はそこまでない。
しかし、リリース時点では別で小さな修正等をskypeチャットなどでやりとりしながら、進める必要がある。それに本番環境の動作確認やデプロイなどは、やはりネットワークがちゃんと使える必要がある。

３：日本のサーバまで遠い。

sakuraのサーバにsshで入って作業をしていたり、httpで動作を確認していたのだけども、遅い。タイだったらタイ国内のサーバにアクセスするのにはかなり快適だったけども、日本のサーバに入るのにはタイムラグがありすぎで、イライラした。

４：やっぱり一人はさみしい。

西洋人がカップルでイチャイチャしているところを、一人で行くというのは、少し堪える。一番いいのは、ペアプロができて、ダイビングのバディにもなれるパートナーを探すことだが、そんな人は、まずいない。

それでも、開発するときは一人でもいいが、カップルの中を一人飯をするのはさみしすぎる。かと言って、他のグループに入って飯を食べると、酒が入るので時間が奪われる。一緒にご飯を食べるだけの仲になりたいのだけど、なかなかそんな人はいないんだよなー。

まぁ、本来の外こもりのようにバンコクなどの都会でこもっていたら、問題無く開発できるのは確かだ。でも、私は秘境で開発したいと思っているので、まだまだ格闘中だなー。

というわけで、明日からSan Fransiscoに行ってくるですよ。その後は、懲りずにanother海外開発合宿に行く予定で、現在いろいろメールを投げているところ。面倒だけど、事前調査が大事だね。いくつかすでに目星を付けてあるけど、思ったより高くつきそうで現在更に調査中。

というわけで、搭乗寸前にポスト。

最近は、休日を図書館で過ごすことが多い。図書館に行くと、愛知県図書館の4Fにいることが多いのだが、もちろん書籍も借りる。その際は、目ぼしいものを最初から狙って借りにいく。そして、昔からずーーっと欲しかった本を借りることができた。それは、Code Complete第2版―完全なプログラミングを目指してだ。

しかし、高いの！Vol1とVol2両方買ったら1万超えちゃうから。。。個人じゃなかなか手が出せない。そして、こういうときにこそ図書館とずっと思っていた。しかし、Code Completeは人気があるためか借りられているときが多かった。しかし、たまたま前回図書館に行った際にVol2の方だけがあったので、Vol1を飛ばして借りることができた。つーか、すでに読み終わった。

つーか、やっぱりCode Completeはいいね。私のレベルにちょうどいいくらい。コードチューニングとかの細かなテクニックもある（実は結構泥臭いが、それがなんとも面白い！）けど、「完全なプログラムを目指して」と言っている割には、総合的なソフトウェア開発に関する書籍で、実際のコードはあまり書かれていない。ハッカー向けの指南書はCode ReadingやらWrite Great Codeなんだろうけど、こっちはもっと仕事で使っている人に向けているのではないか、と思う。少なくとも、私は、大満足。結構分厚い書籍なんだけど、サクサク読めて楽しかったYO

Vol1も読みたいな。明日図書館行く予定だけど、借りれるかな。お。そう言えば、明日はその後で、かのリチャード・ストールマンを見に行くのだ！楽しみ！
Richard Stallman 来日講演で知って早速申し込んだのだった。このGemmaさんはニコニコ動画にscript.aculo.usでマインスイーパを作る動画を上げてくれている。私も手元で同じように書いてみて勉強したよん。私が言うのもなんだけど、キレイなソースでした。つーか、Schemerってこんな書き方するの？私もやってみようかな。
しかし、名古屋では、技術者との交流がねー、と思っていたけどコッテリしている人が結構いるんですね。SchemeとかOCamlとかやってみようかな。今は、図書館で借りたふつうのHaskellプログラミング を読んでいる。遅延評価ってイイネ。まだ読み終わってないので、明日また延長で借りだな。

ねぇねぇ、先日ペアプロしたの！超楽しい！私のペアの人も外向的な人だったのでしゃべりまくり。。その時のペアプロで何が良かったか、ということを一応書いておこう。

1. 相手のペアが仕様に関して詳しくて、私が疎かったので、私が仕様に関して詳しくなった。
2. 相手のペアがその言語に対して知識が少なく、私が知識を多く持っていたので、ペアの学習になった。
3. 現在トラックナンバー１のコードをペアで組んで説明しながらやっていたので、ペアも処理が理解でき、とりあえずトラックナンバーを２にした。いや、まだだが、これから２以上になる可能性が大きくなった。
4. 私は横着なコードをたまに？書くのだが、ペアの目があるのでそんなことをせずに、その辺はちゃんとする。そして、思いつきで書いた修正が必要な継ぎ接ぎのコードを、その場で解決できるものは、どんどん解決していった。
5. 処理に躓いたとき、ペアと相談しながらやることで、リフレクションの効果があり、躓いたところを一人で悩むときよりも速く、楽しく解決した。
6. 仕事が楽しかった。

結局は最後のが一番大事やね。後、再確認したことなんだけど、確かにペアプロでも、フロー状態になるね。つーか、ペアがいた方が緊張しているからなりやすいのかもしれない。。

しかし、問題と思うこともある。ペアプロをするときとしないときを分けて仕事をしないと、していないときも同じ勢いで話しかけてしまう。つまり、集中している人にどんどん話しかけてしまうのだ。見て見てー！これって超エレガントじゃない？って。。。非常に申し訳ない。。。。なので、ペアプロするときは、時間を決めてこの時間からこの時間までとか、このタスクはペアプロするとか、って予め決めてからやらないと、ダメなんだろうな、と思う。というわけで、今後は気をつける。ってか、この辺は誰が決めるべきなんだろ。。。マネージャ？それともプロジェクトのメンバーが自発的に？この辺の時間とかタスクの管理はマネージャの管理下かな。

そこで語られるようなオフィスの状態で働いていないとき、自分が集中できないのはこの環境のせいだと思ってしまう。つまり、集中できないことを自分のせいでないと言い訳にしていたりする。

実際、ピープルウェアは良書と言われているように面白いんだけど、書かれている内容が羨ましすぎて、眩しすぎて、そんな状態にはいない時点で読むと嫌味にしか思えない。読む前は、集中できないのはしょうがないと思っていた自分がいたが、読んでからは自分のせいではないという気にさせられる。

読む時を間違えたな、こりゃ。

でも、実際の仕事をするようになると、自分が作っているものに関してはそうも言っていられず、やはりちゃんとしたものを作らなければ自分が納得しないし、そうでなければ士気が下がる。士気が下がるのははっきり言ってうれしくない。楽しいはずのプログラミングが楽しくなくなるし、どんどんリファクタリングをしていく気が失せる。「あー、動いたらからもういいや」、って。こう思うようになったら、きっと私もプログラマを引退するときだな。現在は、動いてもこのメソッドってやっぱこのクラスじゃねーよな、と思いながらリファクタリングしまくっている。外部から見たら、もう動くもの作っておいて何やってるんだろ？って思われているかもしれん。

でも、このときが一番大事だと思うのよ。作ったときが一番構造に関して頭に入っているので、どんどんリファクタリングをしていくことができるから。逆に「後でやる」とTODOとか書いておいても後でやるときには、そのときに何をやろうとしていたか忘れちゃう。というのは、大袈裟な表現だが、思い出しても、気づいた時にやらないと時間はよっぽどかかるし、「なんでこんなことしているんだろ。。。なんでそのとき書き直してないの。。。」って思って、やる気が落ちる。

うーん。まだまだやね。つーか、最近Joel on Softwareも読んだりして、なんだかマネージャよりの関心が増えてきたのかもしれない。。。Joel on Softwareの「あなたが絶対すべきでないことPART1」に関してはちょっと言及したいことがあるので、後で書くかも。

それともヲイラがバカなだけ？

もちろん独学なわけだが、Cではまったのは、他の関数から文字列を返り値として受け取るときの方法かな。あ、ちなみにここで言う文字列とは、文字の配列と同義なり。

つまり、C言語では、関数が文字列を返すことはできないのですよ！全てはこれに尽きる。文字列の先頭アドレスは返すことができますけどね。これには本当にはまりました。。。文字列という型がないのが、他の普段使っている言語と違うところでしたね。ってか、当然と言えば、当然なのですけど、頭の中では「文字列を返す」というスキーマができてしまっているので、当時はchar型の配列の先頭アドレスを返すといったことがイメージできませんでした。

つまり、こんなことをしちゃうわけ。

もちろん上のは動かない。

まぁ、
初級C言語Q＆A（２） - Ｑ　【文字列を戻す関数】
や
C言語講座：Bug4.htmｌ
を見ながらなんとかそのレベルを脱出しましたけどさ。しかし、このレベルを脱出するのに2年くらいかかった。まぁ、たまーにしか勉強していなかったけどさ。やっぱり近くにわかった人がいて聞けたら2年もかからなかっただろうなー。つーか、時間かかり杉。。。orz

つまり、自動変数で文字列を確保したところで、その関数の返り値は、文字の配列の先頭アドレスなので、ダメなんですよ。そして、その解決方法としてstaticを付ければいいって書いてあるけど、それは嫌なのよ。なんつーか、その方法は生理的に受け付けん。

ということで、残されたのは次の二つとなる。

• 関数の呼び出し元で文字の配列を予め確保しておく（静的に確保しても良いし、mallocで確保しても良い）。そして、そのサイズと一緒に引数にしてにその関数を呼び出す。
• 関数の中でmallocする。あとでfreeをする。

つーわけで上の動かないサンプルを動くようにするには、こうしてみる。ちなみにここで、mallocで失敗したときのことは考えていない。 （追記：Kさんの指摘の通りstrcpyはサイズは積極的にサンプルでも使わない方が良さそうですね。ここは、hogehogeという8文字ということで許してちょんまげ。）

まぁ、いろいろ考えた結果、自分に合ったスタイルで書くのが望ましいと考えていたところ、構造体をクラスのように使うのが私にとっては一番使いやすいと思うようになった。一気に飛んだな。つまり、C 言語によるオブジェクト記述法 COOL 4-2.再コンパイル不要インターフェイスのように。動的バインディング・インタフェースについては、私の理解範囲を超えましたので、よくわかりません。つーか、ifdefの嵐はどうも好きになれん。

それでもmallocやらfreeは処理コストが高いので、静的に確保した方が処理コストを抑えることができるみたいなんだけど、その静的に確保する際のサイズをどうやって決めたらいいか、よくわからないのが今のレベル。。。1024とか、4096とかって数字としてはキリがいいのがわかるんだけど、いつ1024を採用して、いつ4096を採用するなんてことが決められない。。。やっぱり動的の方がいいのよ。うーん。まだまだ先が長いなー。
(more...)

ということでいいのかね？

最近はよくブックオフに出かけて、面白そうな本があれば購入している。探せば良書もいろいろ出てくる。ファウラーのリファクタリングやら、ベックのテスト駆動開発入門やら、グラハムのハッカーと画家、デマルコのピープルウェアなどもブックオフで購入。ハッカーと画家が100円だったときはびっくりしましたYO。そのままamazonで売りさばこうかな、と思った。まぁ、先日いらない書籍を150冊ほどブックオフに引き取ってもらったのだが、1500円。。。まぁ、こんなものか。

で、例によってブックオフで購入したものにペアプログラミングという書籍がある。つい最近、読破したので、ちょっと書いてみるか。

内容は非常に軽いのだが、実はこの書籍には（少なくとも私とって）大事そうなキーワードやら引用がいくつか入っている。それらは、レイブやヴェンガーの正統的周辺参加やCoP、ハッチンスの分散認知といったもの。注文を付けるのであれば、ここにヴィゴツキーの発達の最近接領域というキーワードも入れてもらいたいところだ。とググったけど誰もそんなことは言ってないね。ここは私が提唱者となるという手も。

この書籍は、XPについて少しは調べたことがある人には当然のようなことが書いてあるので、特に新しいことはないけど上に書いたようにもう少し理論的なところが書いてあるのが私にとってはおもしろい。つまり、私にとっては9章が良かった。そしていろいろなパターンのペアプログラミングについて書いてある。専門家と専門家のペアとか。専門家と新人のペアとか。あと、アマゾンのレビューでは、翻訳がイマイチって書いてあるけど、そんなことはないと思うんだけどなぁ。12章以降のスキットが気に入らないのかなぁ。私はああいうの大好きなんだけどね。。

専門家 - 新人のペア

ゼウス（とても速くキーを打っている）： x = frobnatz.bar (1, y,
脅えた羊：すいません
ゼウス（依然キーを打ちながら）：なんだ。 errorNum+
脅えた羊（小さくなり，見つめながら）：なぜコンマの後ろにスペースを入れるのですか。
ゼウス（さらに速くキーを打ち）：いつもやっているからだ。（打ち続ける） 7);
脅えた羊（見ている）：どうしてですか。
ゼウス（キーを打ち，叫びながら）：だから，いつもやっているからだ。今度は君がドライブする番だ。
脅えた羊（とてもゆっくりとキーを打ち始める）： z = frobnatz.mumble(3,4
ゼウス（叫ぶ）：ちがーーーーう！（脅えた羊の後頭部を叩く）
脅えた羊（シクシク泣いて，さらに打つのが遅くなり）：<backspace><space>4);

えと、つまり、ペアプログラミングは、プログラマ同士のコミュニティ形成に関するものであると勝手に解釈しました。本当は、もっと上の人たちを巻き込んだ実践共同体と呼んでもいいと思うのだが、そこまで話がいくとややこしくなりそうなのでこの文章の中では入れない。結束したチーム（デマルコの影響から。。）としてのプログラマのコミュニティができると何がうれしいかというと、個々人の仕事は独立したものではなくなり、共通のプロダクトを目指す実践共同体となることでないかね。そして、実践を通して学び、そしてより自分の属する共同体が目指すものを作り上げようという意識が芽生える。そして、その結果、妥協をしないプログラムを書くようになり、バグも減る。また、ペアローテションによってトラックナンバーが1になることを避けることができる。ペアプログラミングをする際に性格上の問題はありそうだけど、絶対いいと思うんだけどなー。つーか、ペアプロしてぇ。ヲレのタイプとしては、「外向型」で「専門的への道を進行中の平均的」かな。。。

管理者を説得して、ペアプログラミングを推進しようとのことが書いてあるけど、やっぱり管理者は自分の管理するチームに関してのナレッジマネジメントは興味ないのかな？興味があったら普通に飛びつくと思うんだけどなー。ナレッジマネジメントを助けるアプリを作成するよりも、楽しいと思うんだけどなー。

Services_Competeに投票しようかみるために、まず、Competeって何？ってとこから始めたよ。

ほむほむ。Webサイトのトラフィックの比較とかをするらしい。
で、Compete Aboutを読むと、

Is this website safe from spyware and other threats like phishing?
How many people visit this site and how does it compare to other sites?
Are there promotion codes for this site that can save me money?

なるほどね。しかし、なんだか、ググルタソができそうなネタのような気もするが、

Today, search engines help us find sites, but they fall short of showing how safe, popular and valuable a site is.

と書いてあるように、今の段階ではしていないみたい。で、Competeは、なんだか独自の方法で評価する仕組みを持っているみたい。それが何かはよくわからんが、何百万もの人の動向を反映しているんだとさ。うーん。ググルタソが少し力を入れれば、速攻できそうな気もするが、その辺どうなんかな。つか、そこにお金儲けの仕組みがあると判断されれば、買収が一番早いのかもしれん。

で、だ。今回使用してみたかったのが、Services_Competeなのだが、CompeteのAPIをラップしたものということだ。CompeteのAPIでは、Compete Site Analyticsで手に入るようなデータをもらえるようだ。そして、それをうまいことマッシュアップしてみたらどうかね、といったものか。

まず、自分のサイトganchiku.comでやってみたけど

Sorry, we don't have any data for ganchiku.com. With more data, we can cover more sites.

とか言われた。なにー！どうせトラフィックなんてないですよ。うちのサイトは。

というわけで、結構大きなサイトを比較するのがいいみたい。Site Analyticsのページを開くと、mlb.comとnfl.comとnhl.comの比較をしているのがわかる。確かにネットではどのスポーツが見られる人気が高いのかわかるわけだ。なるほどー。ということは、だ。同じようなサービスでどれだけシェアを持っているのかを見るのにいいんじゃね、ということで、SBMサービスを提供しているところを比較してみた。diggとdel.icio.usとhatena。しかし、だ。バグ発見。。。

hatena.ne.jpがne.jpと判断されてるじゃねーか！つーわけで、Contact Usからバグ報告してみた。yahoo.co.jpとかならいけるんだけどね。なぜかne.jpはダメ。バリデーションが変なところで切ってしまっているのだろう。まぁ、おそらく他にもダメなものがあるのだろうね。

本当は、hatena.ne.jpをServices_Competeから使ってみたら、ne.jpと認識されていたみたいで、ソースを見たのだけど、どうも間違っていないっぽかったので、Site Analyticsで試したら、やはり、ということだったのだ。話をうまいことそれに持っていくことができなかったので、無理矢理話を作っちゃった。

(more...)

pear-devでよく議論になっているのが、BC breakに関して。昨日まで、BC breakってなんなん？って思っていたけども、親切なNohnさんが教えてくれたよ。

BCって言うのは、Backward Compatibilityで、後方互換性ってやつね。そして、PEARでは、PHP4のパッケージからPHP5のパッケージに移るに関して、BC breakがあって、そこでは、連番が降られている。。。

例えば、XML_RPCが、XML_PRC2へ。PHPUnitがPHPUnit2へ、と。
確かにこの管理の方法は嫌だなー。なんかもっといい方法はないものか。。

(more...)