lifeLOG + REPOsitory: 2010/08/29

2010-09-04

隠れたウィンドウは見えない、見えないウィンドウは存在しないも同然 #2

前回に引き続き、ウィンドウにおけるアプリケーションウィンドウの配置問題について。今回は、ユーザが行う工夫について考える。

前回の最後に書いたように、ウィンドウを重ならないようにするためにユーザが取り得る工夫は、おおよそ次の 3 つになる。

より大きな画面を手に入れる。
アプリ内で余分な情報は表示しないようにする。
ウィンドウを重ならないように並べる。

より大きな画面を手に入れる

たとえば、新しく iMac の購入を検討しているとする。現行の iMac (Mid 2010) には 21.5 インチと 27 インチの 2 つのモデルがある。予算が許すなら 27 インチの方を手に入れる。画素数でくらべて約 1.8 倍になる。あるいは、置き場所に余裕があるなら、iMac は小さいモデルを選択し、その代わり差額(約 5 万円)で 2 台目のディスプレイを購入するという手もある。

すでにパソコンがある場合はどうするか？ 2 台目のディスプレイをつなげることを検討しよう。すべての機種、モデルでそれができるわけではないが、もし可能なら(そして予算と置き場所が許せば)やってみるべきだ。画面の広さが 2 倍(以上)になる。

古くても良いから単体のディスプレイは捨てずに取っておき、新しいパソコン (iMac など) につなげてみると良い。CRT の頃、ディスプレイはとにかく場所を取ったものだが、液晶ディスプレイが普及してからは、机の上に 2 台のディスプレイを並べることも手軽にできるようになった。

物理的に画面を大きくできない場合は「仮想デスクトップ」を利用するという方法もある。Mac なら標準で利用できる機能だ。ただし、「仮想デスクトップ」は一度に見える領域が増えるわけではない。この機能は、むしろユーザが作業コンテキストを明確にするためにあるものだ。

作業コンテキストとは関連のある複数の作業から構成される作業場(ワークスペース)のようなもの。たとえば、twitter クライアントでタイムラインを眺めている時、誰かのツィートにある URL を開きたくなる。そのときブラウザはすぐそばにあるべきだろう。ブラウザでウェブを見ているときにツィートしたくなったなら、twitter クライアントがブラウザの横にあるとウレシイ。この 2 つがそばにあることで「情報探索とコミュニケーション」のための作業場が生まれる。

わたしはブログの記事を Emacs で書いている。自分が書いた記事もふくめて、あちこちのウェブページを参照することになるから、Emacs のすぐ右横には Safari が開いている。左横にはターミナルのウィンドウが 2 つ。記事のネタになるプログラムを走らせたり、man を参照したり(ウェブで見るより手軽)と、これも良く使う。Mail.app にはメモが置いてあるから、これも近くに開いておく。これらがわたしにとっての「ブログを書く」という作業場を構成している。

人は作業に集中すると、他のことが気にならなくなる。そして気にならない情報は見えていなくても良いのだ。むしろ、見えていると気が散って作業の邪魔になる。だから、複数のデスクトップを切り替えられる「仮想デスクトップ」は作業コンテキストの構築に適している。

twitter より (2010-09-03)

13:49 RT @hyuki: 本を書いていて切実に感じるのは、一日で出来ることは少ないということと、そのような毎日でも積み重ねていけばまとまった仕事になるということ。

2010-09-03

隠れたウィンドウは見えない、見えないウィンドウは存在しないも同然

今回のお題は、ウィンドウシステムにおけるアプリケーションウィンドウの配置問題。

なぜ、ウィンドウは重なるのか？

画面は資源、そして資源はいつも不足している

Mac を使っているのであれ、あるいは PC を使っているのであれ、(それが余程古いものでない限り)今のパソコンを使っているユーザの前では、その画面にいくつものウィンドウが開いていることだろう。ブラウザや iTunes を始めとして、twitter クライアントにメールクライアント、などなど。プログラマなら IDE あるいはエディタとターミナルなんかも加わるに違いない。

ここが肝心な点なんだが、それらいくつものウィンドウを広げるには、Mac や PC の画面はあまりにも小さい。それがノート型なら言うに及ばず、デスクトップ型で 20 インチ以上の画面を備えていたとしても十分とは言えない。

画面が小さい結果として、ウィンドウは互いに重なりあう。みな、それが必然だとわかっている。いくつものアプリを同時に立ち上げるためには避けられないのだ、と。誰もがこれを当たり前だと思っている。他に方法はないのだ、と。

まだ、画面は小さいのだろうか？

(一部の研究者を除いて)人々が初めてコンピュータの画面にウィンドウを見たのは 1984 年 1 月 24 日のことだ。それが備えていた 9 インチ、512 × 342 ピクセルの画面は 2010 年の感覚で見ると余りにも小さい。大きさで言えば iPad (9.7 インチ)に近く、画素数で言えば iPad (1024 x 768) の 1/4 以下だ。

あれから 26 年以上たってパソコンの画面も広大になった。いまどきのデスクトップ型なら 20 インチ以上、画素数も 1,920 × 1,080 (iMac 21' [Mid 2010]) 程度を備えるものはざらにある。最初の Macintosh の 4 倍の広さだ。さらに、2 台目のディスプレイをつなげることのできるものもある。そうなれば、画面の広さは倍増する。3 台目をつなげられるものはさすがに限られるが。

単純に考えると、4 倍の広さの画面には元のサイズのウィンドウを 4 つ、重なりあうことなく並べられるはず。ブラウザ、メールクライアント、twitter クライアントに iTunes、これで 4 つ。普段、使うアプリはこの程度に収まらないだろうか？もし、収まるなら、ウィンドウは重ならなくても良いはずだ。なぜ、まだ重なっているのだろう？

ウィンドウもコンテンツもでかくなった

この 26 年で起きたのは、画面の大型化だけじゃない。画面に収まるアプリのウィンドウも、ウィンドウに収まるコンテンツも大型化した。

メニューと比較的小さなツールパレットであとはすべてキャンバス、というアプリウィンドウの原型はもはや原型として十分ではない。ツールバーが生まれ、描画エリアはペインという名の領域に分割され、ツールパレットも大型化するか、そうでなければ分割された。とてもじゃないが、9 インチ、512 × 342 ピクセルには収まり切らない。

26 年前にウェブは存在していなかったけど、誕生以来、すでに 20 年近くが過ぎた(Wikipedia:ja によれば最初のウェブサーバの誕生は 1990 年末)。登場当時は幅 640 ピクセルに収まっていたウェブページも年々横長になり、今では 1000 ピクセルを超えるページも珍しくない。ページという概念を捨ててしまったために、縦に長くなる傾向はもっと大きい。

見えないのと見えるの、どっちが良い？

重なりあったウィンドウと重なることなく並んだウィンドウ、どちらが使いやすいかは考えるまでもない。隠れたウィンドウは見えない。見えないウィンドウに映し出された情報はユーザにとって利用できない情報だ。利用したければ隠れたウィンドウを表に出すしかない。しかし、そうすると別のウィンドウが隠れてしまい、別の情報が使えなくなってしまう。

twitter より (2010-09-02)

01:50 もう、ストーリミングが始まってる。Apple Special Event
01:53 わくわくしてきたゾ (｀・ω・´)
02:01 お、やっぱりウォズだったのか。
02:10 HDR すげえな。
02:20 iOS 4.2 for iPad は 11月。
02:30 新しい nano 良いなあ。容量が気になる。
02:31 うーん、8GB と 16GB か。
02:33 おお、retina の iPod touch きたーーーー
02:34 よっしゃ。ジャイロも搭載。
02:36 おお、発売は来週かよ。プリオーダーは今日から！
02:47 なんだよ、ジョブズ。マウスを使ってるじゃん。TrackPad 使えよ。
02:51 one more thing...
03:06 tv は日本じゃ関係ないからなあ。
03:08 iPad から ?tv にストリーミングできる(iOS 4.2)のは良いね。
03:17 nano も良いけど、iPhone 4 を持っていない身にとってはやはり iPod touch だよなあ。64G モデルで $399。でも、アップルジャパンは平気で 5万円を超える値段を付けてきそうだな。こんなに円高なんだけど……。
03:26 Apple Store 復帰している。new iPod touch 64GB で¥36,800.- 。円高が反映されているじゃないか (｀ΦωΦ´) ……なので、ポチりました。
03:26 出荷予定日は、2-3 週になってる……(´・ω・｀)。
20:12 RT @haifa310: iPad 版待ってました RT @touch_lab: Twitter公式アプリ、アップデートでiPadに対応 - http://bit.ly/9toXfL

2010-09-02

CSS スタイル定義の優先順位

Blogger のスタイルを変えたい

ここしばらく続けて、CSS のことを調べたり考えたり試したりしているのは、このブログのスタイルを変えたいから。Blogger でこれをやるには、ブログごとに XML で提供されているテンプレートを変更すれば良い。ただ、これが結構面倒なのだ。

なぜ、面倒なのか。まずはテンプレートになっている HTML/XML の構造が複雑なことがある。1 つのテンプレートで表紙から個別ページ、ラベルによる検索結果のページに対応することに加えて、ウェブ上でページ要素(サイドバーなどのコンテンツ)を追加できる等の機能にも対応している。さらに最新版ではテンプレートデザイナーと呼ばれるテンプレートの編集機能にまで対応した作りになっているためだ。

レイアウトを構成する要素のネストは深いく、一番シンプルなテンプレートでさえ、ブログコンテンツの p 要素と body 要素の間に 10 以上の(主に div 要素による)ネストができる。まあ、これは高機能化が複雑さを増すことの良い例ともいえる。

加えて、ユーザが手を出せないスタイルがリンクされることもある。XML のテンプレートを見ているだけではわからないが、実際のブログの HTML ソースを見ると Blogger が提供する CSS ファイルがリンクされていることがわかる。

もちろん、テンプレートにスタイルを記述すれば HTML に直接埋め込まれることになるため、Blogger 提供の外部 CSS の定義を上書きすることは可能だ。実際、これまでそうしてきたし、今回もそのつもりだった。だが、ときどき、この上書きが期待どおりに効果を表さないことがある。これはなぜなのか？

Safari の設定で「メニューバーに"開発"メニューを表示」を有効にしてやると、「Web インスペクタ」が使えるようになる(メニューから「開発」>「Web インスペクタを表示」を選ぶ)。この機能ではページの要素のネストの様子や、各要素に付けられたスタイルの一覧、さらにはスタイルの上書きされている様子も見ることができる。

この機能を使って、期待どおりに効果が表れないスタイルを調べていくうち、ただ単純に後に書かれているから優先になる、というわけではないことがわかってきた。

CSS における優先順位

(「World Wide Web Guide: 段階化の順序」より)
Cascading Style Sheets の Cascade とは順序立てられたリストのスタイルシートという意味から名付けられたもので、スタイルシートが段階的に継承していく働きを表しています。そして、順序立てられたリストの中で記述されている位置やセレクタの違いにより、段階化の順序（スタイル情報が反映される優先順位）は異なってきます。

ブラウザが仕様をどこまで厳密に実装しているかにもよるのだけど、CSS のスタイル定義ではセレクタの書き方によって優先順位が変わる。CSS では基本的に、後の定義が前の定義を上書きする。しかし、優先順位によっては後の定義よりも前のものの方が効果を表すこともある。たとえば、以下の記述の場合、header クラスの div にある h1 に対しては、後ろにある赤色の指定は前の灰色の指定を上書きできない。

(CSS スタイル定義サンプル)
 1: .header h1 { color: gray; }
 2: h1 { color: red }

twitter より (2010-09-01)

19:08 Cocoa Emacs (Emacs 23)がそれ以前のバージョンにくらべて優れている点、その1: 折り畳んで表示される長い行の中を上下にカーソルを移動させることができる。と、書いて伝わるかな？
19:12 コードは、通常、1行はそれほど長くはならないが、Emacsでは普通のテキストは意識して改行しない限り、1段落が長い1行になる。auto-fill を使えば勝手に改行してくれるけど、plain text以外ではこれも都合が悪かったりする。
19:14 そういえば、他のプラットフォームのEmacsではどうだったろう(Meadowとか)？少なくともCarbon Emacs PackageのEmacsでは、カーソルの上下は論理的な行ごとにしか動かせなかった。

2010-09-01

外部ファイルの置き場所としての Google App Engine

さて、前回(→ 外部ファイルの置き場所を求めて……)の記事では、外部 CSS ファイルの置き場所として Google App Engine (以下、GAE) にたどりつくまでを書いた。

GAE でやってみることにしたのは「静的なコンテンツを動的に生成しても良いじゃないか」と思いついたためだ。「なんとゼイタクな」とか「ムダなことを」なんていう声が頭の中を駆け巡りもしたが、現在のコンピュータ(とインターネット)にまつわる技術は、ある意味、計算と通信の資源を湯水のごとく使うことで発展してきたようなものだ。安価で(無料あるいはそれに近い価格で)提供される資源は、どんどん使うことが正義なのだ。ムーアの法則が成立する状況が続く限り「豊穣の時代」が続くのだ。いいじゃん、これぐらい。

「静的なコンテンツを動的に…」に思い至ったのは、コンテンツを要求する側(ブラウザ)にとっては HTTP の向こう側で何が起こっていても関係ないんだ、と気付いたから。ま、当たり前のことなんだけどね。

GAE アプリの作り方

GAE に登録

まずは、アカウントの登録。アカウント自体は Google アカウントだが、App Engine を使い始めるには携帯電話を使った認証が必要になる。具体的には、登録の際にロケーションと携帯電話のキャリアを選び、その SMS あるいは携帯電話用のメールアドレスを指定する。すると、携帯電話に認証コードがメールで送られてくる。そこに書かれたコードを登録画面で入力する、というものだ。

わたしの場合、iPhone のメールアドレス(i.softban.jp)を指定した。すぐに「Google App Engine Code」というタイトルのメールが送られてきた。中にあった 7 桁の番号を登録画面に入力して登録完了。

アプリケーション ID の登録

アカウント登録が完了したら、先にアプリケーション ID を登録してしまう方が良い。この ID を SDK でアプリケーション名として使うことになるからだ。また、この ID はそのままアプリの URL にもなる(独自ドメインを使う場合は別)。具体的には、helloworld という ID なら http://helloworld.appspot.com/ でこのアプリを開くことになる。

ID の登録は GAE の The Administration Console から行う。

アプリケーション ID は先着順。凡人がパッと思い付く程度の名前はもう大抵取られているよ。GAE を使う上で、ここが一番の難関かもよ(´・ω・｀)。

SDK をインストール

アプリの開発をするには SDK が必要で、Mac 版も用意されいる。ダウンロードした SDK のパッケージを開くと GoogleAppEngineLaucher.app がぽつんと入っている。これを /Applications にコピーすれば OK。

初回の起動時に、何やらコマンドラインのツールのシンボリックリンクを /usr/local/bin に作っても良いか、と確認してくる。OK を押せば確かに /usr/local/bin シンボリックリンクができている。おそらく、これは、ユーザが Terminal 上からも GAE Launcher の機能を使えるようにするための作業だろう。

初回起動時に現れる確認ダイアログ

シンボリックリンク張っても良い？	ここに張ったよ！

2010-08-31

外部ファイルの置き場所を求めて…

CSS によるスタイル定義を外部ファイルにしたい

Blogger には画像とブログ自体のテキスト以外のデータを置く場所がない。Google の提供する他のサービスにも汎用のデータファイルをウェブからアクセス可能な形で保持してくれるものはない。そう思ってきた。だから、このブログのスタイルを変えるときにもブログのテンプレート自体に埋め込むしかない、と。

外部 CSS ファイルを使いたい理由

もし、CSS によるスタイル定義を外部ファイルにしてどこかに置けるなら、iPad (や iPhone) 対応もブラウザのユーザエージェントで切り分ける方法を取れる。メディアクエリーを使い CSS の中で対応するよりも、(デバイスの特性値の組み合わせではなく)デバイス自体を判別するという点でスマートだ。また、デバイスごとのスタイル定義をすべて読み込む必要もなくなり、ロードするサイズも減る。iPhone に iPad 用や Mac 用のスタイルを読ませることもなくなるわけだ。

けど、Blogger には、そして Google にも、外部 CSS ファイルを置く場所はない。

Google 以外のサービスはどう？

もちろん、レンタルサーバを借りるという方法がある。月額がワンコインで足りるものもある。CSS ファイルを置く程度のことならそれで十分だ。ま、そこまでするなら Blogger にこだわる必要もなくなる。レンタルサーバ上で WordPress なんかに乗り換えれば、こんなことや(スタイルを変更するために) Blogger のテンプレートの構造で悩むこともなくなる。けど、やはりネットの向こう側のことでは Google にこだわりたいんだよね。

Amazon が提供するウェブサービスに S3 というサービスがある。正式名称を Amazon Simple Storage Service と言い、そのものずばりの「インターネット用のストレージサービス」だ。「インターネット上の」ではなく「インターネット用の」になっていることに注目。つまり、インターネット上で稼動するウェブサービスから使われることを前提としたストーレジなのだ。

ここに外部 CSS を置くことはできるだろうか？もう少し正確に言うと、S3 に入れたデータは HTTP 経由で公開アクセス可能なのだろうか？

(S3 公式サイト; Amazon S3 Functionarity より抜粋)
Authentication mechanisms are provided to ensure that data is kept secure from unauthorized access. Objects can be made private or public, and rights can be granted to specific users.

オブジェクト(ユーザが S3 に収めたデータをこう呼ぶようだ)は private にも、public にもできると書いてある。

(同上)
Built to be flexible so that protocol or functional layers can easily be added. The default download protocol is HTTP. A BitTorrent^TM protocol interface is provided to lower costs for high-scale distribution.

デフォルトのダウンロードプロトコルが HTTP だと書いてある。

ということで、(試していないから確実ではないが) HTTP でパブリックアクセスできるようだ。有料だけど、データのサイズと転送量が少量だから、びっくりする額になることはないだろう。レンタルサーバを借りるよりも(今まで経験したことがないから)おもしろそうだ。

とまあ、こんな流れで昨日まではすっかり、S3 を試すゾ、という気になっていた。今日、Google のあるサービスのことを思い出すまでは。

静的ファイルがダメなら、動的に作ってしまえば良い

何も CSS がファイルでなければならない理由はない。「ファイル」と呼んでいるものの、ブラウザにとって必要なのは HTTP リクエストに対して text/css で返されるデータストリームだ。サーバの HDD にファイルとして存在していようが、サーバ上のプログラムが生成したデータだろうが、ブラウザは気にしない。

静的な CSS ファイルを動的に生成してやれば良い。つまり、極端な例なら CSS のデータを文字列としてプログラムに埋め込んで、それを出力させれば良い、ってことだ。

これなら、Google のあのサービスが(きっと)使える。

2010-08-30

Cocoa Emacs を使ってみたい #2: SKK 自動ロードの仕組み

前回、SKK のインストールでつまづいていると書いた(→ Cocoa Emacs を使ってみたい)。いろいろと調べ(ググり)、あれこれ試して、ひとまず対処方法が決まった。

ちなみに、この記事は Cocoa Emacs (安定板) で書いている。

SKK インストールにおける問題点

「紹介マニア」に書かれている手順にしたがい SKK を ~/.emacs.d/lisp にインストールした。しかし、(Cocoa Emacs を再起動して)C-x C-j を叩いても SKK が起動しない。C-x C-j is undefined と出るばかり。どうも、SKK がロードされていない上に、load-path 上に見つからない様子だ(SKK を load-library でロードしようとするとわかる)。

~/.emacs.d/lisp は別にデフォルトで load-path に入っているわけではないらしい。実際、上述のページの作者が公開している初期化ファイルを見ると、このディレクトリを load-path に追加するコードがあった。

~/.emacs.d/lisp/{apel,skk} を load-path に追加すると、load-library で SKK を(手動で)ロードできるようになった。初期化ファイルで (require 'skk-autoloads) とやれば自動でロードできるようにもなった。

いや、でもまだおかしい。「紹介マニア」には「init.el に記述する必要はありません」と書かれているし、SKK (DDSKK 14.0.92) のマニュアルにも同様に書かれている。いったい、何が違うんだ？

SKK の自動ロードの仕組み

いろいろと調べた(ググった)結果、SKK が emacs の初期化ファイルの記述に関係なく自動ロードされるのは以下の仕組みであることがわかった。

emacs は normal-top-level という関数の中で、load-path に設定されたディレクトリ(とそのサブディレクトリ)から leim-list.el というファイルを探し、ロードする。
DDSKK は SKK のロードと基本的な設定を skk-setup.el というファイルに書き込み、これをロードするための (SKK専用の) leim-list.el を生成する。
DDSKK のインストーラは、上記 2 のファイルを(他のファイルとともに) インストールする。

よって、SKK の leim-list.el を normal-top-level が見つけてくれれば、めでたく SKK が自動ロードが実現する。問題は normal-top-level の実行されるタイミングだ。emacs の初期化ファイル読み込みよりも後なら、初期化ファイル中で load-path に追加したディレクトリも探索の対象になる。一方、初期化ファイル読み込みよりも前なら探索してくれない。試してみたところ、どうも後者らしい。

Cocoa Emacs に SKK を自動ロードするようにインストール

SKK が自動ロードされるためには、leim-list.el と skk-setup.el という 2 つのファイルが、デフォルトで load-path にふくまれているディレクトリに置かれていれば良い。

簡単かつ確実な方法は SKK (と APEL) を Emacs.app の中にインストールしてしまうことだ。

twitter より (2010-08-29)

13:37 日本人には「ノートブック」と「ノート」の区別はつかないんだよ。というか「ノートブック」なんて言葉は使ったことないよ。notebook の訳語は「ノート」であるべき。じゃ、note の訳語は？「メモ」とか「書き込み」がイメージに近いか？
13:39 一つ前の書き込みは Evernote クライアント(Mac) を使っていた思ったこと。翻訳って難しいねえ。

2010-08-29

Cocoa Emacs を使ってみたい

Cocoa Emacs って何？

(MacWiki - CocoaEmacs より)
Cocoa Emacs とは？

Mac OS X のウィンドウ環境で動作する開発バージョンの GNU Emacs（バージョン 23）の総称です。 Adrian Robert さんらが開発を進めてきた Emacs の GNUStep 用のコード（Emacs.app）が本家 GNU Emacs に取り込まれたもので、フロントエンドに Cocoa API を用いているため Cocoa Emacs あるいは Cocoa port と呼ばれています。 Emacs バージョン 22 の Mac OS X 版のコード（Carbon Emacs あるいは Carbon port ）は既に Cocoa Emacs に置き換えられており、 Carbon 版相当の完成度を目指して開発が進められています。

今のところ、Carbon Emacs のような決定版的なパッケージは今のところないらしい。

主要な情報源

ググって見つけたページがこの 2 つ。

[1] Emacs23 (Cocoa Emacs) 入門から中毒まで (紹介マニア)
[2] Cocoa Emacs 64bit版を作ってみる (年越しそばと初詣は絶対に欠かせない)

[1] の方は「入門から…」とあるように、安定板のビルドに始まり各種初期設定の内容までと幅広い。一方、[2] は(準オフィシャルな) Git リポジトリを使った開発版のビルドの方法だ。それぞれから、自分の使い方に合った部分を参考にして作業することになる。

twitter より (2010-08-28)

09:59 MobileMe の更新が近付いてきた。年間¥9,800.-は安いとは思えないん(とくに今年は円高だから)。が、iPhoneやiPad、そしてMacの間の同期の便利さ(何よりその設定がカンタン)は捨て難い。Mac間でMail.appのメモが同期するのも地味に便利。
12:35 「文化女中器」が「おそうじガール」になっていたとは！新訳も読んだのに気付かなかった。それにしてもこのロゴイラストは…。ルンバ(→ http://bit.ly/ai8s4o )に貼ってあったら売れ行き激増だと思うんだが。 → http://bit.ly/bMl9dX

登録: 投稿 (Atom)