2010-09-11

直感的って何だろう?

(グラフィカルユーザインタフェース - Wikipedia より)
グラフィカルユーザインタフェースは、視認性、操作性に優れ、直感的な操作が可能なため、広く普及し、現在では主流のインタフェースになっている。

「直感的」と言う言葉(英語では intuitive)は、初代 Macintosh の登場以来、GUI に対して代名詞的に使われるようになった。GUI であれば直感的、直感的なインタフェースは GUI だ、と言うように。

ただし、GUI が直感的であるのは、それ以前の GUI ではない(GUI と対比して CUI と呼ばれる)コンピュータシステムとの比較においてだ。いくらデスクトップと呼んでみたところで、9 インチのモノクロの画面に表示される「絵」を現実の机と思い込むことはできなかったはず。メタファとは、あらかじめそうだと教えてもらわなければ、関連性を理解できないものだ。

また、Macintosh が当時の他のコンピュータと比較して使いやすいと言われたのは、そもそも使いやすくなるように設計されたものだったからだ。GUI やマウスを備えていたから使いやすくなったわけじゃない。使いやすくする手段(の一部)として GUI やマウスを採用したのだ。

ところが、いつからか本末が逆転するようになっていく。GUI は (CUI より) 直感的、GUI (を備えた Mac)は使いやすい、だから、直感的なインタフェースは使いやすい。論理の飛躍が生まれた。いや、飛躍というより横滑りというべきか。

しかし、本来、「直感的」と「使いやすさ」は別のことを指すはず。

訓練しなければ使えません

確かに、Mac 以前のコンピュータはユーザを選ぶものであった。利用するために特別な訓練を必要とするものだった。けれど、利用に特別な訓練を必要とするという事実と、使いにくいという印象は同じことを意味するわけではない。

たとえば、クルマの運転は法律の上からも、安全という観点からも、特別な訓練を必要とする。だからといって、クルマを使いにくいと言うヒトはいない。クルマの運転が難しいと言う場合も「そう感じる」という事実を単純に表明しているだけで、「もっと簡単にできるはずのことが、道具の作り方が悪いせいでことさら難しくなっている」などといった意味が込められてはいない。

また、当時のコンピュータは(現在の基準からすれば)非力な割に高価な機械であって、ユーザの便益のために割く処理能力の余裕はなかったのだ。だから、訓練によってヒトが機械に近づかなければならなかったのだ。

論理ではなく感覚による把握

言葉の定義からすると、直感とは、推理や考察によるのではなく感覚によって物事をとらえること、だと言う。もう少し噛み砕くと、問題となる状況を見たとき理由はわからないけど答えが思い浮かぶ、そういう状況と言える。なぜそうなるのか、どうしてこれが正しいのか、そのロジックはわからない。だけど、答えはコレだとわかる。それが直感だ。脳内で起きるパターン認識だと言っても良い。

では、なぜ「パッと見ただけで、どう操作すれば良いのかがわかる」のだろう?

それは、過去に、似たような何かを操作する、という経験をしたことがあるから。いま、目の前にある様子が過去に経験した別の何かと似ているために、過去にした行動をいままた適用すれば望む結果が得られる、と判断するわけだ。

ボタンのように見えるモノを見たら押せるに違いないと思う。ハンドルのように見えるモノがそこにあれば、回せるはずだと思う。それが直感だ。

デジタルなモノをアナログな物に似せて作る

われわれは生まれてからずっと様々な物に囲まれて暮らしている。日々の暮らしの中で、周囲にある物に対する働きかけの方法を学んでいる。ボタンは押すし、ハンドルは回す。誰かに教えられることもあれば、試行錯誤の中で適切な方法を身に付けることもある。

もし、デジタルなモノが、われわれが慣れ親しんだアナログな世界の物に良く似ていたら、われわれはモノの利用の仕方を改めて学ばなくても良い。ボタンに見えるモノは押すし、ハンドルっぽいモノは回す。特別な訓練は必要ない。

ただし、外見が似ているだけではダメだ。振る舞いも同様になるように作られていなければならない。デジタルなボタンを押すのではなく回すように作ったり、ハンドルを決して回らないように作ってしまっては、ユーザから文句が来るだろう。「直感的ではない」、と。

デジタルなモノをデジタルなモノに似せて作る

われわれの暮らしの中にデジタルなモノが入り込むようになれば、日々の暮らしの中でデジタルなモノの振る舞いにも慣れてくる。ファミコンでドラクエや FF の操作に慣れた子どもたちは、階層化されたメニューをたどることに対して特別な説明を必要としないだろう。

アナログな物であれ、デジタルなモノであれ、ユーザが十分に慣れ親しんでいるのであれば、それに似せることで「直感的に」操作可能なシステムを作ることができる。「○○のように見えるモノ」が「○○のように振る舞う」とき、ユーザは直感的だと感じるのだ。

つまるところ、「直感的」は、ユーザが熟知している既存のシステムを模倣することによって生み出される、ユーザの脳内に生まれる認識のショートカット(近道)なのだ。

「直感的で使いやすい」って本当?

上述の議論で「直感的」については少しわかった。では「使いやすい」はどうだろう? ユーザはどんなときに「使いやすい」と感じるのだろう? それは「わかりやすい」とか「覚えやすい」と似ているのだろうか? それとも全然、別のことか?

「使いやすい」という特性は、より根源的な他の特性に分解できるのだろうか? もっと言えば、あなたの「使いやすい」は、わたしの「使いやすい」と同じなのだろうか? もし同じなら、わたしにとって「使いやすい」システムを作れば、あなたや彼や彼女にとっても「使いやすい」ものになるはず。一方、もし異なるなら、どうすればあなたの「使いやすい」を知ることができるのだろう?

関連リンク

関連記事

twitter より (2010-09-10)

  • 08:07  うぉー、なんかスゲェ。手のひらに乗るコンピュータか。って感心した後にふと思った。iPhone もそうじゃん、って。→ http://jp.makezine.com/blog/2010/09/chumby_hacker_boards.html
  • 08:09  古い iPhone (や iPod touch) を差して自宅サーバにできるようなドックとか発売されないかな。
  • 08:42  この iPad スタンド、たったいま Amazon で発注した。買っといて言うのもなんだけど、こういうものを必要に感じてしまうところが iPad の弱点だよな。→ http://www.ideaxidea.com/archives/2010/09/xstand.html
  • 08:47  前にも書いたけど、iPad は画面への映り込みのせいで机の上などに水平に置いて使うことが難しい。やはり、画素数そのままで(増える分には文句はない)サイズを小さくしたモデルを出してほしいよ。軽くなるなら小さくなくても良いゾ。 → http://bit.ly/arTYR0
  • 08:57  カッコイイな、コレ。→ http://www.cultofmac.com/groves-bamboo-iphone-case-is-a-work-of-art-review/57347
  • 16:39  Google Instant、おもしろいわ。co.jp からはまだ使えないけど、.com からなら日本語でも Instant な検索になる。suggest と組み合わせたところが秀逸なアイデアかもな。検索語の候補を矢印で切り替えると結果もリアルタイムで切り替わる。いいわ、これ。
Powered by twtr2src.

2010-09-10

ヘッドレスの Mac mini で Time Machine を開けない

Mac mini で、あるフォルダをうっかり削除してしまった。iMac から SSH 経由で rm -rf したから、ゴミ箱にも残っていない。どうしよう? iMac にコピーが残っているから、そこから戻すか。いや、待てよ。Mac には Time Machine があるじゃないか。消す前の時点に戻れば、そこにそっくり丸ごとあるはずだ。

ところで、iMac がやってきて以来、Mac mini はヘッドレス状態で運用している。つまり、キーボードやマウス、それにディスプレイはつないでいない。一般的なファイルなんかの操作は SSH 経由で行えるし、サーバの管理は「サーバ管理.app」でできる。けれど、Time Machine はそのどちらの方法でも操作できない。なので、iMac から「画面共有」で接続し、ログインして Time Machine を開こうとした。「画面共有」ならローカルにディスプレイとキーボード、マウスがつながっているときと同様に操作できる。

ところが、ここで問題発生。

通常、Time Machine を起動すると、渦巻銀河を背景に Finder が無数に並んだ画面が現れる。それぞれの Finder が過去のある時点を表している。Finder の列を後ろにたどっていくと、過去に戻れるわけだ。

それなのに、今日の mini では背景が渦巻銀河に変わりもしないし、無数の Finder の列も現れない。それどころか、画面がフリーズしたかのように見える。Dock もメニューもウィンドウも反応しない。

実際にはフリーズしたわけではなかった。どうやら、画面こそ通常のままだが、操作環境は Time Machine モードになっていたらしい。Finder の列は出てきていないが、画面の中央には Finder のウィンドウが表示されていて、こいつだけは操作を受け付ける。このウィンドウを閉じれば(左上の赤いクローズボタンを押す)、Time Machine モードが解除され、常態に復帰する。

ヘッドレスが原因

フリーズではないとわかって一安心したが、これでは Time Machine が使えない。しょっちゅう使う機能ではないが、使えないのは気に入らない。調べて(ググって)みたところ、原因は mini にディスプレイが接続されていないことだとわかった。詳しくは以下を参照。

画面共有越しでのTime Machine (Apple Discussion - Japan)

解決策は単純。ディスプレイをつなげば良い。幸い、ウチの環境では mini のすぐ横に液晶ディスプレイが置かれている(MacBook がつながっている)。2 系統の入力を持ったものなので、(MacBook の他)もう 1 台のコンピュータをつなぐことができる。早速、DVI ケーブルを探し出し、mini の箱からディスプレイポートと DVI を変換するコネクタも引っぱり出してきて、mini とディスプレイを接続した。

その後はどうしたか? キーボードとマウスもつないだか? いや、そうじゃない。ディスプレイだけつないだ状態で、再び iMac から画面共有で接続した。不思議なことに、今度はちゃんと Time Machine モードに入れる。画面が、渦巻銀河と無数の Finder の列に変わる(多少、もたつくけど)。もちろん、消してしまったフォルダも復活させることができた。

解決できたが……

問題は解決できたが、解決策は気に入らない。せっかくヘッドレスで運用できるのに、Time Machine のためだけにディスプレイをつながなきゃならないし、そもそもキーボードとマウスがなければディスプレイだけつないでも意味がない。

Time Machine を、現状のグラフィカルでリッチな操作環境に加えて、CUI でターミナルから操作できるようにもしてくれれば良いんだけどね。

関連リンク

関連記事

twitter より (2010-09-09)

Powered by twtr2src.

2010-09-09

iPhone シミュレータをウェブページの作成に活用する

おそらく、iPhone や iPad 向けのウェブページを作っている人はみんなとっくに気付いていて、当たり前のように実践しているに違いない。最近になるまで気付かなかったわたしが間抜けなのだ。それは、ウェブページの見た目(やウェブアプリの動作)の確認に iPhone シミュレータを使うという方法だ。

もちろん、実機で確認する方が確実だし、最終的には必須でもある。しかし、ページを作っている最中にちょっと確認するのであれば、シミュレータを使うのもありだろう。何より、Mac の中で完結できるから、手軽さで実機を使うことに優る。また、Mac の Safari でユーザエージェントを切り替えたり、ウィンドウサイズを iPhone や iPad に合わせるよりも簡単だ。

起動、そしてデバイスの切り替え

まずはシミュレータのありか。

/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications

このシミュレータは iOS SDK にふくまれているものなので、iOS SDK をインストールしていない Mac ではどんなに探しても見つからない。ちなみに、iOS SDK のダウンロードだけなら無料でできる(開発者としての登録は必要)。

通常、iPhone シミュレータは Xcode の中から起動するから、単独のアプリだとは気付きにくいけれど、上記の場所に iPhone Simulator.app として存在している。Finder からダブルクリックすれば、通常のアプリと同様に起動する。

iPhone シミュレータという名前だが、iPad シミュレータにもなる。それには、メニューから「ハードウェア」>「デバイス」で目的のデバイスに切り替える。バージョン 4.1 では iPad、iPhone、そして iPhone 4 の 3 つから選べる。また、シミュレートする iOS のバージョンも別途選べるようになっている。ただし、デバイス専用のバージョンを選ぶとデバイスも同時に切り替わる(例: 3.2 は iPad 専用)。

ちょっとおもしろいのは、iPhone 4 を選んだときだ。iPhoen 4 の画素数そのままに巨大なウィンドウが表れる。iPhone のときの 4 倍(タテ、ヨコ、それぞれ 2 倍)だ。まあ、これでは Retina ディスプレイのシミュレートとしては不足だけどね。肝心の解像度(326ppi)を再現できていないのだから。

使い方は iPhone (や iPad) と同様。ただし、タッチスクリーンではないから、タップはクリック、スワイプはドラッグになる。また、マウス単独では不可能なマルチタッチのピンチオープン、クローズには Option キーを併用したドラッグとなる。Magic TrackPad の場合はそのままのジェスチャになればウレシイんだが、残念だけどそうはなっていない。

シミュレータの Safari でページを見る

シミュレータと実機の比較
シミュレータ
(iPhone)
実機 (3GS)

これは、実際にシミュレータと実機でこのブログを開いたときのスクショだ。それぞれを見ればわかるが、見た目の差はないと言って良い。フォントの種類もサイズも同一。行の高さも、折り返す位置も同じ。

ウェブアプリとなると実行速度や搭載メモリの差、さらには特性の差(センサー類は使えない)が差異として表れるかもしれないが、ウェブページの見え方を検証するのであれば、シミュレータも十分に役立つ。

関連リンク

関連記事

twitter より (2010-09-08)

  • 11:15  WEB+DB Press vol.58 の Emacs 特集を読んでいるだけど、なんでみんな Caps Lock を Ctrl に変えたがるんだろう(・д・)? この位置に Ctrl があったキーボードって、昔の SUN のワークステーションとか?
  • 11:18  PC-Unix (GNU/Linux 系とか *BSD とか)で Emacs に触れた人たちは、IBM-PC 由来のキーボード(Ctrl は右下と左下に1個ずつある)を使ったはずだから、A の横にある Ctrl を懐しむことはないと思うんだけど。
  • 11:20  まあ、IBM-PC 由来のキーボードで Caps Lock が無駄に思えて仕方がないのは良くわかるんだけどね。なんで、あんな良い位置に、ほとんど使うことのないキーが(それも大きく)居座っているんだって思うよ。
  • 11:24  あと、この記事(WEB+DB Press Vol.58 p.63) のように Return を Alt に変えるという発想には驚いた。初めて聞いたわ。Emacs で Alt キーっていうことは ESC の代わりだよね。ESC は Ctrl + [ で入力するもんだと思ってた。
  • 12:24  最近、Emacs 上でカーソルを見失うことが多い。なので、(global-hl-line-mode 1) は良いわ。ちなみにハイライトの背景色は "moccasin" がお気に入り。「Emacsテクニックバイブル」p.59より→ http://bit.ly/bugJZu
Powered by twtr2src.

2010-09-08

誰が Redmine を起動したのか?

前回(→ プライベートな問題追跡システムが欲しい)ではうっかり流してしまったんだけど、良く考えてみたら、あの程度の設定で Redmine が Apache のモジュールとして起動されるようになるっていうのはかなり不思議だ。だって、やったことは Passenger のロードとバーチャルホストの設定だけだゾ。どこにも Redmine を起動しろなんていう指示は書かなかった。なんで、あれだけで起動するんだ?

利用するだけなら気にしなくて良いことだけど、一度気になってしまうと頭から離れない。仕組みがわからないと気持ちが悪い。このままじゃ、夜も眠れない。

起動していたのは Passenger

あちこち探し(ググり)回って、結局、公式ドキュメントに答えがそのまま書いてあることに気付いた。

(9.3. How Phusion Passenger detects whether a virtual host is a web application より)
After you’ve read the deployment instructions you might wonder how Phusion Passenger knows that the DocumentRoot points to a web application that Phusion Passenger is able to serve, and how it knows what kind of web application it is (e.g. Rails or Rack).

おお、まさにこの疑問を感じたんだよ。

これによれば、Passenger は Apache の設定にある DocumentRoot の設定を元にウェブアプリのタイプを判別する、とのこと。つまり、こういうこと(↓)。

(同上)
So suppose that your document root is /webapps/foo/public. Phusion Passenger will check whether the file /webapps/foo/config/environment.rb exists.

そうか、それで virtual host にする必要があったのか。本来、DocumentRoot はウェブサーバに 1 つのものだ。ただし、virtual host は、その名の通り仮想ホスト(ウェブサーバ)なので、独自の DocumentRoot を持つことができる。

2010-09-07

プライベートな問題追跡システムが欲しい

コンピュータを使った作業で、その結果が形として(ビットやバイトで)残るのであれば(とくにそれがテキスト系なら)バージョン管理ツールを使うべきだ。一方、公開であれ非公開であれ、コンピュータを使った作業をプロジェクトとして扱うなら問題追跡ツールを使う方が良い。ソフトウェア工学という名の経験則の集積の中で、この 2 つの事実だけは、プログラマであれば誰もが認めるものだろう。

Open Source Software 開発プロジェクトのように公開するものであれば、外部の(つまりインターネット上の)サービスを使うことになる。けれど、私的なプロジェクトであればどうか。自宅内のサーバに、あるいは普段使いのデスクトップマシンに、なんならいつも持ち歩くノート型パソコンにこれらのツールも用意したくなる。

バージョン管理ツール(コードリポジトリ)は Git が良いとして、問題追跡ツールは何が良いだろう? 候補として頭に浮かんだのは、Ruby (と Rails) で作られた Redmine に、Python で作られた Trac の 2 つ。

数年前のことになるが、 Trac には初期の頃にインストールで苦労した覚えがある。いまでは、もうそんなことはない(はずだ)とわかっていても、少しためらう気持ちがわいてくる。そんなこともあって、今回、Redmine を Mac mini (Snow Leopard Server) にインストールすることにした。

インストール先を、普段使いの iMac でなく、mini にしたのは、iMac 以外の機器でも(MacBook、iPadなど、ひょっとして iPhone でも)使うことがあるかもしれないから。iMac は、わたしがその前に座っていないときはスリープさせているが、mini の方は外出するときと夜眠るっている間を除いて常時稼動している。iMac の前にいないときにも使いたいと思ったら mini の方に入れることになる。

Redmine のインストール

公式ドキュメントの Installing Redmine にはインストールに必要なソフトウェアが列挙されている。まずはそれを見ながら Snow Leopard Server (10.6.4) の状況をチェックする。

前提となるソフトウェア
Ruby
[mini] mnbi% which ruby
/usr/bin/ruby
[mini] mnbi% ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]

Ruby、OK。

Rails
[mini] mnbi% which rails
/usr/bin/rails
[mini] mnbi% rails -v
Rails 2.3.5

Rails、OK。

Rack
[mini] mnbi% gem list rack

*** LOCAL GEMS ***

rack (1.0.1)

Rack、OK。

RubyGems
[mini] mnbi% which gem
/usr/bin/gem
[mini] mnbi% gem --version
1.3.5
[mini] mnbi% sudo gem update --system
Password:
Updating RubyGems
Updating rubygems-update
Successfully installed rubygems-update-1.3.7
Updating RubyGems to 1.3.7
Installing RubyGems 1.3.7
RubyGems 1.3.7 installed

=== 1.3.7 / 2010-05-13

NOTE:

http://rubygems.org is now the default source for downloading gems.

You may have sources set via ~/.gemrc, so you should replace
http://gems.rubyforge.org with http://rubygems.org

http://gems.rubyforge.org will continue to work for the forseeable future.

New features:
[...snip...]
[mini] mnbi% gem --version
1.3.7

RubyGems は、標準でインストールされているのは 1.3.5。それでも問題はないが、ついでなのでアップデートしておいた。RubyGems、OK。

Rake
[mini] mnbi% which rake
/usr/bin/rake
[mini] mnbi% rake --version
rake, version 0.8.3

Rack、OK。

MySQL
[mini] mnbi% man mysql
[mini] mnbi% which mysql
/usr/bin/mysql
[mini] mnbi% mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 14
Server version: 5.0.88-log Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> quit
Bye

Snow Leopard Server には MySQL サーバが標準でインストールされている。が、このインストールには少々問題がある。というのも、クライアントとライブラリなどの一部のファイルがインストールされていないのだ。おそらく、サーバの稼動に不要なものが削られているのだろう。今回はこの欠けているファイルに用がある。mysql.gem をインストールするのに必要なのだ。

2010-09-06

Mac アイコンのありか

Finder のサイドバー(左側)に Mac のアイコンが表示されることがある。Finder の環境設定でデバイスとして、その Mac 自身を表示させるように設定していれば「デバイス」のところに表示されているはず。

意外と見逃しがちなんだが、このアイコン、iMac ならちゃんと iMac のアイコンになっている。MacBook なら MacBook のアイコン、Mac mini なら mini のアイコンが表示される。

ファイル共有で他の Mac に接続するとサイドバーの「共有」のところに接続先の Mac が表示されるが、このときのアイコンもちゃんとその Mac のモデルに合わせたものになる。接続した先がどの Mac なのかという情報を接続の際に取得しているんだね。

ところで、これらのアイコン、どこにあるんだろうか?

それは普段、ユーザが目にすることのない場所

前にウェブで見かけた記憶があったので探して(ググって)みた。あちこち探してようやく発見(→ 知られざるSnow Leopard (CoreTypes.bundle編))。後知恵だが、「mac 機種ごとのアイコン」で検索すればすぐに見つかった。適切な検索語を思い付くのは難しいわ。

さて、Snow Leopard では以下にある。

/System/Library/CoreServices/CoreTypes.bundle

すべての Mac のアイコンがあるわけじゃないけれど、意外に古いものもあっておもしろい(eMac とか iBook G4 とか)。

Mac 以外にも tv (Apple TV) や iPhone、iPad、iPod touch といった製品のアイコンも用意されている。

これ、OS のアップデートのタイミングで更新されているんだろうな。新旧モデルの入れ替えなんかもあるのかも。

おまけ: Finder.app のありか

アイコンを探しているときに知ったことなんだが、Finder.app は 「アプリケーション」フォルダには置かれていない。ずっとそこにあると思っていたんだが、探してみたらなかった。どこにあるかと言うと、↑にでてきた「CoreServices」。他に Dock.app なんかもここにあった。システムの根幹に関わるアプリだからうっかり消せないようにするため、「アプリケーション」には置いていないってことだろう。「アプリケーション」フォルダは管理者(最初に登録するユーザは自動的に管理者になる)だと制限なしに書き込み可能だからね。

関連リンク

関連記事

2010-09-05

GAE アプリによるスタイルシートの切り替え

簡単そうだと思ったのでやってみた。実際、簡単だった。要した時間のほとんどは Python の文法を調べることだった。

今回の切り分けでは、以下のようにリクエスト URL に応じて共通スタイルと機器用スタイルに分け、さらに機器用スタイルではユーザエージェントを使って実際の機器に合わせたスタイルに切り替えている。

リクエスト URL返されるデータを収めたファイル
http://stylerepo.../logrepo/common logrepo_common.css
http://stylerepo.../logrepo/device ユーザエージェントに応じて logrepo_ipad.csslogrepo_imac.css に切り替える

つまり、以下のように 2 つのリンクを書くだけでデバイスに応じたスタイルに切り替えられるわけだ。

(スタイルへのリンク方法)
<link type='text/css' rel='stylesheet' href='http://stylerepo.../logrepo/common' />
<link type='text/css' rel='stylesheet' href='http://stylerepo.../logrepo/device' />

切り替えの仕組み

今回の変更で、stylerepo の構成は以下のようになっている。

(stylerepo アプリ構成の一部)
/stylerepo/
    +-- app.yaml
    +-- index.yaml
    +-- logrepo/
    |   +-- __init__.py
    |   +-- base.py
    |   +-- common_handler.py
    |   +-- default_handler.py
    |   +-- device_handler.py
    |   +-- logrepo_common.css
    |   +-- logrepo_ipad.css
    |   +-- logrepo_iphone.css
    |   +-- logrepo_mac.css
    +-- main.py
    +-- stylesheets
        +-- mac.css

前回の状態から logrepo ディレクトリが増えた。また、app.yaml にも手が入っている。

app.yaml

共通スタイルと機器用スタイルの切り替えはリクエストする URL を替えることで行う。この仕組みは GAE に用意されていて、設定を app.yaml に記述すれば良い。

app.yaml では、リクエストの URL パターンごとに処理を行うハンドラを記述する。この URL パターンの記述には正規表現が使えるためコンパクトかつ高機能な記述が行える。たとえば、以下のような記述。

(app.yaml より)
- url: /logrepo/(common|device)
  script: logrepo/\1_handler.py

この指定は リクエスト URL が /logrepo/common または /logrepo/device で終わっていた場合に、続くハンドラに処理させることを意味する。ここで commondevice の選択は正規表現になっていて、実際のリクエストにふくまれている文字列(commondevice) がスクリプト名の指定中では \1 として参照されている。すなわち、/logrepo/common でアクセスされたときには logrepo/common_hander.pyに、/logrepo/device としてアクセスされたときには logrepo/device_handler.py に、それぞれ処理が任せられる。

twitter より (2010-09-04)

  • 18:08  はてブには twitter でつぶやいた URL を流し込んでいる。ときどき見返すんだが、iPad できるならそれが手軽にできるようになるか。 / はてなブックマーク for iPad 公開! http://htn.to/goJLcn
  • 18:22  9/8 だそうな。イベントからちょうど一週間後ってことか。4.0 は不安定だからな(on 3GS)、バグフィックスに期待大。→ http://ipodtouchlab.com/2010/09/ios-41-release.html
Powered by twtr2src.