近くの公園に大量にいた ヨコヅナサシガメを庭木の害虫対策として適切かどうか評価している。

庭木の害虫で、義母からきつく言われているのはイラガの種類。幼虫に棘に毒があり非常に危険ということで、毎年農薬で防除すると言われていた。実際、去年の秋にカキを収穫した時に、イラガの幼生が大量に葉の裏にいたときはゾっとしたものだった。今年から松山に住むことになり、子供もいるので極力農薬は使いたくない、という要望を挙げて、とりあえず薬の使用は保留として、様子を見ながらいこう、という話になった。

そこでイラガほか庭木の害虫対策の筆頭として挙げたのがサシガメ。サシガメなどの肉食性カメムシは、対象の体液を吸うタイプの捕食者で、水生昆虫のタガメやミズカマキリと同様である。ただし捕獲肢がないため、相手を押えつけて襲うということはできないらしい。

飼ったこともないし、知識として知っているだけだったので、とにかくどんなものかをプラケースに入れて1月ほど飼育してみた結果、次のようなことがわかった。

毛虫、イモムシ類をよく捕食する

想定通り、自分よりも小さい毛虫、イモムシ系に対しては非常に積極的に捕食した。チャドクガ、マイマイガの毛虫や、アゲハチョウの幼虫などをあたえたところ、毛虫の棘にもまったくひるむことがなく、近づいて口吻を刺しこんでそのまま体液を吸っていた。

自分より大きなものは捕えられない

自分より大きい獲物には消極的で捕食できなかった。例としてはジャイアントミルワームやシャクトリムシの大型のものなど。ただし相手が死亡していれば、近付いて体液を吸うようだ。

素早いものは捕えられない

例としてガやハサミムシなどはすぐに逃げられてしまい捕食できていなかった。これは捕獲肢がないためやむをえないのかな。

外殻があるものは捕えられない

口吻を関節の隙間に刺しこめばしとめられるとはいえ、動いているものに対してそのようなことはできないようで、ダンゴムシ、カメムシなどは生きているうちは捕食できていなかった。

これらの実験の結果、毛虫に対してのヨコヅナサシガメの天敵としての可能性は立証できた。あとは実際に庭木に離しての効果を調べたいのだが、すでに20匹以上をカキの木やカシの木などに離しているのだが、とんと姿を見せない。もしかすると鳥に食べられてしまったか、まだそれほど餌となる毛虫が発生していないため、他に移動してしまったか。

サシガメに定住してもらうためには、餌となる毛虫などが一定数以上いなければならない。このあたりが系としてのバランスの難しさなのかもしれない。いきなり放しても、すぐに住みつくというわけにはいかない...そう、システムは一度には作れないのだ。

今年はしばらくは、木を眺めて毛虫が発生していないかをチェックする週末になりそうだ。

とある仕事で、構成管理のあたりの支援をやっていて、 bazaar をそれなりに評価していくつかはまりポイントがあったので、その結果をメモしておくことにする。

bazaar(略称:bzr)は、gitやmercurialのような分散型の構成管理ツールの一つ。git/mercurialに対してのアドバンテージでよく言われるのはファイルネームをUTF-8で管理しているので、ファイル名関連の問題が起きないというもの。実際今回bzrを選択したのは上記の理由が第一だった。

実際に使っていて感じたのは、bzrの最大の利点は リポジトリ構成の柔軟性 なんだろうな、という点だった。まぁそれはさておき、評価の際にハマったポイントをメモしていく。

巨大ファイルはadd/commitできるが、branch/checkoutができなくなる

最初に嵌ったのがこの問題。検証していたソースツリーの中に、oracleのdbダンプファイル(1.5GB)が含まれていた。DDLなのでテキストファイルだしということで追加してみたら登録できた。しかしここで油断してはいけない。そのリポジトリをbranchあるいはcheckoutしようとすると、その途中でこけてしまう。

落ちる個所は、zlib.decompressの中で、どうやらzlibで圧縮の掛ったコンテンツを復元しようとして巨大すぎてエラーになっていたようだ。bzrは環境変数 BZR_PDB に1を設定しておくと、エラー発生時にpythonデバッガが起動することができる。これでエラー発生の対象ファイルを突きとめて、原因(1.5GBファイル)が解明できたのだった。ちなみにエラー個所はこのあたりだった。

bzrlib/groupcompress.py (151) _ensure_content
  self._content = zlib.decompress(self._z_content)

なのでbzrへはテキストでも一定サイズ以上(これはまだ究明していないけど、zlibの制限などを調べればいいのかもしれない)のファイルはチェックイン時点で跳ねるようにしておかないといけないようだ。ignoreに含められるのであればそれがいいし、もしそうでない場合は、pre_commitのhookなどにファイルサイズをチェックするスクリプトなどでブロックしておく。コミットできるけど、取り出せない、というのがやっかいだよなぁ。

ファイル分割して登録する、という作戦もあるかもしれない。その際の最大ファイルサイズは別途調べないといけない。

ちなみに自分はignoreに追加で対応した。

コントロールコードのファイルネームが登録されているとマージディレクティブでマージできない

bzrはリポジトリ間の差分をマージディレクティブという差分データとしてメールで送信したり、ファイルに出力して、別のリポジトリでそれを取り込むことで、物理的に隔絶された環境でもリポジトリ間の同期を保つことができる。

ただこのマージディレクティブのpullうまくできないことがあった。これもBZR_PDBでデバッガに入ってようやく原因がわかったのだが、その原因とは登録ファイルのファイルネームにコントロールコード(^{C)の名前を持つファイルが含まれていたからだった。}

しかし直接リポジトリを指定してpullする分には、マージは適切に行われる。なぜファイルネームの不正によって、マージディレクティブによるpullが失敗するのか、というとマージディレクティブをpullする際に、inventoryと呼ばれる、リポジトリ内のファイルの一覧情報をXMLとしてマージディレクティブのバンドル情報から取り出している時に、XMLがinvalidでこけていた。ちなみに以下のようなメッセージだったはず。

ERROR: not well-formed (invalid token):line 6547, column 58

bzrlib/xml_serializer.py(82) read_inventory_from_string()
   raise errors.UnexpectedInventoryFormat

ちなみに単にファイルをremoveしても履歴に残っているとまずいようなので、そのファイルが登録される時点までuncommitして、そもそも不正ファイルが登録される歴史自体を黒歴史として封印する必要があるようだ。

(調査中)Solaris上で作成したブランチの作業ツリーをWindows上で展開できない？

ただ今はまり中なのが、Solaris上で作成したブランチをWindows上にbranch/checkoutする段階で、作業ツリーを展開しようとする時にエラーになってしまうという件。

作業ツリーなしのブランチの複製(--no-tree)ならば成功するのだが、作業ツリーを作る際に、どうもcheckout情報のファイルの中にWindowsで使えないファイル名が含まれているからっぽいのだが、優先度は低いのでまだ調査できてない。

まとめ

ここまでコケた話を挙げているので「bzrだめじゃん」とか感じる人がいたらすみません。bzr自体は評価してみて結構気に入っているのです。BZR_PDBがあるおかげで原因も解明できたしね。

今度はbzrでこんなによかった、という話を書けばいいのかもしれないですねぇ。（そのうち）