Hatena::Groupasakura

浅倉卓司@blog風味? このページをアンテナに追加 RSSフィード

Error : RSSが取得できませんでした。

2006-03-31(Fri)

patchを送るべきか、動的にpatchをあてるべきか

| 17:45 |  patchを送るべきか、動的にpatchをあてるべきか - 浅倉卓司@blog風味? を含むブックマーク  patchを送るべきか、動的にpatchをあてるべきか - 浅倉卓司@blog風味? のブックマークコメント

 tagのAND検索をするにはhas_manyなテーブルに対して-andや-norを指定してJOINできればいいんだけど、そのためにはClass::DBI::Sweetが使っているClass::DBI::Sweet::SQL::Abstractを変更しなくちゃ駄目っぽい。

 対応するには

  • CDBI:SweetとCDBI:Sweet:SQLAbstractを継承したクラスでも作ってそちらを使う
  • CDBI:Sweet:SQLAbstractのメソッドを上書きするモジュールを作る
  • CDBI:Sweet:SQLAbstractのpatchを送ってみる

の3択かな~。

 もっといい方法はないものか。。。


ひとりで勝手にHackathonに協賛してみるtest

| 22:22 |  ひとりで勝手にHackathonに協賛してみるtest - 浅倉卓司@blog風味? を含むブックマーク  ひとりで勝手にHackathonに協賛してみるtest - 浅倉卓司@blog風味? のブックマークコメント

 といっても明日用事があるので出来るとこまでですが~。

 お題は2つ。

 ひとつはClass::DBI::SweetをもっとSweetにするモジュール群。Pie(Aggregate Function)は出来てるので、あとはhas_manyのヤツ。名前どうしよう……。

 もうひとつは、うっかりRD-X5RD-X5EXにしたら番組ナビゲータが使えなくなったので、その対策。


番組ナビゲータ用のツールを書いた

 これでなんとか使える感じ。予約がうまくできないのでアレだけど予約済みの確認はできる。これで「予約忘れたorz」ってことはない。予約はまあ標準のインターフェイスを使えばいいわけで。面倒だけど。

 2chをのぞいたら作者の人が対応するっぽいので公開しなくてもよさげ。

 にしても、番組ナビを新番組シーズンに使えないのはイタイ……。


Class::DBI::Sweet::SQL::Abstract はなんとなく分かった

 うーん、面倒くさそうだ……。

 やって出来ないことはなさげ。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060331

2006-03-30(Thu)

確かにtagのAND検索をするモジュールが必要だ。

| 21:30 |  確かにtagのAND検索をするモジュールが必要だ。 - 浅倉卓司@blog風味? を含むブックマーク  確かにtagのAND検索をするモジュールが必要だ。 - 浅倉卓司@blog風味? のブックマークコメント

 ついさっき

はてなブックマークだと、入力時に一旦 parse して分解してしまって、正規化した tag テーブルにひとつのタグでひとつのレコードという形で保存してある。これだと tag に index 張れば普通に検索できる。というか普通こうするんだと思ってた。

Tags with MySQL

ってのを見かけて、

普通そうでしょー、と主張してみる。というか、RDBMSは正規化してナンボだと思ってるので。全文検索使うならRDBMSじゃないほうが便利な気がするし……。

と思ったのだけれど、コメントを見ると

# kazeburo 『tagテーブルを作ってレコードを追加〜っていうのが普通だと思います。

ただ、複雑なTagの検索、aとbを含んで、cとdを含まないエントリーとか言う時にboolean modeみたいな方法がとれたらSQLが複雑にならなくて楽だなということです』

とか書れてました。そういう時はClass::DBI::Sweetを使えば勝手にSQLが生成されて問題ないっすよ。こうやれば簡単に……あれ、できないっぽい?!


 うーむ。僕はCDBI::SweetのJOINを活用してサクっと解決するもんだと思ってて気にしてなかったのですが、もし本当にできないと*1ちょっと困る。

 SQLそのものはサラっと書ける気がするんで自動生成することそのものは問題ない気がするけど、どういうインターフェイスにするかは悩みどころ。

MyData::Article->search({
  'tags.name' => {
    -and => [qw/ foo bar baz /],
    -nor => [qw/ hoge fuga /],
  },
});

みたいな感じでしょうか*2


今日もYAPC::Asiaに行きましたよ。

| 21:52 |  今日もYAPC::Asiaに行きましたよ。 - 浅倉卓司@blog風味? を含むブックマーク  今日もYAPC::Asiaに行きましたよ。 - 浅倉卓司@blog風味? のブックマークコメント

 今日も思い出せるままに。

 弾さんの話を聞いた感じでは「utf8フラグ≒Stringフラグ」と考えたほうがいいみたいな気がしました。入出力の直後・直前でフラグを操作すればいいんだとは思うけど、全部でやってないとひどい目にあうしなぁ。Template-Toolkitってencodingを指定できたっけとか、DBD::mysqlって文字コード見てるのかなとか。

 Perl6はまあ事前に知っている話以上ではなかった気がしたけど、何か新情報はあったのかな。ちゃんと聞き取れてないので……。

 Haskellはなんかすごく好みの言語っぽい。入門書が出るとか聞いたので、是非とも買ってみよう。そうそう、Audreyさんを見たらなんとなくバグ猫たいにゃんを思い出したんだけど、分かってくれる人はいるカナ?

 svkは超便利っぽく聞こえたよ。さっそく使わなくちゃ。これで微妙に使ってたり使ってなかったりするSubversionをちゃんと活用できるか?



 ――とか、そんな感じでした。

 今日は2トラックになってて全部聞けなかったのが残念至極。

*1:ちゃんと調べてないんで、ひょっとしたらできるかもとか……。

*2:というか、こう書けばCDBI::Sweetで検索できると思ってた。実はできる?

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060330

2006-03-29(Wed)

YAPC::Asiaに行ったので感想などを。

| 00:19 |  YAPC::Asiaに行ったので感想などを。 - 浅倉卓司@blog風味? を含むブックマーク  YAPC::Asiaに行ったので感想などを。 - 浅倉卓司@blog風味? のブックマークコメント

 順不同。憶えてる順。

h2xsとか使うんだっけ?

http://asakura.g.hatena.ne.jp/asakura-t/20060328/1143471246

なんて書いたのは他にもっといいのがあった気がしたからだけど、ちょうど

ベストプラクティスとは、よりキレイで、安全で、効率が良くてメンテナンス性も高いコードを書くための、プログラミングの習慣です。このトークでは、Damian が彼の「ベストプラクティス」哲学を解説し、自分の Perl コードをいますぐに改善できる 7つのカンタンなコーディング習慣を紹介します。

Perl Best Practices

でmodule-starter(Module::Starter)の紹介がなされてました。

 あとはCPANに上げる前にはperltidy(Perl::Tidy)を使ったほうがよさげな気がしました。いまさらですが。


 Plaggerは編集ツールとして大変便利そうだと思っていたけど、フロー向けであってストック向きじゃない印象。だけど、今後の拡張によって「フローをストックに変える」可能性はあるような気がしました。


 他にもJSANは楽しそうなのでそのうちいじってみたいとか、Pugsもいじらなくちゃとか*1、orz.pmはこのためだったのねとか、他にも色々盛りだくさんでした。

*1:これは明日のPerl6の話を聞くと「いじり倒そう」になるかもね。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060329

2006-03-28(Tue)

Class::DBI::Sweet::Pie - Class::DBI::Sweetに集約関数を追加する

| 23:54 |  Class::DBI::Sweet::Pie - Class::DBI::Sweetに集約関数を追加する - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Sweet::Pie - Class::DBI::Sweetに集約関数を追加する - 浅倉卓司@blog風味? のブックマークコメント

 これでClass::DBIで集約関数が使いたくなっても困らないぞ、と。

 あとはドキュメントを整備したりテストコードを書けばいいかな……。

 YAPCが終わる頃までにはCPANに登録したいと思うんだけど*1、正しいモジュールの作り方をすっかり忘れてしまってますよ。h2xsとか使うんだっけ?


SYNOPSYS

  package MyData::CD;
  use base qw/Class::DBI::Sweet/;
  __PACKAGE__->has_a( artist => 'MyData::Artist' );
  use Class::DBI::Sweet::Pie;
  __PACKAGE__->mk_aggregate_function('sum');
  __PACKAGE__->mk_aggregate_function( max => 'maximum');

  package MyData::Artist;
  use base qw/Class::DBI::Sweet/;
  __PACKAGE__->has_many( cds => 'MyData::CD' );
  use Class::DBI::Sweet::Pie;
  __PACKAGE__->mk_aggregate_function('min');

  package main;

  # 一番高価なCDの価格
  $max_price = MyData::CD->maximum( 'price' );

  # fooさんのCDの合計金額
  $total_price = MyData::CD->sum( 'price', 'artist.name' => 'foo' );

  # fooさんのCDで一番安価なものの価格
  ($artist) = MyData::Artist->search( name => 'foo' );
  $min_price = $artist->min('cds.price');


ソースコード

続きを読む

Class::DBI::Plugin::AggregateFunctionでCOUNT(*)する

| 13:50 |  Class::DBI::Plugin::AggregateFunctionでCOUNT(*)する - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Plugin::AggregateFunctionでCOUNT(*)する - 浅倉卓司@blog風味? のブックマークコメント

 以下で動くはず。たぶん。

 類似のモジュールはClass::DBI::Plugin::CountSearchとかClass::DBI::Search::Countとかいっぱいあるので、あんまり意味はありませんが。

 COUNT(DISTINCT column)とかするときは使えるかもしれない。

package MyData::CD;
use base qw/Class::DBI/;
use Class::DBI::Plugin::AggregateFunction;
__PACKAGE__->mk_aggregate_function( count => 'counting' );

package main;
$count = MyData::CD->counting('*', artist => $artist);
$artist_count MyData::CD->counting('distinct artist');

*1Class::DBI::Plugin::AggregateFunctionも一緒に。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060328

2006-03-27(Mon)

Class::DBI::Sweet::Pie

| 12:37 |  Class::DBI::Sweet::Pie - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Sweet::Pie - 浅倉卓司@blog風味? のブックマークコメント

 気が向いたので集約関数を追加するClass::DBI::Sweet用のプラグインを作ってみました。

 Class::DBI::Plugin::AggregateFunctionとか作ってもいいのかもしれません。

  package MyData::CD;
  use base qw/Class::DBI::Sweet/;
  use Class::DBI::Sweet::Pie;
  __PACKAGE__->mk_aggregate_function('sum');
  __PACKAGE__->mk_aggregate_function( max => 'maximum');

  package main;
  # SELECT MAX(price) FROM __TABLE__
  my $max = MyData::CD->maximum( 'price' );

  # SELECT SUM(price) FROM __TABLE__ WHERE artist = 'foo'
  my $sum = MyData::CD->sum( 'price', artist => 'foo' );

ソースコード

続きを読む

Class::DBI::Plugin::AggregateFunction

| 14:10 |  Class::DBI::Plugin::AggregateFunction - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Plugin::AggregateFunction - 浅倉卓司@blog風味? のブックマークコメント

 というわけでClass::DBI::Plugin::AggregateFunctionも作りました。

 SQL::Abstractを利用していて、Class::DBI::AbstractSearch風になってます。

 ベースクラスを識別してClass::DBI::Sweetの時は上のを使うようにしたほうがいいのかな、と思いつつ。似てるけど別物だしなぁ……。


ソースコード

続きを読む

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060327

2006-03-24(Fri)

フローメディアを溜めただけのものがストックメディアだって? とんでもない!

| 23:32 |  フローメディアを溜めただけのものがストックメディアだって? とんでもない! - 浅倉卓司@blog風味? を含むブックマーク  フローメディアを溜めただけのものがストックメディアだって? とんでもない! - 浅倉卓司@blog風味? のブックマークコメント

 ちょっと待ってよ。確かにネットではフローな情報を溜め込めるけど、溜め込むだけがストックメディアではないでしょ。

しかし、既存のフローメディアは「在庫コスト」がべらぼうに高い。一年分はおろか一ヶ月分の古新聞をためておくことすら通常耐えられない。既存のフローメディアがフローに甘んじていた最大の理由が、この在庫コストだったと結論づけてもいいだろう。

ブログは自動ストック機能付き

 フローメディアがストックメディアじゃないのは、単に「在庫コスト」の問題だけじゃない。少なくとも断片化した情報をひとまとめにして(編集して)、参照しやすくなっていないとストックとしては役に立たない。「在庫コスト」は安くなったかもしれないけど、フローのままではそれを「理解するコスト」はやっぱり高いのだ。

 例えば、最近弾さんが「Tie::SaveLater」関連の記事をいくつか書いているけど、これをフローのままで必要な情報を得ようとすると結構コストが高くつく*1。これが再編集されていれば――あるいは最低限として適切な「目次」がついていれば、必要な情報を見つけるためのコストは低くなる。

 だからこそpalさんは

一方で、ネットに関しては

フローメディアに当たるのは

各種ポータル、ブログ、SNS、掲示板など。

ストックメディアに当たるのは

wikiしかないようにも見える。

フローメディアとストックメディア

――と書かれたんじゃないでしょうか。

 もちろん編集するには相応のコストがかかりますけれど、コストをかけるだけのメリットはあると言えるでしょう。少なくとも「まとめサイト脳」なんてネタがでる程度には「編集済みのコンテンツ」には価値があると思います。

 将来的には自動的にストック化するシステムができるかもしれませんが、現状の「検索で見つけられる(かもしれない)」程度ではストックメディアとしては不十分と感じます。


 ……という話をきっと「あとで書く」んだと思いますので、期待して待ってます :)

*1:少なくとも検索してから「当たり」を見つけるまで時間がかかる。

佐藤秀佐藤秀2006/03/26 18:09ちなみに私は、ブログは時系列的にストックされてるし、カテゴリー別でも閲覧できるので一応これも編集の一種と思います。実は「編集」って目的によって変わるので何をもって「編集」とするかかなり難しいのではと。

asakura-tasakura-t2006/03/26 18:42「カテゴリー別」でも弱いと思ってるんですよ。カテゴリー別表示が『適切な「目次」』になるかと思ったこともあるんですが、やっぱり物足りないなと。
「編集が目的によって変わる」というのは正にその通りで、逆に「目的を達成するには編集が不可欠」だと思うのです。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060324

2006-03-23(Thu)

「表現」が増えるわけじゃなくて、「全ての表現がウェブに集まる」ってことなのですね

| 00:02 |  「表現」が増えるわけじゃなくて、「全ての表現がウェブに集まる」ってことなのですね - 浅倉卓司@blog風味? を含むブックマーク  「表現」が増えるわけじゃなくて、「全ての表現がウェブに集まる」ってことなのですね - 浅倉卓司@blog風味? のブックマークコメント

 ちくまのサイトに梅田さんのインタビューがあるというので*1読んだら、

この本のなかに、注意深く、「芸術的な領域を除けば」というフレーズを入れておいたのですが(『ウェブ進化論』第四章、138ページ)、その領域(の総表現社会)は、もうすでにあったのではないかと思います。出版社を頂点としたシステムがあり、そこにはいろいろなもの(小説)が送られてきて、それを読み評価するのが編集者の仕事、ということだったと思います。

■「総表現社会」と出版社

――なんてコメントしてるじゃないですか。つまり「総表現社会」の「表現」という言葉は、誤解されるだろうと認識した上で使っているわけですね。ひどいや(笑)。


 「表現する人」や「表現」そのものの数が増えわけじゃなくて「今まで目にすることのなかった表現が見えてしまう」って話なんですね。「総表現社会」というのは「全ての(表現したい)人が表現する社会」ではなくて、「全ての表現がウェブに集まってくる社会」という意味なんでしょう。そういう風に書いてある気もするけど、もしこの理解で正しいとすれば分かりにくすぎると思います*2


 そして増えた表現はGoogleを始めとするテクノロジー企業が「そこにはいろいろなもの(小説)が送られてきて、それを読み評価するのが編集者の仕事」をするようになるだろう、というのが梅田さんの主張なのだと思いますし、それは確かにある程度はそうかなと思います。

 でも僕は梅田さんの視点には欠けている致命的な何かがある気がしてるんですよね……。

*1http://d.hatena.ne.jp/umedamochio/20060317/p1

*2:そうでもない? 勘違いしてたのは僕だけ?

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060323

2006-03-21(Tue)

絶対成功する有料サイトの課金方法

| 13:16 |  絶対成功する有料サイトの課金方法 - 浅倉卓司@blog風味? を含むブックマーク  絶対成功する有料サイトの課金方法 - 浅倉卓司@blog風味? のブックマークコメント

 「1回支払えば無期限に利用可能」にする。

 以上。


 ――というかですね、なんでどこも月単位や年単位などの期間課金にしているんでしょ。まさか上記の方法がビジネス特許として登録されているわけじゃないですよね?

 課金サイトが流行らないのは期間単位でしか購入できないからだと思うんですよ。だって「1度払ったらずっと無料で(追加課金なしで)使わてよ」って思うもの。少なくとも僕が課金サイトをあまり利用しない理由はこれです。

 こういう話をすると「なんで時代に逆行した課金方法にするんだ?」って言われちゃうかもしれないですけどね。日本でTiVoが流行らず売りきりのHDDレコーダが主流になっていることを考えても、あるいはCSなどが伸び悩んでいるのを考えても、日本人は「月課金」みたいな期間課金には割と抵抗があるんじゃないかと思うんですよ*1。だったらWebサービスも売りきりにしちゃえばいいじゃん、と。


 例えば、はてなダイアリー有料オプションは180円/月ですが、だったら4,800円で無期限の有料オプションを販売する。これくらい(約27ヶ月分)先までの金額を先払いするんであれば無期限で使わせるのもアリじゃないかなと。どれくらい先払いした時に無期限にすれば良いかは議論の余地があると思うけど*2、月課金にするよりは売上は伸びるような気がする。

 はてなは少額決済が可能なんで効果が薄いかもしれないけれど*3mixiあたりだとかなり効果があると思うし、出版系の有料サイト*4なんかは絶対こっちのほうがイイと思います。


 もっともキャッシュフローを考えるとあまり良くないのかもしれないし*5、販売価格が1万円を超えるようなサービス向きではない気はしますけれどね。

*1:どっかのマーケティング会社の調査とかないのかな?

*2:個人的にははてなダイアリーの無期限有料オプションは3,800円くらいが嬉しい。

*3:それでも有料オプション利用者が増えると思ってる。

*4日経BPとか。

*5:たぶん問題はないと思うけど、専門外なので。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060321

2006-03-14(Tue)

Class::DBI::Sweet用のプラグインいろいろ

| 17:42 |  Class::DBI::Sweet用のプラグインいろいろ - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Sweet用のプラグインいろいろ - 浅倉卓司@blog風味? のブックマークコメント

 ある程度汎用的に使えそうなので置いときます。

 CDBI::Sweet用のプラグインはCDBI::Sweet::Topping::Fooでええんじゃろか。。。

続きを読む

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060314

2006-03-09(Thu)

Class::DBI::Sweetで集約関数を使う方法

| 20:03 |  Class::DBI::Sweetで集約関数を使う方法 - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Sweetで集約関数を使う方法 - 浅倉卓司@blog風味? のブックマークコメント

 そのうち本家で対応するんじゃないかって気もしますが。

 とりあえずSUM()だけ。

続きを読む

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060309

2006-03-08(Wed)

Class::DBIのsearchなどで発行されるSQLを確認するTips

| 18:18 |  Class::DBIのsearchなどで発行されるSQLを確認するTips - 浅倉卓司@blog風味? を含むブックマーク  Class::DBIのsearchなどで発行されるSQLを確認するTips - 浅倉卓司@blog風味? のブックマークコメント

 Class::DBIを使ってるときに「どんなSQLを発行してるんじゃろ?」と思うことはありませんか? 僕はあります*1

 なんかいい方法がないかなー、と思ってたんですが、Class::DBI::Plugin::Iteratorを使っていれば

  my $itr = CD->search( .... );
  print $itr->sql, "\n";
  print join ',', @{$itr->args}, "\n";

SQLの中身が確認できることを発見*2。プレースホルダの部分は?になってるけど、その引数も確認できる*3

 どーせならEXPLAINの結果が確認できるとより便利な気もしますな。


Class::DBI::Sweetで集約関数が扱えるようになってた(←わけじゃなかった)

| 14:08 |  Class::DBI::Sweetで集約関数が扱えるようになってた(←わけじゃなかった) - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Sweetで集約関数が扱えるようになってた(←わけじゃなかった) - 浅倉卓司@blog風味? のブックマークコメント

 普段はClass::DBIを使ってるわけですが、集約関数は扱えないんですね。

 直接SQLを書けばいいんですけど。なんとなくダサくてやだなーと思ってたら、Class::DBI::Sweetで扱えるようになってるじゃないですか。前にドキュメントを読んだ時はそんな記述はなかったのに~。


 というわけでやりたいことができるのか調査中なのですが、ハマった部分があったのでメモ。

 Class::DBI::Sweetのバージョン0.08だけの問題かもしれないけれど、SQL::Abstractのバージョンが1.20じゃないとテストが通りません*4

 あと0.07からClass::DBIのバージョンが3.0.12以降必須になってるっぽいですが*5、集約関数の対応は0.06からなので、そっちを使ったほうがいいかもと思いつつ(古いバージョンのClass::DBIが入っているサーバがいくつかあるから)テストしてません。


追記

 別に集約関数のための機能が増えてるわけじゃなかった。。。。

 やっぱ地道にSQL書いていくしかないのね。


さらに追記

 んでも、Class::DBI::Sweetを使えば割とよさげに処理できるのは間違いないっぽい。

 JOINの処理とかはかなりいい感じになるのですね。

 set_sqlにうまくSQLを書けばいいのかもしれない(駄目かもしれないけど)。

*1:より積極的にはEXPLAINの結果が見たいわけですが。

*2:素で忘れてた。

*3:$itr->argsの戻り値が常にARRAY_REFなのはださい気もするけど。

*4:t/08pager.tで失敗する。たぶん検索の書式の問題なので、分かっていればforce installしても大丈夫な気はする。

*5:バージョン文字列つかってるせいかなんかワーニング出てた気がする。

tokuhiromtokuhirom2006/03/09 19:49http://wiki.class-dbi.com/wiki/See_all_SQL
こういう方法もあります。

asakura-tasakura-t2006/03/09 22:01あー、DBIの機能を使えばいいのか。言われてみればそうですね。

nekokaknekokak2006/03/10 12:41DBIのトレースだと長文SQLが途中で切れたりしました。
見たいSQLに限って長文だったりするので、$itr->sqlはいい感じですね。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060308

2006-03-07(Tue)

「総表現社会」って「表現したい人がみんな表現できる社会」ってことで、「表現をみる人」のことは考慮の外なのですね。

| 00:46 |  「総表現社会」って「表現したい人がみんな表現できる社会」ってことで、「表現をみる人」のことは考慮の外なのですね。 - 浅倉卓司@blog風味? を含むブックマーク  「総表現社会」って「表現したい人がみんな表現できる社会」ってことで、「表現をみる人」のことは考慮の外なのですね。 - 浅倉卓司@blog風味? のブックマークコメント

 ぼちぼち『ウェブ進化論』を読んでいて、ようやく「総表現社会」のトコまで読みました。

 結局のところ「総表現社会」っていうのは「表現したい人がみんな表現できる社会」ってことなのですね。

 うーん、想像してたよりつまんない話だった。

 だってさ、パソコン通信時代から「ネットにやってきた人は一定比率で表現してた」わけでしょ。インターネット時代になって「ネットにやってきた人が増えた=表現する人が増えた」程度ではあんまりインパクトないですよ。

 だからてっきり「あらゆる人が表現するようになる社会」っていう想像もつかない話でも書いてるのかと思って期待してたのに。

 それに「表現したい人が表現できる」ってのもまあ確かに凄いことではあるのかもしれないけれど、その何十倍も存在する「表現したくない人」にとってどんな意味があるのかが書かれてないのはちょっと不親切のような気がしました*1


 そもそも表現を見る人にとっては「総表現社会」なんてどうでもいいことじゃないですか。表現の絶対数が増えれば良い表現が増えるって話にもっていきたいのかもしれないけど、全然そんな気がしないんですよね。あくまで僕の過去の体験による感覚なので、うまく説明できないけど。

 「表現したものの淘汰のされ方」は確かに変わってきたけれど、表現されたものの価値とか絶対数とかは変わってないというか。

 このあたりはnoriyoさんの言うところの

いくらWeb2.0フレームワークが整おうが、それはアウトプットの敷居を下げるだけであって、人間がアウトプットするために必要なインプット作業のほうは、いまだ古典的な努力が必要だからです(本を読む、人と議論する、自分と意見を異にする人たちの話を聴く・・・などなど)。

っていうことと関係してるのかもしれません。


 こういうことを書くと「RSSが」「Folksonomyが」とかいう話になりそうな気がするんだけれど、あのへんは表現する側であるところの「編集」に便利なのであって「みる」のに便利じゃない気がするんですよ。

 個人的には「あまり興味のないモノを自然に『みる』ことができる」ようにならんかなと思ってるんですけどね。

*1:全部読むと書いてたりするのかもしれないけど。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060307

2006-03-05(Sun)

Value2.0を考えるなら、Cost2.0も考えよう

| 23:12 |  Value2.0を考えるなら、Cost2.0も考えよう - 浅倉卓司@blog風味? を含むブックマーク  Value2.0を考えるなら、Cost2.0も考えよう - 浅倉卓司@blog風味? のブックマークコメント

 小飼弾さんがValue2.0についていろいろ語っているんだけど、Cost2.0について語っていないのがちょっと不思議*1

 だってさ、ValueもCostも金銭でしか測れない点は同じなんだから、Value2.0を語るならCost2.0も語るべきでしょう。


 ……そんなことを考えたのは、僕は「金銭コストは重要じゃないから、それより○○コストを減らしましょう」って話をすることがあるんだけど、金銭以外のコスト――例えば「時間コスト」「空間コスト」「心理コスト」「参加コスト」「継続コスト」などなど――という概念が相手に伝わっていないんじゃないかと、今更のように思ったから。

 これらの「コスト」って、ひょっとすると一般的な概念じゃないんでしょうか*2。「時間」と「空間」については比較的「金銭」に換算しやすいんであまり誤解は生じていない気がするんですけど、ただそれも換算することで理解しているのであって、直接的な理解はしていないようにも感じますし。

 もし一般的に通じる概念なら今後も安心して「○○コスト」って言えるのですが、もし一般的な概念じゃないなら今後はその説明を変えなくちゃいけないので、ちょっと気になったのでした。

*1:実際にはCost2.0という言葉を使わずに一部では触れているのだけれど。あえてCost2.0と言っていないのは、その存在を実感してないのかなと思って。

*2:ついでに言うと僕が思う「コスト」に相当する日本語がちょっと思いつかなかったし、costを辞書引きしたら主に金銭のことしか書かれていなかったから。「俺用語を使ってたのか?」といまさら思ったのです……。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060305

2006-03-03(Fri)

表現したくない人のためのWeb2.0

| 01:39 |  表現したくない人のためのWeb2.0 - 浅倉卓司@blog風味? を含むブックマーク  表現したくない人のためのWeb2.0 - 浅倉卓司@blog風味? のブックマークコメント

 梅田望夫さんインタビューを読んでいたら、「総表現社会」という言葉が繰り返されていた。

 チープ革命と「総表現社会」とは密接につながってくる。自分が表現しようとするモノを、不特定多数に配るのは、かなりのコストがかかった。選ばれた人だけの行為であり、メディアが中心になり、1万人に1人ぐらいの人が表現者として活躍する時代が続いていた。だが、チープ革命が「誰でも表現者になれる」という可能性をもたらした。そこで現れてくるのが「総表現社会」です。

 確かに「表現したい人」にとっては梅田さんの書かれていることは正しいと思うし、表現したい人にとってはどんどん良い世界になるのだろうという気はする。

 でも、そもそも「表現したい人」――岡田斗司夫さんの言うところの「プチクリ」――ってそんなに多いんだろうか。


 確かに今までは「表現したいけどいろいろな制約があってできなかった」という人もそれなりにいるのかもしれないし、そういう人にとって「総表現社会」の訪れは素晴らしい、というのは分かる。

 でも、ほとんどの人は別に表現なんかしたくないんじゃないだろうかという気がするんですよ。表現する必要なんか感じてないし、そんな面倒なことはしたくないというか。

 梅田さんに限らずWeb2.0を巡る言説は「表現したくない人」のことは無視しているような気がするんですよ。なのでそういう「表現したくない人」も表現するようになる「総表現社会」ってなんだろう?って思ったので、ちょっと考えてみた。


 現状で感じているのは、表現したくない人にとって現状のサービス*1はコストが高いんじゃないかなと。確かに金銭コストはチープ革命のおかげで下がったみたいだけど、それ以外のコストは全然下がってないし。

 「表現社会」で価値が高く評価されているのはおそらく「継続」なんだけど、その継続コストはとにかく高い。『プチクリ』では「好き=才能」って言ってたけど、僕は「継続=才能」だと思うくらいに継続することは難しいことだと思ってる。

 で、「表現したくない人」もたまには表現したくなって表現することもあるだろうけど、そんなものは誰にも届かないわけですよ。少なくとも現在は「表現したくない人」が表現をして多人数に見てもらえる方法は「匿名掲示板」くらいしかない。だから「匿名掲示板」がWeb2.0になるのはいいことなんじゃないかと思うのだ。たとえば中島聡さんが「Web2.0を活用する10の方法、その7」で書かれていることはそういう事なんだろうと思う*2


 あるいは何かを見た/聞いた履歴を「表現」とみなすことで「総表現社会」になるのかもしれない。そういやソニーもPLAYLOGとかはじめてたし。

 でも現状のモノはあまりにも素のままで、表現としてはイマイチなんだよね。あるいは「表現」にするために、結局手間をかけなくちゃいけなかったりして、それじゃあ「受動表現」にはなってないんだよね。

 まあ別に履歴じゃなくてもいいけど、とにかく些細なことをうまく加工して表現にするっていうのはアリだと思うし、個人的にはそのためのシステムを作りたいなぁなんて思ったりもするわけですけれど。



 ――こんな感じで「表現したくない人」も表現するようになるのがWeb2.0的な「総表現社会」なのかなと考えたりもするのですが、一方で何か違うような気もする。何が違うのかは分かんないけれど。

*1:ブログとかSNSとかブックマークとかまあいろいろ。

*2:ただし僕は責任感をもたせることは難しいと感じているし、より積極的に「無責任だからよい」と思っている。これについてはまたあとで。

noriyonoriyo2006/03/06 13:43> 「表現したくない人」も表現するようになるのがWeb2.0的な「総表現社会」なのかなと考えたりもするのですが、一方で何か違うような気もする。
私は「表現したくない人」が「表現したい人」に変質する確率はそれほど高くない、むしろ相当に小さいと思っています。いくらWeb2.0的フレームワークが整おうが、それはアウトプットの敷居を下げるだけであって、人間がアウトプットするために必要なインプット作業のほうは、いまだ古典的な努力が必要だからです(本を読む、人と議論する、自分と意見を異にする人たちの話を聴く・・・などなど)。
そういった知的/体験的インプットのコストを本質的に下げるためには、社会としてやはり教育の問題を本気で見直さないと駄目だなーと思ったりします。ネットも社会のごく一部でしかないのに、激しくWeb2.0マンセーな人たちはネットをぜんぜん相対化してないのが個人的に浅く感じてしまいます。なんか脱線しましたがそんな感じです。

2004 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2007 | 02 | 03 | 04 | 05 | 06 | 07 | 10 | 11 | 12 |
2008 | 02 | 03 | 04 | 06 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 02 | 03 | 04 | 05 | 07 | 08 | 10 | 11 | 12 |
2013 | 01 | 05 | 07 |
2014 | 01 | 02 |
2016 | 01 |
2017 | 01 | 05 |