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

最近は、秋元さんと一緒にならべて.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」に関してはちょっと言及したいことがあるので、後で書くかも。