Rhaco UrlsとFlowを利用して他クラスのメソッドを呼び出すときの注意事項
Rhacoを使って開発してるのだけど、細かな情報はまだまだ把握しきれてないので手探りが多い。
自分用のメモ。
index.phpでやること
- generic.Urlsのインポート
- urlパターンの定義
- 取得したparserでの実行
$parser = Urls::parser($pattern);
$parser->write();
他クラスでやること
- extends TagParse
- flowでテンプレートと変数を定義
- $flow->parser()みたくparserを返す
IE7でAjaxのその後
前回のエントリでIE7でAjaxリクエストの挙動がローカルとリモートで異なる件に触れた。
で、その後の調査結果。
IE7でJavaScriptを含んだプログラムを動かすと、ActiveXコントロールを含んでいるけど大丈夫？というポップアップがブラウザ上で表示される。動いてくれないと困るので、「はい」と答える。これが落とし穴。
この時点でActiveXObjectを使って動く前提とブラウザは思いこんでしまう模様。にも関わらず、XMLHttpRequest判定を前に持ってきているので、そっちでリクエストを投げようとするのが不整合の原因のようだ。
そう、つまりリモートにコンテンツを配置した場合はXMLHttpRequestで扱うとブラウザが思ってくれるので、エラーはでなくなるということだろう。うん、やっぱりXMLHttpRequestに統一してくれとして言えない。
ここからは最近なんとなく思うこと。Ajaxってもう、終わりな気がする。というかHTMLで何でも表現するのはいい加減限界だし、DojoやExt.jsのようなリッチUIを用意するのもブラウザ互換吸収とかで苦労するし、無理がきていると感じる。
なのでUI部分をFlashにという流れが今は主流なのだけど、コントロールの出来でいったらSilverlightのが上だろと思うので、棲み分けを作る側が理解して使い分けるのが正解なんだという当たり障りのない結論に落ち着いた。
とりあえず、業務アプリのUIはSilverlightでいきたい。今はまだFlashかなと思う。後々の浸透度次第か。
IE7でローカルからXMLHttpRequestを使うとエラー？
ActiveXObjectの判定タイミングは前か後か？
とある案件でここと同じであろう現象に遭遇。
IE7からXMLHttpRequestとActiveXObject両方に対応するようになっており、ActiveXObjectの判定は後ろに持っていくべきと言われている。
が、実際のところローカルで実行するとXMLHttpRequestの判定は通るけれども、GETリクエストを投げたところで「アクセスが拒否されました」というエラーが。これはバグと言いたい。
で、結局ActiveXObjectの判定を前にもってくることで解決。腑に落ちない。
if (window.ActiveXObject) {
req = new ActiveXObject("Microsoft.XMLHTTP");
if (req) {
req.open("GET", url, false);
req.send();
}
} else if (window.XMLHttpRequest) {
req = new XMLHttpRequest();
req.open("GET", url, false);
req.send(null);
}
ちょっとしたテストをすると、XMLHttpRequestでもActiveXObjectでもtrueとIE7はなる。うーん、善し悪しだこれは。
そうじゃない、ちゃんと仕様を統一してください。
ちなみに、上記の修正を行う前にはFirefoxとChromeは問題なし。IE7とSafariはNG。
やはりいらない子なのか。
とある案件のクライアントは、それまでIE6を使用していたことを考慮すると、IE7の使用率が増えたことでこういった不具合が起きている可能性があるかもしれない。この案件のリリース時はIE7対応しないという契約だったので、よくよく考えてみればこれって、有償にしていいんじゃないか？
冗談はさておき、ブラウザのバグとか仕様解釈の違いをこれだけシェアの大きいソフトウェアで製作者に押しつけたままというのは不満。だけど、それもプログラマの仕事という事実なのは否定できない。
CSS Nite in Aomori 2009 で発表してきました
まずは皆様お疲れさまでした。恒例のイベントとなってきましたが、まさか自分が発表することになると思っていなかったので、貴重な機会をいただいて感謝しています。
使ったスライドとか
雑感
今更ながらJSRubyを使ってみたんだけどという内容だったのですが、みんなでRuby勉強会@青森に来てみませんか？という前フリでした。HotRubyに興味をもっております。
というのも前フリで、本題は異業種交流をもっとしましょうというのが言いたいことでした。業務知識でも何でもいいので、様々な知識や情報を交換、共有したいというのが切にあります。Give & Takeでそれぞれのビジネスに活かして行きたいと思っています。楽しんで仕事ができるというか、仕事すら道楽にできたら最高だよねと思っています。
そもそも、CSS Niteは敷居をさげて多様な方々にWEBの世界やそこで活躍している人の様子を伝える場と捉えているので、変なことやってる奴がいるなと思ってもらいたいと考えました。「おもしろい」というモチベーションは大事だという裏テーマが伝わるとなお嬉しいですね。
他に思ったことは、アクセシビリティという言葉が現れて久しい中、実際に音声ブラウザなどを利用してOS操作から何から実演で見ることができたのは非常に参考になりました。それを掘り下げて、考察をまた書いて行きたいと考えています。
今後について
とりあえず、交流会にそういう自分が足を運べない時期もあったので、もっとアクティブにしていこうと画策中です。初心者向けにという状況が多かったのですが、それによって基礎固めの機会に恵まれたことが資産になりました。次は自分が突き抜けて行くターンですかね。
今年はただ作るというのではなくて「クライアントが本当に欲しいもの」について精度を上げて行く取り組みを考えたいというのがテーマです。個人だと形式化が弱いので、そこらを重点的に。
目的の共有、要求の精査というものについてヒューマンスキル任せになりがちな反省が有るので、その視覚化とツール化に取り組んでいこうかなと。今のところはクライアントと直接交渉できる場合に限りですけど。そういうフィードバックを勉強会でも発信できたらと思います。
jQueryベースのフォーム入力チェックを実装中
CSS-Nite Aomoriで5分プレゼンを行うので、その準備中。
それと並行して、自分のサイトをWordPressベースで作ってみた。というか、テーマとして作るという宿題がほったらかしだったという。
で、RubyでYAML形式の定義を元にFormを自動生成したくて、ちまちま書いているのだけど、せっかくだしvalidationはjQueryで作ってみることにした。巷にあふれているものではあるけど、自分の勉強がてらだ。
jQuery自体はバージョンいくつの頃だろう・・・だいぶ前に、prototype.jsとjQueryどちらをベースにしていくか？というテーマがプロジェクト内であって、jQueryの挙動が気に入らず、prototype.jsでいくことに。Railsもprototype.jsが前提なんだけど、あまりにjQueryの名前を聞くようになったし、今だと良くなってるのかもね？と思って使ってみた。バージョンは1.3.2。
確かにCSSセレクタを使ってDOMにアクセスできるのは快適だし、直感的に書けるコードも多いのだけど、ちょっとHTMLやセレクタが複雑になってくると、思うように要素がとれなかったり、Arrayで値が返ってくるのかjQueryオブジェクトが返ってくるのかがまちまちだったりと、複雑なことやろうとすればするほど、DOM直接いじってる方が楽だな・・・とか思ってしまう。正しい使い方ができてないのだろうか？
$の挙動からいけば、やはりprototype.jsが自分には合っているようだ。というか、まずブラウザ側の挙動を統一してほしい。それに尽きる。挙動の違いを吸収してほしくて、javascriptフレームワーク使っているようなもんだし。今更すぎる内容だけど、改めて使ってみても、やはり思うことは同じだったりする。
となると、棲み分けなのだろうという結論。すでに固定のHTMLがあって、それに対して簡易的なエフェクトやDOM操作を行うなら、jQueryは非常に効率的だと思う。逆に何らかのデータフォーマットやHTTPレスポンスを元にHTML生成したりと、動的な実装をしたいのであればprototype.jsかなと思う。
エフェクトやGUIなどオールインワンのライブラリを求めるなら、Ext.jsかDojoあたりなのだろうか。思い立つことがあれば、今度はそっち側を試してみようと思う。
gitignoreにファイルを追加する方法
.git/info/excludeにファイルパターンを記述する
EclipseとかAptanaを使ってると.settings, .loadpath, .projectとかが邪魔なので追記必須かな。
特定ディレクトリ以下のファイルのみだと、logs/**/*とかでいける模様。
git on さくらインターネットに移行してみた
もともとXREAを自分のサーバとして利用していたのだけど、さくらインターネットに引っ越しをした。
それまでは、ｓｖｎでソースを管理していたのだけど世間の流れに乗ってみようとgitを使ってみる。
手段のために目的を変えるのはプログラマにはよくあることだと思う。勝手な偏見。というか自分がそうだ。
早速、先達の後を追ってgitの環境を構築。あっさり。素晴らしい。svnもめすぎ。
で、TortoiseGitの人柱になろうと思って導入したけど、どう見てもコマンドの方が楽です本当にありがとうございました。
いや、使いこなせてないだけだと思う。本当に。git-svnはさくらインターネットへの svnインストールのめんどくささから断念。
それまでsvnで管理してたものを切り離し、今後も開発が続いていくものだけをピックアップしてgitに移行。
それぞれのプロジェクトでちまちまコマンド打ってられないので、簡単なシェルを作ってさくさく。
私はWindows使いなのでcygwinですべての作業を行った。
今月に開催されるCSS Nite Aomori でしゃべることになったので、そこで使おうと思っているネタをgit管理で作ろうと画策。
予定は未定なので、とりあえず言うだけにしておこう・・・
先月のRuby勉強会@青森でしゃべってみたりと、ちょっとずつ表に顔を出し始めている。
参加された方に少しでも意味のある内容になればと思うばかり。
世の中の最前線で開発するプログラマ達に比べれば、自分のは稚拙な内容だと思うのだが、最終ビジョンが「町の IT屋さん」と思い描くようになってからは、プログラミングをしない、知らない人たちに対して、どうやったら自分たちの世界に対して敷居を下げつつ、楽しさとおもしろさ、便利さを伝えられるだろうかと考えている。
そのために自分の技術力の低さにへこむこともあるのだけど、技術は磨くのみだし、自分だけ満足してちゃもったいない。
基本、おせっかいなので地道にやれることをやっていきたい。
なんか最後は日記的なひとりごとになってしまった。とりとめないので、今日はここまで。
PDO For WordPressインストールでハマる
レンタルサーバにWordPressをインストールというのはよくある話だけど、
SQLiteで動かそうとしたら、予想外に大ハマり・・・
というわけで、作業メモ。
環境：
PHP 5.1.6
WordPress 5.7.1
PDO For WordPress 1.0.2
こちらを参考にさせてもらいつつ作業するも、なぜか画面が真っ白。
結局、PDO For WordPressのソースをさらに追ってみる。
こんな長時間のprintデバッグとか久し振り。
で、原因はここ。
line 206 on wp-content/pdo/driver_sqlite/pdo_sqlite_driver_create.php
//need this line to comment out.
//$this->_errors[] = preg_last_error();
preg_last_error() >= PHP 5.2.0
というわけで、5.1で未対応のメソッドを呼び出していたためにDBの初期化で停止していた模様。
ものすごい時間かけたわりに作業が1行いじっただけとかよくある話ですけどね。
自覚的デザインを目指す その3
別にこのシリーズを忘れていたわけではなくてですね。言い訳不要ですね。再開します。
予告としてデファクトについて考えるとしました。これは事実上の標準を示す「デファクトスタンダード」のことです。これをWEBにおけるリンクを中心に考えてみます。
- デファクトを破るのはミスリードのリスクあり
- 思考の流れとUIを一致させることが重要
- 一部の色やアニメーションといった視覚効果もフィールとして考える
デファクトの色を採用する必要はない
ブラウザにおいて、リンクのデファクトは大ざっぱに分けると2つでしょう。
- 未訪問
- リンク色：青 テキスト装飾：下線あり
- 訪問済
- リンク色：赤紫 テキスト装飾：下線あり
白地に黒のテキスト、そして上記のようなリンク色がデファクトです。なぜこの色が採用されたのかを知らず、調べたところ情報が見つからず。ならば色彩学かなと思って、その手の本を読んでいる所です。
それはともかく、まずは2つの側面からリンク色というのを考えることができます。1つ目は、見なれたものであることです。およそ、インターネット利用者が最も目にする配色がこれという説明に尽きると思います。2つ目は、白地に黒という配色では、青が浮いて見えて、赤紫が沈んで見えるということです。ここが色彩の問題で、自分では明らかにできていないところですが。
大事なのは、未訪問がテキストの中で目立ち、訪問済が目立たなくなることです。また、そのリンク色の割合によって、自分がどこまでこのリンク群を消化したのかという目安にもなります。これを踏まえれば、リンク色はデファクトのままである必要はなく、「目立っているか、そうでないか」で決定すればよいと考えられます。
リンク以外で下線を使うのはミスリード誘発
問題は下線です。ワープロの世界だと下線とは注目するポイントを示唆するものとして扱われます。ですが、WEBで同じように使ってしまうとミスリードを誘発します。リンクのデファクトを踏まえると、下線がある場合にリンクであると想起させてしまいます。ホバーさせた際に下線が出るのも同じように捉えられると思います。
リンクしないテキストに下線は使わないと割り切ってしまう方が得策です。要は慣れとルック・アンド・フィール(以下、LnF)の問題です。リンクの色と装飾ひとつをとっても、扱いを間違えればLnFの特にフィールを大きく損ねることになります。
非テキストリンクは押せるルックを
非テキストのリンクはどういった形状をとるべきか？という話になると、ボタンがいいと言われます。何故か？と問うと、「押せると思うから」という返答がきます。私はこれについて本質ではないと考えています。なぜなら、WEBデザインの世界だけを見ても、グローバルメニューはボタン(大概はトグル)になっていないものも多いからです。
リンクという視点で考えた場合、テキストリンクを「クリック」することでリンク先のページを表示するというアクションが発生します。しかし、テキストリンク自体はボタンの形状をしているわけではありません。つまりボタンの形状をしていなくとも、「押せる」と思うわけです。これはデファクトであるからこそ、できることでもあります。では、リンクの形状を問わず共通するものは何か？「押せると思わせるルックである」ことです。
テキストであれば、浮いて見える配色で下線を、非テキストであれば押せると想起させる形状なり、注釈などを。ボタンというのは、あくまで押せると思わせる形状の代表的な存在であって、実装手段の1つに過ぎません。
あくまでこれは、前回で触れた「予測できる＝解りやすい」を踏襲しています。すると、リンクのルックとリンク先の内容が一致していることなど、芋づるで押さえるべきポイントが決まってきます。なおかつ、LnFにおけるフィールまで考慮することで、「予測した通りに動く＝使いやすいと感じる」にユーザを導くことになります。これが思考の流れとUIの一致と言えます。
エフェクトをフィールとして使う
WEB上ではJavascriptによるエフェクトの多用がよく見受けられます。いわゆるDHTMLなわけですが、そのエフェクトをどれだけ有効活用されているかと考えると、個人的には疑問に感じる点が多いです。
エフェクトはルックなのか、フィールなのかと問われると、私はフィールと考えています。フィールとして使われるエフェクトというのは、画面上で発生した事象をユーザに通知することです。
例えば、WindowsとMac両方で共通のUIで考えると、ウィンドウの最小化です。デフォルトの設定ですと、Windowsの場合は、縮小化されたタスクトレイ上のパーツに向かって、ウィンドウが徐々に縮小(およそ0.5秒？)されていきます。Mac(OSX Leopardとします)だとジニーエフェクトを利用しつつ、ドック上の格納位置に向かって吸い込まれるように(およそ1秒～1.5秒？)ウィンドウが消えます。どちらも縮小化というアクションに対して、エフェクトを適用することで、ユーザにウィンドウが縮小化され、どこに格納されたかを通知するというフィールを生み出しています。ロード時間中のインジケータ、画面切り替え時の切り替え先のポップアップ、私はこれらが正しいエフェクトの活用法だと思います。
エフェクトを認識する時間はどれぐらいか？
エフェクトと一口に言ってしまっても、様々ありますが、ここのところ気になっているのは、2Dエフェクトと3Dエフェクトについてです。特にKeynoteでエフェクトを適用していると、2Dエフェクトで程よいと感じる動作時間、3Dエフェクトで程よいと感じる動作時間に差があります。
仮説としては、2Dエフェクトは0.5秒以上、1秒以下、3Dエフェクトは1秒以上、2秒以下がしきい値と考えています。といっても、それぞれのエフェクトにさらに細かく種別があるので、もう少し解析が必要とは思っています。ここは、人間の視覚の根本である、情報認知の世界だと思うので長い道のりになる気がしています。
とりあえず、次回についてはエフェクトの認知時間、もしくは時間軸による情報認知について、掘り下げてみようと考えています。
サムネイルの意義を考え直す
つい今朝のことですが、プロジェクトメンバーから興味深い問題提起を受けたので、それについて書こうと思います。私は彼の視点や思考方法をすごく尊敬していて、彼との出会いによって多様性への理解や発想の転換力が豊かになったと思います。
- 新聞の見出しの狙いはカクテルパーティー効果
- サムネイル＝本の背表紙
- デザインコストをかけるべき場所にずれがある
そもそもの話は、画像ビュアーを個人的にプロジェクトメンバーが作成し始めたことがきっかけでした。私も彼も、業務システム屋の出身なので、画面としてのUIというものに、自分なりのこだわりがあります。それゆえに、WEBデザインの案件をこなす傍ら、UIについて突き詰めて考えようと意見交換をすることがよくあります。
2人の中では、およそUI設計における指針は共有されており、そもそものとらえ方も似ていました。結果的に、視線移動にとどまらず、人の情報認知という事象について、裏付けを取ろうと調べだすのは当然の流れだったのかもしれません。
視覚にもカクテルパーティー効果がある
カクテルパーティー効果が視覚にも存在し、その誘導を行っているのが新聞でいう見出しのことらしいという話を受け、自分の中で腑に落ちた点が多々あります。
新聞のUIは独特で、以前のエントリでも触れている逆NとZの視線移動が混在しているにも関わらず、なぜか読み進めることができます。慣れという点を差し引いても、記事が目に入ってくるのは見出しのおかげだと思っていました。
全体を俯瞰した状態で、人はおそらく新聞の内容はほぼ見えていないと思われます。人間の目の精度はそこまで良いものではありません。乱暴に言えば、カメラレンズなので焦点の合っていない場所は、情報の内容まで認識できるレベルではないということです。
つまり、カクテルパーティー効果と同様で、見出しによって注視して初めて周辺の情報がどういった構造なのかを認識しだすと考えることができます。さらに言えば、注視が始まると、それまでの視線移動のリズムや方向などを無視していようが、人間の思考が現在のルールに合わせだすということです。
タイルは画像検索に最適なUIではない
Windowsエクスプローラでも、Macファインダーでも、ショッピングサイトの商品画像一覧でも何でもよいのですが、サムネイルがZ方向に並べられている状態を私はタイルと呼んでいます。
多数のサムネイルが存在する中から、目的の画像を視覚で探すのは困難を極めます。そのためにタグをつけて管理したりと様々な手法があるのですが、すべての画像にタグをつけて管理できる整理上手で勤勉な人間がどれほどいるというのでしょう？
結局のところ、タグ管理というよりフォークソノミーの課題そのままなのですが、画像を保存して閲覧するという過程において自動的に割り振られる情報は保存日などの時間しかありません。ファイル名は任意ですし、重複しないファイル名を望むのであれば(これは極端な思考とは思いますが)MD5で自動生成したファイル名にでもしてしまいたいところです。
実際、Googleが提供するPicasaは保存日を基準にしてグルーピングする手法をデフォルトとしており、そこからユーザが任意のルールで整理を始めるという流れを促しています。
グルーピングはソートと言い換えても同じです。ファイル名の五十音順なり、保存日の降順などでソートしない限り、同じ大きさの画像が並んだとして、視覚だけではとても探せたものではないということです。
実際にやってみるとわかります。1つ1つ丁寧に探していくと、時間がかかりすぎてうんざりし、どんどん飛ばし読みしていくようになります。
サムネイル＝縮小画像は誤解
本屋にいるとします。目的の本があり、その表紙やタイトル、著者、出版社がわかっているとします。どうやって目的の本を探し出しますか？店内の本棚のどこかにあり、店員に聞いたり、検索端末などは利用しません。
おそらく、出版社で本棚を特定し、著者が有名であれば著者で棚を特定し、そこからは背表紙か表紙で視覚による検索を始めます。平積みされない限りは、背表紙を見ていくことになるでしょう。
つまり背表紙で探している状態がサムネイルで探している状態です。目的の本を見つけたとして、表紙を確認し、中身をざっとみる。これが商品詳細のページを見るのと等価の行動となります。
では、背表紙をよく見てみます。縮小画像としてのサムネイルと決定的に違うのは、背表紙は専用のデザインとして作られていることです。文字組、フォント、文字サイズ、配色と様々な要素を駆使して、背表紙という立ち位置から本を表現しています。つまり相当のデザインコストが背表紙1つに払われていると考えます。ここはカバーデザインをされている方やDTP畑の方に何とかしてその実態を聞いてみたいところではあります。
詰まる所、サムネイルは縮小画像として自動生成される程度の代物ではないということです。なぜならば、カバーデザイン1つで本の売れ行きも変わるという事実があるからです。
さらに付け加えると、画像1つ1つの内容は千差万別です。サムネイルを生成するにしても、その画像を簡略化した表示とするために、適切な構図なり、文字による情報の付加が必要となるはずです。それはすでに自動化不可能な話で、それこそ画像認識の話になってしまいます。
内容が異なる情報に対して、等価な情報加工(同じ倍率での画像縮小のみ)を行うことで、かえって視認性を低下させ、情報としての価値を下げている、もしくは失くしていると考えられます。
サムネイルにもデザインコストの明確化を
現実的な話に戻すと、最適なサムネイルを生成する画像認識機能付きアップローダを作るのと、1つ1つサムネイルをデザインするのと、どちらが適切か？という話になります。ここでの適切というのは、用意できる資金に現実的に収まるか？という意味で考えています。
私は1つ1つ手でデザインする方が適切だと思います。なぜなら自動化には限界があります。そして、人が分かりやすい、美しいと感じる理由を解明できて、かつ標準化できない限り現実的な精度と品質は得られませんし、そこまで行くには一生涯を費やす覚悟が必要でしょう。実際、専業として開発されている企業や団体があるのがその証拠です。
具体的な話をします。商品データのアップロードを行うと、通常は画像のアップロードに伴ってサムネイルを縮小画像として自動生成というのが一般的なパターンでしょう。しかし、これが間違いなのだとあえて言います。
例えば、静的ページを作成して何らかの施設概要や内部について紹介するページを作成したのであれば、カメラマンを用意するだけでなく、撮影結果を加工して画像を用意すると思います。
それがショッピングサイトのような多数となると、途端に自動生成で縮小した画像のみとなります。そこに対しての理由がおそらくコストと言う人がほとんどですが、それはコストではなく「面倒だから」が本音だと思います。手間を重視するのではなく、デザイナであるならば、サムネイルを1つ1つ作ることへのコストとメリットを明確化し、対価を得るようにクライアントと検討する方が健全だと思います。
どれだけ膨大な商材をもつショッピングサイトでも、1件1件のデータ登録と画像アップロードという「手間」をさけて通ることはできません。その手間に「費用としてのコスト」が発生しているのです。
かといって1枚いくらなんていう、どんぶり勘定でいきなりクライアントに提示するのは間違いです。ページ内容を踏まえ、それに対する画像数やその品質とデザインコスト、製作期間まで含めて価格を出し、それをならすと1枚いくらです。という所まで説明して合意をとっているか？というのが肝心です。
ただ理想論を言っているつもりはありません。経験則からの裏付けがあり、自動化によるコストダウンが価格競争という消耗を産み、さらにはデザイナの価値の低下、デザインの品質低下を招くという危惧も含まれています。
啓蒙の意味も含めて、デザインへの対価を考えて商売する方がデザイナも納得できると思うのです。
そこまで徹底してこそ、デザイナに価値が発生するのだと思うのです。