SVX日記

　 1ヶ月近く前、このSVX日記にnamazuによる検索窓を装備した頃のハナシであるが、気がつくと2004年8月の日記データファイルが破損してしまっていた。200408.td2(本文ファイル)のサイズが0に、200408.tdc(ツッコミファイル)がヘッダ行だけになっていたのだ。壊れ方からしてオイラの操作ミスの可能性は低そうである。レファラスパムの対象が2004年の8月のエントリに集中していた事実があるし、もしかすると高負荷時にクラッシュしたのかもしれん。

　 幸運なことにサーバ側のキャッシュのおかげで、データが消失した部分の日記にもアクセスできた。しかし、日記本文の修正やツッコミをした瞬間にヘンなコトになるのは目に見えているし、現状でsqueeze.rbにより検索用HTMLを取り出す作業もできなくなっているので、いずれにせよ復旧は必要だ。とりあえず壊れたのが判明した時点で、ブラウザで消失部分の日記にアクセス、2004年8月分の日記はHTMLの状態で保存しておいた。今日はそれをモトに、td2とtdcファイルを手動で逆生成するのである。

　 手動といっても、全部手動でやると死ぬので、Rubyスクリプトを使って概ね整形する。必要のないHTMLタグをバシバシと切り落とし、ヘッダを逆生成し、IMGタグをtdiary形式のタグ形式に戻す。ある程度td2形式っぽくなったらsqueeze.rbでHTMLとして抽出。以前のHTMLとの間でdiffを取り、差分の手動修正、HTML抽出……を繰り返す。ハナシがややこしいが、通常はAからBとC群が生成されるとして、Aが消失したので、BをモトにAを再構築し、再構築したAから以前のC群が生成されるようにAの修正を繰り返すのである。ここでAはtd2、Bはブラウザで保存したHTML、Cはsqueeze.rbで生成したHTML群である。Ah, what a 不毛な作業 it is。

　 結局2時間以上かけて、ツッコミファイルのtdcを含めて復旧。改めて、全ての日付のHTMLをsqueeze.rbで生成し直し、mknmzでインデックスを付け直した。これによりsqueeze.rbの中途半端な改造により、2005年2月分の検索インデックスに本日のリンク元の内容が含まれてしまっていた問題も解決した。うーん、スッキリじゃ。

　 いまさら語るまでもないことだがバックアップは重要である。ウチのサーバはソフトウェアRAIDにより、ミラーリングまで施しているが、こういう時には役に立たない。こんな時にはpdumpfsというバックアップスクリプトが便利である。

　 このpdumpfsはnamazuの作者が作ったRubyスクリプトで、ハードリンクを利用した差分バックアップを行うという特徴を持つモノ。細かい理論はオフィシャルサイトで確認して欲しいが、早い話、フルバックアップと同じ操作性と、差分バックアップと同じサーバ負荷という利点を併せ持つ、目からウロコのバックアップシステムである。UNIX系の/etcのバックアップなんかにも最適である。

　 今回は作業前に~svx以下を丸ごとバックアップして復旧作業に臨んだが、作業後の2度目のバックアップの速いこと。グレートである。そのうち、あちこちのディレクトリにコレを仕掛けようと思っている。できれば、外付けUSB-HDDにバックアップするように設定し、ついでにそのUSB-HDDの電源も自動でON/OFFするようにしたら面白いかもしれない。

　 で、話は替わって、今度は調光器の方に取り掛かる。回路を全部見直し、ダイオードの方向や生き死にも全部チェック。AC100Vに接続し、電灯を調光させている状態で、制御側の交流電圧をテスターで計測してみたりもする。やはり、ほとんど中間電圧が出ない。抵抗器を絶妙にイジって中間電圧を出そうとすると、電灯が不安定に点滅する状態になる。むぎゅぎゅぎゅ〜。

　 再び、秋月の回路図とニラメっこ……よく見るとトライアックって、ダイアックにナナメに線を付加した回路図記号だよなぁ……もう一本、線が増えたらテトリアック？　なんちて……ナナメ……ハッ?!　まさか、トライアックって、極性があるのかッ?!

　 確かにトライアックにはT1, T2, Gと書いてあるけど、T1, T2に極性があるなんて考えてもみなかった。Gに与えるトリガにより開閉する扉のイメージだったけど、厳密に言うと「弁」のイメージだったのか。むむ〜ん。いままであちこちでトライアックについて見聞きしてきたつもりだったけど、まったく気づかなかったな。確かにNとPからトライアック内部の構造について、トランジスタの例を参考に考えれば当たり前だろうに……げしょげしょ。

　 すかさず結線を逆にした結果……ちゃんと動いた。なめらかに光量を調節できる。はぁ、よかった。とりあえず完成。ちゃんと説明書を読んで、プリント基板上に作っていればこんなミスはなかったのだろうが、オイラが中途半端に回路を理解したつもりになり、ナメてかかっていたので落とし穴にハマったようだ。しかし、配線が逆になっていてもそれなりの動きをするとは意外だった。理由はいまいち理解できんが、まぁいいや。

　 ま、ひとつ勉強になったのでヨシとしよう。キットを組んで、まんま動いたんじゃあまり勉強にならなかったしなぁ(くやしまぎれ)。そしてこの後、調光器に改造を施し、計画は第2段階に移行する予定である。その内容については、またいずれ(ちなみに上の写真の右側のケースは単なる友情出演で計画とは無関係)。

　 あ、最後に……今度はリクナビNEXT経由でマイクロソフトからスカウトメールがきたんですけど……あは、あはは、あははは、あはははは、あたたたたた、あたたたたたた、ほわたぁ!!　別にアンチではないけど、好きじゃないので、却下っす。

　 製作中のオシロに関し、なんとなくLM7171でググッたら……

　 「ボルテージフォロアでは使えません」

　 ……という記述を発見。あわてて、データシートを引っくり返すと、確かに「+2倍または-1倍の低利得でも安定動作します」と書いてある。こんな記述、すっかり読み飛ばしておったわい。「+2倍または-1倍の低利得」というと非常に回りくどいが、要するに、非反転増幅回路では2倍以上にすれ、反転増幅回路では1倍未満にするな、ということだ。ボルテージフォロアはオペアンプ自身にはキビしい動作条件である、などという記述をどこかで読んだ気がするが、LM7171はその性能の反面、やや気難しいオペアンプらしい。

　 オイラの設計した回路は、前段がボルテージフォロア、後段が-0.x倍増幅(減幅？)なので、両方ともアウトだ。なんだよぉ、そゆことは、先に言えよぉ。

　 昨日、散々ハンダ付けした後に知る、驚愕の事実。でもまぁ、ピンアサインが同じで、もう少しスルーレートの低めの、フツーのオペアンプに付け替えれば捨てることはないかな。そういうオペアンプを手配しよう。どうも、LF411なんて、よさそうだ。

　 とかなんとかオペアンプを物色していたら、先日はスルーしていた「定番回路」が、突然、理解できてしまった。そっか。オイラの回路では、双ch間でグラウンドが共通である必要があって、そこに不自然さを感じていたけど、こうすれば各chで独立になるわけか。まさに「インスツルメンテーションアンプ」なわけだ。こっちを採用するには、設計からやり直しじゃん……。LM7171のデータシートの中にはこの回路の適応事例が載っていたが、1つ200円という高価なオペアンプでは、さすがにこれは作れないわ……こっちは、上記のLF411の兄貴分であるLF412で作ろうかな。

　 なんにせよ部品が足りないので、オシロ製作はしばしお休みである。

　 借りた本を返しに、鶴舞の図書館へ。ついでに、大須に寄って、部品を購入。先日、HT7733Aによる昇圧回路で失敗したこともあり、インダクタ等を漁りつつも、結局、評価のために秋月のDIP化基板も購入してしまう。うーむ。

　 そのまま名古屋の109シネマへ。今度、職場で映画を観に行くことになったのだが、そこで上映時間の制限で観られない「ベルセルク」がどうしても観たくなってきてしまい、いまさらながら、ひとりで観に行くことに。

　 上映期間が終わりかけなこともあり、19時から1回のみの上映なのだが、なんだか7割以上は入っている感じ。んー、人気があるのかないのかよくわからんな。

　 映画はかなりよかった。ストーリーは、既にテレビでアニメ化されたことのある「黄金時代」の前半1/3なのだが、やはり魅力的なのはこのパートということか。オイラ自身「黄金時代」までは漫画を買い揃えてまで読んだが、その後、テンションが下がって、売ってしまったような覚えがある。

　 長編の映画化では、よく「既に漫画を読んだ人向け」として、説明不足の傾向にマイナス評価する輩がいるが、これだけ多様化が進んだ昨今、初見の層をターゲットに置くなんてのは、むしろナンセンスだ。ざっくり切っても「おいしい」シーンが伝われば成功であることは、太古の「劇場版マクロス」で証明済みである。極端な例では「最終兵器彼女」なんて、漫画原作の時点で「説明不足」を演出の一部としているし。

　 漫画というメディアでは得られない体験ができれば、別に追体験で上等ではないか。コンサートは、CDを聴いてから行くものだ。むしろ「読んでから来いよ」という態度は十分に「あり」ではないか。監督がどのエピソードを重要視し、それをどのように映像として表現したか、それが楽しめればいいんじゃないか。つーか、原作ファンは、それだけを確認しに劇場に赴き、そして、大抵、裏切られて帰るんでしょ？:-)

　 というわけで、今回オイラは割と満足した。なにしろ、戦闘シーンが熱く、なにしろ、斬られる様子の痛さに、ドキドキした。特に最後、アドニス王子に対する演出については入念すぎて息が詰まった。きっと、監督はそれを表現したかったに違いなく、それで漫画では得られない体験ができたのだ。

　 ただ、ストーリーや演出から離れて言えば、決して悪くはなかったものの、声優は深夜アニメのキャストのままのがよかったとか、もっと解像度を上げ、コマ割りも上げてほしかった、と感じた。CGを多用してるんだから、いまどき全部とはいわないが、ドンと48FPSとか、別に不可能というワケでもないんだよねぇ？

　 本日の走行距離は357.5km。累計距離は3386.6km。

　 昨日、pack/unpackって記述方法としてはどうなのよ、と書いてから、なんだか考え始めてしまった。要するに、以下の書き方が全然ピンとこないのでちっとも覚えられない、って話である。

[65, 66, 67].pack('c*')
=> ABC

'ABC'.unpack('c*')
=> [65, 66, 67]

　 じゃ、ピンとくる書き方ってなんだって考えたら、以下が思い浮かんだ。これは実際に動く。いわゆるprintfだよね。

'%c%c%c' % [65, 66, 67]
=> ABC

　 「%」演算子を使っているのがミソだ。「文字列化する」「引数は配列」というイメージが自然に湧く。じゃ、逆に「配列化する」演算子はなんだ？ 苦し紛れだが、こんなのはどうだ。こんな文法はないので動かないが。

'%c%c%c' << 'ABC' # 動きません
=> [65, 66, 67]

　 これに近い記述方法で、実際に動かすことはできないか？ って考えたら、思い浮かんでしまい、できてしまった。

:c_ << 'ABC'
=> [65, 66, 67]

　 RubyのSymbolを悪用(？)して定義した。「<<」演算子を再定義している。「c*」とは書けないので「c_」で代用してみた。

class Symbol
    def <<(packed)
        packed.unpack(self.to_s.sub(/_$/, '*'))
    end
end

　 これを使うと、BASE64のデコード処理を以下のように書ける。

:m_ << 'QUJDREU='
=> ["ABCDE"]

　 そうなると、逆にエンコードする時はこう書きたい。そんな指示子はないので動かないが。

'%m' % ['ABCDE'] # 動きません
=> "QUJDREU=\n"

　 んが、今度は逆に、Stringの「%」演算子を再定義してしまえばいい。指示子の指定が「%」だと既存の機能と衝突するので「:」を割り振ってみた。

class String
    alias :perc :%
    def %(arg)
        self =~ /^:(.+)/ ? arg.pack($1.sub(/_$/, '*')) : perc(arg)
    end
end

　 これを使うと、BASE64のエンコード処理を以下のように書ける。

':m_' % ['ABCDE']
=> "QUJDREU=\n"

　 そもそもBASE64の変換は「文字↔文字」だからピンときにくいだけのことかもしれない。無理にピンとこさせずとも、以下をメモっておけば十分か。

['ABCDE'].pack('m*')
=> "QUJDREU=\n"

'QUJDREU='.unpack('m*')[0]
=> "ABCDE"

　 まぁ、単なるたわむれプログラミングだ。わはははははははは、たわむれは、おわりじゃ。