SVX日記

　 納車直後であるが、今後のためを思って(?)表記オフに参加させて頂いた。

　 柏から常磐高速にのり、外環に乗り換えたところで、道も空いていることだし、「ちょっと試してみた」のだが、あまりにスムーズに100まで出るので驚いた。

　 ソアラの時は当然のように60で走っているのと80で走っているのでは、体感する安定感に大きな違いがあった。高速では80弱で巡航することが多かったものの、ちょっと肩に力が入っていたりもした。

　 が、どうだろう、SVXでは60以降は100まで「すーっ」と伸び、なんの変化も感じないではないか。聞きしに勝る、恐るべき安定性である。なんとなく、追い越し車線を100で巡航している外車の気分がわかった気分であった(※文中の数値の単位には参るです)。

　 で、オフ会の会場であるAW美女木に到着すると、すでに大量のSVXが。それぞれ個性のあるカスタマイズを目の当たりにし、驚く。「これはマネしたい!!」と思うものも多々あったのだが、そのほとんどがDIYっぽく、そう簡単にマネできなさそうなところがツラい。とりあえず、傷んでいる鼻先のエンブレムをキレイにして、何らかのナビをつけたいところ。

　 ちなみに、すぐ隣ではワンボックス車で同様のオフ会が行われていた。私にはまったく興味の湧かない車なので見向きもしなかったが、それはお互い様であろう。

　 帰りは外環の下を通って三郷まで。しかしこの重厚感のある乗り味、たまりませんなぁ。

　 このSVX日記が利用しているBlogシステムであるtDiaryは各日付の日記エントリに対しコメントがつけられるようになっている。関連する話題について深く語るにはよいシステムではあるが、反面、かなり過去の日記にコメントがついても、ほとんど誰も気づかないというサミしさもある(管理者のオイラにはメールが来るので気づくようになっているが)。そーゆー意味からすると、いわゆるシーケンシャルな掲示板とうまく連動するようなプラグイン(外部実装でもいい)があったらオモシロいのに、と思うコトもある……と思ったら、最近のツッコミプラグインってのがあるのね。今度入れてみようかな。

　 と、いうのも「 Gmailにインポート!!」という過去のエントリでちょっと「整理法」について深く考えさせられる興味深いヤリトリがあったからである。まぁ、ヒトクチに整理法といっても個人によって向いている方法はイロイロだろうし、それに対する明快な解答は存在しないであろうから、手段がいろいろと提案されているに越したコトはないだろう。その点で、時系列の整理を強く推奨している「超整理法」という本の提案内容も、なかなか有意義だと思うのである(電子媒体上の情報の整理には向かないと思うが)。

　 そんな中、オイラが心を痛めているのが「電子部品の整理」である。趣味として電子工作を始めてから、もうすぐ2年。もともと整理というモノが、組体操のサボテンよりも苦手なオイラではあるが、それでも電子部品の整理はかなり難しい部類ではないかと思う。

　 そもそも細かい部品が多いのだ。手で扱いにくいほど小さな部品もある。そして種別も多い。電子部品のショッピングサイトを見るとその項目数の多さに驚くが、それでも分別しきれていない印象だ。さらに部品のサイズもバラバラである。ガワ(ケース)も部品の一種であるが、表面実装部品と数万倍の容積差があるから、同じように収納するというワケにもいかない。オマケに部品は消耗するから、数の把握も難しい。そんなトコロにジャンクの取り外し部品が混ざってくるのである……うがーッ!!　ガイアの極み……じゃなかった、アビスの極み……でもなかった、そうッ!!　カオスの極みであるッ!!　なんか、よい電子部品の整理法はないのかッ!?

　 しかしココでハタと気がついた。部品の整理に「超整理法」を適用してみてはどうか。何も考えず、1回の買い物をひとつの紙袋(秋月名物の紙袋がイイ!!)にツッコみ、時系列に並べてしまうのである。オイラの場合、このブログに買い物内容をリストアップしているから、探したいパーツをnamazuで探し、日記エントリの日付をキーに紙袋を探せばよいワケだ。

　 こーなると、紙袋にデカく日付を書いておくのが有効かもしれない。ついでに月別にテーマカラーを決め、その色の紙をタグとして袋の頭にホッチキスでくっつけておくと、頭の中で部品と色が自然に結びついて、記憶に頼った検索にも有効かもしれない。こりゃ、名案かも〜ッ!!

　 問題は現状がシッチャカメッチャカな状態にあるコトなのだが……ま、今の状態は放置するとして、今後はコノ方法を実践していけば、3年後くらいには徐々に事態が収束するかもしれないと期待を抱きつつ、今日も部品探しに部屋をさまようのである……う〜、ケース実装用のRCAジャックはどこじゃ〜……。

　 とゆートコロで、今日もまたSeedをドップリと観る。第30話「閃光の刻」までの5話を観る。物語的にはクライマックスの序章にあたるトコロだ。今までは小競り合いに終始してきたキラとアスランという親友同士だが、戦場以外で偶然に顔を合わせ、ギコちないながらも友情を再確認したのに、それでも戦う運命に逆らえず、互いに互いの仲間を殺めてしまった挙句、憎しみは頂点に達し、とうとう親友を殺してしまうという展開である。もー、究極に盛り上がっちゃうSeedのキモともいえる場面である。ずももももも!!

　 しかしながら、親友を殺してしまう展開ではあるのだが、実は死んではいないのである。ふたりは主人公だから死んでしまっては困るのである。ココでまたチマタの感想ブログを引用すると、あの状態で死なないのは不自然だとか、オカシイとか、ゴツゴー主義とか、散々に叩いている……おまいら、ウルセーんじゃ!!　合理的な説明があるに越したことはないが、そんなトコをツッコんだってしょーがねぇーんだよッ!!　合理的な説明がなくたって、別にソコは物語の本質じゃあねぇーんだよッ!!

　 そーいや今度、オイラもハマった「最終兵器彼女」という作品が実写映画化されるようであるが、この作品は、そもそもナゼ彼女が人間兵器そのものに改造されてしまったのか？　とかそーゆー説明をあえてガッツリと捨て去っている。そして、この作品については、そーゆートコロをコマゴマと指摘する無粋なヤツは極めて少ない。あくまで物語なのであるから、そーゆーふーに観るベキなのである。

　 ちなみにオイラはアニメ版の「サイカノ」もひととおり観たが、それはナイスな映像化であった。今度、映画化されたとして、映画館まで観にいくかどうかはワカらないが、なんとかデビルマンの二の舞だけは避けていただきたいコトを星に願いつつ、オヤスミである。

　 ネタがないんで、ちょっとバラします。

　 先日から子供用のキーボードを1,000円で買って、最高ッ!!　いい買い物したッ!!　なんて自慢してますが……実はイッペイのオモチャです。あ、いや……オイラのオモチャなんだけど、イッペイに貸しています。

　 貸すのはいいんだけど、バンバンと乱暴に扱うし、キーを押しっぱなしにするからウルサいし、興奮してよだれを垂らすし、思い切りナメるし……って、いーかげんにしろッ!!　もう貸してやらないぞッ!!

　 ……貸しますよ、貸せばいいんでしょ。

　 こういうことはないだろうか？

　 ロールプレイングゲームなど、プレイ途中、数十〜数百回ものセーブを繰り返しながら進んでいくゲームがあるとして「直前の記録をいくつか残したい」と思ったことは？

　 最近のゲームでは少ないだろうが、例えば、売ってしまってはいけないアイテムを売ってしまい、その状態でセーブしたら、その後ゲームを進められなくなってしまう、などという状況がある。しかし、そういう場合、セーブエリア1,2, 3を順に使っていれば回避できる可能性がある。直前のセーブデータより、もうふたつ古い世代のセーブデータから始められるからだ。これは簡単に実行できる。

　 では、だいぶ前のイベントをもう一度見たくなった時のために「現在までの中間地点付近の記録をまばらに残したい」と思ったことは？

　 これを「何となく、ではなく」実現するのは難しい。例えば10章まで進んだ時点で5章のデータを残しておくことはできるが、20章まで進んだ時点では10章付近のデータが残っているべきなのだ。セーブエリアの数に制限がなければ考える必要はないが、6個とかに限定されるとやりくりする必要が生じる。

　 この問題は、ゲームのセーブデータに限らない。例えば、自分はヴォーカルの練習の記録を残してあるが、もう始めて5年くらいになるので、最近、記録容量が溢れそうになっている。後で成長の記録を確認したいと思えば、古いものや、2年半くらい前のものは残しておきたい。しかし、具体的にはどのように消していったらいいのか？

　 そしてPCのバックアップである。例えば、6回分の保持が可能な容量があるとして、直近の6世代を残すのはいい方法なのだろうか？ それだと、1週間前にオペレーションミスしたことに気づいたら、あきらめるほかない。直前と、もうふたつ古い世代は残しておくとしても、残りの3回分は、もう少し他にやりようがあるのではないか？

　 つうわけで作ってみた。結論からいうと、完全に気に入った結果にはなっていないが、とりあえず「直前3世代＋まばら3世代」での結果については、そこそこ使える動きになっていると思う。

　 動きを図化するとこんな感じだ。横軸がバックアップ世代、縦軸が時間の経過を意味している。概ねどの時間に着目しても、その時点の中間点と、中間点以降での中間点あたりの世代がまばらに残される動きになっている。フラクタル的にも見えるな。

　 クラス化してあるので、以下のように使う。stored=で最新の世代数を渡し、should_delete?で既存の世代を削除するべきかどうか訊き、肯なら削除すればいい。

backups = {}; last_gen = -1
Dir.glob('xxx_backups/*').each {|path|
    gen = open('%s/.gen' % path).read.to_i
    backups[gen] = path
    gen > last_gen and last_gen = gen
}
 
ebackup = EspBackup.new
ebackup.stored = last_gen
backups.each {|gen, path|
    ebackup.should_delete?(gen) and p('rm -rf %s' % path)
}

　 クラスの内容は以下。

class EspBackup
 
    def initialize(sgens = 3, lgens = sgens)
        @sgens = sgens; @lgens = lgens
        @bhs = []               # 3: [ '1110', '1100', '1000', '0100', '0110', '0111', '0000' ]
        sgens.times {|i0|
            i = sgens - i0      # sgens..1
            @bhs << ('1' * i + '0' * (i0 + 1))
        }
        sgens.times {|i0|
            i = i0 + 1          # 1..sgens
            @bhs << ('0' + '1' * i + '0' * (sgens - i))
        }
        @bhs << '0' * (sgens + 1)
    end
 
    def stored=(gen)
        @rgens = {}
        @lgens.times {
            @rgens[gen] = true
            (gen -= 1) < 0 and return
        }
        bw = ('%b' % gen).size
        @bhs.each {|bh|
            (it = (bh + '0' * bw)[0, bw].to_i(2)) <= gen and @rgens[it] = true
            @rgens.size == @sgens + @lgens and return
        }
    end
 
    def rgens
        @rgens.keys.sort
    end
 
    def should_delete?(gen)
        !@rgens[gen]
    end
end

　 とりあえず、それなりの結果にはなっているので実用に供しようと思うが、完全に気に入った結果にはなっていないのだよな。特に保持数を上げると不自然な結果になってしまう。大きな考え方はいいと思うのだが、フラクタルがヒントなのかなぁ。