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

普段使っている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のドライブには強制排出のための穴はない（これが大はまりした原因でもある…）。

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

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

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

jQuery.popeye 2.0.4 のバグ

昨日の記事でも触れた、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を書いていたので、はまりました^^;

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

今年に入ってから、日本データベース学会（以下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を利用している。

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

1. ffmpeg2theoraの最新版(0.27)では、2パスエンコーディングができるみたいなので、採用した。
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でブログの文章を書いてみた

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

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

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

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

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

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

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

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

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

• ezmlm-idx + postfix quick and dirty howto
• Mixing EZMLM with Postfix

アイデアはどちらも同じで、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アカウントが無効になった

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

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

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

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

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

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

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

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 で我慢しとき。

本: 一澤信三郎帆布物語

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

posted with amazlet at 10.05.20

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

Amazon.co.jp で詳細を見る

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

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

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

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

IKEA初体験

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

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

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

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

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

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

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

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

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

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君だからこそ書けた本だと思います。