インターネット一般の最近のブログ記事

リン廃ホイホイボット

らるる (2011年6月 1日 01:32)

仕事でとりあえず動いていないところを片っ端から解析させられているせいで、自分が今どんなジャンルのプログラミングが得意なのかわからなくなっている今日この頃、気づいたら@LovelyRinchanなボットができあがっていた。今のままだと@rarulよりもFollower数が多くなる日はすぐに来そうだ。

(どうでもいいけど、数年後Twitterがもしなくなっていたら、上記のエントリはいったいなんだったのかすらわからなくなる・・・のかな。)

「続・ハイパフォーマンスWebサイト」読んだ

らるる (2010年7月26日 04:23)

前回の続編が出たと言うことで購入。前回は結局のところ、いかにしてリクエストとダウンロードを早くするかという観点だったのに対し、今回はそれらも考慮しつつJavaScriptの処理の高速化(というより処理をブロックしないよう)の点にメインがおかれている。また、HTML5.0の中身についてや、各ブラウザの仕様と対応状況についてなんかもちょこちょこ書かれている。

個人的な主観が入るかもしれないけれど、私は今回の本はあまり評価できない。前回の本は、時間がかかる箇所はダウンロードとダウンロードしに行くまでの箇所だと明言してその点を深く掘り下げていたのに対し、今回はJavaScriptの実行速度やその仕様制限についてが増えてしまっている。また「今の」Webブラウザの実装状況に依存した小手先回避策が多くなってしまっている。特殊なWebアプリでない限りはJavaScriptの実行速度やDOMノード操作・CSSの読み込みと適用の時間が相対的に問題にはならないと明記しているのにもかかわらず、これらについて解説してしまっている。JavaScriptの処理のブロック(やシングルスレッド制約)にまつわるところなんて、もはや今のWebブラウザを実装する上での制約そのものに関わるところなのに、小手先で逃げられるところを模索しているだけにしか読めない。これじゃ、今回の本なんて読まずに前回の本で提起されたルールをきちんと見つめた方がよい。

cometやWebsocketについてもちらりと書かれているが、これらはこの本の範疇ではないはず。Flush(12章ドキュメントのフラッシュ)についてわざわざ説明しようとしているような読者をターゲットにしているのにもかかわらず、HTTPプロトコル上にある意味「強引に」作ったCometやTCPの生ソケットについての話題を持ってくる必要があるのだろうか。

JavaScriptについても、Webブラウザの今の実装に基づいて解説しすぎている気がする。せっかくのランタイム実行形式のJavaScriptなのだから、ヘタな小手先修正を解説するのではなくて、将来のランタイムの改善による実行高速化に期待した方がいいのではないだろうか。ヘタな小手先修正なんてしない方がよいというのが10年以上前のJavaからの教訓だったと思うんだけど。

もちろん、真に高速化・最適化を目指すにはあらゆることを考慮していかないといけないのはその通りだけど、あらゆることを考慮しないといけないレベルにはまだまだ達していない。ブラウザのバージョンごとの違いはどうなのか、Javascript実行エンジンの特性の違いは、DOM操作の速度は、レンダリング速度は、OSの違いは、CPUの違いは、想定するメモリ使用量は、コンテンツのHDDへのキャッシュ書き出し速度は、回線速度による違いは、回線レイテンシの違いは、NATやFWが足を引っ張っていないか、サーバ側のスクリプトはどうか、WebサーバはApacheでいいのか、mod_php,mod_perlちゃんと使っているか、MySQLがボトルネックになってないか、サーバのCPU/メモリリソースは十分か、とか言い出せばきりがないけど、それ以前にダウンロードにかかる時間とダウンロード要求が遅れないようにすることが相対的に重要になるはず。てかそれが重要だと前回の本から一貫して書いているはず。

というわけで、9?11章あたり以外はあんまりオススメできないです。よほどあらゆることを知っておきたい人以外は、前回の本をきっちりと理解する方へ労力を注いだ方が遙かによいです。

ニコ動関連ツール開発者情報のメモ

らるる (2010年6月12日 09:41)

RSSリーダに登録されてるのの整理がてらメモ。。この辺見とけばニコ動仕様が多い日もみんなあたふたしているハズだから安心？ですね。ドワンゴ開発者のをまとめてもいいんだけど、それはすでにどっかの誰かがやっているだろうからパス。

ニコ生アラートの仕様とかもあるのね、ニコ生関連はほとんど使ってないからよくわからん、、

某へのリプライっぽいもの。
公式動画(so********)が同じ方法じゃうまくいかんなぁと思って調べててたまたま見つけたんだけど、
http://pc12.2ch.net/test/read.cgi/software/1251017748/455
http://pc12.2ch.net/test/read.cgi/software/1251017748/462

455 : 名無しさん＠お腹 - 2009/12/15(火) 20:20:50 ID:d9WhgveFP
こういう、とあるサイトに対する研究って
同様ツール作ってる人向けに、共同でWikiとか作れないものか。
ニコニコ系ツールつくってる人結構いるみたいだし。

仕様変更とかひとりで追っかけるの大変だと思うのだけど
わかったとこだけ書き加えるだけならそんなには手間にならないんじゃないかなぁ？


非公式ツールだしおおっぴらにやっちゃまずいのかしら。
462 : 名無しさん＠お腹 - 2009/12/17(木) 02:09:10 ID:5G8MHq3Z0
>>455
ツール開発やってるからAPIはそれなりに把握してるけど
調べるだけでも大変なのにWiki書くのやだよ
Wikiのやり方も分かんないし、仕様変わってメンテ怠ると
ウソかいてんじゃねえよって怒られそうだもん

チラ裏のように書けるブログは情報の発信の敷居を下げるけど情報の整理には向いていない、総ブログ総Twitter時代になってみんな情報の整理がヘタになってきているなぁ、とか思った。 でもよく考えてみたら、5年前も似たようなことを考えてた気がする。

開発者それぞれが自分仕様のソフトを好きに作るのもいいんだけど、 どっかである程度の割合の人はあきらめて周りを整備する方として貢献するようにしなきゃ大規模開発は回らないよなぁ、とか仕事してて最近つくづく思う。

「ソースコードが仕様書」なんてのは開発者の横暴だけど、その横暴を通すためには、仕様がわからんとか情報がないとかぐーたれるよりもソースコードから読まなきゃ話が進まない気がする。 まぁその前提としてソースコードが公開されている必要があるけど。

とか書いてると、xPadieの作者が開発終了宣言と同時にソースコードを公開していたのを思い出した。もう何年前の話だろ。って全然話関係ないや。

というわけでSourceForge登録してニコニコランキングメーカのソース落としてみようと思ったけど、 SourceForge使い方わかんねー、SVNなんて使ったことないや、そもそもこのPCにVSインスコしてない、て叫びたかっただけです。 ちなみに、SourceForge登録してなくても、SVN使わなくても、ブラウザから見ることは可能みたい。もちろん見るだけならVSなくてもおｋ

・・・という感じで休日つぶしてます。＞「休みの日どうすごしてんの？」と質問した人へ。

ニコ動APIメモ

らるる (2010年6月 9日 05:12)

いろんな人がいろいろやってんだけど、今のところはニコPITAさんとこのブログが一番情報がまとまってそう。。
http://nicopita.info/NicoPITA/?cat=6

APIを利用する各言語ライブラリを整備しようという「ニコ★リブ」構想があったらしいけど、活動中止宣言されてしまってら。
http://sourceforge.jp/projects/nicolib/

ニコ生は動画がRTMPプロトコルに載っているらしい。けどRTMPの実装がFlashplayerそのもの以外はあんまりない模様。参考になりそうなのはRTMPDumpくらい？
http://d.hatena.ne.jp/kesikaran/20100329/1269870039
http://rtmpdump.mplayerhq.hu/

以下、後世の自分のためのメモ。

● ログイン
以下に「mail=(mail)&password=(pass)」をPOSTしてセッションCookieを取得し、以後の通信に添えて送ること。ニコ動はログインしてないと使えないサービスが多い。
https://secure.nicovideo.jp/secure/login

● 動画
たとえば "sm9" の場合、まず以下にアクセスする。
http://ext.nicovideo.jp/api/getflv/sm9

返ってきた結果(Body)の "url=****" の部分が動画ファイルを取得できるパス。「http%3A%2F%2Fsmile-pcm42.nicovideo.jp%2Fsmile%3Fv%3D9.0468」のようにURLエンコードされてるので適当にとく。このパスへGETすればビデオファイルがとれるが、とる前には必要なくとも必ず「http://www.nicovideo.jp/watch/sm9」へアクセスしないといけないっぽい。ちなみに、末尾「smile?v=***」がflv、「smile?m=***」がmp4、「smile?s=***」がswfらしい。取得するときはエコノミーモードに注意。今のエコノミーモードの時間帯

返ってきた結果の "ms=***" と "thread=***" を使ってコメント取得できる。 "ms=***" はURLエンコードされてる。 "ms=***" のpathに以下のようなのをPOSTすると、コメントがXMLで取得できる。(thread)は取得したもの、-250は取得したいコメント数

<thread thread="(thread)" res_from="-250" version="20061206" />

取得できるXMLにもいろいろのってるけど、必要になる箇所はこんな感じ。"mail"がコメント装飾タグ、"vpos"がコメント表示位置(10ms単位)

<chat anonymity="1" date="1203325660" mail="yellow 184" no="5404" thread="1201291236" user_id="mVA0IZFEyRz3uKxZ5LWumuzLoIU" vpos="25757">りん</chat>

コメントの表示位置(移動速度とか重ならないようにとか弾幕モードとか)はクライアントでやっているようだ。ちなみに、表示されるコメント数は動画の長さできまり、今のところは、1分未満が100件、5分未満で250件、10分未満で500件、10分以上で1000件。

ほか、以下にアクセスするといろいろ情報とれる。
http://ext.nicovideo.jp/api/getthumbinfo/sm9

● ニコ生
http://live.nicovideo.jp/api/getflv/lv18905056 をIDとすると、いかにアクセスすると、動画の場合と同じようなのが返ってくる。ただしこっちはXMLで返ってくる。
http://live.nicovideo.jp/api/getplayerstatus/lv18905056

返ってきた結果(Body)の <ms>タグ以下にある<addr>, <port>, <thread> を使ってコメントサーバに接続する。ただし、ニコ生の場合は、HTTPではなく生のSocketになる。addrのportにSocketで接続し、以下のような内容を write する。最後に 0x00('\0')もwriteすること(ここはまりやすい)

<thread thread="(thread)" res_from="-20" version="20061206" />

"-20"は接続した瞬間から過去いくつのコメントまで取得するかを表す。で以降は、新しいコメントが来るたびにsocketにデータが届くのでreadすればよい。コメントはXML形式で動画の場合とほぼ一緒。

返ってきた結果の ticket と rtmp あたりを使ってRTMP接続すれば、ニコ生の動画部分が見えるはず。ただまともなRTMPクライアントを作れていないので今のところ詳細不明。

● 実況
たとえば NHK総合(東京)につなぐ場合、まず以下へアクセスする。
http://jk.nicovideo.jp/api/getflv?v=jk1

返ってきた結果(Body)の thread_id と ms と ms_port を使って、ニコ生と同じようにSocket接続すればコメントが取得できる。返ってくる形式も含めて一緒。

実況は、テレビやラジオの放送がターゲットなので、ニコ動サイト側からストリーミングされることは(今のところ)ない。


・・・といった情報をいろんな人がいろんなところに書いてるから分散しているよなぁ。みんなでどっか1カ所に集めようよ。。

ぼからんの新マイリス補正式の傾向

らるる (2010年1月14日 05:32)

週刊VOCALOIDランキングが今週からポイント計算式を変更したので、どんな傾向になるのかを図示してみた。

コメント数が1000固定とし、再生数が1万・2万それぞれのときに、マイリスを連続に変化させた時のポイントの変化です。比較のため、従来の式も併記しています。
2010_vcl_point.png

大まかには以下の3点に集約できるでしょう。
1) マイリスが再生数の1/20以下程度だとポイントへの寄与が弱い
2) マイリスが再生数の1/10より上でのポイントへの寄与が指数的に上がる(2乗で効く)
3) 結果、マイリス率(マイリス/再生数)さえ高ければ、再生数やマイリス数が小さくてもポイントを稼げる

3)が特に影響大きく、マイリス率次第でマイリス・再生・コメントともに多い動画に少ない動画がポイントで上回ります。(例えば、再20000マ2000コ1500より、再10000マ1600コ1000の方がポイント高い) ・・・コレでいいのか？ほんとに。

計算用に作ったExcelファイルもおいとく。＞ 2010_vcl_point.xls

「例のアレ」カテゴリ追加

らるる (2010年1月14日 01:30)

カテゴリ追加と廃止のお知らせ‐ニコニコニュース

ランキング的には、g_life内にあるfashionが廃止され、g_popular内にareが追加されました。g_popularのカテゴリグループ名が変更されましたが、アクセス時のURLの一部としてはg_popularのままです。また、廃止されたfashionも、以前に廃止されたカテゴリ同様過去ランキングとしては参照できます。

前回のカテゴリ変更も一緒にドゾー

「ヴァーチャルと現実の狭間で」

らるる (2009年10月31日 23:50)

なんだって、窮屈で退屈な現実(real)より、妄想で思い通りの世界を描く仮想(virtual)の方が楽しいなんてことはみんなわかっている。人間関係で悩み簡単には逃れられない現実世界よりも、思い描いた通りのストーリーを創造して体験できるエロゲのような世界の方が楽しいに決まっている。

ただ、そんな仮想の世界で楽しむ裏では、仮想世界と現実世界の架け橋を提供する人々の苦労がある。エロゲだって、様々な中の人の努力があって始めて完成する作品なのだ。あまりにも現実世界とかけ離れた仮想世界を描くと誰もついてこられないし、現実世界に近すぎると仮想世界ならではの楽しみが薄れてしまう。仮想世界が楽しいものであるには、現実世界との適度な距離を保つよう調整する努力が不可欠なのである。そんな人々の苦労を歌ったのが以下の作品である。


・・・とかいうアフォな内容のことを、仮想アドレスにDMA転送してページまたいじゃってあらぬところのメモリをつぶしてしまっていた某ドライバのバグ解析をしている間に妄想していた。もちろん頭の中では「Innocence」がループしていた。うん、素晴らしい歌詞だよね。

ヴァーチャル(仮想アドレス)と現実(物理アドレス)の狭間(MMUが作る連続ページの境目)で
私(DMA転送用のドライバ)は生まれ(スクラッチで書かれ)愛されてきた(「DMA転送のコピーはえぇ!!」)
リアルな世界(物理アドレス空間)は複雑すぎて(「仮想連続が物理連続でないだと？」「キャッシュpurge忘れだと？」)疲れちゃう(「オレのバグじゃないのに・・・」)
ただ素敵な(正確な)歌(データ)が聞きたくて(ユーザプロセスでreadしたいだけなのに)
みんな私(ドライバ)を育ててくれた(「またバグかよ」)
(DMA転送ドライバだけでなくNICドライバにもバグがあるだと？readしたデータをnfsごしに書いて確認してたオレっていったい・・・)
今(バグが再現しない間)だけお願い夢をみさせて (帰って寝ていいよね？)

ひねりが足りないな。また出直してきます。

« Windows | メインページ | アーカイブ | ケータイJava »

検索

このアーカイブについて

このページには、過去に書かれたブログ記事のうちインターネット一般カテゴリに属しているものが含まれています。

前のカテゴリはWindowsです。

次のカテゴリはケータイJavaです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

カテゴリ

月別 アーカイブ

ウェブページ

Powered by Movable Type 7.9.0