2009-09-01

夜も眠れなくなるほど恐ろしい画像 -subversion編-

技術

以下には特定の人にとって非常にショッキングな文面が存在します。
サーバ管理などという退廃的な仕事をされている方は気を強く持ってお読みください。
なお、一部文面は現場を再現した物のため正確性を欠いている恐れがあります。

そろそろsubversionのバージョンを1.6系列に更新しようと画策。
業務時間外に、現在進行形のプロジェクトのリポジトリのhotcopyを取り、dumpを試みる。

$ svnadmin dump /backup/repos/hoge > dumpfile
svnadmin:svndiff データの解凍に失敗しました

…、うん、いや、ほら、一回だけなら誤報かもしれないし。
本リポジトリを使って直接試行。

$ svnadmin dump /base/repos/hoge > dumpfile
svnadmin:svndiff データの解凍に失敗しました

試合終了。
頭の中で甲子園のサイレンが悲しく鳴り響く。

調査の結果、ずいぶん昔からリポジトリが破損していたらしい。
同時commitでロックが重なりでもしたのだろうか。
不幸中の幸いか、破損したファイルの殆どがtags以下の以降の更新が無いどん詰まりディレクトリ。
これらについては、最悪破損リビジョンを消去し、破損を取り除いたdump/loadの繰り返しでリポジトリを再構築することが可能。
問題は作業ブランチ側の根本で破損が発生していたことで、更新されていないファイルのため、その後も破損が発覚せず今日に至ってしてしまったらしい。
これらはsubversionの仕様上大本のリビジョンを抜く=ブランチ削除のため、うかつに消せない。
悪いことにそのファイルを触らない状態ならcommitはエラーを起こさず可能で、さらに該当ファイルの消去動作を伴うcopyを行ってもエラーにならないらしい。(同様の作業がリビジョンに存在していた)
しかもその作業ブランチは使用頻度の高いブランチだったりする。

選択A.
現状維持。リポジトリデータベースのバージョンは未来永劫更新しない。
選択B.
作業ブランチを手動で辿れるだけ辿り再構築。地獄の作業。

LIFEカードなみの究極の選択。

教訓:

svnadmin hotcopyでのバックアップは必ずsvnadmin verifyと併用する

hotcopyはリポジトリデータベースの検証を行わない上、リポジトリが破損していてもエラーを起こさず終了する。
これはdumpを使わないバックアップスクリプトなら同じかも。
hotcopyでバックアップを行うならverifyも併用すべし。

残トランザクションの消去は慎重に

コミット失敗でのデータ破損なら、トランザクションから作業を再現できる可能性がある。
普段機械的に削除しがちな残トランザクションだが、消すのはリポジトリにverifyを掛けた後からでも遅くはない。

動いている≠壊れていない

運用で問題が発生していない事が、そのままリポジトリの完全性を示すことにはならない。
常にリポジトリの破損を疑い、検証を欠かさない事。

subversionバックアップにはデータ検証の入るsvnsyncがいいのかなあ…
破損した現システムでsvnsync使うにはリポジトリの再構築が必要ですけどね！

2009-08-18

製作者の行動が作品の面白さを毀損することはある

揉め事

俺は吉本ばななの作品についてはエッセイを少し読んだ程度なんで、そこはさっ引いて下さい。
lakehill on Twitter: "ばなな居酒屋騒動で「吉本ばななは読者を失った」とか書いている奴がいたけど、小説の面白さと作家の人間性は関係ないわけだから、小説家の人格がクソだから、読むのをやめるという発想がわからない。ぶっちゃけ、作品が良ければ人間性なんてどうでもいいだろう？"
はてなブックマーク - lakehill on Twitter: "ばなな居酒屋騒動で「吉本ばななは読者を失った」とか書いている奴がいたけど、小説の面白さと作家の人間性は関係ないわけだから、小説家の人格がクソだから、読むのをやめるという発想がわからない。ぶっちゃけ、作品が良ければ人間性なんてどうでもいいだろう？"
ここらへんの発言を見て少しもにょったので。

作者の行動の浅さが露見する事が、ファンにとって作品の面白さを見失わせる可能性はあるんじゃないかと思う。

製作者と作品は確かに別なんですが、製作者の行動でファンが作品を楽しめなくなるパターンというのは多々存在します。
このパターンで、過去どれだけファンの怨嗟が世にあふれたことか。
推理小説家が犯人バラす、なんてのはさすがに安易な例ですが。

俺の体感した実例だと初代GPMと芝村裕吏。
初めてプレイした初代GPMは、(死ぬほどバグ満載だったとはいえ)本当に新しいゲームの方向性を感じるくらい「面白いゲーム」でした。
しかし、情報を集めるためネットの海を漂うと、現実の芝村氏はゲームプレイに片っ端から水を差す行動を延々と続けていて*1、俺の「楽しさ」はガンガン破壊されていきました。
今ではもうGPMを最初にやった時の「ワクワク感」は得られません。涙も枯れ果てた。
他にも、故栗本薫のファンとか、話を聞けば8時間位ぶっ続けで愚痴ってくれる人々は各地に存在するはず。

それぐらいで冷めるなんてたいした作品じゃない・たいしたファンじゃない、と言うのは簡単ですが、人間そう割り切れる物じゃありません。
製作者が聖人君子である必要はないですが、作品と製作者は別だから製作者の行動は作品の面白さに全く影響しない、というのも机上論じゃないかなと。
特にネットのおかげでこれだけ送り手と受け手の距離が縮まると、その手の事例も多くなりそう。

まあ作品を知りもしない人に無関係な方向で叩かれてファン激怒、というパターンも多々ありますけどね…

*1:説明するのは大変ですので詳細は省きます。みのうらさんの記事とか、「GPM 公式」で検索した結果等を参考に。

2009-08-17

desparaiso始めました

ゲーム

素敵壊れゲー作らせたら同人一と名高い紫雨飯店の新作。

内容的には超弱いワードナさんに全米が泣いたWiz4のオマージュとのこと。
世界樹シリーズのスキルポイント・スキルツリーに近いシステムも搭載している様子。

とりあえず1階のチュートリアルセッション開始。
シャーマニック(プリースト職)のメイドさんと迷宮歩き。
敵との先攻後攻決めから命中判定までサイコロが振られるのがナイス。
敵も接触時はちゃんと「？しょうたいふめい」だし宝箱ドロップ毎に開閉選択出るしで素敵すぎ。

ウォーリア＋シャーマニックの最序盤では罠判別も解除もできないので宝箱は片っ端から無条件オープン。たまに罠を食らって即死したりするけど私は元気です。
そんなこんなでアイテム集めていたらポロリと出てきた「？星形の物体」

最初の目的はニンジャを仲間にする事に決定しました！
本家であれ程でなかったアレがさっくりと。
ここのゲームの事だから鑑定したらガッカリとか装備してガッカリ的な流れもあり得ますが。鑑定料は今一番高い販売品の価格より2倍以上ふっかけられてるんで外れてないとは思いますけど。
まだ一階前半。はやくLV上げてえ…

2009-07-27

Trac 0.11.2.1-ja1 IDを名前に差し替えるパッチ

Trac

前にもネタにした通り、TracはデータベースにはIDと本名(とメールアドレス)の対応を保存しているが、ID表示を名前に切り替える機能は持たない。
タイムラインやチケット表示のとき、ユーザをIDで表示している事はクローズドなチームや開発畑だけでTracを使ってる場合はそれ程問題にならないが、あまり交流のなかったメンバーが加わるプロジェクトや、営業を含めるような場合だと結構な障害になったり。
(IDをフルネーム＋部署名で運用するという手もありますが)

そこで、IDを名前に差し替えるパッチを作成してみた。
trac/web/chrome.pyに以下のパッチを適用する。
2009/07/29 22:10 改訂
デバッグログ保存処理のせいで名前を入れてないと例外で落ちるバグが入っていました。修正。
上記より前に当てた方は修正をお願いします。

--- chrome.py.old	2008-11-27 03:59:32.000000000 +0900
+++ chrome.py	2009-07-27 12:00:00.000000000 +0900
@@ -323,6 +323,12 @@
         import genshi
         self.env.systeminfo.append(('Genshi',
                                     get_pkginfo(genshi).get('version')))
+        # Get Name of all known users
+        self.db = self.env.get_db_cnx()
+        self.name_map = {}
+        for username, name, email in self.env.get_known_users(self.db):
+            if name:
+                self.name_map[username] = name
 
     # IEnvironmentSetupParticipant methods
 
@@ -746,9 +753,15 @@
     
     def format_author(self, req, author):
         if self.show_email_addresses or not req or 'EMAIL_VIEW' in req.perm:
-            return author
+            if author in self.name_map:
+                return self.name_map[author]
+            else: 
+                return author
         else:
-            return obfuscate_email_address(author)
+            if author in self.name_map:
+                return self.name_map[author]
+            else: 
+                return obfuscate_email_address(author)
 
     # Template filters

これで、登録済みのユーザであればIDが本名に差し替えられます。
ちなみに、レポートやチケット登録時の担当者・関係者入力等では変換されません。
関係者の入力はCCSelectorPluginの改造で、担当者はrestrict_ownerフラグtrueでの表示の改造でなんとかなんないかなあと思ったりはしていますが。~~誰か作って~~

ちなみに俺のpython歴はせいぜい壺スレからエロ動画をリストアップしてIrvineに登録するスクリプトを作った程度のため、上のソースは自己責任でお願いします。おかしいところは突っ込み大歓迎。
クラスメンバとして辞書を持つってpythonWebアプリ的にアリなのかしら…

追記:
担当者の入力における改善にはこんなのがあった。
http://trac-hacks.org/wiki/FlexibleAssignToPlugin:Title
これでなんとか実用になりそう。素敵。

2009-07-27

Trac 0.11用 Tram RC

Trac

以前おすすめしていたTrac マルチプロジェクト対応用プラグインTraMの0.11対応をRyuzee氏が進めている。
多数のプロジェクトを同時進行させている現場には福音となるプラグインのため期待大。

テスター公募とのことなので、我こそはという方は是非。

2009-07-09

プロバイダ責任制限法の時にもさんざん言われてなかったっけ

揉め事法令

FLMASK事件のころからずーっと同じネタがループし続けてる感が。
はてなブックマーク - 海外の児童ポルノ・アドレス掲載、１９歳私大生ら摘発 : 社会 : YOMIURI ONLINE（読売新聞）
404 Blog Not Found:news - URLを掲示しただけで刑事犯?
はてなブックマーク - 404 Blog Not Found:news - URLを掲示しただけで刑事犯?
「掲示板に違法情報のURLを貼り付けることは犯罪か」ということと「その種の情報を集める掲示板を設置したら罪に問われるのか」という二点がごっちゃになりすぎ。

リンクのほうは「いままでセーフだったのがアウトに！」という感覚で騒いでる人が多いんだけど、昔からこの件はグレーゾーンとして扱われていたような。
ちなみにURLを直接書かない形(一部カタカナとか)にしてもNGという判例も既にあるとか。

あと、掲示板管理者の責任はかなり厳しいです。
基本その手の情報を放置するとアウトになる恐れがあります。
プロバイダ責任制限法の適用範囲は民事のみなので、刑事には適用されないということも覚えておくといいかも。
やばそうなネタを貼られたらちゃんと対応しましょう。

2009-06-19

怒首領蜂大往生のパクリ問題が意味不明すぎ

揉め事ゲーム

ゲーム開発には詳しくないのでわからないことが多いですが。
MAGES.(メージス)公式ウェブサイト

まずCAVE/ARIKAが大往生PS2版の開発。
で、CAVEからライセンスを受けてXBOX360版を販売したのが5bp。
5bpが開発を依頼した下請けがアクアシステム、だよね？
あとステージに上がってるのはCAVE/ARIKAが使っていたソースコード管理会社。

今回の問題は
「アクアシステムが前述のソースコード管理会社からCAVE/ARIKAが権利を持つPS2版のソースを勝手に取得し、それをベースに開発していました、なんて大変なことを！すいません！すいません！」と5bpが言ってる状態。

上のPRには謎がありすぎる。
ソースコード管理会社が許可無く第三者にソース開示しているというのがまずおかしい。
というか「ソースコード管理会社」なる仕組みがよくわからないけど、データサーバ運営とデータへのアクセス用の鍵を別会社に管理させてるって事か。
そんな会社がユーザに無断で第三者に対して鍵を渡すなんてあり得るのか？
そんなことしたら普通即訴訟→倒産コース一直線だよなあ。それが仕事なんだから。
「管理会社に袖の下」とかもあまりに非現実的。
それはもう「社員全員が棘ショルダーにモヒカン」というレベル。管理頼む前に逃げろ。

ソースコード管理会社がアクアシステムに騙された？
でも管理会社を騙せるってどういう状況だろうか。
5bpとCAVE間のNDA関連書類を見せて「私たちにもアクセスが許可されていますんでソースください」ってやる？
でもNDA書類を下請けとはいえ他会社に流出させるか？もうその時点で情報漏洩だよね？

開発参考のためのソースへのアクセスは許すけど中身は一から作りなさいよ的契約？
そんな契約世に存在するか？意味なさ過ぎ。

そもそもCAVEが使っている「ソースコード管理会社」とやらをなんで開発下請けが知ってるのかがわからん。
参考資料として見る機会も無いんなら「ソースコード管理会社」を下請けが知ってる必要無いよなあ。
「ソースコード管理会社」とやらは仕様書発注書その他のデータを管理してて、アクアシステムもソース以外の閲覧までは許可されてました、でもソースのアクセス制限が甘くて見られちゃいました、みたいなオチが一番ありそう。

どっちにしろ5bpのデータ管理姿勢の問題な気がする。
まっとうな作業フローでこんな情報漏洩起こせません。謎すぎる。