オーマイニュースで退会した人を調べる方法

のっけからタイトルに反する結論で申し訳ないが正確に把握する方法は現在たぶんありません(笑)。

でもそうとも断言できないんだよなぁ。それについては次エントリーで書く予定。

（注記：以下の文書中、打ち消し線までの範囲には私の推断による誤りを含んでいます。詳しくはトラックバックを参照してください。指摘・説明してくださった平野秀樹氏に感謝します。）

一部のインターネットメディアにおいて実名を曝さずに市民記者になる方法の「辞めていく市民記者」を見る限りはリニューアル当初はそれを調べる方法があったのだろう。

市民記者のプロフィールは http://www.ohmynews.co.jp/profile/登録番号 で見ることができるが、存在しない登録番号で参照したときは、たぶん「登録されていません。」あるいは「存在していません」と表示されるか何らかのエラーになっていたものと思われる。

現在はどうかというと「プロフィールは公開されていません」と表示される。
例えば有り得ない登録番号 http://www.ohmynews.co.jp/profile/9999等を参照すれば確かめられる。

自分で確かめていないのでわからないが、"何らかのエラー" だったのならこのように修正されたのも一応納得できる。でも正しくは「登録されていません。」あるいは「存在していません」と表示するべきではないか？

もし、「登録されていません。」あるいは「存在していません」と表示していたのを「プロフィールは公開されていません」に修正したのであれば最悪。
公開されているプロフィールの離散状態から未登録部はこれからも推定可能だし、リニューアル以前の状態については前述したブログエントリーのように既に推定されている。

今更何をなんの為に隠すのか？

あ～今書きながら思いついたが、ひょっとしてプロフイールを公開していない人の状況はわからないということかな？
そうだとしたらなんという仕様かと・・・。

実はプロフィールには公開されている状態「プロフィールは公開されていません」という状態以外に「この市民記者は退会しました」と表示される状態がある。

例としては http://www.ohmynews.co.jp/profile/10106を挙げておく。
（現時点でこの人はリニューアル以降退会した唯一の人。）

リニューアル以前の退会者については、前述したように「プロフィールは公開されていません」と表示される。旧データを移行したので仕方ないのかもしれないが・・・。
で、リニューアル以前の登録者が今後退会したときにどうなるかに少し興味があったが、日付で言えば昨日 2007/04/29 にハートマソ軍曹が退会したようだ。
プロフィールのURLは http://www.ohmynews.co.jp/profile/5022である。

このブログではオーマイニュースの記事や参加している人について記述することは避けてきた。
そういう観点なら私よりもっと鋭い視点で上手に書くであろう人が沢山いるからだ。その人達に読まれる可能性があることを考えると恥ずかしくて書けない。
しかしながらひと言、ハートマソ軍曹が退会するのは残念であると書いておく。必ずしも彼のコメント等に賛同する訳ではないが、いろんな視点・意見を欲しているからだ。
リニューアル以前の登録者が今後退会したときにどうなるかが判明したことも合わせて感謝します。

リニューアル以前の退会者に限定されるが退会者が判別つかないと困ることはないだろうか？

例えば記事を読んで記者に連絡を取りたくなったのだが「未公開」だったからオーマイニュース編集部に問い合わせたら、それでもよくわからなかったとか。
まぁないか。そんなケース。屁理屈っぽいな。

結局ね、整合性・統一性がないのが気に入らない！！

そういう事です。

美しさも目指して欲しいな♡

さて、ついでなので謎の表を置いておきます。
約100か・・・やっぱ全体からしたら少ないのだろうな。

165	222	228	312	330
350	327	401	439	490
515	556	649	666	695
705	884	933	1099	1330
1340	1386	1445	1486	1679
2038	2078	2086	2210	2246
2394	2566	2649	2812	2832
2885	3030	3066	3213	3222
3227	3321	3375	3588	3595
3701	3807	3923	3947	4025
4053	4138	4407	4416	4150
4222	4223	4244	4263	4436
4453	4517	4548	4550	4568
4571	4575	4627	4639	4773
4811	4914	4967	4996	5006
5022	5042	5049	5078	5092
5101	5158	5167	5180	5184
5323	5337	5347	5357	5388
5390	10008	10013	10038	10047
10055	10056	10057	10058	10060
10070	10080	10083	10087	10092
10105	10107	10114

[2007/04/30 9:30]注記追加。ついでに誤字等も修正。

オーマイニュース内での名前の扱いについて考えてみた

オーマイニュース内で名前が現れる箇所というとたぶん次の３つだろう。

(1)記事の署名
(2)コメントの署名
(3)SNS内での名前

このうち(2)と(3)は現状同一の扱いなので同じものとみなすことにする。
以下の記述では記事署名とニックネームと呼ぶことにする。

ご存知のようにオーマイニュースは原則実名による記事署名となる。
場合によっては本来の意味でのペンネーム（以下にペンネーム）、匿名としてのペンネーム（以下に匿名）が許されることがある。

本来ペンネームと匿名は区別すべきだが、旧システムではこれらを区別しておらず新システムもその仕様を引き継いでしまったため、プロフィール等の情報を公開することができる新システムではいろいろまずい点があるようだ。

ではどういう設計が理想的なのか独断と偏見で考えてみる。

1. ペンネームとニックネームは同じものか？

ペンネームはその本人にとっては実名と同じものと考えられるので別扱いのほうがよさそう。
システム的には記事署名とニックネームはまるっきり別のものであるということだ。
これは現システムでもそうなっていると言える。

2. 実名、ペンネーム、匿名の仕分けは？

先に述べたようにペンネーム≒実名なので実名、ペンネーム共に個人のプロフィールまたは登録情報の一部とするのが正しいように思える。
現在の記事投稿フォームを見ると実名／匿名の選択があり、匿名の場合はその時に使用する名前を入力するようになっているようだが、これは実名／ペンネーム／匿名の三択であるべきだろう。

3. 実名、ペンネーム、匿名の扱いは？

実名、ペンネームの場合にはプロフィール公開可能、匿名の場合にはプロフィール非公開固定となる。これが一番基本。

現在のシステムは記事署名からのリンクが http://www.ohmynews.co.jp/profile/n記事番号 という形式になっている。

一見匿名の事も考慮していい感じに思えるが、匿名の場合は元々リンク自体が不要である。

実名、ペンネームの場合にはいくらプロフィールが非公開だったとしても同一性まで隠す必要はないので、他の箇所でも使用している http://www.ohmynews.co.jp/profile/個人番号 という形式で良いということになる。

結局 http://www.ohmynews.co.jp/profile/n記事番号 という形式は必要ないという結論になる。

同一性の秘匿について異論があるかもしれないが、同一性まで隠す必要があるのならばそれは実名ではなく匿名であると（少なくともおいらは）言い切れる。

同一性を保障するペンネームのほうが実名主義の理念にかなっていると思うがいかがかな？

この事まで考えると http://www.ohmynews.co.jp/profile/n記事番号 という形式は不必要どころか有害であるとまで言えると思う。

あと考えなきゃいけないのは代理投稿か？

私見ではシリーズ物であるならばちゃんと別々のユーザー登録を行う、飛び込みであるならば特別に登録したひとつのユーザーで一括して処理するか別々のユーザー登録を行うかポリシーを決めてそれを尊守するようにすれば良いと考える。

適当なポリシーで適当な運用をしていると今回のリニューアルのような事態が発生したときにまた困ることになるだけ。

現在のシステムの編集部用の機能として存在するのかどうかはわからないが記事の付け替え機能はいろんなケースを考えると必須に近いように思える。

これで実名、ペンネーム、匿名、ニックネームの扱いについてはおいら的にはスッキリしたので次に永続性みたいなものについて考えてみる。
（スッキリしたいからこれを書いてる訳ですがw）

旧システムでは少なくともコメント時のニックネームそしてたぶん記事の署名も入力した時の値を表示し原則それが後から変更されることはなかった。
記録（ジャーナル）を残すという意味でこれは正しい仕様だと思う。
実は旧システムは入力時の値のみ保持しその他冗長な情報は保持していないのではないかと思っていたのだが、新システムにちゃんとデータを移行できたということは個人IDなどもちゃんと保持していたのだろう。見くびってました、ゴメンナサイ。

新システムではニックネームの登録情報を変更したときに全てのコメントの署名も変更されるようだ。記事の署名についてはわからない。

記録（ジャーナル）を残すという意味ではあまりよろしくない仕様であるような気がするがどうだろうか？

コメントの署名については旧システムではこれを悪用(?)する人がいたので確かに現在の仕様にもメリットはある。

では、記事の署名についてはどうだろうか？

現状どうなっているのかわからないので仮定での話しとなるが、これがコメントの署名と同じようになっているのであればそれはまずいだろう。

例えば、結婚・離婚して姓がかわったら過去の記事の署名も全部変わるのか？

そんなバナナ。

近頃問題になっている戸籍問題と同じような事がオーマイニュースの登録データについても起こりそうだ。

私は姓の登録を変更してはいけないのですか？これからはペンネーム（匿名）で記事を書いていかなければならないのですか？

と。

システムの人はとかくデータを正規化したがる傾向があると思うがそれだけが絶対ではない。例えば会計システムで会計年度を考慮せずに単に正規化してシステムを作成したらえらいことになる。（年度等履歴を考慮するかジャーナル主義[俺様用語]にするかはケースバイケースだとは思うが゛。）

余計な事かもしれないがちょっと心配してみました♡

続・オーマイニュースで市民記者のプロフィールを見る方法

オーマイニュースで市民記者のプロフィールを見る方法で紹介した明示されていない編集部記事を見分ける方法は、どうやらユーザー登録未完の状態だったようです。
（判別がつかなくなったけどこれはデグレートではないなぁ）

『憲法改正国民投票法案のどこが問題か』のこの記事へひと言欄での突っ込みが入ったら即座に修正されたようなのでまず間違いないでしょう。

同時に他の「（談　聞き手・古木杜恵）」が記事中に記載されている記事の記者プロフィールからもボタンが消えましたので同一ユーザーの手による記事という訳ですね。

まあ判別つかなくても「元木 <記者名>」で検索すればだいたいの推測は付く訳ですが、少し不便になりました。

この記事をシステムに入力したユーザーは旧システムで登録していなかった編集部員か新しく加わった編集部員か元木編集長代理本人かのいずれかでしょう。少し興味がありますね。

まさかとは思うけどいろいろ細工してあたかもちゃんとした記事（普通に市民記者が投稿した記事）のように仕立ててくるかもしれません。

もしそうならばエンジニアの人にとって無駄な作業が増えるだけですから止めてあげてください。

さてシステム的にはまだ解決されていない問題があるようですがオーマイニュースの中の人はどう考えているのでしょうか。

システムを開発したベンダーの責任？

確かにそれが主因かもしれませんが発注する側に責任がない訳ではないでしょう。

たとえば今現在も解決されていないと思われる代理投稿やペンネームの問題。
ベンダーの中の人がオーマイニュースの熱心なファンであったならば気がついたかもしれませんが普通は気がつかないでしょう。
たぶんヒアリング等行ったと思いますけど、オーマイニュースの編集部の方の誰かが責任を持って対応してあげましたか？
忙しさ等を理由にして時間を割かなかったのではありませんか？

ベンダーの中の人はシステムの専門家かもしれませんが、オーマイニュースの専門家ではないのです。オーマイニュースの専門家は編集部です。そこをお忘れなく。

ベンダーの中の人のほうも見通しが甘かったのかもしれません。コンピュータにあまり精通していないオーマイニュースの中の人を相手にする場合にはもっとリスクを高くとるべきだったのかも。

リリース当初の状況を見るにたぶん最低１回はリリースを延期したのではないかと思っています。もしくはIDCセンター等との契約の都合とか。
そうでなくてはあの混乱はないだろうと・・・。

あと多少興味があるのが開発費どれくらいかなっということ。

下衆の勘繰りで申し訳ないがハード等を除いてざっくり2000万と予測しました。
もちろんもっと少ないかもしれないしもっと多いかもしれない。
テスト不足であった現状を見ると予算不足だったのかもという憶測も成り立ちます。

いつもシステムの人にツンツンとしているので今日は優しさを多めにしてみました。

現在どういう状況なのかはわかりませんが、仲良くがんばってください。♡

続・オーマイニュースで画像を効率よく読み取る方法

オーマイニュースではたまに認証を求められる記事が掲載される。
漫然と原因は

(1) バックエンドの（編集作業用の）プログラムの不具合
(2) 編集作業者の操作不熟達、ミス（遠因としてはシステムの扱いにくさがある可能性あり）

のいずれかだろうなと思っていた。ここしばらく認証を求められるような事もなくこの問題は解決されたと思っていたのだが2007/04/25朝に掲載された『これが「段落の効果的な使い方」だ！』は久々の認証要求記事だ。日が変わった現在もまだ解決されていない。※2007/04/26 22:00 頃確認した時には解決されていました

コメント欄の情報を拾うと"ハグ"であるらしい。

欧米か？

いや、"バグ"だそうです。スマン。

本当か？

認証を求められる記事のhtmlソースを見てみるとURLが
http://manage.ohmynews.co.jp/img01/news/10/10193/aa2b0f0e2cd92673063f_l.jpg
である画像がある。どうもこれが原因のようだ。

たぶん http://manage.ohmynews.co.jp/ は編集者の作業用サーバーなのであろう。
（暗号化されない環境下での基本認証とはトホホであるが・・・）

オーマイニュースで画像を効率よく読み取る方法で述べたように
http://manage.ohmynews.co.jp/img01/news/10/10193/aa2b0f0e2cd92673063f_l.jpg
を
http://img01.ohmynews.co.jp/news/10/10193/aa2b0f0e2cd92673063f_l.jpg
に置き換えると無事画像を得ることができる。

更に世の中には細かい事に気がつく人もいるもので、２ちゃんねる掲示板で末尾の "_l" の部分を "_ll", "_l", "_m", "_s" に置き換えるといろいろなサイズの画像を得られるという情報を得た。投稿時のサイズはこれらサフィクスを除いたもので得られるらしい。

名無しさんに感謝！！

さて、バグらしいということなのでその傾向を考えてみたが img01, img02 での差はどうもないようだ。

原因はなんだろう？

他には正常に表示されている記事が多数あるのでどうしてもバグであるとは思えない。

あるとしたら操作ミス＋可逆性のないシステムと言ったところではないだろうか。まぁこれをバグと呼ぶかどうかは微妙だが編集部が「バグ」と回答するのもいたしかたないところか。

でも本当にバグである可能性もある。何故なら朝掲載された記事が日が変わるまで放置されているからだ。そんなに解決が難しいバグなのか？

もしくはエンジニアがお休みをもらっているとか、どうしても本日は都合がつかなかったとか・・・

どうにも釈然としないのは確か。

オーマイニュースから中間的な報告もないし、改善作業ははかどってるやらはかどっていないのやら。

まっいつものことだから仕方ないか。

さて、新しく manage.ohmynews.co.jp というサーバーも登場したことだし例によって突っ込まなくてもいいところに突っ込んでみる。

http://manage.ohmynews.co.jp:8080/

おー、Apacheをインストールしたデフォルト状態と思われるページが表示される。

8080は通常のhttpのポート80の代用として使われる一般的なもの。思いつきでURL叩いてみた。なんでこんなの表示させる必要があるんだろ。

http://manage.ohmynews.co.jp:8080/omn/

おー、スタイルシート等は読み込めないみたいだがオーマイニュースのトップページらしきものが表示される。
よくよく見ると最新のデータのようだ。ＤＢサーバーは表玄関と共用ということか。
"/omn/" はリニューアル当初のこのようなURLを見た記憶があったので何の気なく打ってみたらこうなったw。

これはなんの為にあるんだろ？。テスト用？？？。編集者用？？？。

認証の件も合わせてこういうのを見てしまうと漠然とした不安を感じてしまうのはおいらだけではないと思う。

最終的にはなんとかして欲しいな♡

[2007/04/26 06:30]
少し文面等を修正した。
[2007/04/27 06:00]
注釈を追加した。

オーマイニュースでサーバー混雑時にそれをすり抜ける方法

オーマイニュースで画像を効率よく読み取る方法で記述したIPアドレスの隙間の話について書いてみる。

自分でも無粋な事してるなと思いつつ、それでも男なら突っ込まずにはいられない。
（隙間と穴を勘違いしてるんじゃないの？という突っ込みはなしの方向でw）

という訳で以下のURLを叩いてみた。

http://203.104.96.164/
http://203.104.96.165/

お～、オーマイニュースのトップページが表示される。

画像については表示されるものと表示されないものがあるが、表示されないものは http://xxx/img01/～ http://xxx/img02/～ のものであるようだからこの２つのサーバーは www.ohmynews.co.jp[203.104.96.163]をアクセスした時にロードバランサを経由して呼ばれるものであると推測できる。

表示される画像は http://xxx/img/～ の位置にあるようだ。

ちなみに再び www.ohmynews.co.jp をアクセスして確認したところ、html本体についての分散処理はリダイレクトではなくフォワードによって行われているようだ。

ついでなのでもう少し突っ込んでみる。

表玄関に戻って http://www.ohmynews.co.jp/ をアクセスしてみてそのレスポンスヘッダーを観察してみると

Set-Cookie: www_sid=3fd2e2b18855eedeb105c039f07c1464ed44821b.www02; domain=www.ohmynews.co.jp; path=/

というような行が存在する。
これはサーバー側のプログラムがセッションを維持するためのデータだと推測される。
（注：コンピュータの世界ではセッションという言葉はいろんな文脈で異なった意味で用いられますので混同しないように）

注目すべきはwww_sid末尾の ".www02" で、これはたぶん負荷分散をアフィニティモデルで行う為に必要な識別子なのであろう。
そういえばリニューアル当初に ".www01" が付加されていたのを見た記憶がある。

何回かアクセスしてみる。".www02" は変化しない。あたり前か、アフィニティモデルだもんね。
アクセス毎にCookieを消すことにして再挑戦。".www02" は変化しない。負荷分散してない？？？

ここで結論を出すのは早計。負荷が重くならない限り www01 は使わないという仕組みかもしれないし、負荷分散の為ではなく耐障害性のための仕組みかもしれないから。

とりあえずわかったのは、203.104.96.164、203.104.96.165 は内部的には www01, www02 という名前で呼ばれているであろうサーバーということ。

ここで、エントリタイトルに対する結論。

サーバーが重い場合には、http://203.104.96.164/（あるいは165）に直接アクセスしたほうが早いかも？

まあぶっちゃけ早くはならないとは思うけどね。この手のシステムのボトルネックはWebサーバーではなくDBサーバーになるだろうと思うから。

さらにもう少し突っ込んでみる。

http://203.104.96.164/をアクスしてみてそのレスポンスヘッダーを観察してみると

X-Cache: MISS from www01

という行が存在する。何らかのキャッシュ処理をしているようだ。
同様にhttp://203.104.96.165/をアクセスしてみると

X-Cache: MISS from www01

という行が存在する。？？？。こちらは www02 じゃないのか？　まぁいいや。

"Cookie:" について注目してみると、それぞれ

Set-Cookie:www_sid=d90894ef64b47b2bc1a758512e6004605f46dd9c.203; domain=www.ohmynews.co.jp; path=/

Set-Cookie:www_sid=3fd2e2b18855eedeb105c039f07c1464ed44821b.203; domain=www.ohmynews.co.jp; path=/

だった。ん？ 両方とも末尾に ".203" が付いてるけどこれは本来 ".164", ".165" って付けようとしてたんじゃないのかな？
もしロードバランサーがこの部分を利用してアフィニティを実現しようとしているなら現状では負荷分散できそうにない感じ。やっぱ耐障害性ONLY目的なのかしら。
[2007/04/29 訂正]
これは内部名が www01, www02 と付けられている場合に http://www01/～ http://www02/～ というURLでアクセスすれば正しく .www01, .www02 が付加されるということらしいので間違ってはいない。疑ってゴメンネ♡

さらにさらに突っ込んでみる。

キャッシュ処理をしているかもしれないのでそれを確かめるために画像をアクセスしてみる。
http://203.104.96.164/img/leaf.png、http://203.104.96.165/img/leaf.png をアクセスしてみるとそれぞれ

ETag: "8b05cd-169-4614abaf"

ETag: "51d24e-169-4614abaf"

という行が付加されている。"X-Cache:"の行は存在しない。
キャッシュにヒットした場合には、"X-Cache:"の行を出力しないという仕様かもしれないからこの画像がキャッシュを通って得られたものであるかどうかはわからない。
まぁ一般的に静的なコンテンツは（サーバー側では）キャッシュしても性能向上には寄与しないと言われているのでどうでもいいけど、"Etag:"の値が異なるのは気になる。

値が異なるのは別サーバーなのであたり前なんだが、値が異なるということは負荷分散を行った場合にクライアント側（ブラウザ）のキャッシュが無意味になる場合があるということだ。（セッションを維持している限りは有効だと思うが・・・）

ひょっとしてリニューアル当初に激重だったのはこの辺りにも原因があったりして。

ここでの結論は今のままでは負荷分散してもいまいち非効率ということですな。

img01, img02 と同様に img も他サーバーに振り分けたほうが良さそう。もしくは、もっと前段でキャッシュするかのどっちか。あっ、"Etag:"を消してタイムスタンプのみの処理にするという方法もあるか・・・。

さて 203.104.96.164、203.104.96.165 に付いていると思われるキャッシュ処理はなんの為に存在しているのだろう？

前述したように静的コンテンツに対してのサーバー側でのキャッシュ処理は現在の構成では無意味。負荷分散との絡みもあるのでやらないほうが良さそう。
（注：現在も静的コンテンツに対してのキャシュ処理は行っていない可能性が高い）

では動的コンテンツ（例えば記事本体）に対してはどうだろう？

現状、同じ記事を何回アクセスしても "X-Cache: MISS from www01" が漏れなく付いてくる。
実際動的コンテンツをキャッシュするようにするのはそれなりに難しいと思われる。プログラム側がそれを考慮しなければならないからだ。

結局このシステム（の中のキャッシュ）は何を狙ったんだろう？

　(1) 動的コンテンツをキャッシュしようとしたが実装未完
　(2) 何も考えてませんでした
　(3) その他

まあ外から見ている範囲では構成設計が甘かったんだろうと思う。

もう既にサービスインしてしまっていて構成変更を行うのは至難の業だとは思うけど、がんばれる所はがんばってね♡

オーマイニュースで画像を効率よく読み取る方法

重箱の隅をつつくような話しで申し訳ない。先に誤っておきます。

オーマイニュースを読んでいるとたまにステータスバーに "img01.ohmynews.co.jpを読み込みました"とか"img02.ohmynews.co.jpを読み込みました"とか表示される。
これは何だろうと思って調べてみたところ http://www.ohmynews.co.jp/img01/ 配下へのRequest（画像の読み込み）は img01.ohmynews.co.jp に、http://www.ohmynews.co.jp/img02/ 配下へのRequest（こちらも画像の読み込み）は img02.ohmynews.co.jp にリダイレクトされているようだ。

先にエントリタイトルに対しての結論を書くと http://www.ohmynews.co.jp/img01/xxx/yyy.jpg というURLは http://img01.ohmynews.co.jp/xxx/yyy.jpg に変換しても読み込めるし、そのほうが効率がいい。
もちろん、img01 を img02 に置き換えても同じ。

以下続きは技術的な事に興味がある人のみどうぞ。

感想は「ふ～んユニークだな」である。もちろん負荷分散の為であることはわかるし、負荷分散にリダイレクトを用いることがある事も知っている。
ただ、リダイレクトによる負荷分散はリダイレクト先（負荷分散先）が複数存在する場合に用いるのが一般的だと思っている。
また、画像の読み込み目的のように個々の要求に対してリダイレクトを用いるケースはおいらが無知なだけかもしれないが初めてみた。

このようなケースの場合はロードバランサーが要求をリダイレクトではなくフォワードするのが一般的だと思っている。リダイレクトを用いるとリクエスト数が増える、Keep-Aliveの効果が減少するというデメリットがあるからだ。
もっともメリットもあり、ロードバランサーを通過する帯域に限界がある場合にはリダイレクトのほうが有利かもしれない。

本来はProxyを利用しないで計測すべきであるがその手段を持たないのでProxyを利用してそのログを観察してみた。
よって参考程度の資料にしかならないことをお断りしておく。

と、資料を載せようと思ったら文字数制限ではいらね～
とりあえず保留ね。

リダイレクトをフォワードに変えた場合は次表のようになる。

	リダイレクト	フォワード
TCPセッション数	42	12
リクエスト数	166	149

たぶんフォワードに変えれば最低10%くらいはレスボンスが改善されそうな予感。
まあぶっちゃけ特定のサーバーにしかリダイレクトしないのなら最初から画像のURLをそのサーバーに向けて記述しておけばいいじゃんとも思ってしまう。

ひょっとしたら前述したようにロードバランサーの帯域あるいは１IPアドレスに対しての帯域に制限があるのかもしれないが・・・。
仮に帯域を100Mとすると100くらいの同時アクセスには十分対応可能、1000くらいでも大丈夫そうな気がするんだがどんなもんでしょ？

帯域で気になったので動画はどうなっているかを見てみたがこちらは img01.ohmynews.co.jp へのリンクとなっていた。これで正解だと思うけど、なんというか、統一感がないな～。

ところでオーマイニュース関係のサーバーのIPアドレスは現時点では次表のようになっている。

名前	IPアドレス
www.ohmynews.co.jp	203.104.96.163
img01.ohmynews.co.jp	203.104.96.166
img02.ohmynews.co.jp	203.104.96.167

う～んIPアドレスの隙間が気になるな～。
この話しはまた気が向いたら書くかも。

なんかくだらないケチをつけてるようでごめんさない♡

オーマイニュースでコメントを読む方法（番外編）

スクリプトを改良しようと思いテストしてみたときにFireFoxのエラーコンソールを見ると次のようなエラーが出ている。
全部で 3 つだ。ん～。

エラー: MM_showMenu is not defined
ソースファイル: http://www.ohmynews.co.jp/news/0/2595/comment?open_comment=1
行: 1

エラー: MM_startTimeout is not defined
ソースファイル: http://www.ohmynews.co.jp/news/0/2595/comment?open_comment=1
行: 1

エラー: ドキュメント要素の後ろに不正な文字列があります。
ソースファイル: http://www.ohmynews.co.jp/news/0/2595/comment/64/view
行: 4, 列: 1
ソースコード:
<div class="news_hitokoto_comment">
^

ちょっと調べたところ 1 番目と 2 番目のエラーは、それぞれ onMouseOverイベントハンドラ、onMouseOutイベントハンドラ中で呼び出されている関数のようだ。
ハンドラ中での記述順が末尾であるため動作にはさほど影響しないようだがちょっと気持ち悪い。
FireFox特有で起こる現象なのかどうかは面倒なので調べなかった。
[2007/05/15 追記]いつ修正したのかはわからないが確認したところこの点は修正されているようだ。乙華麗♡

3 つ目のはちょっと解りにくいが XML としての整形式になっていないというエラーのようだ。
この場合はルートエレメントが 1 つでないためにエラーとなっている。

【正】

<RootElement>
・・・
</RootElement>

【誤】

<RootElement>
・・・
</RootElement>
<RootElement> <!-- 私二股かけられてるなんて許せない(怒) -->
・・・
</RootElement>

試しに手作業で直してテストしてみたが今度は img タグで怒られたりする。あたり前か。Ajax部で通信するデータは正式にはxhtml風になっていないと駄目つー事だね。

まあ動作してるのだから問題ないと言えば問題ないがちょっと気持ち悪い。

ここら辺りを修正されるとhtmlの構造が変わる可能性があるのでスクリプトを改善するのは一時中止するかな。
使ってるのは自分だけかもしれないし（しくしく）

後回しでいいから最終的には直してくれるとうれしいな♡

オーマイニュースで市民記者のプロフィールを見る方法

オーマイニュースで市民記者のプロフィールを見るには記事を表示したときに記者名部分のリンクをクリックすれば良い。

そんな事は知ってるって？ごもっとも。

では次の２つのプロフィールを見ていただこう。

前者は普通の市民記者のプロフィール非公開状態。
後者は
　「この記事は俺の記事だ。ガハハハハ。」
ではなく、市民記者登録をしていない人の記事を掲載した状態と思われる。まっ簡単に言えば非市民記者という訳だ。

オーマイニュースは以前よりMyNewsJapanより記事の配信を受けている。また編集部員による記事も存在する。
明記されている場合が多いが、明記されていないケースも存在する。
そんな時に役に立つかもしれないTipsという訳です。
（個人的にはその手の記事があまり多いのは・・・とは思ってる。）

市民記者の皆さんには出来ればプロフィールを公開していただきたい。別に市民記者の素性に興味がある訳ではなく他にどんな記事を書いてるかをすばやく把握できるからだ。プロフィール非公開でもこれは参照できればありがたい。（もし実装するなら匿名投稿の扱いとかにきをつけてね♡）

たぶん後者の図の状態は軽微ではあるが不具合なのだろうと思う。

でも、直すんなら非市民記者を見分けられるという長所は残しておいてね。

そうじゃないとデグレート（機能ダウン）だぁって叫んじゃうぞ♡　※追記参照の事

---

その他Tips[市民記者登録者限定]

以下の手順でコメント者のプロフィールが一般公開されている場合には、足跡を付けずに参照できます。

　(1) ログインする。
　(2) ニックネームで検索する。
　(3) リンクを見て登録番号(?)をメモる。
　(4) ログアウトする。
　(5) http://www.ohmynews.co.jp/profile/<登録番号(?)>を見る。

いまんとここれくらいしか思いつかない。くだらなくてゴメン。

できればコメント者の名前からプロフィールへリンクして欲しいなぁ♡

秘匿性が重要なら http://www.ohmynews.co.jp/profile/n記事番号cコメント番号 みたいな形式でいいからさ。（コレ実装するの面倒かもね）

知りたいのは何処の誰かではなくて、何に対してどんなこと言ってるか。ただそれだけ。

[2007/04/27 02:00 追記]

どうもプロフィールにボタンが出る状態はユーザー登録未完の状態だったようです。
詳しくは
続・オーマイニュースで市民記者のプロフィールを見る方法を参照してください。

続・オーマイニュースでコメントを読む方法

オーマイニュースでコメントを読む方法でコメント自動展開スクリプトを紹介しましたが、Internet Exploler + .NET Framework + Trixie でも利用できるようです。

Trixieは .NET Framework を利用しますので .NET Framework がインストールされていない場合は事前に .NET Framework のインストールが必要です。
（お使いのＰＣによっては最初からインストールされている場合があります）

.NET Framework には大きく分けて バージョン 1.0 ～ 3.0 までありますが、Trixie の説明にはバージョンは明記されていないため、最低バージョン 1.0 でも大丈夫なのではないかと思います。
基本的に上位互換であるため可能な限り新しいものを入れておけばいいと思います。
（私自身は WindowsXP SP2 + .NET Framework 2.0 + Internet Exploler 6 or 7 という構成です）
お使いのコンピュータのＯＳの種類によっては低いバージョンしかサポートされていない場合がありますのでご注意ください。

.NET Framework のダウンロードはこの辺りから。（辺りと書いたのは前述した理由による）
あるいは Windows Update でのカスタム⇒追加選択からもインストールできるかもしれません。

Trixie のダウンロードはこちら http://www.bhelpuri.net/Trixie/から。

Trixieをインストールした結果、Internet Exploler のメニューの「ツール(T)」に「Trixie Options ...」が追加されていれば成功したものと思われます。

スクリプト本体についてはオーマイニュースでコメントを読む方法を参照してください。

スクリプトのインストール方法はGreasemonkeyとは異なり手動でコピーを行わなければなりません。

通常のインストールを行った場合 C:\Program Fiels\Bhelpuri\Trixie\Scripts\ がスクリプト置き場になりますので、ここにスクリプトを置いてください。

以上です。

ただ、少し気になることが・・・ Inernet Exploler を利用してオーマイニュースを読んだときに通信状態などで（オーマイニュースの）スクリプトが一旦エラーになるとその後ここで紹介したスクリプトも動作しなくなることがある模様です。
まぁ希なケースだとは思いますが・・・。

では興味がある人は試してみてください♡

オーマイニュースでコメントを読む方法

というタイトルのエントリを考えていたんですがオーマイニュースの中の人に先を越されました。

キーッ悔しい。泣いてなんていないからね。

現時点でまだ些細な不具合はあるものの50件以上のコメントにも対応してくれるようになったので方向性に文句はありません。

私から見てクリティカルな機能不全は解消されたため、この手のエントリをすることはもうないかもしれません。（わかんないけど・・・）
なんとなく峠は越えた感じ。

ということで更新が凍結されるか滞りがちになる可能性が高い事を述べておきます。
今まで読んでくれた人ありがとう。

オーマイニュースの中の人も読んでくれてるかな？。
ひょっとしたら最後になるかもしれないので某所の某人のコメントを引用しておきます。

> 先が全く見えない状態だろうけど、あきらめたらそこで終わりですよ。
> 泣きながらでもいいから、ガンガレ＞中の人

ん～自分にも突き刺さる言葉だなぁ。

とにかくがんばれ♡

---

これだけの内容じゃ寂しいので「Greasemonkey」用のスクリプトを載せておきます。

「Greasemonkey」とは何かについては「FireFoxまとめサイト->Greasemonkey」をご覧ください。

これは旧システムでも『オーマイニュースの使い勝手が向上！』で紹介されているツールです。

簡単に言うとブラウザFireFox用のアドオンで指定したURLのページを読み込んだときに指定したjavascriptのプログラムを起動させるツールです。

開発元・配布元はこちらです。

「Greasemonkey」のインストールについては説明しませんので自力でがんばってください♡

ではスクリプト本体。

// ==UserScript==
// @name          ohmynews article ver 0.1
// @namespace     http://blog.goo.ne.jp/nagamasa2005/
// @description   auto comment open
//
// Items page
// @include       https://www.ohmynews.co.jp/news/*
// @include       http://www.ohmynews.co.jp/news/*
// ==UserScript==

open_comment();

function open_comment() {
  // ex. http://www.ohmynews.co.jp/news/20070412/10103
  // ex. http://www.ohmynews.co.jp/news/c...
  // ex. http://www.ohmynews.co.jp/news/list...
  var url = document.URL;
  var i;
  i = url.indexOf("://www.ohmynews.co.jp/news/c");
  if (i >= 0) {
    return;
  }
  i = url.indexOf("://www.ohmynews.co.jp/news/list");
  if (i >= 0) {
    return;
  }
  var s;
  s = url.match(/https?:\/\/www\.ohmynews\.co\.jp\/news\/[0-9]+\/[0-9]+\/comment.*/);
  if (s != null) {
    window.opener.focus();
    return;
  }
  
  var no = url.replace(/https?:\/\/www\.ohmynews\.co\.jp\/news\/[0-9]+\/([0-9]+).*/, "$1");

  var c_url = "http://www.ohmynews.co.jp/news/0/" + no + "/comment?open_comment=1";

  window.open(c_url,"ohmynews_comment");
}

上記水色の部分をコピーしてメモ帖などに貼り付けて名前を付けてファイルを保存してください。

名前は、xxxxxx.user.js という形式でなくてはなりません。（xxxxxxは任意）
私は「nm_ohmynews_article.user.js」というファイル名で作成しています。

ＯＳの設定が拡張子を表示しないようになっている場合は注意してください。たぶん拡張子を表示する設定に変更したほうが無難です。

この保存したファイルをFireFoxで開けば（具体的にはドラッグ＆ドロップ等で）「Greasemonkey」のスクリプトとしてインストールするか否かを聞いてきますのでインストールすればＯＫです。
もちろん「Greasemonkey」は事前にインストール済みでなければなりません。

そうそう機能を説明していませんでしたね。このスクリプトはオーマイニュースの記事を読むときに同時にコメントを全展開するスクリプトです。

免責事項。

このスクリプトによって万一使用者が損害を受けても私は何らその責任を負いません。負えません。
また、「Greasemonkey」をインストールすることによりセキュリティ上の脆弱性が生まれる可能性が高まるということも知っておいてください。

要はすべて自己責任でお願いしますということです。

ブラウザ Internet Exploler にも 「Greasemonkey」準拠の Trixie というものがあります。
ブラウザ Sleipnir にも SeaHorse というものがあります。

これらについても対応可能かどうか調べてみるつもりです。
また、もう少し改良するかもしれません。
（※追記 とりあえず Trixie で利用できるようです。次エントリで軽く説明の予定）

またたいしたスクリプトでもないので勝手に改良、再配布してもらっても結構です。
ただし、改良したものを再配布する場合には少なくとも@namespaceは変更してください。
また再配布する場合には念のため前述した免責事項に類似した内容の告知をお願いします。

とりあえず今日はこのあたりで勘弁してあげます♡
（まだ少しは続くかもってことだな）

[2007/04/17 01:05]
若干内容を追加しました。
[2007/04/17 01:07]
うわっエスケープ文字消えてる。gooプログのイケズ。ちと待って。スクリプト修正中。
[2007/04/17 01:09]
たぶんこれでいいはず。追記するときには気をつける事＞俺。
[2007/04/17 02:10]
見直したらスクリプト中 // ==UserScript== が余分にあったので削除。
追記の時刻も未来予想図になってたので修正。さんざんだぁ。
[2007/04/17 23:40]
Trixieで利用できる旨の注釈を追加。