今日は道の駅にある食堂で昼食を食べました

そこそこ田舎なので、田舎の人も来るという食堂なのだが、自動販売機を使っている人が様子がおかしい。お札が入らないというので、店員を呼びたいのだが、そのレベルでどうしたらよいか分からないようだ。自動販売機には「呼び出し」というボタンがあるのだが、これに気付かないとどうしようもないし、気付いたとしても、これが係員を呼び出すためのボタンだと理解できなければ意味がない。

「もういちど入れてみてはどうですか」と言ってみた。もう一度入れたらちゃんと受理された。自動販売機ではよくあることである。自動販売機に慣れていないと、それが分からない。

都会の自動販売機慣れしている人なら、お札が入らないときに、向きを変えて入れてみたり、裏返してみたり、そうすれば成功することがあると知っているだろう。そのような秘伝は知らない人には使えない。コインだって、裏返してみたり、もっと凄い技もあるのだが、あまり余計なことを書いたら面倒なこともあるかもしれないので控えておこう。

エアコンのリモコンの使い方が分からなくて冷房にできなかったというニュースがあった。この話、紹介したかもしれないが、おそらく、そのリモコンにも非常運転用のボタンがあったのではないか。リモコンで操作する機器の多くは、リモコンが使えなくなったときに最低限の操作ができるように、本体側にもボタンが付いているのである。それだって、そのことを知らなければ使うことはできない。

もう少しインターネット環境が普及したら、エアコンのような機器も全てインターネット経由で操作、モニターできるようになるだろう。設置したエアコンが長期間使われていない場合はサポートできるような体制にできればいいのだが、個人情報というややこしいものがあるので、結局はエアコンの使い方が分からなくて熱中症で…のような事故が起こってしまうのだろうか。

昨日からデバッグに難航しています

難航している原因が二つあって、一つは発生している環境とテスト環境のバージョンがあっていない疑惑があること。これはとりあえず現行の環境のバージョンを確認して解決した、というか、今のバージョンと問題になっている箇所の処理は変わっていないことが確認できた。

もう一つは、現象が再現しないこと。コードを見ても、処理は想定通りに実行されているように見える。メソッドに入るところと出るところでログに記録を残すようになっているのだが、両方ともログに残っているから、処理が正常に実行されて終了したことが分かる。しかし想定されたデータ更新が行われていない。

その原因も一部は分かっている。問題の環境は web service (soap) 経由で実行されている。テスト環境は一部がダミーになっていたり、モックを使ってテストケースを実行するようになっている。web service で呼び出されたときのコンテキストとの違いが結果の違いになっているのではないか。

時間もないので続きはまた明日…かも。

早朝に余計なことをして大変なことになりました

今日から数日出かけるので、サーバーに使っているpcを移動して、その部屋だけ冷房を入れたままにしようとしたのだが、それがよくなかった。動いているものは触るなというのはシステム管理の鉄則なのだが、止めたpcが起動しないというのを何度も経験しているのに、それでもやってしまう。

もっとも、日中に誰もいないと室温が40℃近くなる可能性があるので、そんな所にサーバーを放置しておいて故障するリスクも怖い。誰かいれば、どこかで冷房を入れるので室温が40℃というのは殆ど有り得ないのだ。

症状としては BIOS の設定画面も出てくれないという最悪のもので、おそらくハードディスクの故障だろう。このpcが外部からゲートウェイ的に使っていた入り口になるサーバーだったからさらに困ったのだが、急遽代替のサーバーを使って外から接続できるようにした。ただし、private key がないと接続できないし、web server は停止したままである。

ちょっと困ったのは、このサーバーでプログラミング作業管理用の redmine が動いていたのが使えなくなったこと。まあでも優先度の高い作業は作業中だから状況は分かっているし、対外向けの作業項目はメールでやりとりしている内容が残っているので何とかなるだろう。

データを生成するお仕事がありました

巨大なテキストデータ。具体的にいえば、約2GB超である。ただし gzip で圧縮したら 200MB 程度になるから大したことはない…のかな?

ちょっと昔なら 2GB というとどうやって受け渡ししようかと悩むところだが、今は USBメモリに入れて渡せばいいから楽である。もっとも、問題は受け取ってからそれをどうするかなのだが。

このデータを作るための事前テストに2時間程度。実際にできることを確認してから本番のデータを作って用意するのが1時間。大した作業ではないのだが、待ち時間ができる作業はストレスがたまる。こういう時は秘書がいてくれたら「これ圧縮してコピっといて」で済むから助かるのだが。

仮にさらに10倍のサイズになってくると、どうやって受け渡しするかちょっと悩むかもしれない。

オリンピックを見ていますか?

スポーツ競技は IRC などで chat しながら見ると案外盛り上がる。同じ映像を見ているから、本人同士は遠隔地にいても、一緒に近くで観戦しているような感じになるのだ。深夜の試合だと途中で寝てしまう人もいるようだが。

以前、スポーツではなく、アニメを見ながら chat というのもしたことがあった。テレビで放送されているアニメ映画だと、見ている人が同期が取れているからやりやすい。同時に同じビデオを見るというのもあったような気がする。ヨーイドンで同じタイミングで見始めるのだ。

最初に chat にハマった頃は、今のように深夜にアニメ番組は殆どなくて、何か不思議な番組が結構あったと思う。延々と風景を写しているとか、水槽の魚を紹介したりとか。そういうのを見ながら chat していたのだからよく分からない。遠隔地にいる誰だかわからない人と共有感覚を持つこと自体が面白かったような気がする。

 

わざと試合に負けるということについて

ロンドン五輪で少し前に、女子バトミントンダブルスの試合で後の組み合わせのことを考えて故意に負けたチームが失格になるという事件があった。バトミントンの連盟が「勝つための努力を怠る」ことを禁止しており、これに触れるというのが理由になったようだが、だったら選手もそれを知っているはずなのだから、失格になるのは仕方ないだろう。

サッカーのなでしこジャパンが、次の組み合わせを考えて、勝ちに行くのではなく引き分けを維持するような試合をしたという。そこでちょっと考えたのだが、もしこれが引き分けではなく負けないと次の組み合わせが不利になるような場合だったら、故意に負けただろうかということだ。サッカーは相手も負けに来ない限り、故意に負けるのは簡単な競技である。キーパーがゴールを防がなければいいからだ。何ならオウンゴールというやり方もある。

このような戦略で世間一般に認められているものとしては、野球の敬遠がある。場合によってはそれで負け越し点になっても、最終的に勝ちに行く限り許される。しかし、故意に負けようとするのは八百長となり、かなり厳しい評価が与えられることになるだろう。もちろん、長いペナントレースの中で負け試合を想定することはあるが、それでも試合は一応勝ちに行こうとする。

あくまで私見だが、日本人的なスポーツ感として、故意に負けるというのはかなりの抵抗があるのではないか。勝ち負けではなく、フェアかどうかということを重んじるような気がするからだ。

以前、オリンピックの野球のアジア予選大会で日韓が試合をしたとき、事前に交換した先発オーダーを韓国が直前に大変更して話題になったことがある。日本の感覚だと、そもそも相手を騙してまでして勝とうという発想がないのではないか。フェアではないからである。正々堂々という条件は、勝つという条件に勝る。

先程の疑問に戻って、もし故意に負けた方が後の組み合わせに有利ならサッカーの試合で故意に負けるということが有り得るだろうか。それはフェアじゃないから有り得ないような気がするのである。

今週は2日のアクセスが少し多かったようです

以前から書いているブログがいくつかあって、そちらから社長日記へのリンクを紹介したところ、その翌日の2日のアクセスが数十件あった。それまでの1日あたりのアクセスは毎日数件だったから、ブログから来たとみて間違いないと思う。ただ、ログ解析を見た感じでは、外部サイトから来たというカウントが増えていないのが不思議だが。

その後も1日あたりのアクセスが少し増えた状態をキープしているので、とりあえずここを読んでいる人が数名増えたような気がする。じゃあそれなりのことを書いた方がいいのかなと思うのだけど、先週末に痛めた腰がクリティカルになっていてどうもうまくない。かなり痛みは引いたのだけど、明日は様子を見て、もしかすると病院に行って検査してもらうかもしれない。水曜日はミーティングが入っているので外せないのだ。

毎週の予定は3通りの管理をしている。一つは Google カレンダー。ここに書いておくと他の人も参照できるように設定できるので、使い方次第では便利である。特定の人だけ参照できるように指定もできる。

もう一つは redmine。これはタスク管理を兼ねているので細かい状況を確認できるのだが、確認しただけでは事態は変化しない訳で、どんどんチケットが溜まっていくというチケット地獄の様相を呈する羽目になる。

もう一つはシステム手帳。これがこんなに長く使うとは思っていなかったのだが、確か、最初に入社したときに買ったのだ。以来、30年近く使っていて、かなりボロっちいし、ガタもきているのだが、ここまで使ってしまったらもう一生使うしかないかと思っている。

このシステム手帳に、東京都の主要箇所の地図が入っている。20ページ程度あると思うのだが、かなり前に買ったものだから最近の様子とは違っていたりする。そこで、最新のものに差し替えようとしたのだが、東急ハンズに行って探しても期待のものが見当たらなかった。最近はケータイで地図を見ることができるから、わざわざシステム手帳を見る人もいないのかもしれない。

受験勉強のテクニックも役に立つものです

最近、史上初の東大卒の落語家も誕生したそうだが、芸能界も高学歴を売りにする時代になって久しい。

クイズ番組によく出てくるロザン宇治原という芸人をご存知だろうか。京大芸人として微妙に有名。お笑い芸が全然面白くなくて売れないのでクイズの賞金で食っているという説がある。いや、バカにしているのではない、実際個人的には大ファンなのでバカにするわけがない。

最近この人のクイズの回答で面白いと思ったのが二つあった。

一つは他のブログで前にも紹介したけど、xylophone は日本語で何というかというクイズ。最初が「も」であることは分かっている。宇治原氏がこれを知らなかった。最初、phone というところから電話に関係あるのかと思ったらしい。しかし、saxophone という楽器があることに気付き、そこから楽器ではないかと想像して「木琴」と正解した。

英語の接頭辞、接尾辞の知識があれば難しい技ではない。受験勉強をした人なら、このあたりは定番の知識である。瞬時にそれを連想して回答できるというのは、受験勉強時の特訓が今になって活きているのではないか。意外なところで役に立っている。

もう一つはつい最近見たクイズ。漢字を9つ書いてもらって、それに関連した歴史上の人物を当てるというものだ。

宇治原氏は9つの漢字を見て、まず、マゼラン、コロンブス、パスコ・ダ・ガマを想像したという。ちなみに宇治原氏は歴史が得意らしいので、この程度の人がすぐに思い浮かぶのは驚くに値しない。漢字の内容から、正解はマゼランとコロンブスの2つにすぐに絞れた。どっちだろう?

宇治原氏曰く、もし正解がコロンブスなら誰かが「卵」というヒントを書くはずだ。しかし誰も書かなかったから、正解はマゼランに違いない。

正解がこれだとすればこのような言葉が問題に出てくるだろう、という逆の視点からの推測、これも受験テクニックの一つだが、かなりレベルの高いものである。京大芸人は伊達ではない。

今日はヒアリングがありました

という話は細かいことはもちろん守秘義務があるから書けないが、ちょっと腰をヤッてしまって椅子に座れないような状態なので、今日も休ませてください。すみません。名刺を初めて出したということだけ書きたかったのさ。

晩飯のラーメンを食べて席を立つときに腰をひねってしまった感じ。2週間ほど前から腰が痛かったのがやっと直ったと思っていたのだか、世の中そう甘くないようだ。もっとも、何とか歩ける程度なので、何とかなるだろう。

今日の日記はお休みです

忙しいので。今もちょっと作業中。

ちなみに、今日は体調がかなり戻ったのだが、大急ぎでやって欲しいという仕事が来たので本当に大急ぎでやった。途中まで作ってあったプログラムをチャチャッと変更して対応したので何とかなったけど、データの転送時間とか、大量のデータの処理時間とか、時間のかかりそうな処理にあらかじめ手を付けてなければヤバかったかもしれない。