「言葉」と「思考」の関係性2006年12月04日 00時13分40秒

きっかけは、氏の別の記事に対する、はてなブックマークでの以下のコメント。

ぶっちゃけソースコードと言葉は違う。言葉は見た瞬間自動実行されるバイナリみたいなもの。

おいらとしては、「そう言う側面もある」としながらも、しかし、あえて自動実行させずに、「しかしこの言葉はいったい、どう解釈すべきなのだろう」と踏みとどまって考える (つまり、敢えてソースコード的に捉えて、咀嚼する) ことができるかどうかで、議論の幅は広がるんではないかと思う。

小飼氏の解釈は、らしいなと思った。

ただ、敢えて付け加えると、個人的には、重要なのは実は場面や立場などではなくて、「文脈」なのだと思う。「空気を読む」っていうのは、それまでの経緯を知っている人同士で共有できるはずの「文脈を読む」と言い換えることができるはずだ。

しかし、同時にそうした「文脈」は、個々人の興味によって形成される部分も決して小さくはないため、「自分の文脈」に当てはめて他人の言葉を耳に (あるいは目に) したときに、感情がすこぶる高まってしまうようなケースがあったりすると、それがフレームの引き金になったりする。ここで、視点を切り替え、「相手の文脈」を探ってから、再度その文脈に当てはめて解釈を試みることによって、始めてその言葉の「真意」に気付き、納得を覚えると言うことは、しばしばあるように思う。

しかし、そこへ至るよりも先にフレームに至ってしまうことがある一番の要因は、「自分の文脈」で解釈する方が、それ以外の文脈で解釈するよりも、早くて簡単だからなんじゃないかと思う。

「言葉は見た瞬間自動実行されるバイナリみたいなもの」と感じてしまうのは、言葉を「自分の文脈」で解釈してしまうことに慣れてしまっているからなのではないかと思う。そう言う部分も確かにあるが、でも、それだけではやっぱり駄目なんだとも思う。

それでも、一定の気配りと気遣いはあっても良いと思うけどね。

サイトの横幅問題再び2006年12月04日 12時05分00秒

まーた乗り遅れた。(苦笑)

内容に踏み込むのも面倒なので、以下に雑感をまとめてみます。

  • 印刷時のスタイルが悩ましいのは、W3C 勧告の <img> タグが、widthheight 各属性の指定を推奨している点、および、PC のブラウザ上で画像を (完全な状態で) 表示させるためには、これらのサイズをピクセル単位で指定する必要があるという点に尽きると思います。例えば、画像のサイズを、実際の画像ファイルにより指定される大きさに対する相対指定で指定可能とし、それが推奨されていたならば、画面表示用と印刷用とで css を使い分けるという対応の方が優れていることになります。
  • 印刷を考慮するならば、本来、サイズの類はピクセル単位で考慮するべきではありません。一般的な用紙サイズを「A4・縦」と決め打ちするならば、幅 210mm × 高さ 297mm などとして (つまり、ミリやインチなどの単位で) デザインすべきです (画面表示用と印刷用の CSS を分けるべきだとする意見が多いのはこの辺の事情によるものと思われます)。改ページ位置が指定されることが理想的ですが、ブログなどのテキストサイトでそこまで頑張る必要はないと思います。
  • ブラウザや OS の統計を取ることにあまり意味があるとは思いませんが、PC 以外の端末で小さい画面を利用することまで考慮する必要は、必ずしもないと思います。リキッドデザイン至上主義は、歓迎できません。現実問題として、折り返せば読みやすくなると言うものではありません。本当に小さい端末を考慮する場合、そもそも段組によるメニューの表示なども考慮する必要があるでしょう (それで表示が崩れるぐらいなら、横幅固定にしてくれた方がマシ、という意見は、yokoyan.com でこの問題が取り上げられたときにすでに出てきていた筈)。HTML+CSS に、現状そこまでの柔軟性はありません。このような特別な端末のみをサーバー側で認識して、出力すべき HTML を切り分けるという試みは、すでに携帯電話の組み込みブラウザ向けには十分現実的な話です。(MT にそのような仕組みが存在するのかどうかは、実際使っているわけではないので不明ですが)
  • 個人的な感情としては、デザインぐらいはサイト製作者側で用意しておいてくれよと思います。サイト側はデザインをまったく提供せず、ユーザーが自由にデザインを適用してください、というサイトは、自分でデザインをいちいち用意して適用するのが面倒なユーザーにとっては、不便か、もしくは (デフォルトのまま見ちゃうので) 無味乾燥です。ユーザーがデザインを用意できるという機構は、サイト製作者が提供するデザインが見るに耐えないほど酷いものである場合の「最後の手段」として用いられるべきです。「絵文録ことのは」は、CSS による指定で 640 px 固定となっていますが、この CSS は、ブラウザが対応していれば、ユーザー側で任意の CSS に変更できるし、改行タグを入れているわけでもないので、その場合にはリキッドデザイン足りえます。サイト側の気配りとしてはこれで十分です。

小さい端末で採用しているフルブラウザって、大抵 Opera でしょ? だったら表示サイズとか気にせんでも、ユーザーが自分で表示を縮小すりゃええやん。それができる、本当に本当に便利なブラウザなんだから。(なんて暴論吐いてみるw)

どういうことだー2006年12月04日 19時06分19秒

こんなものをインストールしてみようかと、以下のようなことを試してみたわけなのですが、

  1. この辺の作業は既に実施済み。
  2. 「Visual Studio 2005 コマンドプロンプト」 (VC++ 2005 Express を入れるとスタートメニューから辿って使えるプロンプト) にて、perl Makefile.PL して nmake したら、「windows.h が見つかんねーぞゴルァ」とか言われたので、%PROGRAMFILES%\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat を弄くって INCLUDELIB をセットしなおして再度 nmakenmake install
  3. Perl にて use Win32API::MIDI; してみたら、「msvcp80.dll が見つかりません」とかいう糞なアラートがでてこけちゃったので、%WINDIR%\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd とかいう意味不明なディレクトリ (SDK もしくは再配布可能パッケージとやらをインスコするとそこに保存してくれるらしいことは確認済み) にあった msvc?80.dll (? は p と r と m) の類を %WINDIR%\system32 なディレクトリにコピーして再度試した。
  4. ランタイムエラー「R6034 An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information.」とかいう内容のアラートが出てこけた。お手上げ。

根性なし>ヲレ。つか、無料配布版の VC++ 2005 Express Edition + MS Platform SDK の組み合わせはまだ未テストなのか? それともそもそも Dev.Studio 2005 全般的に未テストなのか? BCC32 はもう諦めてるからいいんだけど、これだけのために Dev.Studio 2005 購入なんてまっぴらゴメンだ。金ないし。

つか、cygwin で試してみたらあっさりインストールできてしまった訳だが。。。

。。。素直に cygwin で作るかな。。。('A`)


Mon Dec 4 21:29:32 JST 2006 - 追記

つか、README に書いてありました。Active Perl の環境ではテストしてませんって。('A`)

DEPENDENCIES

   This module is being developed on Cygwin (http://www.cygwin.com/)
   environment.  It is not tested well on Active Perl environment,
   since I don't have MS C Compiler.  I had a report saying it could
   be compiled and MIDI output worked well but MIDI input did not.
   Any feedback from ActiveState Perl users' are welcome.

Mon Dec 4 23:36:12 JST 2006 - 追記

ラクダ本の 21 章にある手順に従って試しにエクステンションを作ってみたら、まったく同じランタイムエラーが出やがったので、たぶん環境の問題。やっぱり MS VC++ のバージョンの問題なんだろうか。。。(T-T)/