碧落にて気まぐれに一言

2011/10/16

「ペンをカスタマイズする人はいない。ペンの使い方をカスタマイズするのだ」

Filed under: 未分類 — タグ: , — Suguru Yamamoto @ 21:27

電子書類の整理をしていたところ古い読書メモが出てきました。何かの縁ということで、掲載。

2009-05-17 16:29
A.D.ノーマン著「エモーショナルデザイン」より:

ペンをカスタマイズする人はいない。ペンの使い方をカスタマイズするのだ

非常に稀にならペンをカスタマイズする方もいらっしゃるかもしれませんが、そのような人は特殊中の特殊であり、デザインする上ではあまり対象として考えるべきではないでしょう。ほとんどの人はペン自体をカスタマイズしませんし、する必要が無いと思います。

カスタムできること自体は良いことですが、百万人のユーザ全員のニーズを満たしきるようにカスタマイズオプションを用意することはできません。結局の所、あるユーザのニーズを完璧に満たすことができるとしたら、そのユーザ自身の手によってデザインしてもらう以外にありえないでしょう。したがって、ユーザニーズをより良く満たしたいという動機で何らかのオプションを製品に加えるのであれば、その製品だけで完結するようなオプションよりも、他の製品と組み合わせやすいようにする方が良いと思います。たとえば各種の標準規格を採用したり、単純または汎用的なインタフェースを備える、といったアプローチです。

デザインという考え方は色々なものに適用できますが、特にこの考え方は汎用的ですね。ソフトウェアでも、電子機器でも、携帯電話でも、何でも。

2011/03/13

正規表現の「^」記号とマッチング範囲

Filed under: 未分類 — タグ: , , — Suguru Yamamoto @ 20:06

はじめに

(2011/4/6追記。本件はMicrosoftから将来のリリースで修正するとの回答がありました)
(2011/8/27追記。最新版のVisual Studio 2010+最新の.NET Framework 4で試したところ、まだ修正されていないようです。)

本日、各言語での正規表現エンジンを使って「^」記号(文字列または行の先頭を示す、アンカーあるいはゼロ幅アサーション…と呼ぶらしい)に関する動作を調査しました。背景にあるのはAzukiが内蔵している正規表現検索で行頭マッチングが行われないというユーザ報告の不具合(に近いが対策できず黙認していた動作仕様)です。過去に検索機能を実装した際の調査結果では.NETの正規表現エンジンで「Multilineモード」を有効にしても各行の先頭でない位置でマッチする現象が起こり、使えないと判断しました。今回は、この問題を改めて少し掘り下げて調査した結果報告(?)となります。

調査結果のポイントです。

  1. Microsoftの.NETが提供する正規表現エンジンでは、マッチング範囲の終了位置を指定すると「^」が常に「マッチング範囲の開始点」にマッチしてしまう(終了位置を指定しなければ常にはマッチしない)
  2. MSDNの「^」記号の説明Regex.Matchメソッドの説明からは「^」が文字列の先頭でも行頭でもない箇所にマッチする動作は予想しにくい上に、Regex.Matchのオーバーロード間での動作仕様の統一性が失われている
  3. Java (1.5以降)の正規表現エンジンでは「Anchoring Bounds」という概念で「^」の扱いをカスタマイズできる(→ Matcherクラスのリファレンス)が、.NETでは同等の機構が無い
  4. ユーザ指定の正規表現を使うアプリケーションで、特定のマッチング範囲を絞り、「^」をマッチング範囲の開始点にマッチさせたくない場合、実現できないと思われる

ポイント1および2です。Regex.Match(string,int)のオーバーロードを使ってマッチング開始点だけを指定した場合には、行頭でも文字列先頭でもない位置がマッチング範囲の開始点であっても「^」記号は該当位置にマッチしません。しかしRegex.Match(string,int,int)のオーバーロードを使うと、マッチします。したがってオーバーロード引数を追加するだけで動作仕様が変化してしまうため、不自然な印象を受けます。次に例を記します。

string text = "abc";
new Regex( "^[a-z]" ).Match( text, 1 ); // どこにもマッチしない
new Regex( "^[a-z]" ).Match( text, 1, text.Length ); // 1文字目のbでマッチする

ポイント3です。Javaの正規表現エンジンでは「Anchoring Bounds」という概念があり、「^」記号の扱いをカスタマイズできます。Anchoring Boundsを使うよう設定すると、「^」記号および「$」記号のマッチング時にマッチング範囲の前後が考慮されない — つまり問答無用でマッチング範囲の始点に「^」記号がマッチするようになります。そしてAnchoring Boundsを使わないよう設定すると、マッチング範囲の開始点が文字列先頭あるいは行頭でない限り、「^」記号はマッチング範囲の開始点にマッチしません。このように「^」記号のマッチング動作を明示的に指定できる機構があれば、それを使うことで問題回避できますが、残念ながら.NETにはありません。

ポイント4です。どうやら.NETの正規表現エンジンではJavaでいう「Anchoring Bounds」の扱いがRegex.Matchのオーバーロードごとに異なっており、Regex.Match(string,int)はAnchoring Boundsを使わず、Regex.Match(string,int,int)はAnchoring Boundsを使う動作となっています。ここで、もしAnchoring Boundsを「常に使いたい」場合は外部でマッチング対象の文字列をSubstringすることで代替できます。しかしAnchoring Boundsを「常に使いたくない」場合、Regexクラスの外部でこれを実現する方法は無いように思われます。

この仕様はAPIからもドキュメントの記述内容からも想定できるものでなく、また統一が取れていないという点も考えると、意図的な設計結果とは思えません。本件は、改めてMicrosoft社に報告と確認をしておこうと考えています。

以下、各言語・環境での検証コードおよび検証結果を記します。なお言うべきことはすでに記したので、細かい説明はしません。興味のある方や再現してみたい気分になった方へ向けた情報です。

(続きを読む…)

行ごとの編集状態

Filed under: 未分類 — タグ: , , — Suguru Yamamoto @ 14:04

Azukiでは行ごとに3種類の編集状態を定義し、管理しています。具体的には未編集、編集済み、保存済み(一度以上編集されたが最後に保存された状態から変化していない)の3状態です。Azukiで3状態を扱うようにした背景は安直にも「Visual Studioに合わせただけ」なのですが、実際にやってみると思っていたより難しいことが分かりました。

この難しさの背景にはAzukiのデータ構造が単一のバッファ(gapped buffer)で構成されていることがあります。ドキュメント全体を単一のバッファで管理していることから、AzukiはUNDO/REDO情報をドキュメント全体に対する差分として記録しています。言い換えると「行単位の編集履歴」にはなっていません。もし編集履歴を行単位で記録していれば、ある行が「保存済み」状態であるかどうかは簡単に判定できます。しかし、ドキュメント単位での編集履歴で記録していると、正確に3状態を管理する方法が簡単には思いつきません。

元々は「保存済み」状態はUNDO/REDOによって復元されない仕様としていたので「未編集」と「編集済み」の2状態に関しては深く仕様検討したものの、「保存済み」状態についてまでは掘り下げて検討しませんでした。仕様範囲外だったので仕方ない部分もありますが、もう少し先を読んでおくべきだったかなと反省しています。「保存済み」状態までキッチリ検討できていないなら3状態とせず2状態とすることもできたはずなので。

2011/02/16

丸投げ

Filed under: 未分類 — タグ: , — Suguru Yamamoto @ 22:10

ソフトウェアは設計上の階層構造を持つことが多く、ほぼ間違いなく最上位をアプリ層(そのアプリ固有の処理)とした複数の階層を重ねた形になっています。ごく単純なアプリの場合は最上位のアプリ層のみが存在すると解釈すれば、やはり階層構造です。このとき、特に最初が単純な一階層のアプリだったものに機能を追加していく場合、ある程度の規模を越えると階層構造を組まないと管理不可能になっていきます。本日はこの階層構造と「丸投げ」について思うことを書きます。
(続きを読む…)

2010/08/22

「未来のモノのデザイン」を読みました

Filed under: 未分類 — タグ: , , — Suguru Yamamoto @ 16:24

D.A.ノーマン先生の「未来のモノのデザイン」を読み終えました。実は発売直後に購入していたので読み始めはずいぶん前なのですが、読書時間をうまく取ることができておらず、今頃読み終わりました。これからは読書を含む勉強のために時間を毎日 1 時間程度は取っていこうと思っています。

さて、ソフト屋として読み進めた中で一番印象に残ったのは自動化と能力拡大の話です。能力拡大を私の言葉で表現すると、「人+機械=人以上」を達成することかなと考えています。機械をあくまで道具として設計し、それを使う人間は「ただの人間よりも能力が増強(拡大)された人間」になる。そんな設計方針です。

総論を書こうとしても上手く書き出せず、読み返せば読み返すほど理解が甘いのかなと思ってしまう状況で書くのも何ですが、たとえば現在のワープロにある「間違いと思われる箇所を検出したときに自動的に下線を引く」機能は、人間の「間違いに気付く」能力を拡大するものだろうと考えています。うーん、根本の根本にあるものを理解できてはいないような気がするのですが、表に出てくる設計結果=ユーザインタフェース・ユーザインタラクションがどうあるべきか、という観点からはよく分かったと思います。押しつけがましくないこと、人間が決めたいことを人間が決められること、それを使うことで発生する認知的負荷が軽いこと(≒違和感なく直感的と感じる)、あたりが重要かなと思います。

2010/08/12

オルセー美術館展2010に行ってきました

Filed under: 未分類 — タグ: — Suguru Yamamoto @ 11:37

昨日、オルセー美術館展2010に行ってきました。ぜひ行きたい、と意気込む母親の意向(?)で両親と一緒に。

オルセー美術館展2010ではゴッホの自画像など、誰でも知っている名画と呼ばれる作品が多く展示されています。その上に昨日はお盆ということで、猛烈な混雑に見舞われました。入場まで90分待ちと言われたのでお昼を先に食べようとレストランに並んだらこちらは60分待ちと言われ…小さい頃にディズニーランドで行列待ちしたとき以来の「待ち」を経験してしまいました :|

今回の美術館展でハッキリと分かったことは「私は現実の瞬間を切り取って保存したような絵画には興味が無いらしい」ということです。本当に豚に真珠というか、実在の人物を描いた名画などには、実物を前にしても惹かれる感覚がほとんど無く、そこにいたこと自体がもったいないと感じてしまったぐらいです。これまでの経験を改めて振り返ると、私が惹かれた絵画はおおよそ抽象画で、写実的な描き方をされた絵画で惹かれたものは宗教画だったりします。どうにも絵自体に魅力を感じていないらしく、その絵を通して作者が表現しようとする思考や空想など「頭の中の何か」に惹かれているようです。あるいは、単純・純粋に視覚刺激としての映像か。

しかし、できればもっと明るくて人の少ない状況で体験できれば良かったと思います。人混みの後ろからでは全然よく見えないので、頑張って絵の前まで出てきても、私の視力では暗くて細かい部分までは見えないことが多かったです(長い行列待ちで疲れていたのもあります)。細かいところが見えていれば、先ほど記した感想も180度変わっていたかもしれないので、残念ではあります。後から振り返っても変えられることでもなく、仕方ないことではありますが。

2010/04/15

ブログのデザインを更新

Filed under: ブログ運営 — タグ: — Suguru Yamamoto @ 22:50

ブログのデザインを更新しました。WordPress標準添付のClassicスタイルを元に、スタイルシートを書き換えて碧落の配色に変更しただけです。

とりあえず体裁は整いましたので、本日より公開してみます。

Powered by WordPress