|
« 2007年10月 |
メイン
| 2007年12月 »
2007年11月27日
Google相談室
ちょ
投稿者 Juna : 20:40
| コメント (0)
| トラックバック
2007年11月23日
その場のノリで適当に作ったままほっぽらかしてた
↓
うちの初音ミク

↑
ですが、いつの間にかゲイツ様の画像サーチに拾われてました。
Live Search : 初音ミク
さっき見た時は、アダルトフィルタオンで44番目、オフで51番目でした。
何故か記事本体ではなくカテゴリ別アーカイブが拾われてますね。
Googleにはいまだに拾われません。奴ら画像のインデックスほんとに更新してんのか。
Yahooは相変わらず訳の分からないカオスになっています。
画像サーチはLiveで決まり!!ですね!!
ていうか普通にLiveのが一番出来が良いんじゃないですか。
ボクの初音ミクを拾ってくれたからじゃないよ!!ほんとだよ!!
これからもボクの初音ミクのかわいさを世に啓蒙し、これはひどいとかキモいとか言ってくるリテラシの低い連中を積極的にdisって行こうと思います。
飽きた。
投稿者 Juna : 21:50
| コメント (0)
| トラックバック
ニコニコ動画がテレビの座を奪う日は来ない--ひろゆき氏の分析
オンライン事業はインフラをどうするかというのが重大なissueなので、1億人全員に視聴させることを前提にインフラ作ってるテレビには勝てねーと言えば勝てない。みたいなー。
以下俺的見解。
■インターネットのコストは基本的に安い
この安さは、ベストエフォートによる信頼性の低さとか、回線を相互に共有することで保守費用が安いとか、そもそも同じ情報量を送る場合線を引く場所さえあれば無線より有線の方が低コストだとか、色々理由がある。細かいことは触れない。
■一方、youtubeなりニコニコ動画なりの動画配信は高コスト
本来なら低コストなはずの通信手段で、とにかく、現実問題として高いコストが掛かってしまっている。
言い換えるとこうなる「電波放送にはなく、ニコニコ動画にはある、高コスト要因が存在しているようだ」
まぁ細かいことを挙げていけば「インターネットは双方向通信だが、電波放送は送りっぱなしである」とかあるが、何と言っても高コストなのはこれだろう。
・ニコニコ動画はオンデマンドである
ニコニコ動画では全員が違う動画を見ている。テレビに言い換えれば、400万チャンネル放送しているのと同義のことをやっている。
テレビで400万人に400万チャンネル放送しようと思ったらそのインフラは凄まじいものになるだろう。
オンデマンドで個人別に電波に情報を乗せて飛ばす、というと思いっきり身近な機器で「携帯電話」があるが、あれを本気で1億人が同時に使うことを想定してインフラ作ったらどう考えても狂気の機器だ。
■インターネットでテレビと同じ程度のことをやっていいなら……
逆に、テレビのように「全員に、全く同じデータを、全く同じ時間に、送りっぱなしで送って良い」ならインターネットでも低コストで送信する技術が存在する。IPマルチキャストという奴だ。
送りっぱなしについては問題ない。
同報性に関してはTVと同じようにタイムシフト機構(要するにビデオの録画予約)を用意すればある程度妥協すれば吸収出来る。
「少なくともUPされた動画の数だけ」チャンネルが存在してしまうことは苦しいので、「同じデータ」の方にかなりの制限が発生する。
まあ平たく言って、「TVと同じ内容」でいいならIPマルチキャストは十分に使える、はずだ、理念的には。
現実的には、マルチキャスト非対応ルータが途中にいる時どうするとか、NATの内側にいる時どうするとか、配送要求のプロトコルが複雑怪奇だとか、問題ありありで……まぁ現実に「実質無かったことにされている」に近い状態なのには訳がある、というか。
(マルチキャストについては概要知ってたけど、プロトコルとか実装知ったのはつい先日。初期の牧歌的な仕様と、後のヤケクソ気味の拡張で、吹いた。あれは実サービスには使いたくないプロトコルだ)
■自前インフラから逃げてみる
Gyaoみたいに、P2Pを簡易マルチキャストとして使う手もある。
P2Pはインフラ負荷が問題になりがちだけど、winnyとか幹線またいだ接続しすぎだと思う。
もう少し幹線の負荷に配慮したクラスタ化とか出来そうなんだけど、どうなのその辺。
申告回線が速い遅いとかよりも、HOPで接続先選べばだいぶマシになると思うんだけど……。
まあ専門家じゃないのでそういう研究がされているのかどうかとか分からない。
とりあえずインフラ問題に対する回答としてP2Pはあり得ると思う。
ノードがタイムシフトしてくれるので、送信データが揮発するIPマルチキャストに比べると、オンデマンドにも対応しやすい。
現行のP2Pは頻繁に幹線をまたぐ(ものが多いように見える)ため全体のインフラとしてみるとだいぶ不幸だが、クラスタが最適化できれば(低コストな)プロバ構内でのやりとりで済むので中央集権型よりもむしろ全体の負荷は減る。
■そういえばキャッシュProxyって最近聞かないよな
他にもある。キャッシュProxyは元々こういうことを想定した存在だったはずだ。
例えば各プロバにキャッシュProxyを置いて貰い、同プロバの他のユーザに見られた動画はそこでキャッシュして見せれば良い。既にある仕組みを利用するだけだし、明らかに幹線負荷は減るし、専用アプリもいらないし、ララァも喜ぶ。
これだけやると荒らしの踏み台に使われ放題とかユーザのブラウザに設定して貰わないといけないとか問題はあるが、方向性としては有りな気がする。
んー、既存のキャッシュProxyにこだわらないなら、例えばこんなんでいけるかな。
ニコニコキャッシュ専用Proxyを各プロバイダが立ち上げ、そのProxyは自分のプロバのユーザしか接続を受け付けず、接続先はニコニコ動画だけとする。
プロバはニコニコ動画に「キャッシュProxyのアドレス」「カバーするユーザのIPアドレスの範囲」を登録しておき、ニコニコ動画は動画ダウンロード要求を受けた時に要求者のIPアドレスを確認してProxyが存在するユーザならProxyにリクエストを捨てキー付けてredirectする。
Proxyは捨てキーと動画IDをニコニコ動画に照会し、見せていいか確認する。見せていいならProxyは動画を送る。Proxyが持って無ければ落としてキャッシュ。
この場合、プロバとニコニコ動画の協力関係が必要になるので何らかの共通化された枠組みが必要かもしれない。
このやり方だと個人別に認証などを挟んだ上で動画だけのキャッシュに徹することが出来るのと、ユーザから見た時に透過的に処理出来るのが利点、かなぁ。
まぁなんかもの凄い穴ありそうだけど。穴なかったらきっと誰か既にやってるに違いない。
■そもそもニコニコって何
で、それ以前の問題として、そもそもニコニコ動画は本質的に「動画共有サイト」ではなく「コメントを動画にオーバーレイ」させるサービスだったはずだ。
可能であれば動画共有そのものはオミットしてしまって初期のようにyoutubeにでもただ乗り出来ればそれに越したことはない。
極論言えば、別にテレビと喧嘩しなくても、youtubeにただ乗りしたように、地デジ(ワンセグ)にコメントをオーバーレイすることだって理屈の上では出来る。映像ソースはワンセグチューナーから取ってくれば合法だ。
もちろん、PC用チューナーの普及率とか、チューナーから映像を抜いてくるとなるとウェブ上だけで収まらないとか、問題は山盛りなので現実的ではないと思うが。
っつかGyaoとかがニコニコパクってコメントオーバーレイするようなサービスしたらウケるんじゃね。
合法コンテンツだし。
投稿者 Juna : 17:44
| コメント (0)
| トラックバック
2007年11月16日
IAMPとか昔使おうとしてめんどくさくて投げたんで、メールでIMAPは使ってないんだけどねwww
gmailのIMAP解禁とは直接関係なくて、元々RSSを効率良く読みたいなーという悩みから来てて、しかもplaggerもRSS→IMAPが何とかならないかと考え出してから知って、でもなんか違って、うーん。
実はIMAPクライアントってみんな持ってるじゃない。Ajaxが使えるウェブブラウザ、と同じくらいの装備率で。
まあ要するに、IMAPクライアント、つまりメーラを「ブラウザ」として、ネイティブでIMAPをしゃべるサービス、って成り立たないかなと。
この際メールボックスの実体なんて無くてもいいし、後ろにいるのはメールである必要もない。
メーラは「フォルダの中にメッセージが入ってて、そのメッセージをガシガシ読む」というインターフェースには徹底的に最適化されているため、このインターフェースにサービスをマッピング出来ればかなり快適なサービスが期待出来る。自分が一番使いやすいメーラを使えばいいのだから。
もちろん、JavaScriptでガシガシ書けるウェブに比べると遙かに汎用性は低いし、こちらから送れるアクションも幅は狭い。
しかし、メーラのインターフェースに問題を落とし込めれば、ウェブとは違ったことが、誰でも持っているクライアントで、可能になる、はずだ。
実はIMAPのことはよく知らない(←おいおい……)んだけど、最もIMAPに適したサービスは簡単に上げられる。
言うまでもない。身も蓋もないけど、メール。
gmailはgmailfsで遊んで以来全く触っていないのだが、gmailがIMAPに対応したと聞いて「ハァ?」と思った。
だって、ぶっちゃけた話、IMAP対応を突き詰めていけば、究極的にはAjaxインターフェースの方がいらなくなるじゃん?
configだけウェブでやって、メール読むのは全部IMAPでやれば、多分Ajaxインターフェースでやるより快適だよ(原理的には。実際にはgmailのIMAPは遅いらしい?)
例えば、未読管理をサーバ側でやってくれる2chブラウザをIMAPにマッピングする、とか可能じゃないかなと。
どちらかというと購読管理をどういうメタファに落とし込むかとかそういう方が問題だけど、読む分には結構いけそう。あーでも、1メール1レスでマッピングすると発狂しそうだな。
サーバ型のRSSリーダなんかもIMAP向きだと思う。
フォルダの中が本当にフォルダである必要はないし、メールボックスの実体がある必要もない。バーチャルフォルダでいいのだから、「新着10件を抽出したフォルダ」みたいなのも多分作れる、よね。
IMAPにあまり詳しくないのでクライアント側から取れるアクションがどのくらいあるのか分からない。
・メールのフォルダ移動、コピー
→ドラッグ&ドロップでやりたいような操作に使えそう。例えば「非購読スレ一覧フォルダ」から「購読スレ一覧フォルダ」にスレ名の書いたメールを移動して貰えば購読扱いになる、とかさ。
・メール削除
・メールストア
この辺は使いにくそう
・HTMLメール
メールの中にURL書いておいてhttpでアクション取って貰えばそりゃ何でもできるさ
・メールを送る
これはAuth付きのSMTPになるのかな。ある特定のメールに対する返信とかで送って貰えば、あるメッセージに対するアクションは記述出来る。例えば2chで発言することは出来る(しかしこれをパブリックなサービスでやるとOpenProxy状態になっちゃうな)
ウェブインターフェースと比較した時のアドバンテージ
・あの構造を操作する分にはネイティブなので速い
・サーバ側から受信をnotifyできる、よね?(ウェブもCOMETとかあるけどねー)
・ユーザ側が好きなインターフェースのメーラを使える
で、正直言ってIMAPのでっかい仕様を自分で熟読してサーバ実装するとかぞっとしないのでCPANに誰か実装してないかなーできればPOEか何かでー、と思ったけどどうもクライアント実装ばかり。
http://search.cpan.org/perldoc?Mail::Server::IMAP4
一応あることはあったんだけど、うーん。
メールボックスまではいらないんだよね。そこは俺俺バーチャルメールボックスを実装したいんだから。
何らかのメッセージをIRCにマッピングするようなハックは割とあるのに、IMAPを変態的に使う発想はあまりないのかなぁ。やっぱり仕様がでかいから?
plaggerでgmailに送ってIMAPで読む、というのとは違うんだよね。あくまでサービスをIMAP上にマッピングする感じ。
でもgmailもそんな感じぽいよね。使ってないけど。フォルダとか、厳密な意味ではフォルダじゃなくて、「フォルダにgmailのラベルをマッピング」してるだけ。
そういう意味では、gmailのIMAPは、gmailという「SMTPをしゃべってるけど所謂メールとは微妙に違う何か」をIMAPにマッピングしてる。
この発想は何かに応用できそうな気がするんだけどなぁ……。
でも土日はCatalystで人狼作るのに使いたいので、POEでimapd実装するとかは当面スタックの上だな……。腐りそう。
ああ、IMAP上にマッピングされた人狼、というのもありか(イヤ杉)
でもそれだとただのメールゲームとほとんど変わらないからつまらないな。オンラインで管理されてる利点がない。
ふーむ。
そういえばBREWでIMAPネイティブにしゃべれるアプリってauにあったっけかな。
ケータイオフィスとかいうのでIMAPしゃべれるらしい高えよアウト。
ぱそメールとかういやつはPOP専用らしい。おいおい、頑張ってよwinbiffのOrangesoftさんじゃないか。
ないぽ。
投稿者 Juna : 00:28
| コメント (0)
| トラックバック
2007年11月13日
SleipnirのHeadline-Readerがログ溜めると?異常に重いことに業を煮やし、Livedoor Readerに移行。
ウェブアプリとしては非常に「速い」のだが、どうしてもネイティブのアプリと比べると違和感は否めない。
なんかこう、2chブラウザみたいな感じで、Livedoor Reader Readerがあればいいのになぁ。

PlaggerでGmailに投げてIMAPで読む、とか?
ていうかネイティブでIMAPしゃべれるサーバ型のフィードリーダーとかないのかなぁ。
単に「IMAPに転送する」というより「feed-reader over IMAP」が欲しい。
インテリジェンスな仮想フォルダとか作ってさ。で、購読管理なんかはウェブでできるようなの。
でもBloglines→Gmailの機能、でやりたいことは満たせそうな気もするなぁ……。
まぁ当面はLDRを使う。
なんだそりゃ。
投稿者 Juna : 19:24
| コメント (0)
| トラックバック
2007年11月11日
Task::Catalyst
Catalyst::Model::DBIC::Schema
Catalyst::View::TT
Catalyst::Plugin::FormValidator::Simple
Catalyst::Plugin::FillInForm
DBIx::Class::WebForm
Catalyst::Plugin::Session
Catalyst::Plugin::Session::State::Cookie
Catalyst::Plugin::Session::Store::FastMmap
Catalyst::Plugin::Authentication
Catalyst::Plugin::Authentication::Credential::Password
Catalyst::Plugin::Authentication::Store::DBIC
あーなんかキャッシュとかめんどくせ。
セッションもMemcachedにしようかと思ったけど、とりあえずデーモン上げること自体がまんどくさいのでFastMmapでいいや。
memcached大好きなんで仕事では使いまくってるけど。Bradたんの愚直極まる設計はシビれる。
続きは後で書く。
投稿者 Juna : 12:07
| コメント (0)
| トラックバック
2007年11月10日
飽きた。
まあ関連リンクを引くのには使える感じかなぁ。
自分であの村社会に参加しようという気は全く起きなかった。
mixiもすぐ飽きたような人間だしな。
なんかこう、俺みたいに対人関係が乾ききった人間用のコミュニケーションメソッドとかないもんかなぁ。
・長期的には個人のパーソナリティとかどうでもいい
・原則として情報だけが飛び交う
・原則として情報だけを見て考える
って感じの。
形としては2chっぽいけど、2chってどうしても
・ノイズが多くなる(悪意なく本人の無知等から来るものはどうでもいいが、悪意のある荒らしが不可避)
・「場」そのものがパーソナリティを持つ(半年ROMれ現象)
・「発言量」の発言力に対する影響が大きすぎる(1人が延々わめけば話が止められる)
・短期的には発言の一貫性は欲しい(IDがそれに相当するか?)
という感じで、あれはあれで村。
ACばかりの/.jpみたいなのが欲しいのかなぁ、俺。
でも、/.jp自体はID中心に村社会を形成しているし、正直2chと比べてすら情報量が少ないように思う。
なんかこういうのないかなぁ。
・内部的にはID制
・書き込み時には全員匿名で表示され、トピック内ユニークIDが割り当てられる
・トピックを立てた時点で目標(終了条件)を設定する
(例)以下の宿題をスレ主に分かるように教えて下さい。スレ主が満足する答えが得られたと宣言し、撤回せず12時間経過した時点で終了とします。
(例)大根おろしと合うハンバーグの作り方についてあなたの見解を述べて下さい。このトピックは内容如何に関わらず168時間後に終了します。
(例)Googleが発表した「Open Social」を利用したサービスについてアイデアを挙げて下さい。1つのアイデアは最大100文字以内で表現して下さい。挙げられたアイデアについて派生案以外の見解はここで述べず、必要があれば専用のトピックを作成して下さい。このトピックは派生と明記されていない案が100個出た時点で終了します。
・話をトピック以上に発散させてはならない
・トピック内IDを指定し明示的に無視出来る。或る発言者が誰かを無視している場合、そのことは明示的に表示される。
みたいなコミュニティ。
人間そういう生物だとは分かってはいるものの、技術者までムラ社会なのには心底うんざりだお。
投稿者 Juna : 17:30
| コメント (0)
| トラックバック
2007年11月06日
まぁ小沢はまんまと福田とナベツネの情報操作にハメられた、ってとこかなぁ。
小沢が持ち帰ったこと自体は自然なことだと思う。
小沢が言ってる流れが本当なら、密室でいきなり話を振られて、しかも政策丸飲みという大譲歩なのに党内で全く検討もせずにその場で一蹴するのは礼に失するし、党内的にも皆にその提案を見せてから断りましょうというのが筋。
自民側の作戦としては、密室なら言った言わないで済むから何でも言ってOK、御用新聞(読売や産経)が「小沢から出した話だ」「小沢が党内を説得すると確約した」と先手を打って報道、福田は「あうんの呼吸」とか無茶苦茶言って民主の死に待ち、小沢が持ち帰った時には「小沢から振った話だ」が定説で党内は小沢の裏切りにバッシングの嵐、とそんなとこ?
上手いなぁ……
まぁローゼン麻生を陥れた手腕からして福田が「上手い」(もしくは汚い)のは分かり切ってるとして、
民主党内はもう少し冷静に小沢の話を聞く余地はあったんじゃないの?
普通に考えて「小沢から大連立の話を振る」わけないじゃん。次の衆院選100%ボロ負けするよ。小沢だってそこまではアホじゃない。
で、福田から振られた話として、「何で持って帰ってきたんだ」って、決まってるじゃん、党内のみんなに一旦見せるのが筋だから持って帰ったんでしょ。
(少なくとも建前的には)これから与党を目指そうって党が、党首タイマン会談で提案されたこと、どんなことであれその場で椅子蹴飛ばしてくるわけないじゃん。
小沢は小沢で訳分からない。
ハメられてるの気付いたでしょ。もう少しマシな立ち回り無かったの。ブチ切れて辞めるとか言ってる場合じゃないって。
まあ狙いとしては、小沢を民主党から孤立させて一本釣りを狙った、ってとこなのかなぁ。
上手く行きそうな感じだったけど、小沢は続投しそうらしい。うーむ。
自民の汚さは今に始まったことじゃないとしても、こんな情報操作で簡単に浮き足立つ民主の方もどうなのよと思った。
ってか読売があり得なさすぎだわ。アサヒるどころの騒ぎじゃねえ。
で、政治生命を賭けた渾身のギャグを放った鳩山弟がガン放置な件。
投稿者 Juna : 20:34
| コメント (0)
| トラックバック
2007年11月05日
情報弱者Juna、はてブでびゅー。
まぁ単に技術系のブックマークを会社と家で同期させるのがめんどくさい、という本来のSBMとはかなり掛け離れた使い方ですが。
あとまぁ、情報収集用?
del.icio.usの方がCoolだ?
ふぅん。
まぁムラ社会は大嫌いなのでコミューンに加わってどうこうという気はさらさら無いです。
JunaってID取れなかったし。
投稿者 Juna : 20:36
| コメント (0)
| トラックバック
2007年11月04日
原作未読、アニメ版だけ4話まで見た
とりあえず思ったこと
・主催者が余った星を買い取るというルールは主催者から説明されていない
自称リピーターがそのように説明しているが、信じる根拠としては薄弱に思う
(後の展開で説明されるのだろうか)
・カード0枚、星3個、という状態になればいいなら、10分以内にカードを誰かに全譲渡するのが必勝策のように思える
・カードは破棄してはいけないが譲渡はしていい、というルールを説明しないのは「決死で実験してみないと分からない」ため頭脳ゲームとしてはちょっとおかしい前提だと思う
また、ルール説明時点で「この金で星やカードを買い取るのは有りか」という質問くらい誰かしろよと思った。俺は真っ先にそこ突っ込んだぞ。
で、細かいツッコミはともかくとても面白い。
投稿者 Juna : 15:40
| コメント (0)
| トラックバック
2007年11月01日
審問のコードは汚いというレベルではない(もの凄く下手な人が書いた昔ながらのCGI状態)のでもう忘れるとして……
#今見たら本気で見るに堪えないほど酷い
人狼物語のコードは、ざっと眺めてみた分にはだいぶまともなコードだと思いました。
ビュー部分は……ちょっとデザイン修正とか大変そう。
外部ライブラリを使わないという前提だとこうなってしまうのはある程度仕方ない気も。
Shift_JISはいちいちダメ文字を気にしないといけないのでちょっとめんどくさいですね。
審問は内部EUCだったのですが、今から書くなら一律UTF-8にすると思います。
とりあえずまだ(仕事の方の)ドキュメント読みとモジュール選定で右往左往してる(英語あかんねん……)段階ですが
DBIC、TT、Data::FormValidator、HTML::FillInForm、Catalyst::Plugin::Session、Catalyst::Plugin::Cache::Memcached
あたりはまぁ使えそうかなという感触で、認証周りどうしようとかそもそも足りてないとかは、周囲にCatalyst使いがいないため全くの手探り。
まあ足りないものは作れというのが俺的にはジャスティスなんですけども。
投稿者 Juna : 20:03
| コメント (0)
| トラックバック
|