初めてのメンテナンス業務

つい先日、ウェブアプリケーションのメンテナンス業務を引継ぎ、無事完了したのですが、無駄な苦労をしました。課題は3つあって、

1. 本番環境には SSH でログインできない



2. 本番環境と、提供された開発環境は同一の構成ではない



3. システムやツールについて知識が不足している

だったと考えています。最初の2点は私が直接関与できませんが、最後の点について、いろいろと反省点があったので、自戒と未来の自分のために書き残しておきます。

開発環境と本番環境
プロジェクトから提供された開発環境でコードが動作することは、必ずしも本番サーバで動作することが保証されませんでした。それはそれで仕方ないとして、本番環境にできるだけ似せた開発環境を自前で用意すればよかったと思います。それができなかった原因のひとつは、技術的知識/技能の不足です。

MySQL、Apache、PHP それらが chroot された環境で動作するシステムなのですが、これらのコンフィギュレーションの知識がなかったため、自前で用意した環境が信用できませんでした。ほんとになんというか気休めな感じです。

デバッグのツール
基本的に、echo、var_dump、var_export あたりの原始的な関数を使っていました。状況によっては、これらでは足りない場合が出てくるわけです。

で、独自のロギング関数を用意しました。logging_log($obj, __FILE__, __LINE__); みたいな関数で途中記録をためておいて、logging_gethistory(); で記録を読み出すような感じです。これはなかなか便利でしたが、logging_gethistory()に到達する前に、エラーで停止すると見られないというどうしようもない展開です。

プロジェクトが終わってから「PHP デバッグ」で検索すると、いろいろとたくさんツールがあることが発覚。なぜ最初に検索しなかったのかと。

依存関係の把握
Michael Feathers の「Working Effectively With Legacy Code」（レガシーコード改善ガイド）という本を紐解きました。これは変更（デバッグを含む）が困難なコードを、いかに攻略するかについて書かれた本で、その中の依存関係を理解するというところが役立ちました。

たとえば、変数 $foo; の値がおかしい、あるいは関数 $func の動作が怪しい、と。そのときに、どこかで変更を加えていいのかどうか分からないのがレガシーコードです。そこで、この処理や値を変更するとどこに影響がでるか？ あるいはどこの値や処理の副作用で、当該箇所の出力が変わるのかを、簡単な図で会ておきましょう、と。非常にシンプルなプラクティスです。

どこかの値がおかしいとき、それらを逆にたどっていくわけですが、依存関係がかなり複雑でエディタでは追えませんでした。そこで、依存関係の図をかくとずいぶんわかりやすくなりました。グローバル変数の副作用があったりして大変でしたけど。

ユニットテスト
頻繁にファイルをアップロードできなかったので、一気にいろんな変更をしてしまい、ハマることもありました。そこで、機能を追加するまえに、手間がかかっても（当たり前ですが）単体テストのコードを書いて、本番サーバで動くことを確認するようにしました。

SimpleTest を使いました。これは、どっかのフォルダに置いておけばいいので、今回のように環境を自由にいじれないような場合にうってつけです。ユニットテストをするほうが、トータルのリードタイムが短くなりました。

今後
と、いうわけで、これらの反省を生かすべく、自宅サーバで簡単なアプリを運用してみようかなぁと思い始めました。そうすればインフラや環境について詳しくはないにしても、何に疑問をもつべきか、くらいは分かるようになるかな、と。ほんとは Google App Engine みたいなのが便利ですが、学習ってことで。

みなさんは、どうやって技能をみにつけているのか気になるので、コメントくださいませ。

Doing リストがパワフル

Doing リストというのが、生産性の向上に威力を発揮しそうな気がします。集中を強制するから。最初に Doing リストというコンセプトを知ったのは、おそらく「ゆっくりと動きながら高速でこなす、一流の研究者の Doing リスト」だと思います。

黄色いノートパッドはそんな彼を脱線させないための「いま、何をしているか」のリストなのだということが見て取れました。実際、彼はリストに書かれている以外のことは、いっさい実行していません。

他にも、フランクリン・プランナーのタスクでも「やっている最中」という意味で、TODO リストの□の中に、・をつけるというプラクティスがありました。なので、紙ベースでやるときなんかは、・をよく使っています。

これを Things でやってみるわけです。作業中のプロジェクトには「doing」タグを付けるようにしました。こうしておくと、doing タグを選択したらいつでも、作業中のプロジェクトに戻ってこられるわけです。

途中で他のことを思いついたらどうするか。

見つからずにいったんあきらめたファイルを「あ、あそこだったかも」と思い出した場合でも、そのコマンドを打ち込むのではなく、リストにそれが加わってゆくのです。

Things では受信箱にタスクを追加するためのキーボードショートカットがあります。これを使えば、doing プロジェクトから離れることなく、思いついた作業を使い出来ます。紙でもいいけどね。

ともかく doing タグがあると「えーっと次はなにするんだったっけ？」って考えなくていいです。doing のプロジェクトがなくなったら考えますが、それは「今日」のプロジェクトからピックアップするだけなのです。どれをピックアップするかは、それはそれで重要です。それはまた別の機会に（たんにルールが決まっていないだけ）。

Things の今日タスクの進捗をカウントする AppleScript

毎日の進捗を把握し、かつ、モチベーションを（ある程度）上げるために、その日にやるべきタスクの達成度を時系列で記録し始めたわけですが、手間がかかるんですよね。というわけで AppleScript で自動化しました。ほんとは、appscript の Python バインドでやろうとしたのですが、ビルドに失敗したので、AppleScript です。

Things の「今日」タスク総数と、達成したタスク数を表示します。けっこう処理に時間がかかります。

tell application "Things"
    tell list "Today"
        set open_tasks to 0
        set completed_tasks to 0
        repeat with task in (to dos)
            tell task
                if status is open then
                    set open_tasks to open_tasks + 1
                else if status is completed then
                    set completed_tasks to completed_tasks + 1
                end if
            end tell
        end repeat
    end tell
    display dialog "Total: " & (open_tasks + completed_tasks) & return & "Done: " & completed_tasks
end tell

アプリケーションにコンパイルしたもの

もどうぞ。

タスクをこなすペースを可視化する

終了させるのに何時間もかかるような作業は、小さなステップに分割してこなすことにしています。事前に計画を立てるクセがつきますし、進んでいってる感があるからです。

ただ、私がいまやっている仕事が、仕様をまとめる、みたいな仕事なのです。学生のときに論文を書いていたときもそうでしたが、「1章」「2章」みたいな分割のしかただと、先が見えなくて、くじけてしまいます。

そんなわけで自分のモチベーションを保つために、タスクを分割するだけでなく、その時間的な進捗を見るようにしてみました。

eXtreme Programming の本だったかに、テストの結果を時系列で記録しておけみたいなことが書かれていたのを参考にしています。ときどき、タスクの数が急激に増えるのは、作業途中で、大きなタスクを小さなタスクに分割するからです。なので完了/未完了の比率も描いて、状況を把握しやすくしています。しやすいかどうか、ちょっと微妙ですが。

で、このグラフがあると、タスクをこなすペースが分かるんですね。このままでは間に合いそうになぁとか、いいペースだとか。ちょっと厳しめの目標値を立てておいて、それに追いつくように頑張ります。

ただし、この方法は作業集約的なタスクじゃないとうまくいかないかも知れません。

PEP 3003 Python Language Moratorium

PEP 3003 Python Language Moratorium が accept されたようです。この PEP は、当分の間、 Python 3.x の文法を変えませんよ宣言するものです。この変更の一時停止期間をモラトリアムと呼んでいます。

モラトリアムの意図は、Jython や IronPython などが、Python 3.x を実装しやすくするためです。しばらくしたら、IronPython の 3.x 系が出てくるかも。以下、おおざっぱなまとめ。

• Python 3.1 リリース以降、2年間は Python の文法、セマンティクス、ビルトイン関連の変更を行わない。



• Python 3.2 リリースはモラトリアム期間内なので、言語への変更はない。



• Python 3.3 リリースはモラトリアム期間外なので、言語への変更が起こりうる。

変更しないもの

• 新しいビルトイン



• 文法: 文法ファイルは不変とし、あいまいな理由で修正をしてはならない。



• セマンティクス: 特定の例外（下記を参照）をのぞいて、言語としての動作は現状を維持する。



• __future__ でインポートできるもの: 言語の文法やセマンティクスに影響するので。

場合によっては変更するもの

• ビルトインの新規メソッド



• 不適切なセマンティクスの修正: 言語のセマンティクスがあいまいだったり、元々の設計に反して、不適切に実装されている場合は、セマンティクスの変更してもよい。



• セマンティクスの実装が、著しく困難な場合: CPython 以外で、Python 3.x を実装することが著しく困難な場合には、他の VM にがPython 3.xの採用を容易できるようにしてよい。

変更してもよいもの

• C API



• 標準ライブラリ



• 3.x から 2.x へのバックポート



• import のセマンティクス

BP Study #27 で Python 3 について話しました

勉強会 BP Study #27 で、Python 3 について話しました。内容は、Python Code Reading 03 の内容とほとんど同じで、3.1 のことを、ちょっとだけ追加した程度です。Code Reading と BP Study は微妙に参加者が違うので、これでいこう、と。

bpstudy27 Python 3 資料

Python 3 がリリースされてから 1年ほどたちますが、まだまだ Python 2 から 3 への移行は進んでいないようです。Python 開発陣も、そんな性急な移行を期待しているわけではないようですし。

ただ個人的な、そしておよそ合理的ではない期待として、Python 3 への移行が進むとよいな、と思っています。理由のひとつは Python 3 の言語としての一貫性が、好きであるということです。next(x) よりも x.next() のほうがいいとか、些末な不満はありつつも全体として Python 3 が好きです。

Django や GAE が、まだ Python 2.x ベースなので、いきなり業務へ、というわけにはいかないにしても、個人ベースではいくらでもできることはあると思います。というわけで、文書書いたり、既存ライブラリの移植とか、そういうことをやってみようかな、と小さく囁いてみる。

assigned vs own ではなく

今朝がた、

プロジェクトを assign されたのではなく、own していると考えると、何か変わったりするのだろうか。こういう体育会系的な気持ちの持ちようみたいなのは嫌いだけれど、アクションに影響が出るなら、気持ちの持ち方を変えてみたい。

などと、つぶやいたのだけれど、これがあまりにひどい言い方なので、ちと書き直し。というか、まとめ直し。

少し前まで、大きめの組織に所属していました。やりたくてもさせてもらえないことがあった一方で、他の人にお願いできることもたくさんあったと思います。

今は小回りのきく組織に所属しています。そうすると、他の人にお願いできることが減った分、自分が決めていいこと、やっていいこと、やめていいこと、ほっといていいことなどの選択肢が大幅に増えました。これは予想の範囲。

予想していなかったこと（でも予想は可能だったはず）は、自由度が大きくなると、制御しようとする系が複雑になるということ。そんなことは、大昔に学校で習ったことであるのに。締切ひとつとってもそう。数ヶ月後にまとまった成果を上げないといけないとしましょう。そのためにいくつかの細かいタスクが存在します。各タスクの締切をいつにするか。来週でもいいし、再来週くらいでもよい。でも幅をもたせていていては締切にならないし。で、締切の設定の仕方によって、成果が変わる可能性があって、じゃあ成果側を定義しようとすると締切に影響があって、みたいな非線形な関係になっていたりする。

そして、こういうときの工学的な解決方法も学校で教わっている。境界条件を満たしておけば、とりあえず適当に決める。そして、適当に決めた数字の妥当性を評価し、その結果によって、数字を上げ下げする、というのを繰り返すのが数値計算のやりかた。

で、assign と own に話をもどしましょう。一般に assign された仕事は自由度が低く、own している仕事は自由度が大きい傾向があるような気がします。一般にそういう相関がありそうである、という程度の意味で。実際に私が直面していたのは、自由度の大きさのせいで、問題解決空間の大きさに圧倒されていただけだったのだと、今頃気づきました。

伯林旅行記 3日目

はじめて屋台やカフェ以外での食事。もっと早く入っておけばよかった。ドイツ料理好きかも。

Loebenbaeu Pils

Berliner Weisse

やたらと Berliner Weisse を飲んでいますが、甘いお酒ですので念のため。

これでベルリンはおしまいです。明日は帰国のための移動だけ。

伯林旅行記 2日目

KaDeWe というデバートの上のほうの階は食料品売り場で、同じフロアで食事もできるようになっています。

Franzeskaner (Weissebier)

で、昨日と同じお店で。

Markischer Landmann (Pilsner)

Javer (Pilsner)

伯林旅行記 1日目

カフェ

ドイツ経験の豊富な知人におすすめのカフェを教えてもらったので、行ってきました。メニューにミートボールと書いてあったのを注文したら、ハンバーグ的なものがでてきました。でけぇよ。飲み物はホットチョコレートにベイリーズを混ぜたもの。寒かったので暖まりました。

ビール

この日は、昨日とは別のバーに行きました。硬派な女性と、あきらかにこき使われている男性店員がいるお店です。女性のツンデレっぷりに萌えです。デレを見せてくれませんが。

Berliner Wisse （赤）

Shoeffer Hofer

Berliner Pilsner

伯林旅行記 0

先週、職場での最終出社日でしたので、空いている時間を使ってドイツのベルリンに来ています。およそ旅行だとか観光だとかをしたことがないので、どうしていいか分からず、でもとりあえずヨーロッパに行ってみたいなぁという、どうしようもない動機で来ています。

搭乗口でぴこーんぴこーん

成田→フランクフルト→ベルリン、という飛行機でした。成田からフランクフルトの11時間はだるいなぁと思っていたのです。で成田での搭乗口で改札機みたいなのに搭乗券を入れてもらいますよね。あそこで、ぴこーんぴこーんとアラームが鳴るわけですよ。

ちょっとだけ英語が分かるのに、敢えてアメリカを避けている理由は、いつも出入国で別室に連れて行かれるからなのです。なんかとなりで「私が帰らないと、うちの小さい子たちはどうなるの」とかって泣き崩れているおばちゃんの横で、「で、最後にアメリカに来たのはいつだって？」とかの質問をされるのが、もう面倒で面倒で。フライト逃しそうになるし。

なのに、搭乗口でぴこーんぴこーんですよ。泣きそうになりながら係の人と話してみると、満席なのでビジネスクラスの席を用意した、とのこと。やったー、わーい。というわけで快適な11時間でした。

ちなみに国際線に乗るときには、必ず襟付きシャツ、ジャケット、革靴着用です。これが利いているのかどうか、まったく検証していませんが、何度かビジネスクラスに乗ってます。しつこいようですが、検証してません。

ビールっす

この旅行はドイツに行くこと自体が目的なので、現地でのプランはまったくありません。とりあえずビール飲んでおこうくらいなもんです。というわけで、到着したのが夕方で、ぶらぶらしつつ適当に屋台でソーセージ食べたあとは、ビールのお店へ。

Berliner Weisse なるビールのカクテルみたいなのと、Berliner Kindle なる苦いのをいただきました。Berliner Weisse のほうが甘いシロップみたいなのと混ぜるので、Weissebier 特有の臭いに気づかずに飲めました。

EC2 で Django を動かした その2

前回のつづき。

開発サーバと本番サーバの設定

IBM developerWorks の記事のリスト9にあるように、settings.py を開発サーバと本番サーバを if 文で分けておきます。

import socket
import os

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

if socket.gethostname().startswith('mylocalhost'):
    DEBUG = True
    DATABASE_ENGINE = 'sqlite3'
    DATABASE_NAME = 'data.sqlite'
    ...
else:
    DEBUG = FALSE
    DATABASE_ENGINE = 'mysql'
    DATABASE_NAME = 'myappdata'
    DATABSEE_USER = 'myname'
    DATABASE_PASSWORD = 'mypassword'
    ...

のように書きます。私の場合は、データベースの設定くらいしか違いはありません。

デプロイするスクリプト

（生の Django ではなく）Goole App Engine のいいところは、開発コードをそのままデプロイするツールがついていることです。で、まあ、あそこまでデキはよくなくていいので、似たようなコードが欲しいなぁと思って、簡単なシェルスクリプトを書きました。

#!/bin/bash

HOST=$1
IDENTITY_FILE="/path/to/key.pem"
SRC=`dirname $(dirname $0)`
DST=root@${HOST}:/srv/django

if [ $# -eq 1 ]
then
  rsync -auvz --delete --exclude "tools" --exclude ".hg" --exclude "*~" --exclude ".DS_Store"  -e "ssh -i ${IDENTITY_FILE}" ${SRC} ${DST}
  ssh -i $IDENTITY_FILE root@${HOST} apachectl restart

else
  echo $0 host
fi

これを Django project のディレクトリと兄弟になるディレクトリ tools の中に、deploy という名前で保存しておきます。

• /path/to/djangoproject



• /path/to/tools/deploy

ですね。で path/to ディレクトリ内で、tools/deploy hostname で呼び出します。

まず rsync を使って、サーバ側のファイルを更新します。手元のPCは Mac なので .DS_Store ファイルを除外したり、mercurial を使っているので .hg フォルダを除外したり、Emacs を使っているのでバックアップファイル *~ を除外したりしています。

続いて本番サーバのアパッチを再起動するところまで、deploy スクリプトに任せています。

ホスト名を明示的に入力するようにしているのは、きっと将来、テスト用にサーバを作るだろうなぁと考えてのことです。EC2 を使っているので、バージョンアップをする前に、まったく同じ環境のインスタンスを立ち上げてテストするのに、ほとんどお金がかからないので。

今はまだ固定IPを取っていないのですが、人に見せられるようになったら、ドメイン取って公開する予定です。

EC2 で Django を動かした

Django を動かすのに mod_python の入った本番サーバなんてないぞとつぶやいたら、@voluntas さんにEC2を勧められました。その顛末。EC2 のアカウントを取るとか、ssh でつなげる方法とかは割愛します。

MySQL、mod_python、静的ファイルは Apache で配信、/ パスがウェブアプリのルート、を想定しています。

AMI の選択
使用した AMI は、Quick Start カテゴリにある、Getting Started on Fedora Core 8 (AMI Id: ami-3c47a355) です。「Minimal Fedora Core 8, 32-bit architecture, Apache 2.0, and Amazon EC2 AMI Tools.」というやつです。特に深い理由はなくて、プレーンな Apache が欲しかっただけです。

パッケージのインストール
データベースには MySQL、Django の実行には mod_python を使います。MySQL は LAMP の M だから。mod_python は、公式ドキュメントでおすすめになっていたから。という程度の理由で選択しました。注意すべきは、python 2.5、Django 1.0 であることです。

# yum install mysql MySQL-python mod_python Django

ディレクトリ構成

• /srv/foo/project ... Django プロジェクトディレクトリ。django-admin.py startproject で作るやつ。



• /srv/foo/static ... スタティックファイルのフォルダ



• /srv/foo/templates ... テンプレートのフォルダ



• /var/www/html/media ... /usr/lib/python2.5/site-packages/django/contrib/media へのシンボリックリンク



• /var/www/html/project ... /srv/foo/project へのシンボリックリンク



• /var/www/html/static ... /srv/foo/static へのシンボリックリンク

Apache の設定
/etc/httpd/conf/httpd.conf の最後に以下を追記。

<Location "/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE project.settings
    PythonOption django.root /project
    PythonDebug On
    PythonPath "['/srv/foo'] + sys.path"
</Location>
<Location "/static">
    SetHandler None
</Location>
<Location "/media">
    SetHandler None
</Location>

その後、

# apachectl restart

して、/ にアクセスすると、It works! が出たような気がします。

MySQL の設定
ここらへんからが記憶がかなり曖昧です。

/etc/my.cnf を以下のように編集 (参考 http://d.hatena.ne.jp/MOZZ/20070809 )

[mysqld]
（省略）
default-character-set=utf8
skip-character-set-client-handshake

（省略）

[mysql]
default-character-set=utf8

つづいて、確かこんな感じ。

# mysql -u root -p
Enter password: 

mysql> CREATE DATABASE foo_db CHARACTER SET utf8;
Query OK, 1 row affected (0.01 sec)

mysql> GRANT ALL ON foo_db.* TO 'username'@'localhost' IDENTIFIED BY 'mypassword';
Query OK, 0 rows affected (0.03 sec)

mysql> quit
Bye
# /etc/init.d/mysqld restart

以上が、本番サーバの設定。あと settings.py 内部での開発/練習サーバの設定わけと、デプロイをするためのスクリプトを書きました。眠くなったので、またこんど。

LLTV に行ってきました

Lightweight Language Television に行ってきました。LL フィーリングカップルなるセッションで、パネリストとして出ました。このセッションが「そもそもLLではない」「女性が集まるのか？」などなど、新しい試みでした。で、私は一応 Python の人なわけですが、技術的なセッションではないので、せっかくの機会だからってことで、出ました。

各種の名言

• .py とか .rb みたいな、きもい拡張子


• 女性プログラマだったらパッチ送る


• [働きたい会社は？] 家の近く


• 女性の行動はバグに見えるかも知れないけど、それは仕様


• 女性の意思決定の状態遷移図が欲しい（これは自画自賛）

次回はLTででたいかも。あと torufurukawa でついったーしてます。

第24回 トライアスロン中島大会に行ってきました

11年ぶりに、トライアスロン中島大会に行ってきました。愛媛県松山市の瀬戸内海に浮かぶ、中島（なかじま）という島で開催される、51.5km のトライアスロンです。学生のころは、ちょうどインカレの予選と本戦の間に開催されるってことで、参加していました。で、母と妹もいつの間にやら常連になっていて、このたび、3人で参加。父は前夜祭と応援に参加。

先月のアクアスロンでは、スイム棄権というどうしようもない結果でしたが、今回は無事完走しました。ちょうど3時間くらい。コースは違いますが、東野幸治よりも明らかに遅いのですが、しょうがないです。

東野りの影響かどうか分かりませんが、今回は400人ちょいの定員に申し込みが殺到したらしく、100人以上に参加許可が出なかったらしいです。らっきー。この中島大会 TJ 読者が選んだ、2007年出場して良かった大会第10位です。個人的にも、この大会が大好きなので、勝手に宣伝。アド街みたい。

この距離で JTU が絡まないのに、運営がしっかりしています。24回開催はダテではありません。コースもトランジットもシンプルですが、あやうげな箇所については、プログラムに細かい資料が載っています。昨年からは RF タグを使った計測もしているそうで。要所要所にスタッフがいるので困る事もありません。

スイムはビーチと平行に、2往復。瀬戸内海なので波も高くなくて泳ぎやすいコースです。沖縄とかのレースに比べると、水はきれいではないかも知れません。今年はクラゲもいませんでした。クラゲが出る年もあります。

バイクは、海岸沿いを走ります。片道10kmを2往復。ほとんどフラットです。折り返し付近にちょっとした坂が1つ、短いけどきつめの坂が1つ。ですがほとんどフラットと言ってよいかと。折り返し付近は、道も狭いので、追い越し禁止＋徐行です。ゆるいカーブはありますが「コーナー」は1カ所くらい。

ランは 5km を1往復。スタートとゴールは同じ場所です。スタート直後に軽い上り坂、折り返し付近にもちょっとした坂があります。ほとんどフラット。

ランのエイドステーションが 2.5kmごとにあります。道の片側にしかないので、反対車線に行って水をもらいます。ほとんどが中学生のボランティアですが、ちゃんとマニュアルがあるのか、スムーズです。水、スポーツドリンク（おそらく毎年アクエリアス）、スポンジがデフォルト。エイドステーションによっては、バナナとスイカがあります。私はスイカとバナナにアレルギーがあるので、もっぱら水とアクエリアスですが、まあ、スイカアレルギーの人なんて、ほとんどいないんではないかと。

あと非公式なエイドステーションとして、沿道に住んでいる方が、水をかけてくれます。水道代払いましょうかね。大丈夫ですかね。

沿道でたくさんの人が応援してくれるんですよね。鳴りもの使っているグループとか、ゼッケン番号みて名前で応援してくれるグループとか。私は完走目的なので、応援をいただいたら、できるだけ「あざーっす！！」と言いました。だって嬉しいんだもん（こどもかよ）。

島全体のイベントなので、大会前からずーっと島全体が何か作業していると思うのですよね。当日は島の外周道路を半分くらい閉鎖するので、みかん農家の人は仕事できないわけです。別にみんながみかんを買いあさって帰るわけでもないですし。うわさによると、中学生はスタッフを「やらねばならぬ」らしいです。なので感謝、感謝なのです。何かお返しができないですかねぇ。

という気分になる大会です。特に初心者におすすめですが、2:15 くらいで走っていた学生時代も好きな大会でした。2:10 以内で走る人にとっては、どうなのかさっぱり分かりません。

一応、デメリットとなりうることも書いておきます。まず、前泊が条件です。土曜日の午後から受付開始、前夜祭に出ねばなりません（魚とうどんが、おいしいわけですが）。仕事や家庭の事情によっては、この条件はきついと思います。離島なので、前泊しないと、事実上参加できないわけですが。

離島つながりですが、400人の宿泊施設が、事実上 MAX です。住民の方の家に泊まる「ホームステイ」なる選択も公式に用意されていますが、それでも、ぎりぎりってとこではないでしょうか。希望を出せますが、基本的に大会側で宿泊施設を割り当てます。なので、まくらが違うと嫌とか、他人の家に泊まるのは嫌とか、雑魚寝は嫌とかだと、厳しいです。ちなみに私はホームステイでした。多謝。学生のころは雑魚寝もありました。私はいびきをかくことがあるので、隣の人ごめんなさいでした。

そういう大会です。久しぶりに 51.5km のトライアスロンに参加して、あーやっぱり中島大会いいなぁと思った次第です。来年も申し込みます。抽選にあたるといいなぁ。

Snow Leopard の GCD

Mac OS X の次期バージョン Snow Leopard には、Grand Central Dispatch というのがあるらしいです。これは OS なのか、フレームワークというかミドルウェアなのか微妙な感じがしないでもないですが、まあ、そこはよしとして。

概要を読んでみると、マルチコアCPU用の並列コードを書きやすく/並列化しやすくするテクノロジーっぽい。

Block というコンセプトがあって、これがひとつのコードのかたまりになる。資料をそのまま使うと、x = ^{ printf("hello world\n"); }  みたいに定義するそうで。で、後で、x( ); でBlock を実行するというか、呼び出すというか。

Block は、GCD が持っている Queue に突っ込まれて、あとは GCD がコアに振り分けて実行してくれるらしい。これで動的に並列化する部分をそれなりに並列化できる。

Block を Clump、Queue を RunQueue に置き換えると、どっかで聞いた事のある実装と似ているなぁと思った次第です。

第7回 須磨海水浴場アクアスロン

2009年7月5日、第7回須磨海水浴場アクアスロンに行ってきました。諸事情により、かなり前のめりなテンションだったので、うっかり3列目からスタート。スタートしてから気づいたのですが、学生のときでも、そんな前からスタートしたことがありません。案の定バトルに巻き込まれました。しかもウェットスーツを着ていたので、もぐってコースから外れるとかもできず。

その後パニックですよ。息ができない感じです。立ち泳ぎ平泳ぎ背泳ぎでしのいだのですが、顔を水につけるのが怖くなってリタイヤしました。大会運営の方、ご迷惑をおかけしました。申し訳ないです。ボートに引っ張ってもらったのですが、途中でひもが切れたので、自力で海岸まで泳ぎました。いやもうほんと、そのくらい自力でやりますって感じで。

で、傾向と対策をば。まず問題は大きく２つに分けて、(1)パニックになったことと、(2) パニック時の対処です。

パニックになったのは、慣れていないバトルが原因。トライアスロンを再開してからは、いつも、後ろのほうからスタートしてました。ランニングレースでも、昨年の昭和記念でも須磨でも。なのでバトル経験がありません。泳力もバトル力もないのに、そんなポジションにいたら、当然溺れるわけです。

パニック対処の問題は、技術とメンタルの2つがあると思います。

技術的には、溺れたときに場当たり的に立ち泳ぎや背泳ぎをしたこと。最大の武器であるはずの平泳ぎをほとんどしていない。まず平泳ぎ、続いて背泳ぎ、最後に立ち泳ぎって感じにすればよいかと。

深呼吸した気がしない状態が続いて焦った。昨日、プールで泳いで気づいたけれど、泳いでいる最中に、深呼吸した気なんてしない。ちょっと息切れした状態が続いている。だから「大きくはいて、大きくすう」ことができれば実は御の字なのです。それをまず認識すること。

あとは練習かなぁ。「このくらいじゃ、溺れない」っていう成功体験が必要なのかも。オープンウォータースイムに出てみようかなぁ。

ちなみに海でウェットスーツ着用だと、普通にしてたら沈むことはありません。てんぱってるからリタイヤするはめになるだけです。

仕事の合間に運動する

今週から、17時に運動して、また仕事に戻る、というのをやっています。なんかうまくいきそう。

いくつかメリットがあります。まず、夜更かしした翌日に寝坊しても大丈夫、ということ。朝練の最大の敵は睡魔なのですが、その影響を受けません。

夕方になると集中力が切れるのですが、一旦、職場を離れてから戻ってくると、頭がすっきりしているので、再び集中できます。あと、夜に帰宅すると、もう外出したくなくなるのですが、そういう心配もありません。

仕事の後でのみに行っても大丈夫です。

ひとつ工夫をしています。ジョギングをするときは、一旦帰宅するのですが、このとき携帯電話も他の荷物も、すべて職場に置いてきます。そうすると、職場に戻るインセンティブが働くからです。

pyclbr

PyMOTW で pyclbr モジュールが紹介されていました。クラスブラウザを実装するのに便利なモジュールです。

たとえばこんなコードがあったとしましょう。

# foo.py
class Foo:
    def hello(self):
        print("hello")
    def bye(self, person):
        print("Bye,", person)
class Bar(Foo):
    def hello(self):
        pass
    def go(self):
        print()

で、pyclbr はこんな風に使います。

# browse.py
import pyclbr
for name, classinfo in pyclbr.readmodule("foo").items():
    print(name)
    for method in classinfo.methods.items():
        print(method)
    print()

実行結果はこんな感じ。

Foo
('bye', 4)
('hello', 2)

Bar
('go', 9)
('hello', 7)

Bar.bye() は表示されません。スーパークラスのメソッドは、明示的に取らないといけないようです。

テストシーケンス管理ツール TestStand 4.2 から Python に対応しています。実行時に関数やメソッドを指定して呼び出せるはずです。おそらく、このモジュールを使っているんだろうなあと思います。未確認ですが。

wxPython の Event.Skip()

wxPython のことなど。別に中学生と張り合っているわけではありません。張り合ってませんったら。

Ctrl+X とかの、キー押下イベントをキャッチしたいのです。でも TextCtrl を使っているので、特定のキーコンビネーション以外は通常通り処理したいわけです。まさか全てのパターンでの処理は書きたくない。

ウィジェットのほうを探しても見つからないなぁと思ったら、Event オブジェクトに Skip() メソッドというのがありました。

This method can be used inside an event handler to control whether further event handlers bound to this event will be called after the current one returns.

このメソッドをイベントハンドラ内で使用すると、そのイベントハンドラ終了後、既にバインドされている他のイベントハンドラでも処理するかどうかを制御できる。

ウィジェットではなくて、Event オブジェクトのメソッドなのですね。なるほどなぁ。

import wx

class App(wx.App):
    def OnInit(self):
        frame = Frame()
        frame.Show()
        return True

class Frame(wx.Frame):
    def __init__(self):
        wx.Frame.__init__(self, None, title="my frame")
        self._text = wx.TextCtrl(self, style=wx.TE_MULTILINE)
        self._text.Bind(wx.EVT_KEY_DOWN, self._handlekey)
        wx.BoxSizer(wx.VERTICAL).Add(self._text, flag=wx.EXPAND)

    def _handlekey(self, event):
        if (event.GetModifiers()&wx.MOD_CONTROL and 
            event.GetKeyCode()==ord("X")):
            print "^X pressed"
        else:
            event.Skip() # <= ここ

if __name__ == "__main__":
    app = App(redirect=False)
    app.MainLoop()

中学生ハカー

Python Code Reading 10 に行ったら、若いハカーがいました。中学生で、Java やってて、Python に興味を持ち始めて、ゆくゆくは OS を作りたいらしく、カーネルの勉強会にも顔を出しているとか。ブログを覗いてみると、Java のマルチスレッドプログラミングに言及していたりするわけです。うひゃあ。おっちゃんは、中学生のとき並列処理とか知らなかったよ。

プログラミングだけではなくて、テニスなんかも嗜むという男前な少年です。応援したくなります。困ったことがあったら、おっちゃんに言うてみ、と。自分が成しえない夢を託してしまいそうです。

で、森博嗣の「有限と微少のパン」を思い出しました。

子供に夢を託した方が、自分が夢を実現するよりも楽だからだ。(p.200)

確かに。OS を作るという一点にしても、彼のほうが遙かに実現確率が高いです。まあ私は彼の父親ではないし、OS開発どころか、父親や夫というポジションを得ることさえ成しえなさそうですが。

パトロンっていうのも似たような立場なんでしょうけれど、自分が何をしているか分かっている点で、健全なのかも知れません。私は、お金も知識も与えられないので、応援だけしています。ってゆーか、中間試験と高校受験はやっとけ、少年。

と、油断させておいて、彼が試験に忙殺されている隙に、こっそり thireading と multiprocessing モジュールのコードを読んでみます。

Deskography

Deskography という、デスクの写真を公開するシンプルなサービがあります。いやもうそれだけ。それ Flickr (r

ミニマリズムに憧れるので、



とかが好きです。なかなか、ここまでそぎ落とせませんが、そぎ落としたいと思っています。そのうち、私のデスクもアップロードするかも。

Presentation Zen: The Video

Presentation Zen のビデオが出ました。ブログや本に書かれている内容とかなり重複しているので、特に新しい知見があるわけではないです。

YouTube: Presentation Zen: The Video

ですが、このプレゼンがうまいです。いやまあ、こんなかっこいい状態でプレゼンする機会なんて、私にはないのですが、それにしてもうまいです。あと、トピックが後ろにぽわーんと出てきて、ぽわーんと消えていくエフェクトもかっこいいです。

夏頃にちょっと気合いの入ったプレゼンをする機会がありそうなので、参考にしてみます。

シュレッダーはさみ

ネットで買えるものは、基本的にネットで買うという生活をしています。特に、書籍と雑誌。領収書だとか、送り状みたいなものをずーっと保存していてもしょうがないので、捨てるわけですが、今までそのまま捨てていました。誰も私の個人情報なんぞほしがらないだろうし、本気でほしければすぐに調べられると思うからです。

ですが、別に「私の」情報が欲しい人はいなくても、「誰かの」情報が分かればいいという人はいるでしょうし、そういうときにゴミってなぁ、と思いはじめました。というわけで、シュレッダーはさみを購入。

紙がつまりやすいですが、必要にして十分です。

切り刻んだ紙をスキャンして合成すれば、簡単に復元できることは知っています。切り刻んでいない紙と差があればよいのです。ジャングルで虎に遭遇したとき、虎よりも速く走る必要はなくて、一緒に居合わせた人よりも速く走れればよい、という考え方です。我ながらゆがんでいます。

Things のタグづけが発散してきた

GTD 実践ツールとして Things を使っているわけですが、以前に採用した方法が発散してきました。

重要なプロジェクトには★、急ぎのプロジェクトには☆、とタグ付けをしていましたが、これがいまいちです。★と☆が MECE になっていません。これが混乱の元凶でした。

というわけで、☆を廃止。今週するプロジェクトには★をつけます。で、★のついているプロジェクトの中から、最大でも３つくらいまで Today （これも Things 上では黄色い★マークがつく）をつけておきます。

こうしておいて、まず Today のタスクに集中します。で、Today が全部なくなったら、次の３つを選ぶ。と。さて、どうなることやら。

俺の話を聞け - プレゼンを聞いてもらうには

Python Code Reading も 10 回目があるようで、わくわくです。前回の 08 で、私にとって最大の難関は、勉強会とは言えども、非職業プログラマがプログラマ相手にプログラミング言語の話をする、という状況をどう克服するか、でした。実績が明確な人や有名な人であれば、こんなこと気にしなくてよいです。プログラマではなくても Tim O'Reilly だったりね。

そんなわけで、自己紹介の段階でなんとしてでも、話くらいは聞いてやってもいいか、という内容を入れておかねばと思ったわけです。内容に異論や批判はあってもよいのです。めげますけど。けど聞いてもらえないと議論のテーブルにもあげてもらえません。わざわざ平日の夜に集まってもらったのに、ぼーっとしてただけ、というのは申し訳なさすぎます。せめて「聞いてたけど、それは違うんじゃあ」と思ってもらいたい。というわけで、２つの内容を自己紹介に入れておきました。

ひとつめは Python 1.x → 2.x への移行らしきものを見たことがある、ということです。オライリーの Python 本を読んだとき、1.x と 2.x の違いについても触れられていましたし、大学のサーバにも 1.6 と 2.1 の両方が入っていましたし、Python 2.x 非対応のライブラリなんかに遭遇してソースをいじったこともあります。日本で Python が流行りだしたのはもっと後の時期だったので、時期（時間ではない）という点だけを見ると、ちと話を聞いてもらえそうな気がしました。実際、1.x から 2.x への移行は初心者の私にも大した問題ではなかったです。

もうひとつは「ソフトウェアの機能ではなく、ユーザのベネフィットを伝える」という仕事をしている（ことがある）、ということです。Python 3.0 の新機能リストや変更点は python.org あたりにいけばすぐに分かりますし、個々の新機能の使いどころは PEP や雑誌にも載っていました。で、じゃあ、ユーザにとって総合的に何が嬉しいのか？というは意外となかったりするわけです。一方、仕事ではそれを伝えることを求められるのですね。伝えられているかは別にして。で、それを Python でやってみました、という話です。

という前振りのあとで、「Python 3.0 のベネフィットは読みやすさと書きやすさ」である、という乱暴なテーマで話したわけでした。ちゃんちゃん。

openFrameworks

Marco Tempest が使っていたライブラリは openFrameworks なるものらしい。オープンフレームワーク、と聞き取ったので、一般名詞だと思い込んでいました。

The library is designed to work as a general purpose glue, and wraps together several commonly used libraries under a tidy interface: openGL for graphics, rtAudio for audio input and output, freeType for fonts, freeImage for image input and output, quicktime for video playing and sequence grabbing.

openGL によるグラフィックス、rtAudio による音声入出力、freeType によるフォント、freeImage による画像入出力、quicktime による映像入出力をまとめたラッパということでしょうか。ふむふむ。C++ なのですね。

これでデジタルアートっぽいものを作るのだそうで。いつかやる（≒ずっとやらない）。

BP Study #21 に行ってきた

BP Study #21 に行ってきました。初めての参加です。

個人的にツボだったのは、AMQP でした。ネットワーク上でキュー実装するサーバとの通信プロトコルらしい。非同期に enqueue するので、アプリケーションはにデータを渡したら、あとは知らんぷりしてていいらしい。単位時間あたりのメッセージの個数が大量にある場合には、同期してたら大変ですから。キューは、TCP でちゃんとセッションを張っているから、基本的にメッセージを落とさない。だそうです。

キューだけを実装するインフラがあるということに、衝撃を覚えつつ、まあそういわれてみればそうか、と。小さなアプリケーションどうしでは、アプリ側で通信を実装するんでしょうけど。

ところで次回の Python Code Reading 10 は日程的に、ちときついかも。うーむ。

本は電子化されて欲しい

ほとんど炎上レベルな「紙の本が100%亡くなると断言できる、たった一つの理由 」ですが、ちょっと釣られてみる(ウラタロス)。

予測はできないけど、希望があります。私が生きている間に、できるだけ早く、本は電子化されて欲しい。読まなくてもいいような情報伝達手段があれば、もっといいけど、それはさておく。ともかく、紙媒体は電子媒体に取って代わられて欲しい。以下は「私の」wish list です。

紙に対する不満
最初に紙媒体に対する不満を。
検索できない: もうね、検索させろと。なんなら migemo で検索させろと。あやういキーワードだったら「もしかして○○？」とか聞いてくれ。くらいの勢いで検索したいです。
体積と質量が大きすぎる: 欲しいのはコンテンツで、コンテンツはデータなのに、どんだけ体積と質量がでかいのか、と。3週間に2, 3冊程度しか買いませんが、それでも年に1回は BOOKOFF にまとめて売り飛ばします。それとは別に捨てたり、職場の蔵書にしたり。
UNDO を含む編集が困難: いきなり本ではなくて、紙媒体全体の話になりますが、編集しにくすぎ。いつもメモ帳や、裏紙を持っていて、いつでも書ける/描けるようにしています。他に代替手段がないから。でも、編集のしにくさという点で、紙はもう限界ではないでしょうか。

紙に求めていないこと
ページめくりなんて要らないし、紙の味わいも要らない。目が見えるからこんなこと言ってられるのかも知れませんが。ページなるコンセプトは紙の物理的制限から発生しているだけです。スクロール、ブックマーク、検索くらいがあればページなんていらない。

紙じゃなくて電子メディアでもできること
一覧性: ぱっと全体を把握できるというのは、原理的に電子メディアでも可能です。iPhone の Safari みたいにズームすればいい。あるいはコンテンツを魚眼表示でもいいかも。ズーミングインタフェースがあれば、一覧と詳細の閲覧は両立できると思います。
書込、付箋: その機能を実装すればいいだけ。Adobe Acrobat でできることは、できるっしょ。
携帯性: 電源を気にしている人が多いようです。実際、重要だと思います。携帯電話を見ていると、そのうち解決される気がします。

確か、増井俊之さんがどっかで言ってたような気がしますが、昔ホームモータなるコンセプトがあったそうです。一家に一台モータがあれば、みたいな話ですが、そんなのは流行らなかった。でも、あらゆるところにモータの類があります。アナログの腕時計、PCなどのファン、携帯電話のバイブレーション、電子レンジ、洗濯機、ハードディスクドライブ、電気カミソリ。私は持っていませんが、ヘアードライヤ、DVD レコーダとか。

期待していること

小型化: 小さいこと、薄いことはよいことなのでね。
ユビキタス + クラウド: もうね、コンテンツ本体ではなくて、アクセス権を売ってください。あるいはコピーをどこかに置いておかせてください。そのかわり色んなデバイスからアクセスさせてください。PC でも、電子ペーパーでも、携帯電話でも。自分のグローバルストレージに、書込、しおり、タグづけとか保存しておくから、ときどき同期してくれればよいです。
書くほうも電子化: 紙とペンから早く卒業したい。電子かできれば、いろいろ再利用できるし検索もできます。編集もできます。バックアップをとってバージョン管理もできます。
解像度: 解像度はそれなりに向上してほしいです。でも、いまどきの携帯電話くらいでいいかなぁ。
でいい。UNDO もできるし、隠すこともできる。

アラン・デービスの「ソフトウェア開発 201 の鉄則」のなかで、

ハードウェアの進化には楽観的であれ (p.182)
ソフトウェアの進化には悲観的であれ (p.183)

と書かれています。この本は 1996 年に初刷が出ていますが、今でもそれなりに当てはまっている気がします。紙媒体の電子化も、同じようなことになりそうです。

銀のさらのCMが、印象に残るわけ

方々で言及されている宅配寿司「銀のさら」のCMが大人気の模様です。ひどすぎます。ここでいう「ひどい」は「意表をつく内容が素晴らしい」とほぼ同義です。おそるべし比較広告。

どうもニコニコ動画や YouTube から消えていってるので、すぐに見られなくなりそうです。

YouTube: 銀のさら

YouTube: 銀のさら CM

それにしても記憶に残るCMです。これは sticky なメッセージではないかと考え、ちと検証してみましょう。

Chip Heath と Dan Heath による「Made to Stick」という本で、メッセージを記憶に残すために必要な6つの要素を上げています。記憶に残る都市伝説や、マーケティングメッセージ、あるいはプロパガンダなんかも、この6つ要素があるのだ、と。曰く「Simple」「Unexpected」「Concrete」「Credible」「Emotional」「Stories」。これらが銀のさらのCMで、どのように活用されているか見ていきます。

Simple: このCMは非常にシンプルです。宅配寿司が、なんとなれば銀のさらの寿司が、他の外食/中食オプションよりも良いのだ、ということです。一貫して競合と比較しています。

Unexpected: このCMの基本的なキモはここにあるかと。「宅配ピザはセカンドベースと間違われるかも知れない」とか。しかも、唐突に草野球の走者がスラインディングしてきます。ちょw ねーよwww。あまりに意外なので印象に残るわけです。しかも各比較対象にたいして数秒しか時間を使わずに、ぽんぽんとつぎのネタを繰り出します。必然的にシンプルな話になるわけです。

Concrete: 非常に具体的です。「こちらのほうが信頼性が高い」みたいな話ではなく、寿司屋の配達の人と、レストランの店長ロボットがルームランナーで走っていて、ロボットがこける。で、安全だ、と。セカンドベースにしてもそうです。

Credible: 信憑性。このCMの内容にはまったく信憑性がありません。もうそれは、おそろしいまでにない。中華料理で食べたカニの仲間が来るわけがない。このCMでは、信憑性を完全に逆手に取っています。明かな嘘によって記憶に残しています。さらに、信憑性を完全に放棄するというのは、メタな意外性を創出することになっています。

Emotional: Heath の本では、恐れなどの感情を喚起させることで、記憶に残させる、という話です。このCMの場合は、笑い、です。職場で両サイドの席の同僚に、勤務時間中、この CM を見せたら「ぶほっ」みたいな感じになっていました。この強烈な感情の喚起が、記憶に粘りついています。

Stories: 物語性もあります。いろんな逸話を紹介していますが、いずれも一貫して「宅配寿司がよい」と比較しつづけます。そして最後に、宅配寿司は銀のさら、とか言うわけです。あるいは銀座の寿司屋と、銀のさらのどちらを選ぶか、というCMでは、人々がどんどん銀のさらを選んでいく(あるいは妨害されていく)様が描かれます。風雲たけし城みたい。これもストーリーが明確です。

とまあ、えらそーに色々かきましたが、こういうCMが見られるのなら、テレビ買おうっかなぁと思った次第です。

道尾秀介 / 向日葵の咲かない夏

ミステリィとオカルトが混じった小説です。以下、ネタバレあり。

オカルト的な世界が、この小説の下位レイヤーを構成しています。カバーにも

S君は首を吊って死んでいた。[...] S君はあるものに姿を変えて現れた。

とありますので、こういうのがアウトな人は、アウトだと思います。私もこういうの苦手なのですが、ちょうど村上春樹の「国境の南〜」を読んだ直後だったので、すんなり受け入れて読みました。

このオカルト・レイヤーの上に、ミステリィが乗っかります。下位レイヤーに対してはきちんと整合性のある話になっています。この構成に気付かせないように、叙述トリックの布石があり、終盤で回収されていきます。とても面白かったです。

教育目的のプレゼンテーション

相手に何かしてもらうことを目的にしたプレゼンテーションの解説というのはたくさんあります。実際、そういう場合にこそ、プレゼンテーションが必要になることが多いわけですし。ですので、あなたがプレゼンテーションなのだ、とか、心に響かせないと、みたいな話になります。

それとは別に、教育目的のプレゼンテーションがあります。知ってもらうこと自体が重要な場合です。実際、そういう状況においてプレゼンテーションという形式がよいのか分かりませんが、まあ、そういう機会があります。Python Code Reading なんか、そういう例です。別に、私は Python 2.x から 3.0 に乗り換えて欲しいと思っているわけではないのです。

で、そういうときって、話が細かくなりがちで、かつ、細かい話が本質的に重要だったりします。なので、スライドの作り方や、話し方や、スタイルなんかも、一般的なプレゼンテーションとは異なるアプローチが必要なんではないかと、最近思い始めています。

とは言え、プレゼンテーションが始まった段階では「オレの話を聞け」という目的があるので、最初の方は一般的なプレゼンテーションのノウハウが適用できると考えています。

ランニング タイムトライアル 1.5km 6分56秒

ジョギングを再開して1週間になりますが、すでにマンネリ化しつつあります。そこで、週末に予定していた 1.5 km のタイムトライアルを思いつきで決行。

6分56秒。9分くらいかかると思っていたので、上出来です。若かりし頃は、こんなペースで 10 km とか走っていたと思うとぞっとします。

ところで無理しすぎたので、頭がぼーっとして、少し痛いです。酸欠か?

Time Machine を設定してみた

自宅のネットワークストレージとして、バッファローの LS-WHGL/R1 を持っています。バックアップとか、普段使わないファイルを保存するのに使うことを目論んでいました。ところが、Mac OS X の Time Machine って無線 LAN で、このストレージをバックアップ用にしてくれませんでした。で、放置すること数ヵ月。

検索してみたら、いろいろチャレンジしているページがありました。今回は LS-WHGL/R1シリーズでTimeMachineを使う を参考に設定。途中、どこかの手順でしくじったらしく、ディスクユーティリティでドライブが出てこないという自体に陥りましたが、TimeCapsuleじゃないNASを使って、TimeMachineを使ってみるを読みながら、再チャレンジしたら、見事設定完了。おおお。

さっそくバックアップを始めたら、これがまた時間がかかります。まあ、無線 LAN でディスクまるごとバックアップしようとしたら時間がかかりますわな。

あとバックアップ中、というかネットワークでがしがし転送しているときには、Bluetooth のマウスやキーボードの反応がおそろしく悪くなります。なので、作業中はついつい「バックアップを中止」してしまって、なかなかバックアップが終わりません。ないよりマシってことで。

10年ほど前は、バックアップをするために、pdumpfs を NTFS 用に Python で実装して使っていたものです。Time Machine すばらしすぎ。

Glims - Safari の検索用プラグインをインストールした

Mac では Firefox をデフォルトブラウザにしています。理由は (1) プロファイルを分けておける、(2) migemo がある、(3) 検索フィールドから Amazon の検索ができる、の3つです。

ただ Safari のタブをドラッグして、別ウィンドウで開く、というのもなかなかに便利です。調べ物をするときなんか、特に。

で、探してみるとやっぱりあるもんですね。Glims という Safari プラグイン。Firefox の検索フィールドと同じように、検索サイトを指定できます。検索サイトの登録も簡単です。他にも、Google 検索結果でサムネイル表示、cmd-z で閉じたタブを undo なんかもできます。すばらしい。

ジョギングの SNS 「ジョグノート」がすごそう

「ジョギングするぞ!」と、年に12回くらい決意するのですが、続きません。意志の力の弱さには自信があるので、誉められドリブンあるいはジマンパワーを活用して、ジョギングしたいと思います。

というわけで見つけたのが、ジョグノートという SNS。いろいろ機能はありますが、気になる機能は以下の3つです。

練習記録
練習した内容を記録できます。距離と時間を記録できるあたりが、ジョグノートです。あと、ジョギング、ウォーキング、自転車、水泳から種目を選べます。このトライアスロン向きな感じ。それから、距離と時間から、ペースも自動計算してくれます。もちろんグラフ表示。

コースマップ
技術的にはこれがすごそうです。地名や住所から地図検索し、クリックしながらコースを設定できます。設定したコースは公開/共有されます。で、このコースの距離、高低差、カロリーが自動計算され、表示されます。カロリーは体重と距離から概算ですが、有効数字が1桁もあればよいので問題ありません。

ブログパーツ
最近の練習記録をグラフ表示するブログパーツがあります。はてなグラフみたいな感じです。これがあればジマンパワーも炸裂です。

気付いたのですが、今使っているブログサービスでは任意のコンテンツを表示できないのですねぇ。そのために、値段が3倍のサービスにアップグレードするのは、さすがに本末転倒な気がします。 （追記: できました）

仕事が遅い私の Things 活用案

GTD 実践ツールとして Things というアプリケーションを使っています。Mac OS X 用のタスク管理ツールです。50ドルくらいです。β版から使っていたので、10ドルほど安く購入しました。シンプルなアプリケーションなので、色んな使い方ができます。ここでは、私の使い方を記録しておきます。

使用方法の前提

• 公私混同



• 大小さまざまな（GTDではなく一般的な意味での）プロジェクトが同時に走る



• プロジェクトの重要度や期限の厳しさが異なる



• 個々のプロジェクトはボトムアップで発生することがあるが、上位の戦略に結びつけるのは自分の仕事



• 報告ドリブンにしたい

上のような特性から「どのプロジェクトが、いつ終わるのかほとんど見当がつかない」ことが課題です。もうね、何年社会人やってるんだと。ちゃんとプロジェクト管理すると準備におそろしく時間がかかりそうなので、Things を使い続けて、ある程度の解決をしてみようと考えています。

「ical」タグ
Things には作業時間を計算する機能がないので、工数見積は別のツールで行う必要があります。そこで iCal に TODO というカレンダーを作っておいて、プロジェクトAに1時間かかる、みたいな情報をカレンダーに入れておきます。この作業をし終わったプロジェクトに ical というタグをつけます。TODO カレンダーは工数見積のためだけに使うのでアラームなんかは鳴らしませんし、状況によって自由に時間を変更させます。欠点は面倒だということと、毎日のように更新しないといけないことです。

「★」「☆」タグ
ical タグが破綻しそうなので、新しいのを使いはじめました。重要で急ぐ作業には「★」、重要ではないけど急ぐ作業には「☆」をつけます。これは週次レビューで更新されるはずです。もしかしたら、重要軸と緊急軸で分けられた4象限にするべきなのかも知れません。

「template」タグ
定型のプロジェクトはテンプレート化しておきたいものですが、Things にはテンプレート機能がありません。そこで someday の中にテンプレートとなるプロジェクトを作っておいて「template」とタグ名をつけておく方法が、サポートページで紹介されていました。必要になったら、このプロジェクトをコピーして、使います。

AREAS
GTD の責任や役割と呼ばれるものを、このエリアに割り当てます。仕事の場合には、担当している製品やセグメントを使います。プライベートの場合には「Finance」「Health」などをエリアにします。できるだけ MECE になるように。エリア機能を使うのはこれが初めてなので、様子を見て、変更することになると思います。

そんなわけで、Things で人生を立てなおすことを狙っております。

誉められドリブンな人生

今年に入ってから、仕事をコントロールできている感がありません。仕事はたまっていますし、休暇中にも仕事の問い合わせや指示が届きます。ついに GTD が破綻したのではないかと焦ってしまいました。

「タスク管理ツールに最適解はあるか」のように

会社はそれとは逆で、
・作業期限がある。
・報告義務がある。
・日にち、時間という枠でシビアに管理する必要がある。
・かかった作業時間を計測しておくほうが何かと都合がいい。

という意見もあります。一方で、GTD は比較的抽象度の高い方法論なので、状況に応じて柔軟に対応できるはずだという望みも捨て切れません。

「破綻」に、GTD 破綻の分析として

基本的に自分は義務感を行動原理としているということ。

ということが書かれていました。自分の場合はどうかと考えてみると「すごいと思っている人に誉められる」のようです。生々しいのでこの結論に至った仮定は省略です。

そこで思いついたのたが「Report-Driven Work」と「Blog-Driven Life」です。仕事を、報告書を出す、と定義し直します。で、まともな報告書を出すために、まともな行動をする、と。プライベートのほうはブログで。さて、いつまで続くことやら。

村上龍、村上春樹、森博嗣、小林靖子

フィクションを読むようになったのは、ここ5年のことです。村上龍の「5分後の世界」をたまたま譲り受け、うほっこれはいい話、と思ってから村上龍を読むようになりました。「限りなく透明に近いブルー」から「半島を出よ」まで、とりあえず目に付いたものを読みました。数年前に村上春樹を勧められました。「ノルウェイの森」は最後にしようと決めて、こちらもとりあえず、だらだら読む。昨年の夏に映画の「スカイクロラ」を見て以来は、森博嗣です。

いろんな作家のを読むというよりは、ひとりの作家のを続けて読みます。保守的だからですかね。美容院もいつも同じところ、お酒を飲むのも同じ店、朝食もファミマのハムカツサンドです。

仮面ライダー電王の曲をピアノ演奏するというのを、ニコニコ動画で見つけてから、ふと思って電王全部を DVD で見ました。おもしろいと思って、キバやディケイドも見てみたのですが、いまいち。ですがなんとなく龍騎は面白くて、これも週末で全部みました。面白い。

後で分かったのですが、電王と龍騎の共通点は「メインライターが小林靖子」だということです。ははぁなるほど。こんなところにも保守性が出ています。

森博嗣 V シリーズ読了 1回目

金曜の夜は、森博嗣の文庫本を1冊買って、それを読みながら土曜の午前を迎える、という生活が続いています。この週末は「朽ちる散る落ちる」を読了後、ああ読みたいと思い「赤緑黒白」の2冊を買い、おそろしく夜更しして読み(昼に寝るから)、あげくの果てに日曜日の10kmランニングレースを寝飛ばしました。

森博嗣 V シリーズの感想をば。以下、物語の核心に触れた記述があります。

熱を上げて、一生懸命に没頭していられるのは、本当に三日くらい。その三日のうちに行動を起こさないことは不可能だった。とにかく、いても立ってもいられなくなる。(赤緑黒白 p.11)

嗚呼、気持ち分かりますよ、保呂草さん。瞬間的にしか没頭できないのは、私の数ある欠点のひとつだと思います。この性向の悪いところは、長期的な学習や訓練を必要とする技能を獲得できないことです。

Vシリーズでは、ある話が別の話の伏線になっていたり、シリーズ全体を俯瞰したときに何かが分かったりします。飽き性な私は、無頓着に読んでいたのですが、やっぱり気になることや解せないことが出てきました。たとえば「六人の超音波科学者」で超音波を非破壊検査に使えそうだとか、数値計算の誤差に懐疑的な実験屋がいたりとかで、えーそんなもん今さら、と思うわけです。「朽ちる散る落ちる」の有人人工衛星の着陸がやたらとしょぼかったり。あるいは「赤緑黒白」で最後にちょろっと出てくる人物の年齢がおかしくないか、そのトリックはインターネットでいいじゃんとか。

そこでインターネットですよ。「フジモリの脳内ラビリンス」というサイトの、書評のページに各作品とシリーズの解説があって、これを読むと、シリーズを通した謎が解けたり、新たな伏線が出てきたりします。一番衝撃だったのが、Vシリーズは S&M シリーズの 20-30年前の世界だということ。各種技術が実用化されていないことが解せます。

ちょっと注意すれば分かるのです。たとえば誰も携帯電話を使わない。「電話してきます」「家にいなかったから電話に出られなかった」みたいなシーンがある。さらに「捩れ屋敷の利鈍」では携帯電話が出てくる。時間軸というか時刻がシーケンシャルではないはずです。

Gシリーズをちょっと読みはじめていたのですが、ちょっと中止。V シリーズを再読してみようと思います。S&M シリーズは人に貸しているので、後まわし。「四季」シリーズを読むとさらに継りそうな気がします。飽き性な私が、ちゃんと再読できるのやら。

Code Reading スライド作り 10 のポイント

Python Code Reading 08 で講師というか、しゃべりをしてきたわけですが、資料をどうやって作ったのかと何人かに聞かれました。ので、書いておきます。

基本的に、そこらへんのプレゼン本、文書指南書、レポート書き方ハウツー本のとおりにやっているだけです。卑屈に聞こえるかも知れませんが、私ができることは、学校で習ったことと、本に書いてあることのサブセットです。

0. とりあえずダウンロードしてインストール
python.org から 3.0 と 2.5 の tar 玉をダウンロードして make する。時間がかかるので、その間に...

1. さらっと調べる
Google で「python-3.0」を検索して、さらっと読む。で、かたっぱしから、はてなブックマークや Evernote にメモメモ。検索結果のトップ10くらいを読めば、私が話した内容以上の情報が得られます。

2. コードをメモする:
What's New in Python 3.0 に書かれている新機能を、2.5 と 3.0 で比較しながらメモします。たとえば、最初は print 文から print() 関数への変更です。2.5 フォルダで grep -n "print " *.py | less したり、3.0 フォルダで grep -n "print(" *.py | less してコードを眺めます。

なんとなく面白そうだなと思ったファイルを、テキストエディタで開いて、2.5 と 3.0 の違いを見付けて、memo.txt とかにひたすらコピペ。気付いたことがあったらメモしておきます。len(a) == a.__len__() とか。

ひととおり終わると、ここは集中して話したいなぁとか、ちょwイミフww みたいな箇所が、なんとなく絞られています。

3. ポジショニング
「2.5 よりも 3.0 が優位になる条件は何だろう」と考えて、3.0 を 2.x と差別化します。__cmp__() 廃止は可読性や一貫性に大きな影響が出て、StringIO のモジュール階層の変更や oct() や hex() の導入などは瑣末な変更であることが見えてきます。「Python 3.0 のベネフィットが読みやすさと書きやすさ」というのは、この時点でだいたい出てきました。ベネフィットに直接関係なしないコードは思い切ってカット。

4. コードのスライド作り
上のポジショニングに影響する機能とコードを、スライドにコピペです。PowerPoint 使っています。重要でない行や変数は「...」で済ませます。実は最初、この種のスライドは、2.5 と 3.0 を、左右に並列させていました。

5. 導入とまとめスライドを作る
導入として、状況の説明、当事者意識を持たせる、当事者の期待、課題提示、解決策を提示するスライドを作ります。今回は3枚くらいでしたっけ。もくじは「その後」です。この方法は Cliff Atkinson の「Beyond Bullet Points」という本で提案されている方法です。この時点ではタイトルだけ書いておきます。

まとめスライドは、話した内容を箇条書きにしておきます。ついでに、3.0 に以降するべきときと、するべきでないときのスライドも追加。勉強会なので、簡単に済ませました。

6. コードスライドにコメントをつける
コードの重要なところを囲ったり、吹き出しをつけます。話す順番に出現するようにします。コード読みなので「この変数がー、こっちの関数にわたってー」みたいな展開になります。スクリーンの前に立って、指で指し示しすのが嫌だったので、ぜんぶスライドの吹き出しにしました。

指や指示棒を使いたくない理由は、物理的な制約です。背が低いのでスライドの1行目を指させないときが、よくあるのです。それに最近のプロジェクタは明るいので、指や指示棒が見えないことも多々あります。レーザポインタは見にくいので論外。

7. コードスライドのフォント変更
ustream で配信することになったので、慌ててフォントを大きくしました。きっと見えないだろう、と。どうしても1枚に、2.5 と 3.0 を並べられないことに気付いたので、スライドを分割しました。それから編集中のスライド表示の大きさを、ustream の映像サイズと同じにして作業しました。

8. 写真をつける
Presentation Zen のブログや本で、言及されているように、背景にうすーく絵や写真をつけます。特に、コードではなくて、しゃべりでひっぱる導入やまとめスライドに写真をつけます。iStockPhoto から。

9. 練習
声にだして、立ってしゃべる練習をしました。

Python Code Reading 08 で話します

今週の水曜日、Python Code Reading 08 で話します。会場はすでに満席なのですが、ustream.tv でストリーム配信される予定です。

テーマは Python 3.0 移行のポイントで、文字列まわりと例外まわりを丁寧めに、他はさらっと流す内容にするつもりです。個別の変更を code reading の集まりでやってもしょうがないので。あと 2to3 というソースコード変換ツールの紹介もさらっとやります。使ってみた感じでは、このツールはなかなかに使えそうな予感です。

ストリーム配信で見る人のことを考えると、スライドの字をかなり大きくしないと、見えないんですよねぇ。会場の広さを考えて、ちょっと小さめの字で乗り切ろうと思っていたのですが、そうもいかないかも知れません。今から、どのくらい変更できるか怪しいですが、善処したいと思います。

神奈川マラソン

神奈川マラソンの 10km の部に参加してきました。ほとんど練習していなかったので、朝まで辞めようかなぁと思っていました。ですが、じゃあいつになったら練習するんだよ、とセルフつっこみして出発。埋め立て地の海沿いを、変則１往復するフラットなコースです。風は強かったのですが、暖かくて走りやすい。

スタートは首都高の磯子あたりで、そのまま首都高の下を南下。IHI の敷地内に入ってから折り返し。ここでだいたい 2km くらい。トイレに行きたくなり、IHI のトイレを借りる（使ってよいトイレ）。ここで振り返ると後ろから自転車が来ます。なんだろうと思ってみて見ると「最終走者」と。えー！ コースは来た道をもどり再び磯子料金所あたりへ。

ゴール地点を横目に（ここでだいたい 4km）、そのまま北上。1.5km ほど高速道路の下を走り続けます。新磯子の交差点を右折 - 地図上では南東へ - して、ヨットハーバーを横目にずーっと海沿いを道なりに走る。直角コーナーが3箇所あって、その先の火力発電所の手前で折り返し。ここで、だいたい 7km。

制限時間の 70分でゴールするつもりだったので、ここまではひたすら、自重してました。7分/km くらいのペースより速くならないように、とペース落としてました。で、気づいたのですが、人数が多いレースなので、レースが始まってからスタートラインを超えるまでに、３分くらいあったのです。ネットタイムで 70 分でも、トータルタイムだと 73分かかってしまって、強制棄権では？と思い始めたわけです。

やべぇ。というわけで、少しペースを上げました。6分/kmくらい。これでぎりぎり遅れを相殺できるはず。何やら膝が痛くなってきましたが。普段、自動車が走っている道路が閉鎖されていて、フラットで、ちくしょう自動車はいつも、こんなに走りやすい道を走っているのか、という気分です。そんなこんなで、69分でゴール。あー膝が痛い。

Python 3.0 のアノーテーション

Python Code Reading でアノーテーションがちらりと話題になりました。関数定義で

def func(a: expr, b: expr, ...) -> expr

という記述の仕方ができる、というもの。で、こうやって書いた expr は関数オブジェクトの __annotations__ プロパティに辞書で格納されます。

>>> def foo(a:int, b:"hogehoge") -> str: pass
...
>>> foo.__annotations__
{'a': <class 'int'>, 'b': 'hogehoge', 'return': <class 'str'>}

この構文を function annotation というそうです。で、アノーテーションに書かれた式の値が辞書に入るだけで、別に Python が静的に型チェックをしてくれるというわけではないです。一般に Python 関数定義では戻り値の型をコンパイル時に特定することはできませんから。

じゃあ何に使うのかと言うと動的型チェックをテスト時や運用時にするとかでしょう。他にも PEP 3107 にはIDE で関数の引数や戻り値を表示させるとか、その他 inspection のアプリケーションっぽいことが挙げられています。

戻り値の型チェックは、こんな感じでしょうか。

>>> def check(func):
    def call_and_check(*args, **kw):
        result = func(*args, **kw)
        if not isinstance(result, func.__annotations__["return"]):
            raise TypeError
        else:
            return result
    return call_and_check       

@check
def foo(x:int) -> int:
    return x

print( foo(1) )
print( foo("1") )
... ... ... ... ... ... ... ... >>> ... ... ... >>> 1
>>> Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in call_and_check
TypeError

引数の型チェックは、ちょっと面倒ですね。*args に入ってくるのか、**kw に入ってくるのかの場合分けなんかが死ぬほど面倒くさそうです。継承されたメソッドがきちんと規約に合っているか、とかなら簡単にチェックできそうです。

Penta5n - トライアスロンのトレーニング管理できるウェブサービス

トライアスロンの練習記録はどこに書いておいてもよいのですが、ジマンパワーを活用するには公開できたほうがよいです。で、作ろうかなぁと思った矢先に発見。

Penta5n はトレーニングやレースの記録を保存できるウェブサービスです。トライアスロンを想定しているので、スイム、バイク、ランにわけて記録できます。グラフ表示するときも、日ごとの表示はもちろん、積算距離も出ます。

他の機能としては、トレーニングのコーチを生業にしている会社のようで、プランニングなる機能もあるようです。が、どうもエラーが出たり、次へ進むボタンが表示されなかったりです。そのうち直るでしょう。あとライバルの登録や、VO2Max なんかを記録することもできます。ふむふむ。

iPenta5n という iPhone アプリもあって、こちらは GPS を使って走行コースの保存もできるようです。そのうち iPhone とウェブのアプリ統合もされるそうです。

しばらく使ってみようと思います。

森博嗣の S&M シリーズ

森博嗣の「S&Mシリーズ」を読みはじめ、「すべてがFになる」「冷たい密室と博士たち」「笑わない数学者」「詩的私的ジャック」「封印再度」を読みました。最後に読んだ推理小説は、小学生の頃に読んだ、江戸川乱歩の怪人二十面相シリーズなので、20年ぶりくらいの推理小説です。

謎解きがマインスイーパをやっている感じで面白いです。このセルの周りには爆弾が1個なので、こっちには絶対に爆弾が無い、というような感じです。境界条件を特定して、それらの条件を満たすような系をみつける、と。

面白い言い回しを、いくつか。

犀川は何を言ったのかよく覚えていなかった。たぶん、精神が忘却を強く望んだのであろう。(笑わない数学者 p.375)

恥ずかしい発言をした後に。

実は、あの日、パーティのあとで、西之薗君がキッチンでサンドイッチ……、のようなもの……を作ったんです。これは、僕の記憶が曖昧なのではありません。記憶は極めて鮮明ですが、彼女の作ったものが曖昧だった (笑わない数学者 p.440)

まずい料理を食わされたことを回想するときに。

犀川にとって食事のコンセプトは、エネルギィ補給であって、空中給油みたいな形態が理想である。(封印再度 p.252)

昼食時、自席でカロリーメイトを食べていることをごちゃごちゃ言われたときに。あるいは、参加したくない会食に誘われたときに。

あと、どこで出てきたのか忘れましたが「太陽暦の1月1日は、太陽系における特異点でも何でもない」みたいなのが出てきます。記念日的な行事に参加したくないときに。ちなみに、普段読まない推理小説を5冊まとめて読めるのは、年末年始の休暇くらいだと思います。