Fragments of Reality

「…がうまく動かないんだけどさー」
「OSXのバージョンは？」

なんて会話、よくありますよね。 そんなときは林檎のアイコンから「このMacについて」を選択すると、 OSXのバージョンとプロセッサ、および、メモリについて簡単な情報を得ることができます。 もうちょっと詳しい情報が必要な場合は、 システムプロファイラを起動します。 これは、 上記の「このMacについて」で現れるダイアログから「詳しい情報…」をクリックしてもいいし、 ユーティリティから直接起動することもできます。

でも…こんな情報もコマンドラインで知りたいですよね、ふつー。 ってことで、今回はシステムに関する情報を得る、です。

unameとsw_ver

まず、OSXに関する情報から。 上記の会話のように、OSXのバージョンを得るには… ええ、もちろんunameでもいいんですよ、unameでも。 これはBSDでもLinuxでもSolarisでも（略）でも使えるので、 説明するまでもないですが、

$ uname -a
Darwin xxxx.xxxx 8.7.1 Darwin Kernel Version 8.7.1: Wed Jun  7 16:19:56 PDT 2006; 
root:xnu-792.9.72.obj~2/RELEASE_I386 i386 i386
$

ってな具合です。 一方、sw_verというOSX用のコマンドもあります…が、 実はunameのほうが情報量が多いかもしれない。 sw_verで勝ってるのはBuildVersionが得られることくらいです。

$ sw_ver
ProductName:    Mac OS X
ProductVersion: 10.4.7
BuildVersion:   8J2135
$

system_profiler

一方、上記のシステムプロファイラのコマンドライン版がsystem_profilerです。 -detailLevelで情報量を指定することができます。 可能な値はmini/basic/fullで、省略するとbasicです。

$ system_profiler -detailLevel mini
Hardware:

    Hardware Overview:

      Machine Name: MacBook Pro 15"
      Machine Model: MacBookPro1,1
      CPU Type: Intel Core Duo
      Number Of Cores: 2
      CPU Speed: 2 GHz
      L2 Cache (shared): 2 MB
      Memory: 2 GB
      Bus Speed: 667 MHz
      Boot ROM Version: MBP11.0055.B02
      SMC Version: 1.2f10
      Sudden Motion Sensor:
          State: Enabled

    …（略）…

AirPort Card:

    AirPort Card Information:

      Wireless Card Type: AirPort Extreme  (0x168C, 0x86)
      Wireless Card Locale: Japan
      Wireless Card Firmware Version: 0.1.24
      Wireless Channel: 11

$

-detailLevel fullにするとアプリケーションからStartupItemsに至るまで、 ありとあらゆる情報が出力されます。 これだけの情報が出ればさすがに十分ではないかと。

ちなみに-xmlオプションをつけると、上記の情報をXMLで出力できます。 その出力を.spxという拡張子で保存すると、 システムプロファイラで見ることができるようです。 まあ、コマンドラインでやろうぜという趣旨からすると、 どうでもいい機能ですねー。

久々に頭が痛くて泣きそうです。 しかも、昨晩は寝倒したのに治らない…

ってのはさておき、先日MTを3.32にあげました。 ところが…同じ3.32のみやっちは、メニューが全部日本語に。 ここは全部英語のまま。 いや、英語でも全然かまわないんですけど、 同じ環境なのになんで？と。 Settingとか見ても言語環境選ぶところなんてないしなあ。 訳がわからない…

普通、commit logを後から変更するなんてことはしてはいけないんですが、 「あー、typoした！！！」なんてこともたまにあったりして、 そんなときにはお願いだから変更させてください神様、 とか思ったりするものです（しないって

svn:ignoreを設定したことがある人ならpropeditでsvn:logあたりを変更すればいんじゃない？ と思い至るような気もするんですが、 さすがにrevisionに対するpropedit（revprop）は、デフォルトでは禁止されているのです。 これを有効にするには、hooksにpre-revprop-changeを追加します。 pre-revprop-change.tmplがあるので、それをcpしてchmod +xしてください。

$ cd /path/to/svn/repository/hooks
$ sudo cp pre-revprop-change.tmpl pre-revprop-change
$ sudo chmod +x pre-revprop-change
$

pre-revprop-change.tmplの内容はsvn:logに対する変更だけ許可するというものなので、 通常は上記の設定で十分でしょう。 これができたら、propeditします。

$ svn propedit --revprop -r N svn:log

ちなみに、このあたりに説明があります。

Subversionネタを書いたからというわけではないでしょうが、 1.4.0が出てました。 svnsyncの提供とさまざまな高速化が主な変更点のようですが、 OSX使いにはうれしい変更が。 なんと、 通常のパスワード認証のパスワードがキーチェーンを使って保存されるようになりました。 もちろん、今までにキャッシュされたパスワードはそのまま利用できます。 が、キーチェーンに移動したい場合は~/.subversion/auth/svn.simple/にあるファイルを消せば、 次に聞かれたパスワードはキーチェーンに保存されることになります。

残念ながら、キーチェーンを使ったクライアント証明書のサポートまでは追加されていませんでした…

NetAppからこんなプレスリリースが… きいてないよ！ ちょっとこれはダメージ大きすぎるのではないかと…

Hedgehog 0.99.5をリリースしました。 Emacs 21.3でも動くといっておきながらろくに検証してなかったので、 ゴミ・データが混ざってしまう不具合があったようです。 Emacs 21ではstart-processしたあと、 データを渡せるようになるまでにちょっと待ってあげないとだめみたい。 ほんとにこれでいいのかはよくわかんないんだけど。

と、数年前に吠えた人がいましたが、ほんとに品質低いなあ。 今使っているMacBook Proも使い始めて一ヶ月くらいだというのに、 なんと内蔵スピーカを認識しなくなった。 先日もiPod shuffleのバグを踏んだしさ。 さて、そうすると何が起きるか。 サウンド出力デバイスとして内蔵スピーカは死んでいる。 ライン出力には何も挿さっていない。 そうすると残っているのは、なんとS/P-DIFなんですな。 というわけで手元のMacBook Pro、ライン出力端子が赤く光っております。 …ていうか、Apple、いい加減にしろよ。

追記

その後、突然スピーカデバイスが認識されました。 PMU Resetしても見えなかったのに、 再起動もせず、ログアウトすらしてないのに。意味不明…

まあ、些かというか猛烈に個人的な話ですが、 某北陸方面の大切な友人の誕生日です。 おめでとう！

早いもので、今日で3年経ちました。 まあ、いろいろとありましたが（特に最近はいろいろと迷惑をかけてますが）、 感謝感謝です。

ちまたではiTunes7の新機能がどうだという話題で持ちきりですが（ほんとか？）、 実はすてきな機能が追加されていました。

ご存じの通り、 iTunesからはAirMac Expressに接続されたスピーカに出力できるわけですが、 たとえば家中にAirMac Expressを配置して音楽で埋め尽くそうとしても、 同時にひとつのスピーカしか選択できなかったのです。 しかし、iTunes7では複数のスピーカを同時に選択できるようになりました。 これで家中を音楽の洪水で満たすことができます！

なお、「iTunes7では」と書きましたが、 ちゃんと見ていたわけではないので、 iTunes6の後半で既にサポートされていたのかもしれません。

ちょっとぐぐってみるとわかるんですが、 Hyper Linkにtarget="_blank"をつけるのはかなり嫌われているようです。

原因はいろいろあるようですが、大別すると以下のような感じ。

• 新しい窓を強制的に開かせることでリソースを消費する
• W3Cでは非推奨扱い（XHTML1.1以降では既に廃止されている）
• 利用者から「あたらしい窓で開かない」という選択肢を奪う

まあ最初のやつは戯言なのでどうでもいいとして、 基本的には下のふたつが根拠のようです。 しかも、 W3Cで非推奨扱いになったのは利用者の選択肢を奪うことが理由のようなので、 結局は最後の項目が大きな理由と云うことでしょう。

W3Cで非推奨扱いになったにも拘わらず、 target="_blank"はなくなる気配がありません。 ということはtarget="_blank"擁護派もいるわけで、 彼らの主張はほぼ次の通りです。

• ほかのサイトに飛ぶときはいずれにしても別窓をひらくでしょ？

私はどうかというと、 確かに他のサイトに飛ぶときは別窓や別タブで開くことが多いようです。 ただ、この場合は状況に応じて無意識に使い分けているわけで、 target="_blank"が設定されていない（すなわち選択の自由がある）ことを利用していることになります。 また逆に、リンクをクリックしたときに意図せず別窓になることもあるわけで、 「別窓開きやがった、うぜえ」と思ったりすることもあります。

このように見てみると、 個人的な意見も「target="_blank"撲滅推進」のように見えるかもしれません。 しかし、実際のところは適宜target="_blank"を使っています。なぜか。 どのように開くかを「無意識に使い分けている」と上で書きましたが、 残念ながら世の中にはそれが難しい人もいるのです。

クリックするときにShiftを押すだけじゃないか、 と思う人もいるかもしれません。 でもそれは、あたらしいものに適応していける若い世代だけであって、 還暦を過ぎたひとたちにはかなり高いハードルになり得ます。 そんなひとたちには、

「インターネット閉じたらまた開かないとだめだし、 さっきまで見ていたところにも行けなくなるし、 ほかのところは大丈夫なのになんで？」 （注：Internet Explorerを閉じちゃうと窓がなくなるので、 もう一度起動しないといけないということ。 ちなみに、「戻る」ボタンでさっきのところに戻ることもハードルが高い）

ということになってしまうわけで、 適切だと思えるところにtarget="_blank"を入れてあげることが、 ある意味でユーザビリティの向上に繋がっているという側面を否定できません。

こういったことから、 無意識でShiftを押すことが身についた世代が還暦を迎える頃までは、 target="_blank"は必要悪として存在し続けるべきだと思うのです。 だってほら、「うぜえ」と思う人は他の手段でなんとかできるでしょ？

ところで、 target="_blank"は個々のリンクかbaseのどちらかに設定することになります。 前者だと設定したリンク以外はtarget="_blank"にならないし、 後者だとページ内の全てのリンクがtarget="_blank"になって、 それこそ「うざい」ことこの上なし。 divとかで特定の領域だけ設定できればいいのにね。

ってことで、 以下のJavaScriptを使ってtarget="_blank"を設定したりしています。 bodyのonLoadで呼んであげてください。

function setLinkTargetToBlank() {
  var links = window.document.links;
  var baseURL = window.location.protocol + "//" + window.location.hostname;

  for(var i = 0; i < links.length; i++) {
    if(links[i].href.indexOf(baseURL) != 0) {
      links[i].target="_blank";
    }
  }
}