オーマイニュースに繋がらなかったり重かったりした件について

オーマイニュースのお知らせにて経緯が知らされている。
http://www.ohmynews.co.jp/information/10066

2008/04/07 11:01（障害報告）
アクセス急増に伴う接続障害について
4月6日夜21時ごろから数時間、一部コンテンツ（加護亜依さん関連記事3件）にアクセスが殺到し、サイトを閲覧できない状態が続きました。現在（7日午前）は復旧しておりますが、コンテンツの表示に時間がかかっております。ご迷惑をおかけし、申し訳ございません。現在、対応中ですので、恐れ入りますがしばらくご辛抱いただきますようお願い申し上げます。

http://www.ohmynews.co.jp/information/10067

008/04/07 15:28（障害報告）
サーバ動作復旧のお知らせ
4月7日午前10時から、サーバパフォーマンスの改善処置を行い、13時30分現在、通常動作に復旧いたしました。アクセス量によって、今後もご不便をおかけする場面があるかもしれませんが、引き続き注視してまいりますので、何とぞよろしくお願いします。

う～ん、"サーバパフォーマンスの改善処置"って何をしたんだろう？

2007年4月のリニューアル後のオーマイニュースのサーバー構成は『オーマイニュースでサーバー混雑時にそれをすり抜ける方法』に書いたように、画像関係を除いてはWebサーバー×2という構成だったと思われる。その後、『オーマイニュースのメンテナンス内容について』に書いたように実質上Webサーバー×1という構成に変更したと推測している。実際、4月6日夜サイトにアクセスできなかった時でも、http://203.104.96.164/にはアクセス可能だったので、かなりの確度で当たっていると思う。

少し予想外だったのは、http://203.104.96.164/では重いながらも正常に閲覧可能だった事。DBサーバーより先にWebサーバーがボトルネックになっていたという事だ。と言ってもかなり重かったので、どちらが先かというのは僅かな差でしかなかったのかもしれない。

前述したお知らせを見て少しだけ観察してみたが、外側からの変化は特にわからなかった。せいぜいWebサーバーのパラメタ等を変更した程度ではないかと思う。つまり
根本的には解決されていない
だろうということだ。

突発的なアクセス増の場合、不利な事がある。ブラウザ側にキャッシュされたデータを持たない新規アクセス者の場合、画像データやCSSスタイルシート等も含めて全てのデータをロードするので、常日頃オーマイニュースを閲覧している人がアクセスする場合よりもさらに負荷がかかる。

4月7日も17時頃(だったと思うが)かなり重かったので、結構ギリギリだったのではないだろうか。また、いつの日か同じような事態に陥りそうだ。

お金や時間もかかるので、抜本的な改善はなかなか難しいと思うが、少なくとも今回の件で、ピーク時の最大リクエスト数などのデータは残しておくべきだろう。そうすれば、ベンチマーク等でも実際に近いパフォーマンステストが可能になる。
ベンチマークの例の1つとしてこちらをどうぞ。『実用 Apache 2.0運用・管理術/第2回　JMeterによるWebサーバ性能評価の勘所』

ちゃんとお知らせ出した点は○。ある程度の諦めは必要かもしれないです♡

オーマイニュースの新サービス(?)OhmyMailはちょっと微妙

俺的には、なるべく垣根は低いほうが良いと思っているので、いつの間にか始まったらしいOhmyMailを基本的には良いことだと思うのだが、ちょっと微妙だなと思う所もあるので突っ込みを入れてみるw

OhmyMailの登録画面、https://www.ohmynews.co.jp/signup_mailmag/entryを見てみると、メールアドレスの登録部に

現在、「MSN Hotmail」（「@hotmail.com」や「@hotmail.co.jp」など）のメールアドレスに、メールが届かない状態になっております。ご加入のプロバイダなど、ホットメール以外のメールアドレスでご登録下さい。市民記者登録で使用しているメールアドレスは、ご利用できません。

という注意書きがある。

このうち『市民記者登録で使用しているメールアドレスは、ご利用できません。』という文言からは、市民記者登録とは別に登録可能であるように読み取れる。
実際、メールマガジン「OhmyMail」利用規約を読む限りでは、市民記者登録とは別にOhmyMailに登録することは禁止されていないようであるし、たぶん可能であろう。
ところが、同利用規約の"第3条（サービス内容等）"には

2.本会員登録後、市民記者登録した場合、本サービスは市民記者用メールマガジンに移行します。

とあるので、市民記者登録への誘導としての目的もあるようだ。

いや、別に何か間違っているという訳ではないが、
少しもぞもぞする
なんか、もう少し奇麗な体系にならないものなのかなぁと思ったりする訳さ。既に市民記者登録している人が何も考えずに登録した場合に何かトラブルを起こしそうな悪寒が少しだけする。


実際にどういうものが配信されるのかを見てみると

1. 毎日配信「日刊OhmyMail」
   
2. 週刊配信「週刊OhmyMail」

のようにサンプルらしきものが用意されている。結構親切ね。

内容を見る限り、「日刊OhmyMail」のほうは基本的にはRSSフィード情報に同等で、「週刊OhmyMail」のほうは市民記者用のメルマガに同等であるような感じだ。

RSSなんかは、未だに『それ何？』という人もいるだろうからこういうのもいいかもしれない。ただ、実際に登録してみないとわからないが、この2つが常に配信されるのであればうっとおしいと思う人もいるかもしれない。配布物を選択できるとモアベターだと思うができるのかな？

で、一点だけマジ突っ込みなんだけど、サンプル上に示されている配信停止用のURL"https://www.ohmynews.co.jp/resign_mailmag/"は、このエントリを書いている現時点では
存在しません＞＜

サンプルが間違っているのかもしれないが、一旦登録したら解除できないかもしれない。何とかホイホイじゃないっつーのw

もしマジに間違っていたら早々に直してください♡

続・オーマイニュースでは未だに重複投稿が発生するらしい

オーマイニュースのSNS内の情報を元にしたネタでなんとなく多方面に申し訳ない気もするのだが、このブログの趣旨的に面白いので取り上げてみる。

ど～も、記事投稿時にも重複投稿は発生するようだ。まあ、当たり前と言えば当たり前なんだけど、症状が少し変わっているみたいだ。

俺が誤って理解している可能性もあるが、理解している範囲では次のような現象らしい。

1. (市民記者が)投稿する
   
2. (編集者が)重複投稿を見て(多分、重複分のみを)消す。(不採用とする?)
   
3. (市民記者側には)不採用と通知される

?


よくわからないのだが、市民記者側には重複投稿ではないように見えていて、編集者側には重複投稿であるように見えているということなのだろう。

まずは重複投稿どうこうを置いておく事にすると、市民記者側に見えている情報(リスト)と編集者側に見えている情報が１対１ではないらしい事が少し不思議。

これはたぶん市民記者側に見えているのは投稿時のそのままの原稿に関する情報で、編集者側に見えているのはそれを複製して作られた編集作業用の原稿ということなのだろう。しかも元原稿１に対して編集作業用の原稿は複数作成することも可能ということなのではないかと思われる。

まあ、元原稿が１つでも、上下に分割したりするかもしれないから必要な機能なのかも。

で、一旦分割された後は、分割したピースの１つでも消すと市民記者側には不採用として通知されてしまうという事なのではないかと推測。

この推測が正しいとするとまずは↑の仕様がいまいち(正しくは全分割ピースを消した時に初めて市民記者側に不採用と通知されるべき)なんだが、それ以前に

これってたぶん重複投稿じゃないんじゃね？

普通の意味での重複投稿であれば、市民記者側のリストにも重複して表示されるはずで、重複投稿であると認識できるはず。そのうちのひとつが不採用にされたとしても意味はわかるんではないかと思う。

まさかとは思うが、場当たり的に"重複投稿があっても市民記者側のリストには表示しないように修整"した経緯があるとしたら、同じような症状が現れるかもしれないが、いくらなんでもこんな酷い直し方はしないだろう。

このような症状が現れる可能性をあまり思いつかないが、元原稿→編集用原稿にコピーする処理に欠陥がある可能性が高いような気がする。
前提となる俺の推測自体が当たっていない可能性も高いんだがw

まあよくわからん。

こういう時に処理の詳細なログを採取するように作ってあると原因追求・修正が楽なんだけどね。オーマイニュースのシステムの場合、そこまでの厳密さが求められているとは思えないから多分そんなのはないだろうなぁ。

多分関係ないだろうなぁと思いつつ、経験上わかりにくかった過去の事例を１つ。
確かIE5.5の特定のバージョン(セキュリティパッチのあたり方によりいろいろあるので^^;)で、ブラウザが勝手に重複投稿するというもの。
まあさすがに今時はないと思うけど、どこに原因があるかはちゃんと確かめないと直るものも直りません＞＜

あと、これも関係ないと思うけど、一般的に重複投稿を避ける方法のひとつは『オーマイニュースでは未だに重複投稿が発生するらしい』にて既に書きました。

がんばって直してくださいな♡

オーマイニュースはノッペラボーを目指す

以前に確か『にいはんは周回遅れ』のコメント欄かどこかで、だんだんいろんなものが無くなっていくのではないかという話をしていたような記憶があるが、意外と早くもぎとれた模様です。



以前は、評価人数があったのに無くした模様。

これもまた昨日追加されたらしい文言
『あなたも評価に参加してみませんか？　市民記者になると10点評価ができます！』
の意味が、(元々意味は無いと思うがさらに)薄れてしまうような気がする。

こういうのをアドホックっていうんだろうな・・・整合性まるでなし。

たぶん、次は『私の記事評価が無し(あるいは一桁)なのは傷つきます』とか言われて、評価点自体が無くなるのだろうと思う。

たまには正当に評価されていないケースも存在するかもしれないが、ほとんどの場合はつまらない記事につまらないとか、間違った記事に間違っている等の評価が付けられているだけでしょ？
それを消しにかかるという事は、いろんな意味でフィードバックする気はゼロということだな。

それとも透明性をさらに薄めてなにかするつもりなのかしらんとさえ思えてしまう。
今後、平均点で表示されるYahoo!の評価と比較するのも一興かもしれない。

これでは『透明性を！！』なんて謳う記事は恥ずかしくて載せられないよねｗ

何か一般的にネットで望まれている事の逆、逆と進んでいるように感じる。

実験としては面白いんじゃね～のということにしておきます♡

オーマイニュース編集部用の業務システムサンプルの構築に関するメモ

『オーマイニュース編集部用の業務システムサンプルを構築してみたw』で、プログラムやPC環境にそんなに詳しくない人でもがんばれば、フリーでワークフロー環境が構築できるように『Trac月+trac0.11bの説明』を公開してみたが、その後。

はっきり言って、プログラム開発環境の話で、オーマイニュースには関係ありませんw 失礼b

編集部業務用にはとりあえずミニマムセットで作ったが、これを自分のプライベートな用途にも使おうと思い、Eclipse+Mylyn+Subclipse+Trac月+trac0.11bという構成でトライ。Mylynは配布セットにもよるがEclipseに最初から含まれていますです。

まずSubclipseを導入して、Trac月に含まれているSubversionとの連結を試みるがこける。どうもSubclipseで使うSVNクライアントの選択に注意が必要のようだ。

次に、MylynをTracと連結させるために、Trac上でXML-RPCプラグインが必要とわかったので、なんとか動作するようにしたが、最初のうちエラー内容がわからず苦労した。素直にログを見ればよかった。やっぱ急がば廻れだな。XML-RPCプラグイン導入については、『Trac月+trac0.11bの説明』に追記したのでそちらをどぞ。

今まで、Mylyn使ってなかったが、便利だ。

感動!!

どんなものかを一言では説明しずらいが、例えばWindowsでもデスクトップ環境をある程度復元してくれるでしょ？例えば開いていたフォルダとか。そういうのを、"タスク"に結び付けて保存・復元してくれるような感じのよ。(Eclipse内に限っての話だけどね)

これだけだと、仮想デスクトップが複数存在するのと何が違うのというように思う人もいるだろうけど、この"タスク"自体が、タスクとして管理されたものになるわけよ。
具体的に何が便利かというと、複数のタスクを抱えていた場合に、それらを切り替えて"現在、とりかかっているタスク"として選択することにより、それを行うのに必要なリソースだけが見えるという感じ。
いろんな事を同時にこなしていても、何をどこまでやったんだっけ？という状態に陥りにくくなる。これなら割り込み仕事でも少しは気楽さ。

で、MylynとTracを結びつけると、Trac上のチケットをMylyn上のタスクとして扱えるようになるので、尚更便利(便利というより管理し易くなる)。

もうひとつ便利(怖い)のが、Eclipse上で作業していた時間をタスク毎に算出してくれる機能。アイドル時間とかも推定してくれるようだ。この機能は怖いw

Eclipse上ですべての作業ができたら幸せかもしれない。たまにはいろんなプラグインでもあさってみるか・・・
欲を言えば、スクリプト系の言語でもっと手軽かつ自由にカスタマイズできたらいいのにな。Emacsみたいに。


で、しばらく使っているとSubversionの取り扱い時にエラーが。

svn: Checksum mismatch for 'src/nagamasa/ohmyokome/Main.java'; recorded: 'ebdfc3d7691e3e46b05e141ca9b3736e', actual: '48da972fcebd0e57cb318fc85484778c'
update -r HEAD C:/Documents and Settings/nagamasa/workspace/OhMyOkome
At revision 687.

みたいなメッセージ。

原因がよくわからん。Subversionのリポジトリ自体、CVSからSubversion Importerを使ってコンバートして生成したものなので、この過程がまずかったのかもしれないし、Trac月に含まれているSubversionがおかしいのかもしれないし、Subclipseがおかしいのかもしれない。

いろいろ試して(この間、Eclipseがまるっきり立ち上がらなくなるという事もw)、たぶんSubclipseがおかしいのだろうという結論に達して、Subclipseを止めてSubversiveに乗り換える。その後正常そうなので、これで良しということにしている。

これで万事OKかというとまだあるw プログラムソースを変更後Subversionに対してコミットすると、Tracのチケットに対してもコメントを追加するはずなのに、そのようにはならない。

これもいろいろ調べた結果、"Trac月のインストールディレクトリ/projects/svn/プロジェクト名/hooks/post-commit.bat"あるいは"Trac月のインストールディレクトリ/bin/post-commit.sh"のいずれかが悪いということまで確かめる。

post-commit.batは下記の内容。(俺のところはCygwin入れている都合で最終行のみ少し修整しています)

SET TRAC_LIGHT_HOME=C:\ProgramFiles2\TracLight

::-----------------------------
::Call the TRAC post-commit hook
::
SET REPOS="%1"
SET REV=%2

FOR /F "usebackq delims==" %%i IN (`%TRAC_LIGHT_HOME%\python\python.exe -c "import sys,re;r=re.split('/',sys.argv[1]);print r[len(r)-1]" %REPOS%`) DO SET PROJECT=%%i

%TRAC_LIGHT_HOME%\bin\bash.exe %TRAC_LIGHT_HOME%/bin/post-commit.sh "%1" %2 "%TRAC_LIGHT_HOME%" "%PROJECT%"

ここにデバック用に "ECHO %2 >> \WORK\debug.log"とか入れてみるんだが、こける(そこで終了してしまう)。%2 の中味がわかんない。何故こけるかもわからん。
こんな風に%nを(全ての場合ではないが)参照した瞬間にこける原因を誰か知っていたら、後学の為に教えて欲しい!

んで、仕方がないので試行錯誤の結果、post-commit.shの方を以下のように修整した。

#!/bin/sh

REPOS="$1"
ARG2=$2
TRAC_LIGHT_HOME="/ProgramFiles2/TracLight"

REV=`(echo $ARG2 | gawk '{ print $1;}')`
PROJECT=`(echo $REPOS | gawk -F '/' '{ print $(NF);}')`

LOG=`svnlook log -r $REV "$REPOS"`
AUTHOR=`svnlook author -r $REV "$REPOS"`
TRAC_ENV="$TRAC_LIGHT_HOME/projects/trac/$PROJECT"

python.exe $TRAC_LIGHT_HOME/python-lib/trac/contrib/trac-post-commit-hook \
-p "$TRAC_ENV" \
-r "$REV" \
-u "$AUTHOR" \
-m "$LOG"

gawkはたぶん、Cygwinに入っている奴が動作しているはず。(俺っててきと～)

といろんな試行錯誤を経て、動作するようになりましたとさ。
俺の環境に依存して発生した事象かもしれないので、一般的な参考にはならないかもしれないが、メモとして。

誰かの何かの役に立てば幸いです♡