スレッドのログ保管作業

コメントを残す

この記事も管理系の雑ネタです。

　スレッドのログを保管する作業はちょこっとだけ手間がかかります。良くある大規模な2chのログ保管サイトは恐らくサーバ上で定期的に2chのサーバをチェックしてdatを取得、サーバ上で変換＆公開というようなほぼ自動的な仕組みになっていると思います。そうじゃなければやってられませんもの。それに多少触発され、元々手抜きが大好きな自分はログ保管作業にそのような自動化が導入できないか検討した時期が有ります。

　結果から言うと完全自動化は無理と諦めました。その理由は以下の通りです。

  1. 板丸ごとの全dat取得の自動化は簡単だが、特定のスレッド群のみのdat取得は不確実さが伴う
  2. 当方のログ保管所ではスレッドをカテゴライズして公開しているが、これの自動化には不確実さが伴う
  3. 自動化を行うとスレッドの内容を検証せずに公開する事になる
  4. Namazu検索のINDEX作成に関する困難
  5. その他

　(1)は完全で無くてよいのであれば難しい事ではありません。予想される文字列を含むタイトルのスレだけ取得するようにすれば良いのです。Oblivion関係なら /oblivion/i1で済むでしょう。しかし漏れをなくすのは簡単では有りません。例えばアルファベットではなく『オブリビオン』というタイトルだったら見逃してしまいます。じゃそれも含めちゃえばって事になるでしょうが、きりがなくなります2。また、違う板にスレッドが建った時も見逃してしまいます。更に板URIが変更になった場合も対応する必要が有ります。その他にもあぼーん時の処理とかスレッドあぼーんとか完走せず落ちた場合とか色々例外処理が出てきます。手動登録にしてしまえば解決しなくもないですが、自動化する意味がなくなります。このように瑣末ではあるものの考慮しなくてはならない問題がわんさかあります。

　(2)のカテゴライズは(1)と似た問題です。スレッドのカテゴリ分けはスレッドのタイトルで行えるので完全でなくて良いなら或る程度自動化できます。例えばOblivionでは『SS/MOD晒しスレ』という文字列を含むものがModスレッドです。しかし『MOD』だけではだめです。他に『MOD作成支援/相談スレ』やら『エロMOD晒しスレ』というものも存在するからです。ただ、(1)と同じように大文字小文字全角半角ひらがなカタカナTYPO等を考えるときりがありません。(1)よりも間違う可能性は高いでしょう。
　この問題はカテゴライズを廃止すれば解決します。しかしこのカテゴライズ3こそが当方のログ保管所の個性4だと思いますので廃止するつもりはありません。よってこれも解決不能です。

　(3)は、例えばスレッドが荒らしや中傷で荒れたりスレッドの投稿に公序良俗に反するような内容がある場合は保管＆公開しないという方針を現在は採っております5。スレ保管自動化を行うとこのチェック過程が失われてしまいます。定期的にチェックを行えばよいのでしょうが、(1)でも述べたとおり、時々チェックをしなくてはならないというのは不満が残ります。

　(4)は単純に技術的な話です。現在、Namazu INDEX作成はローカルPC上で行っていますが、このサーバにはNamazuが入っているのでサーバ上でもINDEXを作成する事が出来ます6。ですがなぜかkakasiが入っていないのです7。自分で入れてしまう事も可能なので導入してはみたのですが、INDEX作成を試みると数ファイル走査した段階でNamazuが(恐らく強制的に)終了してしまいます。サーバ側で設定された呼び出すプロセス数の上限に引っかかったのだと推測、それを解決できるであろうText::Kakasiを導入しようとしたのですが、軽くやってみた範囲では導入できませんでした。まぁ、動くようになってもPukiWikiログファイル用のフィルタの導入8やら設定ファイルの作成やら課題が多過ぎる上にスレッドログのINDEXの作成しなおしは非現実的9なので結局深入りしないでやめました。多分どうでも良い所で躓いているのでしょうけどね。

　(5)は色々です。例えば、自動化したとしてもそう頻繁に2ch側サーバをチェックするような事はしないつもりですが、許容される頻度がどの辺りに存在するのか未知の段階ではそう冒険は出来ません10。多分分を弁えていれば大丈夫でしょうけど。

　完全を期しなければ自動はかなり達成できますし。しかし、上手く動いているかというチェックを時々行う必要があります。新しいシステムとチェックシステムの作成。これはそれなりに労力を消費します。いくら省力化が趣味といっても投入する労力以上のプラス効果を回収できる見込みがないのであれば意味がありません。

　というわけで現状の更新の流れを書いてみます。

  1. JaneViewにスレッドを登録しておき、スレッドの進行を追い、或る程度完走スレッドが溜まったら保管処理開始
  2. [手作業] JaneView上でスレッドを選択、『タイトルとURLをコピー』を行いテキストファイルにコピペしておく
  3. [Script処理] 上述テキストファイルを解析してJaneViewのログディレクトリから作業ディレクトリにdatをコピーする11
  4. [bat処理] dat2htmlでhtmlに変換。ついでにgzip圧縮まで行う12
  5. [手作業] スレッド情報を記述したCSVファイル13に保管スレッドの情報を追記14
  6. [Script処理] HTML変換したスレッドをローカルPC上でサーバ上の構造を反映15したディレクトリツリー構造に配置する16
  7. [bat処理] Namazu INDEX作成17
  8. [bat処理] HTML化したスレッドと作成したINDEX及びスレッド情報を記述したCSVファイルをtarでアーカイブ化18
  9. [手作業] 作成したアーカイブをscp経由でupload19
  10. [Script処理] サーバ上に設置したScriptを走らせ、カテゴリ毎のスレッド一覧ページ20とINDEX情報ページ21等22を自動作成23

　めんどくさそう？いやいやいや、手順自体は多く見えますがほとんどの処理をワンクリック24でできるようにしてありますので実際はかなり楽です。例えば、(2)なんて追加スレが10もあって御覧なさい、手動でやるとしたらエクスプローラでログディレクトリを行ったりきたりしてdatファイルコピペを10回もやらなくちゃならないんですよ。datファイル名だけじゃどのスレか分かりにくいですし。自分もこの省力化の工夫を構築25してなかったら多分今まで続いてないと思います。

　(1)～(2)はJaneViewを使わない方法26も考えましたが、dat落ち時等の例外処理が面倒なのでこのままにしています27。(3)～(4)はワンクリックで終了。(5)は上記の作業中では一番面倒ですが、このCSVファイルはこのログ保管システムの肝なので手は抜けません。記載する情報はスレッドのタイトルや総レス数の様にプログラムで自動的に決定できる項目もありますが、スレ番28やカテゴリ＆サブカテゴリ分け29、備考情報等は人の手で行う方が手っ取り早いです。(6)の作業はワンクリックで済みます30。(7)～(9)はワンクリックで大体済むのですが、処理待ち時間がかなり発生します。こればかりは改善は無理です。(10)もブラウザからScriptを叩くだけで終わります31。全てを通してみると、新規追加するスレの数にもよりますが(7)～(9)さえなければ10分もかからない作業です。もしScriptやbat利用による省力化を行っていなければ結構時間を浪費していただろうなと思います。

　WikiのNamazu INDEX作成も大体似た感じですがこちらはCSVファイル作成等が無いのでワンクリックでUP用アーカイブ作成まで完走するbatファイルで行っています。一応Wikiでも2chスレッドの様にアンカー毎に記事を検索できるように出来ないかと試行錯誤したことがあるのですが簡単には実現できそうに無いと判断、諦めたという過去があります。

　ここまで省力化に拘るのは自分は面倒くさがり屋であるせいもありますが、かったるいルーティンワークは管理継続の一番の障害だとも思うからです。解決が困難であってもそれを行う事で劇的な改善が期待できるような事柄ならば労力をつぎ込む事に躊躇はありませんし寧ろ闘志が湧いて来るものですが、時間をとられるだけの機械的単純作業は意欲というものをがりがりと削り取ってしまうものです。また、運用形態が複雑な場合、得てしてミスが発生するものです。そういう訳で不確実な成果しか得られない処理は排除しています32。そういう訳で『サボる為には全力を尽くす』『出来るだけ物事は単純化する』の方針を自分基準で実装した形となりました。まぁ、今は上手く回っているので特に問題はなさそうです。もう少し高速化できればなぁとは思いますが。

　余談ですが、ログ保管所ではgz圧縮済HTMLでログを公開しています33。で、NamazuはINDEX作成時にgz圧縮したファイルでも読込んでくれる優れものです。また、HTMLを<a name=’～’>毎に区切って解析(html-split)する事でスレログで言えばレス毎に検索できるようになる優れものです。ですがこの2つを併用することが出来ません。残念。そこでローカルではgz圧縮していないHTMLを解析させ、INDEXではgz圧縮したファイルを解析したように読み替えさせています。ローカルで未圧縮HTMLが容量を食ってしまうのですがこれはしょうがありません。同様に、PukiWikiのログを解析する際にPukiWikiログ用文書フィルタを使用するのですが、これもhtml-splitとの併用が出来ません。併用が出来れば大きなサイズのページ34等で有用なのですが残念な事です。この件に関しては一応回避方法を考えてはいるのですが、まだ手をつけては居ません35。

　ついでに。先日過去ログ保管庫の更新システムの改修を行ったわけですが、そこで新たに投入したScriptにバグが有って過去ログへのリンクが切れている状態になっていました。ご指摘を受けて気づき修正致しました。報告感謝申し上げます。また、ご迷惑をお返して済みませんでした。

  1. 正規表現 [↩]
  2. oblivion, ｏｂｌｉｖｉｏｎ, オブリヴィオン, オブリビオン, オブリ等々。半角全角や当て字、それらの混合やスレ立て者のtypo等 [↩]
  3. と検索システム [↩]
  4. カテゴライズすることで検索の絞込みを容易にする事がある程度可能 [↩]
  5. 少し前までは関連するなら全部保管公開、情報を取捨選択するのは閲覧者で、という方針でしたがそれでは宜しくない事例も有る事に或る方からの指摘で気づかされたので変更しました [↩]
  6. 初心者向け解説：Namazu検索は検索するたびに全データを走査するのではありません。事前に全データを走査し『～のファイルに＋＋って単語が有る』というような事をチェックしてそれをデータとして作成します。この作成したデータをINDEXと言います。利用者がフォームから検索をしたときはINDEXを見てその語がどこにあるか調べて出力します。なぜこうするのかというと検索毎に全データを走査するより遥かに短い時間で結果を得られるからです。この方法の欠点は、新しいファイルが追加された場合はそのINDEXの更新を行わなくてはいけない事と、INDEX作成に使う日本語解析プログラムの精度のせいでINDEXから漏れてしまう単語が出てくる可能性もある事です。スペースで単語を区切る英語等と異なり、日本語はそれが難しいのです。学校で品詞分解を習った記憶があるのでしたらそれを思い出してみましょう。人間が行う場合でも面倒なのにプログラムで行うのなんてもっと難しいのです [↩]
  7. MeCabはありますが [↩]
  8. デフォルトのNamazuには無いので自分で導入しなくてはならない [↩]
  9. Oblivionに限定しても約600スレ。でもってレス毎に検索できるようにしているので実際は600*1,000=60万ファイルをINDEX作成時に走査するのと同等。当方のメインPCでも3時間は必要。INDEXつくり直しではなく新規ファイルのデータだけを追加するだけなら現実的な時間で済むが [↩]
  10. 2ch運営側は自由にアクセス規制できる立場。しかもアクセスがISPではないレンタルサーバだったらアクセス禁止処理等は極めて選択しやすいだろうし、自分だったらそうする。また、有り得ないが某岡崎市立中央図書館みたいな事が発生したら… [↩]
  11. 手作業でdatをコピペしても難しくない作業だが、対象スレ数が多い場合は激しく面倒。よってワンクリックでコピーするScriptを自作 [↩]
  12. これもワンクリックで出来るようにbatファイル化済 [↩]
  13. スレッド名、dat名、カテゴリ、レス数、板のドメイン、板カテゴリ、スレ(の通し)番号、補足情報。このCSVファイルは後でも再利用する [↩]
  14. 実はこれが一番面倒だったが、上のdatコピー時に追記すべきデータの雛形を作成するように修正したので省力化成功 [↩]
  15. サイトを管理する上でサーバ上のツリー構造とローカルのツリー構造を一致させることは極めて有用。本件ではそれに加えてカテゴリ毎にINDEXを作成しているので分類しておいた方が楽 [↩]
  16. 配置には上で作成したスレッド情報を記述したCSVファイルを利用 [↩]
  17. そこそこ時間がかかる処理 [↩]
  18. 転送量削減とupload作業の省力化が目的。upしたアーカイブはサーバ上で展開して反映させる。この処理はそれなりに時間がかかる [↩]
  19. 結構時間がかかる処理 [↩]
  20. 例えばhttp://oblivion/logs/main/ [↩]
  21. 例えばhttp://oblivion/logs/indexinfo.html [↩]
  22. 同時に英語環境向けINDEX情報ページやRSSやGoogleSitemapも [↩]
  23. これらの作成も手作業でも難しくない作業だが、追加スレ数が増えると激しく面倒なので自動作成するメリットが高い。この時にスレッド情報を記述したCSVファイルを使用している。レス数やスレッドタイトルはHTML化済スレを解析するより別にデータ化しておいたほうが楽だし、スレッドの本来のURIはHTML化したスレッドから推測は困難 [↩]
  24. Script処理・bat処理とあるもの [↩]
  25. 最初期はやっぱり手動でしたがあまりにも面倒だったので色々試行錯誤＆改良してここまでになった [↩]
  26. ローカルでdat取得専用プログラムを走らせたりローカルなプロクシを介したり等 [↩]
  27. ただ、Janeはログを日本語を含むPathに保存する。よって使用する使用するScriptによっては多少面倒が出てくる [↩]
  28. 自動化も或る程度可能だが誤判定が避けられない。使用文字やTYPO等 [↩]
  29. これもプログラム処理では完全には上手く行かない [↩]
  30. (5)で作成したCSVファイルの情報を使ってこの再配置を行う [↩]
  31. これも(5)で作成したCSVファイルの情報を使用 [↩]
  32. 例えば自動的にスレッドをカテゴリ分けするような機能。処理後は必ずチェックをする必要が出てくるので案外省力化には繋がり難い。また、下手に処理成功率が完全に近い場合、チェックが疎かになり、結果的にミスを見逃しやすくなる [↩]
  33. もちろん転送量対策 [↩]
  34. 例えばFAQ [↩]
  35. INDEX作成前にWikiログをHTML化してそれを対象にNamazu INDEXを作成する方法。ただ、ページ名の長さ(WindowsではPathを含めたファイル名の長さの上限が結構小さい)が問題になる可能性があり、思案中 [↩]

コメントを残す

メールアドレスが公開されることはありません。