この文書の諸情報
- この文書の永続的URI
- http://kuruman.org/diary/latest
- 公開日時
- 2008年12月15日 午前2時00分46秒
- 最終更新日時
- 2009年1月1日 午前0時36分59秒
- ヘルプ
- フィードバックについて
-
更新情報 - http://kuruman.org/diary/latest.rss
.
最近5日に投稿された全エントリー。
あ28す。
Operaのテッちゃんと冨田さんに対して行われたインタビューが思いの外面白かったので適当に引用しつつ書き留めておく。言うまでもなく、引用箇所をのぞいたすべてが僕の推測や憶測である。
蛇足だが、テッちゃんというOpera社最高責任者の愛称は本人のお墨付きである。
想像している未来は案外近いのだろうと感じさせる回答だった。
今後は、特に解像度が低いMID向けに最適化したようなものをベンダと協業していく方向
いずれにしてもPCよりも、まずデバイス
パソコンというただの汎用機にこれほど依存した社会は徐々に終焉を迎えて欲しい。そう願う僕としては応援せざるを得ない発言。尤も解像度に関してだけ言えば長期的には問題そのものが無くなるのでしょうけれど。
PCを持っているのは世界人口の20％に過ぎませんが、携帯電話端末は50％の人々が持っている
携帯電話端末って、思っている以上に普及しているんですね。なめてました。
高速化の議論の流れは、バイトコードではなく、ネイティブコードに落とす方向です。ただ、インテル向けはいいのですが、ケータイなどARMアーキテクチャを考えると移植しないといけないので、まだ分かりません。パフォーマンスは上がるので選択肢として考えていますが。
ARMあたりでもネイティブコードに落とす方向で考えるあたりいいなぁと思った。
はじめに断っておく。僕はRIAプラットフォームとしてHTML 5は不適当この上ないと思っている。若干の偏見を込めた表現だが、HTML 5は、ページベースの文書をマークアップするために最適化し、なんとかして既存のHTML文書リソースを生かせるようにアクセシビリティ確保を試みつつ、ユーザエージェント間の細かな挙動の差異を取り除こうとする取り組みだ。文書をマークアップするために最適化している以上、アプリケーションをマークアップするために最適化されることはあり得ない。はっきり言ってこんな言語で毎度毎度アプリケーションをマークアップさせられるというのであれば不幸なんて物ではない。と、そう思っている。ネットワーク環境が整い、Webアプリケーションだけに頼るなで述べたようなことが過去のことになった時には、文書向けのマークアップ言語とは別に何らかの適切な言語があってしかるべきだ。体裁を整えるためにCSSが使われることはあるかもしれない。だが、HTML 5を使うというのはアクセシビリティ面で足かせを課すだけにしか思えない。蛇足だが、ChromeがWebKitを採用したのもこのあたりが理由だと思っている。長期的に見たらページベースの文書で人間が処理する情報より、アプリケーションとして処理される情報の方が多くなるのは自明であり、そうあるべきだ。
……で、このインタビューでもRIAプラットフォームとしてのHTML 5という話が出てくる。
- インタビューア
- RIAプラットフォームとして考えると、HTML5は、まだ開発途上で使えません。Webブラウザでのサポートも進んでいません。例えば現状で映像を扱うとなれば、SilverlightやAIRになると思いますが。
- テッツナー
- Silverlightのような独自技術を使うと幅広いユーザーにリーチできません。少なくともマイクロソフトがSilverlightを提供するプラットフォームにしかリーチできません。まだSilverlightは、多くのプラットフォームでサポートされていませんし、普及もしていません。テレビやモバイル環境はどうですか？ Webの技術を使えばより広い層にリーチできます。Flashはデスクトップなら90％以上の普及率かもしれませんが、モバイルでは？
- プロプライエタリな（独自の）技術を使うと、その技術にロックインされてしまいます。ActiveXがいい例です。私が知る限り、ActiveXが広く使われている国が1つだけあります。韓国です。悪いことに、彼らはIE6の世界に閉じこめられています。IE7ですらありません。なぜなら、セキュリティ上の理由からIE7以降でActiveXを使うのは難しくなっているからです。
- 私が指摘したいのは、オープンな選択肢があるときに、そうでないものを使う理由はないということです。
テッちゃんはRIAプラットフォームとしてHTML 5が適当であるという発言はしていない。単にプロプラエタリな技術よりは良い、としか述べていないのだ。
- インタビューア
- HTML5のvideoタグはコーデックについては規程がありませんよね。ライセンスフリーの動画用コーデック「Theora」を採用するという話もありましたが、見送られました。互換性が心配です。W3Cの加盟企業の中にはコーデックを自社開発しているところもあるので、話が複雑です。
- 冨田
- そこはまだ結論が出ていませんが、いずれにしてもオープンスタンダードで成り立つWebの世界が、RIA開発プラットフォームになれるのかが問われていて、そこが主戦場になるのかなと思っています。SilverlightやAIRが主流のRIAプラットフォームになってしまうと、今まで10年かけて培ってきたものが阻害されてしまう危険があります。
- AIRやSilverlightのようなものがプラットフォームになると、それなしでアプリケーションやサービスが使えないという状況になってしまいます。テレビはどうする、ケータイはどうするとなったとき、プラグインがないから再生できませんということが起こり得ます。
- ブラウザベンダが協力して、オープンスタンダードによって互換性を保ちながらRIAプラットフォームを実現していく必要があります。互換性を保ちつつ開発者のみなさんが求めるようなRIAプラットフォームになれるかどうか、それはHTML5に向けてわれわれブラウザベンダがやっていかなければいけないことです。
と思って読み進めていくと冨田さんの発言がちょっと微妙なところだったりする。尤もインタビューアの質問自体、HTML 5とRIAに関する質問ではないし、深読みしても仕方ないのだけれど。
例えば、Operaの平均的ユーザーは起動時に20個のタブを開くというデータがあります。
これにはとりあえず笑った。とりあえず開きっぱなしなんだよ。昔誰が50枚もタブを開くんだ、なんて怒られたことがあったけれど、まぁ普通に開くんですよね。こればっかりはたぶん伝わらないと思う。そういう風にデザインされたソフトウェアを使わない限り。何が言いたいかというと僕みたいな変な人間はこういった統計結果が出ていることに安心感を覚えることができたんだよ、ということ。……違うけど。
- インタビューア
- Chromeには……(中略)……賢いスピードダイヤル機能など新しいアイデアがたくさんがあります。こうしたものをOperaで取り入れる予定はありますか？
- テッツナー
- われわれの考えでは、いつも同じ場所に同じアイコンがあるほうが、ユーザーの行動に合っていると思います。脳がパターンを認知する仕方からしても予測可能性があるほうが使いやすいはずだからです。
これ、昔僕も書いたなぁと思って検索してみたところ、案の定OperaのスピードダイヤルとFirefoxの拡張機能Speed Dialの記事中でちらりと書いていた。
Operaのスピードダイヤルはあくまでも3×3のマトリクス表示を頑なに意識し、サムネイルの表示場所で覚えさせようとしているように思える。
すべての物は何らかの意図を持って作成されているし、デザインされている。ぱっと見るとChromeの動的なスピードダイヤルは賢く見えるかもしれないし、人によってはそれによってリコメンドされるのを見て便利だと感じる。一方、Operaの固定されたスピードダイヤルではマウスを適当に動かすだけでいつものサイトにアクセスできる。どちらを取るかにその制作者の意図が感じられるというわけだ。
Safari 3やChromeで使用されているKHTMLはacceptヘッダでapplication/xhtml+xmlを要求してくるにもかかわらずxml-stylesheet処理命令による代替スタイルシート指定を無視し、すべてのスタイルシートを適用する。このページはそれらの環境で盛大に崩れていたのだが、Chromeの登場に伴いなにやらあまり無視できないシェアになってきた、らしい。一応読めるので放置してきたが、今日限りでUser-AgentヘッダにKHTMLを含む環境に対してはapplication/xhtml+xmlの優先度がtext/htmlより高い場合においてもそれを無視してtext/htmlを返すよう変更した。
AcceptヘッダをみてHTML4.01若しくはXHTML1.1っぽいXML複合文書を出力する事にして、自らXMLを選択するようなUAはきっとスタイルシートの実装が進んでいるはずだ、という事にしている。一応末尾に拡張子html, xhtml, atom, rdfを付加するとそれっぽい形式で帰ってくるという事になっているはずだけれど、上手く動いているのかは不透明。
という仕様は変わっていないため、URIの末尾に拡張子として.xhtmlを付けることでどのように崩れるか確認できる。
nanto_viさんによるとこのバグはWebKitのバグであり、Safari 4では修正される見込み
なのでそうです。情報ありがとうございました。
2002年11月。この時から変わっていない文面がある。
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
これはOpera Mailの署名として初期状態で設定されている文面だ。Opera 7でメール機能が刷新され、M2(現在のOpera Mail)が搭載された2002年から今まで6年間、文言に変更はない。頑なにrevolutionary e-mail client、つまり革新的メールクライアント
であると謳っている。そして、まんざら嘘でもない。他のクライアントに進化がなさ過ぎるのだ。
当時Opera Mailが革新的であると称したのは、アドレス帳とメールクライアントが完全に連携しており、すべてがタグによって整理され、必要なタグを最初から提示している点であろうと思う。このあたりの詳しい解説はあまり知らないが、先日書いたフォルダとタグに関する図解にある図で多少はイメージがつかめるかもしれない。Operaだってこれほど長きにわたって革新性を維持できるとは、夢にも思わなかったことだろう。
アプリケーションに限らず、道具の選択は重要であり、難しい。選択した結果が、時には作業効率をあげ、時には健康を守り、時には心の充足を与えてくれる。触れる時間が長い道具からは、より大きな影響を受ける。
たとえば椅子、ワーキングチェアについて考えてみよう。デスクワークであれば座っている時間すべて付き合うことになる大切な道具だ。立ち上がる機会が多いのであれば、椅子が回転しないだけで相当の時間を無駄にするだろうし、ストレス要因にもなるだろう。これは非常にわかりやすい例だ。だが、ワーキングチェアには前傾姿勢に最適化されたものや後継姿勢に最適化されたもの、ヘッドレストの付いたもの、足に負荷が掛からないように座面を成形したものなど、挙げればきりのないほど多くの取り組みが考えられ、製品が発売されている。短時間で気づくことの出来る要素だけではない。長く座らなければ分からないこともある。そして、個人個人で身体も違えば感覚も違う。人の意見をすべて鵜呑みに出来るわけではない。
椅子が想像しにくければ枕を想像するのも良いだろう。オーダーメイドの枕では高い睡眠の質が得られるという話を聞いたことがある人も多いのではないだろうか。尤も枕の場合は採寸によってある程度最適な物を絞り込むことが出来るのだが。
長い時間使う物ほど、長い時間かけて評価したい。しかし、長い時間をかけるがために多くを比較できない。長い時間使う物ほど選択が重要であるにもかかわらず。
メールに費やす時間は長い。空き時間に処理することが出来る、送受信内容を記録することが出来る、比較的手軽に複数人で同じ情報を共有できる……などといった利点があるからだろうか。理由は定かでないが、決して少なくない時間をメールクライアントに費やしている。この効率を高めることが出来れば生活時間を有意義に使えるようになるだろう。
以前も述べたとおり、不可避の理由がない限りは手元のコンピュータで動作するクライアントを使いたい。長い時間触れるものだからこそ、出来うる限り効率を追求したい。使い勝手の良い物を使いたい。手間を省きたい。
今現在、メールクライアントは比較的重要なアプリケーションの一つだと思う。が、変化がない。6年前のメールクライアントが未だに革新的と謳っても何ら違和感を感じさせない程度に、変化がない。
Webブラウザが持つローカルなブックマーク機能はかつてほど利用されることがなくなりつつあり、Web検索の重要性が増している。それに伴い検索ダイアログを標準で持つようになるなど、適応する形で変化してきた。が、メールクライアントにはそれがない。ブラウザに限らず、コンピュータ上に保存されたファイルだってそうだ。従来のフォルダ管理もしぶとく生き残ってはいる物の、検索フォルダやデスクトップ検索の利用例も増えてきている。コンピュータの高性能化に伴って整理する時代から探す時代へ進んでいるのであれば、メールクライアントもそうなるべきではないだろうか。
しかし、フォルダ管理の柵から逃れられないクライアントはあまりに多い。ユーザに何らかのアクションを求めるクライアントがほとんどだ。検索フォルダくらい私の使っているクライアントにも有る……そう言う人がいるかもしれない。実際、ThunderbirdやMail.Appには同様の機能が搭載されている。Gmailでフィルタとラベルを上手く組み合わせることでも同様のことが実現できるだろう。だが、これらは探すために検索フォルダを用意するという手間を要する。……当然じゃないか、と思った人が多いかもしれない。しかし、ローカルに保存されたファイルやWeb上のテキストと異なり、メールクライアントはテキスト以外の情報を多く活用することが出来る。すぐに思いつく物を以下に挙げよう。
あるメールクライアントでは、メールを受け取ったときにその送信者との過去のやりとりを調べるためにいちいち検索しなくてはならない。あるメールクライアントでは、メーリングリストを新たに購読するたびにそのフィルタリングルールをいちいち定義してやらなくてはならない。あるメールクライアントでは、添付ファイルがあるか無いかと言った単純な絞り込みすら許されない。あるメールクライアントでは、よく使われるメーリングリストシステムで使用されるコマンドを利用者が暗記していなくてはならない。あるメールクライアントは、迷惑メールを自動学習するのに、他のフォルダへの仕分けは自動学習できない。挙げだしたらきりがないが、メールクライアントが進歩する余地はあまりに大きい。ここには敢えてメールの整理の観点から見た要素しか挙げなかったが、たとえば昨年Shurikenが搭載したフォルダウォッチなどはメールの斜め読み環境を改善する一つの提案だろう。(補註: 残念ながら手元にはShuriken 2007しか無いため、実際にどのような使い勝手が実現されているのかまだ体験できていない。)
私が最終的に使うことにしたメールクライアントはOpera MailとShurikenだ。昔からOpera Mailを使い続けているのだが、メールクライアントをきちんと比較することも必要だろうと最近いくつかのメールクライアントを短期間使用し、比較的相性が良さそうだと感じたShurikenをここ数ヶ月併用している。まだどちらが私に合っているか判断できる段階にはないと感じているが、間違いなくいえることがある。Opera Mailは探してくれるメールクライアントであり、Shurikenは探すために整理するメールクライアントだ。
それぞれのアプリケーションが目指す物も、想定する利用者も違う。従って一概にどれがよいとはいえない。理想の形も一つではないだろう。しかし、あまりにも変化がなさ過ぎると思うのだ。不十分この上ないにもかかわらず。
メールクライアントの数は決して少なくない。Wikipediaの一覧によれば現時点で40強のメールクライアントが一覧されている。この中には開発が停止している物や、常用するのが非現実的な物も含まれているが、選択肢が多いことには気づくことが出来ると思う。
しかしこれだけの数があるにもかかわらず、それらのメールクライアントをきちんと比較する機会に恵まれることも少なければ、比較したことがある人も少ないのではないだろうか。最近会う人会う人にメールクライアントの選択理由を訊いてみるのだが、かつてのWebブラウザがそうであったようにはっきりとした理由を持って選択している人は少ないというのが現状のように思う。
今使っているメールクライアントを選択した理由をはっきりと述べることが出来るだろうか。そうでないならば、一度メールクライアントを選択する機会を設けることをおすすめしたい。……と言いたいところだが、残念ながら選択する機会を設けることが難しいのは前に述べたとおりである。ここは一つ、開発者の方々に革新的なメールクライアントの提案を期待したいところだ。
ソーシャルブックマークなどで受けたフィードバックについても取り上げておく。
メールかー。フォーマットに拘らないコミュニケーションクライアントが欲しいよ。
現状のメールは機能的にも貧弱であるのは確かですし、早いところ無くなって欲しいと思う気持ちも少なからずあります。たとえば活字ベースのコミュニケーション以外も参照しつつ管理できるようなコミュニケーションクライアントが欲しいと思います。が、大変残念なことに当面の間は既存のメールとお付き合いせねばならないわけで、その環境を改善したいという気持ちもまた大きいのです。
すでにメール事態が革新的じゃないからなあ
電子メールの仕組み自体が古びた物になっているのは確かですが、それを扱うアプリケーションが革新的であるべきという主張とは全く関係がないのではないでしょうか。
メール処理の一番効率的な方法は「読まないこと」だと思っているので、それを支援してくれるメーラーを要求する。
全く持って同意します。全く読まずに捨てるメールを即時に判別し、件名だけ読んで捨てるメールを可能な限り増やすことで効率化が進められるでしょう。そして、そのために最適化されたインタフェースは次世代のコミュニケーションツールにとっても参考になる物だろうと思うのです。次世代コミュニケーションツールがどのような物になるかは分かりませんから、もしかするとあまりに革新的すぎて僕の思っているようなことは全く的外れかもしれないですが。
もし、リアルタイム性を持った、例えばIMなどが、今の電子メールの役割の一部を果たすようになるのであれば、メールクライアントを改善する取り組みは効果を上げるでしょう。今以上にメッセージの数が増えてしまい、件名が消えうるのですから。携帯電話からのメールが普及するに伴い、幸か不幸か件名のないメッセージを受信する機会は増えつつありますし。
MacのMail.appは革新的とまではいかないけど，メールの文面から電話番号や住所，日時などを自動認識して，アドレス帳やスケジューラへの登録をサポートするなど半歩先を行ってると思う
大変申し訳ないのですが、その程度では半歩も先に行っていないように思います。事実Windows Mobile上で動作するメールクライアントにも同様の機能がありますし。
もちろんメールの文面からの自動認識自体は一つのアプローチだと思います。他にも添付忘れを指摘する機能などが考えられ、これは少なくともShurikenに搭載されています。これも誤送信を減らすことが出来、結果として効率を高めることにつながるでしょう。
ただし僕がこのエントリーを通じて暗に求めているのは、大量のメールを処理し、まとめ、管理する上でのツールとしてのメールクライアントの機能です。その面においてMail.appはOpera Mailに対して何歩か後れを取っているのではないかと推測しました。(補註: 例としてあげた機能の大半はOpera Mailで実現されています。)Mac OS Xの標準アプリケーション同士が連携に強いのは確かですので、おそらく便利なのだろうとは思いますし、トータルで見ると効率的だと感じるのでしょう。私にはこれ以上分かりかねる部分です。
ちなみに参考までに書き添えておきますと、ここしばらく私はアドレス帳に登録するというフローをした記憶がありません。自動登録で事足りているのです。適当に入れて補完され、正しく送信できればそれで良い。ごく稀に探せない人が生じますが、その時には用意された他の手段でその人のメールを探し、私に分かる名前に置き換えています。毎回登録するよりその方が遙かに効率的と感じています。アプローチこそ違いますが、何もせずに探していることに変わり有りませんから。
一応来春 Thunderbird 3 来るけどね…。その頃には、GMail + ガジェットによる拡張機能で全てのニーズが回収され始める気がする。／そもそもバックアップやフィルタリングが面倒なメールをローカルに置いておくという発想が
Thunderbird 3がどの程度革新的になるのか私には分かりませんが、スケジュール機能を搭載してOutlookと同等の機能を有することになる程度であればまだまだ不十分だろうと思います。どの程度斬新な拡張機能が提供されるかにかかっているのでしょう。そのような機能はおそらく本体に取り込まれてゆくでしょうから。
Webメールは確かに便利ですが、すべてがWeb上で管理されるようになるのは数年後といった短いスパンではないのではないかと思います。もちろんそのウェイトは徐々に増えていくと思います。バックアップや最低限のフィルタリングまですべてをローカルでまかなう必要はないでしょう。
しかし今のところ、そしてしばらくの間Webアプリケーションは最適の選択とはいえません。さらに別の理由、たとえばセキュリティ保護などのために、ローカルで完結せざるを得ない環境に置かれる人も、しばらく残り続ける可能性があります。メールクライアントの選択機会や選択肢が増えることは、必要とされうる可能性が考えられる以上、今しばらく必要不可欠なものだろうと思います。
現在当該サーバは復旧しており、下記の情報は無用の物となっている。
Let'snoteのホットキーを使うためのドライバ、pcc-acpiを導入するまでのメモ。
tmatsuuさんのpcc-acpi-0.8.4向けebuildが使用しているLinux Hotkey driver for Panasonic Let's Note Lightへここ数日つながらない。さて、どうやってホットキーを使ったものか。
同サイトでは最新版としてpcc-acpi-0.9-hy20081022.tar.gzを公開している。サーバにつながるにしても修正は少なからず必要。
今やHotkeyの取得はPanasonic Hotkey driverがなくてもカーネルのCONFIG_ACPI_VIDEOがあれば可能。acpidでちょこちょこっと書けばHotkeyによる明るさ調整もすぐ実装できる。
……と、同じくtmatsuuさんのページにあるのを発見。CONFIG_ACPI_VIDEO=yとしてカーネルを作り直して再起動。sudo acpi_listenして取得できるか確認してみるものの、取得できず。.configファイルを見てみると、なぜかCONFIG_ACPI_VIDEO=mになっている。よくわからない。
さらに情報をあさってみるとどうやらVineLinuxやSUSEではPanasonic Hotkey Driverにパッチを当てたパッケージを提供しているらしい。とりあえず試すべく読み進めると、同ページのコメントにてその差分ファイルが提供されていた。
結論から言えば、このパッチを当てればうまくコンパイルできる。makeする際に一つ警告が残るが、一応動いているようなのでとりあえずは気にしないことにする。
……と、導入し終わってから、ふとebuildファイルの存在を思い出した。とりあえず見よう見まねで作ったら動いたので書き留めておく。大変怪しいので、使うべきではない。
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
inherit linux-mod
DESCRIPTION="Panasonic Hotkey Driver"
HOMEPAGE="http://www.da-cha.jp/letsnote"
SRC_URI="http://www.da-cha.jp/files/${PN}-${PV}.tar.bz2"
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~x86"
DEPEND=">=virtual/linux-sources-2.6.23"
RDEPEND="${DEPEND}
sys-power/acpid"
S="${WORKDIR}/${MY_P}"
MODULE_NAMES="pcc_acpi(extra:)"
BUILD_TARGETS="default"
src_unpack() {
unpack ${A}
cd ${S}
wget http://lawnjam.com/r4/pcc_acpi.diff
epatch pcc_acpi.diff
}
src_install() {
linux-mod_src_install
dohtml readme.html
}