今日もマジモード
闇黒日記3月31日ぶんより知ったビジネス☆ナウのe-report「こんなWEB製作会社と仕事をしたい(後編)」より、設問「こんな会社とは仕事がしたくない！／こんな苦い経験をした！ ということがあれば、ぜひ教えてください。」より。
HTMLを委託したところ「Webだから後から修正が利く」などといってチェックを怠り、間違いだらけのものが納品された
仕様書くらい作って渡せよ……（￣△￣；。
製作担当者がコロコロ変わる。掛持ちで仕事を受けていて引き継ぎがされていないため、コンセプトを一から説明しなくてはならない。
仕様書くらい作らせろよ……（￣△￣；。
書面で指示しても、その通りの仕事を納品してくれない。
ほかの業界でこんな調子でやっていて干されたから、ウェブ業界にやって来た（￣△￣；に一票。というか、仕事が忙しくて勉強する時間や社員の研修をする余裕がまったくないのが諸悪の根源なんだろうなぁ。未成熟な業界だねぇ。
Life with MacOS Xの3月31日分に、MacOS Xのインストーラーの歴史と課題に触れたPowerPointスライドがおかれてる。これはためになる、というか面白い。
別にそんなことができる機械やソフトを買ったわけではない。ちと長くなるが、ウェブマスターのためになる(かもしれない)話のきっかけとして、ハードディスクレコーディングを取り上げよう。
10年以上前に雑誌で読んだ、とあるミュージシャンのインタビューに「ハードディスクレコーディングなら、時間軸を気にする必要ないのだから、とにかく材料をつっこんじゃえよ、ということをアドバイスされたことがある。だけど、最初、その意味が分からなかった」といった趣旨の発言があった。この発言者か、アドバイスした人のどちらかは、たしか坂本龍一だったと思う。
ハードディスクレコーダーは、取り込んだ音声ファイルを時間軸上にマッピングしていく方式で音楽を編集する機能を持っている。iMovieやプレミアといったパソコン用のビデオ編集ソフトと考え方は一緒だ。前後の順番はいかようにも入れ換えられるので、曲の頭から「せーのっ！」と録音していく必要がない。極端な話、曲のヤマ場を最初に録音しておいて、あとからイントロやテーマを練ってもいい。コラージュ音楽をやっている人には最適な方法だし、一曲の時間の長いプログレ、例えばYESなんかでも「BIGGENELATOR」ではそういう方法でレコーディングをこなしたという話をどこかで見た記憶がある＜モウロクしてるから確証はない。
で、本題は音楽の話ではない。CSSだ。
ウェブページを作るときにまず、ページのビジュアルを頭に思い浮かべたり、紙やフォトショップ上にラフレイアウトを起こしたりする人がこの話のターゲットだ。で、テキストエディターなりオーサリングソフトで製作にかかるわけだ。だが、このとき、レイアウト上の左上に配置される要素から順に、馬鹿正直に記述していったりしていないだろうか？
CSSには、HTMLの記述順を無視して、画面上の好きな場所に要素をレンダリングする方法が用意されている。だから、CSSの利用を前提にしていれば、本来は先に提示すべき重要な情報から順にHTMLに書いていける。そのように作られたページなら、カーナビやブラウザーフォンでネットサーフィンする時代が来ても、すざましい数のナビゲーションやバナーでイライラする前に、ページのメインの情報に閲覧者がたどり着けるわけだ。
どんな情報を早く伝えなければいけないかをよく考えている企業であれば、そのウェブページも、情報の優先度を考えた構成に近い形を採るようになる。例えばアップルの新iMacの紹介ページなんかがいいかな。
ここは、ページ最上部のナビゲーションを除けば、実にシンプルで分かりやすいページ構成をしている。まずは、新しいiMacの要とも言える、液晶/ネック/半円形のボディという構成がよく分かる概観写真――それは彼らにとっては何よりも強く伝えたいiMacの革新の象徴だ。次に来るのが、iMacの売りとなる装備。仕様や機能を詳しく紹介したページへのリンク。今度のiMacが何を目指したのかを分かりやすく紹介する導入文。詳細な解説。そしてOS Xの搭載やインターネットとの親和性など、今となってはそれほど重要ではない補足情報を経て、パン屑リスト、検索画面、コピーライト、という構成になっているのが分かる。
残念ながら彼らはCSSを使っていない。そしてテーブルレイアウトを使っている。けど、情報をどのように見せるかはよく知恵を絞っている。
もしも、こういった作りをしたうえで、かつ見せ方としてのメリハリが必要だということでレイアウトをいじる必要があるのであれば、そこでCSSが役に立つ。
再優先にしたい情報をきちんと提示した上で、見せ方としてのメリハリも両立するために必要なのは、こういうことだ。最初のハードディスクレコーディングの話にしてもウェブにしてもそうなのだが、まず必要な要素を揃える。レコーディングであればコンプレッサーやイコライザー、場合によっては歪みものを駆使して素材情報としての音を魅力的になるように作り込んでいくはず。そして、時間軸の編集作業とミックスダウンによって最終的な見せ方を決定する。ウェブも然り、情報の素材としてのHTMLを魅力的になるように作り込んだ上で、CSSで見せ方を決めていくのだ。
こういう「ノンリニア」な発想はコンピューターならではだから、馴染みにくいかもしれないけど、身に付けておいても損はないはず。とくにコンピューターを「表現の道具」と言い切る人であれば、なおさらかな。
関連情報：ふりかけ味スタイルシート(byありみかさとみさん)
ノートンユーティリティーズのCD-ROMからマックを起動する機会があった。珍しくOS Xからログアウトすらできない事態に見舞われたのだ。不具合を修正したついでに断片化も解消しようとスピードディスクをかけることにした。3ヵ月くらい放っておいたせいか、極度にデータが断片化している。
OS Xボリュームに対して断片化の解消をすることは、実に効果があるようだ。XDarwin導入後、始めてスピードディスクをかけたんだけど、GNOMEやGIMPの起動が目に見えて速くなった。細かなデータの多いBSD部分やバンドル形式で作られているソフトにとって断片化は大敵なのかもなぁ。
ドコモの携帯電話でこのサイトにアクセスしている人がいるようだ。で、以前にアクセス記録の内容を紹介したときに、何気なく携帯電話でも見れるマークアップしているから、といった趣旨のことを書いてしまったのだ。だが、待て。おいおい、iモードって、EUCに対応していないじゃないかー！ きっと文字化けの嵐に違いない。
こういった時に役に立つのが、PC用のウェブコンテンツを携帯電話用に変換してくれるゲートウェイサービスだ。文字コードも携帯電話に合わせてくれる。有名なのは「通勤ブラウザ」か？ 使うぶんには結構有用なサイトだが、いったいどんなHTMLをiモードに送っているのか気になったので試してみたが、その結果にギャフン！
HTMLがあまりにもひどいのだ。これは何がまずいのかを検討する必要がありそうだ。一応、携帯電話でパソコンのコンテンツを見ることを目的としているサービスなので、いかにデータ転送量を減らせるかを主眼にプログラムを組んでいると考えられる。その辺を気にしながら評価をしていこう。
<html><!-- AllowtelmethodAccess -->
<base href="http://www.sjk.co.jp/c/"><body>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<title>あのー（￣△￣；〜ﾍﾀﾚ日記・3月</title>
<h1>ﾍﾀﾚ日記</h1>
<br>
<h2>今月のコンテンツ</h2>
<br><a href="http://www.sjk.co.jp/c/w.exe?y=anoh.s10.xrea.com/02-03.html%23latest">最新の日記</a>
<br><a href="http://www.sjk.co.jp/c/w.exe?y=anoh.s10.xrea.com/02-03.html%23d2002-03-16c1">はるちゅうぅぅぅぅぅぅー！</a></li>
これはおいらのコンテンツの3月ぶんの書き出しの部分のHTML。世の中にはHTMLにDOCTYPE宣言を記述するサイトがある、という事実をどうやら否定している模様。どうせ否定するならDOCTYPE宣言は削除しておくれ。そちらのほうがパケットの減量にはまだ役に立つ。それからリスト要素のあとに毎回強制改行は辛いな。iモードはリストをちゃんとブロック要素としてレンダリングしてくれるのに。これもデータ転送量を考えるとないほうがまし。
<br>
<h2>2002年3月16日</h2>
<h3 id="d2002-03-16c1">はるちゅうぅぅぅぅぅぅー！</h3>
<br>つーわけで、人様のBBSに出現してばかりいるのもなんだなと感じてまいりました。突発的ですが、そろそろ自ら怪電波の発信をば。あまり気合いが入っていないので、色使いといい、構成といい、そこらかしこに手抜きの跡をみてとれるのではないかと……。<del datetime="2002-03-23T03:20:00+09:00">タイトルロゴ作ってないし！</del><ins datetime="2002-03-23T03:20:00+09:00">作ったぜ、ｺﾞﾙｧ</ins>
<h2>2002年3月17日</h2>
<h3 id="d2002-03-17c1">本日のいいとも増刊号</h3>
<br><a href="http://www.sjk.co.jp/c/w.exe?y=www.amuse.co.jp/artist/risa_sudou/profile.html">須藤理彩</a>っていいなぁー。……なにがって？ うーん、難しいなぁ。
これが、その後の本文部分。さっきのリスト要素のお尻に強制改行が付いていた理由が分かった。つまり、ブロック要素の最後に逐一強制改行を振っているわけだ。
マークアップとしての妥当性はさっぱりなのは、携帯向けにコンテンツを軽量化する、また狭い画面での見栄えを整えるという要求を満たすために苦心した結果だろうと考えるとしよう。だけど、どちらの要望も満たすために、あえて妥当なマークアップを避けただけの効果を出せていないのが問題。本末転倒な結果になっているのだ。
例えば、軽量化。iモードの仕様では終了タグの省略が可能なのだから、普通に段落要素「p」の開始タグを段落頭に振れば良いものを、わざわざ文字数の多い「br」を使ったのは何故なのだろうか。iモードに許された1〜2キロバイトの容量の中で、brが出現する箇所は50以上。それが全てpに置き換われば、3〜4パーセントの容量(50バイトだから、1文くらい？)を節約できるのだ。
次に、見栄えの問題。段落間が空くのをこのゲートウェイの設計者は嫌ったと見える。だが、利用者がどんなサイトを見るのにこのサービスを利用するのかを考えてみよう。
パソコンのサイトを携帯電話で見る以上、フラッシュや画像がバリバリのページを見に行くわけがない。第一、このゲートウェイはimgタグはalt属性ごと削除してしまうので、ロゴや見出し、文章の一部を画像化している場合は、そのまま情報が失われる仕様になっている。そうなると大半は、ニュースなどの速報性の高い文字コンテンツへのアクセスだ。brで段落間が全く空かないテキストが延々と続くのを読むは、かなりきついはず。となれば、段落要素としてマークアップして、行間が空くレンダリングを期待するほうがいいのではないだろうか。
このサービスは利用者の用途の想定や必要な仕様の詰めが甘いように思う。「パソコンのコンテンツを携帯電話で見る」という行為に対して、最適な仕様は何かというのを、ドコモやW3Cの仕様書を見ながらよく比較検討すべきだったはず。「とりあえず終了タグを省けば軽量化」といったレベルの検討では、期待した効果を出せないどころか、逆効果になる場合だってある。マークアップのいい加減さ、インライン画像要素の情報としての価値の喪失、といった事実と合わせると及第点ギリギリの評価しかできない。
無償のサービスだからあまり強くは言えない。けど、これが何かしらのビジネスモデルに絡んでいるなら、コンセプトを実現するために必要な技術の検討はもっと思慮深いレベルで行うべき。もしもビジネスモデルとしてHTMLを利用しようとしているプログラマーの人には、よく考えて欲しいことなのだ。
昨日のマック用オンラインウェア新着サイト「新し物好きのダウンロ〜ド」を見に行った2ちゃんねらーの諸君は、(ﾟдﾟ)ｳﾏｰなものが紹介されていることに気が付いただろう。2チャンネルのログを検索するシャーロック用プラグイン「2検用」がそれだ。
いくつかの板群がひとつのプラグインにまとめられているのだが、これら串刺しで検索できるので、気になるトピックを扱っているスレッドを探すのにはとても便利。自分の名前やハンドルネーム、「〜たん」などで検索すれば、自分が晒し上げられていないかどうかも調べられる。「向かうところ敵だらけ」という人にはお勧めだ。
マニュアルでは一切触れられていなかったけど、シャーロックと同じ技術を採用しているモジラの検索画面からも利用できる。そうそう、OS Xのモジラは、シャーロック用のプラグインが入っている~/Library/Internet Serch Sites/以下を自動的に見に行くので、インストールはシャーロックに対してだけでいいのもポイントだ。ただしモジラ上ではプラグインの名前が激しく文字化けしているのが残念。
さっそく、おいらのハンドルで検索したけど、こんなハンドルらしくないハンドルを使っていては、ハズレしか出て来ない。ならば、某方面の最重要人物のひとりである野嵜さんの名前で検索してみよう。出るわ出るわ、と大喜びすること請け合いだ（￣△￣；。
ちなみにPiroさんで検索するとモジラ関係のスレッドが多くヒット。どこで話題になっているかの傾向が分かってなかなか面白かったり。2ちゃんねると、どうしてもつき合っていかざるを得ない人は、お試しあれ。
モジラ 0.9.9のリリースから約3週間。もじら組の日本語パックページを覗くと、0.9.9用の日本語化モジュールが置いてあるではないか。だが、もじら組のトップページには、そんな情報書かれていないし。なんなんだか。
一応入れてみたものの、OS X環境下では「View」メニューの「Languages and WebContent」からサブメニューが現れず。うむむ、アップデートを失敗したか。おいらの使い方が間違っているだけだった、もともとLanguages and WebContentにサブメニューなんかないのだと(恥。
Mac OS XがUNIXベースというのはｱﾎﾟｰの宣伝文句にもあるんだけど、ターミナルやX-Windowを起動しない限り、それを意識する機会はまずない。ターミナルにしたって、ハードディスクの奥深くに置かれているので、普通は見つけ出していじるということは少ない。おそらく一般のユーザーには極力触らせない方針なのだろう。
そもそも、おいらがこういった環境をいじっているのは、初期のMac OS X用ソフトのインストーラーがフォルダーのパーミッションを書き換えてしまうという事例が多発したのがきっかけ。ターミナルでごちゃごちゃいじっているうちに、面白くなってしまったのだ。ターミナルやX-Windowの環境を立ち上げるとたちまち生のUNIXが顔を出してくる。いろんな事例から、「これはこうだろう」と勘が働くようになって来ているが、所詮焼き付け刃ではどうしてそうなるのかが全然理解できないのだ。
ここまで来たら、どうしてもきちっと説明してくれる解説書が必要になって来る。んで、昨日買って来たのが翔泳社の「独習UNIX」(ISBN4-88135-798-0)という本。「UNIXではあらゆるものをファイルとして扱う」という概念をベースにものを考えろということが、この本のあちこちに書かれている。なるほど、emacsに「新規書類作成」の項目がないのも、シェル上からいきなりファイルに文字を書き込めたりするのも、mvコマンドでファイル名の書き換えと保存場所の変更ができるのも、全ては「なにもかもがファイルとして扱われている」という一貫性のなせる業というわけか。この手の抽象的な概念は、使っているうちに疑問に思った点をうまく把握しようとする段階になって、ようやく役に立つように感じる。ある程度の具象を経験していないと、抽象という高度な概念は理解できないというわけだ。
UNIXの話をするときによく話題にのぼることなのだが、PC-UNIXの難しいところは初心者でもrootを担当しなければならない点。はなっから抽象化された概念を相手にしなければならないのは辛いはず。その点Mac OS Xはrootをとくに意識しなくてもいいシステムだから、純粋にユーザーレベルから学び始められる。研究室に入って来たばかりの新入生が、とりあえずログインとメールの読み書きさえ覚えれば済むのと一緒だ。この時点から少しずつ「具象」という経験値を上げていけばいいのは、凄く助かっている。
HTMLに詳しい某方面の情報を総合したところによれば、divはdivision、つまりグループ化されたものを示す要素だという。会社組織の「〜事業部」も英語では「〜division」と表記するので、ある目的を持った要素（会社でいえば人）が集まって形成されたグループを指すものだと考えればいい。
それにしても、divはデフォルトで視覚効果を伴って表現されることが稀なだけに、理解には少々時間がかかる。おいらの場合、divを理解するまでに次のようなステップがあったのだ。
HTML入門本でdivの説明を目にするが、用途がさっぱりわからない
↓
試しにHTMLに記述してみるが効果がさっぱりわからない
↓
ねーねー、divって何？<HTMLに詳しい人
↓
知るかぁﾎﾞｹｪ、そんな変なタグは使うな、この厨房がぁ
↓
ヽ(`Д´)ﾉもう来ねえよ！ｳﾜｧｧﾝ
↓
ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!!! CyberStudio3でレイヤーを使ったレイアウトをするとdivがたくさん記述されるのをﾊｹｰﾝ!
↓
div要素がp要素をたくさん囲んで1つのテキストボックスを形成しているではないか！
↓
でもレイヤーを使わないと意味ないじゃん！(´･ω･`)ｼｮﾎﾞｰﾝ
↓
divで囲めばCSSのスタイルを一括適用できるじゃん、これはｲｲ!!(ﾟ∀ﾟ)
↓
(ﾟдﾟ)ｳﾏｰ
こうしておいらは、いっぱしのdiv使いとなった。だが、divを使いすぎると構造が複雑化し、ネストの管理が大変だ。XMLでは文法違反があるとパーザーの処理が中断するという噂を聞いたことがある。これが本当なら、将来的にはタグの閉じ忘れなどはが命的なエラーにつながることになる。
だが、それでも深い階層を用意して、細かくマークアップの内容を管理したい人もいるはず。そのためにモジラやゴーライブのDOM表示機能やEmacsの終了タグ補完機能、Jeditやmiなどのテキストエディターがサポートしている文法チェッカーとの連係機能、があるのだ。おいらは、XEmacsの終了タグ補完機能とAHL-Runnnerによる文法チェックを併用してマークアップの不備を防いでいる。手書き派でも、機械に頼れるところは頼ったほうがいい事例だってあるのだ。
「ビルゲイツは囲碁の腕前がかなり高い」という噂を以前から耳にしていたが、2つほどそれらしい情報がひっかかった。そのうち、XBoxかウインドウズ向けに「ビルゲイツのお墨付き！〜マイクロソフト囲碁」とかが登場するのだろうか。
セットアップしたばかりのウェブブラウザーは、まだ何もブックマークが登録されていない。たとえIEといえども、「さとみかん」と入力しただけでhttp://najo.cc.sakura.ne.jp/~alimika/satomican/というURLが、「inu」と入力しただけでhttp://inulink.net/というURLが表示されるわけではないのだ。
こういうのを見て「ああ、ウブなんだなぁ〜。(;´Д｀)ﾊｧﾊｧ」と訳のわからない妄想に浸ってしまうおいらは逝ってよしですか？
PiroさんのLatest topics 4月9日ぶんより。鬱に関する話題。
こんなもので鬱を名乗ったら、本当に鬱病の人に失礼なのかもしれないとさえ思う。
失礼かどうかは鬱な人ではないからわからないけど、Piroさんのサイトで鬱な発言を見るたびに「(鬱で入院中の)おかんの見舞いにでも行ってこようかなー」という気持ちにさせられるのは事実。
かつておいらは、divの定義として「汎用コンテナ」という言葉が当てられているのをどこかで見かけたことがある。それが正確な解釈なのか、正式なものなのか、はたまた私的な解釈なのかどうかはさっぱり覚えていない。
だが、おいらのdivの使い方が、まさに「汎用コンテナ」的な「まとめられるものは、とりあえずまとめておけ」だったのは確かだ。なぜなら、おいらは何らかのグループ分けがまったくされていない裸のp要素の存在が不安だったからだ。それはどんな食べ物にもマヨネーズをかけないと不安になる症状と、大差ない。諸悪の根元は、いくつものトピックをひとつのファイルに詰め込んでいるこの日記の仕様なのだが。
それはともかく、このdivの使い方に関して、野嵜さんの「闇黒日記」4月10日ぶんにこういう記述がある。
XHTML 2.0で檢討中と言はれる「section要素」の代用品として用ゐるのは、よろしくないやうな氣がします。divで代用可能であるならば、「section」なる新要素を定める意義は無いと云ふ事になります。「section要素」の採用が檢討されてゐると云ふ事が、div要素の存在意義に「怪しい」面のある良い(?)證據だと言へるのではないでせうか。
これを見て「よーし、それならパパ今日からXHTML 2.0でsection使いまくっちゃうぞー」と一瞬本気で思ったおいらは実にせっかちかもしれない。よく読むと「検討中と言はれる
」としっかり書いてある。検討中かどうかでさえ、確証がないということだ。おいら的には、用途に合えばHTMLのバージョンを乗り換えるのはやぶさかではないのだ。乗り換え先の規格が普遍性の高いものであればさらにいい。ただしおいらは、XEmacsのHTMLモードの仕様を理解しない限り、いつまでたってもほかの規格を使えないというﾍﾀﾚ度満点の問題を早く克服しなければならない。
さて、XHTML 2.0の情報はおいらにとっては初耳だ。ちょっとオタクなHTMLユーザーとしては、詳細を調べない手はない。W3Cに情報を探しに行ってみると石川雅康さん作成のプレゼン資料が引っかかった。これによるとXHTML 2.0は「可能な限りXMLの標準的な機能を使う
」のを設計目標にしている、とある。
おいらはW3Cの情報を追いかけていなかったため、この石川さんという人がどのような立場で、XHTMLに対してどのような役割を担っているのかについてはまるでわからない。だからW3Cが現在、この設計目標をベースにして「従来あった要素、属性を全て再検討し、必要に応じて再設計
」しているのかどうかについてや、どういう経緯で何を目的にしてsectionを用意しようとしているのかについても、まったく情報がない。
つまりおいらは、もう少しXHTML 2.0について調べてみるか、XHTML 2.0のドラフトが公開されるかいずれかの状況にならないと、div≒sectionという使い方に問題があるのかどうかについて結論を出せない。だが、もしもsectionという要素が、よく言われるセクションをマークアップするために用意されるのであれば便利そうなのは確かだ。
現時点でおいらがウェブ製作をしようとするときには、HTMLを含めたすでにPublicになっている規格の中から、自分の用途に合うものをチョイスしていくしかない。ただのユーザーである以上、そういう制約の上で利用せざるを得ないこともあるだろう。
深いレベルでHTMLやXMLを理解している人であれば、現在のHTMLの不満を解消するためにXMLベースの私的な規格を作ったり、独自タグを組み込むんだり、名前空間を利用して他の規格から必要なタグを取り込んだり、という手を採れるかもしれない。熟練のUNIXユーザーが適切なツールを自作したりカスタマイズするなどして利用できるのと同じような理屈だ。だが私的な規格の採用は、DTDを作成するなどして内容を管理しないと混乱の元になる。管理はおいらにとって荷が重すぎる。それに、拡張したタグの使い方が妥当かどうかをAnother HTML lintなどの一般的なツールは検証してくれない。
ありものを利用している以上、他の規格ならできることを、現在使っている、または現時点で利用可能なHTMLの規格内で代替せざるを得なくなることがあるかもしれない(もしくは、代用による表現そのものをあきらめることも選択肢にできる)。おいらにとって今のところ、前者の代替という手法がdiv要素を使った話題のグルーピングなのだ。
おいらは、OS Xに付属している「コンソール」というソフトに、ソフトがクラッシュしたときにその旨を報告するような設定をしてある。おいらのOS Xは非常に安定しているが、一日に2回ほどクラッシュ報告に名前が登場するこのソフトは、いったい何をしでかしているのだろうか。
Mac OS X用のX-Window対応ソフトをパッケージにして配布している「PINEAPPLE」が、オンラインインストールを採用した。インストールする際にはmphというコマンドをターミナルから実行するのだが、このコマンドから次の9つの機能を利用できる。
デビアン系のインストーラーを採用しているfinkでもこういった機能を利用できた気がするけど、CUIベースで複雑なインターフェースを組んであって、厨房丸出しのおいらは操作法をうまく理解できなかった。PINEAPPLEのmphはコマンドで直接作業を実行できるので、インストラーの操作であれこれ悩む必要がないのが楽なのだ。
Mac OS Xのソフトウェア・アップデートは、アップデート機能しかない。Mac OS Xが標準採用しているインストーラーも操作は楽なんだけど、インストールしかできない。ATOK14には標準インストーラー上で実行するアンインストーラーが付いているけど、これはどうやら実行するスクリプトをファイルの削除専用にしているような気がする。一本でどちらも実行できるように、内容を洗練してくれると便利なんだけどなぁ。
ありみかさとみさんのねこめしにっき4月14日ぶん「激しくアツい猛者」で紹介されていた「家庭内湾計画」を見た。すげー。
おいらの知人の話だけど、彼は無線アクセスポイントとルーターブリッジ機能を使って、2件先のマンションに済んでる知合いとWANを組んでいた。インターネット経由であやしい映像ファイルを交換すると時間がかかって仕方がないからなのだそうだ。2件先ならハードディスクを持っていったほうが早くないかい（￣△￣；。
アクセスの大半をさとみかんからのリンクに頼ってるあのー（￣△￣；です、こんにちわ。アクセスログを見ていて気が付いたのだが、新規公開されたアンテナ「Orange Noise Shortcut」に捕捉されたようだ。ここもさとみかん同様、いくつかのグループに分けてサイトを掲載しているが、ﾍﾀﾚ日記のカテゴリーはなんと「Comet-san Suki Suki Community」……（￣△￣；。
（￣△￣；……、一度も書いたことはなかったが、コメットさんは好きだ。なんで分かったのだろう。コメットさんではウルトラマンタロウこと東孝太郎とのラブロマンスの回が今でも印象深い<ドラマ版かよ、いつの話だよヽ(`Д´)ﾉ。
ありみかさとみさんのねこめしにっき4月15日ぶん「リンクアンカーつれづれ長文注意 」より、ナビゲーションに必要な機能をUA（ユーザーエージェント≒ウェブブラウザー）が用意するという話の中から。
ページ間移動用のナビリンクも、 <link> 要素の rel 属性値などを読んで、 UA が自前のインタフェイスを提供するようになるべきだとも思ってます。
おいらは、モジラにサイトナビゲーションバーが装備されたときに、「おおっ！」と歓喜したクチ。サイトナビゲーションバーを知らない人は神崎さんの「link要素がナビゲーションバーに使われている例」を参照してほしい。
だけど、おいらのサイトであまり活用されていない。ナビゲーションを用意するだけのページ数がないのもあるが、実はそれなりに理由がある。prevやnextにあたるページを記す分にはそれほど手間は気にならないのだが、「章」やら「節」やらの内容を、新たなコンテンツが加わったときに、サイト全体のナビゲーションをアップデートするため修正するのは面倒臭いと思ってるのだ。
だが、かなり大きな構成のサイトでありながら、ナビゲーションバーに情報を細かく提供しているところもある。Piroさんの「outside reflex」だ。ソースを見たところ、各ページにいちいち全てのリンク情報を用意しているわけではなく、サイト全体で共通利用する内容をJavaScriptを使って読み込ませているようだ。いったいどういう風に記述するとそういうことができるのか気になるが、おいらはスクリプトの類に関しては全く不勉強なので、例えパクろうと思ったところでソースの内容をまるで理解できない。
モジラにサイトナビゲーションバーが装備されて久しいが、この機能をきちんと活用しているサイトに出会うのは某方面とマック系の一部のサイトくらい。知名度がないのも理由のひとつにあるけど、やっぱおいらと同じように管理の面倒臭さが気になってチョビチョビとしか使えないという人も多いのではないだろうか。第一、mozilla.orgやもじら組のトップページでさえこの機能を活用していないのだから、デフォルトでオフになっているこの機能の存在価値を理解できる人がどれくらいいるのかは疑問だ。
普及のきっかけがあるとすれば、多くの人の目に付くところで実用的な価値を示せたときだろう。例えば、ネットスケープを自社サービスの標準ブラウザーとして採用する可能性を示しているAOLなんかが鍵を握っているかもしれない。ここが、自社のサイトや提携しているオンラインショップなどをこの機能に対応させたりすれば、少なくとも米国内での潮流が変わる可能性がある。
潮流が変われば、マイクロソフトもこの機能を採用する可能性が出て来る。そして、商用サイトの制作でこの機能の重要性を訴えるディレクターが増えれば、ウェブソフィアやドマクロメディア・ウルトラデベロッパースタジオなどのサイト開発ツールで、サイトの設計図やサイト管理画面からナビゲーションを自動生成する機能が装備されるかもしれない。それを羨ましく思う一般のウェブ系開発者が、似たようなツールを作成して一般配布を始めるかもしれない。その頃にはおいらも重い腰を上げて、ナビゲーションバーに詳細な情報を提供するようになっているかもしれない。
でも、これは今の時点では全然夢物語なのだ。
昨日の話のオマケ。Piroさんは16日ぶんのLatest Topicsで、「僕の場合、タブブラウズ時にバーとタブの内容とがかみ合わないことが多々あるため、サイトナビゲーションバーの利用頻度自体極めて低い
」と述べている。
ならばタブの内容とバーの内容に矛盾がなければ、使うかもしれない可能性もあるかもしれないと勝手に決めつけて妄想したインターフェース案を公開してみるテスト。
↑これでどうだ。
友葉式の4月18日分「半角カナ」や何かの日記4月18日分「続・半角カナ」で話題の半角カナ。先日、スラッシュドット日本語版でも「1byteカナ文字の流行はいかがなものか？」として取り上げられていたのだが、なにかきっかけがあったのだろうか？
マックの標準日本語プログラム「ことえり」は、標準状態では半角カナでの入力ができない。気が付いたときにはそういう仕様になっていたので、2ちゃんねるに行って、「ｺﾞﾙｧ」とか「ﾊｧ?」とかいう言葉を使い始めるまでは全く縁がなかった。「いまさら半角カナは必要ない」という意見には一応同意しておくけど、これほど厨房テイストを楽に表現できる表記はなかなかないわけで………ｱｲﾁｬｸｶﾞﾜｲﾃﾙ（￣△￣；
4月17日分「固有名詞」にて、まだまだ言及中のありみかさんの「ねこめし"日記"でわなくてですね
」。
「漏れのところは中国語サイトだ！」と言い張れば、いくら漢字で書いてしまってもOKなんですね、と言い切ってしまうと、中国語使いの方たちに叱られますでしょうか？
で、試しに中国語で書いてみたものを載せようと思ったのだが、日本語HTMLに中国語を混ぜて記述する方法がわからん、ふ、不覚だ（￣△￣；。オマケにろくに勉強をしていないので、綴りを間違えているかもしれぬ、ｳﾂﾀﾞｼﾉｳ。
「DTDに即したマークアップができる」という触れ込みに触発されてpsgmlを使い始めた人はどれくらいいるだろうか？ おいらは少なくともその中の一人なのだが、デフォルトで表示されるHTML 4.01 Transitional以外のDTDを指定して使う方法が分からずにいた。で、ようやく他のDTDに移行するヒントの一つが見付かった。
検索で見つけた春永浩敏さんのサイト「孤独を求めて、連帯を恐れず」のコンテンツ「FreeBSDに関するTips／XEmacs」によると次のような方法で、XHTMLのDTDを利用した編集が可能になるようだ。
何か変だが、XHTML文書を編集するときにはhtmlモードではうまくいかず、xmlモードにする必要がある。拡張子が.htmlのファイルはデフォルトではhtmlモードになってしまうので、これをxmlモードで開くためには文書の1行目に<!-- -*- xml -*- -->を入れればよい。もちろんXML宣言が最初になければならないので、1行目は例えば<?xml version="1.0" encoding="iso-2022-jp"?><!-- -*- xml -*- -->のようにする。
試してみたところ、この方法でばっちり。あとは新規に「.html」の付く名称のファイルを作成したときに、上のような記述が記入された状態になるような方法を探すだけ。先人の知恵はありがたいものです。来月分はXHTMLでアップできるといいなぁ。
ありみかさんとみさんの「ねこめしにっき」4月20日ぶんの「出先で OSX の恩恵にあずかる」より。
出先からおうちの OSX に SSH で入って、OSX にいれてある w3m で巡回してみる昨今。
おいらもSSHは時々利用している。とはいっても別に移出先からとかそういう大層なことはしていない。別の部屋にあるマシン(これもやはりマック)から「あのファイルになんて書いてあったかなー」というときにリモートログインしてw3mで開いて内容を確認、といった感じ。
例えば、おいらはレンタルサーバーが提供するサービスを利用するのに必要な設定とかをメールに保存してあるんだけど、メーラーにはシルフィードを使っているので、ページャーかテキストエディターがあれば、ほかのマシン上から簡単に中を見られるわけなのだ。
こういうファイルを参照する用途なら、ファイル共有を使うという手段もありなんだけど、あの「移動」メニューからネットワーク上のサーバーを探して、という手順がもはやうっとおしくて。あ、エイリアスを作っておけばいいのか（￣△￣；。
しかし、ありみかさんがやっているように、ブックマークも含めた環境の再現だったらSSHを使うのがベターかもしれないです。……もしかして、X-Windowが動く環境同士だったら、ガレオンとかでもこの手で自分ブックマークを利用できるのだろうか？
ぷらっと、「あっち系リンク」を覗いたら、あそこで拾っている数々の話題を取り上げているサイトにおいらの名前がずらり。いや、別にあそこにリストされているものを意識して取り上げているわけではないです。
テンポが良くて面白いんだけど、これで原作見たりしたらがっかりするのかなー。テレビで面白いと思ったものは原作に違和感を覚え、原作で面白いと思ったものはテレビの放送に違和感を覚え。はぁー。
Petroniusさん、初めましてです。「何かの日記」4月22日分「厨房テイスト」より。
「厨房テイスト」における各種半角カナの表現の利用も解らないでは無いけれども、現在の処、部分的且つ過渡的な表現と思つてゐます。
問題は2ちゃんねるが過ぎ去った以降に、おいらにこの過渡的な表現を使い続ける勇気があるかと……。
真里さんのscrapbookの4月21日分「アニメと原作」より。
俺は一般的なアニメで言えば、原作の方が面白いと思うのですが。
原作やアニメを見て「あれ？」と思うこともあるのは、作り手の見せかたに対する好みの問題が影響していることも多いのかもしれない。
例えば、週刊少年ジャンプに連載されている「ワンピース」。原作の絵だと人物と線の太さがほぼ同じ、登場人物の髪の毛が何も塗られていなくトーンの利用率も少ないので、全体的にメリハリがない。それでいて背景の情報量が多いために、メインとなる登場人物にあまり視線が行かず、話が頭に入って来ないのだ。CX系列で放映されているアニメは背景の情報量が多くてもカラーでメリハリを付けられるので、わりとすっきりして見えるし、すんなり話に集中できる。
逆にアニメでつまらないと思ったときは、間の取り方とかが問題だったり。現実の時間なら5秒で過ぎ去るものを10分近く心の葛藤として見せられても見てる間に飽きてしまう。どのアニメがそうとは言わないけど。
純粋に見せ方とは関係ないけど、アニメで広い年齢層に見てもらいたいばかりに、主人公や登場人物の精神年齢を下げて設定するのもなんとも。おいおい、中学生はそんなことで悩まないぞ、とか。
↑ただのイチャモンにしかみえませんな(だったら書くなよ)。
今日も真里さんのscrapbookの4月24日分「萌えとは無縁のアニメ話」より。
原作の台詞回しはあくまで漫画的な台詞回しであって、アニメには向かないのかもしれない。
言い回しに限ったことではないけど、アニメ化が失敗するのはその辺の作り直しが下手だったと言うか、作り込んでいないと言うか、場数を踏んでいないと言うか。原作と同じものはメディアが違う以上無理な場合が多いので、何を伝えるかという目標設定とそのためにはどんな表現が必要なのかををしっかり検討してほしい。そうでないと、アニメ制作会社はただのオペレーターの集団なのか、それともプロのクリエーターたろうとしているのか、その辺を小一時間(いつものパターンなので、以下略)。
メリハリ無いですか？ 俺がONE PIECEで評価しているのは『トーンの使用率が少ないにも関わらずメリハリのある絵が書ける』所だったのですが
あの書き方ではよくメリハリを付けてるなー、と関心はしてる。ただし、全盛期の週刊少年チャンピオンで育ったせいか、線画／ベタ／トーンの使い分けで遠近感やメリハリを付けるという手法に慣れてしまっていて、それがワンピース見るときに「つらい」と感じる原因になっているようだ。情報量が多すぎて空間が飽和してるように見えてきてねぇ、なにも背景まで細かく書かなくても……と思ってしまう。＜いいわけが苦しいなぁ。
『"OnePeace"』ではなくて『ONE PIECE』です ＞ あのー（￣△￣；さん。って、また揚げ(略)
原作もテレビ欄もしっかり見てないのがバレバレ（恥。ｿﾏｿ、回線切って逝ってくる。
ただいま（藁。
ところで「糞スレ立てるのが趣味なんです、迷惑でしょ？」なおいらだが、Web制作板をしばらくノーマークにしてたら、いつの間にか「 CSSコミュニティの住人になる条件 」なんてスレが立ってる。やられたー＜なにが？
それにしても>>8が挙げてる方法は敷居が高すぎ。検証してみようか。
おいらにはCSSコミュニティは向いていないのかなぁ。鬱だ、えっちねた板に帰ろうかなー。
高校生のころの小池A子たんに、カバンでお尻を責められたという男の話。うらやまし過ぎる（￣△￣；。
うちのアクセスログに残っていたFUMINGさんの「Webサイトつれづれ日記」の4月25日分「朝の続き。」から。大もとネタは25日に取り上げた例のスレ。
3: コミューンの日記を引用し、ついでにリンクしてリファを残す。 ＜あー、こないだやってえらい目にあったよ。相手はきちんと選ぼうっと。
でも、今回の思考のきっかけは、
http://anoh.s10.xrea.com/02-04.html?04250337#latest
のページからだ。
リファラでえらい目か、なにをしたのだろう……？
うーむ、決定的に「えらい目」とまでいく内容ではないなぁ(それ相応に大変な目にはあいそうだけど)。いったい何をしでかしたのだろう。
追伸：該当記事に直接リンクを張る方法があったら、教えてください。
家にはパソコンが2台あるが、実は1台は借り物。これをそろそろ返さないと行けなくなってきた。残った1台は家の人間が使っているので、おいらの使うパソコンがなくなることになる。
「これはやばい！」と、押し入れのなかをごそごそやると、出てきた出てきた、CPUに68030を搭載したマックとSCSI仕様のハードディスクが。SCSI-USB変換ケーブルを通して、漢字トーク7.5.5をぶちこんで、そのうえで残りの領域にNetBSDを入れた。なぜって、XEmacsを使える環境が欲しかったのだ。ひぃひぃ言いながら、2日がかりでX-Windowが起動するところまでこぎ着けて口から出た言葉……、「遅い」。X-Windowの起動に3分はないよなー（￣△￣；。
入れたNetBSDが手元にあった1.3.2というのもあれだが、X-Windowは一回起動に失敗して入れ直しているし、さっきもKinput2のmakeでコケた。これでは先行きが凄く不安。あとはWindowMakerとKTerm、XEmacs、GIMPまで入れてみて、どの程度使えるかが分かった段階で最新のものに入れ換えることにしよう……。
この手間を考えると、インストールが一発で終るMac OS Xや、インストールするだけで日本語でX-Windowを使える環境がすでに整っているPINEAPPLEなどの環境がなんと羨ましいことか。68K用にもこういうディストリビューションってないんですか？
あ、でも心配はご無用。家人のいないときに使えるように、残ったマシンに「anoh」というアカウントは作っておいた。68Kマックがあまりにも遅かったら、リモートログインしてやる（藁＜68KのNetBSDにSSHがあるのかどうか調査したか？
マック／ウェブ／某方面への茶々入れをネタにしたサイトという方向性でだいぶ固まってきたものの、どこかギクシャクした感じが残るのは、おいらの文章が下手くそなせい。あからさまに狙ったものの技量が付いてこなくて、思いっきりはずしていたりして情けなや（￣△￣；。もうすこししっかり校正してからｳﾌﾟしましょうね。「OnePeace」なんて書き間違えるのは恥ずかしいですよ＞あのー（￣△￣；さん。
68030+NetBSDは思いっきり苦戦中。kinput2はmakeできたものの、今度はw3mが通らない。これができないと、ウェブを見られない。どんな小さなプログラムでも一回makeするのに30分以上は取られるんだから、しっかり下調べはしておくべきだったと反省中。NetBSD用のportを使えればこんな苦労はしないのだけど、なぜかncftpでget -Rを使えない、なにがなにやらさっぱり、素人のつらいところなのだ。
このコラムは毎月月末ごろに登場します。
「困ってます、教えてください」と大騒ぎする奴に限って、問題が解決したのかどうかすら連絡して来ない（￣△￣；、に一票。