手帳をmoleskineに戻す

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

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

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

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

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

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

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

Rubyの講義を始めた

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

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

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

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

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

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

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

「雑感」の補足

HTML5の講演資料の「雑感」のところに「現段階の仕様から是非を議論するのは早計」と書いたところ、nanto_viさんから「これは HTML5 とどう関わっていくかによって異なります。是非を議論してその結果を HTML5 に反映させようというのなら、今すぐに動き出さないといけません」というコメントをいただいた。

おっしゃることはその通りだと思う。ここについては、補足の説明をしておきたい。

講演の場となった情報処理学会デジタルドキュメント研究会では、普段からXMLやSGMLに関する研究発表がよく行われる。また、今回は、事前に「マークアップ言語の特集としたい」という情報をいただいていて、聴衆も、普段よりもXMLやSGMLに明るい方が多いだろうということであった。一方、基本的には研究者の集まりであるから、Web制作の現場には明るくない人も多い。私自身の背景知識も、こういう聴衆とほぼ同じである。

講演にあたり、「国島先生のスタンスを表明していただいたほうが、後の質疑が盛り上がると思います」という要望をいただいていたので、最後に1枚、主観的なスライドを付け加えた。それが「雑感」の1枚である。

ここに何を書くべきか。思案した末、講演の準備で私自身が感じた、HTML5に対するある種の気持ち悪さと、その後の思索を軸にしようと考えた。すなわち、マークアップ言語界隈に携わる研究者としては、現在のHTML5のWorking Draftは一見気持ちが悪い。しかし、その原因をよく考え、いろいろな資料や現時点で得られた情報にあたっていくと、その気持ち悪さの多くは解決可能であったり同居可能であったりする。「議論の余地」というのは「非みたいに見えるけど、必ずしもそうとは言えない」という意味である。実際、講演を聞いた知り合いのXML研究者の何人かからは、私が感じたのと同じ気持ち悪さの箇所を質問として受けたので、デジタルドキュメント研究会という場では、それなりに適切なスライドであったと思っている。

私の感じた「気持ち悪さ」の原因は、具体的には何か。これが明らかにならなければ、単なる感想でしかない。いろいろ考えてみると、次のような点に集約できるように思われた。

1. マークアップ言語としてのHTML syntaxの汚さ
2. HTML5のWorking Draftの内容全体を "Markup Language" と言うことへの違和感。あるいは HTML5 という言葉の二重の意味（HTML syntaxと Working Draft の内容全体）
3. XHTML syntaxでの文書スキーマの取り扱い。あるいはXHTML 1.1との関連をあえて排除しようとしているように見えること

1. はさほど大きな問題ではない。HTML syntaxは現実のWebページの姿を追認したものであるわけだから、私がどう感じようが、現に存在するものは否定できない。それに、きれいにしたいならXHTML5を使えばよいだけのことである。

Working Draftの中にHTML syntaxをHTML5、XHTML syntaxをXHTML5と呼ぶ、という記述があり、この呼び方には全く違和感がない。だから、詰まるところ、2. の気持ち悪さは Working Draft のタイトルに起因するものだろうと思う。これが "HTML5 and its friends" とかだったら、なにも違和感を感じないだろう（friendsが適当な言葉か、はともかくとして）。その辺りは承知の上で、あえて「HTML5」というタイトルを付けているのだろうと想像している。

3. はなかなか説明が難しい。ここで言う「文書スキーマ」とは、Relax NGで書かれたスキーマ定義文書のことを指す。DTDは時代遅れのシロモノなので、訣別するのは大賛成である。また、XML SchemaはXHTML5のparsing処理とPSVIが干渉するかがよく分からない（そもそもXML Schemaはいらないと思っているので、調査する気がしない）。Relax NGなら、妥当性検証してもXML Infosetは変わらないので、HTML5の処理モデルに影響は及ぼさないはずである。

HTML5のWorking Draftには、各要素の内容モデルが明確に定義されている。また、HTML5の文書のparsing処理には文書スキーマは必要ない。だから、あえて文書の妥当性検証をしたい、とか、XHTML 1.1のようなスキーマモジュールを活用したい、とかいった用途でしか、文書スキーマは必要ないだろう。パレートの法則で言えば、現時点では明らかに20%のほうである。講演資料に「需要次第?」と書いたのは、この辺りの気持ちを反映している。

それでも文書スキーマに拘るのは、部品として手軽に利用できる文書ボキャブラリがHTML/XHTMLしか見当たらない、という理由による。ODFやOOXMLは巨大すぎて人手では到底扱えない。DocBookは一枚岩スキーマで、独自に拡張したり、ボキャブラリの一部を取り出して使うことがしにくい。TEIはモジュール化されたスキーマを持っているが、いまだにDTDである。（確か）yohei-y君からは「Wikiフォーマットとかどうですか？」と言われたけど、拡張する度に記法を定めパーサを作るのはめんどくさい（汎用のWikiパーサジェネレータとかあるのだろうか?）。

スキーマがなくても、XHTMLボキャブラリを利用することはできる。でも、部品として使えるボキャブラリを自分で定義するのは結構めんどくさいので、最初から部品が用意されていると楽ができて嬉しい。だから、XHTML 1.0のような一枚岩スキーマではなく、XHTML 1.1のようなスキーマモジュールがあると嬉しい。HTML5での要素カテゴリは一枚岩スキーマよりはいいけど、ちょっと個々のカテゴリが大きすぎるかなあ、という感じがする。とても感覚的なものなのだけど。

ニーズとしてニッチなのはよく分かっているし、公式な文書スキーマである必要もないので、syntax.whattf.org のような有志の活動の結果を利用させてもらうのでも充分なのかな、と思っている。

HTML5の講演資料の修正版を公開

先日公開したHTML5の講演資料について、nanto_viさんから「HTML 構文でも空要素の開始タグを /> で終了させられます」という指摘をいただいた。まったくご指摘の通りで、HTML5 Working Draftの9章「The HTML syntax」の9.1.2.1節「Start tags」に、まさに指摘をいただいた通りの内容が書かれている。

完全に私の読み落としである。お詫びして訂正させていただきたい。これに伴い、SlideShareで公開している講演資料も、問題の記述（21ページ「HTML syntaxの例」）の部分を修正した版に差し替えた。すでに2,900 views近くになっている状態では手遅れかもしれないが、お近くの方にも間違いを連絡していただければ幸いである。

Markup Languageと名付けられている仕様書で、開始タグの定義がXMLから変更されているとはまったく予想外だった…

ご指摘いただいたnanto_viさんには改めて感謝申し上げたい。なお、nanto_viさんからのもう一つの指摘「是非を議論してその結果を HTML5 に反映させようというのなら、今すぐに動き出さないといけません」については、稿を改めて書くつもりでいる。