UX Kanazawa Vol.5に参加してきた

※ 早いもので実際に書いてる今日は参加した日から2週間以上が過ぎてしまいました…

今回は UX Kanazawa で続いていた講義 + ワークショップ形式ではなく発表のみ、午前のみというライトな感じで。午前のみはいいよね。参加しやすい。

場所は一部でツチノコと話題のDMM.comのラボの方（金沢事業部）の新オフィス。カラフルな入り口そばの会議室で。さすがに執務エリアには入れないけど、そっちはもっとすごかったので、思わず「ジョインします」と言いそうになりました。この辺じゃあんなオフィスは他にないだろうなぁ。

発表は

  • プロセスの導入 x 2 (DMM.com Labo / PFUソフトウェア)
  • デザイナのロールとバリュー

の3本立て。

特にプロセスの導入の話は面白かった。DMM.com Laboは前行程から、PFUソフトウェアは後行程からの導入という違いも面白かった。

すべて共通するのは

既存の枠組みを取っ払って全体的なアプローチで取り組まないといけない

ということなんだなーと思った。デザイナはシステムの上の方を飾る仕事ではないというか、デザインを実現するためにより広い視野を持ち、広い領域に関わり、より深い成り立ちを理解する必要があるというか、そういう感じ。

なんつーかフルスタックエンジニアの話にも通じるよなーと書きながら思った。

あと、言葉が一人歩きしちゃうのはどの分野も一緒だなと思った。

最後に、場違いな自分のつぶやきを引用しておきます。

UXデザインは従来からやっているデザインそのものの行程には実は大きな変化は起きない。製品改善のサイクルだったり、プロトタイプから練り上げるための根拠作りだったり、そういう部分でモノが実際によくなる実感が得られれば、導入に対してもしかすると大きな障壁はないのかもしれないなと思った。もちろん大手を振るって実践するには組織的な壁があるとは思うけど、少なくともTDDのように実装の行程を変えてしまうという破壊的な変化を必要としないという意味では、やりやすいのかもしれないなーと思ったりした。

逆にペアプロのようにノウハウを伝承しやすい方法論はまだないみたい。そこは逆にUXデザインというかHCDプロセスの普及の課題なんだろう。

今回の UX Kanazawa はお勉強や発見というインパクトではなく、気づきやふり返りといった小さな、でも手応えのある内容だったように思う。割といつもインプットでいっぱいいっぱいになるので、こういう揺さぶりはとても嬉しい。

ありがとうございます。次も楽しみだ。

RTMのタスクにタグ付けするようにしてみた

塩漬けにしていたRTMアカウントを活用し始めてから2ヶ月あまり、タスクのタグを活用しようと思い立った。

いや、実はタスクのタグ付けはずっとずっと以前から考えていた。iCal1でスケジュール管理していた頃から、全部のタスクがフラットで、イベント名でしか区別がつかない状態はうまくないなと感じていた。分類をしたければカレンダーそのものを切り替えるしかないというのもちょっと窮屈。

ということで実際にやってみた。

Twitter / wtnabe: 今作ったRTMのタグ。building, buy, …

作ったタグは

  • building
  • buy
  • codereading
  • develop
  • lecture
  • meeting
  • operation
  • research
  • study
  • writing
  • reading
  • develop
  • design
  • tv

こんな感じ。

タグ付けを試してみた結果、とても具合がいい。

タスク管理としては Trac と RTM の二刀流になってしまっているのだが、Trac の Ticket はあくまでチームで共有すべき課題や情報であり、そこには「どういう性質のタスクなのか」、例えば「bug fix」なのか「問い合わせ対応」なのかといった情報はあるが、「日本語の書き物」なのか「開発」なのか「作業」なのかといった区別は記述しにくい{{fn '記述できなくはないのかもしれないが、たぶん分かりやすくはならないのではないか。' }}。しかしこの記述こそが時間の予測にとって重要な要素なのではないかと最近は感じている。例えば「作業」はかなり正確に予測できるが「開発」は不確定要素が増えるので予測時間には幅が必要、といった具合である。こうした判断の「手がかり」をタグとして表現することで、タスク全体の管理やリスケジューリングの可能性や実施を考えやすくできると思う。

最後に、話はそれるが iCal の感想なぞ。

iCalendar は vCalendar をもとにしており、vCalendar はもともと PIM 上でのスケジュール管理に活用されていたフォーマットなのだが、やはり古さは否めないなーという思いを新たにした。iCal は DAV アクセスを手に入れたおかげで情報の共有にはとても適したものになったけれど、アクションの管理とはやはり違うんじゃないかと今は思っている。

cf.

[追記]

携帯のアドレス帳に Inbox のアドレスを追加した。

記述する場所反映される場所
Subjectタスク名（とメタデータ）
本文ノート

に対応しているらしい。

あとで知ったが、下記のフォーマットでメールからも直接タスクの詳細を記述できる。けど携帯で打っている場合は補完が効くわけでもないのでそこまで凝った使い方はしなくていいような気がする。

[追記]

Remember The Milkが「Smart Add」でさらにキーボードフレンドリーになった - ただのにっき(2009-09-10)

タスクを登録したあとにちまちまタグのところをクリックしてタグ付けしていたけど、そんなこと必要ないってことにこの記事を見て気がついた。

タスク名 #タグ ^期日

で一気に記入できるし、補完も効く。これはいい。

なるほど。ショートカットキーの活用はまだあまり意識していない（むしろまず esc を殺したい）けど、これはいい。

  1. 実際には Thunderbird + Lightning ↩

『Googleを支える技術』読了

実はこの本はスルーするつもりだったんだけど、最近、やっぱこの本は読んどいた方がいいんだろうなと思い直して手にしてみた。

よかった。

何がよかったか。書き手と編集の仕事が素晴らしい。

正直、内容的にはあちこちのサイト、ブログなどで散見できていて、新しい情報は多くない。だけど断片が離散している状態よりも一冊の本になっている方が当然見やすい。それが優れた作り手の手によるものならなおさらだ。

まず図が豊富で、それほど技術に強くない人間でもある程度までは理解した気になれる。もちろん、技術の分かる人間にとってもこの図は非常に有用である。

次に文章が読みやすい。正直、技術系の本に読みやすさは求めない気持ちで挑むことが多いのだが、この本は久しぶりによくできた縦書きの本を読んだような錯覚に陥った。それくらいに書く行為の基本がよくできていると思う。節、章のまとめもいい具合。いいタイミングでくり返し説明されるのでしっかり内容が頭に残る。

しかし見ると著者はライター歴が長いわけでもなさげ。なおかつ「スーパークリエイター」。天は二物を与えるんだねぇと、少し恨めしい気持ちになった。

良書です。

もちろん編集もグッジョブ。というかここ数年の WEB+DB PRESS の仕事ってほんと感心する。以前は「あー Java の雑誌ね」と見向きもしなかったんだけど、LL 全般を扱い出した辺りから急に幅も奥行きも広がって来ていて、構造化プログラミングを特集されたときには正直「やられた」と思ったものだ。ここにきてこれか、と。

次は「サーバ/インフラ」か？ いやー「集合知」勉強したいんだよな。

バージョン番号…

なんか今になってものすごく初歩的なことなんだけど、Perl で

print $];

はちゃんとバージョン番号を返すのに

use English;
print $PERL_VERSION;

は何も出ないな…。まぁ困らないっちゃ困らないんだけど、どうなってんだろ、これ。

Emacs の M-x grep をマルチエンコーディングに

なんかたまにエンコーディングの混ざっているファイル群に対して検索を掛ける必要があったりするんだけど、そのときだけ mi を起動したりしてものすごい敗北感を味わっていたんだけど、lgrep を使うことにした。

厳密には以前から emacs の grep で lgrep は使っていたんだけど、recursive に検索してくれなくてなんじゃこれめんどくさ、と放置気味だったわけ。

今回一念発起してこうしてみた。

(setq grep-program "find . -type f -a -print0 | xargs -0 lgrep -nk -Ou8 ")
  • UTF-8 出力で
  • 半角カナを全角カナに変換してから検索する

ようにしてみた。うむ、やっと便利になった。バイナリファイルも大量にあるっつー場合は適当に find の条件を書き換えて使うこと。lgrep を知らない人は勝手にググること。

Emacs22 の font-lock の色使いが terminal で再現できなくて意味不明

頑なに拒んでいた unicode 化の波なんだけど、一応 javascript のネイティブは unicode だしなということで渋々対応を考え始める。1

なんで渋っていたのかというと、mule-ucs を組み込むと Emacs の起動がやたら遅いから。Debian マシンは当然 CVS 版が入ってるわけないので、これに関しては mule-ucs で我慢することを決め込む。Emacs は終了しないで使う。2

問題は手元の OSX 版。mule-ucs を組み込む方法が分からん。3fink で入れることにすると Emacs からビルドし始めるので、それだったら CVS 版でいいじゃないかと思い立ち、Carbon Emacs を落としてくる。立ち上げる。おぉ、OS ネイティブのウィンドウだ。こえぇ。Emacs は terminal でしか使ったことがないので自分のウィンドウを持ってる Emacs を見るとビビる。いそいそと Carbon Emacs 内のディレクトリをたどり、

emacs -nw

すると普通に terminal の中で起動してくれた。よしよし。

……。

あれ。色分けがおかしくね？ font-lock は有効になっているんだけど、色の付き方がずいぶん中途半端になってしまう。うーん。もう一度ウィンドウを持ってる Emacs を立ち上げてみる。あー。何この中途半端な色。こんな微妙な色が terminal で出るわけないじゃん。

うーん。Carbon Emacs だからかなぁ？と思い、意を決して Fink から Emacs 22 のビルドを開始。その間はずっとサーバ上で作業するので手元の処理が重くなっても気にしない。で、起動。

やっぱり色分けの意味が分からんorz

どうやら Emacs 22 の font-lock の色分けは基本的に terminal での利用は考慮していないっぽい。まいったなぁ。Emacs は細かいカスタマイズって面倒でやってないのでこういう事態が起きるとさっぱり分からない。

※ とりあえず Emacs 21.3.5 にして回避した。

[追記] ansi8 + M-x customize で emacs22 への準備 で Terminal でも使えるようになりました！

  1. ちなみにこれまで書いてきた ecmascript のコードは us-ascii 以外の文字を書かないという方法で回避してきた。 ↩

  2. Debian の apt-get で mule-ucs をインストールするとシステムワイドな emacs の起動時の設定に mule-ucs を組み込むスクリプトがセットされてしまう。それを勝手に外すのはさすがにどうかと思うのでやめた。 ↩

  3. Debian と違って手で入れれば ok だった。 ↩

Ruby で YAML はすごい楽じゃん

プログラマーのための YAML 入門 (初級編) とか Yaml.rb – Yaml for Ruby とか参考に、適当に YAML で書いたファイルを用意して

require 'yaml'
require 'pp'

fh = File.open( FUGAHOGE )
yaml = YAML.load( fh )
pp yaml
puts yaml.to_yaml

こんなんでテスト。すっげ。Hash の配列とか配列の Hash とか Hash の Hash とか、正直 Ruby で書くのはだるいんだけど、YAML だとばかみたいに簡単。なんだこれわ。もっと早く試すんだった。Ruby では標準添付っつーのがサイコーに楽。

しかしこうなると yaml-mode.el がほしくてたまらない。

PukiWiki fork 向け試案

※ まずはじめに、この日記はおれが fork したる！という意思表示ではありません。お間違えのないよう。

pukiwiki.org ドメインが for sale になりましたな。

確認できるのは

  • 増井氏が pukiwiki.jp を取得し、死んでた users-ML に報告
  • heno氏は dev の開発日記に書き込み

やりとりする気なさそうに見えるなぁ。というか pukiwiki.org のサイトは通常の状態では閲覧不可能なのに、なんでいつまでもここにどんどん書いていくのかな、heno 氏は。hosts 書き換えれば見ることができるっていうのと、そのまま使い続けていくのとは別な話だと思うんだけど。

というか、開発以外の話なんだし、自分で blog 用意してそこに書いてくれるのがいちばんありがたい。

  • fork しようかという動きもあるが、愚痴を言う場所になりつつある感じ？ つまり 2ch の PukiWiki スレがもう一つできたようなもんか？

ただ、個人的には fork は悪いアイディアじゃないと思う。サーバ管理やサイトの運営ポリシーの問題を除いてもおおざっぱに

  1. PukiWiki 内部に非常に手を入れにくい作り
  2. アップデートしにくい作り
  3. 設定ファイルやコード中のコメントが日本語じゃなくて敷居が高いなどの問題

があるわけで、これをどうにかしようと思ったら、

  • Wiki 記法のパーサ以外全とっかえ

でいいんじゃないかと思う。1というわけで以降は fork する人向けメモ。（あくまで自分で fork するぞ宣言でないことに注意。）

まず、PukiWiki 全体で global 宣言しまくりで、名前空間がフラットで、それを避けるために関数名とかやたら長くなったりして、超やな感じなので、これはもう全部クラスに分けちゃう2。あとアップデートしにくいのと設定ファイルの問題は

  • 設定ファイルの役割を最小限に絞って、あとは全部 Web インターフェイスで設定するように変更する

で、その設定情報がデータ領域に入るようにすれば、設定ファイルの中のコメントが英語だとかアップデートしにくいだとかの問題を一挙に解決できる、はず。特にコメントの問題は単に設定ファイルがでかすぎるのが問題なんだと思っている。あんだけでかけりゃそらコメント要るし、コメントがすぐ読めなきゃそら面倒くさくてやっとれんて話ですよ。

  • そのためには認証周りをもっと扱いやすくしないとダメ

なんだけど、これは前からそうなんだから、この際だからガンバレと。

もひとつ、コード中のコメントが英語でカスタマイズしにくいって問題も、そもそもコメント見ないと何やってるのか分からないような長大なブロックなどが問題なのであって、もっと読みやすいコードにすることが前提にくるべき。あと phpdoc をフル活用する方向にして、それと簡単な図3をサイト上に載せておけば、ずいぶん楽に全体の構造が把握でき、かつそれぞれのパーツの役割も確認しやすくなると思う。

果たしてそれは PukiWiki をベースにする意味あるのか？という疑問は残るけど、自分にとって PukiWiki が PukiWiki であるいちばんの理由は Wiki 記法なので、自分にとっては意味がある。ま、極端な例だと思うけど、しっかりした何かがベースにないと fork できないままで終わると思うし、fork しない方がいいんじゃないかと思う。

  1. 実際には細かく見ないとどこを使ってどこを捨てるかは言えないけど。プラグインだってどれが現在進行形でメンテされててどれが obsolete かもよく分からないし、ここらでご破算にして整理してもいいと思う。 ↩

  2. 実際には 1.4 以降はあちこちで class は導入されているので、あとはコアの部分をどうするかという問題だけかもしれない。プラグインの設定をその中に定数で書くってのもやめた方がいいな。 ↩

  3. どのクラスとどのクラスがどう絡んで何やってる、っての。別に UML とかそんなの要らないし、あっても嬉しくない。 ↩

アクセスさらに増えた

今度は カトゆー家断絶 から。

人気サイトこえー。コメントには「メモメモ」しか書いてないのに。1日5000なんて行ったの初めてじゃなかろうか。デイリーポータル効果と言えばデイリーポータル効果だな。いったい誰がどういう紹介してくれたんだろう。分からないのがもどかしい。

RDoc 勘違いしてた

Ruby 1.8 に取り込まれたのは知っていたけど、これは HTML のドキュメント生成に使わなくても便利なんだ。

require RDoc::usage

なんかを使って、簡単にスクリプトにヘルプ表示の機能を入れることができる。しかもスクリプト内のコメントをそのまま使えるので二度手間にならない。これいいな。

参考 RDocUsage

正直、多いな。

いや、自分で作っておいてなんなのだけど。

ページタイトルもオブジェクト化してみた。メインタイトルとサブタイトルをプロパティに持って、テキトーなメソッドでそれを吐き出す。 しかし、いやほんと。くじけそうな気がしてきた。まだレイアウトの調整とか全然始めてないのに。

About

例によって個人のなんちゃらです