hns - 日記自動生成システム - Version 2.19.7

void GraphicWizardsLair( void ); //

otsune GWL
FreeBSD, AfterEffects, RETAS, animo, DigitalAnime, Linux, Mac OS, Win2k

[Who is otsune?] [title] [message] [Policy] [注目エントリー] [top]
Twitter Status :


Namazu for hns による簡易全文検索
詳しくは 詳細指定/ヘルプを参照して下さい

検索式:

先月 2007年05月 来月
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31


2007年05月07日(月) [長年日記]

#1 [neta] ニコニコ動画勉強会のPowerPointスライドがWebで公開されていた

dwango research and development dept._ から。
検索用に見出しをメモっておくことにする。
勉強会に参加した時の日記は 4月25日_ にある。

1 ニコニコ動画開発勉強会_:

アジェンダ
  • ニコニコ動画について
  • システム構成
  • 歴史
  • 体制
  • 負荷対策
  • 負荷の推移
  • Web
  • Msg
  • DB
  • チューニングへの姿勢
はじめに
  • ドワンゴ初のPCサイトでした
  • 負荷・XSSへの対応が大変でした
  • 今日は我々が行った負荷対策についてお話します。
  • まずは「ニコニコ動画開発プロジェクト」についてお聞きください
ニコニコ動画について
  • 歴史
  • システム構成
  • 体制
ニコニコ動画について
  • まだ浅いけど歴史
  • 2006
  • 10月下旬 … プロトタイプ開発 (3営業日で完成!)
  • 11月中旬 … ひろゆき監修開始&キックオフ的雰囲気
  • 12月上旬 … プロトタイプベースで本開発開始 (2週間)
  • 12月16日 … (仮)オープン
  • 2007
  • 1月16日 … (β)オープン
  • 1月上旬 … 月間1億PV突破
  • 2月下旬 … 3000万PV/日記録
  • 2月中旬 … (γ)開発開始 (2週間)
  • 2月24日 … DDoS攻撃 & YouTubeからブロック → (β)終了
  • 3月5日 … SMILEVIDEO&(γ)開始
  • 4月22日 … 再生回数2億突破・2600万PV/日突破←いまここ
ニコニコ動画について
  • システム構成
  • ソフトウェア
  • いわゆるLAMP
  • Linux2.6, Apache2, MySQL5, php5
  • メッセージサーバはC++で書かれた独自デーモン (戀塚製)
  • ハードウェア
  • HP DL360 1Uサーバ (全サーバほぼいっしょ)
  • コロケーション
  • とあるデータセンタ
ニコニコ動画について
  • 開発チーム体制 (4/25現在 7人)
  • 鈴木(慎)
  • 雑用/御用聞き/SE
  • 06/12〜07/03 : web実装
  • 戀塚
  • プロトタイプ実装(全モジュール)
  • メッセージサーバ実装 (C++)
  • FLV Player実装 (swf)
  • プログラマー他4人
  • 内、2ちゃんねる面接人材が2人
  • PCサイトデザイナー1人
  • 右上のアイコンのあの人
負荷対策
  • ピーク実績
  • 対策
  • (Web/メッセージサーバ/DB)
負荷対策 - ピーク実績
  • アクセス数
  • βピーク : 2300万PV/日
  • 現在:2600万PV/日
負荷対策 - ピーク実績
  • リソース平均負荷(4/24実績=きのう)
  • 回線帯域
  • 約430Mbps
  • Web : 350 Mbps (1台50Mbps * 7台)
  • Msg: 80Mbps (1台15Mbps * 6台)
  • CPU
  • Web : 50%
  • Msg : 50%
  • DB : Master:50% / Slave:50%
負荷対策 - Web編
  • インフラ
  • Apache最大接続数
  • Apache2ならworkerをつかわないの?
  • php5が現状thread safeではない
  • 従って従来のプロセス起動 (prefork)となった
  • コネクション増加はサーバの台数増加で対応
  • さらにメモリを4Gに増加 (プロセス数=2000)
  • 現在は7台で稼動
  • 回線帯域削減
  • mod_deflate導入 (40%削減)
  • 回線そのものを独立予定
負荷対策 - Web編
  • キャッシュ
  • phpスクリプトキャッシュ
  • 現在apcを利用
  • eacceleratorは一部のPearライブラリで誤動作のため採用を見送り (pear/Services_YouTube)
負荷対策 - Web編
  • キャッシュ
  • データキャッシュ
  • 2006年12月(仮)当初Pear/Cache_Liteを使用
  • なにぶんファイルなので
  • memcacheに変更 Webサーバmemcache(ローカル):動画リスト等
  • 専用memcache (リモート):ユーザセッションデータ
  • 現在は3分毎に動画データキャッシュ生成バッチが稼動
  • DBからデータを読んでは加工してmemcacheへ
負荷対策 - メッセージサーバ編
  • DB参照/更新バッファリング
  • 最新コメントを書き込むクエリ(threadテーブルへのupdate)を最大10秒バッファリング
  • 動画閲覧数カウンタのDB参照を4秒キャッシュ
  • テーブルロックによる待ちの回避 (MyISAM時代)
  • 現在はInnoDB
負荷対策 - メッセージサーバ編
  • データファイルインデックス化
  • コメントを格納するCSVへのインデックスを作成
  • CSVの読み込みの時間を削減
  • 1000行に満たないデータはインデックス化しない
  • 人気動画データファイルには有効だった
負荷対策 - DB編
  • 更新/参照系DB分離
  • レプリケーション
  • db01を更新,db02,03…と参照系とした
  • マスタも今後検索/ユーザ/動画と機能分割予定
  • 参照系はアプリケーションロードバランス
  • webサーバ自身のホストIDから、アクセスすべき参照DBサーバを決定
  • MySQL Clusterとかどうかな
負荷対策 - DB編
  • DBエンジン変更
  • video, threadテーブルにて MyISAM を採用
  • 閲覧数カウンタ増加のためUPDATEが頻発
  • MyISAM=テーブルロック
  • レコードロック機構をもつInnoDBに変更
  • Lock waitが減りました
  • でもオートコミットしないとね
  • 次のページへ!!
負荷対策 - DB編
  • my.cnfパラメータチューニング
  • innodb_flush_log_at_trx_commit
  • ログバッファからディスクへの書き込み頻度
  • 従来は1で運用していたが0にした
  • 障害時に一貫性のとれたデータでなくなる可能性があるが、トランザクションを使っていない&動画情報がなくなるリスクと速度のトレードオフを検討した結果、導入を決めた
  • 値の意味
  • 1 … トランザクション発行後フラッシュ
  • 0 … 1秒に約1回フラッシュ
負荷対策 - DB編
  • 検索
  • 未来検索ブラジル社「senna」を採用
  • FULLTEXT INDEXをハンドリング
  • MySQLバインディング Tritonn やりたい
  • ちなみにSQLのクエリはこの程度の違い
  • 従来の検索
  • SELECT * FROM video WHERE TITLE LIKE ‘%アニメ%’ AND ‘%ハルヒ%’
  • FULLTEXT INDEX利用時
  • MATCH〜AGAINST句
  • SELECT * FROM video WHERE MATCH(title) AGAINST(‘+アニメ +ハルヒ’)
負荷対策 - 番外編
  • アクセスログ集計
  • Apacheアクセスログが6GB/日を突破
  • 当初awstatsで集計していた
  • 毎時集計が追いつかない
  • Google Analyticsへ切り替え
  • 当初より使用していた
  • 数時間遅れで反映
  • リアルタイムではない
  • さらに独自でUrchinを使うかも
チューニングの姿勢
  • 全体
  • スケールアウトしやすい設計を心がける
  • Web, DB, Msgそれぞれ容易に増やせること
  • フロント
  • DBへのアクセスはなるべく発生させないことにこしたことはない (webからのコネクション数&クエリ発行数低減)
  • 前述のmemcache等使いを数分毎に更新するだけでもサイトはリアルタイムに動いてるようにみえる。
  • DB
  • ログ系や、更新が行われないテーブルはMyISAM
  • 更新の多いテーブルはInnoDB
  • MySQLのJOINは避け、非正規化ロジックで対応
思ったこと
  • 苦労=当たり前の積み重ねだから
  • 今回のチューニングノウハウは比較的既知な内容を行った
  • なるべくシンプルに、おもしろいサイトをつくるのが命題
  • プロトタイピングからの立ち上げ
  • ベースがあったので追加開発し易かった
  • 設計の見直しは都度行っている
  • ブログ/2ちゃんねる
  • 告知/ユーザの要望
  • 今回は情報収集の場としてなじんだ
  • 負荷試験
  • やりたかったなあ・・・
  • 体調管理
  • 楽しいけど、やり過ぎない

1 ニコニコ動画の仕組み_:

1.仕組みざっくり
  • システム構成
  • Webサーバー
  • メッセージサーバー
  • DBサーバー
  • プレーヤー
  • 動画が見られるまで
1-1.システム構成
Webサーバー(apache 2, php5)
  • メッセージサーバー(C++)
  • DBサーバー(MySQL5)
  • プレーヤー(Flash8)
  • ユーザー(人間)
図1-1-1.システム構成図
1-2.動画が見られるまで
ブラウザでwww.nicovideo.jp/watch/...に接続
  • プレーヤーが埋め込まれたページが返る
  • プレーヤーがWebサーバーから情報取得
  • 動画サーバーへ接続
  • コメント取得!
  • 再生
  • コメント書き込みが可能
図1-2-1.ブラウザでwww.nicovideo.jpに接続
図1-2-2.プレーヤーが埋め込まれたページが返る
図1-2-3.プレーヤーがURL取得
図1-2-4.動画取得!
図1-2-5.コメント取得!
図1-2-6. 再生
図1-2-7. 書き込み
2.コンセプト設計と進化
コンセプト設計
  • 進化
2-1.コンセプト設計
コンセプトは非同期実況
  • しかもリアルタイム
  • サーバーがコメントをpush
  • 「現在5人が再生しています」などと通知
  • システムはネットゲームだ!
2-1.コンセプト設計
コンセプトを満たすために
  • Flash8のXMLSocket
  • チャット用のメッセージサーバーを自前でつくる
  • 既存のネットワークゲームサーバーを改造
2-1.コンセプト設計
データモデル
  • video(DB)
  • 動画情報を維持
  • thread(DB)
  • 動画ごとに複数持ち得る
  • コメント (CSVファイル)
  • コメント自体
2-1.コンセプト設計
メッセージサーバーの設計方針
  • 情報伝達
  • プレーヤーにできることはプレーヤーに任せる
  • スレッドの実体を管理する
  • DBにはサマリーのみ書き込む
  • C++でデーモンとして実装(Linux)
2-1.コンセプト設計
プレーヤーの設計方針
  • コメントこそがコンテンツである
  • コメントしやすく
  • 簡単入力、即時反映
  • Flash 8
2-1.コンセプト設計
  • プロトタイプが3営業日で完成

2-2.進化
公開向け準備 サーバー編
  • 「このサービスは絶対うける」→スケーラビリティを考慮せよ
  • 「HTTPしか通らないユーザーでも楽しめるようにせよ」令
2-2.進化
公開向け準備 プレーヤー編
  • Flash付属の動画再生コンポーネントは、多機能で逆に面倒
  • 使いやすいUIのコンポーネントを作成
  • swfだけで完結
  • 必要な機能のみ
  • 高速で小さい
2.コンセプト設計と進化(まとめ)
最初のコンセプトである
  • 非同期実況を(ほぼ)保ちつつ
  • なんとかなった
3. もう少し詳しく
Webサーバー
  • メッセージサーバー
  • プレーヤー
3-1. Webサーバー
スケーラビリティ
  • メッセージサーバーの増設に対応
  • getflv: プレーヤーの通信先を一旦問い合わせることで設定変更を迅速に適用
3-2.メッセージサーバー
コードジェネレータ
  • 通信方式
  • 高速化
3-2-1.メッセージサーバー
コードジェネレータ
  • パケット定義からサーバ/クライアントのコードを生成する
  • 無矛盾で迅速な変更が可能
3-2-1.メッセージサーバー
図3-2-1.コードジェネレータ画面
3-2-2.メッセージサーバー
通信方式
  • XMLSocket
  • HTTP
  • 双方向chunked content-transfer-encoding
  • 下りのみchunked
  • polling
3-2-3.メッセージサーバー
高速化
  • DBアクセスを削減
  • キャッシング
  • スレッドの想定コメント数を拡大して再設計
  • 全件読み込みから末尾のみの読み込みに変更
3-3.プレーヤー
画面レイアウト
  • XGA想定
  • 動画再生に同期したコメント表示
  • コメントの細密充填 (特許出願中)
  • マーキー/上下固定、弾幕など
図3-3-1.プレーヤー
図3-3-2. SWF逆コンパイラ
まとめ
  • と思ったけど
  • まだ、まとまらない(進化中)ので
感想
  • ユーザーが満足するものにするためには、ユーザーが自分達で醸成するのを助けよ
  • 実際の利用状況に合わせて改良する
  • 高速なフィードバックが大きな効果
  • 日々の蓄積が大事
Permalink: http://www.otsune.com/diary/2007/05/07/1.html#200705071
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-07 00:00:00 By otsune

2007年05月12日() [長年日記]

#1 [neta] いまどき流行のマイクロブログは「電波文を思いついた→Gtalk経由でtwitterにクリップ。オモシロ画像or動画を見つけた→tumblrにクリップ」がオレにしっくり来た使い方

ブラウズ中に気に成ったものを記録しておきたいんだけど。urlのあるWebページだったら、Pukkaというソーシャルブックマーク投稿に特化したソフトでdel.icio.usに記録している。
だけどソーシャルブックマークにも弱点が有って、.jpgとか.gifみたいな画像ファイルを直接記録するのに向かない。これはただ単に、ソーシャルブックマークサービスがタイトルテキストしか表示しない事に割り切ったデザインをしているからなんだけど。
その点で言うと Tumblr_ は、さらに一歩踏み込んだ設計をしている。基本的にはタイトルとurlと概要文を記録するんだけど、「Text Photo Quote Link Chat Video」という6つの種類に特化して投稿することでリンクの仕方や見え方がばっちり来るようになっている。(既存のdel.icio.usやはてなブックマークのようなソーシャルブックマークだと、画像ファイルを登録しても画像プレビューが見えずに「 403.jpg (JPEG 画像, 500x332 px)_ 」みたいなファイル名しか表示してくれなかったりする)
現状ではtumblrは日本語化がされていないので、ほどよくネットジャンキーの人しか使っていないってのも面白いところ。
そして次に Twitter_ のこと。
このWeb日記の数年以上前には、その時に思いついた電波文を良くメモしていたんだけど。そういう気軽なひとことはtwitterに投稿するようになった。
んでだ。twitterのサービスそのものについての話は他にたくさん有るから省略するとして。このサービスの(個人的な)ポイントは3つ有ると思う。
  • IMゲートウェイ連動(Gtalkチャットで送受信できる)
  • 簡易なAPIの公開(WSSE認証とかAPI Keyを発行して設定とかせずに投稿できる)
  • スケーラビリティへの対応(爆発的人気に対処している技術力)
だからtwitterをブラウザで1日数回以下しか見ないユーザーはtwitterの強みを体験しきれていないと思う。Gtalkで使っていないのに「twitterは○○だ」とか発言していたら、「ああ、そういうめちゃくちゃ狭い観測範囲だけで、まるでサービス全体を語った気に成っちゃう人なんだなぁ」と気の毒に思っていたりもする。
(まぁそれはオレが勝手にそう思っているだけだから根本的にはどうでもよいこと。あとオレはGtalkをAdiumという互換クライアントで使っている)
あと。なんだかインスパイヤした類似サービスが続々と立ち上がっているが。いまどきAPIも用意しないしIMゲートウェイでチャット連動もせずに参入してもほとんど意味が無いと思う。(API公開についてはソーシャルブックマークとかdiggやredditインスパイヤのソーシャルニュースサイトにも同時に言える事だと思う。特に技術力を売りにしているlivedoor ClipにPOST APIが無い事は頭を抱える。開発者のlivedoor社K子健介氏には、一刻も速いAPI開発をお願いしたいところ。ma.gnoliaみたいなdel.icio.us互換APIが良いかなぁ)
でだ。APIとか有っても無くても関係ないユーザーにとって重要なのは、IMゲートウェイのほうだろう。(APIが有れば第三者が作った専用ツールが出る可能性があるので、間接的にはユーザーにも関係あるけど)
いくら投稿APIやRSS受信が有ったとしても、IMゲートウェイの利便性には敵わない。使い慣れた既存のツールにインターフェースを任せる事で、ユーザーは応用するだけですぐに使えるようになるんだし。でもtwitterで惜しいのは「このメールアドレスに送信すれば投稿できるよ」というメールゲートウェイと「このIRCサーバーに接続すれば読み書きできるよ」というIRCゲートウェイが無い事なんだよな。

1 関連話題リンク:

オレのtumblrは otsune tumblr_ で。今の所、del.icio.us/otsuneとかtwitterとかnowaとかのRSSも合わせて表示させているので、ここ一カ所さえ見れば記録を確認できるという使い方になっている。
(追記:tumblrの解説は [O] これから15分でtumblrを始めるための資料_ が分かりやすい)
オレのtwitterは Twitter / otsune_ で。
Addするときはlogin状態で Add otsune_ をクリックすれば受信できる。
(他人の目を気にしすぎるSNS脳の人からすると「twitter add=マイミク申請」ぐらいの大袈裟な行為だと思い込んでしまうかもしれないが。オレは「twitter add=RSSリーダーに巡回登録する or ブラウザにライブブックマーク登録する」ぐらいの気軽な行為だと思っている。だって「(今何をしているのかという)独り言を公開するサービス」なんだぜ。「@名前で問いかけたのに返事が無い」とかSNS脳で気にするサービスじゃないと思う)
あとスケーラビリティに関して。twitterは twitterブームの陰で注目を集める“Erlang” − @IT_
メッセージングシステムに“ejabberd”を使っているという。これは“Erlang”で書かれたIMサーバだ。
SolarisはLinuxよりも優れたLinux − @IT_
同サービスはSolarisで動作しており
によると、スケーラビリティの確保にLAMPだけではないアプローチもしているのが特徴的で面白いなぁと思った。
Scaling Twitter ? SlideShare_ のスライドを見ると、Ruby on RailsとMySQLとmemcachedで良くある手法で頑張っているところも多い感じだけど。

1 twitterの惜しい所:

OpenIDとの連携は欲しいよなぁ。
でもそのあたりは難しい面も有って。 blog.bulkneets.net : 他に何も持たないこと_ で指摘されているけど、統合認証されていないからこその身軽さというのも。
でも「ユーザー設定など全ての権限がある認証」と「発言を投稿することしか出来ない認証」の二つは欲しいところ。
Permalink: http://www.otsune.com/diary/2007/05/12/1.html#200705121
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-12 00:00:00 By otsune

この記事へのトラックバック[3]

ないときにはない2:twitterとtumblrがなければ生きていけない
そんな大げさなものではないけど,手軽さと風通しのよさで,twitterとtumblrの2つは...
alectrope:Tumblr とTwitter はじめました
「void GraphicWizardsLair( void ); // いまどき流行のマイクロブログは「電波文を思...
Onion Kills Zombies: Blog:Tubmlrはじめました
Twitterに続いて、最近ちょっとずつ注目されているTumblrも使い始めてみ...

2007年05月13日() [長年日記]

#1 [neta] script type="text/javascript"で.jsを呼び出すタグは、出来る限り本文の後に移動したほうが閲覧者に親切

ここ最近のJavaScriptブームでblog badge(ブログパーツ)を貼る事が増えたけど。カスタマイズの自由度が高いmovabletypeみたいなツールを使っていると、body(本文)の前に出てくるヘッダーとかにblogパーツサービスから指定された
<script src="http://example.jp/hoge.js"></script>
みたいなのを設置してしまうことがある。でもそういうヘッダーの位置に設置すると、外部サイト(から読み込んだ)JavaScriptの処理が終わるまで本文の表示がされないので、とても反応の悪いblogになってしまう。(このWeb日記でもつい先日までtwitterのblog badgeを貼る時に本文の前でscriptを呼び出していて、反応が重くて表示に時間がかかっていた。あまりにも遅くてウザイので修正したってのがこの日記を書くきっかけ)
その手のプログパーツはヘッダーではなくサイドバーかフッターの出来るだけ後のほうに設置するのが良い。
もちろんこれは、本文の後にサイドバーが来るようなテンプレートにしてあることが前提だ。
大抵のblogテンプレートはそうなっていると思うけど。たまにブラウザでソース見ると、ヘッダーの次に延々と長いサイドバーが続いて、ソースの後半でやっと本文が出てくるようなサイトが有ったりする。(CSSが無関係なテキストブラウザのw3mで閲覧していると、本文を見るためにひたすらスクロールする羽目に成ってウザイ)
自分のサイト構造が「サイドバー→本文」に成っていてウザイかどうかを確認するには。Firefoxの表示メニュー「スタイルシート」で「スタイルシートを使用しない」を選択して見てみると良い。
余談だけど、このWeb日記の構造も人の事は言えんな……

コメントを読む(1) [ コメントする ]

Re: script type= by aitqb    2007/05/24 19:07
記述する位置でそんなに変わるとは知りませんでした。参考になりました。ありがとうご...
Permalink: http://www.otsune.com/diary/2007/05/13/1.html#200705131
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-13 00:00:00 By otsune

この記事へのトラックバック[2]

Jimi_Bandrix::Blog:WordPressで.jsを呼び出すタグを本文の最後の方に表示させる方法
ここ最近のJavaScriptブームでblog badge(ブログパーツ)を貼る事が増えたけど。カス...
[bizmemo]:Twitter BadgeのカスタマイズURLまとめ
TwitterメッセージをBlogに貼り付ける公式スクリプト「Twitter ...

2007年05月14日(月) [長年日記]

#1 [neta] Wikipediaを前ふり無しに「Wiki」と省略表現するかどうかで、その人の知識や属性が伺えるので便利だ

半年前の 2006年9月23日_ にWikipediaをWikiと省略するのは違和感有るってのは書いたけど。
( ;^ω^)<へいわぼけ: Wikipediaを「ウィキ」って言ったら物凄い怒られた_ を見る限り、この半年経過した段階で違和感に同調出来る人は減ったのかもしれないなぁと思った。
  • ハードディスクを「ハード」
  • JavaScriptを「Java」
  • USBメモリを「USB」
  • テレビ朝日を「テレビ」
と、文脈を無視して(←ここが重要)省略する類いの人かどうかを判別するためのキーワードとして使う事にしよう。
無理目にたとえるなら。飲み会とかで「ねぇねぇ知ってる? 水にありがとうという言葉をかけると綺麗な結晶が出来るんだって」とかトークしてきた人が居たら、「ああ。その手の人か」って判別しやすいでしょ?。そういうこと。
ちなみに「blogとかBBSで何の前ふりも無しに「Wiki」と使ったらデフォルトでWikipediaだろ?」という意見は、その人のネットの観測範囲が狭すぎるなぁとは思う。「Wikipedia・まとめWiki」しか世界が無いことは別に何の問題も無いけど、前振り無しで使ってよい言葉かどうかは微妙。(そういう人たちしか居ない場所で言うのは別に問題ない。ただblogは世界に公開された場なので、前振りされていないと考えるほうがよい)

コメントを読む(1) [ コメントする ]

Re: Wikipediaを前ふり無しに「Wiki」と省略表現するかどうかで、その人の知識や属性が伺えるので便利だ by kdoi    2007/05/15 10:02
朝日新聞を「新聞」 というのは?別にアンチ朝日じゃありませんけど,周囲でよく聞く...
Permalink: http://www.otsune.com/diary/2007/05/14/1.html#200705141
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-14 00:00:00 By otsune

この記事へのトラックバック[1]

ここギコ!:うちの周りは「Wiki派」ばかりだなあ
Wikipediaを前ふり無しに「Wiki」と省略表現するかどうかで、...

2007年05月15日(火) [長年日記]

#1 [www] ルーシー・ブラックマン裁判の傍聴記録をblogで書いたら弁護士から「名誉毀損で告訴する」と電話がきたそうだ

霞っ子クラブの裁判傍聴記 | 重要なお知らせ:織原城二の傍聴記を全て非公開にします_ から。
織原城二被告の代理人から電話が有ったそうだ。
霞っ子クラブの裁判傍聴記 | 準強姦等:織原城二(1/2) 無期と無罪の事実_ の記述や、その他の裁判傍聴についてのblogが名誉毀損だという主張。
このWeb日記でも数年前に、公的に公開されている判例にリンクして「○○社と○○社でこんな裁判有るんだ。面白いな」という感想を書いたら、貸しサーバー会社経由で社長当人から「削除しなければ訴える事も辞さない」メールが来た事あったなぁ。(自社名で検索して言及が無いかどうかエゴサーチしまくってこのWeb日記を見つけたそうだ)
ネットで判例が検索エンジンに拾われると、会社名と社長の名前で検索するだけでその判例が読めるという状態として、興味深い現象だよなぁ。
結局その社長当人には「ネットで公開されている判例に大した意見も書かずにリンクをしただけで名誉毀損で訴えられると、それがどう判断されるのかに興味あるし。その裁判をすることで原稿を書くネタが増えて面白いので訴えてみてください。(自分が被告の裁判についてだからルポとして書いても良いですよね?)。では裁判の日付はどうしましょうか」という感じでメールの返事をしたら。その社長は、実は本気で訴えるつもりは無くて単にネットで話題にならないようにしたかっただけみたいな返事が来た。
裁判の判例は、原告側がありもしない無茶で人聞きの悪い主張をしても、それが公的な文章として記録されてネットで公開されちゃうから、それを見たお客がまるで本当の事のように思い込んでしまうので困る。というような懇願もされてある程度は納得したので、会社名と社長個人名を伏せる形に修正する事で話はまとまった。
まぁ根本的には、いくら裁判所が公開している判例だからといって、書いてある主張の全てが本当の事だと思い込むお客の方がリテラシー無くて困るんだけどね。「判例で○○という主張が書かれていますが、あれは原告が一方的に主張しただけで、判決では退けられた事なので」と正確な反論を書いてお客に正しい情報を広めるのがネット時代のまっとうな対応だよなぁ。(確かに単に裁判沙汰になっているだけでキナ臭いと思ってお客がより付かなくなるというトホホな現実はあるけどさ。だから「名誉毀損で訴えるぞ」という武富士裁判やオリコン裁判的なあくどいテクニックが通用するんだろうなぁ)
Permalink: http://www.otsune.com/diary/2007/05/15/1.html#200705151
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-15 00:00:00 By otsune

#2 [neta] たまに「作家なのにblogにこんな偏った主張を書くなんて」という真面目なツッコミがあるが。オレは偏っていない作家なんて存在意義が薄いと思う

渡辺淳一がベストセラー作家なのに新幹線の割増料金の支払いを渋るだとか。森博嗣がブックオフを批判するとか。他にも作家がインタビューに答えて、面白すぎるがヤバい事を平気で言っていたりすることが多々有るけど。
そういう事が有ると当然ツッコミが入るワケだ。「ちゃんとした大人がそんなワガママで偏った事を言うなんて」と。
だけど、作家なんてのは「凡庸でまともではない偏った視点」をもってなんぼの商売なんだから。「作家なのにそんなことを言うなんて」というのはなんかピント外れなツッコミな感覚がある。作家だからこそ妙な発言をしちゃうんじゃないかと。
だからツッコミする時は「作家だから変な事を発言するのは仕方が無い面も有りますが」という前置きでツッコミしなくちゃ。(作家だから何言っても許せ、と主張しているのではない)
これって多分、作家という職業が「文化人」として有識者や学者や政治家や公人のような扱われ方をする時代に成ってからのギャップなのかなぁ?

コメントを読む(1) [ コメントする ]

Re: たまに「作家なのにblogにこんな偏った主張を書くなんて」という真面目なツッコミがあるが。オレは偏っ by everes    2007/05/17 12:38
「本なんか読んでると馬鹿になる」時代から「(Howto)本をどんどん読め」という時代に...
Permalink: http://www.otsune.com/diary/2007/05/15/2.html#200705152
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-15 00:00:00 By otsune

2007年05月16日(水) [長年日記]

#1 [neta] 「子供を作るが育てられない親」も「働かない大人」も「人殺しをしても平気な人」も昔から一定の数で居たんじゃね?

赤ちゃんポストに3歳の子供が入っていたという話題を見て。
なんで急に万人が同じ「産んだらちゃんと育てるのが親だろ」という規範で生きるようになったんだろ。核家族化とかそういう状況の変化が原因なんだろか。
ちょっと話が変わって過去の話だが。オレの妻が妊娠したときに助産院で産むつもりだったので、産婦人科や助産婦の先生と良く話をしたんだけど。
「人類は妊娠した時に自力で産めるのは3割だけ。4割は医学の助けが無ければ産めない状態だったりする。残りの3割は今の医学でも産めない(流産したりとかで妊娠を継続できない)」と聴いた。「自力で何事も無く産める3割」じゃないと、助産院ではなく手術が可能な病院で産むことになりますよと。
オレは、実の姉妹2人と義理の姉妹4人全員に子供が居る。実の姉は帝王切開という医学技術が無ければ出産が出来なかったし。義理の姉はつい半年ぐらい前に出産したけど、緊急手術をしなければ失血死する状態で助かったりした。(つまり医学の助けが無ければ産めない4割だな)。また、他の姉は助産院の自然分娩で特に問題なく産んだりしている。
んで赤ちゃんポストに話を戻すと。
子供を作るけど育児が出来ない親ってのは1割ぐらいはいたんじゃないかなぁ。(数値は単なる個人的感覚で特に根拠は無い)
それに昔は医学が進歩していなかったので「子供を産んですぐ死んじゃった母親」ってのが今に比べたら結構いたんじゃないかなぁ。あと多産多死で子供がやたらと多かったり。
核家族ではない、集落とか親戚ごとに暮らしていた時代だったら、育てられない家庭にいた子は他の親が引き取って育てたりしてたよね。
ニートみたいな、ろくに働かずにぶらぶら暮らしている大人も「プー太郎」と呼ばれるように昔からいたけど。いつのまにか「現代の社会問題」みたいな扱いに成っているし。
ナチュラルボーンキラーズとか人殺しをしても平常心を保てるタイプの人が、軍人として活躍したりするのも昔から居たよね。(人殺しまでいかなくても、ひどい暴力を他人にふるってもちっとも罪悪感が無いタイプの人は居るだろうなぁ)
産めるけど育てられないタイプの人まで「子育てする親」の役割をしなくちゃいけなかったり。働けないタイプの人まで「労働者」としての規範を適用されたり。ナチュラルボーンキラーズのタイプの人が、平和な都市で暮らさざるを得なかったり。
そういう核家族とか、経済的な視点から来た労働者規範とか、社会環境の変化によって無理矢理出てきた「社会問題」なんじゃないかなぁ。
個人的には「産んだら実の親が育てなくちゃ駄目」とか「大人はみんな働かなくちゃ駄目」という規範を万人に当てはめようとするのは賛成できないんだよな。(他人に暴力をふるっても平気なタイプについては、戦時中でもない限り一緒に暮らすのは難しそうだけど)

コメントを読む(1) [ コメントする ]

Re: 「子供を作るが育てられない親」も「働かない大人」も「人殺しをしても平気な人」も昔から一定の数で居 by たかやっし    2010/02/26 05:54
人権観念の変化じゃないですかね? 世の中が、整っていくに従って少しの人権侵害も許...
Permalink: http://www.otsune.com/diary/2007/05/16/1.html#200705161
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-16 00:00:00 By otsune

2007年05月20日() [長年日記]

#1 [neta] イントラネットで「社内専用twitter」を動かすのはどうか?

うちの会社のイントラネットにはY足さんがRubyで作った「行き先表示板CGI」が稼働しているんだけど。イントラネットのformからPOSTで投稿するインターフェースしかないから、外出先から「スタジオ○○に寄ってから帰社」という更新が出来ない。(イントラネットのCGIだからこれはまぁ当然だよね)
一時期、拡張アドレスでメール受信してEmail::MIMEで分解してWWW::Mechanizeでイントラネットに投稿するゲートウェイスクリプトを書いたけど。けっこう不毛だよね。
要するに、jabberプロトコルやモバイルサイトやメール更新に対応したtwitter互換のイントラネット向けツールが有れば良いんじゃないかと。
Web系のとんがった技術者は、たいていIRCというメールよりも気軽にすばやく情報交換できるツールで開発者同士がバグ報告やら開発方針やらを話し合っているんだけど。それを社内の「行き先案内」にも使えないかなぁと。
ここで重要なのは、MSNメッセンジャーなんかだと距離感が近すぎるので駄目だってこと。1対1で返事を期待する強いニュアンスになってしまう。
グループチャットとかで返事を期待しない単なる「いまここにいる」「いまこれをしている」という告知という使い方がちょうど良い。
twitterそのものはWebサービスでソースは公開されないだろうから、互換ツールとして作られてソース公開されているのが必要だけど。
あとイントラネットがセグメント分けされていない会社だったらIP Messengerを使っている所は多そうだな。

1 関連リンク:

ITmedia Biz.ID:“社内IRC”を駆使するエンジニアの仕事術とは――モバイルファクトリー・松野徳大さん_ を見ると、社内専用IRCサーバーを立てている会社ってのもあるな。
Yahoo! JAPANはYahooメッセンジャーを使ってリアルタイムなやり取りをしているらしい。
livedoorの開発室も社内IRCがあると聞いたな。
YappoLogs: Twitterっぽいサーバー_ ってのも有る。POEでざっくり作ってみましたという状態。

コメントを読む(1) [ コメントする ]

Re: イントラネットで「社内専用twitter」を動かすのはどうか? by techmonkey    2008/06/10 21:13
社内twitter作ってみました! http://sites.google.com/site/jtwitter/
Permalink: http://www.otsune.com/diary/2007/05/20/1.html#200705201
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-20 00:00:00 By otsune

2007年05月21日(月) [長年日記]

#1 [www][neta][microformats] アニマライトというアニメ・漫画レビューをまとめるサイトがあるが、hReviewツール提供すればいいのに、ロボット巡回して全文キャッシュするという前時代的な方向に苦労をしている

結論から言うと、一つのサイトに情報が集まっているのは大変便利では有るが、転載やキャッシュによる全文表示という形で苦労するのは古い手法だと思う。
それはhReviewに対応した漫画・アニメに特化したレビューツールを提供して、アニマライト運営のクロスボーダーコンサルティングが扱いやすい形で検索できるように仕向ければいいのだ。
日本の著作権の現状だと、オレはこんな感じに認識している
  • 日本の著作権法には、米国におけるFairUseという概念が無い
  • 日本だとFairUseがないので検索エンジンですら厳密には合法とはいいきれない現状がある
  • キャッシュ表示は日本の著作権法では合法と扱われないだろう
  • キャッシュに広告を出す事は、あのGoogleでさえも避けている(広告をだしたら米国でもFair Useにならないかも)
  • 内容を表示せずに「○○という情報がhoge.example.jp/fugaにあるよ」と提示するのは著作権的にはまったく問題無し
同義問題とか他人のふんどしでアサマシリンクで稼ぐのかよ問題に関しては、そんな論点よりも「キャッシュに広告表示しても平気とはGoogleもやってないのに良くやるなぁ。著作権チャレンジブルすぎるぞ」と思っていたりする。ただ「アニメ・漫画・ラノベ感想の特化型検索エンジン」というのは今のWeb社会ではアリだと思う。
「人が書いたレビューを集めたという、簡単な誰でも出来るただそれだけの事で事業として儲けるのかよ」という他人のふんどし妬み論争も、オレは「ただそれだけの事」を実行することに意味があると思うのでどうでも良い。(キャッシュとして全文転載したり、そこに広告だすのは完全にFairUseから外れるのでマズいけど)
簡単な誰でも出来ることだったら、文句を言うあなたが率先してやれば良いじゃん。もしその「ただそれだけの事」に本当に何の価値もなかったら、誰も利用しないだろうから広告収入にもならないだろうし。(これはアニマライトに限らない全てのWebサービスに当てはまるオレの考え。くどいようだけど、464.jpみたいにFairUseどころか法を無視したのは論外だよ)

話は変わるが。ISBNをキーにして、書籍の正誤表をまとめサイトに出来ないかと 2002年12月_ に思いついて 2006年12月_ にも書いたけど。これを「感想・レビュー」でもやれば良いんだよな。単行本の漫画やラノベにはISBNが有るから良いとして。問題なのはアニメ番組にはこれといったキーになる情報が無さそうってことだよな。(Gコードは地域によって違うし生成方法も非公開だから使いにくい。 Gコード解析_ を見ると、どうやら時刻とチャンネルしか情報が無いみたいだし)
使えそうなのはiEPGだけど。 iEPGフォーマット解析 ―350ml.net―_ によると、放送局名と時刻というざっくりしたデータなので、ISBN的なIDには使えない。まぁ番組名+話数で検索させるという手法に成るか。

オレのこの提案が通じないってのは何となく分かっていて。問題はアニメ・漫画の感想を書く人たちはmicroformatsとそれによって実現するセマンティックWebの便利さだとかに興味を示してくれないって事だろう。だから「ただ単に感想を書くよりも便利でお得に成るよ」というインセンティヴを提供しないとうまくいきそうにない。
たとえば映画生活というサイトでは hReview準拠レビュー作成ツール@映画生活_ なんて形で、レビューしたい作品を検索してWebフォームから感想を書き込めばhReviewの形式になったHTMLを表示してくれるサービスが有る。あとはそのソースを自分のblogにコピペすればOk。(ここでポイントなのは、映画生活という他人の領域に書くのではなく、自分のコントロール下にあるblogで書けるという事。 Japan.internet.com Webビジネス - ウノウ、hReview に対応した Blog 向けレビュー作成ツールを提供_ によると、作ったのはウノウだとか)
またAmazonの商品にレビューを書くためのアフィリエイト支援ツールである G-Tools_ にも マイクロフォーマット(hReview)対応などG-Tools バージョンアップ:Goodpic_ で書かれているようにhReview形式でソースが出力される機能が有る。
本来であれば各種blog事業者が「今日見たテレビの番組・読んだ本・聴いたCD等の感想などを書くには、このフォームを使ってください」みたいな便利ブログエディタみたいなのを用意して。それで記入すればhReviewが適切に入ったレビューがblogエントリーに入るってのが理想的なんだけどね。
ウノウの映画レビューフォームがアニメ・漫画・ラノベにも使えるようになっていれば理想的か。

1 関連リンク:

平和の温故知新@はてな - レビュー検索サイト「アニマライト」に感想をもってかれる_
アニマライトが感想を全文キャッシュしてるらしい? | MOMENTS_
アニマライトについて | まいじゃー推進委員会!_
余談だけど、アニマライトのWebサイトはurlにクエリーパラメータが付きまくって汚いurlだよなぁ。そういうところを見ると、あまり技術的にはエッジを走っていないひとが設計したっぽい気配。
Permalink: http://www.otsune.com/diary/2007/05/21/1.html#200705211
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-21 00:00:00 By otsune

#2 [www][yahoo][GMO][FeedBurner] FeedBurnerを使うとYahooブログ検索に引っかからなくなるそうだ

FeedBurnerは超重大な事実を隠してる - たねちゃんズ12_ から。
ためしに Yahoo!ブログ検索 - 「otsune」の検索結果_ してみたら、確かにFeedBurner使っているこのWeb日記とFreeBSD memoが出てこないな。
feedburner.jpのGMOとしては、Yahoo!にしてやられたという感じで手も足も出ない気がする。
Permalink: http://www.otsune.com/diary/2007/05/21/2.html#200705212
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-21 00:00:00 By otsune

この記事へのトラックバック[2]

Travellers Tales:FeedBurner を自ドメインで使う MyBrand を設定してみた
FeedBurner の Pro 機能が無料に! Google が FeedBurner を買収したことにより、本家...
juyama.net:Feedburner MyBrand 絨
FeedBurner のMyBrandを導入しました。 FeedburnerのMyBrandって何? MyBrandはFeedbu...

2007年05月23日(水) [長年日記]

#1 [www][FeedBurner][yahoo] ブログURLとドメインが不一致でも、ブログのヘッダーで明示していれば信用に値するフィードかどうかは区別できるはず

FeedBurnerは何も隠していないと思うよ - Ogawa::Memoranda_
で、その無限個存在するフィードのうち、ブログURLとドメインが一致するフィードの信用度はより高いとするだけの蓋然性がある。なぜなら両者のURLの所有者が同一であると考えられるから。これに対して、不一致の場合には、濫造されたフィードか、FeedBurnerのように本来は(暗黙的に)信用に値するフィードかを区別できないのなら信用度は一律により低くすべきである。
単純にfeedが持っているlink(この日記で言うところの「http://www.otsune.com/diary/...」)と、feedが提供されている場所(この日記で言うところの「http://feeds.feedburner.com/otsune」)のドメイン部分を、簡単に文字列比較するだけの処理でspam feedだと判定するのであれば確かにそうだけど。
元blogのlink rel="alternate" type="application/atom+xml"ヘッダーで明示してあるのだから、「○○というblogのfeedは××というところで正しいものが提供されている」と判定する事はぜんぜん難しい事ではない。
だから「信用に値するフィードかを区別できない」というのは成り立たない。
もっとも、RSSの無いサイトに対して第三者が「なんでもRSS」とか「勝手FeedBurner」を作っているのであれば、それは成り立つ。元サイトのヘッダーには第三者の作った勝手feedのurlなんて書いている訳ないから当然だよね。
blogのヘッダーが信用できるポインターとしてつかえることは、OpenIDのdelegateで使っている事を考えても問題は無いよね。
つまり今回の「FeedBurnerのYahoo blog検索八分騒動」は、Yahooの検索インデックスのポリシー問題だとオレは思っている。
あっけなく「FeedBurner.*は特例として一律で八分解除」になるかもしれないし「ヘッダーを見て明示されていたら解除」という技術的にまっとうな結論になるかもしれない。逆に「YahooとしてFeedBurnerを特例にする意味は無いので別ドメインfeedは一律でspam判定レベル上げます」という現状のままでいくかもしれない。
どの方針をとっても不思議ではないので、あとは政治的にどう解決するのかに期待したい所。(もちろん「技術的にまっとうな事」をせずに、企業戦略的にあえて八分することをYahooがしたら「Yahooはそういう会社です」という情報の根拠として使うつもりではある)

コメントを読む(2) [ コメントする ]

Re: ブログURLとドメインが不一致でも、ブログのヘッダーで明示していれば信用に値するフィードかどうかは by (o)    2007/05/23 14:07
それはその通り。だけど、前提としてはフィードが主であるのに対してAutomatic Discov...
Re: ブログURLとドメインが不一致でも、ブログのヘッダーで明示していれば信用に値するフィードかどうかは by (o)    2007/05/23 14:53
て書いたけど、ハブられ続けている人がいることの説明にはなっていませんでしたね。別...
Permalink: http://www.otsune.com/diary/2007/05/23/1.html#200705231
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-23 00:00:00 By otsune

2007年05月24日(木) [長年日記]

#1 [FreeBSD] FreeBSD Security Advisory FreeBSD-SA-07:04.file_

cd /usr/src
make update
cd /usr/src/lib/libmagic
make obj && make depend && make && make install
した。
Permalink: http://www.otsune.com/diary/2007/05/24/1.html#200705241
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-24 00:00:00 By otsune

2007年05月28日(月) [長年日記]

#1 [GUI][www][neta] コマンドラインインターフェースとQWERTYキーボードは英語圏ユーザーには良いが、日本語を扱うのはまどろっこしい

COULD:コマンドラインは最強インターフェイス?_ を読んで。
blogエントリー自体の趣旨はまったく同意している。だけど肝心なポイントに触れていない。
それは、英語圏のユーザーに取ってQWERTYキーボードとコマンドラインというのは日本語を使う我々が考えている以上に直感的だということ。
日本語を使う人たちは、日本語そのものをダイレクトに入力する事が出来ない。( T-Code_ という漢字や仮名を2ストロークで直接入力する変わった方式もあるにはある。しかし「A」を入力したいときにAキーを押せば良いという英語のダイレクトさと学習コストの低さにはとても敵わない)
Mac OS XがFinderというGUIによるフォルダ分類志向からだんだん離れて、Spotlight検索志向に移行しているのも「名前を直接キーボードで打てば、それが出てくる」というコマンドラインのメリットを取り入れているんだろう。
Web 2.0で流行ってる「タグ」も、英語ならではの妥協案だと思ってる。日本語でタグを使おうとすると途端に扱いにくくなる感覚がある。(日本語だとブレが大きいからタグで串刺しにするのに向かないからだろうか? でも英語にも類義語(シソーラス thesaurus)でブレが出るよなぁ。あと、タグは区切り(デリミタ)がいまいち定まっていなくて、空白の使えないdel.icio.usだとWikiNameっぽい単語を繋げた表記をしたりもするよな)
キーボードが直感的だと感じるかどうかって、英語圏と日本語圏の若者でもずいぶん違いそうだよなぁ。今だとケータイ配列のテンキーのほうが日本語打つの速い子だって居るだろうし。アメリカ人ビジネスマンはBlackBerryみたいな工夫したQWERTYキーが直感的だと感じているみたいだし。

コメントを読む(1) [ コメントする ]

Re: コマンドラインインターフェースとQWERTYキーボードは英語圏ユーザーには良いが、日本語を扱うのはまど by ヤスヒサ    2007/05/28 09:38
日本語のキーボード操作の違いついては見落としていました。確かにそのとおりですね。...
Permalink: http://www.otsune.com/diary/2007/05/28/1.html#200705281
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-28 00:00:00 By otsune

この記事へのトラックバック[1]

World Wide Walker:コマンドラインで日本語ファイル名を扱う際のジレンマ
[void GraphicWizardsLair( void ); // コマンドラインインターフェースとQWERTYキー...

2007年05月29日(火) [長年日記]

#1 [FreeBSD][work] 外部ファイルやりとりサーバーのscponlycのchrootツリーを最新版にアップデートした

shell scriptソースは g:subtech:otsune_ に書いた。
最近の/usr/libexec/sftp-serverは動作時に/dev/nullを要求するので、chrootしたホーム以下のdevにdevfsをマウントする必要が有る。
一番簡単な解決法は /dev/null in a chroot_ で書いてある起動スクリプトを/usr/local/etc/rc.d/以下に設置して+xしとくことか。
Permalink: http://www.otsune.com/diary/2007/05/29/1.html#200705291
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-29 00:00:00 By otsune

#2 [neta] 著作権法の非親告罪化は海賊版DVDを取り締まるのが主目的なのに「同人文化や作品制作を阻害する」と感情論出すのは、著作権70年延長論争の時に「作品は魂。遺族保護が」と感情論出した松本零士を批難できないよな

まぁルールを決めれば、それにギリギリ引っかからないように裏をかく事は必ず出来るので(例:まねきTV)、ルールとしてはきびしめに書くしか無い。だからどうしても「将来の拡大解釈による検閲・悪用」という可能性を潰す事は難しいんだろうけど。(「文化振興のため」みたいな目標がある著作権法ですら、実質的な大企業の検閲制度として文化振興に反する時もあるよね。iTunes Storeとかは日本は海外と比較して駄目駄目とか)
ダブルスタンダードはよろしくないという価値観においては、松本零士を表に出してきて感情論で押し切ろうとする70年延長派の戦略を批判するひとは、自分も非親告罪論争の時に感情論を使っちゃ駄目だよなぁ。
もっとも、オレはこういうのはダブスタを含めた洗脳合戦だと思っているから、気付かれないのであれば卑怯な作戦も含めてゴンゴン主張しちゃって良いと思う。簡単に言うと「戦争なんだからダブルスタンダード上等。賛成派も反対派も、お互いに自分の利益に成る方向に世論を煽動し合って勝負すれば良い」という感じか。
この辺の「自分の過去の発言は棚に上げて、都合の悪い事はわざわざ言いません」という方針は、blogを良く書くネット系弁護士の人たちは決してネタバレしてくれないけど。けっこう継続的にウォッチしていると見えてきたりする。だからたまに「そこは本当は痛くも痒くもないんだけど」という事について、ぶっちゃけオープンで「これを言うと都合が悪いのですが、正々堂々と公開します」とアピールして、あの人は裏表がない人なんだなぁと誤解させて本当に隠したい事は言わないみたいな「信用の損切り」も必要だよな。ありとあらゆる事を「オレの社会的地位を考慮して根拠無く無条件に信用してくれ。情報源については秘匿せざるを得ないから」としてきた旧来のやり方だと、発言者の社会的地位が見えにくいWebとは相性が悪いし。(これは当然だけど。社会的地位はブラウザの文字の質感とは関係ないから、正論でツッコミされまくってたら説得力無いように肉眼では見えてしまうよね。印刷物だったりしたら社会的地位により文字の質感に差があったけど)

コメントを読む(4) [ コメントする ]

Re: 著作権法の非親告罪化は海賊版DVDを取り締まるのが主目的なのに「同人文化や作品制作を阻害する」と感 by soda    2007/05/29 08:18
うーん、どういう理由でそういう主張になるのか良く分かりませんでした。松本零士氏へ...
Re: 著作権法の非親告罪化は海賊版DVDを取り締まるのが主目的なのに「同人文化や作品制作を阻害する」と感 by yoosee    2007/05/29 09:00
「同人文化や作品製作を阻害する」と言うのは必ずしも感情論としての訴えではなくて(...
Re: 著作権法の非親告罪化は海賊版DVDを取り締まるのが主目的なのに「同人文化や作品制作を阻害する」と感& by otsune    2007/05/30 04:56
1.この日記だと松本零士の話は「著作権70年延長論争で、遺族や作家が可哀想という感情...
Re: 著作権法の非親告罪化は海賊版DVDを取り締まるのが主目的なのに「同人文化や作品制作を阻害する」と感& by otsune    2007/05/30 05:01
後半でポジショントークをし合う洗脳合戦の話を書いているので、そのあたりはまぁそう...
Permalink: http://www.otsune.com/diary/2007/05/29/2.html#200705292
trackback
このエントリーを含むはてなブックマーク del.icio.us livedoor Clip View blog reactions
Last Updated 2007-05-29 00:00:00 By otsune