antipop

2011-11-07

はてなブログはじめました

はてなブログという新サービスがリリースされたそうですね。というわけで僕も以下のURLで新しいブログを作ってみました。

http://kentaro.hatenablog.com/

よろしくお願いいたします。

Permalink | コメント(0) | トラックバック(0) | 22:40

idトラックバック

2011-11-05

藤村龍至/TEAM ROUNDABOUT『アーキテクト2.0』とウェブサービス

藤村龍至/TEAM ROUNDABOUTによる、建築家らへのインタビュー集『アーキテクト2.0』が非常に面白くて、いろいろ考えていたことが整理されたり、新しい知見を得たりした。ここでは、書評ということではなく、本書を読んで思い付いたり考えてみたりしたことについて、少し書き記す。

アーキテクト2.0 2011年以後の建築家像―藤村龍至/TEAM ROUNDABOUTインタビュー集

作者: 藤村龍至,TEAM ROUNDABOUT
出版社/メーカー: 彰国社
発売日: 2011/11
メディア: 単行本
購入: 1人クリック: 1回
この商品を含むブログ (6件) を見る

建築の物理性(一回作ってしまうと簡単には変えられない)というのは、普通には(特にウェブサービスから見ると)制約というか限界を画するものなのだが、それを肯定的にとらえなおすと:

物理性があるということは模型を作ることで誰もが体感しやすいモックアップを元に議論・判断を行える
いずれ建物として実現するためには、設計をどこかで「切断」しなければならないという強制力を持つ

というメリットを、たとえばウェブの設計と比較して見出すことができる。ウェブサービスには完成がなく、どこまでいってもベータ版であり、それが故に常に成長し続けることが可能である面に良さを見出せる一方で、物理的な制約を持つがゆえに、文字通り太古の昔から構築への意志・協働の技術に磨きをかけてきた建築に、学ぶべきところがおおいにあるだろうと思う。

一般に、ウェブサービスの(建築と比較した時の)非構築性の良い面については贅言することもなかろうので省略するとして、一方で、どこまでも「工学的」にことが進めてしまえるウェブサービスへの評価は、それがゆえに非常に制約されたものになってしまっているように見受けられる面もある。本書においても、70年代以降ますます乖離を広げる一方の「組織派」「アトリエ派」という軸を提示した上で、第三の道を行く旨宣言が行われているが、ウェブサービスにおいても似たような状況が見出せるかもしれない。

それはたとえば本書においては、今世紀に入ってからの梅田望夫氏/西村博之氏の言説の比較、ひいては、それは戦後日本における知識人の「大衆」に対する「希望と絶望/諦念と軽蔑」という両軸の21世紀版であるという形で提示される。本書はもちろん触れないが、ウェブサービスにおける後者(ひろゆき氏)的な「工学的」立場は、10年代に入ってますます勢いを増している状況であることは、それが何かを具体的に明示するまでもなく、ウェブ界隈を観測している者なら誰もが感じるところだろうと思う。

その時に、たとえば藤村氏の主張するような「批判的工学主義」のような、「第三の道」をいかにして構想可能なのかということは、ウェブサービス業界においても、考えられてもいいだろう。その際に、冒頭に述べた物理性(濱野智史氏の言葉では「模型性」)をいかに導入していくかが、ひとつのポイントとなるかもしれない。

それは単に物理的/情報的という違いに留まらず、設計プロセスにおけるコミュニケーションの精度を上げるための方法論であり、また、コミュニケーションの幅を広げるためのものでもある。情報環境におけるコミュニケーションの有用性はいまさら問うまでもないことではあるが、かといってそこだけに留まっていることが最上というものではないだろう。その時、ある種の「模型性」を導入することが、よりよいコミュニケーションを促進することにつながるのであれば、わざわざそれを回避する理由もない。

問題意識は、少くとも藤村氏が述べるような意味での建築業界におけるそれと大きく異るところのものではない。「模型性」が具体的にどういうものであるかという点については、今後も他業種を含めた事例を参考にしながら、あれこれとあたりをつけつつ、考えていきたいものだと思う。

Permalink | コメント(0) | トラックバック(0) | 21:30

idトラックバック

2011-11-04

released HTML::ValidationRules 0.01

HTML::ValidationRulesをreleaseしました。

http://search.cpan.org/dist/HTML-ValidationRules/

元は、僕が適当にでっち上げたものを、同僚のスーパーエンジニアid:wakabatanが叩きなおしたので、信頼のクオリティになっています。また、FormValidator::(Simple|Lite)用のプラグインも同梱しておりますので、いい感じに使いやすくなっていると思います。

どうぞご利用ください。

Permalink | コメント(0) | トラックバック(0) | 00:43

idトラックバック

2011-11-01

HTML5のclient-side form validationで書かれたattributeからvalidation rulesを抽出し、client/serverでルールを共通化するモジュールを書いた

Validation Ruleの記述ってけっこう面倒で、うまい方法を思いつけないのでいたのですが、今日、なんとなくHTML5にclient-side form validation specなんてものがあるんだから、それを使ったらいいんじゃないかと思って、ちょっと実装してみました。

以下のようなメリットがあるのではないかと思っています。

client-side form validationを使いつつ、server-sideでも同じルールを別の形式で書くのは無駄感。
HTML5が、validation rulesをHTMLというフォーマットによって定めているとみなせば、client-side/server-side両方でそれを使えばいい感じになるのでは？オレオレフォーマットをいちいち憶えるより汎用的でいい気がする。
デザイナ/プログラマが、同じvalidation rulesを触ることによって、formが受容し得る値の認識が共有できる

id:cho45さんがFormValidator::Simple::Plugin::V8というのを書いて、JavaScript経由でclient/server間のvalidation rules共通化を提示しているのですが、こっちはそのHTML5版という感じですね。

使用例を示します。こういうHTMLがあるとして、普通にclient-side form validationなルールをあれこれ書きます。ここまでは、まあ普通にやるよね、という話。

<!doctype html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>HTML5::ValidationRules</title>
  </head>
  <body>
    <form method="post" action="/post">
      <input type="text" name="text" pattern="[a-zA-Z0-9]+" maxlength="255" />
      <input type="url" name="url" maxlength="255" required />
      <input type="email" name="email" maxlength="255" required="required" />
      <input type="number" name="number" min="200" max="800" />
      <textarea name="textarea" maxlength="1000" required></textarea>
      <input type="submit" value="submit" />
    </form>
  </body>
</html>

そのHTMLから、以下のような感じでvalidation rulesを抽出します。

use HTML::ValidationRules;

my $parser = HTML::ValidationRules->new;
my $rules  = $parser->load_rules(file => 'form.html');

上記のHTMLからは、以下のようなルールが抽出されます。

[
    text     => [ [ HTML_PATTERN => '[a-zA-Z0-9]+' ], [ HTML_MAXLENGTH => 255 ] ],
    url      => [ HTML_URL    => [ HTML_MAXLENGTH => 255 ], 'HTML_REQUIRED'     ],
    email    => [ HTML_EMAIL  => [ HTML_MAXLENGTH => 255 ], 'HTML_REQUIRED'     ],
    number   => [ HTML_NUMBER => [ HTML_MIN => 200 ], [ HTML_MAX => 800 ]       ],
    textarea => [ [ HTML_MAXLENGTH => 1000 ], 'HTML_REQUIRED'                   ],
]

この形式は、FormValidator::Simple->check()にそのままわたせるようになっているので、同梱のFormValidator::Simple::Plugin::HTMLをロードした上で、$rulesをcheck()にわたしてやるだけです。簡単ですね。

use FormValidator::Simple qw(HTML);

my $query  = CGI->new;
my $result = FormValidator::Simple->check($query => $rules);

いまんとこ、とりあえずコンセプトを示すために簡単にできそうなとこからやってみただけで、仕様への対応状況が全然なので、もう少し対応を進めていきたいと思っています(あと、仕様自体も今日初めて必要そうなとこを読んでみた感じなので、理解が怪しい……)。よろしくどうぞ。

追記

id:tokuhiromさんより以下の通りコメントいただきました。

テンプレートエンジンとかつかってるときにどうするか、がむずかしいところですねー

フォーム要素が静的であれば、HTML::Parserにとって不都合ない限りはだいじょうぶなのかなと思っているのですが、問題はご指摘の場合を含む、動的なルール・要素の増減がある場合で、ざっと以下あたりがあり得るかなと思います。

HTML::ShakanやHTML::FormFuなどのモジュールを使ってフォームを生成している場合
テンプレート内の条件分岐でruleを出し分けしたり、input/textareaを増減たりしている場合
JavaScriptにより、クライアントサイドでruleを出し分けしたり、input/textareaを増減たりしている場合

~~(1)については、このモジュール的には(とりあえずは)想定していない用途という感じで、(2)~~(3)についてはちょっとあきらめる感じですかね……。

追々記

上記場合の(1)(2)については、ユーザリクエストに沿ってテンプレートをレンダリングした後に(WAFだったらafter triggerみたいなところで)、$parser->load_rules(html => $string)のインタフェイスを使ってルールを生成し、ユーザのセッションデータあたりに保存しておくという方法で、一応解決可能ではありますね。毎回やるのは遅くなりそうなので、セッションにルールがあったらそれを使い、フォーム生成の条件が変わったらセッションに入れたルールをクリアして新たに生成する、みたいにしたらいいのかな。