平和な休日の朝が

今日は早起きして、のんびりSubversionのソースコードを読んでいた。また、いろいろな手続きがたまっていたので、整理をしていた。昼からは買い物に行こうと思っていた。今日はバーゲンのはずだし、いつも同じ服を着ているので、たまには服を買わないと。そんな調子で、平和な休日の朝を満喫していたら、ヒアリングの連絡ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

今回のヒアリングは、二つ目の提案に集中できるので、前回よりももう少しうまくできるだろう（前回は、短い時間で二つを説明したので、少し早口になった）。それにしても、やはり、一つ目の提案よりも二つ目の提案の方がうけがいい。５月くらいからこちらに集中していれば、デモも、もっともっと良くできたかもしれない。だが、今となってはそんなことはどうでも良いことだ。今は、今回どうやったら全力を出せるかしか考えられない。今回は、新たに資料を作る必要はほとんどないので、デモ用に新たにプログラムを作れるかもしれない。また、提出した提案資料には若干あいまいな点があった。二つの提案を同時に進めていたので、若干おざなりになってしまった箇所がある。ヒアリングまでに、そこを十分に詰めることもできるだろう。でも、それより何よりも、自分の頭の切り替えが重要だ。一つ目の提案への未練を捨てて、二つ目の提案に集中する。二つ目の提案に絶対の自信をもつ。これができれば、きっと良い提案ができるだろう。

普通の日

今日は、僕に良くアドバイスをくれる人が、会社に来てた。
少しは仕事の方も、調子が戻ってきた。

目標の設定

未踏ソフトも終わったし、次の目標に向けて頑張りたいと思う。というか、まずは、自分が夢中になれる目標を設定しないといけない。

夢中になれる目標がないと、仕事もはかどらない。僕は、いつも、やりたいことは土日にやっている。仕事がはかどるから土日の作業がはかどるし、土日の作業がはかどるから仕事がはかどるのかもしれない。ここのところやけに忙しかったので、「しばらく仕事を休んで土日の作業に専念しても良いかも」と思っていたのだが、未踏ソフトのような経済的基盤があるならともかく、それなしでやるのは危険かもしれない。

次の目標は、「Subversion on S3をリリースする」で良いかな。これが達成できたときの状況を、頭の中でイメージしている。この事前のイメージと達成後の現実のギャップが、自分を成長させるはずだ。

未踏ソフト

ヒアリングが終わった。
正直のところ、しんどい評価だった。
でも、自分の思いの方向性を微調整することができ、自分にとっては良い機会だったと思う。

それにしても、この一ヵ月半くらいは、なかなか充実した日々だった。
それまでは構想設計のレベルで、いろいろアイデアが発散していたのだが、
デモを作り始めてから、いろいろなものが一気に具体化されてきたと思う。

今後もこのペースで開発を続けていきたい。そうしたら、何か見えてくるものがあるかもしれない。

証明書の期限切れ

今の仕事で開発しているシステムでは、専用のCA（とそれを受け入れるクライアント）を自前で構築している。本日、証明書の期限切れに気づかず、サービスを30分程度止めることになってしまった。

期限切れに気づいたのは、期限が切れる１時間前だった。「英語OSで動くマシンから、サーバと接続できなくなった」という苦情を受けて気がついた。たとえ１時間でも、事前に知れたことは大きかった。事後だったらプレッシャーが何倍にもなるから、下手したら今日は帰れなかったかも。でも、うまくやればサービスを止めずにいけたかもしれない。その点は反省点かな。

それにしても、アクションを実行しながら、一方で、１時間で何とかなる方法がないかを模索するのは、とてもスリリングな体験だった。徹夜明けの眠さが吹っ飛んだ。

Subversion動いた

でも、まだデモレベルだけど。というか、急遽、デモレベルのものが必要になったので、排他制御や時刻同期の実装よりも、基本機能を先に作った。

これを見る人がどう思うか、反応が楽しみだ。すごいと思うかもしれないし、何とも思わないかもしれない。微妙なところだ。だから楽しみ。

早速動かしてみているが、思ったよりも、パフォーマンスは悪くない。今回未実装のところをしっかり作って、7月中には、リリースしたいな。

時速10km/s

ウィルコムでデータ通信用の端末をレンタルしようとしたら、クレジットカードが通らなかったので、ショップまで行くことにした。西院のウィルコムのショップに行ったら、「ここはウィルコムプラザじゃないのでレンタルできない」とか言われた。ホームページでウィルコムプラザを調べたつもりだったのだが、良く見たらウィルコムカウンターだった。orz

それにしても、西院は、思ったよりも遠かった。というか、西院というから西院駅の近くにあるのかと思っていたら、デルタ教習所の近くまで西に行かないといけなかった。行く途中、見つからないんじゃないかと不安になった。

帰り道、小さい女の子と自転車で競争となった。

僕は、27インチギア付の自転車に乗っているのだが、なぜか、小さい女の子の18インチくらいの自転車に勝てなかった。その女の子は、信号で必ず止まるので、そこで僕が抜き返すのだが、その後、しばらくすると、またその女の子に抜かれてしまう。そういうのが何度も繰り返された。

自分の知らないうちに、自分の力は落ちている。

自分は手を抜いているつもりはないので、自分のスピードが遅くなっていることに気がつかない。一方で、歳をとって要領だけは良くなっている（今日の競争でも、信号の渡り方は、僕の方がうまかった）。簡単な仕事では結果は何となく出せてしまう。だから、本人も、力が落ちていることに気がつかない。

心理学者のユングは、人を、思考型、感情型、直感型、感覚型に分類した。僕は、上の問題は、直感型の人が特に注意しなければいけない問題だと思う。直感型の人の直感が鈍ると、ピントが外れた言動ばかりになり、自分と周囲を傷つけることになる。気をつけなければいけない。

名刺を作成した

これまでは、自分の会社の名刺は作っていなかった。そんなことで、少しでも、今のお客さんに忠誠心を示せればと思っていた。だから、僕は、今のお客さんのところの名刺しかもっていない。

先週、そろそろ名刺を作ろうと思って、会社のロゴを作って準備していた。ネットで検索すると、2000円くらいで、ロゴも入って裏面印刷された名刺を作ることができることがわかった。

そして、来週、急遽、名刺が必要になった。そして、今からネットで注文しても、間に合わないことがわかった。orz

というわけで、今日、名刺屋さんに駆け込んで、名刺を作ってもらった。

ロゴを入れてほしいとお願いしたら、悩んだそぶりで「特別な機械で印刷する必要があるので8000円くらいかかる」とか言われてしまった。

うーん、こういうのって、値段はあってないようなものなんだろうな。彼らにとって値段を決めるファクタは、「お客さんがいくらだったら払うか」ということなんだろうな。今回、僕は、最初にお金をもっているそぶりを一瞬見せてしまった（そうしないとこちらの持ち込んだロゴデータをPCに取り込んでくれない恐れがあったので）。

結局、今回は、ロゴも裏面印刷も入っていないシンプルな名刺を作ってもらうことにした。

少し悩む

昨日の時刻同期の設計で少し悩ましいところがある。

今回は、Amazon S3の上で動くソフトウェアを作るが、設計的には、オンラインストレージを抽象化して、Amazon S3に依存しないように作ろうと思っている。そうしておくと、Amazon S3以外のオンラインストレージを利用することができる。例えば、ネットワークファイルシステム、WebDAVプロトコルのオンラインストレージ、XDrive（最近APIが出たらしい）とか。

そうなると、「サーバの時刻を取得する」というサービスを、どう設計するか悩ましい。以下みたいのが考えられるか。

・オンラインストレージのレイヤに、サーバの時刻を取得する機能をもたせる。ただし、オンラインストレージの種類によっては実装されていない可能性がある（現時点で思いつく限りでは、どんなオンラインストレージに対しても、何らかの実装ができそう）。
・「サーバの時刻を取得する」という専用のサービスを作る。このサービスは、オンラインストレージのレイヤを使ってサーバの時刻を取得する。
・アプリケーションは、「サーバの時刻を取得する」サービスによってサーバの時刻を取得する。

こうしておけば、サーバの時刻を取得できないようなオンラインストレージを利用することになっても、アプリケーションを変更しないですむ。上でも書いたように、現時点で思いつく限りでは、どんなオンラインストレージに対しても、サーバの時刻を取得する何らかの実装ができそう。なので、専用サービスを作るのをサボりたくなる誘惑にかられる。しかし、今回開発するシステムおける「オンラインストレージ」の定義として、「サーバの時刻を取得することができる」という性質を含めることに関しては違和感を感じる。だから、意味的に考えると、この機能を実現することができないオンラインストレージがあることを前提に設計を行わなければいけないことになる。

実際にものを作ろうとすると、一つ一つ技術課題が具体的に見えてくるので楽しい

昨日の仕事が遅くまで続いたので、今日は、仕事は昼からとなった。

昨日は帰宅が遅くなったのだが、遅く寝ても起きる時間はだいたい同じなので、今日の午前中は、暇つぶしに、S3 Subversionの実装方針に考えた。

検討していくうちに、複数のクライアント間で、時刻同期をする必要があることがわかった。だけど、サーバは立てたくない。かと言って、S3以外の外部のサービスも使いたくない。というのも、サーバを立てずに、設定も可能な限り不要で、かつ安全に、Subversionを使えるようにするというのが今回の開発のゴールなので。

となると、特別な通信などは行わずにS3を利用するだけで時刻を同期できれば理想だ。幸い、Amazon S3は、HTTPプロトコルで通信を行うので、レスポンスのヘッダからサーバ上の時刻を知ることができる。（ちにみに、Amazon S3サーバはクラスタリングされていて、接続するサーバは毎回変わる。なので、Amazonのサーバで時間の同期が取れてなかったりしたら、このやり方では破綻する。まあ、とりあえずは、Amazonを信じてサーバ間の時刻の同期は取れていると仮定する。）

Amazon S3サーバと通信するたびに、サーバの時刻とローカルの時刻を比べて、時刻のずれを計算すれば良さそう。リクエスト送信時のローカルの時刻をt1、レスポンス受信時のローカルの時刻をt2、取得したサーバの時刻をt3とすると、

　サーバとローカルの時刻のずれ ＝ t3 - (t1+t2)/2

となる。通信にかかる時間は変動するので、通信を行うたびにこの値を更新していく。

　時刻のずれ ＝ （前回までの時刻のずれ * 7/8）+ （今回の時刻のずれ * 1/8）

ただし、データサイズが小さい通信のみを、計測に利用しなければならない。データサイズが大きい通信では、上りと下りにかかる時間の差が大きくなるので。なお、1/8という数値は、昔のRTTの計算方式から採用した。こんな感じでだいたい妥当な値に収束するかな。