RE;COIL (リコイル)メンバーのarc@dmzによる日記
記事「このブログについて」参照。RSS配信中。
今期アニメもそろそろ観るものが決まってきたので、神霊狩/GHOST HOUND用エントリの内容を今期アニメ全般についてに変更。
いやぁ、一年前まではアニヲタじゃなかったはずなんだけどなあ。一般人だった頃が懐かしい。ま、悪いことじゃない。下手なドラマよりよほど面白いもの。
最後まで観てしまうだろうなぁ、というのは以下四つ。
あとは…
他は一回も観てない。
総評としては、なんか、男のアニヲタ向けが多くない？という。男性向けゲーム原作が多いし。バイト先の声優の卵の人（女性）も、ネウロとガンダム00くらいしか観るもんがないと仰っていたような。
WOWOWでひっそりと放映されている、アニメ制作会社Production I.Gの20周年記念作品。I.Gには、去年とある企画でお世話になって以来、すごく親近感が沸いていて困る。
まあそうでなくとも、オープニングに小島麻由美のポルターガイスト、原作に「攻殻機動隊」の士郎正宗、監督と脚本に「serial experiments lain」の中村隆太郎と小中千昭となれば、それぞれのファンとしては観ないわけにはいかない。
原作から監督、脚本、音楽まで全部ファンな組み合わせでできたアニメ作品は、さよなら絶望先生とこれくらいじゃなかろうか。
「スピリチュアル アニメーション」というふれこみが少し気にかかるけど、3話の時点では面白い。ちょっと小難しい感じ。
いわゆるエロゲーが原作なのだけど、原作のメーカーブランドminoriがなかなかいい仕事をしていて、うまく「いかにもエロゲ」な感じを出さずに済んでいるので、アニメ版もあまりその辺りを意識せずに観られる。
minoriのゲームはたいてい新海誠（秒速5センチメートルや雲の向こう、約束の場所の作者）がムービーを担当していて、efも例外ではなく、デモムービーがとても綺麗。その雰囲気はアニメ版でもうまく出せていると思う。あくまで雰囲気。
つまり、新海誠テイストのすごく綺麗な発色は、デモムービー以上に長く出されるとお腹いっぱいになりがちなんだけど、アニメ版ではその色がひどく前面に出たりはしておらず、適度な雰囲気に留まっている。
そして、アニメ制作元SHAFTの監督・大沼 心×監修・新房 昭之の特徴的な色使い・線画を重視する作画が画面を引き締めている。とくに、オープニングがとても格好いいと思う。エンディングの種類・配色も話によって変わって、よく考えられているなあと感心してしまった。
プロデューサーに前期アニメ最凶の主人公伊藤誠の名前があるのは、もちろん偶然だろうが、今期、かのSchool Daysの後釜と言うには一番相応しい作品な気がする。
School Daysのように猟奇的な描写があるわけではないが、同作品と同様に、エロゲーって何よ？という若干哲学的な問いに答えてくれている作品だと思う。
まず、主人公がこれでもかというくらいフラグを連立させまくる。その立て方が何ともうまい。ああ、エロゲー（あるいは恋愛シュミレーション）ってこういう偶然をうまく組み合わせてるよね…という偶然的必然が、考えられる限り詰め込まれている。
そして、フラグクラッシャーと呼ばれる女の子がときどき他の子の好感度を下げるようなことをする。
それでも折れたフラグを主人公がうまく回収する。
ニコニコ動画にあがっていた動画を観たら（この行為、そのうち違法になるんだよね。）、フラグが立ったり折れたりする要所で字幕職人が選択肢の表示（1.〜 2.… 3.... 等）を作っていて笑った。
制作側もたぶんこの「エロゲーらしさ」を前面に出すことを確信犯でやっていて、次回予告の最後で声優に「データロードですぅ」とか言わせたりしている。あっぱれである。
癒されている。個人的には前期のぽてまよの位置づけ。一週間に一度くらいはこういうほのぼのした時間が欲しいよねぇ。
というわけで、創作活動の参考にしているわけではなくて、単に好きで見ているので、書きたい感想もとくにない。
まったり。
以上、今期アニメの感想。前期アニメの感想もあるよ。
書き途中だけど、まぁ、いいや。プログラマたるもの、思想は実装で示すべきだろう。
Webサイトにアクセスするとき、人は必ずそのサイトのアドレス──正確に言えばURIを指定する。例えばこのブログのURIは http://digitalmuseum.jp/text/replus/ だ。「お気に入り」とか「ブックマーク」はURIをいちいち入力する手間を省くための仕組みで、登録された項目をクリックしてWebサイトを表示するときには、必ずURIが呼び出されている。
URIは、もともと、インターネット上に存在する何らかの情報の場所を指定するURL（Uniform Resource Locator）の概念を拡張したものだ。詳しくはWikipediaのURI、URLのページを見てもらえばだいたい分かる。自分でも説明を読むまで知らなかったが、今ではURLという言い方は古く、仕様上、公式にはURIに取って変わられているらしい。本稿ではいちおう表記をURIに統一するが、URLに読み替えても同じ話（httpスキームに絞った話）しか書いていない。
Webサイトを作った人なら分かることだが、Webサイト上のURIが指し示すものは、普通、ファイルである。
例えば9/23付で公開した記事の中でリンクしたレポートのURI http://digitalmuseum.jp/text/replus/images/070831-nico.pdf は、そのままインターネット上のPDFファイルを指し示している。
また、このブログのURI http://digitalmuseum.jp/text/replus/ は一見、末尾にファイル名が付いていなくて何を指しているか分からないが、実は / で終わるURIはサーバ側（digitalmuseum.jp側）で index.html あるいは index.php を補完するように設定されている。このブログの場合は先のURIで http://digitalmuseum.jp/text/replus/index.php というファイルを指しているとするのが正解である。その証拠に、どちらのURIでアクセスしても同じ内容が見えるはずだ。
具体例はいくらでも挙げられる。例えば mixi は分かりやすくて、個々人のトップページを表示するプログラムのファイル名は home.pl 、メッセージの一覧を表示するプログラムなら list_message.pl などのようになっている。
昔は、URIがファイルを指すことがほとんどだった（と思う）。しかし、近年ではそれ以外の場合もある。というか、ファイル以外を指すほうが多くなってきている実感すらある。
そもそもURIとは「何らかの情報のまとまり(Resource)のありかを特定する標準的な形式(Uniform Identifier)」だ。
ファイルという言葉は一般に「綴じるもの/クリアファイルの類」と説明される。コンピュータの世界では、有意味な一連の情報を綴じたものがファイルである。
だから、ファイル名はURIの一種になりうるが、URIが必ずしもファイルを指すわけではない。
では、「何らかの情報のまとまり(Resource)」には具体的にどんな種類があるのだろうか。
手始めにブログのURIについて考えてみる。
公に公開されたブログでは、だいたいどんなものでも記事ごとに「パーマリンク」とか「固定リンク」、「Permalink」というリンクが表示されており、クリックするとその記事だけを表示するページが出てくるはずだ。固定リンクという言い回しは知らない間に日本語圏で市民権を得ているようで、このブログでも使っている。
では、この固定リンクとは一体何を「固定」するものなのだろうか？ permanent の訳は、英辞郎によれば
【形-3】 常設｛じょうせつ｝の、常雇用の、常置｛じょうち｝の、常在｛じょうざい｝する
である。要するに固定リンクとは、「このURIにアクセスすれば常にその記事が読めるよ」ということを保証してくれるURIへのリンクなのだ。
これは、ブログにおいてとても大事な仕組みだ。もし固定リンクがなかったら、「あ、あの記事どこ行ったかな」と思ったときにブログのトップページから時系列で追うか、タグ（記事ごとにキーワードを指定する仕組み）があればそこから辿るか…何通りかの方法があるにせよ、とにかく一発で記事の情報にたどり着くことはできない。「固定」という言葉を使って説明するなら、記事の情報一つ一つを、あるURIに固定するための仕組みが、固定リンクである。
調べてみたら、似たようなことを詳しくははてなの伊藤さんが二年以上前に書いておられる。
固定リンクのところであらかた説明してしまったが、ブログには他にも「月別の記事群」「特定のカテゴリに属す記事群」などを表すURIがある。
ブログでは、一つの記事情報に対し、その記事を表示するためのURIは複数存在する。例えばこの記事には、固定リンクでもアクセスできるし、2007年9月25日の記事としてもアクセスできる。タグ「Chippie」を含む記事を辿っても読める。
各URIにファイルを対応させると、一つの記事を修正したときにたくさんのファイルの修正を迫られる。
この処理は重い（時間がかかる）ので、個人向けの多くのブログでは、記事情報をデータベースに入れておき、URIが呼ばれたら、その都度データベースへURIに応じた記事を要求し、返ってきた結果を整形して動的にページを生成する、というやり方を採っている。
ただ、いちいちデータベースへ記事を要求する処理も軽いわけではない。そこで、「ページの閲覧者数が多い（＝データベースへ記事を要求する回数が多くなってしまう）」「記事の修正・追加・削除などの頻度が低い（＝各URIをファイルにしたとき書き換えを迫られる頻度が低い）」ならば、全てのURIに対応するファイルを書き換える方策のほうが軽い場合もある。著名なブログのシステム、Movable Typeはそのようにしている。どちらのほうが絶対的にいいというわけではないので、条件に応じて適した方法を採るべきである。
（以降、書き途中）
Movable Typeの機械的な文字列で構成されたファイル名は何とかならんのか。
Ruby on Rails で、URIがクラス、メソッド、引数を表す規約があるらしい。何という横暴。
URIは、情報のまとまりをなるべく忠実に表す文字列であるべきだ。なぜなら、プログラムの内部構造と違って、URIは、情報の受け手が直接に触れる部分＝ユーザインターフェースの一部なのだから。
e.t.c.
ちょっとずつ書き足していこうっと…。
最新の記事を全23件中13件目から計2件表示
© arc@dmz 2007