2011年5月1日
起きてる間、相変わらずしてることはウィキペディア。こんなことでいいんだろうか。
2011年5月2日
今日もウィキペディアの旅に出る。「Wikifyタグ」が貼られた記事の一覧なんてのを見つけたので、修正できる記事が山盛り。「Wikifyタグ」というのは、Wiki的なマークアップになってないという意味で、要するにベタテキストに近い状態という指摘ですな。
この一覧を見ていると呆れるというか、世間の人は逞しいというか。自分に関する記事を堂々とざくざく作るのね。しかも、マークアップは適当で。それでも、よっぽどひどいので無い限り即削除にはせずにタグを貼って何年も修正を待ち続けるウィキペディアン。ウィキペディアンって消耗しそう。
で、旅にはまって、結局朝まで。12時間以上、ずっと続けて作業していたわけか。いいのかな、そんなことで。よくないような気がするんだけど。
2011年5月3日
ということで、寝ずに朝を迎える。
昼頃に少し仮眠。3時間くらい寝ただけだけど、だいぶ楽になったかな。
そして、起きてる間はだいたいウィキペディア。
夜は普通に寝る。
2011年5月4日
朝、普通に起きれた。というか、夏布団に変えたら風邪をひいたらしくて、鼻水が苦しくて起きた。
で、またウィキペディア。とりあえず、Wikifyに全部目を通すところまでは頑張りたい。
作業中に改名したり統合したりした方がいい記事をみつけたので、改名提案と統合提案もしてみる。手順を調べなくてはいけないので、結構大変。ほんと、なにやってんだか。つうか、日本語版の記事が増えるといいなと思っているのに、減らす方向に活動してどうするんだよとも思うけど、一方で ウィキペディアの内容が少しでも整理されるといいなとも思うので、これでいいかな。
そうだ、思い出した。アカウントを取ったきっかけは、くだんのスラドのストーリーに「スペイン語版に記事数で抜かれた」という一文が付いていたのもあるんだよね。それなら、微力でも記事数を増やすように協力して、追いつけるようにしようかなと思ったわけだ。なのに減らす方向に動いてるという矛盾。
2011年5月5日
起きてやることは相変わらずウィキペディア。とりあえずWikifyの一覧の全部に目を通せたので、一区切りついたかな。んが、今度は孤立したページ(他の記事から一切リンクされていないページ)の一覧なんてのを見つけて、目を通し始める。こういう作業を雑草取りと言うらしいけど、きりがないよね。でも、誰かがいつかはしないといけない作業でもあるんだろうけれど。
2011年5月6日
やることは相変わらずウィキペディア。ウィキペディア中毒なんて言葉もあるらしく、こんな現象は珍しくないみたい。そうなのか。とはいえ、一種の中毒症状なんで、自制が必要だろうね。
夜もウィキペディア。「プロジェクト:孤立文書」というのに参加してみた。
プロジェクトというのはウィキペディアの中で特定のテーマに沿って記事を作成したりガイドラインを策定したりする集まりのこと。一般には執筆する分野ごとにプロジェクトが作成されるんだけど、特別なプロジェクトとしてメンテナンス系のものがあり、その一つが「プロジェクト:孤立文書」ということ。とりあえず、孤立したページを全部一通り目を通してみるまでは一区切りつかないかな。現時点で対象は1890ページと膨大なんで1日では終わらないけど。
2011年5月7日
相変わらずウィキペディアなわけだけど、ちょっと飽きてきたかな。作業量が膨大にあるというのも理由かも。なんというか「ウィキペディアを完全に整理された状態にしたい」という理想があっても、現実には実現不可能なわけで。その辺で燃え尽きちゃう人も多いんじゃないかと想像。でもまあ、一人の手では不可能でも、多人数がちょっとずつやれば少しでも理想の状態に近づいていくわけだから、こうして作業することが全く無意味でもなかろう。
今日でウィキペディアの編集回数が300回を越えました。
2011年5月8日
相変わらずウィキペディア。データベースのメンテナンスが行われて、孤立したページの一覧も更新された。1804件と100件近く減少していた。全部が全部私の手柄ではないだろうけど、こうして有意に結果が出ると張り合いが出るね。
ようやく孤立したページの全チェックが完了。これで、これからは新規に追加された記事だけをチェックすればいいから楽になる。
ウィキペディアもOSSも似たところがあるのかな。OSSではコードを書きたい人は沢山いるけど、テストやデバッグやドキュメント書きなんてメンテナンス作業をしたがる人が少なくて困ってるそうだけど、ウィキペディアも記事書きたい人はいくらでもいるのにメンテ要員が足りてないんじゃないかと想像。
ところで、ウィキペディアでは議論も全部wikiでやるんだけど、これってちょっとと思うところがなきにしもあらず。wiki記法が使えるから便利なんだけど、ツリー管理とか署名とかも全部自分でやらなきゃならない。悪い奴がこれまでの議論を全消しとかも出来る(履歴から復帰できるけど)。なにより、ツリーが膨大になってくると、新しいコメントがどこについたのかがさっぱり分からないという点が辛い。なんか方法があるのかなぁ。
提案とか依頼を次々出していたら、自分が今一体どれだけの案件を抱えているのか、わからなくなってきた。一通り終わるまで、続きは自重したほうがよさそう。
ウィキペディア日本語版は現在75万記事ほどあるわけだけど、もしかしてこれって全然少ないんじゃないのかなと、ふと思った。記事をざくざくメンテナンスしていると、ほんとありとあらゆることが記事に成り得るなと思える。そんなことを網羅しようと思ったら、今の百倍も千倍も記事が必要じゃないだろうか。とすると、参加者の数も現状では全然足りてない。もっともっと増えるといいんじゃないかな。
2011年5月9日
相変わらずウィキペディア。削除途中で止まっている記事を発掘する作業を思いついて取り掛かる。600件くらいある削除タグ貼り付け記事中、依頼がされてないのは11件。意外と少ないな。しかし、サブノートが作成されてても正式依頼は行われていないとか、依頼が行われているけど議論の途中で放置されているのとか、問題のある記事は色々あるみたい。こういうのはフィルターとかボットとかで検出してもらうのが望ましいんだろうなぁ。
削除の方針では、主執筆者自身による削除依頼はOKというのがある。さっきみつけた11件のなかには、そのケースに該当するものがいくつかあった。削除依頼に出していれば問題なく削除されるだろうと思うけど、削除タグが貼られただけで削除依頼されてないので放置されていると。でも、これって依頼者の心情としては「削除して欲しいと思ってるのに、なんでいつまでも記事が残っているのよぉ」ってところだよね。ということを勝手におもんばかって、代理で削除依頼を出してみる。そんなことが通るのかどうか分からないので、ためしに1件だけ。
そんなことをしていたので、就寝は明け方の5時頃。だめだめ。
2011年5月10日
起きて相変わらずウィキペディア。しかし、Wikifyも孤立も一通り作業をしたから、特にすることがない。一種の燃え尽き？
夜もウィキペディア。荒らしを見つけてしまった。放置しようかなぁとも思ったけど、見つけてしまったので仕方なくリバート(過去の正常な版に差し戻し)。こんなことして、荒らした人が逆ギレして絡まれたらどうしよう。まあ、その場合はスルーしてればいいか。
2011年5月11日
改名、統合提案から1週間が経って反論がなかったので、それぞれ作業に着手する。手順がいろいろあってややこしい。
今更ながらに自分のウィキペディアでの現時点での方針。タグは貼らない。タグは取らない。削除はしない。ということにしよう。しばらくしたら、また変わるかもしれないけど。とりあえず今のところは。これは揉め事に巻き込まれるのを避けるためってのもあるんだけどね。といいつつ、削除依頼は出してるんだけど、それはどう考えても削除するのが適切だろうと思われる場合だけ。
削除はしないというのは、記事自体だけでなくて文章も含めて。出典が不明だったり誇大だったりと問題のある文章でも出来るだけ改変しない。それは、個人的にはそんな記事や文章でも存在価値があると思うから。ウィキペディアの方針とは合致しないけど。しかし、私が個人的にそう考えてサボタージュすることは別に問題なかろう。どうせ他の人が削除して回るんだし。
あと、今は特筆性に欠ける記事だったとしても、将来に何か特筆することが起こるかもしれない。そうしたときに、スタブ(書きかけで内容に乏しい記事)でも記事があったほうが役に立つということもあるしね。
孤立したページのうち、曖昧さ回避(複数の意味がある単語で、それぞれの記事に誘導する案内記事)のものを索引に登録していくという作業を始める。曖昧さ回避の記事は、その特性上他の記事からリンクされることが有り得ない(普通は誘導先の記事に直接リンクを張る)から、孤立する場合が多い。その場合でも索引には掲載できるから、掲載すれば孤立から救済できるというわけ。
索引を手動で作るのってどうよとは思うけど、孤立したページを減らす方法としては有効なので。とりあえず、アルファベット、ひらがな、カタカナで始まる記事は全部チェックが終わった。漢字で始まるのは、明日にしよう。
記事にはデフォルトソートで読み仮名をふることになってるんだから、そこから索引を自動生成できるように思うんだけど、なにが問題になってるんだろうか。と思ったら、「プロジェクト:索引」というのがあって、そこで索引の自動生成について議論があったみたいだけど、議論が止まってしまっている模様。
ウィキペディアでの標準時間は当然ながらUTC(世界協定時)。個人設定でローカルタイムにすることも出来るんだけど、そうすると議論の時に不便になる。発言には署名と共に発言日時を記載するわけだけど、これがUTCになっているから、日本標準時でウィキペディア上で活動していると新しい発言なのに過去の日時に見えてしまう。
ということで個人設定でUTCにしたんだけど、そうすると今度は今が一体UTCで何日の何時なのか分からなくて不便。いちいち時計を見て9時間引くなんてやってられない。試しに世界時計アプリを常駐させてみたけど、これってロンドンに設定したら夏時間が適用されるのね。ダメじゃん。つうか、世界時計なんだからUTCを設定することもできていいと思うのに。UTC用の時計を買ってこようかしらん。
おお、ウィキペディアの編集回数が400回を越えたぞ。ま、ほとんどが雑草取りなんだけどね。いつのまにかウィキペディアの英語版まで編集してるし。といっても、言語間リンクを張っただけなんで、大したことではないし、英語力は全く必要とされてないんだけど。
あーしまった。改名時に跡地を転送に設定することを提案し忘れてたので、即時削除依頼にまわってしまったよ。まあ仕方ないか。必要なら、そう思う人が改めて立てるでしょう。
即時削除されたのはノートページか。記事本体は転送として残ったのね。ていうか、ノートも移動したのに、残るのか。うーん、難しい。ドキュメントにそんなことまで書いてないよぉ。そんでもって、即時削除依頼は本来は私が出さなきゃいかんかったんだろうなぁ。次からは気をつけよう。
ウィキペディアにはウィキマネーという仮想通貨があるんだけど、これの残高管理とか送金処理とかも全部wikiになってる。ここまで徹底していると、いっそすがすがしい。そして、ありとあらゆるページにGFDLが適用される。通常の記事ページはもちろん、議論のノートもそうだし、利用者ページまで。徹底してるよなぁ。
GFDLというのは、ウィキペディアで採用されている文書のライセンスの一つ。オープンソースで有名なGPLのドキュメント版で、内容もGPLに似通ってる。要旨としては「コピー可」「改変可」「再配布可。ただし、同様のライセンスで」というもの。再配布時は有料で行ってもいいので、極論すればウィキペディアの内容を印刷した百科事典を作って販売してもいい。ドイツ語版だかでは、実際にそういうことも行われているとか。
つまりは、ライセンスさえ守れば自由に使っていいのがGFDL。よく言われることだけど、学生さんがレポートに使っても、ライセンス上は問題ない。ただ、教授がそのレポートを受理するかどうかは別問題というだけで。
2011年5月12日
漢字で始まる項目を曖昧さ回避を索引に登録してこうと作業を始めたけど、漢字の場合は読み方が複数あるから、曖昧さ回避ページは索引に載せられない場合があることに、今更ながら気がつく。普通の記事だと複数の読みのある漢字でも、その記事においては一意に読みは決まっている。しかし、曖昧さ回避のページの場合は、複数の記事をまとめて掲載しているから、それぞれの読み方が混在することになる。
例えば「八幡」という曖昧さ回避ページだと「やはた」「はちまん」「やわた」「はつま」なんて読み方がある。その場合、どの読み方で索引に登録したらいいんだろうか。今はたまたま統一した読み方の記事だけの場合だって、将来別の読み方の記事が追加されるかもしれんし。ということでやめ。
著作権侵害を見つけたので、削除タグを貼って依頼に出す。削除はしないという自己方針に反するけど、この場合は法律違反だし、侵害部分を削除すれば版指定削除で、記事自体は残せるから、まあいいかなと。
ちなみに依頼に出したのは「あまゆーず」というフォークデュオと、「赤いサイロ」という北海道のお菓子の記事。特定版削除だから、大きな影響はないと思うんだけど。と思ったら、特筆性なし、広告ということで削除の意見がついてしまった。がーん。まだ決定じゃないけど。
2011年5月13日
Wikify、孤立のチェックが一通り終わったので、次は作成されていない学校記事を作成する作業に移ろうと思う。大学、高校くらいまではほとんど全部記事が作られているけど、小中学校になると、まだ手が付いてないものが多いみたいだし。ということで試しに一つ作ってみる。
何気なく削除依頼のログを見ていたら、私が以前に削除依頼を取り下げたときに勝手に削除タグをはがしてしまったことを注意されてた。おお、そりゃそうだ。勝手にはがしちゃいかん。まだまだ、手順に慣れてないね。
そうそう。書き忘れてたけど、私が初めて削除依頼を出したのは昨日の2件ではないんだよね。それ以前に、「JHEP」「JHEP (曖昧さ回避)」という同じ内容の記事を見つけたので、要らないと思われる「JHEP (曖昧さ回避)」の方を削除依頼に出したの。そしたら、この2件って履歴を追ってみると、「JHEP (曖昧さ回避)」が先に作成されて、同じ内容で「JHEP」が作られているのね。こういうのをコピペ作成というんだけど、それはいけないらしい。だから、面倒だけど「JHEP」を削除して(コピペ作成なんで削除依頼ではなく即時削除が可能)、「JHEP (曖昧さ回避)」を「JHEP」に改名するのが正しい手順らしい。そのことを指摘されたんで、「JHEP (曖昧さ回避)」の削除依頼は取り下げたんだけど、そのときに勝手に削除依頼タグも剥がしてしまったのよね。それを注意されたと。
コピー自由なGFDLな文書をコピペするのがいけないというのはよくわからないところではあるんだけど、「即時削除の方針:全般6」にそう書いてある。コピペ後、有意な加筆があれば問題ないそうだけど。想像するに、コピペされただけの記事を許すと記事の乱造に繋がるし、コピペするだけで加筆することがないんだったら、記事が統合できるはずということではないかなぁ。
小中学校の記事を片っ端から作ろうかと思ったけど、よく考えると単なる小中学校では特筆性に欠ける可能性があるよな。ということで、議論してそうなところを探してみたら、やっぱりそういう議論は「プロジェクト:学校」にあって、まだ合意は出来てないみたい。今回作ったのは中高一環校という点が特筆性とみなしてもらえたのかな。
ウィキペディアでは削除依頼は基本的にしないでおこうと思ってたけど、やっぱりそうではないのかなぁとも思い返してみたり。私が絶対に間違ってるとは思わないけど、それでも、ぽっと考えただけの思考よりも、多数の人が10年掛けて積み上げてきた思想なら、後者の方が大抵は正しそうだ。
ウィキペディアの求める特筆性に欠ける記事は、見つけ次第削除依頼に出すことで、ウィキペディアの品質に貢献できるというのは、間違ってはいない。うん。ともあれ、私がウィキペディアの編集を始めて、まだ1ヶ月も経ってないんだ。自分のスタンスをそんなに固定して考えないで、ゆらゆら揺れながらしばらく過ごしていってもいいんじゃないだろうか。
でも、一方で関連する文書を読み進めるに従って、こんなにがんじがらめだったら怖くて記事を起こすどころか、1文字だって書けないんじゃないかって気にもなる。まあ、実際のところの運用は、かなり曖昧になってしまっている部分もあるようだけど。
曖昧さ回避の記事で読み方が複数あるものは索引に登録できない問題を「プロジェクト:孤立文書」で質問したら、全部の読み方で登録していいという回答が。おお、そんな大技でいいのか。でもそれも正しいよな。凝り固まって考えていた自分が浅はかだった。これでまた、索引登録作業にまい進できる。
単なる小中学校には特筆性が無いというけど、よく考えるとウィキペディア日本語版には(多分)全ての鉄道駅が収録されてる。これだって主要駅を除けば、駅自体に特筆性はないよな。田舎の無人駅に何の特筆性があるだろうか。しかし、それが許容されているということは、それだけ情報量が充実しているということなのかな。校名、所在地、開校日くらいしか載ってないスタブ(短くて内容に乏しい記事)が歓迎されないということで、学校統計とか使って情報を充実させれば、許されるということなのかな。
ウィキペディアでメンテ的な修正作業をしていると、自分が今まで全然触れたこともなかったような記事が出てきて、それは新鮮で面白い。あと、記事に手を入れると、対象に愛着もわいてきたり。「あまゆーず」なんて全く知らなかったけど、CD買ってみようかという気になるし。(でも記事消されそうだけど)
2011年5月14日
改名提案で1週間反対がなかったものがあったので改名実施。今度は残骸のノートページの即時削除も出したぞ。
孤立ページ、カテゴリ無しページの一覧がまた更新されたので、これらのページのチェックをする。そうそう、いつからか忘れたけど、カテゴリの無いページの一覧というのを特別ページの中で見つけて、それも作業するようにしていたのよね。
カテゴリ無しページは、白紙化後加筆の荒らしが1件あったけど、記事として成り立つとも思えたので、白紙化前の記事と合わせることで対処。ちなみに孤立したページは1669件と更に100件近く減ってた。これで私が作業を開始してから 200件以上減ったことになる。こうして顕著に結果が出ると嬉しいなぁ。
「あまゆーず」の削除回避のために、頑張って情報を調べて加筆してみる。しかし、「特筆性(音楽)」を満たすのは、現時点では無理っぽいなぁ。
「特筆性(音楽)」ではメジャーレーベルでアルバム2枚以上とあるけど、あまゆーずは来月ファーストアルバム。主要ラジオ局で30分以上の番組を持っていることとあるけど、FM大阪で月1レギュラーはあるがメインパーソナリティではない。メインパーソナリティの番組も持ってるけど、コミュニティFM局。尼崎商工会議所の100周年きらきらPR大使なんてのもやってるけど、ローカルだよなぁ。うーん。
9日に代理で削除依頼出してたのは、無事に削除された。特に間違ってなかったみたい。なら、他のリストアップしてるのも、まとめて削除依頼かけるか。
そうか、ノートも全部wikiだから、更新されたページ一覧に出てくるのね。んで、フィルタかけたらノートページの更新だけわかると。なるほどなるほど。そういうことか。そうやって議論の新着発言をピックアップできるのか。もちろん、注目している議論の場合は、ウォッチリストに入れておくという手もあるんだけど。
ウィキペディアの即時削除の方針に「定義文なし」ってのがあるけど、ちょっとどうかと思う。本文も1行くらいしかなくて、本当に中身が無い記事ならともかく、ある程度文章があるのに定義付けの文が無いだけで機械的に即時削除にまわってるのを時々みかける。そういう、ウィキペディアの書き方を知らなかっただけというような記事は、定義文を書き足してやれば救済できると思うんだけどねぇ。実際、管理者さんもその辺は柔軟に対応しているようで、即時削除はあまりしてないみたいかな。
で、そういう削除対象になっている記事に、「BW350」というのがあった。全然知らなかったけど、YAHAMAのバイクらしい。バイクの記事が消されるのは悲しい。なんとか救済できないかな。でも記事自体がスタブ状態だから、削除されても仕方が無いかなぁ。
amazonであまゆーずのアルバムが予約できるならしようと思ったのに、まだだった。しく。
やっぱり特筆性がないからという理由で記事をざくざく消していくのは間違っているんじゃないかな。ガイドラインにもそう書いてある。特筆性がないのなら、特筆性を調べて探して書く。自分で書けないなら、呼びかけて他の人に書いてもらう。そういう努力をした上で、やっぱり特筆性が見つからなかったとなると、そのときはじめて削除になるという段取りだじゃないかな。だからといってスタブ未満の記事を乱造していいというわけではないが、既に出来てしまった記事に関しては寛容であるべきというスタンスなんではないだろうか。
執筆依頼が掛かっている項目に「台湾の温泉」なんてのがあった。参考として中国語の記事のリンク付きで。海星が今台湾で働いていて、休日ごとに台湾の温泉めぐりをしているというので、訳せないか相談してみた。もうすっかり中国語マスターになったと期待して。そしたら「そんな簡単にいくかー」という返事。そりゃそうか。残念。しかし、普段の仕事は中国語でも日本語でもなく英語でやっているらしい。英語で仕事できてるだけで、凄い立派だよ！！
デフォルトソートと索引で並びのルールが違うということに気がつく。なんでそうなった。ちょっとびっくり。ちなみにデフォルトソートというのは、その記事がカテゴリ分類されたときの並び順をきめるための読み方の設定のこと。カテゴリごとに読み方を設定することも出来るんだけど、デフォルトソートだと1箇所で全部のカテゴリに対して設定できるので便利と。だから、正しくはカテゴリのソートキーのルールなんだけど。
で、そのルールなんだけど、ソートキーでは濁音、半濁音は清音に、吃音は直音に、長音は母音に置き換えることになっている。「ウィキペディア」だったら「ういきへていあ」となる。一方索引では、濁音・半濁音を清音、吃音を直音は同じだけど、長音は無視ということになっている。これだと、デフォルトソートを元に索引を自動生成なんて無理じゃないかな。どうだろ。なんとかなるかな。
なんでこうなったかというと、多分歴史的経緯というか、それぞれ別個に発達してきたものだろうから、元になったルールが違うんだろうなぁ。でも、なんか惜しいなぁ。どっちかに統一できればいいと思うのに。
2011年5月15日
夜、孤立した曖昧さ回避を索引に登録する作業をしてたら、既に登録済みのものがいくつかあった。履歴を見ると同じ人。どうやら、私と同じ作業をしている人っぽい。そうかあ、そうやって作業がかぶることもあるかぁ。そりゃそうだよなぁ。
最近、勉強も兼ねてスラドのウィキペディア関係の過去のストーリーを拾い読みしてるんだけど『Wikipediaの将来は「包摂」or「削除」にしかないのだろうか？』とか興味深いな。私は現状では「包摂」側だけど、ウィキペディアンの中でも意見は割れてるのかなぁ。
「包摂」というのは、出来るだけ多くの事象を網羅すべきというスタンス。一方、「削除」というのは厳選した記事のみを掲載することで品質を保つべきというスタンス。まあ、当然相容れない立場ではあるんだけど、綺麗に二分できるというわけでもないだろうね。中間とか、やや片方よりとか、色んな考え方があるんじゃないかな。
ウィキペディアには一次資料をあてにしないというルールがある。例えば、人物記事の場合、一次資料としては本人(存命の場合)だけど、本人の言うことはあてにならないことになっている。なぜなら「自称○○」が簡単に出来てしまうから。だから、一次資料ではなく、ある程度信頼できる二次資料を基にすることになっている。
でも、例えば書物について書く場合、その書物に何が書かれているかという点においては、一次資料を用いてもいいように思うんだけどどうなんだろう。例えば「ドラえもん」に関する記事を書くとき、ドラえもん自体を参考にするのではなく、秘密本みたいなのを参考にしなきゃいけないんだろうか。
とか思ったんだけど、実際にはそうではない。一次資料でも参考にしていい場合がある。それは、一次資料が信頼できる場合。言い換えれば、ウソをつくメリットが無いとみなせる場合。例えば首相官邸のサイト上にある発表資料とかは、一次資料だったとしても信頼できると考えられる。ウソをついてたら、大変なことになるからね。また、書物の場合は、その書物に何が書かれているかという点については、その書物を参考にして構わない。ただし、その書物が百科事典の記事になりうる特筆性を持っているかどうかは、その書物はあてにならない。例えば、ドラえもんがコミックスの累計売上歴代一位だから特筆性があるとする場合、発行元である小学館がそう発表してても、それはウソをつくメリットがあるから信頼できないことになる。同じ内容を出版社協会みたいな組織が発表すれば、それは信頼できる二次資料ということになる。ということで、いいかな。
勉強のためも兼ねて、自分が関わってない削除依頼の議論も多少読んでるんだけど、結構ガイドライン以外の過去の議論を理由に持ち出されることが多いような気がする。法律主義ではなく判例主義というか。これって、どっかにまとめておいてもらわないと、新人は議論に参加できないような気が。
2011年5月16日
孤立した曖昧さ回避の索引登録作業の続き。複数の読みをそれぞれに登録するので、手間がかかる。なかなかはかどらん。正直、飽きてきたって気もするけど、全部終わるまで頑張るつもり。
削除依頼に出ている記事で、ちょっとしのびないかなぁと思うものに、加筆依頼に切り替えてはどうかとコメントをつける。二つほど。一つは翻訳依頼なんだけど、勢いでなんなら自分がしますと書いてしまったり。ほんとにそんなことできるのか＞自分。
夜、引き続き孤立した曖昧さ回避の索引登録作業。残りの1000件近くを全部チェック完了。ぜいぜい。疲れた。でも、これでもう次からは楽になるはず。明日には孤立ページの再検索が行われるだろうから、どれくらい減ったかも楽しみ。
2011年5月17日
孤立したページの一覧が更新された。1433件。前回より200件以上減ってる。私が作業開始した頃からだと400件以上。これはちょっと誇っていいんじゃないだろうか。
ということで、新たに追加された孤立ページを処理していく。あと、カテゴリのないページの処理も。孤立した記事をチェックしていたときに見つけていた、削除したり統合したりした方がよさそうな記事をそれぞれ依頼にかけていく。
勢いで「井上きみどり」さんの記事を立項。
ウィキペディアのメンテナンス的作業をしていると、プログラムで処理したら楽になるだろうなぁということをいくつも思いつく。しかし、プログラムを組んでウィキペディアのサイトにアクセスすると迷惑だよな。と思って調べたら、ちゃんとそういう用途のためにデータベースダンプのダウンロードが用意されているのね。素晴らしい。
試しにスタブデータのアーカイブをダウンロードしてみたけど、これって1ファイルのXMLなのね。むむ。全データを一度に読み込むとメモリを食うな。やり方を何か考えないと。RDBMSに突っ込んで、SQLで処理するというのがまっとうかなぁ。いくらテキストデータとはいえ、シェルスクリプトでさくっとというわけにはいきそうにないな。ちなみに、スタブだけで600MB、2000万行もあった。ふはー。
2011年5月18日
図書館に行って、資料を探す。それらしい資料はあるけど、他の図書館の蔵書なので、取り寄せを依頼。
削除依頼に掛かっている記事。アメリカでは話題になった事件だから英語版にはあってもいいけど、日本ではたいして話題にならなかったから日本語版には不要ってのは、JPOVだよなぁ。まあ、現実に現在の日本語版ウィキペディアがJPOVなのはそうだけど、理念としては違うはずだよね。
注釈しておくと、JPOVというのは日本中心の視点とか観点という意味。ウィキペディアは理念としては言語や民族や国家の枠に捕われないことになっている。だから、理想的には全ての言語版に同じだけの記事があって、内容も同じであることが望ましい。それはまあ現実的には難しくても、少なくとも記事を書くときには言語や民族や国家には捕われない書き方をすることが推奨されている。例えば「わが国では」なんて書き方は「日本では」というように書くべきとかね。そういう文章上の観点もあるし、記事を採用する観点でもある。そこでJPOV(日本中心の視点)を持ち込むのはいけないというのが、ウィキペディアの本来の理念というわけです。
他言語版のウィキペディアでも、個人設定に言語設定がある。試しに日本語にしてみたら、メニューだけ日本語になった。おお、これは便利！いや、英語版くらいなら別に不便はないけど、それ以外の言語の場合はわけわからんから。って、英語版以外は見ることもまずないんだけどね。言語間リンクを貼りに行くくらいはするかもしれんけど。あれ？でも言語間リンクってロボットが勝手にやってくれるようになってるのかしらん。日本語版ではロボットが走ってるみたいだけど、多言語版でもそうなのかなぁ。
なんとなく「Adobe Flash Media Server」の項目を見にいくと、やっぱり赤リンク(つまり記事が作られてない)。それだけならまだしも、「FMS」の曖昧さ回避にも掲載されてないので、とりあえずそこは追加しておく。
「Adobe Flash Media Server」の記事は自分で起こせるくらいの知識はなくはないけど、いちいち調べるのが面倒。英語版の記事がそれほどボリュームがないから、こっから翻訳しようかと始めたけど、やっぱり大変。英語力無いのに無謀な挑戦か。それでも、知識のある事柄だから、だいぶ訳すのも楽なんだけどね。こういうところから手をつけていると、英語力のアップにもなっていいのかもしれん。
関連して「Flash Player」の記事を見にいったら、単独の記事になってなくて「Adobe Flash」へのリダイレクトなのね。その中で、バージョン履歴だけの項目として取り扱われていた。あらら。
それで思ったけど、新聞紙系などの一般ニュースサイトは古い記事は消されるので、あとから検証するのが難しい。紙の新聞の縮小版とかマイクロフィルムとかで探さないといけない。一方、コンピュータ系のニュースサイトは大抵バックナンバーも全部残すから、これらは検証可能なのでは。さっきの「Flash Player」のバージョン履歴も公開日とバージョンだけで出典がついてないけど、これはコンピュータ系ニュースサイトを出典として付ける事が今からでも出来るんじゃないだろうか。というようなことを考えると、またToDo が増えてしまう。いくらでもやることはあるなぁ。
「Adobe Flash Media Server」の翻訳。翻訳作業って、思った以上に消耗するな。知識がある程度ある事柄なのにこれだ。英文を読むのって、わからないところは飛ばしても、大体の意味はつかめたりするんだけど、翻訳となると飛ばすわけにいかんからなぁ。それでも、オンライン辞書とオンライン翻訳があるおかげでだいぶ楽よな。紙の辞書をひく手間を考えると。
オンライン翻訳はライセンスの問題があるのでウィキペディアの翻訳作業には使ってはいけないんだけど、そもそもそのままで使えるレベルの品質になってないんで使えない。それでも、構文とかをつかむヒントになるので使うけど。それでもないより全然ましだよな。
改名と統合から一週間経過したものを依頼一覧から除去。と思ったら、既に削除されてた。おや？と思ったら、こういうのを除去してまわってくださってる人がいるのね。ありがたい。
翻訳が完了したので立項。翻訳の場合、履歴継承の作法があるのでガイドラインを読み直して、ようやくサブミット。はあ、疲れた。でも、やってよかったかな。
雑誌のFLASHの「写写丸」というキャラクターの記事が削除依頼にかかって揉めてる。なんでも雑誌の企画と連動しているとかで、目的外利用かつ宣伝活動ということらしい。
気になったんでコンビニでFLASHを立ち読みしてきたら、ウィキペディアを紹介する記事のなかで、ウィキペディアの記事の作り方を説明する項目として実際に作ってみたということらしい。感心はしないが、雑誌の記事自体はまあ両論併記で中立的だし、作られた記事自体もそんなに宣伝的な記事ではないように感じるんだけど。
帰宅してから関連したページを読み進めていくと、取材に応じた管理者がコメント依頼かけられてたりと、ちょっとしたお祭り状態。あらら。
ちなみにコメント依頼というのは、その名の通り広くコメントを求めることなんだけど、対象がウィキペディアンであることもある。この場合、言葉悪く言うと裁判所みたいなもので、場合によっては被依頼者が糾弾される場にもなりえる。当然、そうならない場合もあるわけだけどね。
削除を主張している人は雑誌の記事の一部として立項されたことを理由としているみたいだけど、それって削除理由にはなってないような気がする。作成された記事が宣伝でないか、特筆性があるかといった点で審議すべきと思うのだけど、怖くて議論には参加できないので、ここでこっそり吐き出してみたり。
2011年5月19日
「写写丸」の削除議論については、本誌に関係なく記事自体で判断すべきというコメントがついてた。やっぱりそうだよねぇ。
統合提案を出していた「エキチカ」「駅チカ」について、どっちに統合すべきか、更に改名すべきかを含むので議論期間を延長することにした。最初からそうすべきだった。
図書館から取り寄せ完了の電話。仕事早いな。せっかくなので、すぐに借りに行く。
絶版バイク図鑑はなかば予想したとおり有名どころのバイクしか載ってない。その時代の全てのバイクを網羅するのは無理か。本のテーマも、絶版バイクを入手して乗ろうってことだしな。しかし、となるとこれくらい有名なバイクなら既にウィキペディアに記事がありそうなので、あまり意味がないかも。まあ、念のために全部調べてみるけど。
日本の名族関東編は、こちらも思ったのとは少し違う。日本の氏族を数多く収録しているのかと思ったら、いくつかの有名な氏族について詳しく物語のように書いているというものだった。ただ、巻末に簡単にだけど細かな氏族に関する記述もあったので、これは役に立つ。
ということで、早速執筆依頼の掛かっている「難波田氏」を立項。しかし、短い文章を著作権違反にならないように書き直すのって結構大変だなぁ。翻訳よりは楽だけど。あと、歴史上の人名って意外とIMEの辞書に入ってないので変換が手間。でも、なんとか立項。スタブだけど。元の文章自体がそれほど量がないんだから仕方あるまい。
あと、この本を眺めていて、自分の母方の氏の出どこが確認できたというのがちょっと面白い。叔父が「うちの先祖は藤原家の出で」とか言ってたのを適当に聞き流してたんだけど、本当だったんだ。ごめんなさい、おじさん。でも、異説もあるようだけどね。
プログラムで問題のあるところを検出しようと、まずアーカイブをダウンロード。過去の履歴は必要ないので、最新版だけの記事だけでいいんで、pages-articles.xml.bz2をダウンロードしたらいいのかな。圧縮して1.3GBもあるよ。ダウンロードだけで一苦労。データ処理も時間かかりそうだなぁ。
ようやくダウンロード完了。bz2で圧縮されてるけど、解凍ツールが無かったので、そのインストールから。まあ、tarball取ってきて、make && make installしただけだけど。
んで解凍だけど、これも当然時間がかかる。出来たファイルは5.3GBもあるよ。うわーーー。ちなみにwcかけてみたら、これまたなかなか返ってこなくて、ようやく結果が出たら89,599,878行とな。これがコンピュータが生成したデータならともかく、XMLタグも含んでるけど基本的に人間が入力したテキストだから凄いよね。
データが手に入ったので、エラー検出を行うプログラムを作成。perlでさくっと、なんだけどperlを書くの久しぶりで随分忘れてて手間取ったり。でも、とりあえずデータを読み込むところまでは出来た。
本来なら、XMLクラスを使ってやるべきなんだけど、なんせデータがでかい。こんなもんを全部オンメモリで処理したら重くって仕方がないと予想。それに、処理すべきデータは汎用なものではなくてウィキペディアが出力するものに固定なんだから、細かいことは抜きにしてもOK。ということで、テキストマッチと正規表現でアバウトにXML解釈。まあ、こんなもんでしょ。
出来上がったんで、試しにフルデータを読ませてみる。と、意外と軽い。おや？何時間も掛かるかなぁと思ったら、10分程度で完了した。マシンの性能のおかげもあるかな。perlのパフォーマンスがいいというのもあるだろうね。
読み込みが出来たら、エラーチェックも仕掛けてみたくなるもの。試しにデフォルトソートが設定されていないものを検出してみたら、山のように出てきた。うわぁ。多分、デフォルトソートが最近に追加された機能で、古くからある記事には使用されてないんだろうなぁ。試しにガイドラインを眺めてみたら「デフォルトソートを追加するだけの編集は謹んで下さい」とちゃんと書いてある。
ちなみに、なんでデフォルトソートを追加するだけの編集が歓迎されないかというと、デフォルトソートは必須項目というわけではないから。カテゴリのソートキーだけど、各カテゴリ呼び出しにちゃんとソートキーが設定されていればデフォルトソートは不要。ソートキーが設定されてなくても記事名でソートされるだけのこと。
何か他の編集をするついでにデフォルトソートを追加するならともかく、デフォルトソートを追加するだけの編集をすると、簡単に編集回数が稼げるうえに、履歴データが重くなってしまうし、履歴の見通しが悪くなるというデメリットがある。だから、推奨されないというわけ。
あと、編集回数が稼げるというのは、編集回数が色々な投票資格に関係してくるから、簡単に稼ぐ行為は推奨されないということ。本来は執筆した回数が多い=積極的に活動しているウィキペディアンという意味なのに、取り立てのアカウントで簡単な編集をしただけで投票資格を得るというのは好ましくないというわけね。まあ、投票資格にはアカウントを取ってからの期間というのもあるけど、これも寝かしアカウントという方法があるから万全ではないし。
いろいろヘルプを見て回っているうちに、曖昧さ回避ページにリンクしている記事一覧なんてのを見つけてしまった。現時点で対象件数5000件。うわー。これはやりがいがある。でも、その編集だけをするのもなんだしなぁ。とりあえずメモっておくことにして、どうするかはまた考えよう。
エラーチェックプログラムで正規表現と改行コードではまる。なんで思い通りにマッチしないんだよぉと、ぐぐってネットをさ迷いながら、なんとか修正。ぜいぜい。そんなことをしてたら、明け方になってしまった。いかんいかん。規則正しい生活をしなければ。
2011年5月20日
エラーチェックプログラムの続き。エラーというか、問題があるかもしてないところを探すだけだからlintの方が適切だと思うので、以後そう呼ぶことにする。
色々チェック項目を追加していくと、途端に処理が重くなる。当然だけど。ほんとは小さなテストデータを使ってテストを繰り返していくべきなんだけど、めんどくさいので本番のでかいデータを使う。だめだめ。
しかし、本番データからチェックに引っかかった記事をテストデータにコピペするとチェックにひっかからなくなったりと謎な現象が起こるので、仕方のない部分もあり。何が原因なんだろう。
没年と存命人物の両方のカテゴリに登録されているチェックを入れたら、1件ひっかかったよ。まさかそんな記事があるとは自分でも思ってなかったのに。
ちなみに該当したのは「糸井しだれ」という記事で、二人の人物を同時に扱っている記事だから、没年と存命の両方が記載されていたのだった。これは仕方ないか。
しかし、こんなの人間の目でチェックしようなんて思っても絶対に無理だよな。やっぱりこんなことはプログラムにやらせるべきだ。うん。やろうとしていることは間違いない。ただし、チェックが本当に正しいかどうかはわからないから、修正は機械的にするんじゃなくて、それぞれ個別に検討してするけどね。
しかし、その後もいくつか亡くなられているのに存命人物のカテゴリが入ったままのが検出されたので、それは修正する。死亡日は更新されてるのに死亡記事が書かれてないのがあったので、そこだけ英語版から翻訳してもってきたりとか。
ようやく全件処理完了。今の時点のプログラムで、レポートは100万行近くにものぼってる。ま、ほとんどがデフォルトソートが無いというものなんだけどね。デフォルトソートが無いだけのものは出力しないようにしようかしらん。そうでもしないと、レポートに目を通すこと自体が大変になってしまう。
テキストエディタは長年TeraPadを使ってきたんだけど、実はTeraPadはUNICODEに正式に対応してない。内部処理がSJISのままで、入出力時にUTF-8に変換できるというだけ。だから、SJISに無い文字を含んだテキストを編集しようとすると文字化けする。
普段の生活では困らないけど、ウィキペディアのテキストを取り扱おうと思うと無理がある。ということで、今更ながらテキストエディタの乗り換え。とりあえずサクラエディタを選択。しばらくこれで使ってみよう。
lintプログラム。チェック項目を増やすと、どんどん処理時間がかかるようになってきて、とても本番データを投入してられなくなってきたので、仕方なくテスト用データを作る。本来なら最初にこれをしなきゃいけないんだけどな。おかげでテストがはかどるはかどる。
しかし、どんどんプログラムが重くなるなぁ。どうしたもんかなぁ。まあ、最終的には数ヶ月に1回掛ければそれでいいような用途のプログラムなんで、少々時間が掛かっても問題ないんだけどね。
表記ガイドを参考に、更にチェックをどかどか追加していく。全てのガイド項目を網羅するのは大変なんでやらないけど、ある程度チェックできるというだけでも意義はあるだろう。
ある程度出来上がったので、本番データに対してチェックを掛けて就寝。開始が0時半頃。出来上がったレポートのタイムスタンプでどらくらい時間が掛かったかわかるな。
2011年5月21日
起きて、結果を見てみたらlintは無事に終わってた。タイムスタンプからして、だいたい3時間くらいで終了してたみたい。意外と速いな。これくらいなら、まだチェック内容を追加しても問題なさそう。昔、3DCGの仕事をしてて、重たいシーンデータを扱っていたときのことを思ったら、この程度の処理時間は全然たいしたことはない。
改名実施から一週間経ったので、改名提案一覧から除去しようとしたら、また既に除去されていた。うーん。
lintプログラムの続き。細かい調整を入れて更に検出項目を追加したり、誤検出を減らしたり。それでレポートを眺めてチェックしていくんだけど、我ながらこのプログラムって凄いな。こんな細かなチェック、人間がやれって言われても無理。って、出版社の校正係の人とかはしてるんだろうけど、コンピュータに出来る事は任せたほうが楽だと思う。
更に更にチェック項目を追加していく。どんどん重くなっていくよ。1パスでは処理しきれないので2パスに変更したし。全記事名の一覧が必要になったんで、ます1パス目で記事名を取得し、2パス目でチェックをするというようにした。それでも、なんとか思っていた機能はほぼ実装完了。おおー。おめでとう＞自分。ということで、本番データでチェック開始。開始時間は16時。さーて、何時間掛かるかな。もしくは何日掛かるかな、だけど。
と、走らせはじめて30分。カウンタが全然進まないんですけど！！これ、まじで何日のレベルかも。うーん、うーん、うーん。ちょっと考えて、一旦プログラムを止める。極端に遅くなっていると思われる処理を外して再実行。ちょっと、その状態での結果を見てみたいし。完全版については、高速化を検討した方がいいかもしれん。これだけ重いと、ほんの少しの処理変更でも顕著な差が出そうだ。
しかし、こうなると俄然面白くなってきたな。個人的には、プログラムの高速化は大好きだ。極端な話、機能実装するより、それが終わったあとのチューニングの方が好きだ。これほど大規模な案件は久しぶりだし、面白そう。わくわく。
あまゆーずのアルバムはライブでの手売り＆通販のみで、一般では売らないそうな。さすがにライブにまで行く気力はないから、通販で買うしかないね。忘れないようにしとかなきゃ。数量限定らしいし。あれ、でもそうするとメジャーレーベルでアルバム発売という「特筆性(音楽)」を満たすか微妙になってくるんじゃないか。インディーズレーベルだとダメらしいから。どこのレーベルから出るんだろう。
プログラムはperlで書いてるんだけど、使っているperlが実は結構古いバージョンなんで、バージョンアップするだけで多少速くなることは期待できるかもしれない。今使っているバージョンがActivePerl 5.8.9 Build 829。なんで今時5.8かというと、Namazuをインストールしようと目論見てたことがあったから。結局Namazuは諦めたので、5.8にこだわる必要もなくなった。
ということで、とりあえずActivePerl 5.12.3 Build 1204のパッケージをダウンロードしてきた。5.14も既に出てたけど、0ナンバーは流石に避けた方がいいかなぁ。perlはだいぶ安心してもいいと思うんだけど、昔5.8.0で凄く痛い目を見たことがあるんで疑心暗鬼。
で、perlのバージョン上げたけど、ほとんど速くならなかった。やっぱり、他人に頼るのはよくないな。自分で頑張らないと。いや、実際には多少速くなってるんだろうけれど、今回の場合は計測誤差の範囲だった、ということで。
おお、ウィキペディア日本語版がもうすぐ75万記事だ。
プログラムを眺めて高速化。速くなることもあるし、思ったより効果がでないこともあるし。色々試して、3倍くらいは速くなったかな。でも、まだまだだな。バグってるところを見つけて直したら遅くなった分もあるし。とりあえず今のバージョンで全件処理してどれくらいか、テスト実行を開始して寝る。
2011年5月22日
起床。プログラムはどうなったかなぁ、と思ったら途中で落ちてる。perlがエラーを吐くわけではなく、Windowsのレベルでプロセスが落ちてる。UNIXで言うところのコアダンプみたいな状態と思われる。ワトソン君が入ってたら起動するんだろうな。今は、マイクロソフトに症状を送信しますかというダイアログが出る。送ってもどうしようもないと思うけど、一応送信しておく。
ちなみに落ちたのはこれで2回目。うむむ。こんなん原因の追究のしようがあらへん。perlのバージョンを変えたことで発生したと思われるので、元の5.8系に戻して再度試してみる。が、やっぱり落ちる。特定のところで落ちるわけでもないし、メモリエラーとかかなぁ。ECCメモリ使ってるわけでもないし、これからの季節長時間処理は無理があるかな。
どうやってプログラムを速くしようか。問題の根本は二重ループになっているところがあるということなんだよな。O(n2)になっていて、しかも対象となるデータが5GB・9000万行と超巨大ということで、計算時間が爆発してしまっている。抜本的な解決方法としては、アルゴリズムを変更してO(n)とかになるといいんだけど、うまいアイデアはなかなかない。
とりあえず、一つ思いついたのは、配列データをループで処理しているところを、 map/grepで処理するように変更すること。perlで配列処理の常套手段ですな。すっかり忘れてたけど。これで多少速くなってくれるといいんだけど。
この際、プログラムが正確に動作しさえすればいいということで、ダーティな手法でも構わず取り入れていく。グローバル変数を多用してみたりとか。まあ、元々書きなぐりのプログラムなんで、そんなに綺麗でもなかったんだけど。この際保守性とかよりも、速く正確に処理できることが目標。
foreachのループをmapに書き換えてみたけど、処理速度変わらず。そんなうまい話は無いか。うむぅ。
それにしてもperlがよく落ちる。1時間くらい作業してると落ちるようになってくるんで、マシンを冷やすために1時間くらい落とす。その間、寝転がって天井見ながらプログラムを考える。1時間経ったら、また作業に戻る。なんか変なことになってるな。つうか、PCはけちっちゃダメだってことだな。ちゃんとしたのを買わないと。
私が翻訳に立候補してた「北京市アメリカ人殺害事件」は、結局削除になってしまった。「特筆性を示しての再立項を妨げません」ということだけど、事件自体そんなに特筆性が高いものではないからなぁ。どうしたもんだか。
lintで発見した、削除タグが貼り付けっぱなしの案件を存続希望として削除依頼に出す。削除タグは勝手にはがしちゃいかんからな。前に勝手にはがして怒られたし。依頼に出して議論して合意して、はじめてはがせる。面倒だけど、決まった手続きはちゃんとふまないとね。
正規表現をindex()に展開したら(もちろんループも展開してべた書き)、テストデータで5秒も縮まった。まじすか！これは面倒でもやる価値あり！perlの正規表現エンジンはかなり性能がいいという話だったけど、流石にindex()にはかなわんか。んー、でももしかして新しいバージョンではその辺の事情も変わっているのかな。しかし、index()に展開した方が遅くなるケースもあるなぁ。データに依存するか。うーん。
再びperlのバージョンを5.12.3に上げてみた。なんか、微妙に遅くなったような気が。。。なんでやねん。
正規表現のindex()展開については、どうやら数が少ない場合には有効という感じかな。なんでもかんでも展開すればいいというものではないらしい。([Ａ-Ｚａ-ｚ０-９]を62個のindex()に展開したが、かえって遅くなった)。逆に、正規表現を使うなら、出来るだけたくさん[]の中にぶち込んでやった方が速くなるみたいだな。それもそうか。
うお、use strictとuse warningsを外したら、それだけで更に5秒速くなった。開発時は必須としても、本番データを処理するときは外しておくべきだな、こりゃ。しかし、盲点だった。
perlIOを使って入出力時にencode/decodeをするようにしたら遅くなるかと思ったけど、意外と速度は変わらんかった。バイト列の方が処理が速いと思ったんだけど、最近は事情が違うのか。
プログラムを最適化するに従って、段々コードが短くなっていく。いや、それは多分正しいんだろうけれど、なんかさみしい。
一番処理が重い部分の高速化に手をつける。が、なすすべ無しというか。合わせて10行くらいしかないわけで、手のつけようがない。ほんの少し高速化はできたけど、本番データに対しては顕著な短時間化とはならないだろうなぁ。効果は無くはないだろうけれど。今日はもう遅いので、続きは明日にしよう。
と思ったんだけど、寝床の中で考えていたら色々アイデアが浮かんだので、起きだしてプログラム修正。絶対速くなるはず！と思ったのに、意外と効果は薄かった。なんでだろう。おまけに結果まで違ってくるし。うーん、原因追求は明日にしよう。
2011年5月23日
引き続きlintプログラム。PCも十分冷えただろうから、全件データで走らせて見る。が、また落ちる。どうにかならんもんか。
あまりにもperlが落ちるので、PCにホコリが詰まっているのかと思って明けてみたら、綺麗なもんだった。違ったか。
それにしても変なんだよな。落ちるのはperlだけで、その他のアプリは全く問題ない。熱暴走してるんだったらマシン全体がフリーズしたり、誤動作すると思われるのに。perlに、まだバグがあるのかなぁ、といかにも素人臭い疑いを持ってみたり。
nortonアンチウィルスを止めてみたら少しは速くなるかなと思いついたが、差は出なかった。でかいファイルを入出力してるから、多少は影響しそうなもんなのに。
memtest86を走らせてメモリチェックをしてみたが、エラーは出ないな。いや、出ても困るんだが。
マザーボードのBIOSを疑ってみる。調べてみると、SPDに関するパッチが出てるな。これか？試しに上げてみるかなぁ。しかし、Foxconnのサイトによれば、BIOSをアップデートするにはフロッピーで起動して、って書いてあるような気がするんだが。今時フロッピーなんて持ってないよ！CDにイメージ焼いてブートすればアップデートしてくれるとかじゃないの！？
更に調べてみたら、FOX Live Updateというユーティリティを使えばWindows上でもアップデートできるのね。なんか他のものまでアップデートしそうで怖いけど、これを試してみるか。その前に、マザーボード関連のドライバも更新されてるので、そっちを先にする。
マザーボードのドライバを更新してみたけど、変わらずperlは落ちるな。まあ、あんまり関係ないか。次はいよいよBIOS更新だけど、流石に怖いのでその前にバックアップを取ってから。
バックアップを取っていよいよBIOSアップデート。無事に完了。当たり前だけど。んで、lintを動かすけど、やっぱり落ちる。うーん。うーん。うーん。どうしたらいいんだろう。
試しにUNIX上で動かしたらどうだろうと思いついたけど、自宅UNIXサーバは玄箱なんでCPUパワーが足りない。こんなんで本番データをかけたら、何日どころか1年掛かるかもしれん。そこで思いついたのが、VMware上にUNIX環境を作ってそこで動かす方法。ま、当たり前の方法と言えばそれまでだけど。
ということで、VMware上にFreeBSDをインストールしてテストデータでlintを動かす。Windowsでの結果と一致。perlで書かれてるから当たり前といえば当たり前だけど、修正も無く動作してほっと一安心。
ということで、いよいよ本番データを投入。といっても、一番重い処理は外したバージョンでだけど。すると、さくっと終了。今までの苦労はなんだったんだと思うほど、あっさりと完走した。うーん、つまり重いデータのハンドリングにはWindowsにはまだ難があるということなんかなぁ。まあ、結果が出たので個人的にはそれでOKだけど。
ちなみに実行時間は1時間ちょっとだった。20日の完走できたときの処理時間が3時間くらいだったから、随分と短縮は出来ている。チェック内容も増えているのに。
それにしても、現時点でレポートが200MB、370万行もあるというのはどうしたものか。このレポートが完成したら、今度はそれをもとに ウィキペディアの修正作業に入るわけだけど、その作業が終わる見込みはあるんだろうか。レポートを公開して、みんなで手分けしてやろうよってしたほうがいいのかなぁ。
問題なく実行できるということで、フル機能バージョンを本番データに対してスタートしてみる。開始時刻は23時半頃。明日の朝になって何件まで進んでいたかで、大体の終了時間が予測できるものと想定。さーて、何日掛かることやら。それでも完走してくれれば、それでいいんだけど。
孤立したページ、カテゴリの無いページの一覧が更新されたので修正作業。新規に追加されたものだけをすればいいんだけど、それでも結構時間が掛かる。
編集回数がとうとう1000回を越えた。といっても、ほとんどが索引への掲載と雑草取りだから、全然偉くないんだけど。やっぱり、調べて記事を書くのが本流だよなぁ。
2011年5月24日
lintプログラム12時間経過で2000件まで進んだ。全部で147万件あるから、単純計算で367.5日掛かることに。。。随分高速化したと思ったけど、それでも1年かかるのかよ。こりゃやってられんということで、とりあえず停止。
これまで出来上がったレポートを眺めてみたけど、1文字2文字の記事のリンク候補の検出が多いな。実質的にはこれはノイズなんで除外した方がよさそう。レポートが無駄に長くなっても読みにくいだけだし、処理速度も多少は速くなるだろう。
遅い根本原因は、リンク候補を探すために全てのテキストに対して全ての記事名を単純文字列検索を掛けているということだ。今更ながら、なんかいい方法はないかとアルゴリズム辞典を引っ張り出してきて眺めてみる。
文字列検索を高速化する方法として、KMP法、BM法が挙げられている。ただ、これらの方法はいずれも事前に表を作るもの。例題は英文テキストのみを対象にしているけど、ウィキペディアの文章はUNICODEなんだから、表もどんだけでかくなることか。って、今時のパソコンにとっては大したことはないかな。
この期に及んで、更にチェック項目を追加したりとか。いや、レポートを眺めていたり、編集したりしていると、ついつい思いついてしまうもんで。
最近、また腰痛がでるようになってきた。原因は多分椅子に長時間座っていることだろうな。しかも、姿勢悪いし。
根本的にはアルゴリズムを変更すべきだけど、小手先の手法として正規表現を使う方法を思いついた。今は記事名分だけループをまわしてindex() で検索しているけど、件数が多い場合は、|で繋いだ正規表現で一気にマッチングした方が速いというのは以前発見した。
ということで、記事名全部を繋げた凶悪に巨大な正規表現パターンを作ってみた。つまり、/記事1|記事2|記事3|...|記事n/みたいなのね。こんなのほんとに処理できるんだろうか。perlの信頼性を信じよう。
ということでやってみたら、凄い！テストデータで10分掛かってたのが1分半に短縮された！凄いぞ正規表現。バカでも速いプログラムが組めるようになってるんだ。いやぁ、車輪を発明してくれた人には感謝感謝だわ。
だいぶ高速化できたので、現時点でどれくらいの速度か計るために、再び本番データで実行。開始は18時半。さて、どれだけ速くなったか。
が、全然進まん。あれ？なんでだ？かなり高速化されたと思ったのに。って、正規表現パターンのサイズが大きすぎ？いくらなんでも詰め込みすぎたか。もしかしたらCPUキャッシュからはみ出してしまって遅くなってるのかもしれんな。
試しに正規表現パターンのデータをダンプしてみたら14MBもあったよ。こらあかん。ということは、パターンを細切れに作ってループをまわすとかそういう処理が必要になるということか。ああ、めんどくさい。つうか、CPUキャッシュサイズを考慮したプログラミングをしなきゃいかんことになるとは思わんかった。
めんどくさいとも言ってられないので、正規表現パターンを分割する処理を組み込む。テストデータで実行すると、当然ながら遅くなる。まあ、仕方が無いわな。午前1時に本番データで実行開始して就寝。明日の朝にどこまで進んでいることか。
2011年5月25日
lintは、遅い。6時間で100件くらいしか進んでない。明らかに遅くなってる。うーん、テストデータでは顕著に効果が出たのになぁ。本番データで効果が出ないなら意味無いからコードを元に戻すか。ということで戻した。また1年バージョンだよ。ていうか、バグ修正で重たくなってるから1年以上だな。
なんとかしなきゃということで、今更ながら形態素解析を行う方法を検討する。形態素解析と言えばMeCabだろ、ということくらいは知ってる。 MeCab使ったことないけど。
ということでインストール。と思ったけど、Windows版はあるもののPerlモジュールは無いのね。 ActiveStateも配布してない。そうか、それでNamazuの人が独自に配布してるのか。しかし、Namazu版はPerl5.8なんでパス。とりあえずFreeBSD環境の方に構築して、そっちでテストをしてみてから。
しかし、形態素解析を使うと精度が落ちるんだよなぁ。まあ、現状の全マッチは誤検出のノイズもあるから、一概に悪くなるとも言えんのだけど。余力があれば、ウィキペディアのテキストに対応したユーザ辞書とか作って配布できたりするといいんだけど、まあそれは先の話として。
ということでcpanからMeCabをインストールしてみたけど、なぜかuse出来ない。は？仕方が無いのでportsから入れてみる。ちょっと苦労したけど、なんとかインストールできた。やっぱり、そのOSの作法にのっとった方法の方が安全なんかな。
ということでMeCabを使って形態素解析してみたんだけど、形態素解析だと分解されすぎてしまうなぁ。記事名って単語というよりも合成語の方が多そうだしな。あんまり役に立たんかもしれん。
とりあえず出来たんで速度計測。テストデータでは6分が5分に縮まった。一応速くなったけど、思ったよりは速くない。形態素解析自体も重いからな。しかし、予想ではデータが大きくなるほどMeCab版の方が有利になるので、それに期待して本番データを走らせてみる。15時10分開始。
3時間ほど走らせてみたところ、大体6000件ほど処理できてた。2000件/時間。ということは147万件だと、約30日。随分速くはなったけど、それでもまだ非現実的な時間。うむぅ。まだ頭をひねらないとダメか。
MeCabを標準でインストールしたので文字コードがEUC-JPになってる。UTF-8と変換するコストがあるから、最初からUTF-8を扱うようにコンパイルしなおそうと思って困った。configureのオプションで指定するんだけど、portsの場合どうするんだ？調べたら、 Makefile.localというファイルを作って、そこにCONFIGURE_ARGS+=xxxと書くのね。ううむ。知らんかった。
で、UTF-8で処理するようにしたつもりなんだが、なんかうまくいかない。まず速度がかえって遅くなった。あと、レポートの件数が減った。なんかまずったのか。わからん。とりあえず元に戻しておくか。
MeCabのドキュメントを眺めていると、MeCab自身は内部処理を全てUNICODEで行っているそうなんで、やっぱり文字コードをEUC-JPに変換しているのは無駄だと思うんだけど、さてどうしたらいいんだろう。
いくつか気がついた点を修正して少しは速くなったようなので、またしても本番データ投入実験。開始は22時20分。さーて、明日の朝にどこまで進んでいるか。
ところで、最初のフル機能版って、確か1件10分かかっていたから、147万件を処理するには、、、約28年掛かる予想になるかな。計算合ってるかな。それが夕方の時点で1ヶ月だから300倍速になったわけか。まあ、頑張ったことは頑張ったけど、最初に書いたコードが遅すぎって話もあるわなぁ。まあ、まずは動くこと優先で作っていくもんなんだけど。
1時間経過。約3000件。1.5倍速か。速くはなったけど、まだまだだなぁ。ただ、ちょっと解せないのは、CPUは100%占有しているようなのに、プロセスタイムが20分くらいしか進んでない。残りの40分はどこに行ったんだ？システムコールでそんなに使わないと思うんだが。でもメモリを確保・解放しまくってたら、それくらいいくか？これを全部処理にまわせるようになれば、3倍速くなるんだけど。
とりあえずrenice -20してみたけど、こういう対処で合ってるんだろうか。あーUNIXの知識が乏しいのが恨めしいぃ。あとVMwareにプロセスの優先順位の設定があったんで、とりあえず「高」にしておいた。でも、これにしてもniceにしても、他にプロセスがなければCPUを占有できるはずだよなぁ。
reniceして1時間経過したけど、やっぱり1/3くらいしか占有してない模様。わからんけど、しばらく立ち上げっぱなしだったから、試しにリブートしてみる。開始時刻は0時半。
2011年5月26日
lintは6時間経過で約4万件。ということは9日間で終了する見込みか。だいぶ現実的になってきたな。
そして、CPUを占有できない原因も分かった。VMware上の仮想マシンだからオーバーヘッドがあってフルスピードが出ないというものだった。考えてみれば当然か。実行開始から6時間経過時点でもCPU消費時間は100分ほど、そしてリブートしてからのuptimeが約2時間。つまり、 FreeBSD上では問題なくフルスピードで動いていたわけだ。
ということは、VMwareをやめてFreeBSDを直接インストールすれば3倍速で3日間で処理が終わるということになる。が、生活マシンだからそれは不便だなぁ。VMwareで少しでも高速化する方法がないかとぐぐってみたら、ドライブ類を全部切断するとかフルスクリーンモードにするとかあった。なるほど。使ってないときは、フルスクリーンにするようにしよう。ああ、Windows上で動けば何の問題もないのに。うらめしや。
更に高速化できないか少し試したけど、あまり効果は出ず。仕方が無い。現状のプログラムで本番実行しよう。ということで15時頃開始。今月中には、、、終わらないだろうなぁ。
重いのはMeCabによる形態素解析だよなぁ。ChaSenより遅いってことはないだろうけれど、より機能の単純なKaKaSiと比べたらどうなんだろうとぐぐっていたら、MeCabの使い方を間違っていることを知った。今やってるみたいに品詞情報も取得するんじゃなくて、単に分かち書きとしてだけ使うことも出来るのね。で、試しに書き換えてみたら3倍速くなった。何事！？なんちゅう速さや。ということで本番実行もやり直し。開始は16時。もしかしたら今月中に終わるかも。
約2時間経過。どこまで進んだかなと思ったら約8000件。あれ？遅くなってるよ。どう考えたって速くなるように変更したと思ったのに。またキャッシュミスとか、そういう関係かなぁ。
幸いに、VMwareをフルスクリーンモードにしていると、CPUをほぼ占有できるようで、CPU消費時間は2時間近くとなっていた。それは一ついい材料なんだけど、さーてねぇ。どうしたものか。
とりあえずコードを元に戻して再度開始してみる。開始時刻は18時半。これで2時間後にどこまで進んでいるかで判断しよう。
考えてみれば、記事の大きさにもばらつきがあるんだから、必ずしも同じ速度で処理が進んでいくわけでもないよな。ということは、比較も同じ条件でしないといかんということだ。これまで、そのときの思いつきというか、生活時間に合わせた条件で比較してたのがよくないのかもしれん。
MeCabのオプションを戻し忘れてたんで、またやり直し。20時開始。んー、でも遅い。昨晩の2時間4万件というのはなんだったんだ。と思って修正履歴を調べてみると、レポートを見やすくするために項目をソートする処理を追加してた。こんなん、無くていい。いや、あった方がいいけど、それで遅くなるんだったら無くていい。ということで、外してまたしても開始。20時半。
2時間経ったけど、やっぱり1万件ほどだなぁ。昨晩の2時間4万件は幻か？どのバージョンで実行したのかわからんようになってしまった。もしかして、何かの機能をオフにしていたものか、見間違いだったんだろうか。うーん、うーん、うーん。
孤立したページとカテゴリの無いページの一覧が更新されたのでメンテ作業。しかし、カテゴリの無いページというのは、大抵は荒らし編集の結果だったりするので編集合戦になっていたりする。そういうのは、巻き込まれてもしんどいので放置。本来なら、荒らしている人の会話ページで対話を試みたりするのがいいんだろうけれど、今の私にはそんな精神的耐性は無いので遠慮しておく。あと改名提案を1件出した。
2011年5月27日
今日でウィキペディアをはじめて1ヶ月。まだ1ヶ月しか経ってないのかと思うし、もう1ヶ月とも思う。編集回数は1000回を越えたけど、ほとんどが索引登録か雑草取りだから、全然威張れないよな。
lintは9時間経過で8万件くらい。やっぱ記事によって速度の違いはかなりありそうだね。これが平均だと6日くらいで終了できるかな。それよりも、現時点でレポートが150MBもあることの方が心配になってきた。このペースだと2GB超のレポートになる？エディタで開けるんかな、そんなん。心配になってきた。
サクラエディタってどれくらい大きなファイルを扱えるんだろうとサイトを見にいったら「内部コードはSJIS」なんて恐ろしい文言が。と思ったら、それは1系の話で、今使っている2系は内部コードがUNICODE化されているらしい。よかった。なんでそんな古い話が載ってるんだと思ったら、1系は普通にサイトがあったけど、2系では更新が楽になるようにwiki化したらしい。わかりにくいよぉ。
ウィキペディアが世界遺産への登録を目指しているということをスラドで知る。あれ？なんでウィキペディア上で話題になってないんだろう。コミュニティサイトでもニュースサイトでもないから、そういう話をする場所があまりないけど、雑談的な場所として井戸端があるんだから、誰かがそこに話を持ってきてもいいような気がするんだが。オンライン嘆願も募集しているそうなんだから、ウィキペディアの公式文書として告知しても構わないように思うんだけどな。
ウィキペディアのダウンロードページを見にいったら新しいダンプが公開されてる！今処理中のは5月7日版。新しい版は5月22日。どうせ時間掛けてチェックするなら、新しいのにすればよかった。と今更後悔。まあ、いいけどね。どうせリアルタイムに同期するのは無理だし、記事はどんどん更新されるから、最新のものというのは無理なことだから。
せっかくウィキペディアのデータを処理するプログラムを作ったので、lintを掛けるだけではなく、統計情報とか色々調べてみると面白いんじゃないかなと思う。ということで、過去のダンプデータもダウンロード。公開されているのは2010年2月26日のまでか。もっと古いのは無いのね。残念。
lintプログラムの修正。というか、今までのは書きなぐりだったんで、ちゃんと書き直し。クラスも使って、それなりにまともに。名前もlint専用ではなくて汎用的なデータ処理ツールということでwpjatoolに変更。あと、テストケースも書かなきゃなぁ、ってテストコードを最後に書いてるようではあかんな。テストラストやん。テストファーストじゃないと。
それにしてもプログラム書くのって楽しいなぁ。こうしてクラス作ってメソッド追加したりしてると、ほんと楽しい。なんでこんなに楽しいんだろうねぇ。
ふと思ったけど、CC-BYって表示義務だよね。コンテンツを使って派生製品を作ったら、派生元の表示が必要。じゃ、その派生製品を使って更に派生製品を作ったら、大元と派生1の両方を表示しなきゃならないの？これを繰り返してたら、BSDライセンスの宣伝条項みたいな問題になりはしないんだろうか。
CC-BYというのは、ウィキペディアが採用しているライセンスの一つであるCC-BY-SAのうちのCC-BYの部分のこと。CCはクリエイティブコモンズのことだからライセンスとしての意味はないとして、BYというのは表示義務のこと。何を表示するかというと、著作権者の表示を行うこと。つまり、ウィキペディアのテキストをコピーして自分の著作ですよと言い張ることは出来ないということですな。SAは継承。改変した作品を配布する場合は同じライセンスで行わなければならないというもの。
せっかく作業日記を書いているのを誰かに読んで欲しくて、Wordで整形して、海星と六波羅にメールで送ってみる。反応はあるだろうか。
2011年5月28日
lintさんは調子よく進行中。現時点で70万件ほど処理が終わってる。ということは、あと2日ほどで終了できるかな。
午前中、眠くて寝る。
ウィキペディアのデータって、一般に入手可能なフリーなテキスト群としては最大級なんではなかろうか。量としてはgoogleが持ってるデータとかの方が大きいだろうけど、一般には入手できない。自分でクローラ作って収集してもいいけど、権利関係の問題がある。
その点、ウィキペディアのデータは権利関係がクリアになってるから、どんな利用をしても大丈夫。そういう安心して使えるデータとしては、かなり規模が大きいものの一つだよね。例えば言語学とか社会学の研究データとして使うようなことが行われてもいいんじゃないだろうか。そこまでたいそうな話とまではいかないけど、自分としてはとりあえずMeCabのユーザ辞書を作るというようなことをやってみようかと思う。
そういえば利用自由なテキスト群としては青空文庫があるな。でも、あっちはそれなりの作家が書いたちゃんした文章だから、傾向が違うよね。ということで、ウィキペディアにも利用価値はあると思う。というか、こういうデータっていくらあっても困ることはないはず。
午後、wpjatoolの開発。MeCabでの解析結果とか見てると面白いな。「機動戦士ガンダム」を「機動」「戦士」と分解するまではいいが、「ガン」「ダム」はダメだろ(笑)。辞書に無いから当然だけど。というような辞書を作っていけるといいね。
そのMeCab解析のレポートも出力してみたんだけど、これも巨大で数百MBにも達してる。何気なくダブルクリックしてテキストエディタで開いてみようとしたことが悲劇を招く。ファイルがでかすぎてマシンが固まった。1時間くらい処理が終わるのを待っていたんだけど、最後には勝手にリブートしてしまった。がーん。 lintの処理も当然に途中終了。しくしく。まあ、そんなに極端に時間が掛からないことが分かったんで、やり直せばいいんだけどね。ついでに、少し高速化できるアイデアがあるから、やり直しのいい機会が出来たと思えば、それもそうだし。しかし、それにしてもなぁ。
ということで、lintを修正する。高速化にプラスして更にチェック項目を増やしたり。で、再度実行開始。20時半。
30分経過。。。既に1万件を突破してるんですけど。めちゃめちゃ速くなってるやん。これは、もしかしてやり直して正解？まあ、得てしてそういうものだけど。それにしても。最初からちゃんと速く作るべきということだよな。見切り発車したりせずに。
全記事名をMeCabに掛けるという機能をwpjatoolに追加。で、出来たレポートが450MB、1000万行という超巨大なもの。これ、誰が目を通すんだ？って、私しかいないけど。バイト雇おうかな(←どこにそんなカネがあるねん!)
出来上がったレポートをテキストエディタでいきなり開くという愚行はもう繰り返さない。splitで10万行ごとに100ファイルに分割した。これなら開けるもんねー。でも目を通すの大変だけど。
MeCabのIPA辞書を眺めていて思うんだけど、いわゆる半角文字が全然登録されてない。もしかしてMeCabではご法度なのか？と思って全検索掛けてみたら「Tシャツ」発見！大丈夫みたい。日本語の文章といいつつ、半角の英数字や記号は混じってくるから、その辺も辞書にあると便利だろうね。
検索しているときに「浮津一番f」なる謎の単語を発見。typoだろうなぁと思いつつ、浮津一番でぐぐってみたら、その誤登録の開発者への報告が一番上にやってくる。浮津一番(高知県室戸市の地名らしい)に住んでいる人にとっては酷な話やなぁ。
しかし、2006年に報告されて次のリリースで修正しますと言いつつ、未だに直ってないんですけど。って、こんなところで言ってもしょうがないけど。IPA辞書はgoogle IMEでも利用されているようで、そっちでの誤変換報告にもあがってしまっている模様。
それにしてもMeCabの出力結果を目で見て全部確認していくのはしんどいなぁと思ったら、--unk-featureなるオプションを付ける事で品詞推定を抑制して、指定した品詞(unknownとか)にすることが出来るらしい。おお、素晴らしい。これでチェックが楽になる。
ということでレポートの作り直し。しかし、これでも万全ではないんだよなぁ。未知の単語でも、組み合わせで辞書にマッチする場合があるから(「アンパサンド」が「アン」「パ」「サンド」に分解されてる)。結局、全部目でチェックしなきゃならんことには変わらんわけか。
しまった、lintをかけなおすんだったら、最新のデータに差し替えればよかった。うかつ！
MeCabの出力を見ながらユーザ辞書を作っていく作業に取り掛かるんだけど、凄い手間が掛かる。全然はかどらない。いちいち読み仮名も調べないといけないし。むーん、なんかやり方を考えないといかんなぁ。これでは全部登録が終わるのに、いつになるかわかんないよ。
2011年5月29日
朝ちょっと遅く起きる。
lintさんは、、、終わってる。そうだろうとは思ったけど。半日かからんかったな。当初の28年というのはなんだったんだ。自分の情けなさに涙が出そう。まあ、終わったからいいんだけど。
ちなみに、出来上がったレポートは1GB、2000万行にも及ぶ超大作。これを元にウィキペディアの修正作業をするのは……もしかしたらライフワークになるかもしれんな。
昨日の反省を込めて、1000行ずつsplitする。出来たファイルは2万。当然だわな。
午後いっぱい使って、lintの出力結果をもとに修正作業を行う。1000行のファイルをだいたい10個ほど処理できた。全部で2000万行だから、フルタイムで作業して1000日掛かるんか。やってられん。
作業していて気がついたけど、重複リンクの検出とか、リンク候補とかは、数が多すぎていちいち見てられない。ということで、レポートからこれらの記述を削除した簡易版レポートを作ってみる。うう、これらの検出処理を高速化するのに時間掛けたのになぁ。まあ、おかげでMeCabとか新しいことを覚えられたんで、いいんだけど。
孤立したページとカテゴリの無いページの一覧が更新されていたので、それぞれ対応作業をする。
「エキチカ」と「駅チカ」の統合提案がもうすぐ二週間の期限になるな。反対意見は出そうにないから、忘れずに統合作業をしないと。統合といえば「iPad 2」と「iPad」の統合は反対意見が出てもうすぐ1ヶ月になるので、こっちもタグ剥がしの作業を忘れずにしないと。
lint結果に基づく修正もする。しかし、果てしないな。レポートを削ったけど、それでもこの作業が完了すると思えない。なんか考えないといかんな。さて、どうしよう。
2011年5月30日
海星からこのテキストの感想がきてた。よかった反応があって。分かりにくいところがあるという指摘があったんで、その点は加筆しよう。反応を得られてよかったかな。
午前中、だらっとlintに基づく修正を少し。しかし終わらんな、この作業。なんつうか、警告件数の多いものだけに絞って修正作業をするようにしたほうがいいのかも。
午後、寝る。そりゃ寝不足だもんな。ぐー。
FreeBSDの環境を構築しなおす。ディスク容量が足りなくなってきたんで。ディスクを足すだけならVMwareで出来るんだけど、そうするとパーティションが別になって不便になるんで。今後も使い続けるだろうから、早めに一新しておいた方が利便性があがるだろうと判断。
INETNER Watchのバックナンバーを出典にして、「Adobe Contribute」と「Flash Player」のバージョン履歴を少し加筆。
海星から、プログラムの修正内容が具体的でないという指摘を受けたので、修正履歴を見ながら書いてみる。ほんとは修正したそれぞれの箇所に書けばいいんだけど、どこがどの修正なのかまで細かく覚えてないので、ここでまとめて。既に書いた内容とも被るけど。
まず分かりにくかったという指摘のあったデータのサイズ。元になるデータはノートと利用者ページを除いたpages-articlesというアーカイブの5月7日版なんだけど、ファイルサイズが5.3GB、行数が9000万行、記事数が150万というもの。これにlintをかけた処理時間が、初期バージョンで約28年(予測)。最終版が6時間くらい。lintをかけた最終結果のレポートが、ファイルサイズが1GB、行数が2000万行、対象記事数70万件。
高速化にあたって行ったのは、だいたい次の通り。
・実行時にはuse strict; use warnings;を外す。
・関数間で引き渡される変数は基本的にグローバル変数化。
・少量のパターンにマッチさせるときはindex()、大量のパターンにマッチさせるときは正規表現をそれぞれ使う。ただし、大量すぎるとCPUキャッシュからあふれるようでかえって遅くなる。ものには限度がある。
例）
少量の場合
if( index( $_, '文字列1' ) >= 0 || index( $_, '文字列2' ) >= 0 ) {
大量の場合
if( /文字列1|文字列2|文字列3|...|文字列n/ ) {
・ウィキペディアで意味を持つ特定の英文字列(Categoryとか)を検出する必要があるんだけど、大文字小文字の揺らぎが許容されている。事前にケースを統一しておくことで、検出の正規表現にiオプションをつけなくて済むようにする。
・リンク候補を発見するため、本文に対して全記事名(150万件ある)をマッチングしていた(本文も150万件あるので、150万2回のマッチング)のを、本文を形態素解析して単語に分解し、単語の記事名が存在するかという処理方法に変えた。
・リンク先が曖昧さ回避を検出するため、本文に対して全曖昧さ回避記事名(5万件くらい)をマッチングしていた(本文150万件なので150万×5万回マッチング)のを、本文からリンクを抽出して曖昧さ回避リストに存在するかという処理方法に変えた。
・形態素解析(MeCab)では、最初はparseToNode()で先頭ノードを取得しループを回してノードを個別に取り出して処理していたが、parse()で分かち書きした結果を一括して受け取るようにした。
2011年5月31日
朝それなりに早く起きる。さすがに早く寝れば早く起きれるか。でもちょっと眠いな。
「あまゆーず」は版指定削除で記事は生き残ったー。やったー。しかし、「赤いサイロ」は削除予告となってしまった。
lintのレポートはファイルサイズが1GB、2000万行、対象記事数70万件。とても一人でこなせる量ではない。とりあえず重要でない警告を外してみたところ、200MB、460万行、(記事数は変わらない)になったけど、やっぱり無理。更に、警告件数が10件以上のものに絞ったら、レポートサイズが8MB、13万行、4500記事まで減った。これくらいならなんとかこなせるかなぁ。それでも相当な期間が掛かりそうだけど。
うお、管理者に二人も立候補者が出てる。確かに、ここんところたて続けに管理者が辞めてたし、それでなくても管理者が少なくて大変という話はあるから、増えるのはいいことだろうなぁ。ただ、立候補者の一人は過去にも2回も立候補して2回とも不信任されているという人なんだけど。さて、どういう結果になることやら。
管理者が足りてないのなら、自分も立候補してみようかという気持ちは少しはないこともないけど、少なくとも今はやる気はないなぁ。管理者というプレッシャーに耐える自信がない。それに、管理者を助けるには、管理者にならなくても、一般のウィキペディアンとして出来ることもたくさんあるんじゃないかと思うし。
午前中、ぐーぐー寝る。よく寝た。
海星とメールでチャット状態。色々意見を貰う。なるほどねぇ。読者視点というのは大切だ。未だにそんなこともわかってない自分というのが情けないけど。
このテキストは、私としては、ウィキペディアンに読んでもらって、にやっとしてもらうことを目的に企画したんだけど、ウィキペディアンじゃない人に編集作業ってどんな感じかを知らせるという役目も果たせるということを気付かせてもらった。なるほど。そっちの方が有意義かもしれんな。そういう方向で加筆を頑張ろう。
午後、wpjatoolの開発。集計機能を作っていく。被リンク数のランキングとかはウィキペディア上にもあるんだけど、今は更新が止まっているから、公開するとそれなりにありがたがってくれる人がいるんじゃないかと想像。
一通り出来たので本番データで走らせてみる。が、なかなか終わらない。つーか、ディスクがりがり言ってるよ。メモリが足りてなくてスワップしてますな。ということでVMwareのメモリを512MBから768MBに増やしてやって再実行。でもやっぱり足りない。うーん、そんなにメモリをふんだんに使うようには組んでないつもりなんだけど。どっかで解放されてないメモリがたまっていってるのかな。
改名提案を出していた「Avalanche Press」という記事について、改名案の「アバランスプレス」は間違ってて、「アヴァランチプレス」か「アバランチプレス」が適切なのではという指摘が。言われてみればその通り。あれ？初稿起稿者のデフォルトソートの記述に沿ったつもりだったけど、見直してみたら、ちゃんと「あはらんちふれす」になってるよ。間違ってるの私だけ！恥ずかしい。だから語学力の無い奴はあかんねん。これから、外国語関係の改名提案はしばらく控えようかな。提案は修正したうえで、審議期間を本日から一週間に延長することにして対応。
wpjatoolでメモリを食う問題。今更ながらメモリ使用量を見積もってみる。現状、記事が150万件あるけど、そのタイトルデータを全てオンメモリで持つようにしている。1件あたり100バイトとして、150MBか。大きいけどスワップするほどではないな。ただ、これを1セットではなく複数セット持っているのが問題だな。うまく統合して持てるように変えれば大丈夫かな。
ということで、少々修正してみたところ、先ほどよりは進むようになったけど、やっぱりメモリを食ってスワップするようになる。うーむ。もしかして、と思って赤リンク(未作成記事へのリンク)の集計を外してみたら、何の問題もなく終了するようになった。topコマンドで確認する限り、メモリ使用量も200MBくらいと、大体見積もりどおりだし。ということは、赤リンクか。
考えてみれば、赤リンクの数は通常の記事数よりもはるかに多いかもしれんわけだな。そりゃメモリ食うか。原因は分かったけど、対処はどうしよう。現状、ハッシュでデータを持っているわけだけど、これを通常配列に変更する？でも、記事名と使用数を保持しないといかんから、やっぱりハッシュが最適だよなぁ。集計を2回に分けて、3パスにするか？それでも処理完了できるか、微妙だけど。
とりあえず赤リンクを外した集計結果を眺めていたんだけど、ファイルとテンプレートの呼び出し回数が実数と乖離が激しい。なんでかなーと調べたら、私の知らない呼び出し方が他にもあった。がーん。ヘルプをよく読まなあきまへんな。ということで修正。
それでも乖離が激しいなぁ。もしかして、と思って試してみたらやっぱり。ウィキペディア上では、ファイル名におけるスペースとアンダーバーは等価なんだ。「あ い」と「あ_い」はどっちからでもアクセスできるようになってる。
一方、私のプログラムでは同一視処理をしていないので別の記事ということになって呼び出し回数にカウントされなくなってしまっている。スペースかアンダーバーのどっちかに統一する処理を入れないといかんというわけだな。
うーん、今日はもう遅いし、明日にしよう。本番データでテストしてるから、処理が終わるまでに時間が掛かってしまって、なかなかテストがはかどらない。