みなさん御存じのとおり、オフィシャルサイトにチケット売れ具合が出るようになりました。えらい便利な世の中になったと感慨もひとしおです。

最少のものをだいたいシーズンチケットぶんだと仮定すると、

• SゾーンとSA指定席は70～90%
• Aゾーンは50～70%
• SS指定は10～30%

がシーチケということになります。席割図を見ると、以下のような分布。

• Sゾーン…約2000席弱
• SA指定席…1235席
• SS指定席…726席
• アウェイ席…4500～5000席 (しかし図の通りだと2階席は1100席くらいしかありませんね…)
• Aゾーン…16000～16500席
• 合計…25000席

ということは、シーズンチケットの内訳は、このくらいかな。

• Sゾーン…2000x7～9割＝1400～1800
• SA指定…1235x7～9割＝864～1111
• Aゾーン…16000x5～7割＝8000～11200
• SS指定席…726x1～3割＝72～217
• 合計…10336～14328

まあだいたい11,000セット売れたというところでしょうか。後援会入会者が昨シーズンで16,000人ですから、全員更新したとすると、後援会に入った人の7割近くがシーズンチケットを購入したということに。平均動員が17,000人程度なので、シーズンチケット＋後援会の緑チケット(1試合平均1600枚使用されると仮定する)で12,600。

Pythonでネイティブコードを簡単に呼ぶ方法として、ctypesとboost.pythonがある。ctypesは最近はPython本体に含まれるし、boost.pythonもBoost本体に含まれているようだ。この2つは、swigや自力でインタフェースを書く場合と比べてだいぶ楽に呼び出せる。

で、どのくらいコストが違うのか、試してみようと。ネイティブコードを呼んだ先では大差ないと思うけど、ネイティブコード呼び出しにかかるコストによっては、インタフェースの粒度を考えないといけなくなる。

そこで、ためしに

• 何もしない
• math.sinを呼ぶ
• cmath.sinを呼ぶ
• boost.python経由でstd::sinを呼ぶ
• ctypesでlibmのsinを呼ぶ

という呼び出しの速度を測ってみた。cmathは複素数に対応した数学関数のパッケージです。sinが複素数を返すことはない…と思いますけど、mathとcmathの比較のために一応。200万回の呼び出して時間を測定して平均した。測定環境がVista(32bit)環境のVMWareの中のFedora8(x68_64)環境、というのがややこしい。こういう環境は測定が正確じゃないかもしれないですね。仮想環境のgettimeofdayはあんまり信用できないような気がする。vmware-toolsを入れて時刻をホストと同期はさせてますが。

Jリーグが始まるまで暇ですね。新ユニを今か今かと待っているんですが、なかなか来ません。totoは忘れないうちにネットで買いました。

というわけで。

リサイクルについてはやはり、考えさせられますね。リサイクルは3つのRの中で最下層に属するものなので、上位の2つを差し置いてリサイクルを推奨するのは間違いですよね。無駄になるものの量を減らすこと(Reduce)、加工せずに再利用すること(Reuse)を先に考えないといけないのであって、リサイクルが大きな顔をしているのはやはり、気に食わない。そうそう、子供用品なんかはReuseの宝庫ですね。うちでは今のところ、かなりの部分がお下がりです。まあそれは置いといて。

リサイクルの中でも、クローズドリサイクルとオープンリサイクルがあるらしい。クローズドのほうは本当に回っていくもの。缶を集めて、そのアルミからまた缶を作る、みたいなもので、私はこれまでリサイクルというのはこれのことだと思っていた。ただ技術的に問題がたくさん出るので、人類はオープンリサイクルという概念をひねり出したんですよ。なんという胡散臭い話なのか。

オープンリサイクルはもともとの姿と再生した姿が何の関連もなくても可という、何でもありの概念。極端な話、燃やして熱にしてもOK(ご丁寧なことにサーマルリサイクルと名付けられてでかい顔をしている)、埋めて地面にしてもOKというわけで、これが許されてしまうと、リサイクルというくくり自体に意味がなくなるでしょう。確かに夢の島でJリーグの試合が開催されて幸せを運ぶことだってあるけど、オープンのほうは「サイクル」になってないんだよね。オープンリサイクルにならない捨て方なんて、果たして今までに存在したんだろうか。

「環境問題はなぜウソがまかり通るのか」という本が話題だったので、だいぶ昔に図書館に予約を入れていたのが今頃になって確保できたので読んでみた。

最初のペットボトルの話は因果の結びつけに無理があるとは思うが、リサイクルがうまく回っていないのは事実だろう。サイクルにして回すには、作って売って回収して再生する、という流れが必要になるが、回収するところで売る量の半分くらいになって(この値は優秀だと思います)、再生するところではその1～2割くらい。平均して、買ったペットボトルの10～20本に1本が何かに再生されるという計算。

おそらく技術的な問題があるため下流の再生の部分が流れないことが分かっているのに、絶大なコストがかかるけれど国民に(分別の手間を)転嫁できる回収の部分だけ発達させてしまった、というのが最大の問題でしょうね。分別して回収しても結局再生のアテがつかないから、そのまま燃やすしかないんだよね。ゴミを燃やすための燃料にするor熱を回収する、というのは分別しなくてもできることですから、分別に意味を持たせるには燃やしてOK(というか誰かに処分を押し付けてOKにしているみたい？)という現状はダメでしょう。再生の技術的な問題を解決してサイクルを回すか、分別回収をやめて無駄なコストを削るか、どちらかをしなければ非効率(による環境破壊?)を解消できない。こないだあった再生紙の問題も同じ構造ですね。再生の部分に技術的な問題があるためにごまかす必要が生じた。

ネットでアップしたPDF類をセブンイレブンのプリンタで出せる。なんて便利な世の中になったものか。モノクロ20円/枚、カラー60円/枚。

類似のサービスは2つほど見つけた。

• 日本に上陸したPrintMe。米国でメジャーなのかな。ただし日本では出力先が少ない。新宿か品川プリンスホテルのフロントか成田空港近くのラディソンホテルくらい。問題外ですな。
• ハイブリッドめーるサービス。郵送してくれるらしい。ただし2枚まで。

他にも印刷屋さん系で製本やチラシ印刷のサービスは多いけど、1部単位でやってくれるところは見つけられなかった。普通にネットプリントと言うとデジカメで撮影した画像データの印刷(現像)を指すことが多いみたい。

で、さっそく登録して税務署に出す所得税の確定申告のPDFを出そうと思ったのだけど、エラーになってしまった。用紙のサイズが混在しているとダメとかいうエラー。いや混在してないんだけど。しょうがないので自宅のプリンタで出した。途中からインクが少なくてかすれてしまったが優秀な税務署の職員なら少々薄くても読めるだろう。

電子申告にはまだ手を出していません。なんだかんだいって手順を見て、面倒だということに。本人確認なんてもうちょっと適当でもいいんじゃないのかな。

しかし、プリンタ捨てようと思ってたんだけどね。こういうことがあるとなると、捨てることができなくなってしまった。

WLWにはAPIが用意されている。どうにかしてこれを呼べないかなぁと思った。ファイルは「C:\Program Files\Windows Live\Writer\WindowsLive.Writer.Api.dll」だということはわかっている。状況から考えて、たぶん.NETのライブラリなんじゃないかな。

まずはPythonに付属のctypesだが、ctypes自体は状況によっては異常に便利な、ものすごいものではあるが、、、

>>> import ctypes
>>> wlapi=ctypes.cdll.LoadLibrary(r"C:\Program Files\Windows Live\Writer\WindowsLive.Writer.Api.dll")

ここから先が続かないんだよね。何の関数を呼べばいいんだろう…そもそも.NETのdllってctypesから呼べるのかどうか…

.NETだからIronPythonだろう、ということでipyを入れてやってみると、当たりっぽいのが出てきた。

>>> import sys
>>> import clr
>>> sys.path.append(r"C:\Program Files\Windows Live\Writer")
>>> clr.AddReference("WindowsLive.Writer.Api.dll")
>>> import WindowsLive.Writer.Api as wlapi
>>> help(wlapi)
 :(大量のテキスト)
>>> dir(wlapi)
['AdaptiveHtmlObject', 'Alignment', 'ContentCreationException', 'ContentResizedEventHandler',
 'ContentSource', 'HtmlDocumentAvailableEventArgs', 'HtmlDocumentAvailableHandler',
 'HtmlScreenCapture', 'HtmlScreenCaptureAvailableEventArgs', 'HtmlScreenCaptureAvailableHandler',
 'HtmlServices', 'HtmlType', 'HttpRequestCacheLevel', 'ILayoutStyle', 'IProperties', 'IPublishingContext',
 'ISmartContent', 'ISmartContentEditorSite', 'ISupportingFiles', 'InsertableContentSourceAttribute',
 'LiveClipboardContentSourceAttribute', 'PluginDiagnostics', 'PluginHttpRequest', 'ResizeCapabilities',
 'ResizeOptions', 'SmartContentEditor', 'SmartContentSource', 'SupportsFeature',
 'UrlContentSourceAttribute', 'WriterApplication', 'WriterPlugin', 'WriterPluginAttribute',
 '__builtins__', '__dict__', '__name__']

なんかぐぐりながらやっていけば、少しは見当がつきそうな感じ。でもプラグインの呼び出しの口はDLLで作らなきゃいけないはずだから、Pythonで作るのは無理かなぁ。プラグインのDLLを別から呼んで遊ぶなんてことはできるかもしれない。WriterPluginではなくWriterApplicationクラスを使えば、自分のスクリプトからWLW経由で投稿、というのは可能か。

cinepaintでブラケット撮影の画像を読み込んで1つにできると聞き及び、やってみた。ずれを検出して補正する機能もついていた。Fedora8で

## yum install cinepaint

でインストール、cinepaintコマンドで起動できる。さっそくこのへんのチュートリアルを見ながら、「ファイル」-「New From」-「Bracketing to HDR」を選び、ずれ(offset)を検出、HDR画像を生成してみた。紫色のエリアがたくさんできるので、「画像」-「Colors」-「Gamma-Expose」で適当にチェックすると、それらしい画像になった。

ただ、手持ちだとさすがにずれはいかんともしがたいですね。cinepaintの補正は平行移動を仮定しているようだけど、それだけではずれがおさまらないです。非常に手ブレ感のある画像になってしまいます。あと、HDR画像をOpenEXRで保存できませんでした(gamma値が外れているとかいうエラーが出る)。xcfやtiff、hdrなどの形式では保存できましたが、cinepaintとgimpの世代が違うらしく、xcfをFedora8のgimpでは開けないという…まあ、32bit IEEE floatをやめてPNGあたりで保存するのがいいかなぁと思います。8bit unsigned intにしてもjpegで保存できませんでした…

会社の人から「何やってんの、Rawtherapee使えばそんなの楽勝っすよ」と言われたので試してみた。rawtherapee hdriでぐぐると、日本語ではその人のページと2chのログくらいしか検索されないんですけど… さっそくインストールして使ってみた。Windows版にはgtk+のライブラリやら何やらも詰め合わされて入っている。Linuxアプリをgtk+ライブラリ詰め合わせにしてWindows版、Windowsアプリをwine詰め合わせにしてLinux版、で両方配布するのが今後は主流になるのかもね。言語ファイルのenglishをjapaneseという名前にコピーして、自分で翻訳していけばUIも日本語が出るようになるので便利だ(？)。私はこういう技術に疎いので妥当な訳語が分からないですが。 rawのデコードにはdcrawを使っているような雰囲気。機能がありすぎてどれを使えばいいのかよくわからないが、「Color Boost」で最高にブーストすると(?)、不自然に色が強調された、それっぽい絵になった。jpegでもColor Boostすれば、それっぽくなるなぁ。 今までいじっていたufraw(こちらはdcrawのフロントエンドか？)でも似たような感じにまではできる。機能はRawTherapeeのほうが多そうです。 それで、RawTherapeeを使って、jpeg1枚とraw1枚でどういう差が出るのか、対決してみようかと思いました。 このシリーズで初めて画像を出してみよう。元の絵はさきほど撮った室内の様子です。自宅の写真はちょっと恥ずかしいですけど。キャプションをそれっぽくするために、無駄にポラロイド風にして傾けてしまった(笑)。RawTherapeeの設定は、以下のようなもの。操作としては普通に読み込んで、ColorBoostでめいっぱい効果が出るようにしてみただけです。

VMWare経由で使っているFedora 8をx86_64版にしてみた。ホストOSが32bitでもゲストOSを64bitにできるようです。えらいです。

VMを生成するときに警告が出てIntel VTが有効になってないとか言われたので、BIOSを眺めて有効にした。今まで有効だと思って「さすがに速いな…」とか呟いていたのだけど、間抜けでした。VMWareはコードのロード時にバイナリを書き換えて実行するときのオーバーヘッドを減らしているので、無効でもそこそこ速いはずです、というのは言い訳です。

確かに、こころなしか速くなってる気がしますね。気のせいかもしれません。

聞いていたとおり、ポインタとlongが64ビットになってますね。あと特に何かせずに普通にoff_tを使っても64ビットになっているので、面倒だったFILE_OFFSET_BITS=64も必要なくなります。あとは変わらず、かな。

# for i in char short int long "long long" quad_t "void *" off_t; do sh sizeof.sh "$i" sys/types.h ; done
sizeof(char)=1
sizeof(short)=2
sizeof(int)=4
sizeof(long)=8
sizeof(long long)=8
sizeof(quad_t)=8
sizeof(void *)=8
sizeof(off_t)=8

スクリプトは以下の通り。

ところで、WLWでは略語(やタグ)についてはプラグインがあって、勝手に略語の定義を探してきてくれたりするのだけど、漢字(かんじ)のルビのプラグインはまだないようだ。なら作ってしまえ、と思ったのだけど、Windowsでプログラムを書くなんてことに恐怖を覚えてしまうし、果たして書けるものかどうかも分からない。あまり大げさにしたくもないので、wxPythonで書いてみた。

一応、ルビ()と略語(と)を作ってクリップボードに送るように書いてある。これをWLWで「形式を選択して貼り付け → HTML」を選べば、そこそこうまいことやってくれる。ただルビはうまく処理できておらず、ルビの外側に書き続けたいのにルビの内側に書き加える形になってしまったり。

勢いで書いてしまいましたが、自分で使うかどうかはわかりません。あと「TAB」キーでフォーカスが移動しないのはなんでだろう…