引っ越しました
はてな に移ります。
http://d.hatena.ne.jp/cept/
新天地にて更新を再開したいと思います。
企業システムとユニバーサルデザイン
通勤の往復で『「誰でも社会」へ―デジタル時代のユニバーサルデザイン』を読んだ。一日で読めるとはなんとお手軽。
ユニバーサルデザインって、数年前に社内の新規事業アイデア公募で「自社の提案に必ずユニバーサルデザインを盛り込むっつーのはどうです？」と提案して、もののみごとに丁重にお断りされた経験がある。その頃もっと張り切ってたら、もしかしたら著者である関根千佳さんに会いに行ってたかもしれない。
バリアフリーは、まずターゲットの人たちに向けてデザインし、その後で対象外の人にも広げていくこと。
これに対してユニバーサルデザインは、もっとも障害のある人間でも使えるように最初からデザインすること。
分かりやすくて優しい文章の中に、はっとさせられる文があった。
「最初から画像を見ない超ハイパーなネットワーカーのニーズと、視覚障害者のニーズは一致しているし、片手に電話を持ってキーボードだけでデータを探したいビジネスマンのニーズと、片麻痺の方のニーズは一致しているのだ。」
そうなのだ！完全な人間がいないように、「健常者」もまた障害者なのだ。
障害者に対する壁は、まだ大きく存在している。しかし障害者の姿という分かりやすいものしか見えないのも、視野が狭いというものだろう。
ユニバーサルデザインやバリアフリーの考えが企業システムの設計で議論されているのを見たことがない。
メーカーは自社のサイトで大々的に謳ってはいるが、現場レベルではまったく話を聞かない。
たとえば色盲の人たちに対する配慮をしているだろうか。
ダム端末の画面は黒地に緑色の文字だが、エラーが赤色で表示される。
株価ボードは緑と赤で示される。
会議の資料に載せた表は、セルの色の違いだけで差を表現している。
ちょっと文字を添えてあげるだけで、色盲の人を困らせることがなくなる。
色盲は通常生活にそんなに困難をきたさない。会社でも周りにいくらかいることだろう。しかし当人達はあえて言わないだけで、さっき述べたような状況に出くわすと困った顔をする。
僕はとりわけ色盲の人がどう感じるかについて敏感になることが多い。
それは、学生時代の友人が原因だ。
対戦落ち物ゲーム「ぷよぷよ」を彼と初めてプレーしたとき、彼は「こんなん分かるかよ！色盲をばかにしてんのか」と言った。
なるほどその通りだ。画面上部から落ちてくる「ぷよ」は色でしか判別できない。細かく見れば色によって形も異なっているのだが、分かりにくすぎる差だ。
何か新たにインタフェースを設計するとき、色のコントラスト、とりわけ緑と赤の差を考える癖がある。
本当ならもっと色々と考慮すべき点はあるのだが、いかんせん自分の経験の範囲でしか考えられず、自然に出てくるのはこれが精一杯だ。
ユーザー(いわゆるペルソナ)をどこまで具体的に想定できるかが、よいデザインを生むもとになる。
「誰のためのデザイン？」と問われて「あなたのためのデザインだよ」と答えたいが、自分の中の“あなた”は、なるべく多く揃えておきたい。
データベーススペシャリスト試験
例のごとく勉強せずに挑んだわけだが。
午後２でメタデータが登場。
問題の下読みでメタデータ、XMLが見えた段階で「メタデータ キターーーー！」
毛色の変わった問題で、結果はさておいて面白い問題だった。
しかし設問は実にありえない設定で、ツッコミどころ満載。
顧客が任意のDTDのXMLを送りつけてきて、
その任意の要素名をカラム名にもつテーブルを自動生成して、
んでもってそのテーブルが顧客数分だけあるんだってよ。
派遣会社の顧客数ってどれだけあるんでしょうねー？
『ピープルウェア』より
「プロセス改善が目標として設定されたとき、おっかないプロジェクトを改善対象から外そうとする。不幸にして、このおっかないプロジェクトは、おそらく改善する価値があるものなのだ」
「バーを上げることはリスクの増加を意味する。あなたが有能になればなるほど、あなたはリスクを負う。それをやらないのなら頭がおかしい」
添え状のモデル
メモ。
他者に提案するものを作ったら、それを見てもらうための添え状も書く。添え状によって他者の関心を誘導する。
添え状の文書構成は、「私―あなた―私たち」というモデルに従わせる。
これに論理展開のモデル「所与―理由―結果」を組み合わせて、次のように書く。
・現状に対する所与としての「私ができること」 ・提案を見てほしい理由としての「わたしから見たあなた」 ・その結果生まれるであろう状況としての「わたしとあなたの間で共有できる価値」
null を返してはいけないのかなあ？
「nullを返してはいけない理由(Saisse's Wiki 2004-04-06)」について。
面白く読みました。
確かにnullを返そうかどうしようか、迷う状況も数多くあります。ただ、ちょっと反対意見を。
すごくありきたりな結論だけど、null を返すことはアリでしょう。
理由は「null は取り得る値の範囲の一部」だから。
安易に null を返すことはモデルのバグの放置につながる、というのはすごくよく分かります。
ただ、それも「安易に」というただし書きレベルのような気がします。要は契約をどこで交わすかという話ではないかと。
サンプルコードに次のようなインタフェースが挙げてありました。
Hoge getHoge();
boolean isHogeGettable();これはすなわち次のコードと(意味的には)同義だと考えます。
/**
* @return Hoge オブジェクト。存在しない場合には null
*/
Hoge getHoge();
「(1)あるかどうかを判定し、(2)ある場合にのみ値を取得する」というプロトコルをクライアントに規定するという意味では、差がないように思います。
また、isHogeGettable()メソッドがあろうとなかろうと、getHogeメソッドは null を返すべきでしょう。getterメソッドに assert が書いてありますが、これは setter 内もしくは getter のクライアント側コード内に配置するべきだと思います。
逆に null を返せないと困る状況があります。たとえば範囲クラスの類です。
class DateRange
Date getStart(); //日付の最初を返す
Date getEnd(); //日付の最後を返す
}
class IntRange {
int getStart(); //最初の数値を返す
int getEnd(); // 最後の日付を返す
}
範囲の片方が開放されているRangeももちろん存在します。その場合は null を返すようにしたい。しかし IntRange クラスの値はプリミティブ型で扱いたいので、返すのに適当な値がありません。
Integer 型を返すのも嫌に感じて、hasStart()/hasEnd()メソッドを追加しました。
(「null を返すべきじゃない」という立場にたつと、DateRangeクラスでも hasXXXXメソッドを採用することになるはずです。ただし、それでも getter は null を返すように設計したい)
もちろん、次のようなインタフェースで null を返されるのは非常に困りもの。
0件のCollection を返して欲しいところです。
(速攻で NullPointerException が出ることでしょう)
/**
* 指定の条件で問い合わせた結果の一覧を取得します。
* @param criteria 検索条件
* @return 見つかった Foo オブジェクトのコレクション
*/
Collection queryFoo(Criteria criteria);
groovy を俯瞰できるページ
groovy のシンタックスを一覧できるページ。
http://viva.sourceforge.net/talk/jug-mar-2004/slides.html
クロージャとかMarkUpとか。
惚れ惚れするよ。
素敵な図書館の近くに住みたい
むかしから図書館のヘビーユーザーでした。
「書物を手元に置いておきたい」というフェチシズムが自分にはあまりないのが、何ともありがたいところです。
かつて川崎市に住んでいた頃は、神奈川県立川崎図書館に足繁く通っていました。
理工書のみで10万冊に上る蔵書数があり、新刊も素早く入架します(試しに新着図書を見てみてください)。
仕事で使う本は、もっぱらここで借りていきました。借り直しに次ぐ借り直しで、半年ほど借り続けたこともあります。
母校の大学図書館は、市民にも開放していました。
大学付属なのでその蔵書は数もさることながら質も高く、まったくもって理想的です。
ただ一方で、一般書籍はそれほど充実していません。
市民開放している大学図書館と、川崎図書館のような一般書籍が充実した図書館。
これらが歩いて行けるような場所に住みたい。
…って、そこはどこなんだろう？
すごい人は昔からすごい
PoEAAの読書会で知り合った人が薦めるものを、気にしてさまよっています。
いまホットなのは Seaser2。
これに関わっている方々を見て、NIFTY－SERVEのFDELPHIを見ていた頃を思い出します。
その頃の私はコンピューティングに関わってまだ1年くらいのペーペー。
FDELPHIというフォーラムの雰囲気は、ビギナーには懇切丁寧、手達はハイレベルな話で盛り上がる。
暖かく、かつ技術者の真剣な魂が交錯する、とても素敵な場でした。
私のコンピューティングに関する価値観はこのフォーラムで育てられたといっても過言ではありません。
(あとはFPROGかな)
いちどFDELPHIのオフラインミーティングにも参加したことがあります。
Seaserまわりにいる方々は、そのころから熱く、素敵でした。
「Seaserのからさわぎ」に参加表明をしました。
IoCもAOPも、おそらく本質は理解してません。
勉強、研鑚するのはもちろんですが、FDELPHIでお世話になった方々の熱い姿を見られれば何よりの幸せです。
