とっぷぺーじ
ねこめしにっき
2002/06/中旬
2002/06/下旬2
ドイツ勝利！！！ ああよかった…。
欧州出身のフェアなレフェリーの下でフェアな試合して、それでもドイツとけっこう拮抗してた。これまでの疑惑判定の後押し付きで勝ち続けてきて、乗っちゃったチームのイキオイはすげーって事か。きょうの好ゲームでこれまでの疑惑や不審が晴れるわけじゃないし、結果も三位または四位が確定かぁ。すげぇ納得いかんなぁ。あ、初めて複数人がユニホーム交換してもらえたゾ。（笑）
まぁ、興行上の理由そのほかで、地元開催の三位決定戦に向かうほうがヨイってのがまことしやかにささやかれてたわけで。順当にいけばブラジルに負けたトルコと対戦になるかな。日本に勝ったそのトルコに勝てば、イコール日本に勝った事にもなるワケだ。ウリナラまんせーの大団円へ。どっちにしろトルコは、明日のゲームも、もし韓国と当たっても、絶対負けるな！！！！さとみちんはトルコを応援しています。
各地でほんのり話題のコレ。
アクセシビリチーのビギナーに紹介するのにもってこいの文書。 WAI WCAG （日本語訳版）をいきなり読めって言うよりは 512 倍とっつきやすいし。ホントに読みやすい文書だった。スバラシ。
たしかに、その道の話題が日頃から好きで好きで二言三言ノベまくりな人々から見たら、ツメのアマい部分も結構あるのだけど。「音声ブラウザ系でこう読み上げられる」系のハナシに、既存の特定 UA の実装依存前提なフンイキが漂ってるとか。ウインドウの横幅が800ピクセルのとき、横スクロールなしで表示できること
っていう指針とか。
まぁナニゴトにも、過ぎたるは及ばざるが如しって事もあるし。理想と現実の妥協点をどこに設定するかは、状況や場面やコストや制作者の価値観によって違うし。そのあたりで、よくある原理主義的演説で終わらず、適度にバランス感覚のある文書だなと思った次第なりん。
とりあえずデフォルトの Preferred スタイルはいつもの「ぴんくすとらいぷ」に戻しましたですよ。そろそろシオドキ。えろ壁紙こみゅんスタイルの 2 つはもうしばらくの間、代替 CSS にシテオクです。
それにしても、 Mozilla のスタイル切り替え機構は、ブラウザ自前のヤツも JavaScript 制御のやつも、なんでか知らないけどイマイチ挙動が不審。 link 要素の並べ順によって項目が出たり出なかったりとか、切り替え後は :after 疑似要素が消えてたりとか。
一連の100 質問系に回答したページは、「ぷろふぃ〜るズ」に移動したです。通り一遍の自己紹介よりはよっぽどセキララに自己を紹介しまくる結果になるのが 100 質問のコワイトコ。でも、ムダに長くて読む気も失せまくるから、ある程度のセキララは隠せますか。ああ、隠せませんか。そうですか。しかし、よくもまぁアレコレ答えたもんだー。
元あった URL にアクセスされたときもリダイレクトで新 URL へ飛ばすので、被リンクが多めの日も安心。
ご承知のよーに、 MS 製品だからとか IE って名前だからとかから来る偏見によって、重箱の隅をつつきまくった異様にキビシイ評価ばかりが下されてる不憫な MacIE でありまして、この手のネタは何度でも取りあげる。なんであの出来損ないブラウザ OmniWeb ばかりが礼賛されるのでショー。
ページホルダを活用している人は既に知っているかもしれないけど、ひょっとしたら知らないかもしれないのでちょっとした使い方を。
[ 遠吠え より ]
というわけで、 MacIE ページホルダのすさまじくベンリな活用法が紹介されている。これはぼくもずいぶん前から活用してる技。ツールバーに配置したピン付きアイコンを Cmd + クリックすると、さらに和めますヨ。わらい。 MacIE でさとみかんを使ってるひとは、是非参考に。
以下を書いていて思ったが、ユーザーがそれまでの経験に基づいてどのように行動するかを的確に予想しそれに併せて作り込んでおり、しかもこれが4.5には確立していた訳で、今更ながらMicrosoftの開発者には驚かされる。どうにも、Appleと同じ様にその技術に関する宣伝がヘタクソな感があるんだが……例えば、技術的には明らかにより稚拙なSidebarの方が普及してしまっていたり。もっとも、プラットフォームの絶対数の問題なのかもしれないが。
Mozilla の Sidebar や Opera のカスタムパネルなんて、 MacIE ページホルダの劣化コピーでしかないですからね。あと、MacIE5 で二年前に用意されてた、ツールバーアイコンの完全なるドラドロオリエンテッドのカスタマイズや、ツールバー全体を一撃で畳めるアイデアなんて、 OSX そのものの GUI に採用されちゃったりしてるし。先進性には目を見張るモノがありますやね。そういえばスクラップブックのアイデアはまだどこにもパクられていないなー。これもコロンブスの卵的に強力なアイデアだと思うし、他ブラウザに乗り換えられない理由のひとつ。
で、何が言いたいかってゆーと、MacIE6 をそろそろ出してくださいヨってあたり。次の 3 年間を先取りする GUI アイデアと Web 標準仕様の準拠度でまたドキをムネムネさせてくだちぃ。
ページホルダをなんとかAppleScriptやJScriptから扱えないものか
の件については…。ぼくも一度そのあたりを探ったことがあるのだけど、やっぱり分からんかった。というか、手段無しかも。 AppleScript の用語辞書にパゲホルダ関連が無いのは一目瞭然だし、 JScript についても、 WinIE みたいに独自機能制御用のモノがドカドカあるフンイキでもないし、というか MS の技術資料サイトにも MacIE のハナシがほとんど無かったりするし。
閉鎖しました。
[ 閉鎖 より ]
ショック！ 有益なリソースがテンコモリのサイトだったのに、惜しい…。今のところ消えてるのはトップページだけだし、早いうちにローカルへ保存しとかなきゃ…。
帰還。
そして、えろ壁紙コミュン参加はもうしばらく継続中。でもって週明けとゆーこともあるので、緊急事態用（謎）のスタイル切り替えスクリプトを設置。わらひ。しかし Opera6 では選択メヌーが現れませぬユエ、あしからず。
おでかけしよかと思ったけど、なんか暗黙の名指しをされてる気分がしたので。
えー、そこでいくつかマカーに質問なんですが、 Mac ってどれぐらいのスペックだったら、アプリを余裕もって動かせますか？私の Mac への先入観として OS がよく落ちるというのがあるんですが（確か数年前にそう聞いた…んだろう）どうなんでしょう？ちなみに5万円で売られていた中古 iMac のスペックはこんな感じでした。
- CPU 300Mhz ぐらい
- メモリ 64MB
- OS MacOS 8.?.? 下のバージョンは覚えていない
[ ツキニイチドノハツジョウキ より ]
ぼくわつい 2 〜 3 ヶ月前まで、初代ベージュ G3 ましん（1998年1月購入） をシツコク使い倒して、お絵描きからネト生活から OSX 常用まですべてこなしてましたが、何か。
ん。 OSX を動かすんでない、つまり OS8.6 〜 9.1 あたりを使うんであれば、そのへんで不自由しないかと。まぁどーゆー作業をするのかにもよるのですがー。フツーのインタネトライフ（なにそれ）程度なら、 PC 互換機でも 3 年前スペックマシンで十分なのと同じワケで。あ、メモリは多少増やしたほうがいいかも。 64MB はちと。
OS9 まではたしかに時々落ちます。といっても、とんでもなく OS がよく落ちる
という伝説は、 System 7.5 の頃の暗黒時代に形成されたものでありまして、 OS8 以降はそれほどでもないです。もちろん OSX ならかなり頑丈。落ちることより、アプリ等の処理待ちでしばらく操作不能になる場面が Windows とかに比べるとけっこう多いので、そっちのイライラのほうがアレかも。ぼくが OSX 常用して OS9 に帰りたく無くなった理由のひとつがソレ。
あ、あと Mac は、敵意や猜疑心を持って接したり、自身のことをいつまでも理解しようとしないユザが使ったり、新機種購入を思い立ったりすると、なぜだか知らないけどフツーは起こりえないトラブルや様々な怪奇現象が発生するです（笑） オカルトのよーだけど、けっこうマジ。
- Macintosh はどれぐらいのメモリを積めば Photoshop/AffterEffects 等のアプリケーションがスイスイ動きますか？
- 同上でCPUはどれぐらい？
- Mac CPU のチップって intel とどこら辺が違うのでしょう？
- MacOS X って良いんですか？
- なぜにマカーはデスクトップ上にファイルが散乱してますか？
ぼくなりのなげやりな回答。
ま、いろんなハナシはマカ系サイトをいろいろ回ってくだちぃ。
エロ壁紙コミュン入りを狙ってみる。いあチョサクケンとかショーゾーケンとかがヤバイので期間限定。それとプロバイダの規約上マジエロなのはマズいので、茶を濁し気味に。制服美少女萌え。
んでわ週末恒例のおでかけ。
トルコ勝利！！！！！！！！！！！
日本戦のあと、日本の分まで戦う
なんて泣かすセリフを残したトルコ。そゆメンタリチは日本だけのモノかと思ってただけに親近感がが。今大会は、戦前の注目度が低いゲームほどやたらな好ゲームったりするパターンが多いけど、今回も。すさまじくスリリング。自分的ベストゲーム。日本はトルコみたいなサカをできるようになったりしないかなぁ。身長のデカさは他として。
いやぁ…。まいった。また勝っちゃった。レフェリングもシサシブシに公正だったような、やっぱり 2 失点くらいを線審に帳消ししてもらった気分もあるような。でもすげぇチームだわ、韓国。ヤってるサカ自体にはなんのモンクもないですよ。日本が目指す道では無いけど。
サカ専用スタジアムじゃなかった分、キムチ色の声援の圧迫感が半減しとりましたなー。イタ戦に比べると、ショボさが日本最終戦の宮城みたいな感じが漂った。それでもけっこう圧迫感があるけど。
つか、日本にしても韓国にしても、開催国なのにサカ専用スタジアムでのゲームが少なすぎ。なぜ日本ではスタジアム新築の際に、マイナーな陸上競技のためのトラックを律儀に必ず用意してしまうのか
、ってベンゲルも著書で言ってたけど、日本においては W 杯より国体のほうがいろんな意味（嘲笑）で何十倍も重要なイベントだからですな、そりゃ。 W 杯にかけるイキゴミと向こう見ずのイキオイの差がダンチガイってのもあって、韓国のがサカ専用を倍ぐらい多く作っちゃった。これもウラヤマシ。
しっかし、優勝候補撃破 3 つ目かぁ。自他共に認める強豪とは結局一度も当たらずに終わっちゃった日本との、経験の差がどんどんひろがってゆくヨヨヨ…。くそぅ。
ああ、ぼくも韓国はもう応援してません。あ、初戦のポーランド戦の後までは応援するキモチがあったし、勝利も喜ばしかったんだけど。でも、ずっと前から・このあともずっと日本の宿敵ライバルであるチームを、アジアの隣国だからとか共催国だからって、手のひら返したように応援するのはやっぱムリだなって事にだんだん気がついた。ライバル関係ってのは、少年マンガのソレのようにすがすがしいものばかりじゃないっしょフツー。妬ましさとか遺恨とかのドロドロした感情も真実。それもサカ。ある意味韓国サポのほうが正直。
つか、今回の共催は、パンピー日本人の眠ってた嫌韓感情を掘り起こしまくってしまった感があるですな。マスコミは必死でそれを押さえようとしてるようだけど、相も変わらずうわべだけの親善友好を唱え続ける事に意味はあるのだろうか。ポルトガル戦やイタリア戦の勝ちをイマイチ祝福できないのも、ライバルチームの大躍進への妬ましさだけでもないワケで。しかしそーゆードロドロした感情をアチラもコチラも持ってるって事を、うわべの友好親善で覆い隠すことなく事実として認めた上でつきあってく、ってなステージに到達したのかもしれず。なら共催もあながち失敗ではなかったのかも。オトナのツキアイをするには、まだまだ双方コドモなのかもしれづ。
…また第三国チーム同士のゲームでテーハンミングッコール大合唱かよ。ヽ(´ー`)ノ
似たもの同士の対戦は、ドイチュラントに一日の長アリでしたか。メリケンのスーパースピードが炸裂する場面は後半めっきり無かったしなぁ。
結局、84% くらい寝てる脳髄で観てしもーた。ほとんど内容覚えとらん…。鬱すぎる。
さて元祖無骨×新興無骨。ガキンガキン。北澤はベシャリに安定感があるなぁ。将来は NHK 解説者かいな。
ふむ。「選択肢そぎ落としの美学」ってやつが一定の価値観として共有されてるマクで生活してるだけに、けっこう納得の行く内容。いあ、その美学をわかっとらんマクアプリは増える一方ではあるのだけど、 Win みたいな極限カオス UI 万歳状態ではないわけで。
ウチのサイトは、サイトのコンテンツリストをすべてのページに配備するという事はしてない。どのページも、自身の直前直後パゲか、直近の一覧パゲにしか移動できない。大きなサイト内移動は、唯一サイトコンテンツリストのあるトップパゲを必ず経由しなきゃダメ。つまりたとえば、今みてるこの日記ページから、こことはぜんぜん別系統のイラスト展示コーナーに行くには、いちどトップパゲに戻らなきゃいけない。ただし、必要がありそうな場面では、直接目的地へワープするためのリンクはできるだけ用意しまくるけど。
「そりゃ単に全ページにコンテンツリストを置くのがメンドイからやってないんだろ」とか言わないでホスィ（笑） やろうと思えばジャバスクとかでラクチン管理で可能デス。
理由は、やっぱりサイト内移動ナビゲーションの道筋を制限することで、現在位置を見失いにくくするため。多少の不便は確かにあるのだけど、トップパゲを根っこにしたサイトの木構造を道しるべとしやすい利点のほうが勝ると考えたから。もち、ユザビリチテストとかしてるわきゃないので、これでホントに良いのかは不明。でもぼくは「選択肢そぎ落としの美学」に慣れ親しんだマカゆえに。
つか、大ワープがどこのページからでも常に可能なサイトって、逆によく道に迷うんですよ。マジに。そゆトコに限って、ホントにその場面に必要なピンポイント移動用リンクが用意されてなかったりしてて。
さて、サカサカ。
なんつか、ちょっと長い文章を書くと、そのあと何回も追記したり訂正したりしまくることが多いッス、いつも。カラ更新多めで最凶。つか、寝てなくて眠いけど、もうすぐサカの天王山なゲームががが…。
でもって、夜のドイツ×アメリカ戦もナニヤラ骨と骨が衝突する音が聞こえて来そうで（謎）、見逃せないしー。寝れない。つらい。
ちと引用が前後しますけど、説明の都合により。
ちなみに、リソースフォークってのは「拡張子」や「関連付け」の情報のことで、こいつを実データの頭にくっつける形式がMacバイナリというのだという、お勉強をした(笑)。
ちがいます。 Win における「拡張子」にあたるものは、ファイルタイプ・クリエータコードと呼ばれるモノで、それを含めたファイルフラグ方面は「 Finder 情報」と呼ばれます。リソースフォークはまたベツモノ。
Mac のファイルは、ひとつのファイルがデータフォーク部分とリソースフォーク部分の二層式になってるコトについては宜しいスよね。データフォークは正味のデータを納める部分。リソースフォークは、そのファイルに貼ったカスタムアイコン画像とか、アプリで開いたときのウィンドウの位置とか、そーいうたぐいのメタデータ関係を納める部分。その二層式のファイル個々には、さらにファイルタイプ・クリエータや Finder フラグ等もセットされてる。そりが Mac ファイルの（概念的）しくみ。
Win 方面で使われる Mac バイナリ
って語の用法は、 Mac 界隈における本来の "MacBinary" とは別モノであるコトが多い気がします。Mac 界で言うトコロの本来の "MacBinary" はエンコード方式の事。非マク環境では普通には存在できないリソースフォークや Finder 情報を、データフォーク部分へすべて押し込める方式の一つ。こうすれば、データフォークしか存在できない非マカ世界にもファイルを持ち出せる、というワケで。
（似たモノに BinHex ちうのもあります。 BinHex は 7bit ASCII にエンコードする方式。 MacBinary は 8bit バイナリ。）
Finder 情報は主にフラグ関係なので固定長でして、 MacBinary エンコードしたときの Finder 情報相当の部分も固定長 (128 bytes) 。 Win 方面で「 Mac バイナリカッター」と呼ばれるモノの多くは、その固定長部分を決め打ちして切り落とすツールかと。
しかし、リソースフォーク部分は当然のようにファイルごとにサイズがまちまちです。決め打ちで切り落とせるものじゃない。ゆえに、リソースフォークを持つファイルを MacBinary エンコードしてた場合、それを Win 上で元に戻して正味のデータ…つまりデータフォーク部分を取り出すには、リソースフォークの事も考慮したツールを選ぶ必要アリです。
けど MacBinary エンコードではデータフォーク部分の後ろに付加されるので、単純に Finder 情報部分だけ切り落としただけでも、非マク環境で使用可能なファイルにはなるかも。しかし場合によってはそれのせいでダメなケースがあるかもしれないし、なにより非マク環境ではまるで用途無しなムダデータがくっついてる状態なので、できればリソースフォークもキレイサッパリ除去できるツールを選ぶのが吉かと。
たとえば大御所 Aladdin Expander とか、 Mac-bin とか。
直接わたしが受け持っている仕事ではないので詳しくは分からないのだけれども、先方から送ってきたMOの中身がWinで見れないのです。写真なのですけどね。Macから取り込んだらしいので、MOはMacで読んで社内サーバに保存。そのときに拡張子がついてなかったらしいのだけど、Photoshop6.0で開いたらEPSで読まれたとのこと。で、拡張子がついてないファイルをWinで見れないのはまぁわかるとしても、EPSとして読み込んだものをウェブ用に保存、でJPEGにしてもWinで見れない。「ヘッダが読み取れません」とかエラー出ます。少なくともIrfanViewではそう。これはなぜ？
モトのファイルがホントに EPS だったのかはさておき、 Win の Photoshop でそのファイルを開くことができて画像も見れて、それを単に JPEG 保存しなおしたものが IrfanView で表示できないっていうことでしたらば、そりゃ Win 上の作業工程になにかモンダイがあるとしか言い様が。
JPEG 保存するまでをマクでヤって、それをファイルサーバ越しで Win に持ってきた、…というのであれば、そのサーバやクライアントがマクの Finder 情報 やリソースフォークをどう扱うモノなのかがモンダイなのかも。
フツーは、 データフォーク部分とそのほか部分（リソースフォークや Finder 情報）を 2 ファイルに完全分離して記録する「 AppleDouble 形式」が使用されるか、単にデータフォーク部分だけを取り扱って他は完全無視かのどちらかかと。 Win のファイル共有フォルダを MacOSX でマウントして、そこへ書き込むときは前者方式でして、FTP サーバに binary 転送でアプするときは当然後者の扱いがされます。
前者方式であれば、そのデータフォーク部分だけが記録されてる方のファイルをフツーに開けば OK だし、後者であればさらにナニも問題ないわけで。しかし、よもやサーバ側またはクライアント側が勝手に MacBinary 等のエンコード処理をしてたりすると、めんどくさい事態カモ。
（ Mac 用の FTP クライアントには、リソースフォークを持つファイルのアプロード時に、自動的に MacBinary 等のエンコード処理を行う設定の可能なモノが多いです。けど、そのおせっかい機能は普通は使わないモノデス。）
自分の仕事の方でも、圧縮して送ってもらったソフトをWinで解凍すると中身のPSDファイルが開かないのに、Macで解凍するとちゃんと見えたり（でもってそれはWinのPhotoshopでちゃんと触れる）……とか。Macの謎は（わたしにとっては）とっても深い。勉強しなくちゃ…。
非マク由来の圧縮方式である LHA や ZIP 等は、本来 Finder 情報やリソースフォークを扱えない仕様です。そこで Mac のアーカイバは、圧縮する前にいったん MacBinary エンコードを行ってから LHA 圧縮なり ZIP 圧縮なりをするものが多いです。そういうファイルを Mac のアーカイバで解凍するなら、まずフツーに解凍した後さらに MacBinary デコード処理をします。これで完全元通り、という算段。
もちろんこの MacBinary エンコード処理を経由しないで、データフォーク部分だけを素直に圧縮する設定も、たいがいの Mac アーカイバは可能です。その設定を行って、データフォークだけを LHA や ZIP 圧縮したものなら、 Windows でもフツーに解凍できるですよ。ただ、この設定はたいがいデフォルト OFF だったりしまして、初級マカもこのへんの道理を知らないので、いかんともしがたい事態になるわけです。（笑）
（ボク的に初級と中級マカの分かれ目は、ファイルタイプ・クリエータやリソースフォークが何かを知っていて、それらを適切に扱えるか否かだと思ってるです。つまり、そのへんを知らん初級マカは非マカのお隣さんとは上手くつき合えない事が多い。）
リソースフォークという概念は、ファイル自身がリッチなメタデータをバカスカ持てるとゆー豪勢かつ未来的な概念で、マクオンリーの閉じた世界だとすごく有用なシロモノです。が、このよーにクロスプラットホームでデータのヤリトリをするのが普通になった現在では、ファイルタイプ・クリエータコードと共に取り扱いに難儀するシロモノ。ゆえに MacOSX 以降は、あんまりリソースフォークには頼らないようにしよう、拡張子ベースで関連づけを保持しよう、なんて方向になりつつあるんだけど、生粋のマカ的には正直反発感がぬぐえず。そんなのはただの退化にも思えるし。しかし、しょうがない部分であることは納得できなくもない。ムツカシイ所。
ねこめしにっきヘッドライン
Mail to Alimika Satomi
Site search
About copyrights