2008年12月 | プログラマ2.0日報

TOP > プログラマ2.0日報 > 2008年12月

哲学の逆襲

2008.12.24

って今年のまとめ、かな。

こういう感想を抱くのは、今年面白かった本の傾向なんですね。

実はこれは去年の今頃出た

「RESTful Web サービス」（Richardson＆Ruby）→[レビュー]

から引き続いている傾向のように思います。まあ「RESTful」だって起点を少しいじれば「今年の本」に入っても不思議じゃない本ですけども、今年は

「マイクロフォーマット」（Allsopp）→[レビュー]

「Make Things Talk」（Igoe）→[レビュー]

と「熱い本」の印象が強いんですね...（あと熱いのというと「プログラミング Erlang」[レビュー]かな）

で、今挙げた本はどれもある意味、「（少なくとも現状は）少数派」からの、「哲学の普及」を目的とした本です。REST は勿論「RESTafarian」なんて言い方があるくらいですし、マイクロフォーマットは「噂のタネ」にはよくなるけども、普及は？な現状をどうにかしようと活動中のもの、「Make Things Talk」が代表するフィジカル・コンピューティングは運動として面白くなってきたばかり...と、

考え方はとっても面白いんだけど、

な「運動」を代表する本なんです（Erlang だってハッカーのマイナー文化を代表する「関数型言語リバイバル」ですしね）。でまあ逆に、「何でこういう熱い本が今年目立つのか？」という問題（コッチの方が面白い）を問うと、

もはやソリューションの数は「１つだけ／どっちか」ではなくて、かなり沢山ある...

ということなんじゃないでしょうか？だからこそ、ソリューションの間で「コレがいい」「アレがいい」というのは、かなり微妙な違いの問題になってきている、と言い換えてもいいのかもしれません....決定的なソリューションはなく、

いくつかあるソリューションのどれでも、みな似たような解決手段を持っている

という状況が、たとえば

○作者が日本人で、日本語のマニュアルが完備してるぞ！
○コミュニティが充実しているぞ！

とか、ツール自体の「本質的？」でもない偶然の性格によって違いが出てしまうようなことに繋がってもいるわけです。特にオープンソース開発の「コミュニティ」は、その「ソフトウェアの体質」を決定してしまうような部分もありますから、逆に言えば「コミュニティのあり方・体質・体制」が「ソフトの（性能的な）評価」以上に重要にもなってくるわけです。

でしかも、「ソフトの差別化」は普及につれて「差が縮む」方への圧力がかかりますが、「コミュニティの差別化」は普及によってますます「ライバルとは違う」ことを強調したくもなるでしょう.....だからこそ、「コミュニティの哲学」が先鋭化していく傾向が見えてくるのかもしれません.....

ですから、

モノは似てるが、考え方は違う！

というのが、今年の傾向？かもしれませんね。（今年印象的なソフト....は hadoop かな？）で勿論「今年のコンセプト」は「Make Things Talk」が代表する「フィジカル・コンピューティング」とそのブームですし、逆に言えば、

コンピュータ・プログラミングというモノが、本質的に「文化」だ！

ということをしっかり押さえているオライリーのカルチャー的強さが目立ったようにも思います...だったら来年は、

プログラマは体育会系じゃなくて、文化系だ（苦笑）

ということにでもなれば面白い、かも。

投稿者 : 杉浦　こずえ | 投稿日時 : 2008.12.24 09:31

「実体」の実態は？

2008.12.22

冗語風な言い回しって好きですね私。

結構これ前から気になっていたのですが、少し調べたんです。その問題とはですね、

何でXML では実体参照で他のファイルをXMLに取り込めるのに、XML であるはずのXHTML ではそれができないか？

ということです。たまにあるんですよねこういうＸＭＬ（James設定ファイルより）。

<?xml version="1.0"?> <!DOCTYPE config [ <!ENTITY fetchmailConfig SYSTEM "../conf/james-fetchmail.xml"> ]> <config> .... 略 &fetchmailConfig;

こうすると、&fetchmailConfig の位置に、../conf/james-fetchmail.xml の内容が展開されるので、

ファイルを分割して管理できる

というメリットが生まれるわけです。しかし、XHTML 自体では、

何か別のファイルをインクルードしたり、変数のように断片を扱って引用して使う

ということができないわけです（勿論 JSP とかvelocity とかテンプレート系ツールを使えば別）。

まあ、XHTML でできない理由....というと、これは XML 文法面での問題がかなり大きいです。XHTML では実質上

<?xml version="1.0" encoding="Shift_JIS"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">

と DOCTYPE宣言をすることが求められますが、エンティティ定義は DOCTYPE 宣言の中に書かなくてはなりませんし、しかも

DOCTYPE 宣言は１ＸＭＬファイルに１つしか宣言できない（アタリ前）

なので、実質上

断片を管理するためのエンティティの宣言ができない

からやりようがない、という結論になります。

.....じゃあ、逆に、

XHTML がバージョンアップするとかして、エンティティのような断片管理ができるようになる...可能性があるか？

というと、これもどうやらキビシイようです。というのは、

ブラウザの２つの顔？

という面白い問題があるようなのですね。

ＩＥだとかFirefox だとか Opera だとか、皆知ってるブラウザはいうまでもなく、

もともと（SGML風な言語である） HTML ブラウザだった

わけです。しかし HTML の XML 化されたバージョンである XHTML が（それなりに）普及したことで、事後的に

（SGML風な）HTMLブラウザであり、かつ XML ベースのXHTMLブラウザだから、XMLブラウザでもある...

というモノに変化していきました。ですから、この３つのフォーマットを取り扱うことができるのですけども、論理的には

ＸＭＬ⊃ＸＨＴＭＬ

であっても、

XML ブラウザ機能が拡張されて、XHTML ブラウザになっているわけではない！

という事情があるのです。これは、

XML の規約に（うっかり）反したタダの XML 文書は、違反文書だとして却下すればいいが、XML規約にうっかり反した XHTML文書でも、とにかく表示できなければ、デタラメな HTML が表示できている現状と整合性が取れない

というオトナな現実もあります。（確認：→error.xml.html は</body></html>を落としているから、XML宣言してても well-formed ではないが、それでも XML としてエラーという扱いにならずに、レンダリングが強行されます...お試しあれ）

で、さらに、そういう

XHTML「も」解釈できる HTML ブラウザとしてのブラウザ

は、

（典型的な）妥当性検証を行わないユーザエージェント（この用語は「XHTML1.0: 拡張可能ハイパーテキストマークアップ言語」 3.2 ユーザエージェントの適合性による）

なので、実は、

DTD の URL が DOCTYPE 宣言に書かれていても、URL から DTD を入手して合わせて記述を検証する必要はまったくない

ために、XHTML 規約で決まっている範囲のエンティティ（要するにHTML4とまったく同じ）をレンダリングすればいいだけ

ということになります.....（結構ショック？）

XHTMLブラウザから見た XML宣言とかDTD とかは、

単なる飾り（極論）

に過ぎなかったりするのですね（少し悲しい）。

逆に、Well-formed な XHTML を、XHTMLブラウザの XML ブラウザモードでブラウズさせる（言い方ややこしいですが、要するに拡張子 .xml でちゃんと表示する XHTML を表示してみる）と、

使っているエンティティによって、ブラウザによって動作が違う

なんてことになります。要するに、& < > " ' の５つのエンティティは、XML 規約で決まっているモノなので、

ＤＴＤで宣言があろうとなかろうと、常にちゃんとレンダリングされる

わけですが、XHTML で（というか、HTML4で）決まっているエンティティ（©とか）は、

DTD に定義がある

ということになります。なので、今回は「XMLブラウザ」なので、宣言されているDTDを見にいかなくてはならず、

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd

を取りに行ってレンダリングをするのですが、IEはその解釈に失敗するようです（結構情けない）....しかも、面白いことに、CSS なしのタダの XML なのに、Firefox では <table> タグとかを、HTML のジョーシキに従ってレンダリングしてしまいます（ＩＥはタダのXMLとして表示します）。

あれ～と思って、いろいろやってみましたが、どうやら、Firefox では、

<html xmlns="http://www.w3.org/1999/xhtml"> 要素の中にあることで、HTML流レンダリングのスイッチが入る

という格好のようです。理屈じゃないようです....結論、としてまとめるとするならば、

XHTML は XML かもしれないが、XML だと思ってはいけない！

という（アタリマエな）結論になるようです....（参考「XHTML と実体参照」）

XML 方面の主流は「実体は極力使わないようにしよう」という方向に進んでいます

要するに外部参照まで面倒見ることにすると、検証が大変過ぎることになるケースが多いのがイヤがられてるようですね。ふう....

投稿者 : 杉浦　こずえ | 投稿日時 : 2008.12.22 22:01

指悪魔と付き合う(後編)

2008.12.16

さて、前編では「今でも生きている finger」の話でしたが、後編は yafingerd という(名前のとおり) Yet Another な fingerd の話です。これ結構面白いんですね。

まあ、標準の fingerd ってプロトコルが単純な分(というかほとんど昔から進化してないです)、実装も単純です。tcpd から呼んで、指定されたユーザがいて、特に問題がなければ

1. アカウント名とホスト上でのホームディレクトリ、 GCOS フィールド、ログインシェルといった /etc/passwd 情報
2. ログインしている端末の表示
3. メールが届いているか
4. .project ファイルの内容(現在携わっているプロジェクトの名前などを１行で）
5. .plan ファイルの内容(現在携わっているプロジェクトについてのあれこれ)

といった情報を表示します

....あれ、これ実名が入りがちな GCOS とか、アカウント名とか、ログインしている端末とか、イマドキはセキュリティ的にまずいんちゃう！？

まあ、たとえ実害がなくてもキモチは良くないですよね、うん。で、そこらへん yafingerd は考えてあります。設定ファイルでは、

showpgp: PGP公開鍵($HOME/.pgpkey)を表示する
showproject: $HOME/.project を表示する
showplan: $HOME/.plan を表示する
showname: GCOS フィールド(実名がセットされることが多い)を表示する

という設定内容で、ユーザごとにキメ細かな制御ができるようになっており、今時無意味な使用端末（そりゃ昔は１台のコンピュータを何人かで共用して、それぞれの端末の前に「誰がいる」のが意味があったのですが...）とか、「メールが届いているか？」（セキュリティ的にまずいのは勿論、今 localなMDAで（要するに POP3 とか IMAP ではなく、SMTP で）メールを受け取ってる人なんているんだろうか？）とかはまったく出さないことにしています。ですから、前編の CMU の出力はおそらくこの yafingerd(かその系列のもの)でしょうね。

でさらに面白いのは、設定ファイル次第では、

自分の好きなプログラムを(ユーザごとに)起動でき、

しかも、

メールサーバの仮想メールアカウントみたいに、「仮想fingerアカウント」が作れる

という特徴です。前々回、

telnet を使って、何かヘンなサービスを提供する

なんて話をしましたが、よく考えてみれば、

telnet ポート(23)を監視しリクエストをハンドルするのは、別に telnetd でなくてもいい！

わけで、

telnetd じゃなくてこの yafingerd で提供するのもいいんじゃないか？

ということです。だって、telnet だとログインシェルの代わりに /etc/passwd のシェルフィールドに別なプログラムを指定する（chsh(1)とか使ってね）わけですから、結構気持ちが悪いです。また、当然

実アカウントとは無関係なアカウント名で運用できる

というのは結構大きいように思います....ね、遊び心があれば、ちょっとこれ調べてみるのも面白いかも知れませんよ！

ちなみに、yafingerd で運用すると、http での finger(79番ポート)アクセス

というのが出来ちゃいます。つまり、http の

GET http://<host>:79/<account> HTTP/1.0

のリクエストで、HTML で整形された出力が得られます。ですから、CMU の Peter Lee 学科長ならば、

http://cs.cmu.edu:79/petel

とかアクセスしてみるといかが？（けどCMUの場合、さすがにこれは邪悪と考えたのか、結果がマッチしないように機能を殺してあります....ちなみに、Firefox/Opera では 79番ポートは自分の扱うWelKnownポートじゃない！というノリで、セキュリティ制限が走って表示しないようです.....そうしたいのは判らないでもないけどね。で、Konqueror とIEはＯＫでした）

投稿者 : 杉浦　こずえ | 投稿日時 : 2008.12.16 12:44

指悪魔と付き合う(前編)

2008.12.15

って冗談です。finger daemon なんていうレトロな話題です。

実際、今時 finger なんてレトロもいいとこです。 finger というと、

1. モリスワームで使われた２つの入口のうち、１つが finger デーモンのバグ(もう一つは sendmail のデバッグオプション。ただしクラック手法は古典的なバッファオーバーランなので、finger プロトコルに問題があったわけではない)。
2. 現在ログインしているかとか個人情報とか、昔はともかく商用での供用が開始して以降の「荒れた」インターネットでは、公開するのが適切とはいえない情報を提供するかもしれない。

といったあたりから、過剰な「危険」イメージがついちゃったサービスのような気がします....実際私、finger デーモンは立てたことがなかったです。

それでも今みたいに、

何でも HTTP プロトコルにのっけちゃう

世の中になって、レトロな趣味の持ち主たちの間では、たまに

ヘンなプロトコル

の話題で盛り上がるみたいですね。たとえば、去年(2007年)はなぜかは、gopher プロトコルの話が一部で盛り上がってました(「空前の gopher ブーム到来」当然洒落です)。さすがに私は現役では gopher 使ったことはなかったのですが、archie だとさすがにあります。IIJ archie って結構お世話になりました.....(けど2006年にひっそりと停止されてます。archie って検索サイトのハシリみたいな便利なものでしたから、WWW じゃなくて Google に負けたようなものかも。少しは名誉？)

とはいえ、finger ともなると、今でも Linux のディストリビューションには

/usr/sbin/in.fingerd

がちゃんとあって、tcpd 経由で起動できる設定になってます。 /etc/inetd.conf とかちゃんと書けば、使おうと思えば使えちゃうわけですよね。

私はですね、ある話からちょっとこの finger デーモンに憧れてたところがあるんです。

カーネギーメロン大学(CMU)の大学院生たちは、長年の問題(引用註：ハッキングの最中にジャンクフードを食べること！)を、ジャンクフード／コンピュータインターフェイスを作成して解決した。計算機学科のコーク自動販売機が置かれていたのは３階、研究室からずっと離れた場所だった。そのために彼らは売り切れマークを眺めるために、あるいはもっと運が悪ければぬるいジュースを買わされるために、長い道のりをたどらされることがよくあった。(略)(売り切れの)ランプとシリアルインターフェイスをつないで、「販売状況」データを学科のPDP-10メインフレームに転送するのは、わけのない作業だ。PDP-10から見ると、販売機のインターフェイスはなんと telnet 接続になっていた。(略)学科内のローカルなイーサーネットにつながった全マシン、さらには Internet 接続のマシンからでも、販売機の状態を自由に確認できるネットワークプロトコルまで設計したのだ。(略)思いっ切りお手軽に機能を実現するために、彼は標準の finger の機能を流用した。彼は finger サーバに手を加えて、仮想のユーザ "coke" が finger されたときに、販売機の状態表示をするプログラムを実行するようにしたのだ。(略)
finger coke@g.gp.cs.cmu.edu
この自動販売機の状態は、Internet のどのマシン、たとえ地球の裏側からでも確認できるのだ！(van der Linden「エキスパートCプログラミング」邦訳 p105)

....カッコイイでしょこれ。70年代の話ですよ！けど、「コーラの冷え具合」を確認すること、イマのあなたはできますか？(おっとこっちは Arduino 関連のネタですね)

で...ですが、gopher がいまだに使えるサイトがあるように、またアメリカの有名人たち(とくに大学)では、「finger が使えるからちゃんと .plan ファイル（個人の予定など finger サービス用に公開する内容を自由に書けるファイル）を書いておく」人がいるようですね。ちょっとこのサーガの舞台である CMU で試してみると、たとえば、cs=Computer Science 学科（2008年の全米の大学の計算機科学部門でNo.1評価だそうです）の学科長である Peter Lee 教授を finger すると、

% finger petel@cs.cmu.edu
[cs.cmu.edu] One entry found for exact uid match Login: petel Name: Peter Lee Directory: /afs/cs.cmu.edu/user/petel Mail is forwarded to <メールアドレス> Plan: Professor of Computer Science and Associate Dean for Undergraduate Education Office: <住所> email: peter.lee@cmu.edu Web: http://www.cs.cmu.edu/~petel FAX: <Tel> PGP public key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 <PGPの公開鍵> -----END PGP PUBLIC KEY BLOCK----- "I live with fear every day of my life, but sometimes she lets me race." +-----------------+ | Bless this MESS | +-----------------+

とちゃんとした .plan ファイルを書いていることが判りますね。で、最近の .plan ファイルの流行は、PGP の公開鍵を入れておくことのようです。確かに PGP の公開鍵を公開する場所って特に決定版があるわけじゃないですから、 .plan ファイルというのもセマンティックに正しいものかもしれませんね。

(ちょい長くなりましたから、続きは次回。けど、finger の .plan ファイルが、ブログの鼻祖である...なんて面白い考察があります「「ブロガー第1号」は誰？--誕生から10年を機にその起源を探る」)

投稿者 : 杉浦　こずえ | 投稿日時 : 2008.12.15 09:35

telnet は古い友達

2008.12.11

私が昔風なのか...とも思いますが、たとえばメールサーバを立てたとき、一番最初の送信テストはどうしますか？いきなり自分がいつも使うMUAの設定を変えて、送ってしまいますか？

いえいえ、私はそんなことはしません。常に

% telnet localhost 25

と telnet を使った手動アクセスでチェックして、一応動いている、という自信を持ってから、MUA でのアクセスにします。勿論この要領で、POP3 サーバだろうと HTTP サーバだろうと何でも telnet でチェックして、それから専用クライアントでのチェックに入るのです。これが私の常識かな。

ですから、telnet でメールを送ったり、HTML を見たりするためのプロトコルには当然詳しくなるわけです....これプログラマとしては、全然ムダなことではありません。アクセスするためのフレームワーク的ライブラリ（httpClient でも JavaMail でも）を使う時に、やはり

プロトコルがどういうモノかよく判っていれば、ライブラリの構造にもカンが働く

わけで、これ結構重要なポイントじゃないか、と思いますよ。とはいえ、telnet 自体は Unix 系ＯＳは当然ながら Windows ですらちゃんと

そこにある

手放せないツールのわけです。で...やはりそう思ってる人がいるようで、例の「Make Things Talk」の中で、こういう風に書かれてました。泣けます。

（ssh と比較して）それでもこの本で telnet を使う理由は、その場面で使えるツールがそれしかないからだ。telnet は古い友達のようなものだ。決してイケメンではないかもしれないが、そいつはいつもあなたの隣にいてくれて、他の誰もがあなたを失望させる場合でも、ちゃんと仕事をしてくれるやつだとわかっているのだ。
（「Make Things Talk」邦訳p13）

こうまで言われたらホントに友達冥利に（というか、ツール冥利に）尽きる、というものでしょうね。

そういえば、ASCII アニメ（エスケープシーケンスで動かす奴）を見せる用途で、

<a href="telnet:user@host.domain">ASCIIアニメ見る？</a>

と telnet プロトコルのアンカーを HTML に埋め込んでたURLがありましたが、今でも

スターウォーズ（telnet://towel.blinkenlights.nl/ ＨＰ）そういえばコレ昔からあったもの。懐かしい...
サッカーワールドカップ 2006(telnet://ascii-wm.net:2006/　ＨＰ)　こっちはイマドキなもので、精度が凄いです。リアルでびっくり。

とかあるようです。そういう使い方もないわけじゃないですね（苦笑）。何かヘンなサービスをさせるのに、意外な使い方があるかもしれないですよ...

投稿者 : 杉浦　こずえ | 投稿日時 : 2008.12.11 20:52

Make Craft:

2008.12.10

あ、判ります？「Make Things Talk」があまりに面白かったこともあって、その母体である Make: の日本語版第５号（2008/9発行）を買いました...で、実はこの号、

Make: の（アチラでの）姉妹誌である、「Craft:」の特集

が大きなスペースを占めている号なんです。この「Craft:」については、この号でのCraft:関連記事の翻訳をされた野中モモ氏の「Lilmag Blog」のページが詳しいのですが、

加えて、『Make:』よりもソフトで審美的な手づくりを扱っている（女性向け、と言ってしまえば話は早いがそうは言いたくないのがLilmag）2006年創刊の姉妹誌『Craft:』が、雑誌内雑誌として本邦初登場。

というわけで、安易な

Make: ギジュツ科（ダンシ向け）
Craft: カテー科（ジョシ向け）

というようなフンベツをまとめて廃棄しちゃう...といったあたりが今回のテーマ、かな？

DIY(Do It Yourself) っていうと、日本だと「日曜大工」のシノニムに過ぎないけども、アメリカだとちょっと別なカゲキな DIY があるんです。知ってます？

それはですね、ガールズ・パンクとフェミに結びついたサブカルの世界での使い方で、要するに「何でも自分たちでやっちゃおう」という考え方で、自分たちで音楽レーベルを作り、自分たちのジャーナリズムとしての「（ファン）ジン」を自分たちで制作・流通させ...という、アングラだけどもカゲキで、しかもアメリカだと意外な影響力さえ持っていたりする....という、「カッコイイDIY」なんです（バンド的には BIKINI KILL とか...「riot grrrl」って呼ばれることもある運動です。よくまとまってる資料というと大垣有香氏「riot grrrlというムーブメント」(←ウェブにある...)に勝るものはないのでは？）。

どっちか言うと、Craft: のDIY はこういう「面白くてカッコイイ・サブカルなDIY」の色彩が強く出てます（アカラサマに政治的ではないですが...）。特にこの号で紹介されている「Gangsta WRAP」は、グラフィティ（落書き・タギング）のようでそうでない、街角のいろいろなモノに落書き...じゃなくて勝手に「編み物でカバーを作ってかぶせちゃう！」なんていうスレスレですけども、フェミでカゲキでアートな活動だったりします。

ですから、母体である Make: とどう違うか、というとそれは「男性向／女性向」というジェンダー分けでもマーケティングでもなくて、

「Make」に載るプロジェクトの場合、最終的にはその見た目よりも機能の面のほうが重要になるけれど、こちらは審美的な意味で魅力的であることが実用性ともども必須条件なのです。（「Craft:」編集長カーラ・シンクレアによる「Welcome」 p145）

要するに、トンガったボーイズもガールズも、みなギークなんです。テクノロジーと同時にロックで「自分で何でもやっつけてやろう！」というDIYの精神があれば、まだ世の中捨てたものじゃないわけですね。何となく今まで「Make:」は知ってても敬遠していたは失敗でした。反省。ちょい応援したくなってます..（というか、Make: Craft: を出版できちゃうオライリーのサブカル的底力は敬服に値します）

ちなみに Craft: 特集の目玉で、Arduino 関連でも注目されたのは、「プログラマブルなＬＥＤタンクトップ」という、ライフゲームのグライダーがタンクトップの上に格子状に並べられたＬＥＤのパターンで永遠に飛んでいく、というとっても「ハッカーらしい」ファッション（リア・ビクリー）だったりします。導電性の糸でミシンをかけちゃいますよ、カッコイイでしょ！

投稿者 : 杉浦　こずえ | 投稿日時 : 2008.12.10 23:55

USB とは汎用シリアルバス

2008.12.04

の略です。Arduino ネタの続きです。

でここらの最近の「やさしいマイコン」の特徴....というか、接続はみんな（イマドキ当然に）USB です。ハテ？と思って今自宅機の裏を眺めましたが、シリアルポート（いわゆるRS-232C）もうないですね（苦笑）。

USBというと、転送速度とか１２７台まで繋げるとか、ホットプラグできるとか、いろいろなメリットがあるわけですが、ここで重要なのは、

バスパワーを供給できる

という電気的な性格だったりするわけです。結構意外....かもしれないこととしては、実は USB は、

４本しかケーブルがない

という事実、知ってました？でバスパワーを供給しますから、２本は Vcc（＋5V）と GND(－）です。残り２本はペアになって動き、それぞれが信号に応じて＋側、－側に動き、パリティとして働くようになりますから、実際の信号伝達に使うのは、

事実上１本だけ

なんです（実は3.0ではこれが「上り下り」に増え、「全二重」になるようです）。でも「シリアル」ですから、それでイイんです。それより電源を供給しちゃって、

あまり電気を消費しないデバイスなら、特に電源を考えなくてもＯＫ

というのが、実はマイコンで何かする時にとってもうれしい仕様なんですよね。

しかし...というか、私は「Linux で動く」を基準にしてマシンをアセンブリしてましたから、世間よりも USB の採用が遅かったんです。要するに USB は

公的規格ではなくて、メーカー（コンパック・インテル・ＭＳ・NECなど）の共同規格

でしたから、２１世紀の初め頃は

Linux のサポートが薄い....

という状況が一時あったんです。それこそ

ゲイツＯＳでしか動かない悪魔のデバイス（この言い回しを使ってる実例）

なんて言い方した時期がありますしね。Linux では　2.3.x で対応が始まり、安定版では 2.4系カーネルでようやく使えるようになった...なんて事情があります。やはり Linux は「私的規格のサポートはどうしても弱い」という宿命があります（そりゃ仕様を公開してくれないと作業できないです）から...

とはいえですねぇ、11/18 に新しい USB3.0 の仕様が発表されたようです。対応デバイスの登場は来年末くらいだと予想されますが、Linux どうだろ（下位互換性はあるようです）。

そういえば以前（一応２１世紀だっけ）のマシンでトラブった対策で、大きいファイルを一晩かけてクロスケーブルでシリアル転送した記憶が蘇ります...通信速度は記憶してないですが、やたらと遅くて悪夢でした.....ふう。

投稿者 : 杉浦　こずえ | 投稿日時 : 2008.12.04 22:18

使い道もあるもんだ...

2008.12.01

というのは、Java 5 の新機能（遅ればせながらね）、static import です。地味だねえ...

要するに、クラス変数とかクラスメソッドが、クラス全部を import しなくても、「その変数だけ」で import できる機能です。こうやるだけですね。

import static jp.or.nurs.sug.Test.CONST_NO1;

とかね。そりゃ使えば使えちゃうモノだけど、

これを使うとホントに助かるコンテキスト

ってあるんだろうか、と結構？になっていたのですが、初めて、

あってよかった....

となった場面に遭遇しました。それはですね、

Constants という名前のクラスが、複数のパッケージにあって、双方とも static 変数を供給するためのクラスだったりします（ありがちな名前ですね）。ですから、両方を同時に import すると、クラス名がバッティングしてしまうので、じゃあ、両方とも FQCN で記述しないと....となるのですが、これが static import で回避できます。

import static sub2.Constants.ZERO; import sub1.Constants; public class Test { public static void main( String [] args ) { System.out.println( ZERO ); System.out.println( Constants.ONE ); } }

この時、最初の ZERO は、static import された sub2.Constants の ZERO を指し、２番目の ONE は sub1.Constants の ONE を指します。ですから、使う度合いの少ない方を、変数名名指しで static import すれば良いわけですね。

さらに面白いのはコレです。

public static void main( String [] args ) { System.out.println( ZERO ); System.out.println( Constants.ZERO ); }

ここで、最初の ZERO は static import された sub2.Constants.ZERO を、２番目の ZERO は普通に import された sub1.Constants.ZERO をうまく区別して指すか...というと指しました。ふう、うまく出来てます。static import は決して無駄じゃなかったですね！

もう少し背景に突っ込みましょうか。Java ではあまり強調されないことですが、実はクラス変数・クラスメソッドはまったくなしで済ますこと、というのはＯＯＰ言語では不可能なことじゃないのです。その場合どうやって数学関数とか import するのか....というと、実は

import なんてせずに、Math ライブラリ・クラスを継承しちゃう

というやり方をすればイイのです。勿論、クラス変数・クラスメソッドなしの世界を実現するためには、

多重継承ができないと、現実的ではない

のですけどね。言い換えると、static クラスを import して使う、ということは、

かなり弱いけども継承「のような」性格がある(static クラスを implements したらもう少し強いけども）

ことになります。クラス変数・クラスメソッドの場合、

インスタンスとは独立しており、上書き(override)はされずに、単純に隠蔽される

という仕様には、弱いながらも import や implements によって「多重継承みたいな」状況になったとしても、ホントの多重継承でややこしい問題になるいわゆる「名前の衝突」の問題に直面しなくても済む、というメリットがあったりするのです。

この多重継承で「名前の衝突」が起きた時、どっちかの名前を「改名」して衝突を回避する、っていう手法があります。自分の複数ある親クラスのメンバ名が偶然同じとき、どちらのクラスのメンバなのか区別できないので、それを継承の際のオプションとして「改名」しちゃう、という機能です。これは C++ にはないのですが、Eiffel にはあり（というかEiffel が参考にした非ＯＯＰＬである Ada にも、「パッケージの継承」の機能があるので、やはり「改名」があります...）、Meyer が「オブジェクト指向入門」（第１５章）で結構突っ込んだ議論をしてます。今遭遇した問題というのも、実はこういう「改名」が必要となるような「名前の衝突」の問題なんですよね。