金環日食

5月21日に発生した金環日食ですが、第一接触から第四接触に至るまでの全過程を観測することができました。



上から第二接触(金環の始まり)、最大食、第三接触(金環の終わり)です。
ベイリービーズもばっちり見えます。

前日から宇宙クラスタ仲間三名が私の自宅に集まり、どこで見るのかを検討していました。
当日は日食帯全域で雲が出る予報だったため、GPV 気象予報 を使って雲の動きを見ながら観測場所を考えていました。
最初は千葉東部、次に水戸、浜松、埼玉、青梅、山梨と観測予定場所を切り替え、最終的に午前三時の予報を信じて青梅での観測に決定しました。
で、撮れたのが上の写真。
観測当時は近所のおばちゃんたちも何人か出てきて、一緒に見ていました。

反省点も多々ありますが、まぁ、何とかなったと言うことで。

遮光グラスを使って太陽を確実に見つける方法

金環日食まであと1ヶ月切りました。
メディアの露出も増えてきているので、日食観測の準備を始めている方も多いんじゃないかと思います。
日食を観測するのに絶対必須のアイテムが遮光グラスなんですが、これを装着した状態で太陽を見つけるのって非常に難しいんですよね。
何しろ減光率が10万分の1ですから、太陽以外は全く見えません。
かといって裸眼で太陽を見てしまうと、確実に目を痛めます。
見えないものを見つけるために見てしまうわけに行かないこの難しさ。さぁ、困った。
まぁ、慣れれば額で太陽を見つけることもできるんですが。
# 額が一番暖かい方向を向く

そこで、遮光グラスを使用していても確実に太陽を視野に入れる方法を考えてみました。

1. 太陽を背に向けて、自分自身の影に正対する。
2. 下を向いたまま、回れ右をする。
3. 下を向いたまま遮光グラスを装着し、顔を上げる。

実際にやってみると、気持ち悪いくらい一発で見つけられます。
特に、小学生くらいの子供さんに観測させる場合にはオススメ。
あと、双眼鏡で観測する場合。
小学校で叩き込まれる「回れ右」ってかなり厳密に180度回転できますから、視野の狭い双眼鏡でも有効なはずです。


さて遮光グラスを使ったからと言って、安全に太陽観測ができるとは限りません。
正しく使わなければ事故の元です。
遮光グラスの付け外しは、必ず下を向いて行いましょう。
また、遮光グラスは側面を両手で覆って、確実にホールドしてください。

第三回金環日食シンポジウム 発表資料

先週土曜日の4月21日、三鷹の国立天文台で開催された「第三回金環日食シンポジウム」に参加してきました。
そのポスターセッションに参加しましたので、その資料を掲載します。
内容は先の「わんくま名古屋」から日照網膜症に関する部分を切り出した上でもう少し拡充したものです。

発表資料：皆既日食観測での日食網膜症の罹患について(PDF/739KB)

2009年7月に皆既日食がありましたが、私はこの日食を飛行機から観測する機会に恵まれました。
地上が大雨の中、私たちは皆既をはっきりと観測することができましたが、その代償に日食網膜症を患ってしまったわけです。
文字通りの痛い目を見ましたので、来月の金環日食ではそうなる人が出ないことを祈って参加しました。

日食観測って、正しく行えばかなり安全であると思うんです。
が、不適切な観測をすれば文字通り目を焼いてしまいます。
病気を患うのはある程度仕方のない部分もありますが、日食網膜症は100%自業自得で、避けようと思えば避けられる障害です。
どうか皆様、目を大切に。

さて、会場でよく聞かれた質問。

・完治したのか
　⇒ 少なくとも、視野や視力に影響はありません。が、疲労や脱水症状、強い光を見たりすると目の奥がうずきます。実は徹夜明けで、シンポジウム中も目が痛かったりorz

・太陽を直接見たのか
　⇒ 少なくとも私は、直接見た覚えがありません。しかしフィルタは能力が保証されている(後でスペクトル取ってもらった)ので、不適切な観測に依ることはまず間違いありません。

以上二点がよく聞かれました。

金環日食

4月14日(土)、「わんくま同盟名古屋勉強会#21」にスピーカーとして参加してきました。
わんくま同盟はIT技術者が多く集まるコミュニティですが、勉強会そのものはノンジャンルですので、たまにはこんな話も出るわけで。
というか、私の登壇ネタは宇宙系と .NET Framework 系が半々くらいでしょうか。

発表資料：金環日食(PDF/900KB)

今回伝えたかったことは「目を大切に！」の一言に尽きます。
太陽光線は非常に強く、間違った日食観測は文字通り目を焼きます。
その目を焼いた例がここにいるわけでして、文字通り「痛い目」に会いました。
日食網膜症って、ぶっちゃければ網膜のヤケドなんだよ！

さて。
日食というのは、月が太陽を隠すことで起こる現象です。
ということは、新月の時にしか起こらないワケです。
しかし新月の時ならいつでも起こるかといえばそうでもなく、月の公転面は地球の公転面に対してわずかに傾いているため、ほとんどのケースでは月と太陽は別々の方向にあるわけです。

でもまぁ、全地球的には日食ってあまり珍しい現象でもなく、部分日食、皆既日食、金環日食を合わせると、年に2、3回は発生しています。
ただ発生地域が恐ろしく限られるため、特定の地域に限っていえば「一生に一度見れるか否か」くらいになります。

んじゃまぁ、実際に日食網膜症を患った身として。
きっぱりと目が痛いです。
最盛期には、目をくりぬいた方がいいんじゃないかと思うくらい。
幸いにして私は完治しましたが、統計的には運のいい半数に入ったに過ぎません。
実際に、知人の中には視覚欠損にまで至った方もいますし。
てことは、日食網膜症になるくらいだったら観測を中止して次の機会を狙った方がいいわけです。
日食はちょっとがんばれば結構見えるけど、目は一度壊したら二度と元に戻りません。

では安全に観測するには、きちんとした遮光グラスがほしくなります。
ところが、遮光グラスって安物だと目を覆う面積が極端に小さいんですね。
これ、危ないと思うんです。
眼鏡をかけている方は、よほど大きな丸眼鏡でもないと眼鏡の縁が見えることを思い出してください。
遮光グラスかけていても、この縁の外に太陽があったら目を焼いてしまいます。
けっきょく、ビクセンの太陽観測グラスが一番確実ということになるわけです。

あとは、ピンホール法や投影法による観測。
こちらは太陽を直接見ない間接観測ですから、非常に安全です。
でもピンホールを通して太陽を見たり、投影板と望遠鏡の間に頭を突っ込む輩が出てくるでしょうから、指導者の監視の下、安全に観測していただきたいですね。

IDisposable を確実に成敗する

わんくま同盟東京勉強会#64(2012/10/22)と名古屋勉強会#19(2011/10/29) での発表資料です。
数カ所から欲しいと言われていた資料ですが、長いこと放置していて申し訳ありません。
# #18 の LT 資料があがってるのを見て勘違いしていたorz

発表資料
ソースコード

DB やファイルアクセスをするクラスは、一般に IDisposable インターフェースを継承して作成します。
こうすると using ステートメントを使用できるようになり、アンマネージドリソースを確実に解放できるようになります。

using ステートメントは非常に優れたシンタックスシュガーなんですが、欠点もいくつかあります。
たとえば親が子供を産み、子供が孫を産み……で、その一族がことごとく IDisposable なオブジェクトだった場合はネストがえらいことになります。
LDAP だったら 3 段程度、Excel を操作しようとすると 6 段 7 段当たり前の世界が待っています。
もちろんフラットな書き方をすればネスト問題の多くは解決するんですが、たとえばExcelのブックを開く場合のように、子供を産む前に何らかの処理が必要になる場合はネストが深くなってしまいます。
他にもスコープが一つのメソッド内に限られるなど、運用の柔軟性に欠ける面もあります。

ところが Stack を使用すると、これらの問題が一気に解決してしまいます。
IDisposable オブジェクトを生成するたびに StackK に積み込み、解放のタイミングで foreach で回して、それぞれの Disopse() メソッドを呼び出すわけです。
通常は try-finally の finally 節で上記の解放処理をしますが、メンバ変数の場合は Dispose() メソッドやデストラクタで行ってもいいでしょう。

しかし、タイプ量が増えるのが問題です。
そこで Stack をメンバに持つ Disposer クラスを設計しました。
Disposer.Push() で IDisposable オブジェクトを自身のスタックに積み込みますが、このメソッドは引数をそのまま返すため、スマートポインタのように扱うことが可能です。
さらに IDisposable を継承しているため、using ステートメントを使用することで解放処理がさらに簡便になります。

さらに発展させて、Disoposer をメンバに持つ、Excel の各クラスのラッパークラスを作ってみましょう。
レイトバインドで Excel を叩こうと思うと、どのみちラッパークラスが必要です。
そして、それぞれが子供を産むたびに自身の Disposer に積み込むようにしましょう。
すると従来の COM アクセスでは不可能だった「プロパティの連鎖」すら可能になってしまいます。

レイトバインドの場合、インストールされている Excel のバージョンを問いません。
この機構は元々 Excel2000/2003 両対応のアプリケーションを作成するのに作ったんですが、そのアプリは2007, 2010 に至る現在でもノーメンテナンスで動作しています。
# 32bit/64bit 両対応でもあるから、改修予算を取りっぱぐれたというorz

署名つきアセンブリをテストする

VS2010 で DLL を作成し、それを VS 標準の MSTest で単体テストしている。ところが DLL とテストプロジェクトに署名をしたところ、テストプロジェクトをビルドする段で下記のエラーが発生した。

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamTest\Microsoft.TeamTest.targets(14,5): error : 値が有効な範囲にありません。

ネットを漁っても有効な解決策を見つけることはできなかったが、 #if ディレクティブを使用することでこのエラーを回避することができたので報告する。


プロジェクト構成は、テスト対象である "Common" と、テスターである "CommonTest" の二つ。
当初は署名なしで開発を進めていたが、電子署名が供給されたので "Common" に対して署名を設定することにした。
ところが "Common" の internal メソッドをテストするために、 "InternalsVisibleTo" 属性を設定している。
従って "CommonTest" にも署名が必要になるが、そしたらビルド時に上記のようなエラーが発生するようになった次第。

まずは "Common" と "CommonTest" の署名のあり/なしの組み合わせを調べてみた。
すると、双方とも署名なしの場合のみビルドが通った。
"Common" に署名をつけると

フレンド アセンブリ参照 'CommonTest' は無効です。厳密な名前の署名つきアセンブリはその InternalsVisibleTo 宣言内で公開キーを指定しなければなりません。

というエラーが出る。それではと思って "CommonTest" に署名をつけてその公開キーを指定すると、冒頭のエラーが出て "CommonTest" のビルドが通らない。

次に "Microsoft.TeamTest.targets" でぐぐってみると、以下の2件だけがヒットした。

えーとつまり、アクセサによるプライベートメソッドへのアクセスが原因か？
いやいや、今回はパブリックメソッドだけのテストで済ませるのは不安ありまくり。
かといって、今更リフレクションでどうにかするのもチト、いや、かなりきつい。

2012/03/29 追記 ---
非常に単純なプロジェクトで試してみたら、アクセサによるプライベートメソッドのテストを作ってみても問題なくビルドが通った。
件のプロジェクトは継承やCOM連携なども仕込んであるので、まだ他に原因があるのかもしれない。
--- 追記 ここまで

そこでコンパイルシンボル "TEST" が有効な場合は "InternalsVisibleTo" 属性を有効にした上で CommonTest プロジェクトもビルドし、無効な場合は "AssemblyKeyFile" 属性で署名ファイルを指定するようにした。

// AssemblyInfo.cs
#if TEST
[assembly: InternalsVisibleTo( "CommonTest" )]
#else
[assembly: AssemblyKeyFile( "Common.snk" )]
#endif

その結果、パスワードなしの署名ファイル(.snk)でならビルドが通るようになった。
しかし、パスワード付きの署名ファイル(.pfx)だと以下のエラーが発生する。

エラー CS1548: アセンブリ '<アセンブリファイル>' を署名しているときに暗号に失敗しました -- 'アセンブリ署名のエラー -- パラメーターが間違っています。 '

AssemblyKeyFile にパスワードを指定できない以上、当然っちゃー当然だわな。
そこで今度は sn.exe で .pfx ファイルからキーペアを CSPコンテナに突っ込み、AssemblyKeyName 属性でキーコンテナ名を参照することにした。

C:\>sn -i CommonPass.pfx CommonKeyPair
// AssemblyInfo.cs
#if TEST
[assembly: InternalsVisibleTo( "CommonTest" )]
#else
[assembly: AssemblyKeyName( "CommonKeyPair" )]
#endif

その結果、パスワード付きキーペアであってもビルドに成功した。
ただし、AssemblyKeyFile、AssemblyKeyName のどちらを使用した場合も、ビルド時に下記の警告が発生する。

警告 CS1699: コマンド ライン オプション '/keycontainer' を使用するか、'AssemblyKeyName' 以外の適切なプロジェクト設定を使用してください。

リリース用の設定で警告が出るのは少しばかり気持ちが悪いんだが。
もちろん、警告の意図を知った上で無視してはいるんだけど。
他に何かいい手はないものかなぁ。

住基カード作ってきた

先ほど、所用で市役所に行ってきました。
市民課、収納課など一部の課だけとはいえ、日曜日にも窓口が開いていてくれるのは本当にありがたい。
ところが、青梅市役所のサイトには日曜窓口について何も書かれていないんですね。
木曜日の夜間窓口業務については書かれているのに。

さて、所用のついでに住基カードも作ってきました。
住基カードには名前だけが書かれているA様式と、顔写真や住所も記載されていて公的身分証明書としても使えるB様式があります。
電子納税をするだけならA様式で十分なんですが、B様式が必要になった場合にはA様式のカードを廃止手続きした上でB様式を作り直すことになるそうです。
住基カードの有効期限は10年間らしいので、写真代が別途かかるけどオールマイティなB様式を選択しました。

ついでに窓口でいろいろ聞いてきたんですが、電子納税だけを目的とする人はA様式を選ぶことが多いそうです。しかしB様式は運転免許証よりも強力な公的身分証明書になるので、たとえば横田基地に出入りする業者さんなんかが申し込むようですね。
横田基地に入るには国籍の確認があるらしく、本籍地の記載のない運転免許証だとパスワード必須らしいです。でも住基カードだと見せるだけなんだとか。

そういえば身分証明書として運転免許証を提示するのに、プライバシーを気にする人がいるそうです。そういう理由でB様式を選ぶんだとか。
どちらも住所・氏名・生年月日・顔写真が入っているんですけどねぇ。
だいたい身分証明って、プライバシーの一部を開示する行為そのものでしょうに。
プライバシー権を声高に吠え立てる人の考えってワケワカラン。