kunishi's blog

mac miniからCD-Rが排出されなくなった→解決

2011-04-06T12:55:00.000+09:00

普段使っているMac miniにCD-Rを突っ込んだところ、ディスクのマウントができない。しゃあないなあ、と思ってディスクを排出しようとしたところ、できない…2日間ほど苦しんだ挙句、Twitterで @shima__shima さんや @bleu48 さんの助けを借りて、ようやくディスクが取り出せた。せっかくなので、調べた結果も含めて書き記しておく。

まず、どんな状況になってしまったのか、ディスクユーティリティのスクリーンショットを示そう。

CDがグレーになってる…こんなん初めて見た。もう少しUnix的に状況を調べると、こんな感じだった。

/Volumes/011221_2010 というディレクトリがあるが、パーミッションが111 (--x--x--x)
dfでは /Volumes/011221_2010 は出てこない。つまりマウントが完了していない

雰囲気としてはディスクマウントのプロセスが途中で止まっている感じである。

で、やったことを順に書いてみる。3,4,5,6が @shima__shima さんから教えてもらった方法、7が @bleu48 さんから教えてもらった方法である。ちなみに、最近のMac miniのドライブには強制排出のための穴はない（これが大はまりした原因でもある…）。

キーボードのejectキーを押す→もちろんダメ
ディスクユーティリティで「取り出す」を実行→ダメ
マウスを押しながら起動：ググるとすぐに出てくる解決策だが…→今回はダメ
diskutil eject /Volumes/011221_2010→ダメ
umount -f /Volumes/011221_2010; diskutil eject /Volumes/011221_2010→今回はマウントが完了していないので、umountの意味がない。ダメ
diskutil eject /dev/disk3s0：デバイス番号を直接指定する→ "Volume failed to eject" と言われ、ダメ
ejectキーを押しながら再起動→シャットダウンの時に /Volumes/011221_2010 をumountしにいくみたいで、シャットダウンが終了しない。仕方なく、電源を強制切断してから、ejectキーを押しつつ起動→成功!!

マウスを押しながら起動するのとejectキーを押しながら起動するのとでは、なんか内部的な動作が違うのかなあ。ともあれ、修理を覚悟していたので、ほんとに助かった。@shima__shimaさん、@bleu48さんに感謝である。

ちなみに、取り出したCD-Rをもう一度同じように突っ込んでみたところ、同じように止まってしまったので、ディスクが壊れていたっぽい。速攻で（本物の）ゴミ箱行きにした。

jQuery.popeye 2.0.4 のバグ

2011-03-31T16:17:00.001+09:00

昨日の記事でも触れた、jQuery.popeyeのバグについて書いておく。

いつ、どういう不具合が起こるのか先に述べよう。jQuery.popeyeはWebページ中でインラインで画像をオーバレイ表示できるJavascriptライブラリで、jQueryをベースにしている。動作はデモページを見てもらうと一目瞭然だと思う。不具合は、画像を拡大表示したとき、あるいは画像を拡大表示した状態でスライドショーを前後に移動させたときに、存在しないURLへのHTTP GETが2回発生する、というものである。

バグはpreloadNeighbours()関数にあった。以下にパッチを示す。

--- jquery.popeye-2.0.4.js.orig	2010-06-14 22:39:42.000000000 +0900
+++ jquery.popeye-2.0.4.js	2011-03-31 15:35:26.000000000 +0900
@@ -384,7 +384,7 @@
                     } else {
                         neighbour = 0;
                     }
-                    preloaderNext.src = a[i].href[neighbour];
+                    preloaderNext.src = a[neighbour].href;
                     
                     // previous image
                     neighbour = i;
@@ -393,7 +393,7 @@
                     } else {
                         neighbour--;
                     }
-                    preloaderPrev.src = a[i].href[neighbour];
+                    preloaderPrev.src = a[neighbour].href;
                 }

配列aには、拡大したときに表示される画像へのリンク（a要素）が順次格納されている、と考えてもらって良い。a[i]が現在拡大表示されている画像（を表すa要素）である。jQuery.popeyeでは、現在拡大表示されている画像の前後の画像についてあらかじめHTTP GETを行って、ブラウザのキャッシュを利用して画像の表示を高速化するという処理を行っているように見える。

で、このバグである。a[i].hrefって、現在表示されている画像のURLであるので、a[i].href[neighbour]とは、URL（文字列）中の一文字を指してしまう。当然、配列aの添字を変更してあげないといけない。

まあ、404 Not FoundなHTTP GETリクエストが発生するだけだから、サーバのログでも見てないと気がつかないかもしれない、とも思うのだが、もし学生のプログラムだったら「もっとプログラムを勉強しなはれ!」と一蹴するレベルのバグだよなあ、これ。

ちなみに、jQuery.popeyeには難読化されたソースコードも含まれているので、パッチをあてる際には注意。ええ、両方読み込むようなHTMLを書いていたので、はまりました^^;

日本データベース学会の研究動画配信新システム

2011-03-30T17:37:00.000+09:00

今年に入ってから、日本データベース学会（以下DBSJ）が会員限定サービスとして行っている研究動画配信システムの新バージョンの実装を続けていた。先日、このシステムがめでたく公開と相成った。せっかくなので、経緯等について書き記しておこうと思う。

DBSJの研究動画配信サービス自体は、2003年に始まっている。当初から主に、3月に行われるデータベース関連の研究ワークショップ（DEWS:データ工学ワークショップ、DEIM:データ工学と情報マネジメントに関するフォーラム）を対象とし、その研究発表を、リコーのMPMeisterというソフトでWebコンテンツ化したものを配信する、というスタイルをとっていた。（MPMeisterにリンクを貼ろうと思ったが、かねて聞いていた通り、3月末で生産終了となっていたので、リンクは張らないでおく。）しかし、対象発表件数の増大に伴い、コンテンツ作成の手間がひじょうにかかるようになり、諸方面で協議の結果、今年のDEIM2011から、動画のみの配信にして手間を軽減しようということになった。この方針転換により、今年度の動画公開は、サイト運用側、つまり私に、従来より負荷がかかるものとなった。

実のところ、当初はコンテンツの構成が変わるだけで、それほど手間は増えないと考えていたし、そういう公開方法も選択肢としてあり得たと思っている。しかし、いろいろ思案しているうち、システムの全面構築し直しという方向に傾いていった。

システム設計にあたり、次のような点を重視した。

閲覧環境を極力限定しない。Windows, Mac, Linuxのいずれでも、また使用ブラウザがなんであっても閲覧できること。ファイアウォールの中からでも問題なく閲覧できること。iPhoneやiPad、Android端末などからでも閲覧できれば、通勤通学のちょっとした時間で見ることができたりするので、より望ましい。
バッチ処理による動画エンコーディングが可能なこと。事前の情報から、発表件数が300件に届くことが分かっていた。つまり動画を300本処理しないといけないわけで、バッチ処理前提の動画エンコーディング処理手順を構築しておかないと、やってられない。
AVCHD形式の動画をエンコードできること。後で分かってきたことだが、AVCHD形式の動画は、特にMacで処理するには何かと不便なことが多い。
ちゃんとしたWebアプリケーションフレームワークを使う。今後、学会のシステムを大きく改修することも念頭にあるので、それを見越しての判断である。機能面、普及度、個人の趣味^^;により、Rails 3を採用した。

試作を繰り返しているうちに、動画部分はHTML5のvideo要素によるマークアップに落ち着いていった。当初はFlash videoを考えていたのだが、手持ちのソフトでswfのバッチ処理をする方法がわからず（Adobe Flash CS4 + Adobe Media Encoder CS4で swf + flv/f4v 形式のFlash videoをバッチ生成する方法ってあるんでしょうか…）、この方法は断念した。結局、Dive into HTML5の動画に関する記事に基づき、Ogg Theora, H.264, VP8という3種類の動画をバッチ生成し、Flashも含めてvideo要素のfallbackでマークアップするという方法を採用した。ただし、Flashの組み込み方はこの記事のままではなく、Adobe Developer Connectionのチュートリアルにもあるswfobjectのスタティックパブリッシングを採用した。上のスクリーンショットでは、講演資料をハンドアウト風にスライドショーで見られるようにしているが、ここはjQuery.popeyeを利用している。

また、動画エンコードの方法も元記事から少し改良している。改良点は:

ffmpeg2theoraの最新版(0.27)では、2パスエンコーディングができるみたいなので、採用した。
HandBrakeの最新版(0.9.5)では、エンコードのプリセットがいくつか追加された。プライベートで使っている経験から、iPhone 3GS/iPhone 4/iPadでも再生可能なプリセットとしては "AppleTV" が一番よさそうと思っているので、これを採用した。

結果、300本×3 = 900本の動画のエンコーディングを行うこととなったが、この目的のためにLinux PCを2台新規に投入した結果、4日ほどですべてのエンコードが終了している。

先に書いたとおり、システム全体はRails 3で実装を行った。本格的にRailsを触るのは初めてで、Agile Web Development with Rails の 4th edition を読みながらのコーディング作業だったが、セッション管理による認証もAjaxも使って、その割に実装期間1ヶ月強というのは、我ながらまあまあ早かったように思う。Railsサマサマである。

今のところRailsのcachingも全然使っておらず、Apacheのチューニングも全然やっていないので、性能面がすごく心配だったのだが、チュートリアル講演3本を公開してからのログを見る限り、それほどアクセスの殺到もないようで、少し安心している（アクセスが少ないというのは、それはそれで、うーん、とも思うのだが）。ログを見ている限り、目論見通りiPadでアクセスされている方もいらっしゃるようで、こういうところは嬉しい。

以下、雑感である。

Railsすばらしい。
英語が読めるかどうかで、Railsの開発効率はぜんぜん違うような。githubのプラグインの説明もほとんど英語だし、疑問が出てきた時にググルと、的確な解決策が海外のブログやstackoverflowなどに出てることが多い。
パフォーマンスは今後の課題。今のところ、Rails経由で動画を送り出すのは遅いと考えて、Apache経由で送り出している。本来はRails経由で（つまりセッション管理の元で）送り出したいのだけど。
ブラウザのプラグインにはいろいろ苦しめられた。特に動画関係。勝手にsource要素をembed要素に置き換えてしまうヤツとか、入れてるだけでVP8動画のスムーズな再生が出来なくなるヤツとか（しかもFirefox 3では問題が出ず、Firefox 4になった途端悪さをするとか…一時、Firefox 4を完全に疑ってました）。
jQuery.popeyeにバグが…しかもかなり orz なバグ。開発元にはコメントしてみたんだけど、バグフィックスしてくれるかなあ。これは別記事で書こうと思ってます。
Androidはワケわかりません。ちゃんとテスト機（NECのLifetouch note）まで用意したのに、再生できるはずのH.264が再生できない…基本的に資料が少ないし、何を基準にして実装すればいいのか見当がつかず…今回のシステムリリースでは対応を見送らざるを得なかった。

iPod touchでブログの文章を書いてみた

2010-11-11T00:44:00.000+09:00

初めて、iPod touchでブログの文章を書いた。Twitterのtweetを書くとか、メモみたいなブログの下書きを書くとかいうことはこれまでもしてきたが、長文の記事を書くのはこれが初めてである。書いた記事はこちら。

流れはこんな感じである。まずDraftPadで本文をあらかた書き上げる。ここはオフライン環境でやっている。次に書いた文章をBlogPressにコピーして、オンライン環境で投稿する。実際は若干手直しが必要だったため、（Macの）ブラウザからBloggerにアクセスし、すぐにドラフトに戻して、手直し後に再投稿を行った。この辺がどうにかならないか、というところは今後の検討課題である。なお、DraftPadもBlogPressもiPadアプリがあるから、iPadで作業をしたほうが捗るかもしれない。

BlogPressで最初から文章を書かないのは、アプリケーションの安定性の問題である。一度BlogPressで書いて、投稿時にアプリが落ちて文章が全部なくなった、という痛い目をしたのだ。DraftPadは、履歴という形で過去に編集した文章をこまめに残してくれるので、（履歴が残りすぎ、という嫌いはあるものの）安心できそうである。

内容さえ決まっていれば、iPod touchでも案外書けるもんだね、というのが印象である。もっとも、私は文章を流れに任せて勢いで書いていくタイプのようなので、スタイル的に合っている、というのはあると思う。

というわけで、もう少しブログの更新もしないといけないね、という気持ちにさせられた今日の出来事であった。

postfix環境下でezmlm-idxを動かす方法

2010-09-09T13:19:00.000+09:00

日本データベース学会のサーバ交換を6月に行ったのだが、そのときに先送りになっていた作業をようやく終わらせた。MTAをqmailからPostfixに移行する作業である。学会を立ち上げたときに、私が設定に慣れているという理由でqmailを採用して以来、ずっとそのまま運用してきたのだが、何かとqmailの設計のまずさや古さが目立つようになってきて、以前からPostfixへの移行を検討していた。サーバ交換をいい機会に、移行を実行した、というわけである。

MTAの移行自体はそれほど難しくはない。厄介なのは、ezmlm-idxというメーリングリスト運用ソフトをどうするか、という点だった。これがqmailにべったり依存した設計になっており、qmail以外のMTAでは簡単に動きそうにない。諸処の事情で、他のメーリングリスト運用ソフトに移行することも難しい。

考えることは皆同じのようで、Postfixでezmlm-idxを動かす方法をまとめたページがいくつかあった。

アイデアはどちらも同じで、Postfixで受け取ったメールをqmailに渡し、ezmlm-idxのメール配送をさせる、というものである。前者はPostfixのサービスとしてqmailを定義する方法、後者はPerlスクリプトを介する方法である。前者の方がスマートに思えたので、今回、前者をベースにしていくつか方法を改良して、作業を行った。

まず前提として、qmailおよびezmlm-idxは適切にインストールして、正しく動く状態にしておかなければならない。qmail関連の設定ファイル、ユーザアカウント、パーミッションなどの設定も行っておく必要がある。もっとも、qmailが動いている環境からPostfixに移行するなら、あまり気にしなくてよい部分ではあるが。

次にPostfix側の設定である。ポイントは2つ。master.cf に qmail をサービスとして定義すること、transport_mapsを用いて、ezmlm-idxで使用するメールアドレスを受け取ったらqmailに渡すように設定すること、である。

master.cf の定義はこんな感じ。Postfix付属のコマンド pipe を用いて、メールをqmail付属のsendmailに渡すようにしている。pipeのflags=R（Return-Pathを取り除く）、user=qmailq（qmailのqueue管理アカウント）辺りに注意する必要がある。

qmail unix - n n - - pipe flags=R user=qmailq argv=/var/qmail/bin/sendmail ${recipient}

transport mapsの設定はこんな感じ（/etc/postfix/pcre_transport）。ezmlm-idxはVERPを全面的に活用しており、メーリングリストfoo@examle.comに対してfoo-*@example.comというアドレスを大量に使用する。したがって、正規表現による定義が必須である。なお、元記事の定義ではVERPを完全にカバーしておらず、例えば bounce mail の処理がうまくいかない。

/^foo(-.*)?@example¥.com$/ qmail:

main.cf に追加する transport_maps の定義はこんな感じ。

transport_maps = pcre:/etc/postfix/pcre_transport

最後に、qmailの動かし方である。元記事では「qmailのdaemonは全部止めろ」とあるのだが、これではqmailによるメール配送のログがとれない。qmailのdaemonには、SMTPリクエストを待ち受けるsmtpdと、実際のメール配送を行う qmail とがあり、後者は Postfix と同時に走らせていても問題ない。私は daemontools によって qmail を走らせているので、こんな感じで smtpd だけ止めた。

svc -d /service/smtpd /service/smtpd/log rm /service/smtpd

いくつか注意点を述べておく。

ezmlm-idx周りは完全に qmail の設定のままでよい。例えば .qmail-foo* もそのままでよく、.forward-foo* などにする必要はない。
上と関連して、仮に新しく ezmlm-idx でメーリングリストを運用する場合も、普通に ezmlm-make でメーリングリストを作成し、pcre_transport に定義を書き加えるだけで良いと思われる。
Postfix側のVERPやMaildirの機能は全く使っていない。したがって、home_mailbox = Maildir/ とか recipient_delimiter = - でなくても動くと思われる（検証はしていない）。

突然googleアカウントが無効になった

2010-06-30T19:55:00.000+09:00

久々に激しく肝を冷やした。自分のgoogleアカウントが突然無効になってしまったのだ。私のgoogle依存度を知っているひとなら、これがどんなにピンチか、わかっていただけると思う。

普段通り使っていたときに突然無効になってしまったから、心当たりもない。とりあえず、アカウントを有効にすることが最優先である。googleのページにある通り、自分の携帯電話に自動音声ガイダンスをかけてもらったのだが、これがなぜか無音なのである。何度かやってみたが、結果は同じ。困った…

Webからgoogleのサポート宛にメッセージを出すとともに、同じ手順を何度か繰り返す。そのうち、よし、音声ガイダンスが正しく流れた。ようやくアカウントが有効にできた。一安心である。そういえば、音声ガイダンスが聞けたときには携帯のマナーモードを解除していたが、いや、まさか、関係ないよね…

操作を進めよう。すると、どこかから不正アクセスがあったとかで、パスワードの変更を求められた。今まで少々安直だったかもしれない。ランダムパスワードに変更しておいた。

それにしても、いかにgoogleに依存してしまっているか、身にしみて実感させられる出来事だった。いったん不測の事態が起これば、gmailその他のデータを紛失してしまうだけでなく、インターネット上での自分の拠点を失ってしまうことになる。現実の天変地異とちがって、データのバックアップさえあれば、時間はかかっても拠点を築き直せるのが救いか。

バックアップを真剣に考えなければならない、という、ありきたりの結論になってしまったようだ。

マークアップ言語の視点からEvernote文書を見る

2010-05-20T09:59:00.001+09:00

mehoriさんの記事を見てから、Evernote文書をマークアップ言語の視点から解析してみようと思っていた。

Evernoteはクラウド上だけでなく手元のパソコンにもデータを保存しているが、これはENML(Evernote Markup Language)という形式のXML文書が主になっている。一つのEvernoteのノートが一つのENML文書になっていると考えてよい。

基本的には、ENMLはHTML/XHTMLをベースにしたマークアップ言語であり、タグセットがほぼHTML/XHTMLのサブセットになっている。極めておおざっぱに言えば、body要素の内容からいくつかのタグを取り除いたものがENML文書になると言える。ただし、XML名前空間によってタグセットが共有されているわけではなく、厳密に言えば、単にタグ名が同じであるに過ぎない。また、一部、ENML独自のタグが導入されている。

Evernoteでは、Webページをクリッピングすると、そのページの内容がテキストベースで取り込まれる。内部的には、この動作は、WebページがUTF-8のXHTML 1.0 Transitionalの文書とENML文書で保存されることに相当している。XHTML 1.0 Transitionalとして妥当でない文書でもHTML5文書でも、クリッピングするとXHTML 1.0 Transitionalになるみたいである。CSSはどうなるかというと、スタイルを保存するために新たなdiv要素やspan要素が追加され、この要素のstyle属性に展開されて、EvernoteのXHTML文書とENML文書の両方に書き込まれている。こういう振る舞いを総合すると、ブラウザ上のDOMをなんらかの方法でシリアライズして保存しているのかな、と想像している。

また、Evernoteからノートを書き出すと、単一のEvernoteエクスポート形式の文書が得られる。これもXMLであり、元々保存されているENML文書の他、ページを構成する画像その他の部品がすべてBase64形式で符号化され、単一パッケージ（単一文書）になったものである。

ENMLではスキーマをどう扱っているか。なんとDTDなのである。これは今に到るまで変わっていない。いったんDTDベースでシステムを構築してしまえば、Relax NGやXML Schemaを導入する必要性がない、ということなのだろうか。あるいはHTML/XHTMLベースなので、XHTMLのDTDをそのまま借用している、ということなのだろうか。このDTDを眺めていると、パラメータ実体や外部パラメータ実体が使われていて、なんだか一昔前にタイムスリップしたような感覚になってくる。

ENMLのDTDは途中で大きく変わっている。ENML 1.0(DTDへのリンク)とENML 2.0(DTDへのリンク)である。切り替わったのがいつか正確には分からないが、ENML 2.0のDTD中にあるCopyright表示が 2007-2009 になっているし、タイムスタンプ（これはCVSのもののように見えるが…）が 2007/10/15 になっているから、この辺に切り替わったのかもしれない。

ENML 1.0の文書モデルはXHTML 1.0 Transitionalの文書モデルと非常に似ている。各要素の内容モデルがDTDレベルで厳密に決められているし、インライン要素やブロックレベル要素など、XHTML 1.0で行われていた要素の分類を引き継いだDTDになっている。一方、ENML 2.0の文書モデルはかなりルーズであり、どの要素の内容にどの要素が出現してもよい。要するにこんな感じである（説明のため、ENML 2.0 DTDの記述を意訳?している）:

<!ELEMENT a (#PCDATA | a | abbr | .... | var)*>

ところで、ENML 2.0 DTDの冒頭に面白いコメントが書いてある。

This is based on a subset of XHTML which is intentionally broadened to reject less real-world HTML, to reduce the likelihood of synchronization failures. This means that all attributes are defined as CDATA instead of more-restrictive types, and every HTML element may embed every other HTML element.

現実のHTMLをなるべく排除しないように、またその結果として同期の失敗の可能性を減らすために、内容モデルを広げた、という感じだろうか。

あんさん、そら、アタリマエでんがな。みんながみんな、文書をDTDどおりに書いてくれるなんて、大間違いや。文書のココロが分かってへん。まあ確かに、なんでもタグを許したら収拾つかんようになるさかい、制限したい、ゆーのは分かるんやけど、DTDつこたらあかんわ。well-formed で我慢しとき。

本: 一澤信三郎帆布物語

2010-05-20T01:13:00.001+09:00

一澤信三郎帆布物語 (朝日新書)

posted with amazlet at 10.05.20

菅聖子
朝日新聞出版
売り上げランキング: 169767

Amazon.co.jp で詳細を見る

中学から大学院まで足かけ15年も京都に通っていたためか、一澤帆布の鞄にはずっと憧れていた。自分のお金で最初に買ったのは、白いショルダーバッグだったように思う。汚れが目立ってくる度に手間をかけて洗い、裾がほつけてくるまで使ったような覚えがある。その後も一澤帆布の鞄にはずっとお世話になってきた。

基本的に京都ローカルの小さな商店、でも個人的にとても愛着のあった一澤帆布が、よりによってお家騒動で一気に有名になってしまったときには、複雑な気分であった。そのときには京都を離れてしまっていたので、一澤帆布にも信三郎帆布にも立ち寄る機会がなく、ようやく店を訪れることができたのは2007年。信三郎帆布もかなり軌道に乗ってきたように感じられる時期であった。品物を実際に見れば、どちらに義があるかは明らかだった。信三郎帆布が往年の一澤帆布の丁寧なモノ作りを受け継ぐ一方で、一澤帆布は手抜きが目立った。正確には、職人の技量が足りず、妥協したモノ作りをせざるを得なかった、ということなのだろう。マスコミの報道なんかより、品物こそがはるかに雄弁に真実を語っていたように思う。

この本が書かれたきっかけは、もちろんこのお家騒動であったろう。しかし実際の文章からは、お家騒動の話よりも、信三郎氏と職人さん達の真摯で手抜きのない、しかしあそびのあるモノ作りが印象に残る。タイトル通り、一澤信三郎さんのドキュメンタリーである。

モノ作りや商売の視点から見ても、信三郎氏のアプローチは実に興味深い。金具一つに至るまでこだわる姿勢はアップルのそれに通じるところがある。クチコミをベースとしたスモールビジネスに徹するのも、何となく今風である。しかし商売のテンポは、インターネットのスピード感とは無縁の、ゆったりとしたものだ。何十年経っても、やっぱり東山の地で同じようにいい鞄を作ってくれているに違いない。そんな気持ちにさせてくれる。実に京都らしい商売の仕方やなあ、と、京都出身の私は思うのである。

IKEA初体験

2010-05-06T05:33:00.004+09:00

IKEAポートアイランド店に行ってきました。デザインや音楽を通して北欧、特にスウェーデンに関心を持っている私にとって、IKEAは一度行ってみたい店の一つでした。関西に戻ってきて、手軽に行けるようになったのは幸いでした。

今回の目的は、自宅のワークスペース用の机や椅子を揃えることでした。主な居室が畳からフロアリングに変わって、これまで使っていたロータイプのデスクが使いづらくなった上に、椅子が娘のお気に入りになってしまい、娘に分捕られてしまったのです。お蔭で今は、フロアリングに座布団を敷いて正座をしながらパソコンを使う有様です。どういうワークスペースにするか、ようやくアイデアが固まってきたので、いざIKEAへ! という次第でした。

印象は、というと、とにかくでかかった。建物も、ショールームも、レジも、レストランも、とにかく何もかも… アメリカタイプのショッピングセンターに慣れていれば当たり前なのかもしれませんけど。とにかくスペースが非常に広いので、展示も比較的ゆったりしてるように思いますし、入り口からレジにたどり着くまで結構時間がかかります。でもそのおかげで、なんとなく買い物がゆったりできました。ショッピングに行くと、あとでどーっと疲れが出るんですが、それが比較的なかったなあ、と。この後、三宮の繁華街に出たんですけど、時間的には短いのに、そっちのほうが疲れが大きかったです。このゆったり感は、たぶん、照明やBGMが抑えてあることも要因になっているように思います。

商品は豪華ではないけれど、ちゃんと作ってあるという感じを受けました。そういうところも北欧らしいなあ。インテリアもいいものがいろいろあったし、また来てみようと思いました。

もう一つ面白かったのが、最寄りのポートライナー南公園駅です。写真をご覧あれ。

どこの外国の駅でしょう? という感じの装飾なんですね。ちなみに写真の dalahäst というのは、スウェーデンに古くから伝わる装飾つきの馬（の玩具?）のことです。もっとも、下の説明も英語だから、大半の日本人は「きれいな装飾」くらいにしか思わないんでしょうねえ。文化交流を意識してるのであれば、日本語で説明を書いた方がよいのではないのかなあ。

ちなみに、買ったものは下記の構成です。居室が4畳半なので、なるべく重厚にならないようにして、圧迫感を出さないように心がけました。まあ、さんざん迷った割には割と普通の構成ですね…

机…VIKA AMONテーブルトップ（120×60cm, バーチ調）+ VIKA ANNEFORSテーブル用脚・収納付き（ホワイト） + VIKA CURRY脚（ホワイト）
椅子…NOMINELLS回転チェア（ブラック, アームレスト付き）
キャビネット…ERIK引出しユニットキャスター付き（ホワイト）

山本陽平君の「Webを支える技術」

2010-04-22T13:15:00.001+09:00

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)

posted with amazlet at 10.04.22

山本陽平
技術評論社
売り上げランキング: 134

Amazon.co.jp で詳細を見る

やっと昨日読み終えました。素晴らしい労作です。Web開発に関わる人は必読の本です。

昨今これだけWebが普及し、Webサービス開発が注目されている割には、Webに関するまとまった良い資料はなかなかありません。実際、昨年の講義でWebを取り上げたときにも、下調べと講義資料作りにかなり苦労しました。

URIにせよHTTPにせよAtomにせよ、簡単な紹介か、さもなくば仕様書という状態ではないでしょうか。中間がないのですね。また、これら個別の技術を俯瞰し、Web全体を説明する資料というのは、私の知る限り、W3CのArchitecture of the World Wide Web, Volume Oneしかありませんでした。この文書はもちろん貴重ですが、最初の導入の資料としては、記述が細かすぎるのと、どうしても関連仕様を芋づる式に参照しなければならないのが欠点であったように思います。芋づるをたどっていくときりがないので、どこかで打ち切らなければならないわけですけど、どこで打ち切るかの見極めが難しい。特にWebの場合、開発の現場での使われ方というのが要不要を決定する主要因になるように思っていて、私のように、仕様から技術を眺めてしまいがちな大学教員からすると、なおのこと見極めが難しいのです。

yohei君の新著「Webを支える技術」は、上に述べた空白地帯を埋め、Webを俯瞰することのできる、素晴らしい書籍です。技術者としてWebに関わるときに最低限知っておいてほしいことを、簡潔かつ分かりやすくまとめています。

何が書かれているか、も大事ですが、それと同じくらい、何が書かれなかったか、何が省かれたか、その取捨選択の適切さが、現場を良く知っているyohei君ならではの視点であり、本書の素晴らしい点です。取捨選択の過程で、どれほど芋づるをたどり、また捨てていったのか、その労力を想像するに、頭が下がる思いです。（自分も苦労しただけに…）

もう一つ素晴らしいのが、バックボーンに情報科学の視点がちゃんとあるところです。表面上あまり出てきませんが、11.2節のセマンティクスの説明とか、17章のリソース設計の辺りが、ちゃんと情報科学を学んだ人ならではの書き方だなあと思いました。こういう記述があると全体が引き締まった感じがするのは私だけでしょうか。

理論と現場の両面から長くWebと関わってきたyohei君だからこそ書けた本だと思います。

初めての人のためのLISP [増補改訂版] (竹内郁雄)

2010-04-15T11:40:00.001+09:00

初めての人のためのLISP[増補改訂版]

posted with amazlet at 10.04.15

竹内郁雄
翔泳社 (2010-03-10)
売り上げランキング: 1779

おすすめ度の平均:

この本を読まずしてなんとする！
Ｌｉｓｐのおすすめテキストです

Amazon.co.jp で詳細を見る

なんといってもあの竹内先生の書いたLisp本ですから、買わねばならんだろう…と思って購入しました。ぱらぱらとめくってみてピンと来たので、他の積ん読本を差し置いて読み始めて、一気に読んでしまいました。

恥ずかしながら、旧版は読んでません。もともと「Computer Today」誌に連載された頃（1983年）は中学生から高校生あたりで、プログラミングには興味すら持っていませんでした。大学に入ってからも実験はFortran, Pascal, PL/1, アセンブラあたり、研究室でもC言語、講義でも関数型言語に触れる機会はなく（大学院でラムダ計算の講義があったんですけど、初回をやむを得ず欠席したら輪講形式になっていて、入り込めなかった）、旧版が出た頃（1986年）は、Lispは関心はあっても縁がない言語でした。そんなわけで、この有名な本に触れるのは今回が初めてです。

オビに「天下の奇書」とありますけど、まさにその通りですね。竹内先生の語り部の部分が存分に発揮されてて、実に面白い読み物になってます。想像ですが、竹内先生の講義って、何をやってもこんな感じだったんじゃないかなあ。

講義を連想したのにはいくつか理由があります。まず、17章構成で、講義の標準回数（15回）に近いこと。17章のうち、最後の章は増補改訂版のときに加筆された部分で、さしづめ、竹内先生の最終講義といったところでしょう。そうすると、残りは16章。「15回講義やったんだけど、終わらなかったから、もう1回補講するわ」という感じです。もう一つは、本文中の随所に出てくる、「細かいところはいいから、Lispの心をつかんでほしい」というメッセージです。これって、自分が講義をやってるときにいつも思うことなんですよね。講義という場の性格上、学生に飽きさせないように内容を構成するというのは重要なことで、そのためには詳細に立ち入らなかったり、場合によっては多少ゴマカシを交えて話を単純化する、ということをよくします。竹内先生の手法はまさにそれなんだろうと思いました。

そういう同業者の視点で見ると、この本が偉いなあと思うのは、Lispの泥臭い部分をあえて盛り込んでるところです。理論的な内容ほど講義はやりやすくなり、泥臭い話ほど講義はつまらなくなりがちです。自分もそれでいっぱい失敗してきました。竹内先生は、そこを面白い話術で軽々とクリアしてるんですよね。すごい語り部の能力だなあと思いました。

一度、竹内先生の講義を受けてみたかったなあ。

遠距離通勤生活4週目

2010-04-13T23:20:00.001+09:00

明石に引っ越してから3週間経った。自宅は明石、職場は総社ということで、新幹線と在来線による遠距離通勤生活も、はや4週目である。岡山駅での接続がよい組合せを見つけたので、実質、自宅から職場まで1時間半というところである。

よく「1時間半も通勤にかかるのでは、大変でしょう?」と言われるのだが、実はそうでもない。いや、むしろ、この1時間半は誰からも干渉されない貴重な時間であって、ここを有効に活用しないともったいない、という気持ちのほうが強い。結果として、「この通勤時間を最大限に生かすには、それまでに何をしておけばよいか?」とか「仕事場に着いたらすぐに仕事に取りかかれるようにするには、この時間に何をすればよいか?」というような考え方をするようになってきた。例えばフィードリーダ(Google Reader)のチェックをするなら、あらかじめフィードのタイトルだけ見て面白そうな記事をEvernoteに全部放り込んで、オフラインの通勤の間に読む（このときにタグ付けも行う）といった感じである。引っ越す前からOmniFocusを使ったGTDを実践しているのだが、それが活きている。

ほかにも、いろいろ生活パターンが変わった。プラスの効果としては、読書量がぐっと増えてきた。それに、出勤・帰宅の時間がほぼ決まって、それによって生活にリズムが出てきた。一方で、ブログの更新や物書きをいつどういう形でやるか、その辺りの生活パターンはまだつかめていない。ブログの更新が滞ってるのは、そのせいもある。

私の場合は、自家用車で近距離通勤するより、列車で遠距離通勤するほうが、性に合っているみたいである。

追記: Google Readerから記事をEvernoteに放り込むのは以下の記事を参考にしている。

Google Reader から直接 Evernote に記事を送る（はてブにも！）

引っ越しました

2010-03-23T21:40:00.001+09:00

この度、長らく住んでいた岡山を離れ、明石に引っ越しました。妻が関西の大学に常勤で勤務することになり、子供のこととか諸々考え合わせた結果、引っ越しが最善だろうということになった次第です。

ただ、私の職場は今まで通り、岡山の大学です。ということで、今日から、明石と岡山を新幹線で往復する遠距離通勤を始めました。岡山と言っても実際は総社ですから、待ち時間込みで1時間半から2時間くらいはかかりそうです。

まあ、私自身は遠距離通勤はあまり苦にしていません。中学生の頃から遠距離通学していましたし、今の大学に来る前は、大津の自宅からNAISTに通勤していました。むしろ、通勤が車から列車になったことで、自由に使える時間が増えて重宝しそうです。実際、今朝の車中では、たまっていた日記を書くことができましたし、このブログを書いているのも新幹線の中です。なるべく早いうちに遠距離通勤は解消したいなあ、とは思っていますが、まあ、今後どうなるかは分かりません。

久々に関西に戻ってきて、ホームグラウンドに戻ってきた気分です。生活環境も便利になりました。今まで住んでいたところは、最寄りのコンビニまで歩いて15分とか、スーパーにも車でないと行きづらかったりしましたからね。

岡山でお世話になった方々、これまでありがとうございました。勤務地はまだ岡山ですから、またお世話になることもあると思いますが、その際はよろしくお願いします。

DEIM2010@淡路夢舞台

2010-03-03T18:52:00.001+09:00

データ工学関連の国内最大のイベントである、DEIM2010に行ってきた。今年は会場が淡路夢舞台、宿泊が隣接するウェスティン淡路ということで、なかなか豪華だった。ホテルの豪華さは今までのDEWS・DEIMで随一じゃないだろうか。大学のスケジュールの関係で、ここ何年かはどうしても都合が付かず、泣く泣く参加を見送ってきたのだけど、今年は情報処理学会第50回全国大会のおかげでDEIMの日程がずれて、うまく参加できた。研究を聞けるのもいいことだけど、それ以上に、旧知の研究者の人たちと会って話をするというのが楽しい。たとえ研究と直接関わりのないことであっても、話をしてると刺激を受けることができる。

今回は、シンポジウム開催前に公式Twitterがアナウンスされ、それとほぼ同じタイミングで公式ハッシュタグが決まったので、データ工学関連の国内会議では初めて、Twitterが積極的に使われた。研究発表の様子をtsudaる人も複数人いたし、シンポジウムに参加してると思われるTwitterアカウントをまとめて公式アカウントのリストにしたり、実行委員会からの連絡がTwitterでいちはやく流れたりした。会場内はほとんど無線LANが通じてたから、Twitterを普段から使ってる人にはおもしろかったんじゃないかと思う。会場内の人、別会場の人、DEIMに来てない人…普段ならきっと話をすることのなかったであろう人と、まさに研究発表が行われている瞬間に話をしている、というのはとても新鮮だった。コメンテータ委員会でも「おもしろかった」という意見が意外な人から出てた（まさかM先生がTwitter見てるとは思わなかったな）。もっとも、同時期に行われていたインタラクション2010に比べると、積極的にtweetする人の数は限られていたし、ハッシュタグを付けずにtweetしてた人も結構いたように思われる。この辺りは、参加者の意識の問題でもあるわけで、回を重ねれば変わってくるのかもしれない。今後も続いていってほしい企画の一つである。

個人的にも、今までから積極的に聴いていたXMLのセッション以外に、データマイニング系のセッションに、意識して積極的に参加した。指導している学生にもデータマイニング系のセッションで発表してもらったし、別のデータマイニング系セッションでコメンテータもした（こっちは希望したわけではなかったのだけど）。最近、自分の研究の方向性として、文書を扱う、というのを一つの軸にしたいと思っていて、その過程で、自分がこれまであまり知らなかった機械学習のあたりを勉強しておいた方が良さそうだ、と思い始めている。その一環である。もっとも、コメンテータはしんどかった…行列式とか、大学生の頃からほとんど触れてないので…

XMLのセッションは、今回は割と下火だったような気がする。そろそろ新ネタがでにくくなってきているような印象があるね。それと、自分の興味がやはり文書寄りにあるんだなあと再認識した。理論的な話で言えば、木オートマトンをベースにしたスキーマ理論のあたり。大阪大の石原先生のところの研究がいちばん興味を惹いた。でも、たぶん、この辺はデータ工学界隈のXML研究としては主流とは言えないんだよね。

Twitterでも何人かtweetしてる人がいたから書いておくと、DEIM2010の予稿集は、5月頃には公式サイトで公開される予定である。また発表については、日本データベース学会会員に限り、ストリーミング配信される予定である。

iTunes Storeで思わず買いすぎてしまうのを防ぐには（iTunes Cardは使わないよ）

2010-03-03T17:55:00.000+09:00

iTunes Storeで思わず買いすぎてしまうのを防ぐには : ライフハッカー［日本版］, 仕事も生活も上手くこなすライフハック情報満載のブログ・メディア

私もiTunes Storeでは半端じゃない量の曲を買っていて、この問題はずっと頭を悩ましているところではある。なので、期待して読んだんだけど、結局「クレジットカードで買うのをやめてiTunes Music Card（≒現金）で買おう」という話で、少々がっかり。田舎に住んでると、iTunes Music Cardを売っている店にすぐ行けるわけではないから、カードを買いにいくだけで億劫になりそうだ。Apple Storeから買えばいいのだけど、それでも到着までに何日かかかるわけで、本当にすぐ買いたい曲が買えない、てなことが起こりそうで、それはそれでストレスになる。

最近どうしてるかというと、買いたいアルバムがあってもすぐには買わず、必ず一旦ウィッシュリストに放り込むようにしてる。で、あとでウィッシュリストを眺めて、それでも欲しかったら買う。どのくらい冷却期間をおくかは場合によるけど、なるべく1週間、最低でも2〜3日はあけるようにしてる。どうしても欲しくて、ウィッシュリストに入れたその日に買ってしまうこともあるけど。今は、ウィッシュリストに20個くらいアルバムが放置されてる。

私の場合は、これだけでずいぶん買う量が減った。もっとも、冷却期間を置くというのは以前からお買い物でやってることだし、アマゾンでもだいぶ前からやっている。つまり、私に合った方法だった、というだけのことなんだけど、まあ、記事を見かけた勢いで書いておいてみよう。

情報処理学会DD研@甲南大学

2010-02-09T19:28:00.001+09:00

1月29日に情報処理学会デジタルドキュメント研究会(SIGDD)が甲南大学であるというので、参加してきた。SIGDDは自分の興味に近い研究会で、以前から参加したかったのだが、なんせ地方大学の一教員が自由に使える旅費は少なく、DB系の学会に参加するだけで精一杯で、なかなか調整できなかった。今回は近場だし、HTML5のチュートリアルをして中核メンバーと知り合いになったので、行ってきた、というわけだ。

行ってよかったなあ、と思うのは、今まで名前だけ存じ上げていた方に懇親会の場で直接お話ができたことだった。

まず大野邦夫先生。SIGDDの予稿集で、XMLや日本語組版について何度も投稿されており、名前だけは存じ上げていたのだが、HTML5のチュートリアルは泣く泣くご欠席ということで、お会いする機会がなかった。今回自らご発表されていたのだけど、その中でCLOSなる言葉を使われていて、「おー、CLOS! なつかしー」と一人感激していた（おおげさ）。懇親会でたまたま臨席になったのでお話ししていたら、NTT時代に「Lispの神様」こと竹内郁雄さんのもとでLispを使っておられた、とか、GNU Emacsマニュアルの日本語訳に関わられた、とか、面白い話がいろいろ出てきた。共通の知り合いもいることが分かったし（rayちゃん、お元気そうでなにより）。

もう一人は小林龍生さん。かつて「XML開発者の日」なる濃いーイベントがあったが、そこでUnicode漫才をされてた方、と言えば、ピンと来る人にはピンと来るだろう。私もこういう認識である。ジャストシステム在籍時に共著でSIGDDで発表されてたのは知っていたが、こんな場でお会いできるとは。「XML開発者の日」の壇上におられた方は、自分にとってはある意味憧れで、機会があればお近づきになりたい人たちなのだ。村田真さん、川俣さん（xml-usersメーリングリストで私の「Data on the Web」翻訳を取り上げていただけた）、檜山さん（ブログにコメントさせていただいたっけなあ。松本吉弘先生の著書の話で盛り上がったような…）、細谷先生（後にXYZ研究会でお近づきになれた）、宮下尚さん（Meadowで名前は存じ上げていたけど、こんなところでお会いできるとは。やはり後にXYZ研究会でお近づきになれた）などなど。小林龍生さんもその一人だ。XML開発者の日の話を持ち出したら、照れておられたけど。

実際の小林さんは、どことなく技術者らしくない雰囲気を漂わせていらっしゃる方だった。懇親会の場での話題は、日本語の話を中心に、戦時中の戦艦の話まで多岐に及んだ。でも、技術の話にはあまりいかない。なんか、文系の研究者と話をしているような感じを受けた。「イチローがインタビューに必ず日本語で受け答えをするのはなぜだと思うか」「Google日本語入力は『みぞうゆう』と入力すると『未曾有』と返すけど、こういう日本語入力を留学生が使いたいと言ってきたらどうするか」なんていう問いかけをされてくるのだ。後者は、正しい日本語とは何か、という、非常に根源的な話なのだろうと思う。後者については「長く日本にいるつもりの留学生になら、勧めるかも」と答えたが、とても難しい。

「XML開発者の日」の昔話でも盛り上がったのだけど、小林さんはこのイベント（特に3回目あたりまで）のことを「皮膚がひりひりするような」と形容しておられた。私は2回目から参加した人なのだが、この形容を聞いて、なんと的確な表現をされる方なのだろう、と思った。プログラムだけを見れば、今流行りの勉強会と似ているのかもしれない。でも、実際は違っていた。XMLという期待の技術と、その裏にある、文書、文字、マークアップ言語、といった過去の「怨念」（と村田さんは形容されていたような）、銀の弾丸にはなり得ないというある種の諦念、そういうのが一緒くたになって、独特のエネルギーを持った場になっていたと思う。そして、その場にいる人は、背景の説明なしに発表を理解できる、つまり、同じ感覚を共有する人たちだった。それを一言で言いのける小林さんはすごいなあ、と思った。

機会と旅費があれば、SIGDDにはまた参加しよう。そして、懇親会でまた面白い話に加わらせていただくことにしよう。

VOXからのお引っ越し、続き

2010-02-08T00:59:00.001+09:00

昨日VOXからWordpress.comへのインポートを行ったばかりなのだが、もうWordpress.comから移行をやってしまった。ここのところあまりに忙しい上に、風邪気味で体調が悪く、逃避行動してしまった、というのが正直なところである。

結局どうしたかというと、このブログに統合してしまった。過去の経験からして、複数ブログを持っていると、結局使い分けに困ってしまうということが往々にしてあったからだ。やはり私は「入り口一つの法則」（by 野口悠紀雄）が合っているらしい。

やり方は難しくなかった。Wordpress.comからエクスポートしたファイルをWordpress2Blogger conversion utilityで変換し、Bloggerの新規ブログにインポートする。あとは、リンクや画像などをBloggerの環境に合わせて変更し（これが一番時間がかかるのだが…）、Bloggerのヘルプにしたがって統合するだけであった。WordpressのエクスポートファイルはRSS 2.0ベース、BloggerはAtomベースということで、変換はそれほど難しくはなかろうとは思ったが、想像通りであった。

Typepad Micro, Wordpress.com, VOX, はてなダイアリー、と、アカウントだけ持っていて使わないブログが増えてきたなあ。

VOX Importer for Wordpress.com

2010-02-06T00:42:00.001+09:00

ついにVOXから脱出する方法ができた! しかも公式ツールですよ!

いやー、興奮した。Wordpress.comがVOXのブログからのインポータを公開してくれたのだ。

VOXというのはもちろんTypepadが立ち上げたブログサービスであるわけだけど、公開範囲を細かく制御できたり、写真や本、音楽といったメディアコレクションを公開できたり、と、先日公開されたTypepad Microとかなり重なるところを狙ったサービスだったのではないか、と思っている。で、おもしろそうなので、アカウントを取って細々と使っていたわけなのだが、VOX自体があまり流行らないうちに、機能の進化が止まってしまったように思う。開発者がいなくなったのかなあ、と、勝手に想像しているのだけど。

このVOX、一つ致命的な欠陥がある。ブログ内容のエクスポート機能がないのだ。おかげで、自分の書いた文章を持ち出すわけにもいかず、ほとほと困っていた。Typepad Microの公開で、一番期待していた機能はVOXからのインポート機能だったのだけど、まさか、本家のTypepadではなく、Wordpressがやってくれるとは。

Wordpress.comはアカウントを持っていたので、早速使ってみた。とてもよくできている。ブログの記事、コメント、添付ファイルを残らずインポートしてくれるし、タグも保存されている。非公開ブログ記事も、非公開のままインポートしてくれている。メディアコレクションはインポートしてくれないみたいだけど、まあ、これはあきらめもつく。

これでVOXは塩漬け決定。そのうちアカウントごと消してしまってもいいかな。Wordpressをそのまま使い続けるか、どこかへエクスポートするかは、そのうち決めることにしよう。

本日の出来事

2010-01-22T18:50:00.001+09:00

とある書籍の執筆について、出版社の方と打ち合わせをした。しばらくの間、さらに忙しくなりそうだ。私にうまく書けるだろうか。ともあれ、話は進み始めたから、あがいてみるしかない。

センター試験、今年も無事終了

2010-01-18T14:32:00.001+09:00

昨日は一日中、センター試験の監督だった。新型インフルエンザも出ず、無事終了することができた。

私の大学では、幸いにして、２日間のうち1日だけ担当するだけで済んでいる。今回も朝8:00に集合して18:30までの一日仕事、しかもそのかなりの部分は立ち仕事なので、2日間担当だと、正直翌日は疲れて何もできない。1日だけでよいというのは本当に助かっている。

今年は久々に2日目の担当だった。昔は１日目も2日目もたいして変わらなかったのだけど、今はリスニングがある分、1日目のほうが精神的にしんどい。2006年度にリスニングが始まって以来、4年連続で1日目担当だったので、今年はだいぶ気が楽だった。

リスニングの何がしんどいかというと、通常の試験とトラブル対処の方法が全く違っていて、しかもその対処方法が多岐にわたっているところだ。最初の年なんか、トラブル対処のフローチャートが30くらいあったのではないか。普段毎日のようにやっている業務ならともかく、年に一日しかやらない業務についてフローチャートを30も覚えるのは、到底無理である。とにかくトラブルが起こりませんように、と神頼みしていたのを今でも覚えている。最近はノウハウもたまってきて、だいぶ整理されてきたようだが、それでも、たまにしか監督業務を担当しない先生やメカに弱い先生だと、かなり恐怖を覚えておられるそうである。

あと、センター試験はとにかく全国一律、公平に実施するということが重視されていて、実施体制側でも守るべきルールがとにかく多い。例えば、読み上げる台詞は一言一句完全に指定されていたりする。今年はさらに、新型インフルエンザ対策でてんやわんやだったようだ。監督要領の印刷段階で対策が間に合わなかったのだろう。今年の要領には、かなりの訂正が入っていた。私の大学では、なんと、その訂正の大部分について、訂正済みの紙がのり付けされていた。おそらく大学の事務方がやったことであろう。その労力たるや、頭が下がる。事務方も、そしてセンターも、当日はぴりぴりしていたことであろう。

受験生も最初は緊張しているのが多い。センター試験に失敗してはならない、という気負いもあるだろうし、会場に慣れていない、という、割と単純な原因もあるだろう。前日に下見ができるとはいえ、試験会場の中まで見られることは稀だろうと思う。初めての場所で、（現役生の場合）本物の大学入試を初めて受けるわけだ。緊張するな、というのが無理だろう。

受ける側も実施する側もとにかくぴりぴりしている状態で試験はスタートするわけで、1日目の最初の科目のときは、空気が異様である。それに比べれば、久々の2日目の空気はだいぶ穏やかであった。

自分は大学教員だから、受験生を選抜する側でもあるのだけど、こうやって実際に試験に臨んでいる受験生を見ると、みんな応援したい気持ちになってくる。どういう結果になるかは分からないけど、あと少し、最善を尽くしてもらいたい。

今年を振り返って

2009-12-26T23:04:00.002+09:00

忙しかった今年も、ようやく終わりに近づいてきた。28日は休暇を取ったので、昨日で仕事納めであった。

今年は本当に忙しかった。いや、忙しいというよりも、自分の自由な時間が全く取れなかった、というのが正しいか。育児に追われて、自宅でMacの前に座って何かする、という時間がほとんど取れなくなってしまった。平日の夜も然り、土日も然りである。結果的に、このブログもほとんど更新できていない。月に3本ペースになってしまった。日々のフィードリーダチェックも、ざっと眺めて注目記事に印をつけるだけ。記事の内容を熟読するところまで、とても手が回らない。

職場のほうはというと、これも忙しかった。講義4コマ、実験3コマ、研究室のゼミ3〜4時間を毎週やっていると、残りの時間はほとんど講義の準備と大学の雑用と学会仕事（論文誌の編集委員とか）で終わってしまう。特に後期に入ってから、新たに始めたRubyの講義の準備が大変で、毎回3時間かけて準備しては、うまくいくかどうか不安を抱えつつ、ヒヤヒヤで講義をする、という繰り返しだった。

時間に余裕がないと、心にも余裕がなくなってくる。来年はもう少し余裕を持った生活にしたいものだ。

かな入力が効かなくても「ことえり」の再変換は使える

2009-11-18T18:12:00.003+09:00

たまたま発見したので、うれしがって投稿してしまおう。

日本語入力には「ことえり」を使っているのだが、たまに、ひらがな入力モードにしているのにひらがなが入ってくれなくなることがある。あまりちゃんと調べてはいないのだけど、Safari で起こることが多いように感じる。この状態になってしまうと、いくら「ことえり」のモードを切り替えても復旧せず、該当アプリケーションを立ち上げ直すしかなくなってしまう。Gmail、Google Docs、ブログ、…、Safari上で日本語入力を行う機会が多い昨今、この状態になってしまうと本当に困ってしまう。

今日発見したのは、この状態でローマ字入力をした後、かなキーを2回押したら仮名漢字変換が行われる、ということである。調べてみると、これは「ことえり」に元々備わっている再変換という機能らしい。Macを何年も使っていながら、今回初めて知った。「ことえり」の動作が変になった状態でも再変換が使えると分かったのは収穫だった。

科研費の申請終了

2009-11-02T18:30:00.001+09:00

先週の金曜日、来年度の科研費の申請書類を提出した。ほとんどの大学はもうとっくに終わっていると思うのだが、うちの大学はずいぶん遅くまで待ってくれている。

まあでも、これも良し悪しで、裏返せば、事務局は最低限の形式チェックしかしないということなので、申請書のクオリティは教員の責任で上げないといけない、ということでもある。本音を言うと、結構この辺は辛かったりする。研究資金の取り方が未だによく分からないまま、毎年申請書を出している状態なのである。

大学の教員というのは案外徒弟制度みたいなところがあって、研究の仕方にしても、講義の仕方にしても、基本的に誰からも教わる機会がない。たまたま身近に何かの技術に秀でた先達がいたら、そこから技術を盗む、というのが多いのではないか。後は個人の能力に依存した創意工夫が頼りだろう。個人の得手不得手に依存しているから、オールラウンドに秀でるというのはとても難しい。

研究資金の取り方もそういう技術の一つで、誰からも教わる機会がない。その上、私は基本的にあまり物欲のない人で、かつ、中長期の研究計画の立案も得意でない。こんな状態だから、科研費の申請書類書きもすごく苦手である。過去に審査結果の開示を求めたときも「資金の使い方の計画に問題あり」と指摘されてたっけ…自分でも分かっていて考えてはいるけど、計画の立て方がうまくならないんだよね…

妻が以前所属していた私大では、申請書類の学内提出期限がかなり早く、その代わり、事務局で結構チェックが入っていた。事務局に優秀な人がいるからできることなんだろうけど、こういうのを聞くと、うらやましいなあ、と思ったりする。

今年の申請書も、提出してから、ああしとけばよかったかなあ、これはよくないなあ、と思うところしきりである。まあ、もう提出してしまったからしょうがないよね。

出来の悪い学生って、普段こんな心境なのかなあ。

手帳をmoleskineに戻す

2009-10-13T18:38:00.004+09:00

私のGoogle Readerには、最近手帳の話がよく出てきている。文房具には自分も割とこだわりがあるようで、文房具、特に手帳の話題がよく出てくるブログを見ると、つい購読してしまう。季節柄、来年度の手帳が出てくる頃なので、皆さんどうも語りたがる、というわけだ。私もやっぱり語りたくなっているので、こんな記事を書いている。

ブログに書いてなかったかもしれないが、今年の前半は、初めて「ほぼ日手帳」を使ってみていた。前から気になっていた手帳で、でも冷静に考えるとどうも用途がぴたりとこなくて、毎年見送っていたのを、昨年末、どうにも我慢できなくなって購入してみたのだ。

結果は…やっぱり7月くらいで挫折してしまった。最近、スケジュール管理はiCal + iPod touch （財政面その他で iPhone は買いたくても買えないのだ…）に移行してしまっているので、使うとするなら事後、つまりやったことや気になったことを日記風に書く、という用途が中心になる。そうすると、ほぼ日手帳は、升目が細か過ぎるとか、万年筆の乾きがもう一つ悪い、とか、自分としては気になるところが多い。

日記だったらTwitterやブログはどうか、というと、そうもいかない。オンラインでは書けないこともいろいろあるわけで、それを書き留めておきたいのだ。

というわけで、考えた末、再びmoleskineに活躍していただくことと相成った。前に使っていたハードカバー Plain Pocket がまだ残っているので、これを使い切った後、ハードカバー Rules Pocket に移行する予定である。どうやら私は万年筆で文章を書きたいらしいので、これが一番合っているみたいだ。文章を書きたいというのは、Twitterをやりつつも、このブログを結構続けているという辺りとも共通している気がする。

moleskineの日記タイプにしなかったのは、8月頃から日記を書き始めて、日によって分量にかなりムラがあることが分かったためである。半ページほどの日もあれば、2ページ以上に及ぶこともある。書きたいことが2ページあるのに、それを無理に1ページに抑えるのが嫌だった。

ちなみに、私の「ほぼ日」を見て気に入ったらしい妻は、今年度に引き続き、来年度も「ほぼ日」でいくそうな。オンラインストアで購入した来年の「ほぼ日」が先日届いて、嬉々としている。まあ、ユーザを一人増やした、ということで、私の「ほぼ日」もそれなりに役に立った…ということにしておこう。

Rubyの講義を始めた

2009-10-08T11:30:00.005+09:00

勤め先の大学でも、先週末から本格的に講義が始まった。この後半年間、講義の準備などで忙しい日々が続くことになるが、今年は例年以上に負荷がかかりそうだ。3年生対象に行ってきたプログラミング言語の講義の内容を、JavaからRubyに変えたからだ。この変更自体は何年も前から考えてきたことで、カリキュラムの変更を機に、ようやく実行に移したというわけである。

Javaの講義を始めたのはこの大学に着任した翌年だから、かれこれ10年くらいになるだろうか。オブジェクト指向プログラミング言語といえば、SmalltalkかC++がまず挙がる頃だった。そんな中でJavaを取り上げたのは、アプレットという講義で教えるには適当な題材があったからだ。ブラウザでプログラムが動くというのは学生の興味を惹く話だし、そのために教えるべき内容もあまり多くはなかった。演習を伴わない、という制限の下での講義なので、話だけでそこそこ楽しめるというのは割と大事なのである。

ところが、いつの間にかJavaの用途はデスクトップアプリケーションやサーバサイドアプリケーションになり、ブラウザで動くプログラムもJavascriptやFlashに移り、講義はだんだんとやりにくくなっていった。Javaは、ひとまず動くだけのプログラムを作るにも知らなければならない知識が多く、しかもそれが直列的にならない。Hello, Worldプログラムを作るだけでも、「public や static はとりあえずオマジナイだと思っておいて」と説明せざるを得ない。また、一通り文法を教えて、具体的な題材を通して講義を進めようとしても、クラスの使い方が話の中心になってしまう。講義でメソッドの説明を順次聞いても、ひたすら退屈だろう。

大学の講義というのは、概して、興味をそれほど持っているわけではない学生に対して、いかに興味を持たせるか、というところから始まる。その点において、Javaは面白い話がしにくい。竹内郁雄先生が「Javaには遊び心がない」と言っておられるが、その気持ちはとてもよく分かる。

教える側が面白くないのに、教わる側が面白いわけがない。それなら、教える側が面白いと思える言語に変えよう…という結果、Rubyを選んだわけである。もともとスクリプト言語は大好きな上に、最近関数型言語に自分の関心が向いていることが加わって、こういう選択になった。実社会でも注目を集めているのもいい。なお、関数型言語そのものは、ずっと前から2年生対象に Standard ML を教えている。

せっかくスクリプト言語を対象にするわけだから、具体的な事例もそれにふさわしいものにしたい。というわけで、Webアプリケーションを事例にして、うちの学科が以前より手薄だったアプリケーション層のプロトコル（HTTP）やデータベースの利用まで話してしまおう、という目論見を立てている。とはいえ、計画通りに講義が進むとはとても思えないが。

ともあれ、半年間にわたる自転車操業の開始である。さてさてどうなることやら。